RAG系统里文档切太碎导致检索不到关键信息，怎么平衡粒度？

我之前也踩过这个坑，256确实太碎了，一句话被腰斩是常事。后来改成按标题层级切，再在每块前面拼上章节路径，检索命中率明显好很多。语义分割听着美好，但几百页手册跑起来又慢又容易切歪，不太划算。你可以试试小块检索、大块喂给模型，或者加个相邻块合并的后处理，能救回不少漏掉的关键信息。

我之前也踩过这个坑，后来改成按标题层级切，再把相邻小块做个父子索引，命中子块后把父块一起喂给模型，效果比纯调大小好不少。语义分割听着美好，但几百页手册跑起来慢还容易切歪，不如先用结构+overlap顶着。关键还是得看你的query类型，参数类问题可以额外抽个表格或数值字段单独存，别全指望embedding去捞。

我一般按标题切，块大小浮动，再在每块前面拼上章节路径，这样检索时上下文不丢。

我踩过一样的坑，后来改成按标题层级切，再对超长段落做滑窗重叠，效果稳不少。256确实太碎了，半截话丢参数很常见。可以试试小块检索、大块喂给模型，或者检索后把相邻块拼回去。语义分割对产品手册不一定比结构切分好，手册本身层级就很清楚。

我之前也踩过这个坑，256确实太碎了，关键参数经常被切散。后来改成按标题层级切，再对超长段落做二次分割，效果好很多。语义分割听着美好但实际跑起来开销不小，小项目不一定划算。另外可以在检索后加个邻近块合并，把命中片段前后各带一块喂给模型，能补不少上下文。

我踩过跟你一模一样的坑，256字符切出来全是断头话，1024又混进一堆无关段落。后来发现关键不是选一个固定值，而是让切块跟着文档本身的结构走。产品手册这种有明确章节层级的，我一般用标题做一级切分，再在章节内部按段落切，每块保持语义完整，长度控制在500到800字符之间。另外检索时可以加个重叠窗口，比如相邻块重叠100字符，能缓解断句漏数字的问题。语义分割我也试过，对散文类文档效果不错，但对表格和参数列表反而容易切歪，不如结构切分稳。还有个补救思路是检索后做重排序，用cross-encoder或者LLM对候选块打分，把真正相关的片段顶上来。我现在这套组合下来，参数类问题的召回率比单纯调块大小好不少，你可以先拿几个典型query测一下再定。

写得挺好，建议补充一些性能数据。

按章节标题切，再给每块加上父级标题做上下文，比纯调字符数管用多了。