RAG 有哪些主要缺陷?

30 秒回答

1. 检索阶段：召回率低、相关性不足、向量语义鸿沟
2. 生成阶段：上下文利用不足、幻觉与知识冲突、长文本建模困难
3. 系统层面：延迟高、成本高、冷启动问题
4. 改进方案需具体对应上述问题

回答与解析

答案要点

• 检索阶段：召回率低、相关性不足、向量语义鸿沟
• 生成阶段：上下文利用不足、幻觉与知识冲突、长文本建模困难
• 系统层面：延迟高、成本高、冷启动问题
• 改进方案需具体对应上述问题

一、检索阶段的缺陷

1. 召回质量不稳定

• 向量检索存在"语义鸿沟"：query与文档的embedding空间不对齐，导致字面相关但语义检索失败
• 稀疏场景（专业术语、ID、代码）dense retrieval效果差
• 改进：混合检索（BM25 + 向量）、query改写/扩展、重排序（Cross-encoder）

2. 上下文切片粒度难把握

• 切分太细丢失全局语义，切分太粗引入噪声
• 改进：语义切分（基于主题边界）、层次索引（摘要+详情）、多粒度召回

二、生成阶段的缺陷

3. 上下文利用不足（Lost in the Middle）

• 模型对长上下文中间位置信息遗忘，关键证据在prompt中间时被忽略
• 改进：重排序把关键文档放首尾、压缩/摘要减少长度、显式引用机制

4. 知识冲突与幻觉

• 检索内容与大模型参数知识矛盾时，模型可能"固执己见"或随机选择
• 改进：置信度校准、检索内容高亮标记、source attribution强制引用

三、系统层面局限

5. 延迟与成本

• 检索+重排+生成链路长，首token延迟高
• 改进：检索缓存、预计算embedding、流式生成、推测解码

6. 复杂推理场景失效

• 多跳问答、对比分析、数值计算等需要综合多源信息时表现差
• 改进：引入Agent（ReAct迭代检索）、知识图谱增强、专用工具调用

四、小红书场景的特殊考量

社区内容RAG还需解决：UGC质量参差（需内容过滤）、实时性要求高（新笔记秒级索引）、多模态内容（图文联合检索）。

口语版讲法(约4分钟)

• 问题本质：RAG不是万能方案，落地要看场景
• 检索阶段：混合检索解决语义鸿沟，切分要语义化
• 生成阶段：知识冲突和长上下文遗忘，用重排和置信度
• 系统层面：延迟成本与复杂推理，引入Agent
• 收尾：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 局限性和改进方向的基本看法。

关键一句:Agentic RAG 中模型自我反思（Self-RAG/Corrective RAG）的可靠性保证

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商客服，用户问‘我上个月买的那个蓝牙耳机怎么连不上手机？’系统从商品库和对话历史里检索相关文档。实际跑起来，你发现有时候检索到的内容跟问题不太沾边，甚至模型自己瞎编答案，你觉得这背后可能是什么问题？

2. 问法 2 · 层层追问

   你用过RAG吧？感觉怎么样？……那有没有遇到过检索结果不靠谱的情况？……再进一步，如果检索到的内容里有些跟模型自己的知识冲突了，模型会怎么处理？你觉得这个流程整体上有什么硬伤？

3. 问法 3 · 直球架构

   分析一下RAG在实际应用中的主要缺陷，从检索、生成和系统三个层面分别说，比如召回率低、上下文丢失、延迟高等，然后针对每个问题给出对应的改进方案。