文档解析为什么是企业知识库最大的坑：PDF、扫描件、表格、PPT 各自怎么处理
做知识库，很多人把预算和精力花在选模型、调提示词上，真正拖垮效果的往往是前面那一步：文档解析。我们接手过几个「模型换了三轮、答案还是不对」的项目，回头一查，向量库里存的是一堆断句、错行、串列的文本，模型再强也只能照着垃圾答。这篇按文件类型讲，都是踩过的坑。
先明确一件事：解析质量决定问答上限
RAG 的链路是「解析 → 分块 → 向量化 → 检索 → 生成」。前一步错了，后面全是放大器。一句「违反本条规定，罚款 500 元」如果被切成「违反本条」「规定，罚款 500」，检索时命中的概率极低，因为语义已经碎了。
我们内部有个粗略的判断标准：随便抽 20 个片段，让不熟悉业务的人读一遍，如果读不出完整意思，这批解析就是不合格的。别急着怪模型幻觉，先看切片。
PDF：看起来最规整，实际最会骗人
PDF 不是文档格式，是打印格式。它只记录「这个字画在坐标 (x, y)」，不记录段落、标题、阅读顺序。这带来三个典型问题：
- 双栏排版被横向拼接。学术报告、产品手册常见左右两栏，按坐标顺序抽取会把左栏第一行和右栏第一行连成一句，读起来像乱码。
- 页眉页脚混进正文。每页顶部的公司名、页码、密级标识，会被当作正文切进片段，检索时大面积误命中。
- 「伪文本」PDF。看起来能选中文字，实际是字体子集乱码，抽出来是「」这类字符。这种情况要直接转 OCR 路线，别在文本抽取上耗时间。
处理建议：优先用能识别版式的解析器（按栏切分、识别标题层级），抽取后做一次页眉页脚规则清洗——同一位置连续出现 3 页以上的短文本，基本可以判定为页眉页脚。有条件的话，保留标题层级作为分块的边界，别按固定 500 字硬切。具体怎么把解析结果接进检索链路，可以参考我们的企业知识库方案说明。
扫描件：OCR 只是起点，坑在后面
扫描件（合同、发票、老制度文件、盖章通知）是第一个重灾区。很多人以为接了 OCR 就完事，实际上 OCR 之后还有三关：
- 倾斜与模糊。手机拍的纸质件常有 3-5 度倾斜，OCR 行切分会错位，长句被拦腰截断。前置做一次纠偏和二值化，准确率差别很明显。
- 字符混淆。「0/O」「1/l」「元/无」「巳/已」在低分辨率扫描件里几乎必错，涉及金额、编号、条款序号时后果严重。
- 没有版面信息。纯 OCR 只给文字流水，表格变成长串，标题变正文。必须用带版面分析的模型，输出「这段是标题、这块是表格、这行是页脚」的结构，而不是一锅粥。
我们的做法是：扫描件解析结果单独打标，检索时降低权重或强制附带原文页码，让回答能回链到扫描页图。用户点开原图核对一眼，比模型解释十句都管用。这一层在AI 智能体私有化部署里通常做成「引用回链」能力，属于必备项而非加分项。
表格：知识库答串行的头号元凶
表格是第二个重灾区，也是事故最集中的地方。原因很直接：表格的信息不在单元格里，而在「行列表头的对应关系」里。一旦解析把表头丢掉，或者按阅读顺序把表格拍平成一行文字，语义就彻底毁了。
举个真实场景：一张报价表，列是「产品型号 / 单价 / 起订量」，如果解析后变成「A型 1200 100 B型 980 200」，那么用户问「B型起订量多少」，检索很可能召回整段，模型据此编出「B型起订量 100」。这不是幻觉，是解析阶段埋的雷。
几条实操原则：
- 表格必须带表头走。每个数据行在入库前补上列名，转成「产品型号=B型，单价=980，起订量=200」这种自解释结构，再向量化。
- 合并单元格要展开。跨行跨列的合并格，解析器经常只填第一格，其余留空，导致后续行丢失归属。
- 大表拆小。几十行的宽表整块入库，检索命中后塞进上下文会挤爆窗口。按行组拆，每组自带表头。
- 数值和单位分开存。「3 个月」「90 天」混在文本里，模型做比较时容易出错。
| 文件类型 | 典型坑 | 处理方式 | 是否重灾区 |
|---|---|---|---|
| 文本型 PDF | 双栏错序、页眉页脚污染 | 版式感知解析 + 规则清洗 | 一般 |
| 扫描件 | 倾斜模糊、字符混淆、无版面 | 纠偏 + 版面分析 OCR + 引用回链 | 是 |
| 表格 | 丢表头、合并格、整表过大 | 行级自解释 + 表头补全 + 按行组拆分 | 是 |
| PPT | 文本框顺序乱、图内文字丢失 | 按形状位置排序 + 图内文字单独 OCR | 一般 |
PPT：顺序乱，但危害相对可控
PPT 的问题是「一页多个文本框」，抽取顺序按对象创建顺序而非视觉位置，结果标题跑到页尾，图注跑到开头。另外大量信息在截图和图表里，纯文本抽取等于没抽。
处理上比表格简单：按形状的坐标做一次排序（先上后下、先左后右），把每页的标题单独提出来作为分块的主题标签，图片走 OCR 把文字补进来。合并单元格那种破坏性错误在 PPT 里少见，所以危害等级低一档。培训课件、产品介绍这类内容，做成「一页一块」通常比按字数切更好用，配合企业 AI 培训里讲的检索测试方法，能快速验证效果。
一条容易被忽略的原则：解析要可回溯
不管哪类文件，解析产物都要保留三样东西：原文件 ID、页码或 slide 序号、原始片段文本。出了问题能定位到「是这份文件的第 7 页解析错了」，而不是只能看到一条向量。
我们踩过最亏的一次坑，是早期没存原文映射，用户反馈答案串行，排查了两天才发现是某份 Excel 导出的 PDF 里表格列顺序错位。后来加了抽样校验：每次批量入库后随机抽 30 条片段人工过一遍，重点看表格和扫描件。这个动作花不了多少时间，但能挡住大部分线上事故。
另外提醒一句成本：OCR 和带版面的解析模型比纯文本抽取贵不少，全量跑一遍的费用要提前算。分类型差异化处理——文本型 PDF 走轻量解析，扫描件和表格才上重模型——是我们目前比较推荐的折中。模型 API 与成本管理里有一套按任务分流的思路可以参考。
下一步可以这么试
不用一上来就重构整套系统。拿出你们知识库里被问得最多的 10 份文档，覆盖 PDF、扫描件、表格、PPT 各两类，跑一遍解析，打印出片段人工读。如果超过三成读不通顺，那就是解析问题，先修这一层，再看检索和生成。修完之后同样这 10 份文档再测一轮问答，对比效果，比任何评测榜单都直观。
需要人一起看的话，可以把样本发给我们做一次解析质量评估，或者直接打 400-873-2750 聊聊你们现在卡在哪一步。也可以先看看知识库里其他落地记录，再决定要不要动。