向量模型和大语言模型的区别

很多人把嵌入模型当成「小号大模型」，结果在搭知识库时发现它不回答问题、只会返回一串数字，调参也不知道从哪下手。这篇把两类模型的分工拆开：谁负责把文本变成可比对的向量，谁负责读上下文写答案，中间怎么接、怎么换、出问题先查哪一环。适合正在做 RAG、检索或语义搜索，需要判断「这个活该用哪种模型」的开发者。

很多人第一次接触嵌入模型，是被它那串浮点数劝退的：输入一句话，返回几百个看不出规律的数字，既不回答也不解释。于是下意识把它当成「小号大模型」，结果搭知识库时发现方向全错了。这两类模型压根干的不是一件事：一个负责把文本变成能比大小的向量，一个负责读上下文写答案。

这篇不重复各自的概念定义，而是把一次检索生成请求拆成环节，告诉你每个环节该派谁上场、参数该盯哪几个、出问题时先查哪一段。适合正在做 RAG、语义搜索或文档问答，拿不准「这个活该用哪种模型」的开发者。

先把两类模型各自的活说清楚

嵌入模型的输入是文本，输出是定长向量，它只做「表示」，本身不产生任何自然语言。它的价值在于让语义相近的文本在向量空间里挨得近，方便算相似度。大语言模型的输入是上下文，输出是 token 序列，它做「生成」，负责把信息组织成人能读的句子。

嵌入模型

文本进、向量出，用来比相似度、排顺序，不生成句子

大语言模型

上下文进、文本出，用来写答案、改格式、做推理

判断口诀

要「像不像、排不排前」找嵌入模型；要「写不写、答不答」找大语言模型

两者的输入输出结构不同，不能互相替代，更不能直接拿嵌入模型的输出当答案喂回去。什么情况下这条不适用？当你的任务只是「把已有的原文挑出来给人看」，不需要生成新句子时，整个链路可以只保留嵌入模型，不接生成侧，这时候硬塞一个大语言模型纯属浪费。

一次检索生成请求里，它们分别在哪个环节

把一次典型请求拆开看，两类模型出场的时机完全不重叠。写库阶段，文档切片后交给嵌入模型算向量，存进向量库，这一步大语言模型不参与；查询阶段，用户问题同样过嵌入模型算向量，做相似度召回，拿到若干候选片段；生成阶段，才把召回片段拼进提示词，交给大语言模型组织答案。

1. 第一步 切片入库把文档切成合适大小的块，逐块调用嵌入模型算向量写入向量库。验证方法是随机取几条，看同一段文本重复算出来的向量是否稳定。
2. 第二步 问题转向量用户问题走同一个嵌入模型算向量，注意这里必须和入库用的是同一个模型、同一套归一化口径，否则相似度没有可比性。
3. 第三步 相似度召回用问题的向量去向量库检索，取 Top-K 个候选片段。验证方法是把召回结果打印出来，人眼看是否真跟问题相关。
4. 第四步 拼提示词生成把候选片段填进提示词模板，交给大语言模型出答案。验证方法是先确认片段真的进了上下文，再评价答案好坏。

这条链路里任何一段掉链子，用户看到的都是「答得不对」，所以排障必须分段定位，不能一上来就怪生成模型。一个简单的验证手段：把召回片段单独打印出来看一遍，如果片段本身就不对，换再强的生成模型也救不回来。

向量这一侧的参数：维度、距离度量、归一化

先明确一个判断标准：维度决定存储和检索开销，不是越高越准。更高的维度可能带来更细的区分度，也可能只是让计算更贵、效果没变化。评估维度时应该拿自己的语料测召回命中，而不是看别人说谁更高级。

距离度量这块特别容易出事：不同度量算出来的排序可能完全不同，混用会让检索结果整体跑偏。接之前去站内模型资料库核对每个嵌入模型推荐的度量方式，别靠猜。另外，换嵌入模型往往意味着整库重算，选型前先确认自己能不能承受这次重跑。

什么情况下不必硬堆向量？当你的语料以短问句为主、领域词又特别偏时，通用嵌入模型可能还不如关键词召回那一�路管用，这时候考虑做混合检索，而不是一味换更大的嵌入模型。

生成这一侧的参数：上下文、切片大小、输出格式

召回片段塞多长，受大语言模型的上下文限制。切片太大，一个片段就占掉大量窗口，能塞进去的候选条数变少；切片太小，单条片段缺上下文，模型拼不出完整意思。切片策略要和召回条数一起调，不能单独改一个。

• 切片大小和召回条数是联动参数，改一个就要重测另一个
• 要求返回 JSON 等固定结构属于生成侧的事，用提示词或结构化输出字段约束，跟嵌入模型无关
• 结构化输出的稳定性要单独测，不同模型对格式约束的服从度不一样
• 生成侧换了模型，提示词和结构约束都要重新回归，别假设行为不变
• 上下文没塞满不代表更好，关键看召回内容是否覆盖了回答问题所需的信息

有一个常见误解：以为调大召回条数一定更好。实际上塞太多不相关的片段会稀释关键信息，还可能让模型被无关内容带偏。合理的做法是先在评测集上试几档条数，看准确率的变化曲线再定。

分工错位长什么样：常见症状对照

下面这张对照表可以当排障顺序用：先按症状找到最可能出问题的那一侧，再动手，不要一上来就换模型。

有一个判断边界值得记住：如果召回片段本身就对，答案还是错，问题在生成侧；如果片段本身就不对，改提示词是白费力气。分段定位能省下大量试错时间。另外，新旧向量混存是最隐蔽的事故，换模型后一定要确认整库重算过。

选型顺序：先定检索侧还是先定生成侧

建议先定嵌入模型和向量库，再挑生成模型。原因是嵌入模型决定了入库成本和后续能不能平滑替换——它一换，整库向量就得重算；而生成侧换模型的代价小得多，改个配置、回归一遍提示词就行。

1. 先筛嵌入模型看语种覆盖、维度、是否支持批量调用、能不能本地跑。排行榜只作参考，务必用你自己的语料测一遍召回命中。
2. 再定向量库根据数据量、是否需要过滤条件、是否要混合检索来选，同时确认换嵌入模型时重建索引的成本。
3. 然后挑生成模型按任务分开挑，看上下文长度、结构化输出稳定性、限流情况和调用成本，不必一个模型打天下。
4. 最后搭小评测用一组典型问题固定住召回条数，分别只换检索侧和只换生成侧跑两轮，量化对比。

小团队起步的务实做法：先用一套通用嵌入模型加通用对话模型把链路跑通，别一上来就追求每个环节都最优。等线上暴露出具体问题，再按漏召回和答不准的案例分别替换对应那一侧，这样每一步都有明确的验证目标。

小评测怎么搭：验证分工是否合理

评测不用做得很大，关键是能把「检索问题」和「生成问题」分开。准备一组带标准答案的问题，固定其他变量，每次只动一个环节，看指标往哪边变。

• 固定召回条数，只换嵌入模型跑一遍，看召回命中率变化
• 固定嵌入模型，只换生成模型或提示词跑一遍，看答案准确率和格式合规率变化
• 每条记录召回片段，答案错时先看片段对不对，直接分出是哪一侧的问题
• 用例覆盖几类典型问题即可，不用追求数量，放版本库里持续跑
• 换模型或改切片策略前先跑一次基线，避免改动后说不清是哪个变化带来的效果

记录召回片段这个动作特别值：它让排障从「猜」变成「看」。答案错的时候，翻一下当时喂进去的片段，片段对就是生成侧没组织好，片段错就是检索侧没找对。评测集不大也能起作用，关键是长期留存和可重复。

接进生产要盯的几个点

两类模型在调用特征上差别很大：嵌入调用通常是批量、离线为主，大语言模型调用是高频在线。把它们套同一套超时、重试、并发参数，往往一边不够用一边过度保护。

日志至少把两类调用的耗时和失败原因分开记，否则排障时根本看不出是哪一段慢、哪一段错。向量库和嵌入模型版本要绑定记录，换模型不换库、换库不换模型都容易留下脏数据，后面很难查。

至于具体该选哪家、当时的调用成本是多少，这些数字会变，别按记忆里的印象做决策，直接到站内页面核对当前数据更稳妥。