很多人搭 RAG 时默认「一个对话模型就够了」，结果召回一堆不相关内容、答非所问、引用对不上号，回头查才发现是中间某一环压根没配模型，或者配了但职责搞混了。这篇按 RAG 的链路顺序把涉及的模型类型逐类拆开：每类负责什么、什么场景可以省掉、出问题先查哪一类，最后给一份上线前的自查清单。
很多人搭 RAG 时的第一反应是「选一个对话模型就够了」，结果上线后发现召回一堆不相关内容、答非所问、引用还对不上号。回头排查才发现，不是模型不行，而是中间某一环压根没配模型，或者同一环上塞了两个职责重叠的模型，互相打架。
RAG 本质上是把「查得准」和「答得好」拆给不同模型干的流水线活儿。按链路顺序粗分三段：进料阶段负责切分与向量化，检索阶段负责召回与重排，生成阶段负责组织答案与引用。哪一环缺失，症状完全不同：召回不准多半出在检索段，胡编乱造多半出在生成段，答得对但说不清出处往往又是生成段的引用约束没做。下面逐类拆开讲。
先按链路认清：RAG 不是「一个模型」
把 RAG 当成一个模型来选，是新手最容易走的弯路。它其实是分工制：切分和向量化交给嵌入模型，粗排召回靠向量检索，精排再靠重排模型，最后组织语言交给生成模型。每一环的输入输出格式都不一样，替换其中一环时，上下游的接口约定要一起改。
- 进料阶段
- 把原始文档切块并转成向量，决定库里有什么可以被查到
- 检索阶段
- 用向量召回候选片段，再用重排筛出最相关的少数几条
- 生成阶段
- 把问题和片段拼成提示，输出答案并标注来源
什么情况下可以不套全链路？单文档、一次性问答的极简场景，比如给一份合同做临时问答，直接把全文塞进长上下文比搭一套检索便宜得多。判断标准很简单：语料能整体塞进上下文窗口，就不需要检索段。硬凑全链路只会增加维护成本。想知道自己是否已经踩进「过度设计」，可以去 /guides 看有没有对得上的排查思路。
嵌入模型：把文本变成能比距离的向量
嵌入模型的职责只有一件事：把切片和用户问题映射到同一个向量空间，让语义相近的内容在距离上能靠得近。它不生成答案，也不做排序，只负责把文本变成能算距离的数字。这一环配错，后面再好的生成模型也救不回来。
- 语言覆盖：中文语料是否吃得动，别拿只擅长英文的模型硬套中文资料
- 可接受的最长输入长度：切片超过模型上限会被截断，信息就丢了
- 向量维度与存储成本：维度越高，索引占用的存储越大，检索也越慢
- 是否支持本地部署：有数据不外传要求的场景，这一条直接决定候选池
排查顺序也很固定：召回全是无关内容，先怀疑嵌入模型与语料语言是否匹配，再怀疑切片粒度是不是切碎了上下文，最后才看检索参数。具体有哪些嵌入模型可选、各自维度多少，到 /embeddings 核对当时的清单，别照搬别人的选型结论。
重排模型：给召回结果重新排个序
向量召回擅长的是「快速捞一大批」，不太擅长精细判断谁更贴题。重排模型的作用就是把这批候选按与问题的相关度重新打分，只留靠前的几条喂给生成模型。它和嵌入模型的分工不能互相替代：一个管捞得广，一个管挑得准。
| 情况 | 建议 | 原因 |
|---|---|---|
| 候选噪声大、答案常被无关片段带跑 | 加重排 | 粗排捞回的噪声需要二次过滤 |
| 语料干净、问题指向明确 | 可以先不加 | 重排带来的收益不明显，反而增加延迟 |
| 需要严格控制上下文长度成本 | 加重排 | 只把少数高相关片段送进生成，少塞无用内容 |
| 对响应延迟极度敏感 | 先量基线再决定 | 重排会增加一次模型调用，延迟和成本都会上升 |
代价要说清楚：重排是额外一次模型调用，延迟和调用成本都会上升。上线前先量一遍不加重排时的基线，再对比加上之后的答案命中情况，用数据决定，别凭感觉。怎么测延迟和吞吐，可以到 /tools/speed-test 看具体方法，具体数字以当时页面为准。
生成模型：负责组织答案与引用
生成模型是链路里唯一对用户开口的那个，职责是把检索到的片段和用户问题拼成提示，输出答案并标出来源。注意它不负责「找」，只负责「说」。把找资料的活儿压给生成模型，等于让它靠记忆瞎猜，幻觉就是这么来的。
它和普通对话调用的差别在于约束：必须让它只用给定材料回答，材料不够就明说「没查到」，而不是编一个像模像样的答案。这条约束做不做，直接决定检索段的工作有没有白费。
- 长上下文承载能力：要一次塞进多条片段，窗口太小会截断关键证据
- 指令遵循稳定性：能不能稳定遵守「只依据材料回答」的约束
- 结构化输出：需要前端展示引用来源时，能否稳定吐出可解析的格式
- 成本与延迟的平衡：只做摘要式问答，中等档位往往够用；要复杂推理再往上选
生成段的成本占比通常最高，具体各家模型的价格区间和上下文长度，到 /price-watch 核对当时的数字，别用半年前的印象做预算。
容易被忽略的辅助模型
除了上面四类，链路上还有几个位置可以放模型，但都不是必须的。它们的共同点是：先用规则或提示词顶替，观察到效果瓶颈再单独上模型，别一上来就全铺开，否则链路越长越难定位问题。
- 查询改写与扩写把口语化问题转成利于检索的表述，多轮对话里尤其有用，能补上省略的指代对象
- 意图路由判断这次请求要不要走检索，避免用户只是打招呼也去查一遍库，白白烧调用
- 结果校验对生成答案和检索片段做一次一致性检查，发现引用对不上就回退重答
- 验证方式关掉某一环跑同一批问题，看答案命中率变化，再决定是否保留这一环
判断辅助环节要不要上，标准不是「别人有我也要有」，而是「关掉它之后，同一批问题里明显答错的占比是否上升」。如果差距看不出来，就先别留，链路越短越好排查。谁家模型适合放在哪个环节，可以参考 /rankings 上的分类，但那只是参考，还是要拿自己的语料跑一遍。
下一步拿一段真实语料，把嵌入、重排、生成三段分别单独替换一次，记录每次答案命中情况的变化，就能看出你自己这套链路里哪一环是短板，比看别人的选型清单有用得多。→常见问题
RAG 里最少需要几个模型才能跑起来？
最低能跑的是两个：一个嵌入模型负责检索，一个生成模型负责回答。重排、查询改写这些属于提效项，可以后加。但如果只用一个模型既做嵌入又做生成，通常两边都不讨好，不建议省到这种程度。
嵌入模型和重排模型能不能只留一个？
不能互相替代。嵌入模型要提前把全部语料算成向量，是离线的、批量的；重排模型只在每次查询时对少量候选打分，是在线的。留嵌入不留重排，只是召回粗一点；反过来则根本没有可检索的索引。
换了生成模型，检索部分要不要跟着换？
一般不用，检索段和生成段是解耦的，换生成模型不影响已有索引。但换嵌入模型就必须重建索引，因为没有向量就没法检索。换之前先确认新模型支持的最长输入长度是否能覆盖你现有的切片长度。
