RAG 如何处理 PDF、Word、Excel 和网页？

上一篇文章里我们讨论了 RAG 如何做多租户。一个重要结论是企业级 RAG 不能把所有知识混在一起租户边界、权限边界和配置边界都要设计清楚。但多租户只是基础。真正到了企业知识库里你还会发现一个更现实的问题知识并不是纯文本。真实文档往往来自PDF Word Excel 网页 图片中的文字 系统导出的报表 邮件正文 Wiki 页面这些文档格式不一样结构不一样解析难度也不一样。如果文档解析做不好后面的切分、Embedding、检索和生成都会受到影响。所以这篇文章讨论一个非常基础但决定上限的问题RAG 如何处理 PDF、Word、Excel 和网页。为什么文档解析这么重要RAG 的第一步不是检索而是把资料变成可用的知识单元。也就是说系统必须先理解文档里到底写了什么。原始文件 ↓ 解析 ↓ 清洗 ↓ 切分 ↓ Embedding ↓ 检索如果解析阶段把内容弄错了后面的结果自然也会错。比如表格列错位 页眉页脚混进正文 标题层级丢失 图片里的关键字段没识别出来 Excel 的表头和单位丢了 网页导航内容被当成正文这些问题不会让系统立刻报错但会慢慢污染知识库。最后表现出来就是检索不到真正答案 召回了错误片段 模型回答看似合理但依据不稳 引用内容和原文对不上所以文档解析不是前置小工具。它是 RAG 系统的地基。PDF 为什么最麻烦在企业知识库里PDF 往往是最常见也最麻烦的格式。因为 PDF 不是天然的语义文档它更像“排版结果”。同一份 PDF 可能包含正文 表格 图片 页眉页脚 脚注 跨页段落 多栏排版 扫描件PDF 解析常见问题包括第一文字顺序错乱。多栏排版的段落可能被打乱。第二表格错位。单元格内容容易被拆散。第三页眉页脚污染正文。第四扫描件没有文本层。需要 OCR 才能识别。第五公式、特殊符号和图注容易丢失。所以 PDF 不能只靠一次解析就直接入库。更合理的做法是判断 PDF 类型 ↓ 如果有文本层提取正文和结构 ↓ 如果是扫描件走 OCR ↓ 清理页眉页脚 ↓ 保留标题、段落、表格、图片说明 ↓ 再做切分对于 PDF 表格最好保留表头、行名和单位。因为很多答案不是在正文里而是在表格里。比如审批额度表 错误码说明 接口字段列表 报价规则这些都需要尽量结构化提取。Word 文档适合保留结构Word 文档比 PDF 更适合结构化解析。因为它本身有标题、段落、列表和表格等语义结构。Word 解析时建议尽量保留标题层级 段落 列表 表格 批注 版本信息如果只把 Word 当纯文本处理很多结构会丢失。比如一级标题 二级标题 项目符号列表 注意事项 表格这些信息对于后续切分非常重要。Word 文档里还经常有修订痕迹 页眉页脚 自动目录 模板说明 空白页这些内容通常不该进入知识库正文。所以 Word 解析建议保留结构 清理模板噪声 保留表格和列表语义 补充文档版本和作者信息如果文档中包含修订模式最好在入库前先确认是否使用“最终版”。否则历史修订和备注也可能污染答案。Excel 不是简单文本而是结构化知识Excel 是很多 RAG 系统最容易被低估的格式。很多人会把 Excel 直接拼成文本。这通常不够好。因为 Excel 的核心价值是结构表头 行列关系 单位 字段依赖 区间值 空值含义如果只把它转成一串文本很多信息会丢失。比如一个报表部门 | 审批额度 | 审批人 财务 | 10 万以下 | 主管 财务 | 10 万以上 | 总监这里真正重要的是列关系不只是字面内容。Excel 解析建议第一先识别工作表名称。第二保留表头和单位。第三处理合并单元格。第四尽量保留行列语义。第五识别空值、默认值和备注列。第六对大表做分块而不是整张表直接塞进上下文。对于 Excel最好的方式往往不是纯文本化而是“半结构化入库”。比如把每一行转成可检索记录{sheet:审批规则,department:finance,limit:10万,approver:主管}这样检索会更稳。如果是数值报表、列表报表、对照表这种结构化处理特别有价值。网页正文抽取最怕噪声网页是另一类非常常见的数据来源。网页问题在于页面上不只有正文还有大量无关内容导航栏 菜单 侧边栏 相关推荐 广告 评论区 脚注 登录提示 弹窗 分享按钮如果抽取不干净知识库会被噪声淹没。网页正文抽取通常要做几件事第一识别正文区域。第二过滤导航、广告、推荐和评论。第三保留标题、段落、列表、代码块和表格。第四处理懒加载和分页内容。第五注意文章更新后的版本变化。很多网页文章还会有上一篇 下一篇 相关推荐 作者信息 版权声明这些内容一般不该直接进入正文。网页抽取的目标不是把页面文字全拿下来。而是尽量提取“对问答有价值的正文”。不同文档要用不同策略文档类型不同解析策略也应该不同。可以大致这样理解PDF优先恢复正文顺序和表格结构 Word优先保留标题层级和列表语义 Excel优先保留行列关系和表头 网页优先抽取正文并过滤噪声 图片优先 OCR再补充结构化理解如果全部文档都用同一套解析逻辑效果通常不会好。因为PDF 需要解决排版问题 Word 需要解决结构保留问题 Excel 需要解决表格语义问题 网页需要解决噪声过滤问题所以文档解析前最好先识别文档类型。然后给不同类型设置不同流水线。解析后的清洗和切分更关键文档解析只是第一步。解析后还要做清洗和切分。比如PDF 页眉页脚清理 Word 模板噪声清理 Excel 空行和备注处理 网页导航和推荐内容过滤然后再按结构切分成 Chunk。如果文档本身结构清晰切分可以更稳。比如一级标题下面的段落作为一个自然块 表格按表头和行块切分 代码块单独保留 长段落按语义断点切分这样检索时更容易命中真正有用的片段。如果解析不好切分就只能盲切。盲切会导致标题丢失 上下文断裂 表格语义破坏 答案不完整所以解析和切分必须联动。解析失败怎么办真实场景里解析失败很正常。比如文件损坏 PDF 加密 图片分辨率太低 表格结构太复杂 网页反爬 编码异常这时系统不能悄悄吞掉错误。应该明确记录文件类型 解析引擎 失败原因 失败位置 重试次数 是否需要人工介入如果解析失败可以考虑几种兜底方式换解析器 走 OCR 切换备用抓取策略 人工上传结构化版本 标记为待处理不要为了追求“尽量都入库”而把低质量内容硬塞进去。因为坏数据进库以后后面清理会更难。一个可落地的文档处理链路一个比较稳的企业 RAG 文档链路可以这样设计文件接入 ↓ 文档类型识别 ↓ 解析器分流 ↓ 正文抽取 ↓ 结构保留 ↓ 噪声过滤 ↓ 元数据补全 ↓ 质量检查 ↓ 结构化切分 ↓ Embedding ↓ 索引入库其中几个关键点第一文档类型识别要尽量早。第二结构化信息要尽量保留。第三清洗规则要区分文档类型。第四解析失败要有日志和兜底。第五表格、代码块、列表、标题这些结构不要轻易丢。落地建议第一不要把所有文档都当纯文本处理。第二PDF、Word、Excel 和网页要分开设计解析策略。第三尽量保留标题层级、表格和列表等结构信息。第四网页抽取要重点过滤噪声。第五Excel 不要只拼接成大段文本尽量保留行列语义。第六解析失败要可观测不要静默失败。第七解析后的结果一定要做质量检查再入库。第八文档处理链路要和切分、检索、评测联动起来看。总结真实 RAG 知识库的第一道门槛不是模型而是文档处理。PDF、Word、Excel 和网页各有各的难点。如果解析没有做好后面的切分、检索和生成都会建立在错误的文本之上。所以企业级 RAG 要做的不只是“把文件读进来”。而是要把不同类型的文档转换成结构清楚、噪声干净、可追溯的知识单元。下一篇文章可以继续讨论多模态 RAG。因为越来越多知识不是纯文本图片、截图、图表和表格也需要进入检索链路。