完整题目
请分析检索增强生成（RAG）技术在实际应用中存在的主要缺陷和局限性，并讨论相应的解决方案或改进方向。
本文目录
答案要点
- 检索阶段：召回率低、相关性不足、向量语义鸿沟
- 生成阶段：上下文利用不足、幻觉与知识冲突、长文本建模困难
- 系统层面：延迟高、成本高、冷启动问题
- 改进方案需具体对应上述问题
一、检索阶段的缺陷
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质量参差（需内容过滤）、实时性要求高（新笔记秒级索引）、多模态内容（图文联合检索）。
换一种问法，检查是否真正理解
场景切入
假设你在做电商客服，用户问‘我上个月买的那个蓝牙耳机怎么连不上手机？’系统从商品库和对话历史里检索相关文档。实际跑起来，你发现有时候检索到的内容跟问题不太沾边，甚至模型自己瞎编答案，你觉得这背后可能是什么问题？
层层追问
你用过RAG吧？感觉怎么样？……那有没有遇到过检索结果不靠谱的情况？……再进一步，如果检索到的内容里有些跟模型自己的知识冲突了，模型会怎么处理？你觉得这个流程整体上有什么硬伤？
直球架构
分析一下RAG在实际应用中的主要缺陷，从检索、生成和系统三个层面分别说，比如召回率低、上下文丢失、延迟高等，然后针对每个问题给出对应的改进方案。
练习口述回答 · 约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]]。