RAG检索质量差：Embedding与Rerank调优

这道题其实是在问，当[[RAG]]的检索环节掉链子时，怎么系统性地定位和修复。我一般先定位失效环节，是召回不够、精度太差，还是排序没排好。比如召回问题，相关文档根本没进候选池，那可能是向量表示不够好或检索范围太小；精度问题就是噪声文档混进来了，需要过滤或[[重排]]；排序问题则是相关文档得分低，得改进重排模型或特征。

具体到方案，我重点讲几个点。先说查询侧优化。用户query经常口语化、缺主语，我会用LLM做意图澄清，扩展同义词、补全主体。还有一个好用的技巧是HyDE，先用模型生成一个假设答案，拿它去检索，效果往往比用原始query好。复杂问题我会拆成子查询分别检索再合并，这样能提高召回。

再一个是检索侧增强。最基础也最有效的方案是[[混合检索]]，把向量检索和[[BM25]]关键词检索结合起来。向量擅长语义匹配，BM25强在精确匹配，比如订单号、错误码这些，向量可能跑偏，但BM25能精准命中。实际落地时，我会先用混合检索做粗筛，再上轻量重排比如[[Cross-Encoder]]精排，把最相关的几篇顶到前面。这里有个坑，Cross-Encoder效果虽好，但延迟高，所以一般只对粗筛后的top 50或top 100重排，不能全量做。

文档侧也有一些技巧。比如动态上下文压缩，用LLM从长文档里提取关键片段，去掉冗余，这样既能提升精度又能减少[[Hallucination]]。还有元信息过滤，比如按时间、来源标签预过滤，对时效性强的场景很管用。

工程权衡上，我会根据场景取舍。举个例子，客服退款场景，用户query口语化严重，查询改写收益明显；但如果是企业合规文档检索，对精度要求高且能接受几百毫秒延迟，那Cross-Encoder重排值得上。通用场景我倾向先上混合检索加轻量重排，再按需叠加。前提是得有bad case回流机制，持续收集线上失败的query，定期分析并迭代模型或规则。

说到迭代，其实这里还有一个延伸点：当检索质量一直上不去时，我会考虑是不是chunk策略出了问题。比如固定切分容易把关键信息切散，导致召回失败，这时候可能要改用语义切分或parent document策略，让子chunk和[[父文档]]关联。

所以整体上，我更倾向把检索优化看成一个持续迭代的过程，先定位瓶颈，选最轻量的方案上线，再用bad case驱动改进，而不是一上来就堆复杂模块。