Embedding模型与对话大模型区别

很多人搭 RAG 时把两个模型混着看：以为对话模型够强就不用 embedding，或者拿 embedding 模型去回答用户问题。结果要么检索出来的片段答非所问，要么生成的答案凭空编。这篇按职责把两类模型分开讲，给一套选型和排查的顺序。

很多人搭 RAG 时把两类模型混着看：以为对话模型够强就不用 embedding，或者拿 embedding 模型去回答用户问题。结果要么检索出来的片段答非所问，要么生成的答案凭空编。这两种毛病看着都是「答得不好」，根子却在完全不同的地方，调错方向就白费力气。

这篇按职责把两类模型分开讲，给一套选型和排查的顺序。核心就一句：一个管找，一个管说，中间靠检索结果对接。先把这条线理顺，后面选模型、调参数、排故障才有章法。

先把两边的活分清楚：一个管找，一个管说

向量化模型只做一件事：把文本压成一串数字，判断两段话语义像不像。它不生成任何文字，也不理解你的问题本身，只是把问题和文档都变成同一种坐标系里的点，然后算距离。对话大模型负责读检索到的片段、组织答案，但它不擅长从海量文档里精确定位，靠它硬扛检索一定漏。

向量化模型

输入一段文本，输出一个向量；用途是算相似度、出候选列表

对话大模型

输入问题和材料，输出一段人话回答；用途是组织语言、归纳、改写

重排模型

对召回的候选片段再打一次分，把最相关的往前提，可选但常有用

• 任务输出是相似度分数或候选列表，用 embedding；输出是一段人话回答，用对话模型
• 对话模型再强也不能替你建索引，它前面必须有人把材料喂进去
• 文档量很少（几十段）时，关键词匹配或直接把全文塞进上下文可能更省事，不一定非上向量
• 需要跨语言、同义改写也能召回时，向量检索的优势才明显；纯编号、专有名词查询关键词反而更准

一条 RAG 链路里各自站在哪一步

离线建库阶段，切块后用 embedding 模型逐块向量化，写进向量库。这一步跟对话模型完全无关，换对话模型不用重建索引，反过来换 embedding 就必须全量重建。在线问答阶段，用户问题用同一个 embedding 模型向量化，召回若干片段，可选再过一个重排模型精排，最后交给对话模型生成。

1. 定切块规则按段落或固定长度切，决定是否重叠、是否加标题前缀；把规则写进配置，别散在代码里
2. 建库并抽样验证向量化入库后随机抽几段原始文本，人工看切块有无切断语义；这是后面所有效果的地基
3. 用同一模型向量化问题查询端必须与建库端同一个 embedding 模型，配置项复用同一个值，防止被手改
4. 召回后人工看片段先不接生成，把前几条召回结果打印出来看相关性，跑通了再接对话模型

一个关键约束常被忽略：建库和查询必须用同一个 embedding 模型和同一套切块规则。中途换模型会导致新旧向量不在一个空间里，相似度算出来没有意义，而且不会报错，只会悄悄变差。切块大小、是否重叠、要不要加标题前缀，这些工程参数对召回质量的影响往往比换模型还大，先固定下来再对比。

选型清单：两边分别看什么指标

两边要看的指标没有重叠，别用一个榜去推另一个。embedding 侧关心语言支持、单块最长能吃多少字、维度带来的存储和检索开销、是否需要配重排；对话模型侧关心上下文窗口能否装下多个召回片段、对长材料的引用忠实度、单位成本。具体维度与候选清单到 /embeddings 核对当时的数字。

• 只换对话模型不动索引，跑一遍对照
• 只换 embedding 不换生成端，再跑一遍对照
• 两边同时换，最后跑一遍；三段结果放一起才知道瓶颈在哪一端
• 不要用对话模型的排行榜去推 embedding 的好坏，两个榜的评测任务完全不同

答不好时怎么排查：先分清是找不到还是说错

答得不好时，先别急着换模型。把召回的原文片段打印出来人工看：片段本来就答非所问，问题在切块或 embedding，换对话模型没用；片段里答案明明在、模型还是答错或胡编，问题在提示词、片段顺序或上下文被截断，这时才该调对话端。两边都没问题但答案风格不对，属于提示与格式约束的范畴，优先级排在检索之后。

排查顺序固定为：切块 → 召回结果 → 重排 → 生成。跳步调试最容易白折腾，比如召回全是垃圾却一直在改提示词。每一步都拿同一批问题跑，记录改动前后的差异，不然调到最后自己都记不清哪个改动起了作用。

检索决定上限，生成决定表达。上限没到，改表达等于白改。