过境笔记

主题

RAG：让 Agent 先查证，再回答 ​

今天先记住 ​

RAG（Retrieval-Augmented Generation，检索增强生成）不是“给模型外挂一个资料库”这么简单。它在 Agent 系统里的位置，是把“凭上下文猜”改成“先拿到相关证据，再基于证据决策或回答”。它解决的不是模型会不会说话，而是模型在信息不完整、知识会变化、资料分散时，能不能把依据找回来。

它在大地图里的位置 ​

还是看这条链路：

txt
用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

昨天讲“短期状态和长期记忆”，今天往旁边拧一圈：RAG 是上下文进入模型之前的一道检索门。它先从文档、知识库、历史记录或代码索引里找材料，再把少量相关片段放进当前上下文。

所以 RAG 不等于长期记忆。长期记忆回答“以前确认过什么”，RAG 回答“这次任务需要查哪几段资料”。

它到底是什么 ​

最小的 RAG 流程只有三步：

  1. 把用户问题变成检索请求。
  2. 从外部资料里取回相关片段。
  3. 让模型基于这些片段生成答案、计划或下一步动作。

关键点在“取回相关片段”。如果检索拿错了，模型后面说得再顺也只是顺着错材料发挥；如果取回太多，上下文会被噪音塞满，真正重要的约束反而被挤掉。

为什么 Agent 里会用到它 ​

Agent 经常要处理不在模型参数里的东西：项目文档、接口说明、当天发布规则、用户自己的长期偏好、刚刚生成的日志。把这些内容全部常驻 prompt 太贵，也容易过期；完全不放进去，模型又只能猜。

RAG 的价值是把“需要时再查”制度化。比如一个发布 Agent 在写每日课程前，不该靠记忆猜框架，而应该检索课程框架、上一课主题和已有文件；一个代码 Agent 在改函数前，也不该只凭文件名判断调用关系，而应该先检索相关定义和引用。

这不是抽象地“提高准确率”，而是避免具体失败：引用旧规则、漏读约束、重复写同一主题、把不相关历史当成当前事实。

怎么判断它有没有用 ​

如果答案必须依赖项目内文档、知识库、日志、历史记录，RAG 很可能有用。

如果问题只需要当前对话里已经给出的信息，先别上 RAG，直接用上下文更稳。

如果资料会频繁变化，比如 API 文档、发布流程、产品规则，RAG 要优先查最新来源，并在答案里保留依据边界。

如果检索结果无法解释“为什么这几段被拿回来”，系统很难调试。至少要能看到 query、命中文档、片段位置和相似度或排序理由。

最近冒出来的词 ​

今天不追新词，先把主线概念讲稳。

一个小例子 ​

txt
Input:
用户要求生成 2026-07-19 的 AI Agent Daily，并说“不要重复上一课”。

Process:
1. 检索 ai-agent 目录，找到上一课是“短期状态和长期记忆”。
2. 检索课程框架，发现下一条主线是 RAG。
3. 把框架要求、上一课标题、今天日期放进当前上下文。
4. 生成文章并检查标题、frontmatter、文件路径是否一致。

Output:
系统写入 /ai-agent/2026-07-19.md；
主题选择 RAG；
文章不会再讲昨天的“长期记忆”，而是解释“检索如何把外部证据带进当前任务”。

这个例子能用来判断一个真实系统：它是在“生成前查证”，还是“生成后找理由”。前者是 RAG，后者只是补引用。

常见误区 ​

  1. 以为 RAG 就是向量数据库。向量库只是常见检索手段，RAG 的核心是“查什么、怎么排、放多少、如何使用”。
  2. 以为检索到内容就一定可靠。检索只能给候选证据，仍要判断时间、来源和适用范围。
  3. 以为片段越多越好。太多片段会稀释重点，让模型忽略真正关键的约束。
  4. 以为 RAG 可以替代工具调用。RAG 负责拿资料，工具调用负责改变外部状态，两者不能混成一件事。

今天自测 ​

  1. RAG 和长期记忆最核心的区别是什么？
  2. 如果 Agent 回答时引用了过期文档，你会检查 RAG 流程里的哪几步？
  3. 什么情况下不用 RAG 反而更稳？