RAG 适用场景

🎯 学习目标

• 说清 RAG 不是替代 LLM，而是为 LLM 提供可更新的事实层
• 能对照业务场景判断 RAG 是否合适
• 区分「模型不知道」与「检索没召回到」两类失败
• 建立「回答 + 引用来源」的产品预期

引言

用户问「公司去年 Q3 报销政策是什么？」通用 LLM 既可能瞎编，也无法保证引用最新内部文档。RAG（Retrieval-Augmented Generation）的核心思路是：先查资料，再让模型组织语言。本节从问题出发，而不是一上来就堆向量库名词。

章节正文

第 1 步：RAG 解决的五个典型痛点

痛点	没有 RAG 时	RAG 如何应对
知识滞后	模型停留在训练 cutoff	检索最新入库文档
幻觉	流畅但无依据	用检索片段锚定事实
不可追溯	用户无法验证	回答附 chunk 来源
领域知识不足	通用语料缺私有知识	注入企业语料
长文本限制	整库塞不进窗口	只检索相关 chunk

RAG 不保证 100% 正确，但把错误从「黑盒幻觉」变成「可定位到检索哪一步出了问题」。

第 2 步：RAG 不适合什么

以下场景 RAG 不是首选：

• 强推理/数学：靠检索公式片段不够，可能需要代码执行或推理模型
• 实时性极高且结构化：库存、余额应查 API + Tool，而非文档索引
• 文档质量极差：垃圾进垃圾出，应先治理语料

判断口诀：答案是否已经存在于某份可索引文本中？是 → RAG 候选；否 → 工具或 Workflow。

第 3 步：最小 RAG 心智图

离线：文档 → 切分 → Embedding → 写入向量库
在线：用户问题 → 检索 Top-K 片段 → 拼进 Prompt → LLM 生成 → 带引用返回答案

两个世界：索引世界（慢、可批处理）与查询世界（快、要延迟可控）。很多线上问题来自只优化了后者而忽略索引更新与 chunk 质量。

第 4 步：与 Fine-tuning 的边界

手段	擅长	不擅长
RAG	事实更新、可引用、低成本迭代	改变模型风格、复杂行为
SFT/LoRA	格式、语气、任务模式	频繁变更的事实库

企业知识问答通常 RAG 优先；只有当「必须固定输出格式/流程」且检索不够时才叠加微调。

动手练习

1. 列举你业务中 3 个适合 RAG 的问题、2 个不适合的，并写理由。
2. 画一张「用户 → 检索 → LLM → 引用」时序图，标注失败时可观测的环节。
3. 阅读一篇带脚注的 RAG 产品回答，反推其 Prompt 可能如何约束「仅基于上下文」。
4. 对比同一问题在纯 LLM 与 RAG（mock 片段）下的回答，记录 hallucination 差异。

常见问题

Q：RAG 能消除幻觉吗？

不能消除，但能显著降低。模型仍可能错误归纳检索片段，或在片段不足时编造。需 Prompt 约束、拒答策略、引用校验与人工反馈闭环。

Q：知识库很小（几十页）还需要 RAG 吗？

若总文本可稳定塞进上下文且更新不频繁，可「长上下文 + 全文」简化架构。一旦超窗口或需频繁更新，仍应切分检索。

Q：RAG 和 Agent 是什么关系？

RAG 常作为 Agent 的一个 Tool（search_knowledge_base）。Agent 还可多步规划；RAG 专注「用检索增强单次或少数几次生成」。

本节小结

RAG 为 LLM 提供可更新、可审计的外部事实层，解决滞后、幻觉、领域与窗口限制。先判断问题是否「文档里已有答案」，再进入后续流水线学习。