14.02-RAG适用场景

要点

• RAG 的核心价值是「基于私有或实时知识，检索事实并生成回答」——不满足这个条件，通常不该上 RAG
• 三个诊断问题决定选型：知识在哪里、会不会变、要不要溯源
• RAG 真正的优势区间是：知识量大 + 持续更新 + 需要引用出处
• 知识库小于 5000 字，直接塞进 Prompt 往往更简单可靠
• 风格学习、确定性转换、深度推理——这些场景用 RAG 是选错了工具

1. 别急着搭 RAG，先回答三个问题

很多团队在决定做「知识库问答」之后，第一反应是搭 RAG。但在动手之前，先花十分钟想清楚三件事——答案不同，方案就完全不同。

1.1 你需要的知识在哪里

模型训练数据包含了截至训练时间的公开通用知识：Python 语法、HTTP 协议、常见框架用法。它不知道的是你公司的报销流程、今天的产品价格、某个客户的订单状态。

判断标准很简单：如果你用 GPT-4o 直接问，它能准确回答，就不需要 RAG。 模型本身的知识已经够用，加一层检索只是徒增延迟和成本。

知识在模型外面的情况分两类：私有数据（公司文档、产品手册）和实时数据（新闻、股价）。这两类才需要考虑 RAG。

1.2 这些知识会更新吗

知识在外面，也不一定需要 RAG——还要看更新频率。

如果知识几乎不变（比如公司创立以来的核心章程），微调（Fine-tuning）可能是更好的选择。把知识训练进模型权重，推理时不需要额外检索，延迟更低、成本更稳定。

但如果知识会频繁更新——产品文档每周迭代、政策法规随监管变化、新闻每分钟刷新——微调的成本就不可接受了。每次变化都要重新训练，RAG 更新知识库却是即时的。

1.3 需要告诉用户答案来自哪里

这一点容易被忽略，但在很多场景里是硬需求。

客户问「你说的保修期是 3 年，出处在哪」，员工问「这个合规要求是哪份文件规定的」——你需要能追溯到具体文档片段。RAG 天然支持溯源，每个回答都能标注来自哪个 chunk、哪份文档。微调把知识融入了权重，无法做到这一点。

如果来源不重要、只要答案对就行，微调或长上下文都是可选项。

把这三个问题组合起来，得到一个选型表：

知识位置	更新频率	需要溯源	推荐方案
模型已知	—	—	直接用模型
私有数据	几乎不变	不需要	微调
私有数据	几乎不变	需要	微调或 RAG
私有数据	频繁更新	需要	RAG
实时数据	实时	需要	RAG
实时数据	实时	不需要	RAG 或 Function Calling

大多数实际场景落在「私有数据 + 频繁更新 + 需要溯源」这个区间——这正是 RAG 的主场。

2. RAG 为什么在这些场景有效

上一节给了判断框架，但还有一个更深的问题：RAG 在这些场景里有效的底层原因是什么？

答案在于 RAG 同时解决了三件事：

1. 知识边界问题——模型只知道训练数据里有的东西，RAG 把外部知识注入上下文，突破了训练截止日期的限制
2. 规模限制问题——上下文窗口装不下几十万份文档，RAG 先检索出最相关的几段，只给模型看它需要的
3. 可信度问题——模型「凭记忆」回答时无法验证，RAG 每次检索都带上来源，回答可以追溯到原始文档

这三个条件同时成立的场景，RAG 才是不可替代的。如果只满足其中一两个，可能有更简单的方案。

2.1 企业内部知识库

公司有几万份文档，员工用自然语言提问，AI 基于文档回答。这是 RAG 最经典的应用。

四个条件同时成立：文档量大（上下文装不下）、文档持续更新（新版本、政策变化）、员工需要验证来源、不同部门看到不同知识库（权限隔离）。

// 企业内部 RAG：查询时按用户权限过滤知识库
const ragSystem = {
  knowledgeBases: [
    { id: 'kb-product', name: '产品文档', accessibleBy: ['all'] },
    { id: 'kb-hr', name: '人事政策', accessibleBy: ['hr', 'managers'] },
    { id: 'kb-finance', name: '财务规范', accessibleBy: ['finance', 'managers'] },
    { id: 'kb-eng', name: '技术规范', accessibleBy: ['engineering'] },
  ],
  async query(question: string, userId: string) {
    const user = await getUser(userId)
    const accessibleKBs = this.knowledgeBases.filter(
      (kb) => kb.accessibleBy.some((role) => user.roles.includes(role))
    )
    return vectorDB.query(queryVector, {
      filter: { kbId: { $in: accessibleKBs.map((kb) => kb.id) } },
    })
  },
}

这里的权限隔离不是附加功能，而是 RAG 架构的自然结果——每个知识库在向量数据库中独立存储，查询时按 namespace 过滤即可。微调做不到这种粒度的知识隔离。

2.2 客服与专业领域问答

客服机器人、法律咨询、医疗指南、金融合规——这些场景对准确性要求极高，模型不能「凭记忆」回答。

核心原因：这些领域的知识会更新（新版法规、新产品信息），而且回答必须有依据。用户问「经济补偿怎么算」，你要能指出来自《劳动合同法》第几条，而不是让模型自己编一个。

// 法律 RAG 的溯源结构
const legalRAGResponse = {
  answer: '根据《劳动合同法》第四十七条，经济补偿按劳动者在本单位工作的年限...',
  citations: [
    {
      source: '《劳动合同法》',
      article: '第四十七条',
      text: '经济补偿按劳动者在本单位工作的年限，每满一年支付一个月工资...',
      effectiveDate: '2008-01-01',
    },
  ],
}

这类场景的 Prompt 设计也需要更严格的约束——明确告诉模型「只基于检索到的内容回答，知识库没有答案时告知用户，不要编造」。

2.3 实时信息问答

新闻、股价、天气——信息变化太快，训练数据追不上。RAG 的知识库可以对接实时数据流，每次查询都拿到最新数据。

这个场景也可以用 Function Calling（让模型调用外部 API 获取数据）。两者的分界线是：需要从大量数据中检索选 RAG，需要调用特定 API 获取特定值选 Function Calling。 如果你的「实时数据」其实就是一个 API 调用返回一个数值，Function Calling 更直接。

3. RAG 不适用的场景

判断什么时候不用 RAG，和判断什么时候用同样重要。

3.1 学习特定风格或语气

让模型学会公司品牌语气、特定作者文风——RAG 在这里帮不上忙。

原因：RAG 检索的是事实性内容（「这个产品有什么功能」），不是风格模式（「用什么语气描述这些功能」）。你可以用 RAG 检索到产品功能的描述，但很难用它教会模型「像乔布斯一样介绍产品」。

更合适的方案是微调——让模型从大量风格一致的文本中学习输出模式。

3.2 知识已经在模型训练数据里

「Python 怎么安装」「HTTP 404 什么意思」——模型本身就知道答案。加 RAG 的效果是：多一次 embedding 调用、多一次向量检索、多一段上下文占用，而回答质量不升反降（检索到的文档可能不准确，反而干扰模型）。

判断方法：如果通用模型直接问就能准确回答，就不需要 RAG。 先用 GPT-4o 测 20 个典型问题，如果准确率已经够高，省掉 RAG 这一层。

3.3 确定性转换任务

把 JSON 转成 XML、把 Markdown 转成 HTML——这是确定性规则，不需要知识，也不需要模型参与。写代码做转换比用 LLM 更可靠、更便宜、更快。

RAG 解决的是「知识密集型」问题，不是「规则密集型」问题。

3.4 知识库太小

如果你的「知识库」只有几页内容，直接塞进 Prompt 就够了。

// 知识库 < 5000 字时，直接塞进 Prompt 更简单
const smallKB = await loadSmallKnowledgeBase()
const prompt = `
根据以下信息回答：
${smallKB}

问题：${userQuestion}
`

RAG 引入的复杂度（切分策略、embedding 模型、向量数据库、检索调优）在小知识库场景里得不偿失。第 5 节会给出具体的切换阈值。

3.5 需要深度推理而非事实检索

「根据 A 公司的财务数据和行业趋势，分析明年的增长潜力」——这需要模型自己思考，不是从文档里找现成答案。

RAG 能提供相关数据，但推理质量取决于模型本身的能力。这种情况可能需要 RAG + CoT（Chain of Thought）结合，或者直接用更强的推理模型。RAG 解决的是「知道什么」，不解决「怎么想」。

4. 容易误判的边界：长上下文 vs RAG

这是 2025-2026 年最常见的争论：模型上下文窗口已经大到 128K-200K token，直接把所有文档塞进上下文不就行了？

短答案：知识库小的时候可以，大到一定程度就不行。 但原因不只是「装不下」。

长上下文有三个隐藏成本：

1. 注意力稀释——上下文越长，模型对中间部分的注意力越差。这就是「Lost in the Middle」现象：模型对开头和结尾的信息记得清楚，中间部分容易被忽略。RAG 每次只给模型看最相关的几段，上下文短，注意力集中
2. 成本线性增长——上下文越长，每次请求消耗的 token 越多，成本越高。RAG 的上下文长度相对稳定（系统指令 + top-K chunk + 问题），不随知识库规模增长
3. 延迟增加——上下文越长，模型处理越慢。RAG 的检索延迟通常在几十毫秒级，而处理 100K token 上下文的延迟可能是处理 2K token 的几十倍

经验阈值：

知识库规模	建议方案	原因
< 5000 字	直接塞进 Prompt	简单可靠，无额外复杂度
5000-50000 字	长上下文或 RAG 均可	看成本预算和延迟要求
> 50000 字	RAG	上下文装不下，注意力稀释严重

5000 字和 50000 字不是精确分界线，而是量级参考。实际决策时，还要看文档结构（结构化程度高更适合 RAG）、查询频率（高频查询 RAG 成本更低）和溯源需求（需要溯源必须 RAG）。

5. RAG 的成本估算

决定是否上 RAG，成本是不可回避的因素。好消息是：索引成本极低，主要成本在查询侧。

5.1 索引成本：一次性投入

// 索引成本估算：1 万份文档
const totalDocs = 10000
const avgDocLength = 2000        // 平均每份 2000 字
const totalTokens = totalDocs * avgDocLength / 2  // ≈ 1000 万 token

// OpenAI text-embedding-3-small: $0.02 / 1M token
const embeddingCost = (totalTokens / 1_000_000) * 0.02  // ≈ $0.2

1 万份文档的全量索引，embedding 成本约 $0.2。向量数据库存储（10 万条向量）在 Pinecone 免费层即可承载。

5.2 查询成本：每次请求

// 单次查询成本估算
const queryTokens = 50           // 问题向量化
const contextTokens = 2000       // 检索到的上下文
const outputTokens = 500         // 模型输出

// Embedding: ≈ $0.000001
// LLM (GPT-4o): 输入 $2.5/1M × 2050/1M + 输出 $10/1M × 500/1M ≈ $0.01
// 单次查询总成本 ≈ $0.01

每天 1000 次查询约 $10/天、$300/月。这个量级对大多数企业可以接受。

成本优化的主要方向在查询侧：缓存高频查询结果、用小模型做初筛减少大模型调用、调整 top-K 控制上下文长度。如果查询量达到每天数万次，这些优化的收益会非常显著。

6. 四个常见误区

误区一：「所有 AI 功能都要上 RAG」

不是。如果一个功能用 Prompt + 模型本身知识就能做好，加 RAG 是增加复杂度，不是提升质量。先问第 1 节的三个问题。

误区二：「RAG 能解决所有知识问题」

RAG 解决的是事实性知识检索。如果问题是「这个产品应该怎么改进」，这需要推理和判断，RAG 能提供相关数据，但推理质量取决于模型本身。不要期望 RAG 替代思考。

误区三：「RAG 不需要评估」

「检索 + 生成」听起来简单，但每个环节都可能出问题：切分不好丢信息、embedding 不准检索偏、Prompt 没约束模型编造。没有评估就上线等于盲飞。第 14.17 节会讲 RAG 评估体系。

误区四：「向量数据库选好了就万事大吉」

向量数据库只是链路中的一环。切分策略、embedding 模型、检索算法、Rerank、Prompt 设计——每个环节都影响最终效果。第 14.05-14.13 节会逐个拆解这些环节。

7. 下一步

三个问题帮你锁定是否该用 RAG：知识在哪里、会不会更新、要不要溯源。三个答案都指向 RAG 时，就可以进入工程实现阶段。

RAG 的第一步是文档上传和索引——把文档变成可检索的向量。下一篇讲文档上传流程，也就是 RAG 索引链路的起点。