RAG 的文档处理流程是怎样的？
这道题考的是 RAG 文档处理管线的完整理解。你不光要会调库，更要能讲清楚从原始文档到可检索向量这整条链路是怎么设计的、每个环节在干什么、为什么这么干。
我从四个方面来讲：
- 六步管线：文档处理的完整流程
- Chunking 策略：怎么切、切多大、为什么这么切
- 语义丢失问题：切分带来的典型坑和解决方案
- 生产级校验：怎么保证处理质量
一、文档处理的六步管线
RAG 的文档处理分六步，像一条流水线：
上传 → 解析 → 清洗 → 切分 → Metadata → 入库
1. 上传与校验
第一步很简单但不能省。上传文件时要校验格式、大小、完整性。PDF 损坏、图片格式不识别这些问题要在这里拦掉。
2. Layout 解析
这是最关键的一步。把 PDF/Word 这些非结构化文档转成机器能读的内容。PDF 尤其麻烦，文字可能横着排、竖着排，表格、标题、脚注混在一起。
现在主流方案是用专门的解析库，比如国内有庖丁解析、unstructured 这些开源工具。复杂文档可能还要上 OCR。
3. 清洗去噪
解析出来的内容有很多"脏东西"：页眉页脚、重复的页码、公式转成的乱码、空行空格。
这一步要把这些噪音去掉，同时保留核心内容。留噪音进去，切分之后更难处理。
4. 切分（Chunking）
把长文档切成小块。这是整个管线里最影响检索效果的环节，后面会单独讲。
5. Metadata 提取
给每个 chunk 打标签。常见的有：
- 文档标题、作者、日期
- 章节结构（属于第几章、第几节）
- 原文位置（页码、段落号）
- 文件类型、来源
这些 metadata 干嘛用？检索的时候不光能召回内容，还能按权限、按类型、按时间过滤。 比如员工只能查自己部门的文档，就靠这个过滤。
6. 向量化入库
切好的 chunk 进 embedding 模型，生成向量，存进向量数据库。FAISS、Milvus、Pinecone、Chroma 都行，选型看规模和运维能力。
二、Chunking 策略怎么选
这块是高频考点。你得能讲清楚怎么切、切多大、为什么这么选。
固定长度切分 vs 递归字符切分
固定长度切，就是按 Token 数硬切。比如每 512 Token 一切，不管在哪断句。
问题很明显：一句话可能被拦腰斩断，"北京是中国的首都" 切成 "北京是" 和 "中国的首都"。检索的时候召回的片段缺胳膊少腿，大模型看了也懵。
递归字符切分更聪明。它会顺着文档的结构来切：先按段落，段落太长就按句子，句子还长就按逗号、按空格。像顺着纹理切西瓜，而不是横着乱砍。
主流方案基本都用递归字符切分。LangChain、LlamaIndex 都内置了这个方法。
切多大？
有个经验值：
- 通用文本：400-512 Token
- 代码：100 Token 左右
为什么这么分？
512 Token 是因为大多数 embedding 模型训练时用的上下文就是这个长度左右。切太大，单个 chunk 的语义太杂；切太小，上下文窗口装不下足够的背景信息。
代码切更小是因为代码逻辑紧凑，一行函数调用可能就包含完整语义，切大了反而引入无关代码。
重叠切分
相邻 chunk 之间要有重叠，一般 15-20%。
原因很简单：假设有一句话跨在两个 chunk 中间，只召回其中一个就漏了关键信息。加个重叠兜底，能把被截断的语义补回来。
语义切分
更高级的方案是用模型来判断哪里该切。比如 TextChunker、nltk 的 sentence splitter，会分析语义完整性再切。
好处是切出来的 chunk 语义更完整。坏处是要多调一次模型，成本高、延迟大。
现实工程里，递归字符切分 + 重叠基本够用。 语义切分适合对精度要求极高的场景。
三、语义丢失问题与应对
切分最大的坑是什么？把完整的语义切成碎片。
三大典型问题
1. 边界截断
表格被切成两半，前半截是表头，后半截是数据。大模型看了前不着村后不着店。
政策文件尤其容易出这个问题。比如"……符合条件的，可以申请……（续上）……以下补贴"，断章取义就理解反了。
2. 表格结构崩塌
Excel 转 Markdown 表格经常对不齐，或者表格被解析成一团乱文本。这种 chunk 检索到了也没用。
3. 专有名词被截断
"自然语言处理" 被切成 "自然语言" 和 "处理"，检索 "NLP" 可能就匹配不上了。
Parent-Child Chunk 方案
解决这个问题的主流方案是双层结构：
- Parent Chunk：大块原始文档，比如一整页或一整段
- Child Chunk：从 Parent 里切出来的小块，用于实际检索
检索先用 Child Chunk 召回，召回之后关联到 Parent Chunk，把完整的上下文一起喂给大模型。
好处：检索粒度细，生成时上下文完整。
代价：存储和检索逻辑都更复杂。
表格专项处理
表格被截断是个老大难问题。几个思路：
- 表格单独做结构化存储，不做切分
- 用 OCR + 表格识别模型专门处理
- 把表格转成 "题目 | 答案" 这样的问答对存储
四、生产级校验与降级策略
面试官有时候会追问：如果某个环节处理失败了怎么办？
核心原则：不要让单点故障导致整个流程挂掉。
每个环节都要有校验点
解析完了检查一下内容是不是空的，清洗完了看看有没有丢太多字，切完了确认 chunk 数量有没有异常。
校验通过才往下走，不通过就走降级。
逐级降级，不是直接失败
打个比方：考试打分时，作文跑题了给个辛苦分，格式错了扣一分，不会直接判零分。
文档处理也一样：
Layout 解析失败 → 降级到 OCR
OCR 也失败 → 降级到纯文本提取
纯文本也拿不到 → 标记为处理失败，留人工处理
表格解析失败 → 降级为普通文本块
Metadata 提取失败 → 用文件名、时间戳等默认值
目的：让系统尽可能吐出有用的结果，而不是直接挂掉。
监控与告警
生产环境要监控每个环节的失败率。如果某天 PDF 解析失败率突然从 1% 飙到 20%，说明解析服务出问题了，要赶紧查。
面试怎么答
基础版（能过的回答）
RAG 的文档处理分六步：上传校验、Layout 解析、清洗去噪、Chunking 切分、Metadata 提取、向量化入库。Chunking 环节一般用递归字符切分，通用文本控制在 400-512 Token，代码 100 Token 左右，相邻 chunk 加 15-20% 的重叠。切分容易出现边界截断和表格结构崩塌的问题，主流方案是用 Parent-Child Chunk 双层结构来平衡召回精度和上下文完整性。
这个回答把核心流程讲清楚了，能过。
加分版（让面试官眼前一亮）
文档处理六步管线里，最关键的是 Layout 解析和 Chunking。Layout 解析决定内容能不能完整提取，Chunking 决定检索效果的上限。通用文本用递归字符切分，400-512 Token，主要是因为这个粒度在语义完整性和上下文覆盖之间平衡最好。代码切更小是因为语义密度高，切大了引入噪音。
切分最大的坑是语义丢失——表格被截断、专有名词被断开、因果关系跨 chunk。Parent-Child Chunk 是目前最通用的解法，用细粒度 Child 做召回，用粗粒度 Parent 提供完整上下文。表格这块如果有条件可以单独做结构化存储，效果更好。
最后强调一点：数据处理管线质量比换 embedding 模型提升更明显。 很多团队花了大力气调 embedding，其实先把 Chunking 策略优化好，效果立竿见影。
加分的点在于：
- 能解释策略背后的原因
- 能说出 Parent-Child Chunk 的机制
- 能点出"数据质量比模型重要"这个工程经验
一句话总结
RAG 文档处理的核心是六步管线 + 精细 Chunking，要靠重叠切分和 Parent-Child 结构解决语义丢失问题，同时每个环节做好校验和降级，保证系统韧性。