25 篇博文 含有标签「embeddings」

迁移工单只有一行：“将 Embedding 模型从 v3-small 升级到 v3-large。”新模型在公开基准测试（Benchmark）中胜出 12%。流水线代码改动只有六行 Python。团队预计需要两天的开发时间，加上一个周末就能跑完的重嵌入（Re-embedding）任务。两个月后，查重功能的误报率比更换前翻了一倍，“相关项目”栏目悄然变成了废话生成器，语义缓存的命中率更是断崖式下跌，因为在旧空间运行良好的 0.95 阈值在现在几乎匹配不到任何内容。

没人动过这些功能。没人提交过 Bug。这个在迁移计划中被归类为“基础设施”的模型切换，悄无声息地改写了每一个使用相似度得分的业务规则。

大多数构建 AI 编程助手的团队都会采用与文档检索相同的现成 RAG 流水线：根据 token 数量对源文件进行分块（chunking），对块进行嵌入（embedding），将其存储在向量数据库中，并通过语义相似性进行查询。这种流水线在处理散文（prose）时表现良好。但在处理代码时，它会悄无声息地失败——而且这些失败很难在聚合指标中显现，因为检索到的代码块看起来似乎合情合理，直到模型生成了错误返回类型的代码、调用了签名错误的函数，或者遗漏了调用图中三层之后才存在的依赖项。

问题不在于嵌入模型或向量数据库，而在于分块策略。代码不是散文。它具有结构属性——依赖图、调用链、类型签名、作用域层级——而基于 token 的分块在检索器看到它们之前就破坏了这些属性。修复这个问题需要重新思考在进入嵌入步骤之前如何分解代码。

你花了数周时间构建检索流水线。分块策略已调整，相似度阈值已校准，用户反馈看起来很积极。然后，在某个周一的早晨，在你没有任何部署的情况下，检索质量开始下降。以前能搜出正确文档的查询，现在返回的却是关联度极低的噪音。没有错误日志。没有异常。流水线运行顺畅。

发生变化的是你的嵌入（Embedding）提供商更新了模型。你的整个向量索引——那些费尽心力嵌入的数百万个文档——现在填充的是来自一套坐标系统的向量，而这套系统与你的查询编码器生成的向量已不再匹配。结果不是系统崩溃，而是不可见的垃圾数据。

大多数构建 RAG 系统的团队从不思考嵌入维度的问题。他们直接选用 text-embedding-3-large，保留默认的 3072 维度，然后继续推进。在处理 1 万份文档时，这无关紧要。但在处理 1000 万份文档时，你已经给云服务商每月多付了 30 美元的存储费用，而实际上只需 3.75 美元。在处理 1 亿份文档时，你面对的是 1TB 的 float32 数据，其中大部分并没有物尽其用。

嵌入维度与实际检索质量之间的关系，远弱于维度与运营成本之间的关系。这个差距——你实际支付的成本与所获得的质量之间的鸿沟——就是向量维度税。

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

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

一个团队构建了一个 RAG 系统。英语检索召回率达到了 94%。他们发布了产品。三个月后，来自法国和德国用户的支持工单堆积如山——聊天机器人不断返回无关结果或根本没有结果。工程师们查看他们的监控仪表盘。整体召回率：91%。看起来一切正常。

语料库是英语。嵌入模型（Embedding model）仅支持英语。用户则不然。每一个法语查询都被嵌入到一个向量空间中，而这个空间的设计初衷从未考虑过与它所检索的英语文档共享坐标。余弦相似度并不低——但它们在几何上毫无意义。而且因为聚合指标掩盖了分布问题，在用户大声抱怨之前，这个问题是不可见的。

这就是多语言 RAG 检索差距，也是服务于非英语受众的生产级 AI 系统中最常见的静默失败模式之一。

大多数向量数据库教程只展示如何插入百万条嵌入并运行查询。但它们不会告诉你六个月后会发生什么——当你的语料库已经超出单节点承载能力，你不得不对整个检索管道所依赖的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 万行的表更换主键编码”。