RAG 文档处理与切分策略
1. 大白话：这是什么？解决什么痛点？
RAG 的文档处理与切分，就是把 PDF、Word、网页、表格、FAQ 这些原始资料，先解析、清洗、补元数据，再切成适合向量化和召回的小知识块。它本质上是 RAG 的“地基工程”：不是把文档丢进向量库就结束，而是要保证进入索引的内容本身是干净、完整、可追溯、可过滤的。
面试里我会先强调一个判断：很多 RAG 答不好，不是大模型不行，也不是向量数据库不高级，而是“垃圾进，垃圾出”。比如 PDF 多栏解析顺序错了，表格字段关系被拆散了，页眉页脚被当正文入库了，或者 Chunk 把“适用条件”和“处理结论”切成两半。后面即使用更好的 Embedding、更大的 Top-K、更强的 LLM，也只是把错误内容更稳定地表达出来。
所以文档处理要解决的核心痛点是三件事：第一，保住原文结构，不让标题、表格、列表、页码、章节路径丢失；第二，控制切块粒度，让检索既能命中精准片段，又不丢上下文；第三，通过 Metadata 保证权限过滤、版本过滤和答案溯源，不让 RAG 变成一个只会模糊匹配的黑盒。
2. 底层机制与高频考点
一条比较完整的 RAG 入库链路通常是：文件上传与格式校验 -> Layout-Aware 解析 -> 清洗去噪 -> 结构化增强 -> Chunking -> Embedding -> 向量库和元数据入库 -> 采样评估。这里最容易被问到的是解析、切分、元数据和失败排查。
文档清洗不是简单 trim 文本，而是要去掉 HTML 标签、乱码、重复空行、目录残留、页眉页脚、无意义水印等噪声。结构化解析则要按文档类型处理：Markdown / HTML 优先保留标题层级和列表，PDF 要关注阅读顺序、页码、表格和图片说明，Word 要读取标题样式重建文档树，表格型材料要尽量转成 Markdown 表格或行记录。普通纯文本解析遇到多栏 PDF、合并单元格、扫描件 OCR 时很容易结构错位，生产上最好用版式感知解析器，并对高价值文档做抽样校验。
Metadata 是面试高频点。每个 Chunk 至少应该带 source_id、source_type、title、section_path、page、created_at、updated_at、tenant_id、acl、business_tags 等字段。它不是给后台展示用的，而是检索硬约束和证据链。权限过滤尤其要注意：不能先向量召回 Top-K 再过滤权限，因为 Top-K 里如果大部分无权限，过滤后就会召回不足，甚至出现越权风险。更稳的做法是先用 Metadata 做预过滤，再进入向量检索或混合检索。
Chunk Size 和 Chunk Overlap 没有万能值。块太小，召回可能很准，但模型看到的是残缺上下文，容易断章取义；块太大，上下文更完整，但会混入无关内容，向量相似度被稀释，生成阶段信噪比下降。一般可以把 400-800 tokens 作为技术文档起点，FAQ 或短政策可以更小，法规合同优先按条、款、项切，代码文档优先按包、类、函数、注释块切。Overlap 是解决边界截断的手段，但也不是越大越好，过大会增加重复索引和召回噪声；通用文本可以从 50-100 tokens 重叠开始调。
切分策略要按文档形态选。固定长度切分实现简单、适合快速验证，但不懂段落和表格。递归切分会按章节、段落、句子、空格逐层拆，适合结构不规则但文本连续的技术文档。按标题、段落、页面切分更适合天然有结构的 Markdown、HTML、法律条款、产品手册。语义切分会用 Embedding 判断句子相似度，把意思相近的内容聚在一起，但成本高，且容易产生几十 token 的超小块，必须设置 min_chunk_size。父子切块是很重要的工程折中：用小子块做向量召回，提高命中精度；命中后把对应父块放进上下文，提高回答完整性。它的代价是索引和关联查询更复杂，但对长文档、政策解读、故障手册非常有价值。
失败场景可以按链路排查：如果答案完全不相关，先看解析是否乱序、噪声是否入库；如果召回到了相似但不能回答的片段，看 Chunk 是否切断了条件和结论；如果模型答得没证据，看 Metadata 是否缺页码、章节路径和来源；如果多租户场景召回不足，看是否做了召回后权限过滤；如果表格类问题错得离谱，看表格是否被拍平成失去字段关系的普通文本。
3. 🎯 实战口径
如果面试官问我“你做 RAG 时文档怎么切”，我不会只回答 chunkSize=512, overlap=100。我会说我会先把它当成一条离线索引管线来设计：先根据文档类型做解析和清洗，保留标题层级、页码、章节路径、业务标签、权限字段，再根据查询场景选择切分策略。FAQ 和短政策可以切小一点，技术方案和教程文档用递归或标题切分，表格和合同不能按 token 硬切，要保住字段关系和条款完整性。
在我的 [[苍穹外卖AI客服]] 里，RAG 检索不是孤立模块，而是在 Spring AI Advisor 链里和意图识别、用户上下文、对话记忆、工具过滤一起工作。像售后规则、退款政策、配送说明这类知识，如果 Chunk 把“退款条件”和“不可退款例外”切开，客服 Agent 就可能给出有风险的承诺。因此我会在入库时把 section_path、业务类型、门店/租户、版本和来源页码写进 Metadata，在线检索时先按租户、业务标签和版本做预过滤，再做向量召回和重排，最后把带来源的上下文交给大模型。
我会优先采用“结构切分 + 递归兜底 + 父子切块”的组合：子块用于精准召回，父块用于补足上下文；对高频 FAQ 还可以生成问题变体或摘要一起入索引，提升“用户口语问法”和“文档正式写法”之间的匹配率。上线后如果发现 RAG 答错，我会沿着“解析质量 -> Chunk 边界 -> Metadata 过滤 -> 候选召回 -> 重排 -> 上下文组装”逐层排查，而不是一上来就换 Embedding 模型或盲目调大 Top-K。
相关链接：[[苍穹外卖AI客服]]