Embedder 的困境:LLM 更好,但代价是什么?

TL;DR 在 37 个任务上对比 10 个 LLM 与 26 个 embedding 模型，总体性能几乎打平，但 LLM 成本最高可达 1,431 倍；结论支持按任务分工：相似度/分类/聚类用 embedding，推理密集型检索再用 LLM。

问题

问题背景

文本嵌入是语义搜索、分类、聚类和检索等任务的基础设施。当前业界并行存在两条技术路线：专用嵌入模型（如 bge-en-icl、Qwen3-Embedding）和指令微调大语言模型（如 Gemini 3.1 Pro、GPT-5）生成 embedding 或直接完成跨文档推理。随着 LLM 能力提升，是否用 LLM 替换传统 embedding pipeline 已成为工程决策中的核心争议。

现有方法局限

专用嵌入模型在推理密集型检索上存在明确短板：其依赖单向量几何相似度，难以处理多跳推理、条件匹配或跨文档证据合成，典型如法律条文检索和阅读理解式 QA。而 LLM 路线虽然语义理解更强，却面临三类工程约束：

• 推理成本中 reasoning tokens 占比高达 28–81%，单次基准运行成本最高可达 USD 154；
• 开放权重 LLM 在相同 GPU 上 token 处理速度比嵌入模型慢 2.5–736 倍；
• LLM 在分类任务上容易过度解读短文本意图，反而不如锚定参考标签的嵌入模型稳定。

为什么难/重要

质量与成本并非线性权衡：总榜上最佳 LLM 与最佳嵌入模型仅差 0.4 分，但成本差距最高 1,431 倍。这使从业者无法简单全局替换，必须按任务类型进行分工。业界在 RAG、企业知识库、多语言语料等场景中，误判会直接导致延迟上升与预算失控。

行业类比

类比 RAG 系统中检索器与重排器的分工：向量检索负责快速召回，LLM 仅对少量候选做精读重排。嵌入模型与 LLM 的关系同理——前者负责相似度、分类与聚类，后者专精推理密集型检索。

核心洞察

• 聚合指标掩盖任务特异性：两类模型总体打平，但最优选择高度依赖任务。与只报告单一平均分的基准不同，本研究按分类、STS、聚类、Pair Classification、检索分层评估，发现 LLM 在检索上领先 +8.5，Embedding 模型在分类上领先 -5.6，其余类别统计平局。这挑战了 LLM 全面替代 Embedding 的叙事，为工程选型提供基于任务细粒度的决策依据。
• 推理 token 是 LLM 推理成本的主要构成，但并非越多越好。在 28% 至 81% 的推理成本占比下，减少推理预算对多数模型检索质量持平或提升，与更深推理必然更优的假设相悖。这意味着工程师可将推理预算视为可调参数，在质量与成本之间动态权衡，而非默认开启最大思考深度，尤其适用于对延迟敏感的生产环境。
• Pareto 前沿显示 Embedding 模型占据性价比支配地位，仅有一个 LLM（Gemini 3.1 Pro）进入前沿。同类工作通常只报告准确率或单点成本，本研究将质量、美元成本、吞吐量联合建模，揭示 LLM 成本可比同质量 Embedding 模型高 1431 倍，同 GPU 吞吐慢 2.5 至 736 倍。这为技术决策者提供清晰分工原则：默认使用 Embedding 处理相似度、分类、聚类，仅在推理密集型检索中评估 LLM 的必要性。

方法

输入

37 个任务数据集覆盖五大类：分类（8 个）、语义文本相似度（STS，10 个）、聚类（9 个）、配对分类（4 个）、检索（6 个）。任务输入包括单句文本、句对、查询-文档对等，部分任务含多语言与跨文档推理场景。

关键模块

1. 模型池：10 个 LLM（来自 6 个家族）与 26 个 embedding 模型（参数量 118M 到 14B）统一接入评估。LLM 通过生成式 prompt 产生嵌入或直接输出答案；embedding 模型使用池化或 [CLS] 表示。
2. 评估协议：按任务类别采用标准指标——分类准确率、STS Spearman 秩相关、聚类 V-measure、配对分类 F1、检索 nDCG。对 LLM 与 embedding 模型应用相同任务模板与评估脚本，并用 bootstrap 方法检验统计显著性。
3. 成本核算：区分 embedding 成本（按 token 计）与 LLM 成本（按推理 token 计，含 reasoning token）。记录每次 benchmark pass 的总美元成本。
4. 吞吐量测量：在相同 GPU 上测量开源 LLM 与 embedding 模型的 token 处理速度，参数量范围 2.5 到 736 倍差异。
5. 消融实验：对 LLM 降低 reasoning token 预算，观察成本与检索质量的变化；对分类任务进行 few-shot 消融。

输出

• 总体性能对比、按任务类别排名、retrieve-then-rerank 矩阵、成本-吞吐量 Pareto 前沿。
• 关键结论：LLM 与 embedding 模型总体性能接近（最佳差 0.4 分），但 LLM 成本最高达 1431 倍；reasoning token 占 LLM 成本 28%–81%。

与同类方法的差异：现有基准多仅报告精度，本工作引入成本感知评估与 reasoning token 消融，直接揭示高成本 LLM 的边际收益，为部署时的任务分工提供依据。

实验

实验设计

• 对比 10 个 LLM(6 个家族) 与 26 个 embedding 模型(118M–14B 参数),覆盖 37 个任务:分类、STS、聚类、pair classification、检索。
• 统一通过 API 或同 GPU 记录质量、成本与吞吐;代表性数据集包括 FQuAD、Banking77、STSBenchmark、BIOSSES、AILAStatutes。

关键发现

• 聚合性能几乎持平:最佳 LLM Gemini 3.1 Pro 得分 77.6,最佳 embedding 模型仅低 0.4 分(77.2)。
• 任务分化明显:检索上 LLM 领先 +8.5,分类上 embedding 领先 -5.6;聚类、STS、pair classification 统计上无显著差异。
• 成本悬殊:LLM 单次 benchmark 成本最高 USD 154,同等质量 embedding 模型为 USD 0.11,差距 1,431x。
• 推理 token 占 LLM 成本的 28–81%;开源 LLM 在同 GPU 上处理速度慢 2.5–736 倍。

基线对比与工程启示

• Pareto frontier 由领先 embedding 模型与 Gemini 3.1 Pro 构成,说明仅极少数 LLM 在成本-质量上具备竞争力。
• 部署分工建议:相似度、分类、聚类使用 embedding;仅推理密集型检索考虑 LLM。
• 降低 reasoning budget 在多数模型上可保持或提升检索质量,是直接降本路径。

行业影响

落地场景

文本嵌入广泛应用于语义搜索、推荐、内容聚类、意图分类和 RAG 检索。论文结论支持一个清晰的产品分工：embedding 模型 继续承担相似度计算、分类和聚类等大规模高效率任务；LLM 仅用于推理密集型检索，例如需要跨文档比较、多跳推断或复杂条件筛选的查询。具体场景：电商搜索中，先由 embedding 模型完成向量召回，再对复杂查询（如“适合跑步且降噪好的轻便耳机”）调用 LLM 做推理重排；企业知识库问答中，用 embedding 模型做文档聚类与粗排，LLM 只处理最终答案生成和少量高价值重排。

商业价值

核心收益在成本侧。论文显示 LLM 达到与 embedding 模型相当的质量，成本最高达 1,431 倍，吞吐量慢 2.5 到 736 倍。改用 embedding 模型处理分类、STS 和聚类，可将推理预算降低 28%–81%（减少 reasoning tokens），且不影响检索质量。对于高并发在线服务，embedding 模型的低延迟和高吞吐能显著降低 GPU 集群规模，直接节约基础设施成本；同时 LLM 仅用于少量请求，可优化整体响应时间和用户付费 API 费用。

与现有产品/工作流的接口

集成路径清晰：保留现有 embedding pipeline，仅新增一个轻量路由层。根据任务类型或查询复杂度，决定请求走向。

• 相似度 / 分类 / 聚类：直接调用 embedding 模型，输出向量后接下游逻辑。
• 检索：embedding 模型做召回，若查询包含复杂关系或需多文档推理，再触发 LLM 重排（如 gemini-3.1-pro 配合低 reasoning 预算）。
• 模型替代：可将分类任务从 LLM few-shot 切换到 embedding 模型微调或线性分类头，保持性能同时大幅降本。

论文作者建议的“分工”不是二选一，而是按任务特性路由：embedding 模型承担高频基础语义任务，LLM 保留给真正需要推理的检索场景。这为现有产品提供了一条低风险、渐进式降本路径。

具体 use case：内容平台做标签聚类和相似度去重时用 embedding 模型；对于深度语义搜索（如法律条文的相似案例辨析）保留 LLM 重排。医疗问答系统用 embedding 模型做患者问题分类和文档粗检索，LLM 只处理需跨指南推理的复杂病例。

局限

• **LLM 覆盖有限与版本漂移**：论文评估了 10 个 LLM（六个家族）和 26 个 embedding 模型，但未覆盖所有主流闭源模型（如 GPT-4 系列部分变体），且闭源 API 迭代频繁，**Gemini 3.1 Pro** 等分数可能随版本更新而失效。embedding 模型列表虽较全面，但仍限于公开权重或可访问 API，可能遗漏最新或专用模型。该覆盖缺口使“最佳 LLM 与最佳 embedding 模型差距 0.4”的结论具有一定时效性和样本偏差，不能外推到所有模型。
• **监督不对称与推理 token 混淆**：embedding 模型通常在分类/STS 任务上有专门监督微调，而 LLM 以 zero-shot 或 few-shot 方式评估，二者训练信号不对等。此外，LLM 在检索任务上的领先部分依赖于生成额外推理 token，尽管消融显示降低推理预算可保持质量，但推理 token 的成本占比高达 28–81%，这种“以算力换性能”的策略可能偏离文本编码的本质。该不对称可能高估 embedding 的性价比，或掩盖 LLM 在特定任务上真正的编码能力。
• **检索语料规模过小且缺少中间路线对比**：实验中的检索任务（如 FQuAD、TwitterHjerne）均为小规模、特定领域语料，未模拟真实生产环境中百万级文档、高动态更新的检索场景。在超大规模语料下，embedding 模型配合 ANN 索引的成本优势更加显著，而 LLM 逐文档推理成本随语料线性增长，结论可能反转。此外，工作未纳入 cross-encoder 或 ColBERT 等后期交互模型，这些模型在精度-成本权衡中可能占据不同 Pareto 位置，导致分工建议的适用范围受限。