做 RAG 的人常卡在同一个地方：向量库那一侧该用嵌入模型，回答那一侧该用对话模型，但两边的接口长得像、都是「给一段文字返回一段东西」，一不小心就拿对话模型去算相似度，或者指望嵌入模型能顺着上下文回答问题。这篇把两者的分工、判断标准和落地步骤拆开讲，最后给一套出问题时的排查顺序。
做 RAG 的人经常卡在同一个地方：向量库那一层要用嵌入模型，生成回答那一层要用对话模型，但两边的接口长得几乎一样，都是「喂一段文字、返回一段东西」。结果就出现两种典型翻车：拿对话模型去算相似度，或者指望嵌入模型能顺着上下文回答问题。这篇只讲一件事——这两类模型到底哪里不一样，以及你该按什么顺序做判断。
下面按分工、输入输出规则、选型动作、要不要加重排、出问题先查哪一步这个顺序展开。每一节都尽量给能直接落地的判断标准和动作，不给「看情况」这种废话。
先把两种模型的分工摆清楚
嵌入模型的输出是一串固定长度的向量，它只负责把文本压成坐标，本身不会生成任何字。对话模型的输出是 token 序列，负责组织语言、做推理、顺着上下文接话。RAG 里嵌入模型管「找得到」，对话模型管「答得好」，这是流水线上的两道工序，不是谁替代谁。
- 判断信号一：下一步要算余弦相似度、要写进向量库，用嵌入模型；下一步要把结果拼成提示词给用户看，用对话模型
- 判断信号二：需要模型「说人话」「按格式输出」「结合上下文推理」，对话模型；只需要模型「把语义变成可比较的数字」，嵌入模型
- 判断信号三：同一段文本编码两次结果应该基本一致（模型版本不变的前提下），对话模型同一句问两次结果可能不同，这是正常现象
- 不适用的情况：纯关键词检索够用，或者语料本身只有几十条、直接塞进上下文就能解决，这时候上嵌入模型是浪费
- 嵌入模型
- 输入文本，输出定长向量，不生成文字，用于召回和相似度计算
- 对话模型
- 输入提示词（可含多轮历史），输出 token 序列，用于生成和推理
- RAG
- 检索增强生成，把「找资料」和「写回答」拆成两步做的整体流程
输入长度、批量和计费口径都不一样
嵌入模型一般有单条文本长度上限，超长要先切片再分别向量化；对话模型按上下文窗口算，长文档可以整段喂，但会消耗大量 token。另外嵌入模型通常支持一次请求传一批文本，单位成本通常比对话模型低不少，具体数字到 /official-api 和 /inference 核对当时的口径，别拿印象里的数字做预算。
| 对比项 | 嵌入模型 | 对话模型 |
|---|---|---|
| 输出内容 | 定长向量 | token 序列（自然语言） |
| 是否多轮 | 基本不支持 | 依赖历史消息，同一句在不同上下文结果不同 |
| 输入长度 | 有单条上限，超长需切片 | 按上下文窗口算，长文档可整段喂 |
| 批量请求 | 通常支持一次传多条文本 | 一般一条请求一组消息 |
| 典型用途 | 召回、聚类、去重、相似度 | 生成回答、抽取、改写、对话 |
落到动作上很简单：给嵌入模型准备的是干净、长度受控的切片文本；给对话模型准备的是带指令和检索结果的提示词。两者的数据预处理流程要拆开写，不要指望一套清洗逻辑同时喂给两边。清洗规则混用，通常先坏的是召回质量，而你会误以为是模型不行。
RAG 场景下怎么给两边各自选
嵌入模型看四件事：中文语义效果、向量维度、单条长度上限、能不能本地跑。维度和长度上限直接决定你的向量库存储成本和切片策略，选之前必须先把这两个参数确定下来，否则后面迁移代价很大。对话模型看的则是长上下文、指令遵循和成本，因为 RAG 的提示词里要塞检索片段，上下文窗口小的模型会被迫砍掉召回内容。
- 定切片策略先按业务文档的真实结构（段落、标题、表格）定切片粒度和重叠长度，别先选模型再回头迁就切片
- 挑嵌入模型拿你库里真实的中文样本跑一遍召回，看目标片段能否进前几名，到 /embeddings 对照当时可用的条目挑
- 挑对话模型把召回片段和问题拼成提示词，测它能否在长上下文里抓住关键信息、能否按你要的格式输出
- 核对成本与额度到 /ai-nav/category/ai-api 看两边的额度与计费口径，确认向量化（一次性）和问答（每次请求）的用量结构你能接受
什么时候要在两者中间加一层重排
只用嵌入模型召回时，靠的是向量距离，语义相近但答案不对的片段很容易被排到前面。加一层重排模型，对候选集重新排序，能明显改善送进对话模型的上下文质量。判断信号有两个：召回的前几条里经常混有不相关内容；或者答案明明在库里，却没被召回进上下文。
加重排的代价是多一次调用、多一段延迟，所以候选数量要控制住，别把整个库都丢进去重排，一般只对召回的前若干条做重排。是否值得加，取决于你的延迟预算和准确率要求，两者 trade-off 得自己算。到 /embeddings 看当前有哪些嵌入与重排相关的模型条目，再决定加不加。
效果不对时的排查顺序
RAG 效果差，大家习惯第一反应是换对话模型，但按下面的顺序查，通常能更快找到真正的原因，也省掉重复花钱试模型的力气。
- 先验证嵌入模型拿两句你确定语义相同的话算相似度，看分数分布是否合理；这一步能排除掉大部分「模型选错」的怀疑
- 再查切片切得太碎会丢上下文，切得太长会被截断，两种都会让召回变差，切片策略要单独调并单独评估
- 然后才看对话模型把检索到的原文直接贴进提示词，看模型能不能答对；原文在它还是答错，才是提示词或模型的问题
- 最后看计费和限流向量化是一次性成本、问答是每次请求都花钱，两边用量结构不同，别用同一个预算口径去评估
先确认是「找错了」还是「答歪了」，再决定动哪一侧的模型。下一步把你这边的切片策略和嵌入模型对照表拉出来，再到站内模型资料库核对你打算用的嵌入与对话模型当时的参数和报价，避免拍脑袋选型。→
常见问题
嵌入模型能不能直接拿来回答问题？
基本不行。嵌入模型的输出是一串数字向量，它的能力是判断两段文本像不像，不是生成句子。你拿它去对话，得到的只会是向量而不是文字。要做问答，向量只负责把相关片段捞出来，真正组织语言的是对话模型。
RAG 里是不是对话模型越强，整体效果就越好？
不一定。检索没召回正确答案时，再强的对话模型也只能靠猜，这时候它反而更容易编。先确认召回质量，再看对话模型。很多看起来像「模型不行」的问题，实际是切片和嵌入模型不匹配造成的。
这两种模型必须用同一家的吗？
不必须。嵌入模型负责编码、对话模型负责生成，两者通过向量库和提示词连接，只要接口能对上就能混用。选的时候各自按自己的指标挑：嵌入模型看检索命中率，对话模型看回答质量和成本，具体报价到 /official-api 对照。
