夜雨聆风开篇：答案在文档里，为什么仍然检索不到
设想一个常见场景：集团把《差旅费用管理办法》的 PDF（便携式文档格式）接入知识库后，员工问：“跨城培训住宿超过标准能否报销？”答案其实写在制度里，却没有被找出来，系统反而给出了错误的报销上限。
问题往往并不神秘，常见失败包括：
此时再调整检索排序，得到的仍是失真的输入。对读者而言，这像一次 Retrieval-Augmented Generation（检索增强生成，RAG）失败；对工程团队而言，许多失败其实更早发生在 Data Indexing（数据索引）——知识还没有被准备成可靠使用的证据。
完整 RAG 流程与本文边界
一套完整的 RAG 流程可以分为三个边界：
三个阶段彼此相连，但各自解决不同问题。
下面的流程图给出本文坐标：原始文件先经过解析、清洗、切分和治理，再完成嵌入并形成混合索引。本文只讲第一步，止于 Published Hybrid Index（已发布混合索引）；后续的在线检索与回答生成只用于说明位置，将在后续文章展开。
图 1 RAG 全流程与本文边界
处理到这一步，文件本身还不是“可用知识”。接下来的 Parsing（解析）与 Cleaning（清洗），要把它恢复成既忠于原文、又方便后续处理的形态。
Parsing & Cleaning：恢复可用的文档结构
Parsing 负责识别文档中有什么，Cleaning 负责去掉干扰而不改变原意。它们的交付物不是一长串抽出的文字，而是 Normalized Document Tree（标准化文档树）：一种统一的中间表示，能够同时保留正文、标题层级、列表、表格、图片之间的关系，以及回到原文的位置。
这一区别决定了后续质量。PDF 的文字流未必保存表格单元格和行边界；扫描件即使识别出了文字，也可能把阅读顺序弄错。因此，Parsing 是否成功不能只看“是否抽到了文本”，还要逐项检查：[1][2][3]
处理路线应由“页面中的信息以什么形态存在”决定，而不是只看文件扩展名。常见能力各自解决不同问题：
一个 PDF 可能是可直接读取的正文，也可能是扫描件或复杂版面；同一个扩展名不能替代对页面形态的判断。
DOCX（文字处理文档）、XLSX/CSV（工作簿/逗号分隔值）、PPTX（演示文稿）和 HTML（网页文档）各自带有可利用的结构线索。其中 DOCX、XLSX 和 PPTX 属于 Office Open XML（开放式办公 XML）格式，其结构依据来自该格式标准；HTML 的文档结构和 CSV 的记录、字段结构分别有各自的标准依据。[4][5][6] 旧的 .doc、.xls、.ppt 不在 Office Open XML 的覆盖范围内，需要单独选择解析器并独立验收，不能沿用开放 XML 格式的结构假设。
下表按 Document Type（文档类型）列出常见内容的处理重点。它不是产品选型清单，而是验收时可以逐项判断的结构检查表。
| Document Type | 处理重点 | 必须保留的结构 | 常见失败 |
|---|---|---|---|
| 校正双栏等复杂页面的阅读顺序，并移除重复页眉和页脚。 | 页码、标题层级、表格边界、数值单位和原始阅读顺序。 | 左右两栏交错、页脚混入正文，或金额与单位分离。 | |
| DOCX | 区分正文、批注和修订内容，并识别重复模板区域。 | 标题层级、列表层级、表格关系和有效版本的正文。 | 条款层级被压平，或修订稿被误当成现行制度。 |
| HTML | 提取主内容，排除导航、广告和重复推荐区域。 | 页面标题、正文顺序、列表、链接文字与其指向关系。 | 菜单或推荐内容进入知识库，正文失去链接上下文。 |
| XLSX/CSV | XLSX 识别工作表、合并单元格、表头、数据行和单位；CSV 识别分隔规则、表头、数据行和单位。 | XLSX 保留工作表、合并关系及表头—数据行—单位关系；CSV 保留表头—数据行—单位关系。 | XLSX 的合并关系或空行造成错段；CSV 分隔错误会使表头、数据行或单位错位。 |
| PPTX | 按每页的主题聚合文字、图表和备注，并识别重复版式。 | 幻灯片标题、内容组、备注，以及图表或图片与说明文字的对应关系。 | 模板文字淹没正文，或图表脱离其解释文字。 |
| Image/Scan（图片/扫描件） | 纠正方向并识别文字块和页面区域，再核对识别质量。 | 原始页面、文字块位置、阅读顺序和图像区域。 | 倾斜导致漏识，文字块顺序错误，且低质量内容无法复核。 |
下面的路由图展示了按内容形态选择处理路线的过程：不同分支最后都汇合为同一个 Normalized Document Tree。
图 2 不同文档的解析路由
要让这棵树真正可用，团队至少应守住三条原则。
不同文档的回源位置示例包括：
Parsing 与 Cleaning 的目标不是抽取尽可能多的文字，而是恢复可被后续切片、检索和引用共同使用的文档结构。
Chunking：按语义单元切分
Chunking（切片）将文档组织为 Chunk（切片单元）；一个可用的 Chunk 不是按固定字符数裁出的文本，而是能够独立召回的证据单元：它保留判断问题所需的最小完整上下文，同时能沿标题层级或父级关系回到原文。制度中的条件、结论与例外，表格中的表头、单位与数据行，都不应因为长度计数而失去联系。
Token（词元）适合度量模型输入，却不是语义边界。切分时需要同时权衡三类影响：[7][8]
这些参数都不能替代对内容结构的判断。
下表比较六类 Strategy（策略）。它的作用不是给出唯一答案，而是说明不同切分起点的适用条件、优势和风险。
| Strategy | 如何切分 | 适合内容 | 优势 | 主要风险 |
|---|---|---|---|---|
| Fixed-size（固定长度切片） | 按统一长度切开，必要时保留相邻边缘。 | 句子较短、分布均匀且跨段依赖少的文本。 | 实现简单，吞吐和成本容易估算。 | 条件与结论可能恰好落在边界两侧。 |
| Recursive（递归切片） | 先按段落等较大边界切分，超出容量再逐级下钻到句子或词。 | 段落边界稳定、但缺少严格层级的通用文档。 | 在满足容量限制的同时，尽量保留较大的语义单元。 | 分隔符与真实结构不一致时，仍会误切。[7][8] |
| Structure-aware（结构感知切片） | 沿标题、章节、条款和版面块边界切分。 | 制度、手册、网页等结构明确的内容。 | 能保留标题路径和内容类型，便于回源。 | 上游结构识别错误会被继续放大。 |
| Semantic（语义切片） | 根据主题变化识别边界，将语义连续的句段合并。 | 访谈、纪要和连续叙事等弱结构文本。 | 不依赖固定分隔符，更容易保持主题连续。 | 边界受模型、语料分布和判断阈值影响，结果与成本更难预测。 |
| Parent-Child（父子切片） | 用较小的 Child 参与召回，命中后补充其所属 Parent。 | 条件、例外或解释分散在多个段落的长条款。 | 同时兼顾精细定位与较完整的判断上下文。 | 父子错配会带回错误原文，Parent 过大又会引入噪声。 |
| Block-specific（块类型专用切片） | 先识别表格、代码或列表，再按各自内部结构切分。 | 表头与数据行、函数签名与函数体、有引导语的列表。 | 可针对不同内容保护关键依赖，并与其他策略组合。 | 块类型识别错误，或跨块说明未被关联，都会造成上下文缺失。 |
图 3 Chunking 策略选择路径
图 3 给出的顺序可以作为策略选择的起点：
Fixed-size 更适合作为结构弱且内容均匀时的基线，而不是默认答案。
这棵决策树不会自动产生最佳参数。同一种制度文档，不同问题也可能需要不同粒度。例如：
最终选择必须回到真实语料与真实查询集，而不能只根据文档类型套规则。
切分失败往往在后续才暴露，常见表现包括：
Chunk Size 与 Overlap 没有跨语料通用答案。验证时应按顺序执行：
这样才能判断改善来自策略本身，还是来自样本变化。
Metadata：让 Chunk 可定位、可管理
Metadata（元数据）的价值，不是给 Chunk 贴上尽可能多的标签，而是让证据在进入索引后仍然知道自己从哪里来、位于哪里、谁可以使用，以及出现问题时如何追查。它连接的是检索命中与原始文档，也是发布、撤回和审计能够落地的基础。
Metadata 不是越多越好，只保存能被检索过滤、引用回源、权限治理、版本管理或问题排查实际消费的信息。
Embedding：把文本转换为可比较的表示
Embedding（嵌入）把 Chunk 转换为可比较的向量表示，让写法不同但含义相近的内容有机会靠近。模型选型不应从榜单名次直接跳到采购决定：MTEB（大规模文本嵌入基准）表明，没有一个模型能在所有评测项目上始终占优；C-MTEB（中文大规模文本嵌入基准）补充了中文场景的评测覆盖。两者适合缩小候选范围，不能代替企业自己的数据验证。[9][10]
真正的选择过程，可以依次回答四个问题。
选型完成也不是生命周期的终点，仍需关注三类并列风险：
因此，模型、语料、查询集和评测结果应共同版本化。每次升级都应隔离生成候选结果，重新跑同一套业务评测，并复盘新增与既有失败样本后再决定是否发布。
Embedding 选型的终点不是“找到榜单第一”，而是证明候选模型在自己的语言、术语、上下文和成本边界内可靠。
Hybrid Index：让不同类型的问题都有入口
只依赖一种检索信号，会把它不擅长的问题变成系统盲区。混合索引的价值，是让语义、原文字面和治理属性各自有合适的入口。这里讨论的是三类互补的逻辑检索信号或能力，不是必须分别建设三个物理索引：它们可以共存于一个物理索引，也可以按搜索产品的能力拆分。
以向量信号为例，下面两种写法没有复用原词，但语义接近：
在线 Retrieval 必须绑定当前请求者身份，根据这些属性执行 Fail-closed（默认拒绝）过滤：身份或权限条件缺失、无效或无法判定时，不让证据进入候选。本篇只说明 Data Indexing 应准备什么，不展开在线信号组合与授权实现。
Hybrid Index 的意义不是堆出三个物理索引，而是让三类逻辑检索能力各自承担擅长的问题。
Validation & Publishing：验证后再发布
Validation（验证）回答“候选结果是否合格”，Publishing（发布）回答“如何让线上稳定地使用合格版本”。两者必须连成一条质量链路，按四个动作执行。
这四个动作把“流水线跑完”与“可以发布”区分开来，并将发布变成可验证、可撤销的状态变化。候选版本未通过质量校验时不能进入线上；上一版尚未安全保留时，也不应贸然切换。
发布成功的标准不是处理流程没有报错，而是新索引通过质量校验、能够稳定切换，并且出现问题时可以回到上一良好版本。
结语与系列衔接
从原始文件到已发布混合索引，每一步都在决定后续检索究竟能看到什么：
如果上游出现以下任一问题，后续排序和生成都无法凭空还原已经消失的信息：
反过来，Data Indexing 做得扎实，检索阶段才有机会在正确边界内找到完整、可核验的证据。
Data Indexing 决定后续检索能看到什么；没有被保存下来的结构、语义和治理信息，在本文所述的在线检索与生成链路中无法可靠补回，需要返回 Data Indexing 修复并重建。
第二篇将从在线 Retrieval 开始，依次认识：
这里只先列出主题，具体实现留到下一篇展开。