35 篇博文 含有标签「embeddings」

当 RAG 系统返回错误答案时，事后分析几乎总是聚焦于同一批嫌疑人：检索查询、相似度阈值、重排序器、提示词。团队会花好几天调整这些组件，而真正的原因却静静地躺在索引流水线里无人触碰。失败早在几周前就已发生——那时有人拍板决定了分块大小。

大多数 RAG 质量问题是架构性的，而非运营性的。它们源于索引时做出的决策，这些决策会悄然塑造 LLM 最终能看到的内容。等到用户投诉时，检索系统正在做它被设计好的事——只是那个设计本身就是错的。

你的 RAG 系统运行正常。延迟处于常规水平。错误率为零。但一位询问“加州雇佣法”的用户却不断得到关于房地产的搜索结果 —— 而你的日志显示一切正常。

这就是嵌入漂移（embedding drift）在作祟：这是一种不会抛出异常、不会导致错误率飙升，也不会出现在标准可观测性仪表盘上的检索失效模式。当你的向量数据库积累了在不同条件下生成的嵌入时 —— 比如不同的模型版本、不同的分块规则、不同的预处理流水线 —— 向量开始指向不兼容的方向，这种情况就会发生。系统仍在处理请求，但语义坐标已不再对齐，检索质量在数周或数月内悄然恶化。

你的 RAG 系统评估看起来还不错。NDCG 尚可接受，演示也能运行。但有一类故障是单一指标评估无法捕捉的：那些你的检索器从未接近过的查询——持续如此，因为你的整个嵌入空间从一开始就没有能力处理它们。

这就是检索单一化。一个嵌入模型、一种相似度度量、一条检索路径——因此也是一套系统性盲点，这些盲点看起来像模型错误、幻觉或用户困惑，直到你真正检查检索层才会发现真相。

解决方法不是更大的模型或更多数据，而是理解不同的查询结构需要不同的检索机制，并构建一个能够停止将一切都路由到同一漏斗中的系统。

你的 RAG 流水线上线六个月后，某些东西悄然改变了。用户没有大声投诉，但对答案的信任度正在下降。反馈评分从 4.2 跌至 3.7，一些支持工单提到了"过时信息"。你的工程师检查日志，没有错误、没有超时、没有明显的回归。检索流水线在你配置的每一个指标上看起来都很健康。

但事实并非如此。它正在腐烂。

检索债务是向量索引中积累的技术性衰退：不再代表当前文档内容的过期嵌入、污染搜索结果的已删除记录产生的墓碑块，以及索引语料库时使用的编码器版本与当前计算查询嵌入的编码器版本之间的语义漂移。与代码腐烂不同，检索债务不会产生堆栈跟踪，它产生的是带有自信引用的微妙错误答案。

当工程师评估向量数据库时，他们通常会加载 ANN 基准测试，并选择在 recall-at-10 排行榜上名列前茅的产品。三个月后，他们就开始提交迁移工单了。这些基准测试是在单一客户端、静态且索引完美的索引数据集上测量查询吞吐量的。但生产环境完全不是这样。

本指南涵盖了预测向量数据库在实际工作负载下能否撑住的五个维度，以及一个将这些维度与你的技术栈进行匹配的决策框架。

大多数 RAG 实现都以同样的方式开始：启动一个向量数据库，使用一个不错的模型嵌入文档，在查询时运行余弦相似度，然后发布。演示效果看起来很棒。相关性感觉出奇地好。然后你将其部署到生产环境，发现“Error 221”检索到了关于“Error 222”的文档，搜索特定的产品 SKU 会出现语义相似但错误的条目，而添加日期过滤器会导致检索质量大幅下降。

向量搜索是一个真正强大的工具。但在大多数生产环境的检索工作负载中，仅靠它是不够的。在 2025 年，通过 RAG 获胜的团队并不会在稠密嵌入（dense embeddings）和关键词搜索之间做选择——他们会刻意同时使用两者。

这是一个决策框架，用于判断混合检索何时值得增加复杂性，以及如何在不破坏延迟预算的情况下构建每一层。

你的语义搜索很可能正在悄然恶化，而你的监控面板对此毫无显示。

没有错误日志，没有 p99 毛刺，没有健康检查失败。查询依然返回结果，余弦相似度评分依然看起来正常。但相关性正在一点一点地悄然下滑——每一个被遗漏的新词，都在拉大用户语言与嵌入模型训练语言之间的距离。

这就是嵌入漂移问题。它之所以难以察觉，正是因为它不产生任何可见的失败信号——只有检索质量的缓慢侵蚀。用户会说产品"越来越没用了"，然后悄悄离开。

大多数团队把 embedding 生成当作一次性的 ETL 任务：跑一个脚本、填充向量数据库、然后就不管了。这在演示中行得通，在生产环境中却是慢动作式的灾难。你的向量索引不是一个静态的产物——它是一条持续运行的流水线，有自己的故障模式、数据新鲜度保证和运维手册。与主数据库不同的是，它出问题时没有任何异常会被抛出。系统照样返回结果，只是这些结果悄悄地、自信地错了。

如果你在运行一个检索增强生成（RAG）系统、语义搜索功能，或任何依赖 embedding 的产品，你的向量索引值得获得与 PostgreSQL 集群同等的严谨对待。以下是大多数团队在这件事上犯错的原因，以及生产级 embedding 基础设施究竟应该是什么样子。

BM25 发表于 1994 年，其数学原理简单到可以写在白板上。然而在 2025 年的生产检索基准测试中，它在真实世界查询的相当一部分场景中，依然超越了数十亿参数规模的稠密嵌入模型。那些在部署纯向量检索后才发现这一问题的团队，往往是以最糟糕的方式发现的：用户反馈幻觉，而他们在评估集中却无法复现——因为评估集是从那些已经能正常工作的查询中构建的。

这是检索领域的抽样偏差。稠密检索在特定且可预测的查询形式上会失败。这种失败是无声的——大语言模型仍会从检索到的任何片段中生成流畅、自信的答案。没有错误日志，没有延迟异常，只是对查询产品 SKU、错误码、API 名称或任何词汇特定而非语义通用内容的用户，悄悄给出了错误的回答。

解决方案是混合检索。但"混合检索"作为一个工程决策，本身定义不够充分。本文将介绍实际的失败模式、如何正确融合检索信号、重排序层的位置，以及——最关键的——如何在用户发现之前，找到当前流水线正在悄悄失败的查询类型。

大多数团队在意识到他们的语料库中很大一部分内容——产品截图、演示录制、架构图、客服通话录音——对于纯文本检索系统是不可见的之后，会将多模态 RAG 加入到他们的路线图中。在生产环境中令他们感到惊讶的并不是嵌入模型的选择或向量数据库的选择，而是模态之间的差距：同一个语义概念，当被编码为图像和句子时，会落在向量空间中完全不同的区域，而搜索引擎根本不知道它们是相关的。

这篇文章涵盖了多模态嵌入对齐的技术原理、在大规模场景下真正有效的跨模态重排序策略、相对于纯文本 RAG 的成本和延迟状况，以及多模态检索特有的失效模式。

你的 RAG 昨天回答得还很正确。今天它却自相矛盾了。看起来什么都没变 —— 除非你的嵌入模型（Embedding）提供商悄悄更新了模型，导致你的索引现在成了一个混合了不同向量空间的“科学怪人”（Frankenstein）。

嵌入模型是每个检索增强系统（RAG）中不起眼的基石，而且它们的失效方式通常极其难以诊断。与提示词（Prompt）更改或模型参数微调不同，嵌入模型的问题往往出现得非常缓慢，表现为一种无声的质量下降，在用户开始投诉之前，你的评估系统（Evals）甚至都察觉不到。本文涵盖三个方面：如何为你的领域选择合适的嵌入模型（MTEB 评分的误导性往往大于帮助）、升级模型时究竟会发生什么，以及无需从头重建即可更换模型的版本控制模式。