嵌入式模型和对话模型区别

做 RAG 的人最容易卡在一个地方：检索那一环和生成那一环，用的是完全两种模型，但很多选型文章把它们放在一张表里比。结果要么拿对话模型去算相似度，要么指望嵌入模型回答问题。这篇把两类模型的职责、输出形态、调用方式和验收口径分开讲一遍，给你一套照着自己项目对号入座的判断顺序。

做 RAG 最容易卡住的地方，其实是检索那一环和生成那一环用的是两种完全不同的模型，但很多选型文章把它们塞进一张表里比参数、比价格。结果就是有人拿对话模型去算相似度，有人指望嵌入模型回答问题，钱花了活没干成。把这两类模型的职责、输出形态、调用方式和验收口径分开看一遍，再照着自己项目的链路对号入座，选型会清爽很多。

先说结论方向：嵌入模型负责把文字变成一串坐标，专门干排序、聚类、去重、算相似度这类活；对话模型负责吃上下文吐文字，专门干回答、总结、按格式输出这类活。一个不说话，一个不排序，硬让它们互换，要么拿不到结果，要么成本和延迟都失控。

两类模型到底各干哪件事

嵌入模型接收一段文字，输出一个固定长度的向量，这个向量本身没有可读语义，它的价值在于「两段文字变成两个点之后，距离近不近」。对话模型接收一段拼接好的上下文，输出下一段文字，它的价值在于「把已有信息重组成人话」。RAG 链路里，前者管「哪几段最像问题」，后者管「把这几段拼成答案」。

• 要排序、要聚类、要去重、要算相似度，找嵌入模型
• 要回答、要总结、要按指定格式输出、要多轮追问，找对话模型
• 同一段文字，嵌入模型和对话模型的输入输出都不通用，别想着一次调用两用

为什么不能互相替代

嵌入模型的向量没有语义可读性，你没法让它「顺便回答一句」，硬把它当生成用只会拿到一坨无意义的数字。反过来，对话模型确实能算文本相似度，但每比一次都要拼提示词、跑一次完整前向，成本和延迟远高于一次向量计算，量一上来就撑不住。

还有一个坑是调用方式混用。嵌入模型一般一次能批量塞很多段文字进去算向量，接口形态和对话模型那种一问一答差别很大。如果你的封装把两者塞进同一个客户端类里，参数一多就很容易串味，后面排查会很难受。

选嵌入模型时该看哪几项

先看语种覆盖。中文知识库别直接套英文榜上的高分模型，效果经常对不上。站内 /embeddings 和 /ai-rankings 能横向翻一遍，但记住榜单题目和你的语料往往不是一回事。再看向量维度和最大输入长度，维度高不一定更好，存储和检索都会变贵，切块长度也要跟模型能吃的长度对齐，超了会被截断。

1. 定语种与场景确认你的语料以中文为主还是中英混排，再决定候选范围，别一上来就按总榜从上往下挑。
2. 对齐切块长度看模型的最大输入长度，反推你的文档切块该切多大，切太长会被截断，切太短会丢上下文。
3. 小样本实测召回拿你自己语料里的真实问句做几十条小样本，测召回率，别只看榜单名次。
4. 决定要不要加重排召回靠嵌入模型，最终排序常常再补一个重排模型救长尾，具体取舍站内有专文讲，这里不重复研究。

阈值判断很关键：小样本上召回想明显偏低，先怀疑切块和语种，而不是急着换更大的模型。换模型之前先把这两项调一遍，往往比直接升级划算。

选对话模型时该看哪几项

第一眼看上下文窗口够不够塞进「检索回的片段 + 对话历史 + 系统提示」，长文档场景这一步最容易翻车，去 /models 和 /ai-dict/category/basics 核对口径。第二眼看输出格式稳定性，RAG 里常要求模型按固定结构回答或带引用标注，格式飘的下游解析会炸。

• 上下文窗口要覆盖检索片段加历史加系统提示的总和
• 输出格式稳不稳定，能不能稳定带引用标注
• 单价与限流，RAG 每次提问都带检索结果进去，输入 token 比普通聊天高不少
• 是否支持你需要的工具调用或结构化输出

成本这块别凭感觉估，先去 /official-api 和 /tools/token-price-calculator 按你的平均片段长度和提问频次算一笔当时的数字。另外，如果你的答案几乎完全来自检索片段、不太需要改写，用抽取式办法直接回原文也能跑，未必非要接对话模型。

落到自己项目上的排查顺序

把链路拆成三段看：文档入库时调嵌入模型做向量化，提问时先把问题嵌入再去检索，最后才把片段交给对话模型。这三条调用最好别复用同一个客户端封装，参数和错误处理都不一样。压测也要分开做，嵌入模型看每秒能处理多少段、失败重试怎么算，对话模型看首字延迟和输出长度。

最后一步是留退路。两类模型都要能换，尤其是入库那一步，一旦换了嵌入模型，旧向量通常要重算一遍，这个成本提前记进计划，别等上线了才想起来。检索和生成两个指标也分开验收，混在一起看会互相掩盖问题。

嵌入模型负责找得着，对话模型负责说得好，把这两件事混在一张表里选，就是给自己埋雷。