RAG检索到的文档片段太碎，回答时总是断章取义，大家怎么处理chunk切分？

表格和条款类文档别硬切，按标题层级拆再给每段补上父级路径当上下文，召回准很多。

按标题层级切再合并小片段，表格单独抽出来处理，别硬切。

我之前也踩过这个坑，纯按字符数切PDF就是灾难。后来改成先按标题层级切大块，再在块内按语义或段落切，表格单独拎出来做结构化处理，效果好很多。512太小了，结构复杂的文档建议先解析出章节树再决定chunk边界。检索那块可以试试加个rerank，或者用parent-child的方式，召回小片段但喂给LLM的是父块，能缓解断章取义。

这个场景我太熟了，表格和条款混排的文档，纯按字符数切基本就是灾难。建议先按标题层级切，再在叶子节点里做二次切分，表格单独抽出来走结构化解析。语义切分可以试，但别指望它解决层级断裂的问题，得配合metadata过滤才能精准召回。检索那块也可以考虑混合检索加rerank，光靠调chunk_size是绕不出去的。

我之前也踩过一样的坑，RecursiveCharacterTextSplitter对表格和带层级的条款基本是灾难。后来换成按标题层级切，再用小模型对每个chunk做语义完整性判断，碎片的概率低了不少。报销这种流程类问题，其实可以额外建个结构化索引，把条件和结论绑在一起存，别全指望文本切分。你检索那步也可以试试加个rerank，光靠向量召回确实容易把不相关的条款拼一起。

按标题层级切再小块塞进大块里，表格单独走结构化解析，别硬拆。

这种结构化的文档直接上RecursiveCharacterTextSplitter确实容易翻车，它本质是按字符递归找分隔符，根本不理解标题层级和表格结构。我之前做类似项目时也踩过这个坑，后来改成先按文档的标题树做一级切分，把每个章节当成独立单元，再在章节内部做二次切分，效果明显好很多。表格的话建议单独抽出来做结构化处理，别硬塞进文本流里，不然切碎了LLM根本拼不回去。至于语义切分，听着美好但实际落地成本不低，embedding模型选不好反而更碎，而且对中文层级文档的边界识别也没那么准。chunk_size 512配50 overlap其实不算离谱，问题更可能出在切分逻辑没跟文档结构对齐。另外你可以试试在检索后加一层rerank，或者用parent-child的检索方式，召回小的精准片段但喂给LLM的是完整父块，这样既保召回又保上下文。单纯调大chunk_size治标不治本，噪声和幻觉只会换个形式出现。

我之前也踩过这个坑，512确实太碎了，表格和条款一断就开始胡说。后来我改成先按标题层级粗切，再用小chunk做检索，命中后把相邻片段一起喂给LLM，效果好了不少。语义切分可以试，但对PDF解析质量要求挺高，解析烂的话再语义也白搭。你们文档里的表格多吗？表格建议单独走结构化提取，别硬塞进文本chunk里。