面试题 · 检索
搜索「分块」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在RAG系统中，当检索模块返回的相关文档并非目标答案时，可能的原因有哪些？可以从哪些技术角度进行优化以提升整体系统的准确率？
语义层面
数据层面
系统层面
1. 检索器增强
按学习路线查看教程、项目和面试题。
2. 查询侧优化
3. 重排序（Rerank）
4. 反馈与迭代
| 场景 | 诊断方法 | 解决思路 |
|---|---|---|
| 检索未召回 | 检查正确答案是否在候选池 | 扩大召回、混合检索、查询扩展 |
| 检索召回但排序低 | 查看正确答案的原始排序位次 | 重排序优化、特征工程 |
| 检索正确但生成错 | 分析上下文窗口、指令遵循 | 提示工程、RAG-specific微调 |
实际优化需结合具体bad case分析，避免盲目堆技术。
深入理解RAG架构，掌握检索与生成模块的协同机制，学习常见失败模式及优化策略。
场景切入
假设你在做一个智能客服系统，用户问“我的订单怎么还没到”，系统检索出的文档是订单退换货政策，完全答非所问。你觉得可能是什么原因？怎么从技术层面避免这种问题？
层层追问
RAG系统的检索结果如果跟问题不相关，你觉得问题出在哪儿？……如果文档本身是好的，但就是没召回，那可能是哪里的问题？……那召回回来了但排名太低呢？还有没有可能是查询本身表达不清？
直球架构
RAG中检索模块返回的文档与目标答案不匹配，请分析可能的原因，并给出至少三个技术优化方向，包括检索器、查询处理或排序策略上的改进。
这道题问的是检索结果不对目标答案的原因和优化方向，其实本质是问检索和生成之间的对齐问题。我们做[[RAG]]时经常会遇到：明明数据库里有正确答案，但检索模块就是没把它捞上来，或者捞上来了但排序太低，导致生成器没看到。那原因可以从数据、检索、查询三个层面拆，优化也对应着来。
先说数据层面。很多人上来就调模型，但我会先检查文档质量和[[Chunk]]策略。举个例子，客服退款场景下，用户问‘退款多久到账’，文档里可能写的是‘退款处理时效为1-3个工作日’，但如果你把这句话和‘退款条件’、‘退款流程’切到一个块里，或者块太小把‘1-3个工作日’截断了，那检索时语义就不够。所以数据预处理是前提，分块策略直接影响召回天花板。如果文档本身质量差，比如过时、矛盾，那后面怎么调都白搭。
再来说检索策略。最常见的问题是单一向量检索的召回瓶颈。用户口语化表达‘我的钱什么时候退回来’和文档正式说法‘退款到账时间’在语义空间里可能离得远。我的做法是**[[混合检索]]**，把[[BM25]]关键词召回和向量召回结合起来，结果做加权融合。你可以这么理解：向量负责语义相似，关键词负责精确匹配，比如订单号、错误码这种就得靠关键词。但混合检索也有坑，如果权重调不好，比如关键词权重太高，反而会召回一堆噪音。上线时我会先离线跑一批bad case，看哪些是向量没召回、哪些是关键词没召回，再调比例。
再进一步，检索出来Top-K可能还是不准，这时候要加[[Rerank]]。用轻量级的[[Cross-Encoder]]对候选结果精排，它比[[双塔]]模型精度高，能纠正向量排序的偏差。比如用户问‘苹果有什么新品’，向量可能把水果苹果的文档排前面，但Cross-Encoder能根据上下文判断用户要的是电子产品。不过重排有延迟成本，所以我会把它放在最后几位的候选集上，而不是全量。
查询侧优化也很关键。用户问题往往短、模糊，我会用LLM做查询改写，比如把‘退款多久’扩展成‘退款处理时效是几个工作日’。还有个技巧叫HyDE，先生成一个假设文档再检索，能拉近查询和文档的语义距离。但这里有个风险：如果LLM改写错了，比如把‘苹果’错误扩展成‘水果’，反而会引入噪音。所以我会加置信度过滤，改写后和原查询做相似度对比，分太低就弃用。
另外多说一句，检索正确但生成错的情况也很常见，这其实涉及[[Faithfulness]]问题，比如生成了文档里没有的细节。这时候优化方向就变成提示工程或微调了。
所以整体上，我更倾向把RAG系统看成检索和生成的协作，优化时要先诊断是哪个环节的问题。如果检索没召回，先看数据分块和混合检索；如果召回但排序低，加重排；如果检索正确但生成错，才去动生成器。盲目堆技术容易事倍功半，关键是基于bad case做迭代。