171 篇博文 含有标签「rag」

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

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

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

模型有知识截止日期。用户不知道它是什么。产品在几乎所有情况下都不会告诉用户。当用户问了一个正确答案在三个月前已经改变的问题时，助手会给出一个言之凿凿的错误答案——这并非因为模型失效了，而是因为产品从未提供一种方式来标记这种信息鸿沟。你与用户之间的信任契约是隐性的、不对称的，并且每当世界发生变化而你的 UX 假装没有变化时，这种契约就会被悄然打破。

主流模式是将截止日期视为一个注脚：一段埋藏在帮助中心里的披露文本、一个无人阅读的 /about 页面，或者在第一周就被关闭的一次性工具提示。这种定位是一个 bug。知识截止日期不像“上下文长度”那样是模型的一个属性。它是一个 UX 界面——经过工程化、设计和演进——将其视为次要因素，会导致交付的产品在用户无法审计的语调下，围绕自身的无知进行编造。

向量索引即便有约 10% 的误差，也没人会惊慌。但知识图谱如果缺失了一条边，就可能导致有人向监管机构提交一份错误的答案。从数据工程组织的架构图来看，这两种故障模式如出一辙——都被归类为“索引陈旧”——并且它们共用同一个变更数据捕获（CDC）流水线，具有相同的延迟容忍度。流水线的规格是根据向量负载确定的，因为向量是更“大声”的消费者。图谱默默地继承了这些默认设置，而这种沉默本身就是 bug。

向量检索和图谱检索在数据陈旧时的失败表现截然不同。将它们视为同一种延迟问题，会导致你构建出的系统虽然在 RAG 基准测试中得分很高，但在多跳查询中却会产生隐蔽的错误——当然，这种“隐蔽错误”往往是用户最后才会察觉到的。解决方案不是更快的流水线，而是要认识到“陈旧”具有两种不同的含义，为每种边类别设计新鲜度分层，并在监管机构发现之前，通过评估机制捕捉到这种差异。

长上下文与 RAG 的经济学在两年内翻转了两次，而在那两个窗口期中选择了某种架构的团队，现在正处处支付着错误的代价。在 2024 年，趋势是将一切都塞进上下文窗口，因为窗口在不断扩大，而每 token 的价格在持续下降，因此检索流水线被斥为过时的繁琐工作。在 2025 年，共识发生了反转：关于“上下文腐烂”的研究表明，在百万级 token 的提示词中，窗口中部的有效召回率大幅下降，全窗口调用的延迟变成了用户体验问题，且账单变得非常惊人，于是检索技术重新得到了重用。到 2026 年，正确的答案不再是任何一种口号。它是一个在设计阶段做出的基于单个功能的决策，并记录下四个维度的权衡，因为为整个产品选择单一架构，是让每个功能同时出错的低成本方式。

一直困扰着团队的思维模型是将长上下文 vs RAG 视为路线图上的承诺，而不是针对每个界面的选择。你阅读了一篇有影响力的博客，选边站队，雇佣了擅长那一边的工程师，编写了一份将其规范化的平台文档，现在每个新功能无论是否合适，都采用了相同的架构。需要新鲜数据的功能忍受着陈旧的上下文。需要可扩展语料库的功能为他们永远不会使用的检索基础设施买单。需要引用来源的功能在发布时却缺失了这一项。这些都不是 bug。它们是将功能级决策视为产品级决策所带来的必然代价。

两年前，一个团队将他们的检索索引指向了 Wiki、Zendesk 导出文件以及公共文档的快照。上周，同一个索引返回了一个已弃用的运行手册（runbook），告诉 SRE 去重启一个已不存在的服务。该运行手册已经废弃了 18 个月。没人负责它的下线工作，所以没人把它删掉。Agent 自信地引用了它。模型没有错；错的是语料库（corpus）。

这是检索评估（retrieval evals）中不会出现的故障模式：语料库被视为一次性的工程决策，而实际上它是一个持续的治理问题。负责初始摄取（ingestion）的团队早已解散。本应标记出客户机密 PDF 的法律审查从未发生，因为没人告诉法务部门存在这个流水线（pipeline）。“新鲜度策略”（freshness strategy）只是一个在第三季度离职的人留下的 Slack 消息。检索索引变成了任何人抓取过的每一份文档的共享收件箱，而纳入标准已逐渐演变为“任何容易摄取的内容”。

一个用户在 14:32:07 向你的助手提问。你的检索器在 14:32:08 触发，从政策手册中提取了五个分块。模型思考了几秒钟，起草了回复，并在 14:32:12 流式传回了一个答案，自信地引用了第 4.3 节——而管理员在 14:32:10 刚刚删除了这一节，因为它有误。用户读到了一段来自已不存在文档的权威引用，甚至还附带了一个返回 404 的可点击链接。

你的技术栈中没有任何环节报错。检索器返回了有效的命中结果。模型生成了流利、有据可查的文字。引用的分块 ID 在检索发生时确实存在。然而，根据任何合理的定义，这个答案都是一个幻觉——并不是因为模型胡编乱造，而是因为在它观察世界与开口表达的间隙，底层数据已经发生了变化。

这就是 RAG 的“写后读竞争”（read-after-write race），而大多数生产级流水线对此毫无防备。

用户根据 GDPR 第 17 条提交了删除请求。你的团队删除了 Postgres 中的行，清除了 S3 中的缓存文档，并从 CDN 中轮换掉了缓存的 PDF。搞定。隐私团队签字，安全团队签字，工单关闭。六个月后，一名拥有向量索引读取权限的数据分析工程师为了一项聚类实验提取了一组 float[1536] 数组样本，通过公开可用的反演模型（inversion model）运行这些数据，并重建了原始 32-token 文本块中大约十分之九的内容——包括你已经“删除”的文档。没人预料到这一点。没人怀有恶意。流水线完全按照设计运行，只是威胁模型从未将向量存储视为数据副本。

在我见过的几乎每个 RAG 团队中，这种思维误区都是一致的：嵌入（embeddings）被视为不透明的数值产物——是衍生品，而非数据。安全评估批准上线是因为“嵌入不是 PII（个人身份信息）”。隐私评估批准了删除处理，是因为“源文本已不存在”。这两个团队都错了，谁都没有将向量存储建模为用户数据的第三份副本——它紧挨着源数据库和分析仓库，任何拥有索引读取权限的人都可以查询，且由于没有任何工具能识别出 1536 维的浮点向量属于敏感数据，它完全处于所有 DLP（数据泄露防护）扫描器的范围之外。

当 RAG 系统回答错误时，大多数团队的第一反应是归咎于编码器（encoder）。更换更大的嵌入模型（embedding model）。尝试针对特定领域微调过的模型。增加维度。三个迭代周期（sprint）后，召回率曲线只提升了几个百分点，而用户的投诉看起来还是老样子。

诊断错了。大多数检索失败并非嵌入失败。它们是查询形状（query-shape）失败——在编码器运行之前就存在的词汇不匹配，无论如何调整向量都无法修复。

用户输入“如何取消”。相关的文档标题却是“订阅生命周期管理”，并使用了“终止”、“计费周期结束”和“服务停用”等词汇。世界上没有任何编码器能靠词汇运气将这两个字符串拉入同一个邻域。余弦相似度（cosine similarity）的差距是真实存在的，它存在于输入中，而非模型中。位于检索之前的查询重写层是大多数流水线跳过的步骤，随后他们却要花一个季度的时间试图在下游进行补偿。

我在上个季度交谈过的一个团队在财务伙伴指出 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 万行的表更换主键编码”。

一家中型 AI 公司的财务负责人在上个季度告诉我，他们通过将 Agent 骨干模型从 Sonnet 切换到 Haiku，“优化了他们的 LLM 支出”。Token 账单下降了 22%，而每个已解决工单的总推理成本仅下降了 4%。当我们进行完整的成本拆解时发现，模型这一项支出大约仅占单次请求成本的三分之一。检索、重排序（reranking）、可观测性、重试放大以及人工介入（human-in-the-loop）审核队列吃掉了剩下的部分——而且当你更换模型时，这些环节都没有变得更便宜。

这是我目前在 AI 团队中看到的最常见的财务核算错误。Token 成本是你每月支付的发票上的分项，因此它成了每个人都在优化的数字。但对于任何非平凡的生产系统——RAG、Agent、任何带有工具调用或评估门控的系统——模型推理往往只占实际单位经济效益的 30% 到 50%。剩下的部分隐藏在你的工程仪表盘不会显示、且财务团队不会将其归类为 “AI 支出”的地方。

智能体对话记录中最危险的一句话不是幻觉。而是四个冷静的词：“我没有找到。”智能体听起来在认知上表现出谦逊。听起来像是完成了尽职调查。对于任何下游读者或调用者来说，这听起来完全像是一个事实。然而，这句话并没有提供关于该事物是否存在的信息。它只提供了关于特定工具在使用特定查询、咨询特定索引（而智能体恰好在那个时刻有权访问该索引）时发生了什么的信息。

在这两种解读之间，隐藏着一个随时可能发生的生产事故。支持智能体告诉客户“我们没有你的订单记录”，因为同步延迟导致写入只读副本的时间推迟了 90 秒。编码智能体声明“该模块没有测试”，因为它搜索了一个不包含测试文件夹的目录。合规智能体回答“档案中没有先前的违规记录”，因为审计索引尚未摄取上周的报告。在每种情况下，智能体的输出在语法上都是一种否定，但在认知上，它只是一个被重新表述为断言的“耸肩”。