rag 模型一般用来做什么

很多人第一次接触 RAG，是被「让模型读我自己的资料」这句话吸引的，但真动手前会卡住：我这点需求到底算不算 RAG？是查文档问答、做客服、还是给内部工具加个检索？这篇不讲原理，只按开发者能对上号的场景来梳理，帮你判断该不该上、先从哪个场景试，以及什么情况下 RAG 反而不合适。

很多人第一次接触 RAG，是被「让模型读我自己的资料」这句话吸引的，但真动手前会卡住：我这点需求到底算不算 RAG？是查文档问答、做客服、还是给内部工具加个检索？这篇不讲原理，只按开发者能对上号的场景来梳理。

先说清楚一件事：RAG 不是万能药，它更像给模型临时配了一摞参考资料。你要做的，是先判断自己的问题是不是「资料不在模型脑子里」，还是「模型不够聪明」。前者才轮到 RAG。判断标准很简单：如果回答必须引用一份你自己维护的资料清单，那基本就是它了。

先对齐：RAG 到底替模型干了哪件事

RAG 的价值是把外部资料在回答前塞进上下文，让模型基于给定材料作答，而不是靠自己记住的东西。它解决的是知识不在模型权重里、或者变动太快的场景，不解决推理能力问题。换句话说，它管的是「模型知不知道这件事」，不管「模型会不会想」。

• 如果回答必须引用一份你自己维护的资料清单，才轮到 RAG；只是想让模型换个语气，那是提示词的事
• 资料规模很小、直接贴进上下文就能装下时，先别急着搭检索链路
• 模型推理能力不够、需要它做多步计算或结构化输出，RAG 帮不上忙，那是提示词或微调的事
• 回答要能指回原文段落、方便人工复核，这类对召回质量比生成质量更敏感

开发者最常拿它做的几类活

从这几类里挑一个先试，别一上来就做全覆盖知识库。先切一个主题、几十份文档，跑通「进料—检索—生成—人工抽查」这条最短链路，能在一周内出可人工复核的结果，才算值得继续投入。

想横向了解链路里的能力选项

如果你还在纠结用哪套嵌入模型或向量数据库，别急着自建。先翻站内的工具目录和资料库，横向看一遍能力边界和接法，再决定是买现成还是自己搭。到 工具目录（/tools） 和 模型资料库（/models） 核对当时的选项。

什么情况下 RAG 不是好选择

要的是模型掌握某种新能力或新文风，RAG 改不了，那是微调或者提示词的活。资料本身没整理过，比如扫描件、表格混排、口径不一的多个版本，先做进料清洗再说，检索层再强也救不了脏数据。

• 要的是实时事实（今天几点、最新一次发布），走工具调用或接口查询比 RAG 更直接
• 团队只有一两个人、问答量很低时，人工翻文档可能比搭一套检索链路更划算
• 法务、医疗等答错代价极高的场景，没有人工复核环节就别直接上 RAG
• 资料本身在持续大改、边界不清，先定好资料口径和版本管理，再谈检索

判断标准就一条：先估「维护成本」和「问的人次」。问的人够多、资料更新够频繁，RAG 才划算。否则它只会变成一个没人维护的索引库。

不适用的情况举一个

一家 5 人小团队只有十几份内部说明，更新频率也不高，这种情况下直接把这十几份文档放进上下文或做成一个搜索页就够用。等文档数量涨上来、问的人变多，再考虑上检索链路，不然前期投入都花在维护索引上了。

从哪个场景开始试最不容易翻车

优先选「答错代价低、有标准答案」的场景，比如内部文档问答，能快速看出召回准不准。别一上来就做全覆盖知识库，先切一个主题、几十份文档，跑通「进料—检索—生成—人工抽查」这条最短链路。

1. 切一个小主题挑几十份文档、一个明确主题，别做全覆盖。验证标准：资料边界清晰，问的问题都能在这批文档里找到答案。
2. 搭最短链路进料、检索、生成、人工抽查四步跑通即可，先不追求花哨的排序和重排。验证标准：能走完一遍，知道哪一步出问题。
3. 攒一份人工对照集把真实被问过的问题攒下来，答得对不对用同一批题前后对比，别凭感觉说变好了。验证标准：有人能独立复核。
4. 决定要不要扩结果稳定、有人愿意用，再扩主题或换更好的检索组件。验证标准：扩之前先看维护成本能不能跟上。

想横向了解检索链路里的能力选项，可以先翻站内的嵌入模型与向量数据库目录，再决定要不要自建。查到具体数字看 模型资料库（/models），选型对比看 工具目录（/tools）。

RAG 管的是「模型知不知道这件事」，不管「模型会不会想」；先判断问题属于哪一类，再决定要不要搭检索。