在RAG中“语义被切割”通常是指一个完整事实、条件或逻辑关系被拆到不同Chunk里导致检索只找回其中一半。例如原文员工可以申请远程办公但必须满足以下条件 1. 入职满一年 2. 最近一次绩效为B及以上 3. 每周最多远程办公两天。如果切成Chunk 1员工可以申请远程办公。 Chunk 2入职满一年绩效为B及以上每周最多两天。模型只检索到Chunk 1时就可能错误回答“所有员工都能申请”。解决这个问题不能只靠调大Chunk而要结合结构化切分、重叠、父子检索和上下文扩展。一、 不要按固定字符数硬切最容易破坏语义的方式是每500个字符切一次它可能在句子、列表、表格甚至条件表达中间切开。更好的方式是按照以下优先级递归切分标题 ↓ 章节 ↓ 段落 ↓ 完整句子 ↓ 逗号或其他标点 ↓ 最后才按Token长度截断例如separators [ \n# , # 一级标题 \n## , # 二级标题 \n\n, # 段落 \n, # 换行 。, # 句子 , ]核心原则是优先保证语义完整再满足长度限制。长度最好按Token计算而不是按字符数因为模型的上下文限制是以Token计算的。二、 使用Chunk Overlap重叠窗口相邻Chunk之间保留一部分重复内容。例如原文A B C D E F G H Chunk 1A B C D E Chunk 2D E F G H其中D E就是重叠部分。常见起点可以设置为Chunk大小300800 tokens OverlapChunk大小的10%20%例如chunk_size 500 tokens chunk_overlap 80 tokens重叠适合解决一个句子刚好横跨边界代词指向上一段条件和结论距离较近上下段存在承接关系但Overlap不能解决所有问题。它设置得太大会导致数据重复检索结果高度相似上下文浪费向量库体积增大因此不要仅靠无限增加Overlap。三、使用语义切分语义切分不是按照长度切而是检测相邻句子的语义变化。例如句子1员工每月可以申请一次交通补贴。 句子2补贴上限为500元。 句子3申请必须在每月25日前提交。 句子4公司的招聘流程包括初试和复试。句子13都在讲交通补贴应放在同一个Chunk句子4开始讲招聘应从这里切开。基本过程是文档拆成句子 ↓ 计算相邻句子的Embedding相似度 ↓ 相似度明显下降的位置视为主题边界 ↓ 合并同一主题的连续句子语义切分比较适合长篇报告会议纪要新闻和研究材料没有清晰标题结构的文本但它的计算成本更高而且相似度阈值需要根据业务数据调试。四、 检索后自动扩展相邻Chunk检索到某个Chunk以后把它前后的Chunk一起取回来。例如检索到Chunk 8远程办公的申请条件系统同时返回Chunk 7远程办公适用范围 Chunk 8远程办公申请条件 Chunk 9远程办公审批流程伪代码retrieved search(query) for chunk in retrieved: context get_chunk(chunk.index - 1) context chunk context get_chunk(chunk.index 1)为了实现这一点每个Chunk需要保存{ document_id: employee_handbook, section_id: remote_work, chunk_index: 8, previous_chunk_id: 7, next_chunk_id: 9 }相邻扩展特别适合说明书、法规和连续叙述文档。但最好限制在同一个章节内避免把下一章的无关内容也带进来。五、使用父子Chunk这是实际RAG系统中非常有效的方法也叫“小块检索大块返回”。处理文档时建立两种Chunk父Chunk8002000 tokens保持完整章节语义 子Chunk100400 tokens用于精确检索例如父Chunk完整的“员工远程办公制度” ├─ 子Chunk 1申请资格 ├─ 子Chunk 2申请流程 ├─ 子Chunk 3办公天数限制 └─ 子Chunk 4违规处理查询时用户问题 ↓ 检索到“申请资格”子Chunk ↓ 根据parent_id找到完整父Chunk ↓ 把父Chunk交给大模型这样同时兼顾小Chunk检索精确大Chunk上下文完整如果直接使用大Chunk做向量检索其中会包含多个主题向量容易被无关内容稀释如果只使用小Chunk生成答案语义又可能不完整。父子Chunk正好解决这一矛盾。六、 给每个Chunk补充上下文有些Chunk单独拿出来后完全看不出它属于哪个主题。例如原始Chunk只有需要在三个工作日内完成审批。单独向量化时很难知道这是报销审批、请假审批还是采购审批。可以给它添加标题和章节路径文档《员工费用管理制度》 章节差旅报销 审批流程 正文 差旅报销需要在三个工作日内完成审批。Embedding时使用带上下文的内容但展示答案时可以只展示正文。建议保留的元数据包括文档标题 章节标题 父级标题 文档类型 产品型号 发布时间 适用部门 版本号这种方法通常称为上下文增强或Contextual Chunking。七、合并检索到的连续Chunk假设检索结果中出现Chunk 5 Chunk 6 Chunk 7 Chunk 12由于5、6、7是连续的可以先合并为一个完整上下文合并结果AChunk 57 结果BChunk 12合并时还可以消除Overlap产生的重复文本避免模型看到同一句话多次八、使用多粒度索引同一份文档可以建立多种粒度的索引文档摘要索引判断应该查哪份文档 章节索引判断应该查哪个章节 段落索引查找精确事实 句子索引查找编号、定义和具体数据查询流程可以是先定位文档 ↓ 再定位章节 ↓ 最后检索具体段落这比在所有零散Chunk中一次性搜索更容易保持文档结构九、推荐的实用组合对于普通企业制度、产品手册和技术文档可以从下面的配置开始1. 先按标题和章节解析文档 2. 在章节内按段落和句子递归切分 3. 子Chunk控制在300500 tokens 4. Overlap设置为50100 tokens 5. 保存标题、章节路径和版本信息 6. 建立父子Chunk关系 7. 使用子Chunk检索 8. 返回父Chunk或相邻Chunk 9. 对结果进行Rerank 10. 合并连续Chunk并删除重复内容简化架构如下文档 ↓ 按章节切分 父Chunk ↓ 按段落和句子切分 子Chunk ↓ 向量化和建立索引 用户问题 ↓ 检索子Chunk ↓ Rerank ↓ 获取父Chunk和相邻Chunk ↓ 合并、去重 ↓ 交给大模型回答最关键的原则不要试图找到一个适合所有文档的固定Chunk大小。真正有效的方案是结构决定边界小块负责检索大块负责理解标题补充上下文相邻片段负责恢复连续语义。最终还要准备一批真实问题进行评估重点检查正确片段是否被召回、条件和结论是否同时出现、表格和列表是否完整以及最终引用是否真正支持答案