用开源模型搭RAG，召回效果差得离谱，是chunk切分问题还是embedding选错了？

先别急着换模型，查查是不是纯向量检索把关键词漏了，试试混合检索加BM25。

几百页的技术手册，chunk设512其实有点大，容易把关键段落和无关内容混在一起，试试256加10%重叠。你这两个问法召回差异大，本质是bge-large对口语化改写不敏感，换bge-m3会好一些但别指望根治。建议先加个轻量query改写，把用户问法往文档里的术语靠，比如“超时时间”改成“timeout配置”，比调chunk见效快。HyDE对技术文档效果一般，容易引入幻觉，先别折腾那个。

我之前也踩过类似的坑，bge-large-zh对同义问法的鲁棒性确实一般，换成bge-m3后召回明显稳一些，尤其是你这种技术手册场景。不过先别急着换模型，建议拿几个bad case看看召回的chunk里到底有没有正确答案，如果有但排后面，那问题在排序不在embedding。query改写和HyDE值得试，成本不高，但更省事的做法是先加个BM25做混合检索，关键词匹配能兜住不少语义漂移的情况。

你这个问题太典型了，我搭RAG也踩过一模一样的坑。其实你提到的两种问法召回差异大，核心原因大概率不在embedding本身，而是query和文档段落之间的语义鸿沟——用户口语化提问和手册里那种“设置timeout参数”的书面表述天然就对不齐。bge-large-zh其实不算弱，换bge-m3提升有限，除非你确实需要多语言或者长文本场景。我建议你先别急着换模型，花半天时间把检索链路拆开看：拿几个bad case，把query和top10召回的段落都打印出来，一眼就能看出来是没召到还是召到了排后面。如果关键段落压根没进top50，那基本就是embedding或chunk的问题；如果进了但排后面，那就是排序或query改写能救的。HyDE对技术手册这种场景确实有用，但成本是你每问一次要多跑一次生成，延迟翻倍，看你能不能接受。另外chunk 512对API文档可能偏大，试试按标题层级切，或者用small-to-big那套思路，检索用小块，喂给LLM用大块。调RAG确实烦，但别每个环节都动，先定位瓶颈再改，不然调完一圈你都不知道是哪个起了作用。

你这个问题大概率不是chunk的锅，512配50重叠对技术文档来说挺合理了。bge-large-zh对同义改写确实不太稳，“设置超时”和“请求超时”在向量空间里可能隔得挺远，换bge-m3会好一些但别指望质变。建议先别急着上HyDE，花十分钟加个BM25混合检索试试，关键词匹配能兜住不少这种case。如果混合完还是不行，再考虑query改写，那个调起来其实比换模型省事。

你这两个问法其实语义很近，bge-large对同义改写确实不太稳，换成bge-m3会好一些，但别指望换个模型就解决所有问题。我建议先加一层query改写或者用HyDE生成假设答案再检索，对技术文档场景提升挺明显的，成本也不高。另外你chunk 512在API文档上可能偏大，试试按标题层级切或者压到256，召回精度会好不少。别每个环节都瞎调，先把检索链路固定住，再单独换embedding对比着看。

我遇到过一模一样的问题，bge-large换成m3提升有限，后来发现是纯向量检索对同义改写的鲁棒性不够。你可以先加个BM25做混合检索试试，成本很低但效果立竿见影。query改写和HyDE确实有用，但优先级排在混合检索后面。另外几百页文档可以考虑加个rerank模型精排，比折腾chunk实在多了。

你这情况八成是检索策略的问题，不是embedding不行。bge-large-zh在中文技术文档上其实够用了，换bge-m3提升有限。你试试加个BM25做混合检索，关键词匹配能兜住“超时时间”这种术语，再配合RRF重排，效果立竿见影。query改写和HyDE确实有用但成本高，先别急着上，把检索层调好再说。