你大概听过「RAG 能治幻觉」这句话，真到自己上手时却发现名词满天飞：有人说 RAG 是个架构，有人说 RAG 是种模型，还有人把向量库和 RAG 混着叫。这篇不堆术语，先把 RAG 到底分哪几类、检索增强在哪一步起作用讲明白，再给你一份动手前要定的清单，让你看完能判断自己该从哪种做法起步、什么情况压根不该上 RAG。
你大概听过「RAG 能治幻觉」这句话，真到自己上手时却发现名词满天飞：有人说 RAG 是个架构，有人说 RAG 是种模型，还有人把向量库和 RAG 混着叫。这篇不堆术语，先把 RAG 到底分哪几类、检索增强在哪一步起作用讲明白。
后面再给你一份动手前要定的清单，让你看完能判断自己该从哪种做法起步、什么情况压根不该上 RAG。凡是涉及价格、跑分这类会变的数字，正文不写死，一律让你去站内对应页面核对当时的数字。
先说清「RAG 模型」这个词其实指三样东西
很多入门读者卡在第一步：到底什么算 RAG 模型。把这三类角色拆开看，跟厂商聊天时就不容易被绕进去。判断标准很简单，对方一提「RAG 模型」，先问清楚他指的是哪一类。
- RAG 本身是一套流程：把资料切块、向量化、检索、拼进提示词，再交给大模型生成，不是某个单独训练出来的模型
- 日常说的「RAG 模型」通常指三类角色：负责把文字转向量的嵌入模型、负责排序的重排模型、负责最终作答的生成模型，三者可以来自不同厂商
- 第三类是「带检索能力的整体方案」，比如把检索封装成工具的 Agent 式 RAG，这类更该叫架构而不是模型
- 判断标准：如果对方说「我们训了个 RAG 模型」，先问清楚是指微调过的生成模型，还是只是把检索串起来
- 嵌入模型
- 把文本变成一串数字向量，用来算相似度，检索的第一步靠它
- 重排模型
- 对召回的候选片段重新打分排序，决定哪几条真正进上下文
- 生成模型
- 拿到拼好的上下文后作答的那一个，也是最常被单独称为「模型」的角色
检索增强到底在哪一步帮上忙
生成模型的知识边界停在训练数据那一刻，RAG 的作用是在提问时把相关资料临时塞进上下文，让回答有据可依。完整链路分四段，出问题时按这个顺序往回查。
- 进料把原始文档清洗、切块。切得太碎会丢上下文，切得太大又会稀释检索精度，先拿少量文档试出合适粒度
- 入库用嵌入模型把每块文本转成向量存进向量库，这一步要确认增量更新怎么做，别只能全量重建
- 召回按用户问题检索相似片段，可选加一层重排。召回质量差时，先看这一步的候选是不是压根没包含正确答案
- 生成把召回片段拼进提示词交模型作答。如果候选里明明有正确内容却答错，问题多半在拼接方式或提示词，而不是模型
不适用的情况也说清楚：问题答案本身就在模型常识里，比如写代码、做翻译，上 RAG 只会增加延迟和成本，这类场景别硬套。
几种常见 RAG 做法的对照
做法没有绝对高下，只有适不适合你当前的资料和问题类型。下面这张表帮你先对号入座，再决定加多少复杂度。
| 做法 | 适合什么场景 | 主要代价 |
|---|---|---|
| 朴素 RAG | 资料量小、问题直接、问法接近原文 | 遇到口语化提问或同义词容易漏召回 |
| 混合检索 RAG | 专有名词、编号、型号多的资料 | 要维护两套召回并统一排序，调参更花时间 |
| Agent 式 RAG | 问题模糊、需要多跳推理或反复换查询词 | 调用次数和延迟都上去了，成本随之增加 |
选型原则：先在朴素 RAG 上跑通并量出基线效果，再按失败样本决定往哪个方向加复杂度，别一上来就堆高级技巧。站内的向量数据库目录和嵌入模型清单可以帮你对一下候选范围，具体条目和当时列出的参数以站内页面为准。
动手前要定下来的几件事
这几件事没定，后面调起来就是盲调。它们跟用哪家模型关系不大，属于先想清楚再动手的部分。
- 定评价方式：准备一批真实问题加期望答案，改一次配置就跑一遍，否则无法判断调整是变好还是变坏
- 定切块策略：按段落还是按固定长度、要不要重叠，都取决于你的文档结构，先拿少量文档试
- 定失败兜底：检索不到内容时是直接说不知道，还是退回纯生成回答，这个策略要在提示词里写死
- 定容量口径：文档量涨上来后，检索延迟和存储成本会一起涨，先估算一遍用量再选库
- 别指望一次配好，RAG 的效果是调出来的，先保证每改一步都能对比
容量和成本相关的具体数字，站内价格追踪和模型资料库会随各家调整更新，直接到 /price-watch 核对当时的数字，别拿旧截图做预算。
什么情况下先别碰 RAG
RAG 不是万能药，下面几类场景先别急着上，不然容易花时间做完发现方向就不对。
- 资料总量很少、直接放进上下文就够用时，检索这一层是多余开销
- 需要模型改变说话风格或输出格式时，该用提示词或微调，不是 RAG 的活
- 数据实时性要求极高、文档每小时都在变的场景，要先解决同步和增量入库，再谈检索质量
- 团队没人维护知识库更新时，RAG 上线后很快会答旧内容，这类情况更适合先做人工整理的 FAQ
判断标准可以简化成一句：检索这一层能不能带来模型自己不知道、又确实需要的信息。能，就值得做；不能，先用更简单的办法。
RAG 解决的是「模型不知道」的问题，不是「模型不听话」的问题；搞混这两类，工具再换也白搭。下一步如果你已经决定要试，先去站内工具目录里把嵌入选型和评测工具列出来，再按上面那张对照表挑一种起步做法，边跑边看当时的实测数据。→
常见问题
RAG 模型和普通大模型是同一个东西吗？
不是。普通大模型指生成模型本身，RAG 是在它外面套一层检索流程。生成模型没变，变的是每次提问前先塞进去一段相关资料。所以换生成模型不影响检索那部分的选型，反过来也一样。
入门应该先做哪一步？
先把一小批文档切块入库、能检索出东西，再把它拼进提示词让模型回答，这条最小链路跑通比什么都重要。跑通之后拿十几个真实问题测一遍，看错在哪一段，再决定是升级切块、换嵌入模型还是加重排。
RAG 能彻底解决模型胡说八道吗？
不能，只能降低概率。检索到的内容本身可能有错、可能过期，模型也可能没照着资料说。所以生产环境里通常要求回答附上来源片段，让使用者自己核对，同时保留人工复核环节。
