嵌入微调差距:通用向量并不理解你特定领域的“相关性”含义
你的 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 的相关性分级对“查询-文档对”进行评分。这是质量最高但也最昂贵的信号,通常每次判定的成本在 2.00 之间。如果有 10,000 次判定,仅训练数据一项你就需要投入 20,000。对于高要求的领域——法律、医疗、监管——这种质量提升 通常能够证明投资的合理性。对于其他所有人来说,结合合成数据和点击反馈是更务实的路径。
没人谈论的 A/B 测试鸿沟
这是团队经常自我欺骗的地方:离线指标提升了,发布了微调后的模型,但在生产环境中却毫无变化。或者更糟的是,离线指标提升了,但由于细微的分布偏移,模型在最重要的长尾查询上表现更差。
嵌入评估的严谨做法需要两条独立的测量路径。
离线评估在留存测试集上使用 Recall@K、NDCG@K 和 MRR。这衡量了模型是否能将相关文档排在靠前的位置——这是标准的机器学习指标。关键的失败模式是在你训练时的相同分布上进行评估。务必从你的微调数据中留出一个验证集,并考虑留出一个完整的切片(例如某个时间段或某个子领域)来测试泛化能力。
在线 A/B 测试在生产环境中为部分流量运行微调后的嵌入模型,并对比下游业务指标:参与度、任务完成率、用户满意度评分、转化率。通过这一步,你可以了解到离线指标的提升对用户是否真的有意义。这两组指标应该同步移动——如果不同步,说明你构建的模型虽然在评估中表现良好,但并不符合真实用户的相关性分布。
实践经验:不要在离线 NDCG 提升时就宣告胜利。去跑 A/B 测试。那些在 MTEB 上得分很高但在现实查询中没有改进的模型,正是 RTEB 旨在揭露的对象。
