跳到主要内容

嵌入微调差距:通用向量并不理解你特定领域的“相关性”含义

· 阅读需 13 分钟
Tian Pan
Software Engineer

你的 RAG 流水线在理论上看起来很扎实:分块很清晰,向量库已建立索引,延迟也在可接受范围内。但用户一直在抱怨结果是错的 —— 并不是完全错误,而是在关键细节上“稍微”有些偏差。检索到的片段讨论了正确的概念,但时间点不对。它涵盖了正确的主题,但司法管辖区不对。它提到了正确的产品,但缺少了使其真正有用的库存信号。

这就是嵌入微调鸿沟。通用嵌入模型被训练用来编码语义相似性 —— 即两个文本意思大致相同的属性。但这并不等同于相关性。相关性是特定于领域的、对上下文敏感的,并且对于在互联网规模的通用语料库上训练的模型来说通常是不可见的。

像 text-embedding-ada-002、BGE 或 E5 这样的现成嵌入模型在捕捉广泛语义相似性方面表现出色。它们在数千亿个 token 上进行训练,能够识别出“心跳骤停”与“心力衰竭”相关,或者“违约”与“未履行合同”属于同一个法律范畴。问题在于,嵌入空间中的相似性并不等同于你在检索任务中的实用性。

考虑一个法律发现系统。关于 2023 年特定先例的查询可能会检索到几个 1980 年代的语义相似案例。它们涵盖了相同的法律原则 —— 余弦相似度很高。但对于研究当前判例法的律师来说,那些旧的先例可能几乎毫无价值,而最近的裁决才是关键。嵌入模型没有将“时效性”视为相关性信号的概念。它从未接受过权衡这一指标的训练。

同样的模式在各个领域不断重复。在电子商务中,查询“100 美元以下的跑鞋”需要将当前的库存和价格视为相关性信号 —— 而通用嵌入模型会将这些信号视为噪声。在医学文献检索中,经过同行评审的临床试验与会议摘要之间的区别至关重要,但语义相似性会将它们同等对待。在企业搜索中,本季度的监管更新可能会取代两年前技术上相似的文档。

通用嵌入模型究竟在优化什么

MTEB (Massive Text Embedding Benchmark) 排行榜已成为比较嵌入模型的标准指标,它是衡量通用语义质量的合理方式。模型在数十个数据集上的语义文本相似性、检索和分类等任务上展开竞争。问题在于,“MTEB 性能”与“生产系统中的检索质量”虽然相关,但并不等同。

基准测试社区在 2024 年底明确意识到了这一点,并推出了 RTEB (Real Time Embedding Benchmark),因为他们观察到模型越来越多地对现有 MTEB 数据集产生过拟合,而没有转化为现实世界的改进。可重复性审计发现,自定义提示策略、归一化技巧和特定于数据集的超参数可能会虚标性能,而没有提供真正的泛化能力。

实际的后果是,你不能简单地选择 MTEB 上排名最高的模型并期望它在你的领域表现良好。这些模型竞争的任务可能与你实际的检索问题几乎没有共同点。在 Reddit 对话和维基百科段落上进行微调的模型已经学会了语义相似性如何映射到这些数据集上的用户相关性。但在你的语料库中,这种映射关系是不同的。

特定领域的嵌入具体地展示了这种差距。针对法律语料库微调的 Voyage-law-2,在法律检索基准测试中的 NDCG@10 表现比通用模型高出 15% 以上。这种差距并不是因为法律文本很奇特 —— 而是因为法律检索中的“相关性概念”包含了通用训练根本没有编码的信号(司法管辖区、时效性、先例权重)。

核心技术:带难负例的对比微调

缩小这一差距的机制是对比微调。其直觉很简单:在 (查询, 正向文档) 对上训练模型,其中正向文档是用户实际认为相关的;以及 (查询, 负向文档) 对,其中负向文档是那些“看起来”相关但实际不相关的。

关键词是“难”负例。随机负例很简单 —— 将关于心脏手术的查询与关于气象学的文档进行比较并不能教给模型任何有用的东西。难负例是那些模型会被误导的情况:语义相似但在查询环境下是错误的文档。例如来自同一法律领域但司法管辖区错误的法律案件;属于正确类别但价格区间错误的商品;或者发表时间过早六年的相同主题的研究论文。

典型的微调工作流分两步运行。首先,在 3-5 个 epoch 内使用随机负例训练基准模型 —— 这能让你在不产生过拟合的情况下确定大致方向。其次,使用该基准模型对语料库进行嵌入,并识别每个训练查询的前 K 个最近邻。这些近邻在过滤掉已知的正例后,就成为了第二轮训练的难负例。

最常用的损失函数是多负例排名损失 (MNRL),它将训练批次中的所有非正向文档视为负例,并优化正向文档以获得最高的相似度。难负例挖掘增强了这一点,确保每个批次中的“干扰项”确实难以区分。

小数据集的效果往往超出你的预期。研究表明,在少至 6,300 个标记样本上进行对比微调,与基础模型相比,NDCG@10 可提升 7-10%,且在单个 GPU 上的训练可在不到一小时内完成。高质量的难负例比数据集的大小更重要。

从生产环境中收集训练信号

大多数团队的瓶颈不在于训练过程,而在于训练数据。获取足够多且具备高质量相关性判定的 (query, relevant_document) 对是非常困难的。

按照成本和质量从低到高,有三种数据源值得考虑:

来自点击数据的隐式反馈。 如果用户与检索到的结果进行了交互,你就获得了信号。点击、停留时间以及后续操作(购买、保存、复制)虽然带有噪声,但具有可扩展性。如果用户点击了结果 3 而忽略了结果 1 和 2,这就是一个反映结果 3 更具相关性的噪声信号。在大规模数据下,这些噪声会相互抵消。其局限性在于点击数据包含位置偏差(position bias)——无论质量如何,用户点击第一个结果的频率总是更高——因此在使用前需要进行去偏处理。

来自 LLM 的合成查询。 使用性能较强的语言模型,针对每个文档块生成其最能回答的假设性问题。给模型一个文档,并提示它生成 5 到 10 个用户在寻找该信息时可能提出的自然查询。这种方式在完成设置后,几乎可以以零边际成本生成 (query, document) 正样本对。使用 GPT-3.5 或 Claude Haiku 进行合成查询生成,可以在几小时内以几百美元的成本生成 10 万个以上的训练对。合成对并不完美——它们忽略了你用户的真实分布特性——但它们是一个有用的起点,特别是对于人工标注成本昂贵的领域。

人工相关性判定。 专家标注员按照 0–4 的相关性分级对“查询-文档对”进行评分。这是质量最高但也最昂贵的信号,通常每次判定的成本在 0.500.50–2.00 之间。如果有 10,000 次判定,仅训练数据一项你就需要投入 5,0005,000–20,000。对于高要求的领域——法律、医疗、监管——这种质量提升通常能够证明投资的合理性。对于其他所有人来说,结合合成数据和点击反馈是更务实的路径。

没人谈论的 A/B 测试鸿沟

这是团队经常自我欺骗的地方:离线指标提升了,发布了微调后的模型,但在生产环境中却毫无变化。或者更糟的是,离线指标提升了,但由于细微的分布偏移,模型在最重要的长尾查询上表现更差。

嵌入评估的严谨做法需要两条独立的测量路径。

离线评估在留存测试集上使用 Recall@K、NDCG@K 和 MRR。这衡量了模型是否能将相关文档排在靠前的位置——这是标准的机器学习指标。关键的失败模式是在你训练时的相同分布上进行评估。务必从你的微调数据中留出一个验证集,并考虑留出一个完整的切片(例如某个时间段或某个子领域)来测试泛化能力。

在线 A/B 测试在生产环境中为部分流量运行微调后的嵌入模型,并对比下游业务指标:参与度、任务完成率、用户满意度评分、转化率。通过这一步,你可以了解到离线指标的提升对用户是否真的有意义。这两组指标应该同步移动——如果不同步,说明你构建的模型虽然在评估中表现良好,但并不符合真实用户的相关性分布。

实践经验:不要在离线 NDCG 提升时就宣告胜利。去跑 A/B 测试。那些在 MTEB 上得分很高但在现实查询中没有改进的模型,正是 RTEB 旨在揭露的对象。

什么时候微调是错误答案

嵌入微调并不总是解决检索质量差的最佳工具。在决定微调之前,请考虑以下两种通常能以更少投资带来更高 ROI 的替代方案。

重排序(Reranking)。 交叉编码器(cross-encoder)重排序器使用全注意力机制同时读取查询和每个候选文档——它不受预计算向量相似性的限制。检索 20 个候选结果,重排序到前 5 个。这能捕捉到嵌入模型虽然检索到了语义相似的文档,但遗漏了区分最佳结果的细微质量信号的情况。在检索流水线中,使用精心挑选的交叉编码器模型进行重排序通常是 ROI 最高的改进方案,因为你是在添加一个质量信号层,而不是更换检索基础。如果你的用户抱怨“正确”的文档几乎总是在前 20 名中,但没有排在第一位,那么请从这里开始,而不是去微调嵌入模型。

元数据过滤。 如果领域特定的相关性信号(如时效性、来源权威性或类别)可以编码为结构化元数据,请在检索前后对其进行过滤。一个本应限制在过去五年内案例的法律查询,可以应用一个日期过滤器,这几乎没有实施成本,且无需嵌入模型去学习该信号。元数据过滤不需要训练数据,没有过拟合的风险,并且是立竿见影且可逆的。它无法处理相关性是连续的、依赖上下文的信号的情况,但许多实际的“相关性错误”问题实际上是伪装成检索问题的结构化标签问题。

只有当你拥有大量的领域特定训练信号、相关性失效是语义而非结构性问题、并且已经尝试过其他替代方案时,嵌入微调才值得一试。

生产维度与成本

一个会对后续产生连锁反应的技术决策是嵌入维度 (Embedding Dimensionality)。通用模型通常输出 1,536 或 3,072 维向量。在处理 1 亿份文档时,从 384 维增加到 3,072 维会使存储需求从约 150 GB 增加到 1.2 TB —— 成本增加了 8 倍 —— 且近似最近邻搜索 (Approximate Nearest-Neighbor Search) 的延迟也会成比例增加。

这里值得考虑使用套娃表示学习 (Matryoshka Representation Learning, MRL)。MRL 模型的训练方式使得输出向量的前 N 维包含最关键的语义信息,而后续维度则增加细粒度的细节。这让你可以在推理阶段根据质量与成本的权衡来选择维度 —— 一个经过微调的 1,536 维模型在 512 维下仍能保持 99% 的质量,同时减少 9 倍的存储需求。如果你要进行大规模部署,MRL 微调应该从一开始就纳入训练方案中。

微调本身的成本通常比团队预期的要低。基于 API 的微调(如 Cohere、OpenAI 的微调端点)通常花费在 50 到 500 美元之间,具体取决于数据集大小和基础模型。在单张 A100 上针对中型数据集进行自托管训练的成本也在这个范围内。昂贵的部分在于数据收集,而不是计算。

复利回报

那些发布了微调嵌入模型后就止步不前的团队,其实错失了系统最大的收益。生产系统现在持续输出隐式的相关性信号 —— 每一次点击、每一个会话、每一个下游用户行为,都是关于你的用户真正认为什么内容相关的关键数据点。如果检索系统能够摄取这些信号进行定期重新训练,那么它相对于通用嵌入的优势将逐月叠加。

实际的架构是一个定期重训流水线:收集行为数据、使用当前模型挖掘难负例 (Hard Negatives)、使用更新后的数据集重新训练,并在推向生产环境前进行离线评估。初始微调在基础模型之上提升效果;第二轮训练在第一轮基础上提升;第三轮则进一步优化拟合度。经过三到四个周期后,你的嵌入模型与领域内最好的现成替代方案之间的差距,通常是仅仅通过提示词工程 (Prompt Engineering) 或检索技巧所无法逾越的。

通用嵌入是一个合理的起点。但从你拥有生产流量的那一刻起,它们就不再是一个合理的长期基础,因为这些流量包含关于领域相关性的信号,这是任何通用网络训练都无法复制的。如今在基准测试中排名第一的模型是根据昨天的查询数据训练的。而你的系统此时此刻正在生成训练数据。

References:Let's stay in touch and Follow me for more thoughts and updates