本文属于 RAG 工程框架中的「1 数据接入与文档切分」环节,聚焦「Chunking centric RAG」方法。可先阅读 RAG-00.方法概述 再进入本篇。
原理
优先优化“文档如何切块”,再做索引与检索。
1 | flowchart LR |
优缺。
- 优点:低成本提升召回相关性;对所有 RAG 都有效。
- 缺点:需要领域样本反复试验。
性能/资源
- 离线迭代成本中等。
- 在线几乎无额外成本。
应用场景
- 文档结构稳定(规章、SOP、技术文档)体系。
- 作为 RAG 质量优化第一步。
统一合成数据示例
输入数据片段
1 | { |
中间结果(不同切分策略对比 + 离线指标)
1 | [ |
要点:短窗口把「上限」与「30 天」拆进不同块,多约束问句容易只命中一半;带 overlap 的较大窗口更贴合「切分-centric」要优化的对象——语义完整性与召回边界的折中。
最终输出示例(给下游索引)
1 | { |
原始发表与工程实现
- 代表性原始发表:TextTiling (Hearst, 1997)。
- 核心解决问题:解决文档切分边界与语义完整性冲突。
- 成熟实现工具:langchain-text-splitters, llama-index, unstructured。
详细原理拆解
- chunk_size 与 overlap 联合优化,目标是最大化 recall@k 并控制 token 成本。
- 典型实现可拆为:输入预处理 -> 方法核心计算 -> 候选/证据构建 -> 生成与引用。
- 工程调优重点:质量(准确率/引用率)与成本(时延/token)的联合优化。
1 | flowchart LR |
工程落地扩展示例
伪代码
1 | def chunking_centric_build(docs, strategies, eval_queries, embedder): |
参数示例
1 | chunk_strategies: |
常见失败案例
- 失败模式 1:只在单一查询上肉眼看切块,未用离线 recall@k,上线后复杂问句仍漏约束。
- 失败模式 2:overlap 过大导致块近乎重复,索引膨胀、检索变慢,收益不成正比。
- 失败模式 3:切分与领域强相关(表格/条款),一套参数打全部文档,子语料质量差。
Demo 数据带入计算示例
1 | 评测问句 q:「报销最晚提交时间?」需同时命中「30 天」约束。 |