RAG 的ingestion 和chunking 是什么，什么地方容易出错？

RAG 里 ingestion 和 chunking 是检索质量的地基——大部分线上「检索不准」的问题其实都是在这两步埋下的，而不是 embedding 模型或 LLM 的锅。

Ingestion（数据摄入）
指把原始文档变成可检索单元之前的一整条流水线，大致是：
加载 → 解析/提取 → 清洗 → 分块 → 向量化 → 写入索引（带 metadata）

核心是「解析/提取」：从 PDF、HTML、docx、Markdown、网页等异构格式里把正文和结构抽出来。这一步是脏活，也是最容易出问题的地方。

Chunking（分块）
把长文档切成更小的检索单元。常见策略从粗到细：

• 定长切分（按 token/字符 + overlap）——最简单，也最容易切坏语义
• 递归分隔符切分（先按段落，再按句子逐级 fallback）——LangChain 默认那套
• 结构感知切分（按标题层级、Markdown 结构、代码 AST）
• 语义切分（用 embedding 相似度找自然边界）
• 命题/句子级切分（proposition-based）

容易出错的地方
解析阶段

• PDF 是重灾区：多栏排版会被读成串行乱序；表格塌成一坨没有行列关系；页眉页脚每页重复污染正文；扫描件走 OCR 又引入错字。这类错误很隐蔽，因为文本「看起来」抽出来了，实际语义已经乱了。
• 丢结构：标题层级、列表、表格的从属关系被拍平成纯文本，后面无论怎么切都补不回来。
• boilerplate 污染：导航栏、footer、cookie 提示混进 chunk，稀释语义信号。
• 编码 / 去重没做：同一份文档多版本、模板化重复内容会让检索反复命中噪声。

分块阶段

• 块太大：一个 chunk 里混了多个主题，向量是「平均语义」，precision 掉得很快，还浪费上下文窗口。
• 块太小：句子被孤立，丢掉了理解它所必需的上下文。
• 边界切在错的地方：句子中间、表格和表头之间、代码和它的函数签名之间被切开。表格尤其致命——表头和数据行分家后两边都没用了。
• overlap 设置不当：完全没有 overlap 会在边界丢信息；overlap 太大又制造冗余、放大重复命中。
• 指代丢失（lost context 问题）：这是最典型的坑。某个 chunk 写着「它同比增长了 20%」，但「它」指的是什么、在什么时间段，定义在三个 chunk 之前——单独检索到这块等于没用。
• 一刀切：对散文、表格、代码用同一套切分策略。异构内容需要异构策略。

向量化 / 索引阶段

• chunk 长度和 embedding 模型的最优输入长度不匹配（很多模型超过某个长度语义就糊了）。
• query 的粒度和 chunk 的粒度不对齐——用户问的是细节，chunk 却是大段综述。
• metadata（来源、页码、时间、章节）没存，后续没法做过滤和溯源。

几个能明显缓解的做法

• Contextual Retrieval：给每个 chunk 前面拼一句用 LLM 生成的「这段在整篇文档里的上下文」，直接治指代丢失问题，对召回提升很明显。
• Small-to-big / parent-document retrieval：用小 chunk 检索、返回时带上它的父段落，兼顾 precision 和上下文完整。
• 结构感知 + 内容分类型切分：表格、代码、散文分别处理。
• metadata enrichment：切分时保留并附加结构化信息，供过滤和 rerank。
• 建评测集：ingestion/chunking 的改动一定要有一套 retrieval 评测（recall@k、命中率）来量化，否则全凭感觉调参。

求加米 🙏