炒股就看金麒麟分析师研报，权威，专业，及时，全面，助您挖掘潜力主题机会！

（来源：科技行者）

2024年之后，几乎每隔几个月就会有人问同一个问题：现在的大语言模型这么强，是不是可以把公司里那套专门用来做文本相似度、分类、聚类的嵌入模型系统直接扔了，全都换成大模型来做？

这个问题听起来有点奇怪。嵌入模型和大语言模型本来是两条不同的技术路线,前者专门把文字变成一串数字向量，方便机器做相似度计算和分类；后者是能读会写、能推理的通用模型。但现在的大模型确实什么都能干一点,你完全可以把一段文字扔给它，让它输出一个"相似度打分"，或者判断这段评论是正面还是负面。

那问题来了：如果大模型什么都能干，为什么还要保留专门的嵌入模型？

哈佛大学、斯坦福大学和一位独立研究者做了一件挺实在的事情。他们没有停留在"哪个更聪明"这种模糊判断上,而是拉来了十个当红的大语言模型和二十六个嵌入模型，在三十七个任务上正面比拼，同时把每一次调用的真实成本都算得清清楚楚,包括花了多少钱、跑了多快。这篇论文的标题叫《嵌入者的困境：大模型更强，但代价几何》，读完之后你会发现，答案比"谁更强"复杂得多。

先说结论：打了个平手,但这个平手很值得琢磨

两边最强的选手打成了平手。

表现最好的大模型是谷歌的Gemini 3.1 Pro，在这套综合测试上拿了77.6分；表现最好的嵌入模型叫Octen-8B，拿了77.2分。差距只有0.4分，研究者做了统计检验，这个差距完全落在误差范围内，说白了就是没有显著差异。

这本身已经是个挺有意思的信息了。要知道，嵌入模型是专门为这类任务训练出来的，用了对比学习、难负样本挖掘、多阶段蒸馏这些精细工艺；而拿来测试的大模型完全是通用型选手，没有为这些任务做过任何专门训练，就是直接上场应试。一个专业选手和一个业余全能选手打平，这说明大模型的通用能力确实强到了一个新阶段。

但故事到这里才刚刚开始。

如果只看总分，你会觉得这是个可以随便选的局面。可一旦把总分拆开，按照分类、语义相似度、聚类、配对分类、检索这五大类任务分别看，情况完全不一样了。

打分是怎么算出来的：一套叫MTEB(LLM)的新考卷

要理解后面的所有结论，得先弄明白这次考试到底考了什么。

>MTEB：全称Massive Text Embedding Benchmark，一套业内公认的文本嵌入模型评测标准，涵盖多种任务类型，被广泛用来给嵌入模型打分排名。

研究者没有直接套用现成的MTEB全量测试集，而是专门做了一个瘦身版，叫MTEB(LLM)。原因很实际：如果让大模型跑完整套MTEB，光是API调用费用就要花掉数百美元一个模型，而且有些检索任务需要把整个文档库塞进提示词里，如果文档库太大，模型的上下文窗口根本装不下。所以他们从原始任务里抽取了固定的子集，保证语料库小到能塞进提示词，同时保留任务类型的多样性。

这三十七个任务分成五类。分类任务考的是能不能准确判断一段文字属于哪个类别，比如判断一条推特是不是有毒言论，或者用户说的话是要办什么银行业务；语义相似度任务考的是两句话意思有多接近；聚类任务是把一堆文档自动分组；配对分类是判断两句话是不是在说同一件事；检索任务则是给一个问题，从一堆文档里找出最相关的那一篇。

评测的方式也有讲究。嵌入模型走的是传统路子：分类任务用最近邻算法在标注好的训练集里找参照物，相似度任务直接算向量夹角的余弦值，聚类用K-means算法自动分组。大模型则是完全零样本作答,不给任何例子，直接让它根据任务描述输出结构化答案。

>零样本：指模型在没有见过任何该任务具体示例的情况下直接进行预测，全凭任务描述和自身已有知识作答。

这个设置其实模拟了一个非常真实的场景。很多公司想用大模型，恰恰是因为手头没有足够的标注数据来训练一个专门的分类器。这个对比反映的正是这种"缺数据"场景下两条路线的真实差距，而不是在理想条件下比拼理论上限。

分类任务：大模型输了,而且输得不算小

先看最没有悬念的一类:分类。

在这套测试里，最好的嵌入模型SFR-2拿了90.8分，而最好的大模型Gemini 3.1 Pro只有85.2分，差了5.6分。做统计检验后，这个差距是显著的，不是噪音。

差距在细粒度任务上被进一步放大。比如有一个叫Banking77的任务，要把用户的银行业务咨询归到77个具体类别里；还有一个叫MassiveIntent的任务，要在60种意图里选一个。这种任务里，嵌入模型靠着最近邻算法，能够参考成千上万条已经标注好的训练样本，精确地找到"和这句话最像的那些例子属于哪一类"。而大模型只能凭借对标签名称的理解，靠自己的语言直觉去猜。

论文里举了一个特别生动的例子。有个用户问"我怎么才能找到我的卡"（"How do I locate my card?"）。Gemini 3.1 Pro的推理过程是这样的："用户在问怎么定位他们的卡，这说明卡可能丢了或者不见了，这符合'挂失或被盗'这个类别。"于是它判断这是"lost_or_stolen_card"，但标准答案其实是"card_arrival"，也就是查询卡片配送状态。而参数量小得多的Gemini 3 Flash反而蒙对了，因为它没有进行那么深的推理，直接按字面意思理解成了查快递。

这个例子挺打脸的，直觉上你会觉得推理能力越强、想得越深，回答应该越准。但在这种存在歧义、依赖数据集内部约定俗成用法的任务里，过度推理反而会引入错误的联想路径,模型在"想太多"。而嵌入模型靠着海量标注样本做锚点，反而不会被语言上的多重解读带偏。

这就好比你去问一个刚入职的博学新人和一个干了十年的老员工同一个问题："这个客户说要找他的卡，是什么意思？"新人可能引经据典地分析这句话背后可能隐藏的各种含义，想得越多反而越容易把简单问题复杂化；老员工不需要想那么多，他见过一千个类似的咨询，凭经验一眼就知道十有八九是在问快递到哪了。如果没有这种"见过一千个案例"的经验积累，光靠聪明和推理，反而可能被语言的多义性绕进去。

这也解释了为什么研究者专门做了一个"少样本"补充实验：给大模型五个示例，看能不能追平嵌入模型。结果是，在只有两三个类别的简单任务上，给不给例子区别不大；但在Banking77这种77个类别的细粒度任务上，五个例子根本不够用，成绩反而从83.1分暴跌到16.5分,因为提示词里塞了五个例子，模型可能被这几个例子的分布带偏了，判断力反而更差了。这说明想靠"喂几个例子"来弥补数据量差距，在标签空间特别大的场景里基本不现实。

检索任务：风水轮流转，大模型扳回一城

如果说分类是大模型的伤心地，那检索任务就是它彻底翻身的地方。

在检索这一类里，Gemini 3.1 Pro拿到64.5分，最好的嵌入模型只有56.0分，领先了8.5分，这个差距同样是统计显著的。而且Pro不是勉强赢，它在六个检索任务里赢了五个。

要理解这个反差，得先明白传统嵌入模型是怎么做检索的。

>双编码器：一种检索架构，把查询和文档分别独立编码成向量，两者之间没有任何交互，最后只用向量的相似度打分。这种方式的好处是可以提前把所有文档编码好存起来，查询来了只需要做向量比对，速度极快。

双编码器的问题在于，它从头到尾都不知道"查询"和"文档"之间具体在说什么，只是把两段文字各自压缩成一个向量，然后比比谁离得更近。这在语义比较直白的场景下没问题，但一旦任务需要跨文档推理，比如要理解一段复杂的法律条款是否真的回答了用户的具体问题，这种"各自为政"的编码方式就有点力不从心了。

大模型走的是完全不同的路子，研究者管这个叫"语境内全文检索"。简单说，就是把整个文档库塞进提示词里，让大模型像人一样通读全文，一边读一边判断哪篇文档能回答这个问题。

>语境内全文检索：把候选文档全部放进大模型的输入提示词中，让模型直接阅读并判断相关性，而不是先把文字转成向量再比对。

这种方式最直观的好处，就是模型能看到查询和每一篇候选文档的完整关联，可以做真正的阅读理解，而不是简单的向量距离比对。

论文里一个特别典型的案例是法语阅读理解检索任务FQuAD。这个任务需要模型读懂法语段落，找出真正回答了问题的那一段。Pro在这个任务上拿了92.0的高分，最好的嵌入模型只有72.0，这是整套测试里差距最大的一项。

生活中有个类比特别贴切。假设你在图书馆找一本能回答"唐朝为什么会灭亡"的书，双编码器的做法相当于图书管理员看了一眼书名和目录关键词，凭着"这本书讲唐朝，那本书也讲历史"这种粗浅印象给你排个序；而大模型的做法是真的把每本候选书都翻开读一遍，确认里面到底有没有直接回答这个问题的段落。前者快，但可能推荐一本讲唐朝服饰的书给你；后者慢，但真的读懂了内容。如果图书管理员没有翻书而只看书名做判断，很多真正贴题的书就会被错过，这正是双编码器在推理密集型检索任务上系统性偏弱的原因。

不过，检索任务里也有一个大模型输掉的例外,一个叫AILAStatutes的法律法规检索任务。这个任务要把具体案情匹配到相关的法律条文，标准答案通常只有四条精确的法条，但Pro返回了十四条,涵盖了合同法、劳动法、正当程序等各种"看起来相关"的宽泛概念。而排名最好的嵌入模型Octen-8B靠着余弦相似度，给出的是一份窄而精准的候选列表。

这其实揭示了一个有意思的规律。当任务需要的是"广泛联想"，大模型的推理能力是加分项；但当任务需要的是"精准锁定"，这种联想反而变成了噪音。

聚类、语义相似度和配对分类：三家打成平手

除了分类和检索这两个泾渭分明的战场，还有三类任务两边基本打平。

在聚类任务上，最好的嵌入模型SFR-2拿了66.7分，Pro紧随其后拿66.6分；在语义相似度任务上，嵌入模型Qwen3-E-4B以88.8分微弱领先Pro的88.5分；在配对分类任务上，嵌入模型KaLM-12B拿到87.1分，比Pro的83.2分还要高出不少，不过统计检验显示这个差距同样没有达到显著水平。

这三类任务有一个共同的底层逻辑：它们本质上依赖的是几何上的相近性，或者是有标注参照物的匹配，恰好是余弦相似度这套数学工具最擅长的领域。当任务的核心是"这两个东西像不像"，而不是"需要跨文档做复杂推理"时，向量空间里的距离计算已经足够精确了，大模型的额外推理能力在这里派不上太大用场。

论文里也做了一些细致的案例分析，挺有意思的。比如有一对句子讲的是从"穆斯林身份"转变为"伊斯兰主义者身份"，Pro给这对句子打了4.5分（满分5分），但标准答案是5.0分。它的推理是："伊斯兰主义者指的是一种政治意识形态，而伊斯兰教徒是宗教身份的形容词，二者有区别。"这个区分从语言学角度讲得通，但标准答案的标注者把这两个词当成了等价表达。这说明模型有时候太较真了，抓住了一个语言学上站得住脚但和数据集标注惯例不一致的细微差别，反而拉低了和标准答案的一致性。

成本才是真正的分水岭：贵出1431倍是什么概念

如果说前面的分数对比是"打了个平手"，那接下来这一部分，会让"平手"这两个字显得意味深长。

Gemini 3.1Pro跑完一整套MTEB(LLM)测试，花费是154.14美元。而拿了77.2分、几乎跟它并驾齐驱的嵌入模型Octen-8B，跑完同样的测试只花了0.108美元。

算一下倍数，154.14除以0.108，大约是1431倍。

>成本核算方法：论文对大模型用的是各家API的实际计费token数,包括输入、输出，以及"思考过程"消耗的token,乘以对应的公开单价；对嵌入模型则是实测在一块H100显卡上跑满负荷时的吞吐速度，再换算成对应的电费和显卡租赁成本。

也就是说，为了多拿那0.4分，你要多付出三个数量级的成本。这已经不是"精益求精"的性价比问题了，这是"值不值得"的问题。

而且这个1431倍并不是精心挑选出来的极端案例。论文专门做了敏感性分析，换了不同的硬件假设,比如按需付费而不是抢占式实例、用性能较弱的显卡、甚至改用商业化的嵌入API定价,这个倍数在所有场景下都稳定在300倍以上。换句话说，无论你怎么调整假设条件，大模型的成本劣势都是数量级级别的，不是可以靠优化抹平的小差距。

这里边最大的成本黑洞，叫"思考税"。

思考税：大模型为什么这么贵

现在的很多前沿大模型都支持"扩展思考"，也就是在正式给出答案之前，先在内部生成一大段推理过程，业内管这个叫思维链。

>思维链：模型在给出最终答案前，先输出一段逐步推理的文字，模拟人类"想清楚再回答"的过程。这类"思考token"通常和最终答案一样，按照输出的价格计费。

论文的核算发现，这部分"思考"消耗的token，占到了这些大模型总推理成本的28%到81%。有的模型比如Qwen3.6-27B，思考部分甚至占了总成本的81%,换句话说，你花的钱里，五分之四都花在了模型自言自语、内部盘算上，只有五分之一花在了真正吐给你看的答案上。

这就好比你雇了一个律师帮你写一份简单的租房合同。如果这个律师每次动笔之前都要在脑子里把民法典从头到尾默诵一遍，哪怕最后写出来的合同和别的律师一模一样，你付给他的钱有八成都是在为他"默诵民法典"这个过程买单，而不是为最终那份合同的质量买单。如果他真的能靠这套默诵流程写出更靠谱的合同也就算了，问题是，论文接下来揭示的事实是，这种昂贵的"默诵"很多时候根本没提升合同质量。

研究者做了一个"减少思考"的消融实验，专门验证这一点。他们把Gemini 3 Flash的思考强度调到最低档，同时把几个开源模型的思考功能直接在服务端关掉，让生成的思考token数量减少了54%到96%。

结果相当反直觉：在检索任务上，六个测试场景里全部保持或提升了成绩。有个叫PublicHealthQA的公共卫生问答检索任务，思考token减少了94%，但检索得分反而从49.0涨到了66.0，涨了整整17分。研究者猜测，这可能是因为在直接阅读理解就能搞定的任务上，模型"想得太多"反而会对一个本来很直白的相关性判断产生反复摇摆的二次怀疑，就像你原本一眼就能看出这道数学题该怎么解，但非要反复检查、越检查越怀疑自己，最后把简单的判断复杂化了。

而在分类任务上，减少思考带来的变化都在1分以内，基本可以忽略不计。这从侧面印证了前面的发现:分类任务的瓶颈根本不在推理深度，而在有没有足够的标注参照系。

速度差距：同一块显卡上，嵌入模型能快出700多倍

除了花的钱，还有一个更容易被忽略的维度:速度。

研究者把两个能塞进单张H100显卡的开源大模型,Qwen3.6-27B和Qwen3.6-35B-A3B,和多个嵌入模型放在同一块显卡上跑，专门测了每秒能处理多少个token。这样做的好处是排除了API限速这种人为因素的干扰，纯粹比拼硬件层面的处理效率。

结果是，两个开源大模型的吞吐量大约是每秒5400到5900个token，而嵌入模型里最大的那个每秒能处理14700个token,是最慢的LLM的2.5倍；嵌入模型里最小的那个，每秒能处理430万个token,是最慢LLM的736倍。

>推理吞吐量：单位时间内模型能处理的token数量，反映的是硬件利用效率和实际服务能力，数值越高说明同样的硬件能同时服务更多用户或更快完成任务。

这个速度差距背后的原因，其实和模型的底层工作方式直接相关。嵌入模型只需要对输入文本做一次编码，出来就是一个固定长度的向量，是一次性的、并行的计算过程；而大语言模型是自回归生成，也就是一个词一个词往外蹦，每生成一个新词都要把前面所有已经生成的内容重新过一遍模型，这个过程本质上是串行的，没法像编码那样一步到位。

想象一下拍照和写信的区别。给你一张照片，相机咔嚓一下就把整个画面全部记录下来了，这是一次性完成的；但如果让你用文字详细描述这张照片里的每一个细节，你得一个字一个字往下写，写第十个字的时候还得回头看看前九个字写了什么，才能保证语句通顺。嵌入模型干的是拍照的活，大模型干的是写信的活。如果检索系统面对的是百万级、持续增长的文档库，用写信的方式去处理每一个查询，那种排队等待的延迟会随着规模扩大而急剧恶化，这也是为什么论文特别强调，在生产环境的大规模场景下，这个速度差距会限制大模型方案的实际可行性。

更进一步：把检索拆成两段，效果会不会更好

论文里还做了一个特别贴近实际生产场景的实验，叫"先检索再重排"。

这个思路是这样的：先用速度飞快的嵌入模型从海量文档里粗筛出一个几十到上百篇的候选短名单，然后再用一个更精细、更贵的模型对这个短名单做精细排序，决定谁才是真正最相关的那一篇。

>重排序：检索流程里的第二阶段，在第一阶段筛出候选名单之后，用更复杂但也更慢的模型对候选结果重新打分排序，力求把真正最相关的结果排到最前面。

研究者在两套标准检索测试集上验证了这个思路,一套叫BEIR，考察常规的语义检索能力；另一套叫BRIGHT，专门考验需要复杂推理的检索能力。

结果又是那个熟悉的分野。在推理密集的BRIGHT测试集上，用大模型做重排序，能把一个强劲的嵌入模型第一阶段的成绩从22.3分的nDCG指标一路拉到35.1分,提升相当明显。但在语义为主的BEIR测试集上，情况反过来了，单独用一个强嵌入模型做检索反而拿到63.1分，比任何一种加了重排序的组合方案分数都高。

这个发现进一步印证了整篇论文的核心结论:该用推理的地方，推理确实有用；不需要推理的地方，加上推理反而是浪费甚至添乱。

而且这种"先筛后精排"的组合方案，成本比全文本塞进上下文的方式便宜得多。重排一个百篇左右的候选名单，大概花费10到30美元；而把整个语料库塞进提示词直接问，一次就要花154美元。

这就像你想在一个大型商场里找某件特定款式的衣服。你不会真的把整个商场从头到尾逛一遍,那太耗时间了。更合理的做法是先站在商场入口，凭着导购图和大致印象快速锁定几个可能有这件衣服的店铺,这一步靠的是效率；然后再走进这几家店，仔细对比每一件类似款式的衣服，确认到底哪一件才是你要的那款,这一步靠的是细致判断。如果你从一开始就试图靠"仔细看"来逛完整个商场，那速度会慢到没法忍受；但如果你从头到尾只靠"大致印象"筛选，又可能在最后一步错过真正对的那件。分工才是效率和精度都要的答案。

那到底该怎么选：一份务实的分工建议

把所有结果拼在一起，论文给出的建议其实挺清晰，也挺朴素。

对于分类、相似度计算、聚类这些不需要跨文档深度推理的常规任务，嵌入模型应该是默认选择。它们又便宜又快，而且分数往往比大模型还高，没有理由为了追求"用最新最强的模型"而多花上千倍的钱。

对于确实需要理解复杂上下文、进行跨文档推理判断的检索任务，尤其是那种答案藏在细节里、需要真正"读懂"才能找到的场景，大模型或者"嵌入模型加大模型重排序"的组合方案，是值得投入的。

论文还专门画了一张成本与性能的对照图，横轴是每次跑完整套测试的花费，纵轴是得分。图上能看到一条清晰的帕累托前沿,也就是"用最少的钱拿到最高分"的那条边界线。这条线上密密麻麻站满了各种嵌入模型,从最便宜的118M参数小模型，到性能拔尖的Octen-8B,唯独有一个大模型挤上了这条前沿线，就是Gemini 3.1 Pro，它靠着在检索任务上的优势，把这条线往性能更高的方向拉长了一小段，但代价是成本陡然跳升了1431倍。

>帕累托前沿：在多个目标（这里是成本和性能）之间找到没有其他方案能同时做得更好的那一组"最优权衡点"的集合，落在这条线之外的方案，要么更贵却不更好，要么更差却不更便宜。

论文作者的态度挺坦诚的，他们承认这个对比本身有几个局限。比如，检索测试用的语料库都比较小，只有82到415篇文档，能整个塞进提示词里，但真实的生产环境往往面对的是百万级甚至更大规模的文档库，那种场景下靠"整篇塞进去读"这种做法完全行不通,所以论文测出来的成本差距，其实是被低估的下限，实际部署中真实的成本差距可能更大。另外，分类任务里嵌入模型能用上完整的标注训练集，而大模型只能靠零样本或者极少数示例，这种"武器不对等"本身也是一种真实的部署约束，反映的是实际应用场景，而不是刻意制造出的不公平比较。

写在后面

读这篇论文最触动我的地方，其实不是那个1431倍的成本数字，虽然这个数字确实够震撼。真正让我停下来想了很久的，是那个关于Banking77分类任务的小例子,同一句"我怎么找到我的卡"，参数量更小、思考更少的Flash模型答对了，参数量更大、思考更深的Pro模型反而答错了。

这颠覆了我们对"越聪明越准确"的默认预期。一直以来，行业里的直觉是模型越大、推理越深，效果就该越好。但这篇论文用大量证据说明，推理深度和任务需求之间存在一个匹配问题:有些任务的答案就在字面意思里，你越往深处想，反而离正确答案越远。

另一个让我意外的细节是思考税的分布,有的模型思考成本占到总花费的81%，但把这些思考砍掉九成之后，检索成绩不降反升。这说明现在很多大模型的默认推理设置，可能本身就是针对"最难的那一小撮任务"校准的，套用到日常大部分场景上，纯粹是浪费。

这让我想到一个更大的问题：我们现在评估AI模型，是不是过于依赖单一的排行榜分数了？如果只看MTEB(LLM)那个总分，Gemini 3.1 Pro排第一，你可能会立刻决定全面切换。但只有把成本、速度、任务类型都摊开来看，才能看到那个真实、复杂、需要权衡的全貌。或许真正值得追问的是：在AI技术选型这件事上，我们到底愿意为"看起来最强"付多少倍的溢价？

Q&A

Q1：MTEB(LLM)是什么？

A：MTEB(LLM)是研究者专门设计的一套包含37个任务的评测基准，从原始的MTEB嵌入模型评测集里抽取子集组成，目的是让大语言模型和嵌入模型能在完全相同的数据和任务上公平对比，同时兼顾API调用成本可控和上下文窗口限制。

Q2：为什么大模型在检索任务上比嵌入模型强这么多？

A：因为检索任务经常需要跨文档的深度推理，而嵌入模型是把查询和文档分别独立编码成向量再比对相似度，没法做真正的联合阅读理解；大模型可以把整个文档库放进提示词里逐一通读判断，在需要理解复杂上下文的场景里更有优势，比如法语阅读理解检索任务上分数领先了20分。

Q3：用大模型做嵌入任务到底贵多少？

A：论文测算表明，表现最好的大模型Gemini 3.1 Pro跑完一整套测试花费154.14美元，而性能相当的嵌入模型Octen-8B只需要0.108美元，成本相差约1431倍，并且在换用不同硬件和定价方案后，这个倍数依然保持在300倍以上。