RAG 是什么？和微调有何区别：2026 落地选型与排错指南
编辑标准与来源政策: 编辑标准, 团队. 内容均链至原始来源，见 方法论.
RAG（Retrieval-Augmented Generation） 就是：先从你的文档/知识库里检索相关片段，再让大模型基于这些片段生成回答。它解决的是「模型不知道你的私有资料」和「回答要可追溯来源」两类问题。
| 对比项 | 纯大模型问答 | RAG |
|---|---|---|
| 知识来源 | 训练数据 + 对话上下文 | 你的文档 / API / 知识库 |
| 能否引用内部资料 | 弱 | 强（可强制 citation） |
| 典型失败 | 幻觉、过时 | 召回错、引用漂、成本炸 |
| 适合 | 通用常识、写作 | FAQ、制度、合同、客服、研究助手 |
三种常见场景怎么选
| 场景 | 要不要上 RAG | 先验证什么 |
|---|---|---|
| 公司制度 / FAQ | 值得试 | 召回 Top-5 是否含正确答案 |
| 合同条款核对 | 值得试 | 引用是否逐条支撑结论 |
| 纯创意写文案 | 先别上 | 没有“必须检索”的材料 |
RAG 和微调有什么区别？（先把最容易懵的说清）
很多团队一上来就纠结：我们是该做 RAG，还是该微调（Fine-tuning）？
最短答案：
- 资料会更新、要可引用、要能指出“出自哪一段” → 优先 RAG
- 要改模型说话习惯、固定格式、领域口吻，且知识相对稳定 → 才考虑 微调
- 很多时候：RAG 解决“知道什么”，微调解决“怎么说/怎么做风格”；二者可以叠加，但起步通常先 RAG
| 对比 | RAG（检索增强） | 微调（Fine-tuning） |
|---|---|---|
| 像什么 | 开卷考试：先翻资料再答题 | 把知识点背进脑子里再答题 |
| 知识更新 | 改文档/重索引即可，通常更快更便宜 | 要重新训练或继续训练，周期长、成本高 |
| 可追溯 | 容易要求“必须引用原文片段” | 很难稳定指出答案来自哪条内部制度 |
| 典型价值 | 制度、FAQ、合同、客服、知识库问答 | 口吻统一、分类格式、特定推理习惯 |
| 典型风险 | 检索错了就答错（召回问题） | 背错/过时知识更难发现，更新贵 |
| 什么时候先别上 | 没有可检索的文档 | 只有几页会变的制度，却想靠训练硬背 |
一个生活化例子
- 问「我们公司差旅报销上限是多少？」→ 应该去翻最新制度：RAG 更合适
- 希望模型回答永远用你们客服话术、固定 JSON 字段 → 微调或强约束提示词可能更合适
- 既要引用最新制度，又要固定输出格式 → RAG + 输出约束（必要时再微调）通常比“只微调”更稳
选型口诀
- 知识常变吗？常变 → RAG
- 必须给来源吗？必须 → RAG
- 只是想让它更像你们的语气吗？→ 先提示词/少量样例，再谈微调
- 又变知识又要语气？→ 先 RAG 跑通，再考虑微调锦上添花
下面进入落地排错：不要一出问题就换模型，先拆召回、引用、延迟和成本。
RAG 的四种形态
| 场景 | 推荐形态 | 核心组件 | 风险 |
|---|---|---|---|
| FAQ / 帮助中心 | 传统 RAG | chunk、embedding、vector search、rerank | 问法变化大时召回不稳 |
| 合同 / 制度 / 报告 | GraphRAG / structured RAG | 实体、关系、层级摘要 | 构图成本高，更新慢 |
| 多文档研究 | Agentic RAG | query planning、tool use、multi-step retrieval | 延迟和成本上升 |
| 客服 / 内部知识库 | RAG + 评测集 | golden questions、citation、feedback loop | 没有评测就无法持续改进 |
Microsoft GraphRAG 的官方资料把 GraphRAG 定位为从非结构文本抽取结构化数据，并用图谱和摘要增强查询，可参考 Microsoft GraphRAG GitHub 和 Microsoft GraphRAG docs。这类方案适合关系复杂的文档，不适合每个普通 FAQ 都上。
7 天试点流程
- 第 1 天：选 30-50 个真实问题，覆盖简单事实、跨文档、边界问题和无答案问题。
- 第 2 天：整理文档版本、来源、更新时间和权限边界。
- 第 3 天：跑 baseline，记录召回片段、答案、引用和延迟。
- 第 4 天：调整 chunk、embedding、rerank 或 graph 结构，只改一个变量。
- 第 5 天：加入引用检查，验证每个结论是否有片段支持。
- 第 6 天：记录 token、延迟、缓存命中和失败样本。
- 第 7 天：决定继续优化、缩小范围或暂停。
最小评测表
| 问题类型 | 样例数量 | 通过标准 |
|---|---|---|
| 单文档事实 | 10 | 答案准确且引用原文 |
| 跨文档比较 | 10 | 能找齐关键来源 |
| 无答案问题 | 5 | 明确说无法从资料判断 |
| 时间敏感问题 | 5 | 能说明资料日期 |
| 权限边界问题 | 5 | 不泄露不可见内容 |
FAQ
2026 年做 RAG 还需要向量库吗？
多数场景仍需要，但向量库只是底层组件。真正决定质量的是文档处理、检索策略、引用约束、评测集和监控回路。
GraphRAG 一定比传统 RAG 好吗？
不一定。GraphRAG 适合关系复杂、跨文档推理多的资料。如果只是帮助中心 FAQ，传统 RAG 加 rerank 和评测集可能更划算。
RAG 项目最先补什么？
先补固定问题集和引用检查。没有评测，任何优化都只是感觉。
用 RadarAI 把关注变成固定节奏
如果只靠社交平台刷热度，很容易在同一天看到十几个互相矛盾的结论。更稳的做法是把关注动作拆成三步：先看官方发布和仓库变化，再看开发者是否真的能复现，最后决定是加入 watchlist、做小样本测试，还是暂时忽略。RadarAI 适合作为第一层过滤器：先从每日更新里发现变化，再回到官方文档、GitHub 仓库和产品页面核验。
适合继续阅读：
具体任务场景：内部制度问答 RAG
假设团队要做一个内部制度问答系统。输入是员工手册、报销制度、权限流程和历史问答；问题题包括“哪些费用可以报销”“审批超过几天怎么办”“某个例外情况是否适用”。第一轮不要追求全公司上线，而是选 30 个常见问题和 10 个边界问题做评测。
| 输入 | 动作 | 验收 | 失败样本 |
|---|---|---|---|
| 制度文档 | 切分、索引、保留来源 | 能召回正确条款 | 只召回相似但不相关段落 |
| 常见问题 | 生成答案和引用 | 答案短、引用支持结论 | 答案正确但引用错 |
| 边界问题 | 判断资料不足 | 明确说无法判断 | 虚构制度之外的规则 |
| 新版这份指南档 | 更新索引 | 旧答案不继续引用过期条款 | 新旧制度混用 |
这个场景可以暴露 RAG 的核心问题：召回、引用、版本、权限和评测。只要其中一项没有记录，上线后就很难排查。GraphRAG 或 Agentic RAG 可以解决部分复杂关系问题，但也会带来构图、延迟和维护成本。
发布后监控什么
| 指标 | 说明 | 异常时先查 |
|---|---|---|
| 无答案率 | 模型承认资料不足的比例 | 文档覆盖或问题分类 |
| 引用准确率 | 引用是否支撑结论 | citation prompt 和片段切分 |
| 召回命中率 | 正确文档是否进入候选 | embedding、hybrid、rerank |
| 平均延迟 | 用户等待时间 | top-k、rerank、缓存 |
| 单问成本 | token 和服务成本 | 上下文拼接和模型选择 |
这些指标比“用户觉得好不好”更可执行。RAG 项目只要有固定问题集和这些监控项，就能持续优化；没有它们，就会变成每次出错都靠猜。
从技术优化回到业务答案
RAG 团队很容易沉迷检索参数，但业务方只关心答案是否可信。每次优化都要回到三类样本：常见问题、边界问题、无答案问题。常见问题看效率，边界问题看准确性，无答案问题看系统是否克制。只有这三类都稳定，RAG 才适合扩大范围。
决策记录模板
把一次关注记录写下来，比临时争论更有用。可以用下面这张表作为团队内部记录格式：
| 字段 | 写法 | 示例 |
|---|---|---|
| 触发信号 | 从哪里看到这个变化 | 官方文档、GitHub release、RadarAI 更新 |
| 相关任务 | 它可能影响哪个现有流程 | 代码审查、客服问答、知识库、模型选型 |
| 验证动作 | 准备用什么小样本测试 | 30 分钟 quickstart、20 个固定问题、一个低风险 bug |
| 通过标准 | 什么结果才算值得继续 | 能复现、可审查、成本可估算、失败可回滚 |
| 当前决定 | watch / test / adopt / skip | 先 watch，两周后复查 |
| 复盘日期 | 什么时候再看 | 7 天、14 天或 28 天 |
这个记录不需要复杂，但必须可追溯。很多低参与内容的问题，是读者看完没有下一步；很多团队内部讨论的问题，是每次看到新工具都从零开始争。把信号、任务、验证和决定写成一行，既能减少重复讨论，也能让后续复盘有依据。
发布后如何复盘这个页面
内容刷新后，不只看排名。更应该看四类指标：第一，engagement_rate 是否比刷新前提升；第二，engaged_sessions 是否随 sessions 增长；第三，页面里的相关链接是否有人点击；第四，是否带来订阅、收藏或继续阅读。若 sessions 高但参与仍低，优先检查首屏结论是否清楚、表格是否太靠后、内链是否像“更多文章”而不是下一步动作。
如果 7 天后仍然低参与，可以先小修标题和开头；如果 14 天后仍然没有改善，检查页面是否与相邻主题重复；如果 28 天后仍然没有点击和停留，就考虑把它并入更强的主题页，保留原 URL 的流量入口和解释价值。
下一步行动
如果你负责这个主题，不需要一次性做完所有验证。先选一个低风险样本，把输入、动作、验收和失败记录下来；再把结果放进团队周会或个人复盘。能复现、能解释、能回滚的变化，才值得进入下一轮测试。不能复现但持续出现的变化，保留在 watchlist；既不能复现也无法对应实际任务的变化，直接跳过。