4 哪些场景适合用 RAG，哪些场景不适合
P1 · rag
🏷 标签：rag, use-case, trade-off, decision
1️⃣ 考察意图
面试官想看你能否跳出“RAG 万能论”的陷阱，精准判断技术选型的边界。这题不是背概念，而是工程取舍决策——考察你是否理解 RAG 的检索延迟、噪声引入、推理能力短板等核心 trade-off。刁钻点在于：很多人只会说“需要外部知识就用 RAG”，但忽略了“模型已掌握的知识”和“深度推理任务”才是反例。答好了能展示系统设计视野和落地经验，证明你不是只会调 API 的工程师。
2️⃣ 标准答
适合 RAG 的场景：
- 知识频繁更新：如新闻摘要、实时股价问答。RAG 通过检索最新文档（如用 BM25 或 DPR 索引每日新闻），避免模型过时。坑：索引更新延迟需控制在分钟级，否则用户拿到旧数据；解法是用增量索引（如 Elasticsearch 的 _update API）配合 TTL 策略。
- 需要引用来源：如法律合同审查、医疗诊断辅助。RAG 能返回检索到的原文段落（如用 ColBERT 的 token-level 匹配），增强可信度。工程取舍：检索精度 vs 召回率——用 dense retrieval（如 DPR）提高语义匹配，但牺牲对罕见术语的召回；可混合 sparse（BM25）做互补。
- 长尾/开放域问题：如企业知识库问答，用户问“公司 2023 年 Q3 的营收策略”。RAG 从海量文档中定位答案，避免模型幻觉。实际落地坑：chunking 策略不当（如固定 512 token 切分）会切断上下文；解法是用语义分块（如基于段落边界或 embedding 相似度聚类）。
- 多语言/低资源场景：如小语种客服。RAG 检索双语语料，绕过模型训练数据不足。注意：检索器需用多语言 embedding（如 LaBSE），否则跨语言匹配差。
不适合 RAG 的场景：
- 知识高度固定且模型已掌握：如“1+1=？”或“太阳从东边升起”。RAG 引入不必要的检索延迟（通常 100-500ms），且检索结果可能噪声干扰（如搜到“太阳从西边升起”的玩笑帖）。解法：用分类器（如 fastText）预判问题是否需检索，或直接让模型内化知识。
- 实时性要求极高：如高频交易问答、实时语音助手。RAG 的检索+生成流水线（尤其 rerank 阶段）延迟不可控（>1s）。取舍：牺牲精度换速度——用近似最近邻搜索（如 HNSW）替代精确检索，或预计算高频问题的缓存。
- 需要深度推理：如数学证明、逻辑谜题。RAG 检索的片段可能包含无关噪声，打断推理链。例如，问“证明根号 2 是无理数”，检索到“根号 2 约等于 1.414”反而误导。解法：用 CoT 提示或微调模型（如用 GRPO 强化推理），而非依赖 RAG。
- 创意写作：如诗歌生成、故事创作。RAG 检索的模板化内容会扼杀原创性，且引用来源限制想象力。工程取舍：若必须用，只检索风格参考（如“李白诗风”），不检索具体句子。
总结：RAG 是“知识增强”工具，不是“推理增强”工具。决策时画一个 2x2 矩阵：X 轴是“知识新鲜度/外部性”，Y 轴是“推理深度”；RAG 适合高 X 低 Y 区域，低 X 高 Y 区域用纯 LLM 或微调。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，适合 RAG 的场景——知识频繁更新、需要引用来源、长尾问题，比如实时新闻问答或法律文档审查；第二，不适合的场景——知识固定且模型已掌握、实时性要求极高、需要深度推理，比如数学证明或高频交易；第三，核心取舍——RAG 是知识增强工具，不是推理增强工具，决策时用‘知识新鲜度 vs 推理深度’矩阵判断。总结一句：RAG 解决‘模型不知道’的问题，不解决‘模型想不通’的问题。”
4️⃣ 高频追问 & 应对
追问 1：你说 RAG 不适合深度推理，那如果用户非要问数学证明，怎么优化？
应对策略：可以混合使用——先检索相关定理（如勾股定理的证明步骤），再让模型用 CoT 推理。但注意：检索结果必须高度相关，否则噪声会放大错误。工程上，用 reranker（如 Cohere Rerank 3）过滤低分片段，并设置置信度阈值（如 <0.7 则 fallback 到纯 LLM 推理）。实际案例：在医疗诊断中，RAG 检索症状描述，但最终诊断需模型推理，所以用两阶段——检索+推理分离。
追问 2：RAG 的检索延迟怎么优化？给具体数字。
应对策略：典型 RAG 流水线延迟分布：embedding 生成（~50ms for 512 tokens）、向量检索（~10ms for HNSW 索引）、rerank（~100ms for 100 候选）。优化点：1）用量化 embedding（如 int8）减少存储和计算，延迟降 30%；2）预计算高频问题的缓存（如 LRU 缓存），命中率可达 40%；3）用异步流水线（如 FastAPI + asyncio）并行检索和生成，总延迟从 500ms 降到 200ms。取舍：缓存牺牲新鲜度，适合知识变化慢的场景。
追问 3：RAG 和微调怎么选？给个决策树。
应对策略：决策树：1）知识是否频繁更新？是→RAG；否→2）模型是否已掌握？是→纯 LLM；否→3）数据量是否足够（>1000 条）？是→微调（如 LoRA）；否→RAG。注意：微调适合固定知识（如公司内部术语），但成本高（训练+部署）；RAG 适合动态知识，但需维护检索索引。实际案例：客服系统用 RAG 处理新产品问题，用微调处理常见 FAQ。
5️⃣ 避坑 · 常见错误答法
- ❌ “RAG 适合所有需要外部知识的场景，比如数学证明。” → ✅ “数学证明需要深度推理，RAG 检索的片段可能引入噪声，打断逻辑链；更适合用 CoT 或微调。”
- ❌ “RAG 不适合实时场景，因为检索太慢。” → ✅ “实时场景可通过 HNSW 索引和缓存优化延迟到 200ms 内，但若要求 <50ms（如高频交易），则不适合。”
- ❌ “RAG 和微调是互斥的，只能选一个。” → ✅ “可以混合使用：RAG 处理动态知识，微调处理静态知识；例如医疗问答中，RAG 检索最新论文，微调模型理解医学术语。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“实际落地坑”切入，比如“我在客服系统中用 RAG 处理长尾问题，但发现 chunking 策略不当导致召回率低，后来用语义分块提升 15%”。展示你踩过坑并解决了。
- 如果你只做过传统 NLP：用“检索 vs 生成”类比迁移，比如“传统信息检索中 BM25 和 DPR 的取舍，和 RAG 的适用场景判断类似”。强调你理解 trade-off 思维。
- 如果你是校招无项目：聚焦“决策树”和“2x2 矩阵”的抽象框架，比如“我复现过一篇 RAG 论文，发现它不适合数学推理，因为检索噪声干扰 CoT”。展示你读过论文并思考过边界。
- “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (Lewis et al., 2020) — RAG 原始论文，理解设计动机
- “REALM: Retrieval-Augmented Language Model Pre-Training” (Guu et al., 2020) — 对比 RAG 的预训练变体
- “When Not to Use RAG: A Decision Framework” (LangChain 博客) — 实用决策指南
- “HNSW: Hierarchical Navigable Small World Graphs for Approximate Nearest Neighbor Search” (Malkov & Yashunin, 2016) — 延迟优化核心算法
- “ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction” (Khattab & Zaharia, 2020) — 检索精度提升方法