知识库项目七成工作量在文档，不在系统
做过知识库项目的人都知道一件事：系统搭起来是最快的部分。
真正吃时间的是文档——把散在各处、格式各异、版本混乱的资料，变成能被检索的东西。这部分工作量经常占到七成，却经常在报价时被算成零。
这篇讲怎么在动手之前把这件事估清楚。
摸底要看的四件事
报价之前一定要看甲方的真实文档，不是听他们描述。重点看四件事。
一、格式：扫描件是最大的坑
扫描版 PDF 本质上是图片，没有文字层。 直接传进知识库，系统读到的是空的——你以为传进去了，其实什么都没有。
判断方法很简单：用 PDF 阅读器打开，试着选中一段文字。 选不中就是扫描件。
处理方式是先做 OCR，但 OCR 的效果取决于原件质量：清晰的印刷件效果不错，复印多次的、有手写批注的、表格密集的，识别错误率会明显上升，而且错误往往是隐蔽的——数字识别错一位，答案就完全错了，还查不出来。
这部分工作量要单独算，而且要留出人工校对的时间。
二、结构：表格和长文档
表格是第二个坑。 一个二维表被拉平成一行文字之后，行列的对应关系就丢了。「张三的联系方式是多少」这种问题，在丢了表头对应关系的文本里是答不出来的。
处理方式取决于量：表格不多的话，手工转成问答形式的文本最可靠；量大的话要考虑专门的表格解析，但效果需要实测。
长文档的问题是上下文依赖。 一段话写着「上述三种情况均需提前申请」，单独被检索出来时，读者根本不知道「上述」指什么。这类内容需要在切块时特殊处理，或者干脆改写。
三、时效：过期文档比没有文档更糟
这是最容易被忽略、后果最严重的一条。
如果新旧两版制度都在知识库里，系统会随机挑一个来答，而你无法预测它挑哪个。用户拿到的答案可能是三年前作废的规定——这比系统答「我不知道」危险得多，因为它看起来是对的。
文档治理这件事必须在项目范围里说清楚：是甲方负责整理出有效版本，还是你来做？如果是你来做，那要有人跟甲方逐份确认哪些还有效——这个沟通成本往往比技术工作还大。
写进合同：要么明确这部分由甲方负责，要么明确它是收费的工作内容。含糊过去的话，最后一定是你在做，而且没收到钱。
四、覆盖度：知识到底在不在文档里
这是最根本的一个问题：用户会问的那些问题，答案真的写在文档里吗？
很多组织的真实情况是：一部分知识写在文档里，一大部分在老员工脑子里。上知识库系统只是把这个问题暴露出来——用户问了，系统答不上来，因为答案从来就没被写下来过。
摸底方法：让甲方列出二三十个用户最常问的问题，然后逐个去文档里找答案。找不到的比例，就是这个项目的真实缺口。
如果缺口很大，那这个项目的第一阶段其实是知识梳理，不是系统建设。这件事要在方案阶段讲明白，否则验收时双方都难受。
怎么估工作量
一个粗略的框架，按文档状态分三档：
状态好：电子文档为主，结构清晰，版本明确，有现成的问答手册或规范条目。这种情况文档处理的工作量最小，主要是导入和切块调优。
状态中等：格式混杂，有一些扫描件和表格，版本基本清楚但需要确认。需要预处理和人工介入。
状态差：大量扫描件、表格密集、版本混乱、知识大量未成文。这种情况下文档整理本身就是一个独立项目，应该分阶段做、分别报价。
判断依据是实际看到的文档，不是甲方的自我描述。 甲方普遍会低估自己文档的混乱程度——这不是他们不诚实，是他们太熟悉自己的资料，意识不到外人看不懂。
文档怎么组织才好检索
摸底之后，如果要做整理，有几个原则：
按用户的问法组织，不是按内部的分类。 内部文档写「退换货政策」，用户问「买错了能换吗」。最省事的办法是把用户的常见问法直接写进文档，让两边对得上。
一个片段回答一个问题。 把十条政策塞进一大段，检索时相似度会被稀释，模型拿到的材料里还混着九条无关内容。拆成一问一答的形式，效果明显不同。
别让片段依赖上下文。 写的时候假设每一段都会被单独拿出来读。
朴素的验证标准：随便挑几个切好的分段自己读一读。如果你自己都读不懂，模型也读不懂。 这个标准比任何参数调优都管用。
切块策略要能调
不同类型的文档，合适的切法完全不同：
- 规章制度、技术规范：有清晰条目结构，按条目切最合适
- FAQ、问答手册：一组问答就是一个自然的块
- 叙述型长文：按段落或语义切，但要处理上下文依赖
所以能不能自己调切块策略，是判断一个方案能不能落到实处的关键指标。只能按固定长度切、没有调整余地的方案，在结构化文档上效果会明显受限。
各平台在这方面的能力差别见平台页，检索效果的排查方法见 Dify 知识库检索不准怎么排查。
验收标准要提前定
「回答得准不准」没法验收，双方各说各话，项目就卡住了。
可行的做法是提前定一批测试问题——三十到五十个真实业务问题，双方一起确认标准答案，验收时按这批题跑。
好处有三个：验收有客观依据；开发过程中能当回归测试；甲方在整理测试题的过程中，自己会想清楚需求。
同时要提前说明能力边界：需要跨多个文档做对比推理的问题（「A 部门和 B 部门的标准有什么不同」），检索式问答天然不擅长。这类问题要么排除在验收范围外，要么单独设计流程处理——写在方案里，别等验收时才解释。
小结
知识库项目的成败，七成在动手之前就决定了：
- 看真实文档，不听描述
- 拿常见问题去文档里找答案，量出真实缺口
- 把文档治理的责任写进合同
- 提前定可测的验收标准
- 最后才是选平台、搭系统
跳过前四步直接搭系统，是我们见过最常见的浪费。
如果需求已经超出平台能力，判断标准见低代码 Agent 平台的能力边界。项目上拿不准也可以直接找我们聊。