面试题 · 检索
当大模型应用中出现检索上下文不准确或质量不佳的情况时，您会采取哪些应对策略和技术方案？
1. 查询侧优化（Query Rewriting）
2. 检索侧增强
按学习路线查看教程、项目和面试题。
3. 文档侧处理
4. 重排序与过滤
| 方案 | 延迟 | 效果增益 | 适用场景 |
|---|---|---|---|
| 查询改写 | +50-100ms | 中等 | 用户 query 口语化严重 |
| Cross-Encoder 重排 | +100-300ms | 显著 | 对精度要求高，可接受延迟 |
| 混合检索 | +20ms | 中等 | 通用场景 baseline |
实际落地建议：先上混合检索+轻量重排，再按需叠加复杂模块，同时建立 bad case 回流机制持续迭代。
场景切入
假设我们做一个电商客服助手，用户问“这个订单什么时候发货”，结果检索出来的上下文全是退款政策，完全对不上。你遇到这种情况会怎么排查和修复？
层层追问
RAG应用中检索上下文质量不行，你一般怎么处理？……比如是召回不够还是噪声太多？……那如果要兼顾效果和延迟，你会优先上哪些方案？
直球架构
当检索上下文不准确或质量差时，请给出你的应对策略和技术方案，包括问题诊断环节和至少三种具体方案，并说明各自的适用场景和trade-off。
这道题其实是在问，当[[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驱动改进，而不是一上来就堆复杂模块。