553 篇博文 含有标签「ai-engineering」

你的产品路线图写着“进军日本和巴西市场”。你的财务模型显示 LLM API 支出项为每月 $X。这两个数字都是错的，而且你直到国际化推广前几周才会发现这一点。

Tokenization（分词）——将用户文本转换为模型可处理的整数的步骤——对英语有着深刻的偏向。一段日语文本所需的 Token 数量可能是同义英语句子的 2–8 倍。这个倍数直接影响到 API 成本、上下文窗口余量和响应延迟。那些根据英语基准测试来模拟 AI 预算，然后直接切换语言选项的团队，通常会被比预期高出 3–5 倍的账单吓一跳。

你的检索精度提升了。重排分数改善了。生成器的忠实度指标比上个季度更好。然而用户却在抱怨系统越来越差。

这是生产级 AI 工程中最令人困惑的故障模式之一，而且发生频率远超团队预期。当你构建一个复合 AI 系统——检索结果送入重排器，重排器送入生成器，生成器再送入验证器——你就继承了一个根本性的归因问题。端到端质量是唯一真正重要的指标，却也是最难付诸行动的。你无法修复"系统变差了"。你需要修复某个特定组件。而在一个四阶段流水线中，这件事出乎意料地困难。

你的 AI 功能在内部测试中表现出色。工程师拍手叫好，产品经理竖起大拇指，评估套件在基准测试中显示了 94% 的准确率。然后你上线了，两周之内，用户就遇到了你从未见过的故障模式——错误的答案、混乱的输出，以及让模型显得极为糟糕的边缘情况。

这就是生产分布差距（production distribution gap）。这不是一个新问题，但对 AI 系统来说，它比确定性软件严重得多。理解其背后的原因——并制定具体的解决方案——是决定 AI 功能悄然侵蚀用户信任还是随着使用不断改进的关键分水岭。

询问大多数工程师为什么在生产环境中使用 Few-shot 提示词，你会听到类似这样的回答：“它看起来效果更好。” 询问他们为什么要加入思维链（Chain-of-thought），答案通常是：“我读到过它有助于推理。” 这些回答并不完全错误。但它们只是披着工程外壳的惯例。关于每种提示词技术何时真正胜出的证据已经足够具体，你可以系统性地做出决定——而正确的选择可以将 Token 成本降低 60–80%，或者防止你甚至没察觉到的性能退化。

以下是研究结果，以及如何将其应用到你的技术栈中。

你的检索器在 94% 的情况下都能返回正确文档。你的 LLM 在给定良好上下文时能正确回答 96% 的问题。可以上线了。能出什么问题？

把这两个数字相乘：0.94 × 0.96 = 0.90。在不考虑任何边缘情况、提示词格式问题、token 截断，以及检索器与正确文档一起返回的干扰文档之前，你就已经损失了 10% 的查询。但更深层的问题不是这个算术——而是你的单元测试永远不会发现这一点。检索器在隔离测试中通过了。生成器在隔离测试中通过了。失败的是两者的组合，而大多数团队对此没有任何测试。

这就是检索-生成接缝：检索器交付内容与生成器实际能够使用的内容之间的接口。它是生产 RAG 系统中测试最不充分的边界，也是大多数故障的根源。

一家中型 SaaS 公司的团队在阅读了一些基准测试后，在每个提示词中都加入了“让我们一步步思考”（let's think step by step）。他们的响应质量有了明显的提升——但他们的 LLM 账单也翻了三倍。当他们深入研究日志时，发现大部分额外的 Token 都花在了支持单分类和会议记录总结等任务上，而在这些任务中，额外的推理对输出质量并没有明显的改善。

扩展思考模型对于难题来说是真正的能力飞跃。但如果不加区别地应用，它们也是一个可靠的成本陷阱。一个经过良好调优的推理部署与一个昂贵的部署之间的区别通常归结为一点：理解哪些任务真正受益于思维链（chain-of-thought），而哪些任务只是在为显而易见步骤的冗长叙述买单。

某金融科技公司首次部署AI交易审批代理时，产品团队在一周离线评估结果良好后便确信模型已准备好自主运行。他们将其推进至副驾驶模式——代理提出审批建议，人工可以覆盖——审批率看起来很不错。三周后，一个规律浮现：模型在系统性地低批准来自非英语用户的交易，这种偏差与姓名模式相关，而非风险信号。在上线前没有人检查过分段层级的性能。这不是欺诈检测失败，而是阶段门控失败。

大多数团队原则上理解AI功能应该渐进式上线。但他们缺少的是一个具体的工程框架来定义"渐进"的实际含义：哪些指标解锁每个阶段、在升级之前需要哪些监控，以及什么触发自动回滚。没有这些，自主性升级就变成了组织层面的乐观主义行为，而非可重复的工程决策。

你的 AI 功能顺利上线了。延迟很低，错误率微乎其微，HTTP 响应全是 200。六个月后，一名用户抱怨聊天机器人言之凿凿地推荐了一款你在三个月前就停产的产品。工程师深入调查后发现，系统在回答用户问题时，有三分之一的情况都是错误的——这不是因为代码部署出了问题，也不是因为依赖项升级，而是因为时间的流逝。你将一张快照交付到了奔流的河水中。

这并非假设。行业数据表明，91% 的生产环境 LLM 在部署后的 90 天内会出现可衡量的行为漂移。一个最初能在无需人工干预的情况下处理 70% 查询的客户支持机器人，到第三个月时，这一比例可能会悄然下降到 50% 以下——而此时，基础设施仪表盘全程显示的都是代表正常的绿色。“六个月悬崖”是真实存在的，它是无声的，而且大多数团队并没有能够预见其到来的监测手段。

一家电信公司发布了一款 AI 客服聊天机器人，拥有 99.99% 的可用性和低于 200ms 的响应时间 —— 每一个传统的 SLA 指标都显示为绿色。然而，在 35% 的账单查询中，它的回答都是错误的。没有任何合同条款涵盖这一点。没有任何警报触发。客户只是悄然流失。

这就是 AI 的“西瓜效应”：系统表面看起来很健康，内部却在悄悄腐烂。传统的可靠性 SLA —— 可用性、错误率、延迟 —— 是为确定性系统构建的。它们衡量的是你的服务是否回答了问题，而不是回答得好不好。在传统的 SLA 下发布 AI 功能，就像保证你的支持团队发送的每封邮件都能送达，却不对回复内容是否合理做任何承诺。

当一个人脸识别系统报告95%的准确率时，你的第一直觉是发布它。但这个直觉是错的。同一个系统可能同时对深肤色女性的错误率高达34%，而对浅肤色男性只有0.8%——40倍的差异，完全隐藏在那个令人安心的聚合数字里。

这就是聚合准确率幻觉，它正在摧毁从招聘到医疗保健再到语音识别等各个行业的生产AI功能。这种模式在结构上与辛普森悖论相同：一个在聚合层面看起来公平的模型，可以同时在每个有意义的子群体上进行系统性歧视。聚合指标是加权平均值。当某些子群体在评估集中数量较少或代表性不足时，其失败率会被多数群体的成功所稀释。

修复方法不是换一个不同的准确率阈值，而是分类评估——按子群体计算性能指标，定义差异SLO，并像监控延迟和错误率一样在生产中持续监控它们。

常见的失败模式不是构建了不起作用的AI功能，而是在不知道功能是否有效的情况下就将其上线。团队跳过评估基础设施的原因不是懒惰——而是构建评估需要标注数据，而在第一天你根本没有。

这就是评估的冷启动问题。要获得有效信号，你需要系统在生产环境中运行。要有信心地部署，你首先需要评估基础设施。这种循环依赖是真实存在的，它导致团队做出三种选择之一：没有评估就上线，在生产环境中才发现故障；延迟上线，同时花数月时间手动标注数据；或者使用合成评估——并承担其中的所有风险。

本文讨论的是第三条路如何正确走通。合成评估冷启动是可行的，但前提是你要理解它无法检测什么，并从一开始就围绕这些盲点进行设计。

大多数团队都是通过惨痛的教训才发现系统提示词蔓延（System Prompt Sprawl）问题的。AI 功能发布了，用户发现了边缘情况，而修复方案总是如出一辙：增加另一条指令。六个月后，你就有了一个 4,000 token 的系统提示词，没人能完全记在脑子里。模型开始执行一些并非初衷的任务——不是因为它坏了，而是因为你写的指令之间存在细微的矛盾，而模型正悄悄地代表你处理这些矛盾。

蔓延并不是一种灾难性的故障。这正是它的危险之处。当你的指令发生冲突时，模型不会崩溃或抛出错误。它会做出选择，通常很流利，通常看起来很合理，而且通常错误得刚好足以成为真正的支持负担。