RAG 长文档怎么切块?

回答与解析

核心切块策略对比

关键工程实践

重叠策略（Overlap）

• 比较零重叠、短窗口与较长窗口，用同一评测集确认是否改善边界上下文断裂
• 对QA类任务尤为重要，答案常跨块边界

多粒度设计（Parent-Child）

• 较小块用于精准检索（具体长度作为候选变量）
• 较大块用于生成上下文（具体长度受模型窗口与证据完整性约束）
• 通过元数据关联，兼顾召回与理解

动态切块

• 结合LLM判断语义完整性（成本较高）
• 或用聚类算法（如BERTopic）发现自然主题边界

选型建议

• 延迟敏感：把固定长度与低冗余候选纳入评测
• 精度敏感：比较语义切块、结构切块与多粒度方案
• 结构化文档：优先保留标题层级，块内自包含

最终需通过检索召回率和端到端答案质量联合评估，无绝对最优。

学习建议

建议系统学习该知识点

口语版讲法(约4分钟)

• 一句话定位：本质是检索粒度和语义完整性之间的权衡
• 先讲最直接的方法和它的边界
• 再讲语义切分和它的前提
• 最后讲混合策略和落地风险
• 收尾给出工程师姿态的取舍并给出可延伸点

这道题其实问的是在RAG系统里，怎么平衡检索粒度和语义完整性。说白了，你要找的信息有可能散落在文档的不同位置，切太碎可能让关键上下文断裂，切太大又可能把噪声带进来。我从最直接的方法说起吧。

最粗暴的当然是固定长度切块，按token或者字符数硬切。这个方案的好处是简单、可预测，处理日志或者流式数据这种没有强语义结构的场景很合适。但它的致命伤是语义断裂，比如一个完整的段落被拦腰切断，重要的结论前半段在一个块，后半段在另一个块，检索时很容易丢信息。所以它的边界很清楚：只适合内容本身没有强依赖关系的场景，比如错误日志、时间序列数据。

那对于论文、报告、企业SOP这类有完整语义的文档，就得按语义边界来切。按句子、段落，甚至按标题和章节来切。这样切出来的块内部语义自包含，检索精准度高。但这里有个前提：文档结构要清晰。如果是一份没有标题、没有分段、格式混乱的OCR扫描件，语义切分效果会大打折扣。而且块大小不均匀，对后续的Embedding和检索延迟有影响。

所以真正落地的时候，我倾向于把两者结合起来。一个很实用的做法是多粒度设计，也叫Parent-Child结构。较小块负责精准命中，较大父块负责补回生成上下文；两者的具体长度都作为候选变量，由文档结构、模型窗口和同一评测集决定。通过元数据把小块和大块关联起来，这样既保证了召回率，又给了模型足够的上下文。举个例子，在客服退款场景里，用户问‘我的订单退款为什么还没到账’，小块可能只切到‘退款到账时间为3-5个工作日’这一句，但大块会包含完整的退款政策段落，包括申请条件、审核流程和例外情况，这样模型生成的回答才完整。

这里有个常见的失败场景：如果文档本身是高度嵌套的，比如法律合同或者技术手册，纯按段落切可能把跨节的逻辑拆散。我的处理方式是结构化感知切块，优先按标题层级切，保证每个块在逻辑上是自包含的。比如一份产品说明书，按‘第一章-第一节-1.1’这样的层级切，每个块内部不依赖其他块的信息。

另外，重叠策略也很关键。我会比较零重叠、短窗口与较长窗口，验证共享边界内容是否真的补回了跨块证据。这对QA类任务特别重要，因为答案经常跨块边界。

不过，我最近在思考一个问题：切块策略到底能不能动态化？比如让LLM自己判断语义完整性，或者用聚类算法发现自然主题边界。但这样成本会上升，而且实时性可能跟不上。所以我会把语义切块、多粒度、固定长度和不同重叠窗口放进同一组候选，再按精度、延迟与成本选择。没有绝对最优的方案，最终还是要通过检索召回率和端到端答案质量来联合评估。

总的来说，我会把切块策略看成是RAG系统里一个需要反复调优的环节，而不是一劳永逸的决定。

关键一句:切块策略能否动态化，比如让LLM或聚类算法自动判断语义边界。

面试官还可能这样问

1. 问法 1 · 场景切入

   我看你做过知识库问答。假设用户上传了一本几百页的技术手册，我们要用它来回答各种细节问题。你会怎么把这本书切成一段段，既保证检索能命中，又让生成器能看懂上下文？

2. 问法 2 · 层层追问

   RAG 里文档切分你一般怎么做？……如果按固定长度切，有什么坑？……那怎么避免句子被切碎？……有没有办法既保留小粒度又给大上下文？……你觉得哪种策略最实用？

3. 问法 3 · 直球架构

   设计一个 RAG 系统的文本切块模块，要支持固定长度、语义边界、递归分层三种策略，并且能配置重叠比例。你怎么设计接口和策略选择逻辑？各自适合什么场景？