面试题 · 评估
请分析检索增强生成（RAG）技术在实际应用中存在的主要缺陷和局限性，并讨论相应的解决方案或改进方向。
1. 召回质量不稳定
2. 上下文切片粒度难把握
学习内容与项目面试，在同一条路上。
3. 上下文利用不足（Lost in the Middle）
4. 知识冲突与幻觉
5. 延迟与成本
6. 复杂推理场景失效
社区内容RAG还需解决：UGC质量参差（需内容过滤）、实时性要求高（新笔记秒级索引）、多模态内容（图文联合检索）。
场景切入
假设你在做电商客服，用户问‘我上个月买的那个蓝牙耳机怎么连不上手机？’系统从商品库和对话历史里检索相关文档。实际跑起来，你发现有时候检索到的内容跟问题不太沾边，甚至模型自己瞎编答案，你觉得这背后可能是什么问题？
层层追问
你用过RAG吧？感觉怎么样？……那有没有遇到过检索结果不靠谱的情况？……再进一步，如果检索到的内容里有些跟模型自己的知识冲突了，模型会怎么处理？你觉得这个流程整体上有什么硬伤？
直球架构
分析一下RAG在实际应用中的主要缺陷，从检索、生成和系统三个层面分别说，比如召回率低、上下文丢失、延迟高等，然后针对每个问题给出对应的改进方案。
我觉得这道题本质上在问：[[RAG]] 到底是不是一个拿来就能用的银弹？答案显然不是。它有很多坑，而且不同场景下坑还不一样。所以我的理解是，RAG 适合知识密集但不需要深度推理的场景，比如客服退款政策查询，而微调适合模型需要内化某种能力的场景，比如翻译。真正落地的时候，往往是 RAG 和微调配合着来，或者 RAG 内部几种检索策略混着用。
先说检索阶段最大的问题，召回质量不稳定。向量检索有个所谓的语义鸿沟，query 和文档的 [[Embedding]] 空间可能没对齐，比如用户搜“退款流程”，向量可能把“退货政策”排前面，但字面相关的“退款”反而排后面。特别是专业术语、订单号、错误码这种稀疏场景，[[Dense Retrieval]] 效果很差。我的改进思路是上 [[Hybrid Search]]，把 [[BM25]] 关键词检索和向量检索结合起来，先粗筛再精排，比如用 [[Cross-Encoder]] 做 [[重排]]，把真正相关的文档提上来。这里有个前提：重排模型一定要针对你的业务数据微调过，否则效果反而变差。
另一个检索问题是上下文切分粒度。固定按字数切分，太细了丢失全局语义，比如一个退款政策被切到两段里，模型只看到半截；太粗了又引入噪声。我会用语义切分，比如按主题边界或者 Markdown 标题来切，再构建层次索引，[[父文档]]存摘要，子文档存细节，召回时先定位到父文档，再拉子文档。这样既保证精度，又不丢信息。
生成阶段的核心矛盾是知识冲突和长上下文遗忘。模型有自己预训练的知识，当检索到的内容跟它记忆里矛盾时，它可能固执己见，也可能随机选一个，这就是 [[Hallucination]]。我的做法是让模型显式引用来源，比如在 prompt 里要求“只根据以上文档回答，如果文档没有，就说不知道”，同时做置信度校准，把检索结果分太低的直接丢掉。还有一个常被忽略的点：Lost in the Middle 现象，模型对长上下文中间位置的信息容易遗忘。我会把关键文档放到 prompt 首尾，或者先压缩再喂给模型。
系统层面，延迟和成本是逃不开的。检索加重排加生成，链路很长，首 token 延迟高。我会做检索缓存，对高频 query 直接返回结果，还有预计算 Embedding 和流式生成。另一个风险是复杂推理场景，比如多跳问答“退款的商品如果价格变了怎么算”，RAG 单次检索搞不定。我会引入 [[Agent]]，用 [[ReAct]] 模式让模型迭代检索，或者结合 [[Knowledge Graph]] 做结构化推理。但这也引入新风险，Agent 可能陷入死循环，所以上线前我会特别关注超时和重试策略。
说到 Agent，其实 RAG 的下一步就是 [[Agentic RAG]]，让模型自己决定什么时候检索、检索什么、怎么整合。但这里有个关键问题：怎么保证 Agent 的决策是可靠的？比如它可能因为一次错误检索就放弃正确答案。我最近在关注 [[Self-RAG]] 和 [[Corrective RAG]]，让模型在生成过程中自我反思，发现矛盾就重新检索。这虽然增加了计算开销，但能显著提升 [[Faithfulness]]。
所以整体上，我更倾向于把 RAG 看作一个工具箱，而不是一个固定流程。检索和生成之间的平衡，取决于业务对精度和延迟的要求。如果让我选，我会优先保证检索质量，因为生成再强也救不了错误输入。这就是我对 RAG 局限性和改进方向的基本看法。