31 篇博文 含有标签「embeddings」

大多数向量数据库教程只展示如何插入百万条嵌入并运行查询。但它们不会告诉你六个月后会发生什么——当你的语料库已经超出单节点承载能力，你不得不对整个检索管道所依赖的HNSW索引进行分片时，实际情况如何。答案是：供应商在营销材料中刻意回避的事实是，HNSW图在分区方式上存在特殊阻力，会导致无声的召回率下降，而恢复这一质量所需的运营模式会带来真实的复杂性。

本文将深入探讨HNSW分片失效的技术原因、实际中召回率损失的表现，以及团队在超出单节点容量后用于维持检索精度的运营模式。

我建议的一个团队花了两个月时间在其 RAG 流水中不断更换 LLM。从 Claude 到 GPT，再到 Gemini，最后又换了回来。每一次更换都能让幻觉率降低几个百分点，但从未在关键指标上有所进展：他们的支持代理找到正确知识库文章的概率仍然不到 60%。他们调优的层级错了。检索器返回的是无关的文本块，而无论 LLM 多聪明，都无法根据检索器从未呈现过的文档来回答问题。

嵌入模型是 RAG 系统中决定 LLM 甚至“被允许”看到什么的部分。它描绘了语料库的几何结构——即在向量空间中，哪些文档会落在哪些查询附近。一旦这种几何结构出错，LLM 就只是一个对错误上下文侃侃而谈的自信叙述者。换一个更聪明的 LLM 通常只会让回答更显“文采”，而不会让回答更准确。

一个新的嵌入模型发布了。基准测试数据提升了 4 %。一位 Staff 工程师提交了一个工单：“将 embedding 升级到 v3。”两周后，索引已完成重新嵌入，别名已切换，团队通过特性标志（feature flag）发布了变更。六周后，支持工单堆积如山。搜索结果“感觉不对劲”。复盘会召开了。没人能解释为什么出现了退化，因为没有系统崩溃，每个仪表盘显示的都是绿色。

问题不在于模型的更换。问题在于向量存储根本不知道哪些向量来自哪个模型。数据库里没有这一列。没有用于追踪哪些记录已回填的迁移表。没有 alembic_version 行，没有 schema_migrations 表，也没有先前状态的 pg_dump。团队将 embedding 升级视为一次简单的配置切换，而向量存储在模式（schema）层面缺乏能阻止他们犯错的概念。

Embedding 迁移需要数据库迁移二十年来一直依赖的相同产物：写入每个向量、在每次查询时检索、并作为切换和回滚准入准则的单条记录版本标签。这是大多数团队最容易忘记添加的一列，而后期补救的成本远高于前期添加。

大多数团队在生产环境中第一次更换嵌入模型（embedding model）时，都会将其视为批处理作业。重新运行嵌入器，构建新索引，切换别名，然后部署。延迟保持正常。错误率为零。每个查询都有结果。然而，检索质量会在数周内悄悄下降，而没人察觉。因为症状是“用户抱怨答案感觉不对”，而不是监控面板上的红报警报。

这不仅仅是部署问题，而是一个团队决定盲目进行的架构迁移（schema migration）。旧的嵌入空间和新的嵌入空间是不同的参考系；以前表示“这两个段落关于同一个话题”的余弦几何（cosine geometry）在数值置信度上不再具有相同的含义。以前聚集在一起的文档和查询会以非均匀的方式漂移。在旧分布上训练的重排序器（re-rankers）会开始处理那些不再符合其学习规律的样本。对逐点相关性（pointwise relevance）评分正常的评估套件会漏掉这一切，因为没有任何单个文档移动得太远，但整个图谱发生了旋转。

如果将这种更换视为数据库迁移，几乎所有出错的情况都是可以预防的。如果将其视为批处理作业，那么回归（regressions）就会按照无人负责的进度表悄然降临。

我在上个季度交谈过的一个团队在财务伙伴指出 AI 账单时陷入了短暂的恐慌。他们原以为，像大多数团队一样，昂贵的支出项会是生成——即聊天、总结和智能体推理背后的 GPT 级调用。事实并非如此。他们的每月 Embedding 支出在 1 月悄然超过了生成支出，到 3 月翻了一番，并有望在年中翻两番。没有人为此建模，因为 Embedding 模型的每 Token 定价看起来就像舍入误差：小型模型每百万 Token 2 美分，大型模型 13 美分。按照这个费率，谁会为此做预算？

答案是：任何产品度过了原型阶段并开始大规模索引内容的团队。在不断增长的语料库上进行语义搜索、重复检测、分类、聚类、更换模型时的重新索引——每一个工作负载消耗的 Embedding Token 都是以十亿计，而不是以百万计。与受用户请求限制的生成不同，Embedding 的吞吐量仅受你决定索引的内容限制。而这一决定很少经过成本审查。

本篇文章将探讨 Embedding 支出升级的具体机制、改变成本曲线的架构杠杆，以及从托管 API 转向自建服务的盈亏平衡计算。

在某个预发布（staging）频道里，一位工程师写道：“将嵌入模型（embedder）升级到 v3，新模型在 MTEB 上的得分提高了 4 分，冒烟测试通过后合并。”两天后，客服工单开始陆陆续续出现，反馈搜索结果感觉“莫名其妙地不对劲”。一周后，检索精度下降了 14 个百分点，余弦相似度分数从 0.85 暴跌至 0.65 左右，而且没人能解释原因——因为这次部署看起来与过去五次模型升级完全一样。这根本不是一次普通的部署。而是一次披着部署外衣的数据库迁移。

嵌入模型轮转是 AI 基础设施中最容易被归类错误的变更类型。它通过与提示词（prompt）微调或生成模型版本更新相同的渠道进入你的系统——配置文件、PR、CI 检查——因此它遵循配置变更的治理流程。但从底层来看，新的嵌入模型并不会产生旧向量的更好版本。它产生的向量完全存在于不同的坐标系中，跨两个流形计算余弦相似度是一个范畴错误（category error）。正确的心理模型不是“升级依赖版本”，而是“在提供读取服务的同时，为一个拥有 5000 万行的表更换主键编码”。

大多数关于 RAG 质量的讨论都聚焦在错误的地方。团队在争论嵌入模型的选择、微调检索的 top-K、以及尝试各种提示词模板——然而在数据摄取阶段做出的一个架构决策，却悄然决定了系统能力的上限。这个决策就是分块策略（chunking strategy）：即在索引之前，你如何将文档切分成片段。

一项 2025 年的基准研究发现，分块配置对检索质量的影响，甚至比嵌入模型的选择还要大。然而，团队通常会选择默认配置——通常是 512 个 token 的 RecursiveCharacterTextSplitter——然后花上几个月的时间去思考，为什么他们的检索精度总是差强人意。问题在索引时就已经埋下了。更换模型无法解决这个问题。

大多数RAG团队会花数月时间调整分块大小、尝试不同的嵌入模型、争论混合搜索配置。然后他们上线，宣告成功，转身离开。六个月后，用户开始抱怨系统给出错误答案——团队才发现，当初精心构建的索引已经悄然腐化。

索引新鲜度是最后才被解决的问题，通常是在用户投诉事故之后才被重视，而非之前。与检索质量问题会立即在评测中暴露不同，数据陈旧是无声无息的退化：延迟保持平稳，检索看似正常，上下文召回率和忠实度等标准RAG指标评分良好——直到系统自信地返回几个月前就已更新的政策时，才会东窗事发。

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

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

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

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

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

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

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

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

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

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