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

打开任何季度计划电子表格，你都能找到团队交付的每一个功能、每一张外包发票、每一项云服务支出。你找不到的是那些从未发生的停机事故、在触达客户前被拦截的幻觉退款，或者是凌晨 2 点被评测（eval）拦截的 Prompt 回归。这些“非事件”没有 SKU。它们不产生工单、没有复盘报告，也没有 Slack 讨论串。因此，当评测预算面临续约时，它在与拥有 Demo 的功能争夺人力配额——而且几乎每次都会输。

这不是勇气的问题。这是一个衡量标准的问题。评测投资同时兼具安全网和测试套件的属性：它悄无声息地产生复利，在规避灾难中体现价值，而其全部价值都建立在“反事实（counterfactual）”之上。财务部门在结构上对反事实视而不见。如果你领导一支 AI 团队，你的工作不是去争论评测是否重要——这一点每个人都会点头同意。你的任务是让那些只相信电子表格的人，能够看懂这种具有复利效应且无形的投资回报。

你开启了一个“评测工程师 (eval engineer)”的招聘需求。一周后，你的招聘人员问了一个显而易见的问题：这个岗位的职级是什么，一份优秀的简历长什么样？你给不出答案。两年前，这个头衔还不存在。没有职级评定标准，没有标准的面试流程，LinkedIn 上也没有现成的“评测工程师”人才库。你在为一个行业尚未达成共识是否存在的职位进行招聘。

这是交付 AI 系统过程中一个隐形的瓶颈。模型是现成的，基础设施是可租用的。你无法从市面上直接买到的是这样一种人：他们的实际工作是确保基于 Prompt 的系统保持“诚实”——而你那套为拥有数十年先例的岗位而构建的招聘机制，并没有给他们留位置。

直觉是等待。等待头衔标准化，等待培训班批量产出候选人，等待别人写出你可以照搬的职级指南。这种直觉是错误的。无论头衔是否存在，工作就摆在那里，而现在就开始组建团队的人，会在竞争对手还没开启招聘需求之前，就摸索出什么是真正的“优秀”。

故障复盘进行得非常顺利，直到遇到了一个没人能回答的问题。下午 2:14，结构化输出错误激增，某个收入工作流停滞了 90 分钟。时间线还原得很清晰：三周前，有人修改了系统提示词（system prompt），多加了几个关于“对话语气”的词，这在特定输入下悄悄导致模型偏离了 JSON 契约。修复方法很简单，只需一行代码回滚。但接下来的部分很难：有人问是谁做的改动，谁审核的，以及未来哪个团队负责维护这个提示词。房间里陷入了沉默。没有 Pull Request，没有审核人。改动是某个人在晚上 11 点通过厂商控制面板操作的，而那个人已经不记得这回事了。

那种沉默才是真正的事故。JSON 契约的失效只是症状。根因在于，系统中杠杆率最高的一处行为逻辑，竟然没有负责人，没有变更历史，也没有走任何管理其他生产环境变更的流程。模型没有出错。模型完全按照指令行事。失败之处在于，“指令”本身完全脱离了变更管理。

这是目前最常见的生产环境 AI 事故之一，而且几乎从未被正确命名。复盘报告在根因栏写下“提示词退化（prompt regression）”然后就此揭过。但“提示词退化”描述的是代码表现。真正的根因是组织架构图上的一个漏洞。

在你的代码库某处，有一行代码看起来像 retriever.search(query, top_k=8)。某位工程师在某个下午写下了那个 8。它从未被团队以外的任何人评审过，从未出现在规范文档中，也从未被重新审视。这一个整数决定了你的上下文窗口中有多少配额分配给了检索到的文档而非对话历史，决定了每次请求的成本，决定了响应速度的感官体验，并且——由于语言模型在长文本下的实际表现——还决定了答案的准确性。

这是一个产品决策。它却被硬编码在一个 f-string 里。

一名用户拨打你的保险语音代理，询问关于其免赔额（deductible）的问题。语音识别器听到了 "the duck tibble"。你的语言模型接收到了字符串 "the duck tibble"，发现它逻辑不通，于是要么提出了一个令人生疑的后续问题，要么——更糟糕的是——胡编乱造了一个关于并不存在的产品答案。用户挂断了电话。你的日志显示了一次成功的交互：音频输入，生成转录，产生回应，没有抛出错误。

这就是几乎每个生产环境中的语音代理都存在的隐蔽失败。语音转文本系统完成了它的工作——它产生了一个最优的猜测。语言模型完成了它的工作——它对收到的文本进行了推理。而 Bug 就存在于它们之间的鸿沟中，存在于一个将概率猜测重新标记为事实的交接过程中。

每天，你的智能体（Agent）都会把失败案例打包成“礼物”发还给你。一名用户点击了“踩”。另一名用户读完答案后一言不发，直接关掉了标签页。第三名用户将同一个问题改写了三次，直到智能体终于答对。每一个都是带标签的失败案例 —— 真实的输入、真实的上下文、系统失误的真实时刻 —— 由那些最希望系统运行正常的人免费提供给你。

大多数团队都会把这些信息全部丢掉。并非故意为之。点击“踩”只是增加了仪表盘上的一个计数；放弃使用表现为留存图表中的一次下滑；改写问题看起来就像普通的日常使用。没有任何东西能将信号及其产生的上下文一并捕捉，因此也就无法进行回放、分选（Triage）或转化为测试用例。你所拥有的最丰富的评估数据源正擦肩而过，而团队却还在继续手动编写合成的评估（Eval）案例。

这就是你从未构建的智能体反馈循环。它不是你忘记购买的某种工具，而是一条流水线 —— 从用户信号，到分选后的失败案例，再到新的评估案例 —— 它之所以未能建立，与技术本身关系不大。

财务部门对你发布的每个功能都会问一个问题：“每个用户的成本是多少？”对于传统功能，答案是一个数字。页面渲染、数据库查询、推送通知 —— 每一个的边际成本在不同请求之间几乎没有波动。你测量一次，乘以用户数量，预测就能成立。

AI 功能打破了这种契约。问一下“这个智能体（agent）每次请求的成本是多少”，坦诚的回答不是一个数字，而是一张直方图。同一个智能体，处理上一个工单可能只花 2 美分，但在处理下一个工单时可能会烧掉 4 美元。因为用户问了一个模糊的问题，智能体循环调用了 11 次工具，而每次调用都将不断增长的对话全文重新输入模型。这两次请求的平均值 —— 2 美元 —— 既无法描述其中任何一次请求，更无法真实反映最终账单。

这就是陷阱。当你向财务提交一个单一的平均成本时，你并不是在简化混乱的现实。你是在报告一个在特定的、昂贵的方向上完全错误的数字。

编程面试的设计初衷是为了隔离单一变量。把一个人关在房间里，给他们一个问题，拿走他们的参考资料，观察他们是否能独立将问题转化为可运行的代码。这种形式的一切——白板、空白编辑器、禁止查阅资料——都是为了剥离协作者和工具，从而衡量一种被隔离的技能：这个人能否在压力下独自编写出正确的代码。

这项技能已不再是工作中需要锻炼的技能了。2026 年的日常工程工作是工程师与智能体（Agent）之间的协作。工程师决定构建什么，智能体起草大部分代码，而工程师真正的任务是审查、纠正，并判断智能体何时在“自信地犯错”。面试衡量的是独立产出代码的能力。而工作奖励的是指导一个不知疲倦、快速、偶尔产生幻觉的协作者。代理指标与目标已经脱节，而大多数招聘流程尚未察觉到这一点。

这并不是在抱怨作弊，尽管作弊是每个人都关注的症状。这是一个测量问题。当你无法再观察到测试旨在隔离的变量时，测试就不再产生信号——而一个在所有人仍然信任它的同时却不产生信号的测试，比根本没有测试更糟糕。

一个新的嵌入模型登上了排行榜。它比你 18 个月前发布的模型得分更高，API 只需更改一行代码，甚至维度也一致。有人提了一个工单：“升级嵌入模型”。这看起来就像更换一个日志库一样简单。

事实并非如此。嵌入模型并不是你检索系统的一个普通组件——它就是你检索系统所处的坐标系。更换它并不会改进你的索引，而是会让索引失效。而最残酷的地方在于，系统并不会崩溃。没有异常，没有失败的健康检查。你的搜索只是开始返回微妙不同的结果，而在 RAG 管道中，“微妙不同”意味着不同的文档被喂给了模型，也就意味着不同的答案最终传达给用户。

你在 18 个月前编写了这套评估集（eval set）。那时它是一个非常有用的工具：低价模型的得分是 71%，更好的模型得分是 84%，而当出现回归（regression）时，分数会下降并被察觉。这套测试套件在 CI 中赢得了一席之地。于是你不再关注它了。

今天再运行它，每个候选模型的得分都是 96、97、98。新版本的得分与旧版本相同。你怀疑表现较差的模型与你认为更好的模型得分也一样。仪表盘上的数字依然显示为绿色，检查依然通过，但它实际上什么也没告诉你。你的评估集并没有坏。它只是变简单了——因为底层的模型变强了——而没人在意它失去区分度的那个瞬间。

这就是评估饱和（eval saturation），这不仅是你可能遇到的失效模式，更是任何静态测试套件在足够长的时间跨度下必然走向的终局。一个所有模型都能通过的测试，已经不再是测试了。

每一个成熟的 AI 团队构建其评估套件的方式都如出一辙，而且几乎没有人会公开说出那个潜台词。生产环境中出现了一个故障。有人写了一份复盘报告。一名工程师将该事故提炼为一个测试用例，将其添加到评估套件中，于是仪表盘再次变绿。重复这个循环一年，你就会拥有几百个案例、一个令人满意的通过率，以及一个足以让你在演示幻灯片上感到无比安心的数字。

潜台词是：那个评估套件其实是一个博物馆。每一件展品都是团队已经挺过来的故障类别。98% 的通过率证明了你的系统可以抵御过去 —— 抵御那些已经发生过的特定破坏方式 —— 而对于模型迁移、提示词编辑或用户行为转变即将引入的新型故障模式，它几乎给不出任何参考。评估集是一个披着先行指标外衣的滞后指标。

你发布了一个模型升级。评估套件的分数从 87% 提升到了 91%。更新日志信手拈来，领导层纷纷鼓掌，然而那些真正重要的仪表盘——用户满意度、工单升级率、点踩率——却毫无动静。毫无起色。甚至可能略微变差了。

这是 AI 工程中最令人迷惑的失败模式之一，因为表面上没有任何东西坏掉。评估运行正常。数字是真实的。在你测试的 600 个示例中，模型确实有所改进。问题在于，这 600 个示例是你构建套件那一周的流量快照，而在那之后的几个月里，你的用户已经走出了画面。