861 篇博文 含有标签「insider」

AI 功能发布中存在一个重复出现的模式：演示（demo）惊艳全场，功能正式上线，两周内发生了一些灾难性的事情。不是宕机——那些很容易捕捉。而是一些更微妙的事情：模型自信地生成错误信息，成本飙升到预期三倍，或者在真实负载下延迟激增导致功能无法使用。团队手忙脚乱，功能被悄悄禁用，大家一致同意“下次做得更好”。

问题不在于演示做得不好。问题在于演示成了唯一被重视的测试。

你的 Sprint 回顾涵盖了那些常见问题：不稳定的测试、某人一直推迟的数据库迁移、用胶带勉强粘合的 API 端点。但如果你正在交付 AI 功能，代码库中最昂贵的债务恰恰是那种没人会写在便利贴上的。

传统技术债务是线性积累的。你走了捷径，之后为此付出利息，等痛苦到了一定程度再重构。AI 技术债务是复合增长的。一个默默退化的提示词会产生污染评估的训练信号，这会误导你下一轮提示词修改，进而进一步侵蚀用户体验的质量。等有人注意到时，三层假设已经在底下腐烂了。

你的 AI 产品在评估套件中获得了 82% 的分数。你向 40 个国家发布了产品。三个月后，法国和德国用户报告的质量与英语用户相似。印地语和阿拉伯语用户则悄悄停止了使用该功能。你的综合满意度评分几乎没有波动 —— 因为英语用户主导了指标池。悬崖一直都在。你只是没有测量它。

这是大多数发布多语言 AI 产品的团队都会遇到的典型情况。质量差距并非微乎其微。像 QwQ-32B 这样的最先进模型，在英语推理基准测试中分数为 70.7%，但在斯瓦希里语中则下降到 32.8% —— 这是 2025 年测试的最佳模型在性能上的 54% 相对崩溃。而且这还是 最佳 模型。这种差距并不会随着模型变大而消失。它在高资源语言中会缩小，但在其他语言中依然很大。

你的 Agent 在预发布环境中运行完美。它调用正确的工具，推理多步骤计划，并返回精心打磨的结果。然后生产环境来了：地理编码 API 在 7 步计划的第 3 步超时，LLM 在句子中间返回不完整的响应，而你的 Agent 自信地编造数据来填补空白。直到客户发现，没有人注意到。

LLM API 调用在生产环境中有 1-5% 的失败率——速率限制、超时、服务器错误。对于每个任务进行 10-20 次工具调用的多步骤 Agent，这意味着相当比例的任务至少会遇到一次故障。问题不在于你的 Agent 是否会遇到故障，而在于你是否曾经测试过它遇到故障时会发生什么。

每家在构建多 Agent 系统的公司最终都会发现同一个令人不安的事实：他们的 Agent 并没有反映技术架构图，而是反映了组织架构图。

处理客户入职的 Agent 与管理计费的 Agent 协调不好——不是因为技术限制，而是因为构建它们的团队之间本来就不怎么沟通。

康威定律——系统设计会映射构建它的组织的沟通结构——已经有五十年历史了，但从未像现在这样切中要害。在 AI Agent 时代，这条定律不仅适用，而且被放大了。当你的"系统"是一个由自主 Agent 组成的网络在做决策时，每一个组织接缝都会成为潜在的故障点：上下文丢失、交接中断、Agent 各自为局部指标优化而相互冲突。

大多数将"差分隐私"视为合规复选框的团队实际上并没有得到保护。他们在流水线的某个环节添加了噪声——也许是在微调时添加到梯度上，也许是在检索时添加到查询嵌入上——然后得出结论认为问题已经解决。合规文档写着"已启用 DP"，工程团队继续前进。

他们没有做的是：定义 epsilon 预算、核算系统将服务的每一次查询所消耗的预算，或者验证其隐私损失是否受到有效约束。在实践中，"我们添加了噪声"与"我们拥有有意义的隐私保证"之间的差距，正是大多数现实世界 AI 隐私事件发生的地方。

本文就是关于这个差距的：差分隐私对 LLM 实际承诺了什么，这些承诺在哪里失效，以及团队做出的工程决策——通常是隐性的——如何决定他们的 DP 部署是真正的保护还是表面文章。

每个 AI 产品的融资演示文稿（Pitch Deck）里都有同一张幻灯片：更多用户产生更多数据，数据训练出更好的模型，进而吸引更多用户。这就是数据飞轮。它听起来像是一台关于产品质量的永动机。在最初的几个月里，它确实奏效了——准确率攀升，用户很满意，各项指标都在持续向好。

然而，在大约第三个月的时候，曲线趋于平缓。模型不再有实质性的提升。标注队列在增长，但准确率几乎没有波动。你的团队仍在收集数据、仍在重新训练、仍在发布新版本——但飞轮已经悄然停滞。

这并非罕见的失败模式。研究显示，40% 部署 AI 模型的公司在第一年内会经历明显的性能衰减，高达 32% 的生产评分流水线在六个月内会遇到分布偏移（Distributional Shifts）。飞轮的崩溃并非伴随着巨响，而是在低语中腐朽。

大多数团队构建内容审核的方式都是错误的：他们将单个 LLM 或微调后的分类器连接到每一条用户生成内容，眼睁睁地看着延迟飙升至平台可接受的阈值之上，然后手忙脚乱地添加缓存。问题不在于缓存——而在于架构。生产规模的内容审核需要的是级联（cascade）系统，而不是单一系统，而这些阶段之间的边界决策才是大多数生产事故的根源。

这里有一个具体的数据，它将改变你对这一问题的看法：在生产级联系统中，将 97.5% 的安全内容通过轻量级检索步骤进行路由，同时仅针对风险最高的 2.5% 样本调用前沿 LLM，可以将推理成本降低到朴素全 LLM 部署的 1.5% 左右，同时还能将 F1 分数提高 66.5 点。这不仅仅是一个边际优化，而是一个架构上的必然选择。

2023 年，斯坦福大学和加州大学伯克利分校的研究团队做了一项受控实验：他们在 3 月和 6 月分别向 GPT-4 提交了完全相同的提示词，任务非常基础——判断一个数字是否为质数。3 月时，GPT-4 的准确率为 84%。到了 6 月，使用完全相同的 API 端点和完全相同的模型别名，准确率已跌至 51%。没有变更日志，没有通知，没有传统意义上的破坏性变更。

这项实验清晰地揭示了一个在多服务架构中部署 LLM 的团队迟早都会遇到的问题：模型别名不是稳定的契约。当你的下游支付处理器、推荐引擎或合规系统依赖 LLM 生成的结构化 JSON 时，你就建立了一个隐式的 API 契约——而隐式契约会悄无声息地崩溃。

每个集成工程师都曾面对过两个拒绝相互通信的系统。一个说的是 2008 年的 SOAP XML，另一个期望的是上季度刚设计的 REST JSON 负载。传统的解决方案——编写自定义解析器、维护映射层、祈祷没人改动模式——在第三或第四个系统加入之前都还能用。之后你就要维护一个没人愿意接手的组合爆炸式翻译代码了。

现在团队正在将 LLM 放入这个缺口中。不是作为聊天机器人，不是作为代码生成器，而是作为运行时协议翻译器——读取一种格式并输出另一种格式。对于某些用例，它的效果出奇地好——而对于其他用例，它的失败方式则真正令人担忧。理解这两个区域之间的边界就是整个博弈的关键。

2024 年初，Open LLM 排行榜的榜首几乎被一种从未经过训练的模型全面占领——它们是合并而来的。各团队将两三个基于 Mistral-7B 微调的变体，用一个 YAML 配置文件对权重进行平均，便以极低的计算成本超越了专门训练的模型。从外部看，这项技术简单得近乎可笑：把一些张量加在一起，除以二，就可以发布了。但现实远比这复杂——如果你不理解其背后的原理，那些锋利的故障模式足以让一个生产部署翻车。

这是一份面向希望在生产中使用模型合并的 ML 工程师的实践指南：各方法在数学上到底做了什么、何时有效、何时会悄然降级，以及如何针对给定的候选模型选择正确的工具。

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

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