扫描件、表格、老文档：知识库上线前的文档预处理

知识库项目里，系统搭起来是最快的部分。真正吃时间的是把文档变成能被检索的东西。

这部分工作量经常占到七成，却经常在报价时被算成零。

这篇讲怎么判断、怎么处理、怎么估。

第一步：五分钟判断文档能不能直接用

拿到一批文档，先做这几个检查，比什么都重要。

检查一：能不能选中文字。

用阅读器打开 PDF，试着用鼠标选中一段文字。选不中就是扫描件——本质是图片，没有文字层，直接传进知识库等于什么都没传。

检查二：有多少表格。

翻几页看看。表格密集的文档要单独处理，因为拉平之后行列关系会丢。

检查三：排版是不是分栏。

双栏或多栏排版的 PDF，解析时可能按整行读——把左栏和右栏的内容连成一句，读起来完全不通。

检查四：有没有明显过期的内容。

看看有没有同一份制度的多个版本、有没有已经作废的文件。

检查五：随便挑一页，想象它被单独拿出来。

能读懂吗？如果满篇都是「上述情况」「详见第三章」，那切块之后这些片段会失去意义。

这五个检查加起来五分钟，能定下这个项目的工作量量级。

四类问题文档的处理

一、扫描件：OCR 之后必须人工抽查

OCR 能把图片转成文字，但它的错误是隐蔽的——不会报错，只会把「8」认成「B」、把「0」认成「O」。

这类错误在知识库里查不出来，只会在用户拿到错误答案时暴露，而且很难追溯原因。

处理要点：

• 原件质量决定效果。 清晰的印刷件效果不错；复印多次的、有手写批注的、表格密集的，错误率明显上升。
• 含数字、编号、金额的部分必须人工核。 这些地方错一位，后果完全不同。
• 工作量要单独算，而且要留出校对时间，不能只算 OCR 的机器时间。

一个省事的办法：先问甲方有没有 Word 原件。很多时候同一份内容有电子原稿，用原稿比处理扫描件干净得多，也快得多。这一问经常能省掉几天工作。

二、表格：量小手工转，量大要实测

二维表被拉平成文字后，行列的对应关系就没了。

一张「姓名 / 部门 / 分机号」的表，拉平后可能变成一串没有分隔的文字。问「张三的分机号」答不出来——不是检索的问题，是信息在解析阶段就丢了。

处理方式：

• 量不大：手工转成句子，「张三，技术部，分机号 xxx」。最可靠。
• 量大：用专门的表格解析方案，但效果必须实测，不能想当然。拿几张真实的表试，看解析出来的结构对不对。

判断标准：如果表格里的信息是用户会直接问的（联系方式、参数、价格），那必须保证结构不丢；如果表格只是佐证材料，丢了影响不大。

三、分栏和复杂排版：优先换来源

这类文档解析出来顺序错乱，修起来很费劲。

优先做法是换来源：找原始的 Word、Markdown 或者纯文本版本。

实在没有的话：转成纯文本后人工过一遍。量大的话，这本身就是一个独立的工作量，要单独报价。

四、老文档：编码和繁简

从老系统导出的、多年前的、不同人在不同电脑上写的文档，编码混乱的概率最高。

症状：整段变成问号或方块字。

处理：统一转成 UTF-8。批量处理时要逐个检测，不能假设都是同一种编码。

还有一类更隐蔽的：繁体字、异体字。它们能正常显示，看起来没问题，但检索时会出问题——用户用简体提问，匹配不上繁体的内容。上传前统一转简体。

详细的排查方法见 FastGPT 知识库出现乱码。

处理完之后：内容怎么组织

预处理只是让文档「能被读进去」，还要让它「能被找到」。

一个片段回答一个问题。 十条政策塞在一段里，检索时相似度被稀释，模型拿到的材料还混着九条无关内容。

按用户的问法补充表述。 文档写「差旅费报销标准」，用户问「出差住宿能报多少」——直接把用户的问法写进去，比调任何参数都见效。

补上行业黑话和标准说法的对应。 「工单（也叫报修单、维修申请）」，一句话解决检索匹配问题。

别让片段依赖上下文。 写的时候假设每一段都会被单独拿出来读。

工作量怎么估

按文档状态分三档：

状态好：电子文档为主，结构清晰，版本明确。工作量最小，主要是导入和切块调优。

状态中等：格式混杂，有一些扫描件和表格，版本基本清楚。需要预处理和人工介入。

状态差：大量扫描件、表格密集、版本混乱、知识大量未成文。这种情况下文档整理本身就是一个独立项目，应该分阶段做、分别报价。

判断依据是你实际看到的文档，不是甲方的描述。 甲方普遍会低估自己文档的混乱程度——不是不诚实，是他们太熟悉自己的资料，意识不到外人（和机器）看不懂。

一个能省大量时间的做法：先小批量验证

别一上来就处理全部文档。

常见的浪费是这样的：花两周把三千份文档全处理完、全导入，然后发现切块方式不对、或者某类文档解析有问题，于是全部重来。

推荐顺序：

第一步，挑二十份有代表性的。 要覆盖不同类型——制度文件、表格、扫描件、长文档各来几份。别挑最规整的那些，那样测不出问题。

第二步，走完整流程处理这二十份。 预处理、导入、切块、建索引。

第三步，看切出来的片段。 逐个读一遍，能不能单独读懂。这一步能暴露大部分切块问题。

第四步，拿真实问题测检索。 用二十到三十个业务同事提供的真实问题，看正确内容能不能被找出来。

第五步，确认没问题了，再处理剩下的。

这五步花一两天，能避免几周的返工。 而且第三步和第四步的发现，往往会改变你对整批文档的处理方式——比如发现某类文档必须换来源、某类必须手工整理。

另一个好处：这批样本和测试问题可以留着，作为后续验收和回归测试的基准。做一次，用很久。

合同里要写清楚的一条

文档治理的责任归属。

是甲方负责整理出干净的有效版本，还是你来做？

含糊过去的结果通常是：你在做，而且没收到钱。 而且这部分工作琐碎、耗时、没有技术含量，做起来最消耗人。

建议写法：明确「甲方提供的文档需为可编辑的电子文本，如需 OCR、表格重构、版本梳理，按工作量另计」。

完整的项目推进方法见知识库项目七成工作量在文档，交付阶段的注意事项见 FastGPT 部署与交付。

文档预处理量大、需要定制处理流程的，可以找我们聊聊。