RAG系统里文档切块后语义割裂严重，有什么优雅的解决方案吗？

试试用小模型先做语义段落识别再切块，比固定大小靠谱多了，召回质量能上去不少。

我们之前也踩过这坑，后来加了句级重叠窗口，配合标题层级切分，长文档推理稳多了。

我之前也踩过这个坑，固定大小切分是真的粗暴。后来我试了按标题和段落结构去切，再配合一个滑动窗口做重叠，效果好了不少，至少上下文连贯性上来了。不过多轮对话那种长依赖还是难搞，想问下你有没有试过在切块时保留一些元数据（比如页码、层级），召回后直接喂给LLM做二次总结？感觉比单纯拼原始块更靠谱一点。

我之前也踩过这个坑，固定切块真的挺反人类的。后来试了按标题和段落结构递归切，再配合一个滑动窗口重叠区，召回完整度明显好了不少，你可以试试看。

另外我觉得可以加个“父子块”策略，检索用小块，喂给LLM的时候把父块拼回去，这样语义连贯性和检索精度都能兼顾。你们现在有做query改写吗？多轮对话里把指代消解掉再检索，割裂感会轻很多。

这个坑我太懂了，固定chunk_size基本就是赌运气。我现在用语义分割先划出完整段落，再按段落边界动态切块，召回率能提不少。另外你可以试试给每个chunk加个“上下文摘要”字段，检索时把摘要和正文拼一起，能缓解不少割裂问题。

不过说实话，多轮对话场景光靠切块优化不够，还得在检索后加个相关性重判逻辑，不然容易把历史轮次里的干扰信息也带进来。你们现在用的是哪种embedding模型？有些模型对长文本的语义捕捉能力差异挺大的。

试试加一层父子分块，父块保留完整语义，子块做检索命中后再映射回去，效果立竿见影。

试试滑动窗口+父文档召回吧，切块时留点重叠，检索命中后直接拿整段原文喂给LLM，效果立竿见影。

我们之前也踩过这坑，后来改成按章节切块，再配合摘要索引，长文档推理稳多了。

这问题太真实了，我之前搞合同审查的RAG也差点被切块逼疯。后来试了几个土办法，感觉最管用的是“递归切分+重叠窗口”，就是按标题、段落这些自然边界先粗切，再对每个块做带overlap的细切，虽然存储会涨个20%左右，但召回质量肉眼可见地提升。另外你提到长文档推理，我怀疑光靠切块优化不够，得配合一个“段落级索引”的结构，比如先把文档按章节建树，向量只存叶子节点，检索时用父节点做上下文补全，这样即使某段被切断，也能把相邻章节的语义拉回来。还有个歪招是让LLM自己判断，比如检索阶段多召回几块，用prompt让模型挑出和问题相关的连续片段再拼接，虽然费点token，但比硬切强。不过说真的，多轮对话场景我会倾向先把历史对话摘要成独立文本块，跟文档块分开存，不然切块问题会被对话噪声放大。你现在是纯靠向量召回还是加了重排？如果重排模型没针对切块调过，建议试试用交叉编码器对“问题+相邻块拼接”打分，效果比单块得分靠谱很多。