跳到主要内容

第 2.2.1 节：先圈定哪些文档适合解析入库

进入实现之前，先围绕“先圈定哪些文档适合解析入库”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出文档的适用场景、不适用场景、前置条件和进入工程实现的判断标准。

本章要解决什么问题​

上一章讲了 RAG（检索增强生成） 的边界：它适合回答“企业资料里有依据的问题”，不适合替代工具调用、审批和人工判断。从这一章开始，我们进入 RAG 真正容易翻车的上游环节：文档解析和数据入库。

很多新手做知识库，会把第一步理解成“上传文件，然后提取文字”。这个理解太粗糙。企业客户交给你的资料通常不是干净文本，而是一批混合来源：

  • 售后政策 PDF（便携式文档格式），里面有页眉、页脚、表格、脚注和旧版条款。
  • 产品说明 Word（文字文档），里面有标题层级、批注、修订痕迹和嵌入图片。
  • 价格表 Excel（电子表格），价值在 sheet（工作表）、表头、行列关系、单位和生效日期。
  • FAQ（常见问题） Markdown（轻量标记语言），结构清楚，但可能混有代码块、引用和历史说明。
  • 官网网页，正文旁边有导航、页脚、推荐文章、活动横幅和脚本噪声。
  • 扫描件或拍照资料，需要 OCR（光学字符识别），还可能出现错字、漏行和倾斜。
  • 历史工单，里面有客户原话、客服处理过程、隐私信息、内部备注和最终结论。

如果这些资料在入库前被解析坏了，后面的 Embedding（嵌入向量）、分块、索引、检索、重排序和生成都会被连带拖坏。坏解析不会只停留在上游，它会在下游表现成更难排查的问题：检索命中错误、引用指向错误、旧政策覆盖新政策、表格价格被读错、模型把页脚当正文、OCR（光学字符识别）错字被当成正式条款。

本章要解决的问题是：如何把真实企业资料转换成可检索、可追溯、可更新、可权限控制、可质量验收的中间文档格式。

这里有一句话要提前记住：文档解析不是 RAG 的杂活，而是 RAG 的上游闸门。坏解析会毁掉检索。

本章用流程图、字段契约、状态流转、质量标记和验收清单，带你建立文档入库的工程设计方法。

学习目标​

学完本章后，读者应该能做到：

  • 说明为什么文档解析会直接影响 RAG 的检索质量和引用可信度。
  • 区分 PDF（便携式文档格式）、Word（文字文档）、Excel（电子表格）、Markdown（轻量标记语言）、网页、扫描件/OCR（光学字符识别）和工单历史的解析重点。
  • 设计一套解析后的中间文档格式，而不是把所有资料粗暴拼成纯文本。
  • 为每份资料保留来源、版本、文件指纹、权限、状态、生效日期、质量评分和入库追踪编号。
  • 设计表格块、图片块、正文块、标题路径和原始位置的记录方式。
  • 设计 parse_status（解析状态）、ocr_status（光学字符识别状态）、quality_score（质量评分）等质量字段。
  • 说明入库日志如何帮助排查“为什么这个问题搜不到”。
  • 设计解析失败、OCR（光学字符识别）低置信度、权限缺失、版本冲突和表格丢失时的兜底。
  • 把本章能力连接到后续分块、Embedding（嵌入向量）、索引、重排序、MCP（模型上下文协议）和 LangGraph（智能体状态图框架）。
  • 在面试中把文档解析讲成知识工程能力，而不是“我用了某个 loader（加载器）”。

贯穿业务场景​

本章继续使用同一个贯穿项目：企业客服知识库与工单 Agent（智能体）工作台。

这个工作台要服务外部客户、一线客服、售后专员、运营管理员和质检负责人。系统需要回答产品、售后、价格、保修、FAQ（常见问题）和历史处理经验相关的问题，也要在必要时切到 Tool Calling（工具调用） 查询订单、创建工单或转人工。

现在客户交给你第一批资料：

资料来源具体例子业务价值解析难点
售后政策 PDF（便携式文档格式）2026 年售后退换货政策、保修条款回答退货、换货、保修、维修问题页眉页脚、页码、表格、扫描页、版本冲突。
产品说明 Word（文字文档）产品安装说明、使用限制、注意事项回答产品适用范围和操作步骤标题层级、嵌入图片、批注、修订痕迹。
价格表 Excel（电子表格）不同套餐、地区、渠道价格回答价格和套餐差异sheet（工作表）、表头、单位、合并单元格、生效日期。
FAQ（常见问题） Markdown（轻量标记语言）客服常见问题与标准答复快速回答高频咨询标题结构、列表、表格、引用、历史废弃段落。
官网网页产品页、服务页、帮助中心面向外部客户的公开资料导航、页脚、广告、重复链接、抓取时间。
扫描件/OCR（光学字符识别）盖章制度、老版合同附件、图片说明补充历史资料或正式文件识别错误、漏字、页序错乱、图片质量差。
历史工单客户投诉、售后处理记录、客服备注发现真实问题和解决路径隐私脱敏、内部备注、情绪文本、最终结论不稳定。

客户的期待通常很简单：“这些资料能不能直接做成知识库？”工程师不能只回答“能”。你要继续追问并落地：

  • 哪些资料是正式有效的？
  • 哪些资料只能内部客服看？
  • 哪些资料已经过期但仍有参考价值？
  • 哪些资料需要 OCR（光学字符识别）或人工复核？
  • 表格和图片要不要进入检索？
  • 历史工单是作为知识依据，还是只作为质检和经验挖掘来源？
  • 每次入库失败后，谁能看到失败原因，谁负责修复？

一个成熟的客服知识库不是“文件上传成功”就结束，而是要让每个可检索片段都能回答 6 个问题：它来自哪里、属于哪个版本、谁可以看、是否生效、质量如何、出了问题如何追踪。

新手为什么会卡住​

新手做文档解析和数据入库，通常不是卡在某一个库怎么调用，而是卡在“资料进入知识库之前要治理什么”。常见误解有 9 个。

误解问题在哪里正确理解
文档解析就是抽文字抽文字会丢失标题、表格、图片、页码、来源和权限解析目标是生成带结构、元数据和质量标记的中间文档。
所有格式都可以转成纯文本Excel（电子表格）行列关系、PDF（便携式文档格式）页码、网页正文区域都会丢不同格式要保留不同结构，不能一刀切。
loader（加载器）能自动解决一切加载器只负责一部分抽取，不负责业务版本、权限、审核和日志工程系统要补上治理层和验收层。
文件名就是来源文件名可能重复、被改名、没有版本信息需要 source_id（来源编号）、file_hash（文件指纹）和入库记录。
旧资料先放进去再说旧政策可能和新政策同时命中，导致错误承诺入库前要有版本、生效日期、失效状态和冲突处理。
扫描件 OCR（光学字符识别）出来就能用低清晰度扫描会出现错字和漏行需要 ocr_status（光学字符识别状态）、置信度和人工复核。
表格转成一段话也能搜价格、套餐、地区、单位会混乱表格要保留 table_blocks（表格块）和表头关系。
权限可以等检索时再管入库时没有权限标签，后面很难可靠过滤permission_tags（权限标签）要在资料进入系统时写入。
入库失败是技术细节运营不知道失败原因，就无法修资料入库日志必须让运营、客服和开发都能定位问题。

这些误解背后有一个共同点：把文档解析当成技术前置步骤，而不是知识库质量控制。真实项目里，RAG 效果差，经常不是模型差，而是资料在入库时已经坏了。

继续学习​