RAG检索总返回不相关内容，有没有更好的分块策略推荐？

我之前也踩过这个坑，固定长度分块把标题和正文切散了，检索时自然抓不住关键上下文。你可以试试按markdown标题层级做递归分割，把父级标题拼到每个chunk前面，这样A产品和B产品的语义边界会清楚很多。表格的话建议单独抽出来做摘要再入库，硬切容易丢字段对应关系。另外检索阶段加个元数据过滤，比如按产品名先筛一遍，比纯靠向量召回靠谱。

这问题挺典型的，我前段时间也踩过坑。固定分块确实容易把不同产品的段落混在一起，后来改成按标题层级切，再把表格单独抽出来做摘要，效果好了不少。你可以试试先按markdown标题递归分，再对每个chunk加上所属标题路径作为元数据，检索时带上这个过滤条件。另外chunk_size别太小，容易丢上下文，我一般正文500到800，表格另处理。

我之前也踩过这个坑，固定字符切分确实容易把相关上下文切散。后来试了按标题层级做父子块，子块检索、父块喂给LLM，召回质量提升挺明显。PDF表格建议单独抽出来做结构化处理，别硬切，不然表格语义全乱了。另外可以加个rerank模型过滤一下，光靠向量相似度对“A产品”和“B产品”这种区分度不够。

试试按标题层级做父子块，检索用子块召回父块，表格单独走结构化解析。

这个问题我踩过类似的坑，感觉你遇到的未必是chunk_size的锅，更像是检索时把不同产品的语义混在一起了。固定字符和递归分割都只看长度，不看文档结构，A产品和B产品的段落被切进同一个chunk里，向量自然就糊了。我后来改成先按标题层级切，把每个多级标题当成一个父块，再在父块内部按语义做子块，检索时用父子关联召回，效果明显好不少。表格的话建议单独处理，别硬塞进文本流里，可以用LLM把表格转成带字段说明的自然语言描述，否则行列语义全丢了。另外一个容易被忽略的点是metadata，给每个chunk打上产品名、文档类型这些标签，检索时先做过滤再做向量匹配，能挡掉一大半跨产品的误召回。你现在的embedding模型是通用的还是针对中文领域微调过的？这个对精度影响也挺大的。

可以试试按标题层级做父子块，检索用子块但返回父块，结构化PDF会友好很多。

我们之前也踩过这个坑，固定字符切分基本没法保留语义边界。后来换成按标题层级切，再对超长段落做二次分割，召回明显好多了。PDF表格建议单独抽出来走结构化解析，别硬塞进文本块里。另外可以加个metadata过滤，把产品名写进chunk的标签，检索时先筛再排。

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。