RAG 长文档怎么切块?

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

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

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

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

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

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

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

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