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

我认识的一个团队花了六个月的时间，在他们标准的资深工程师面试流程中额外增加了一个“AI 环节”。他们面试了 70 名候选人，录用了 3 名。但这三个人中，没有一个交付的 Agent 能在生产环境平稳度过一个周末。团队将此归咎于人才市场。但人才市场没问题，问题出在面试流程。

标准的工程面试是为这样一套技术栈校准的：正确性可验证，性能可通过基准测试衡量，优秀的工程师是那些能将问题分解为确定性组件，并根据已知规范推导边缘情况的人。那套技术栈依然存在，那些技能依然重要，但预测交付 LLM 产品能力的技能群与此基本是正交的。你的流程是在为错误的职位询问正确的问题。

这是一个结构性问题，而非校准上的微调。在为确定性系统设计的流程中加入 45 分钟的“AI 环节”，并不能筛出 AI 开发者——它筛出的是既擅长经典系统又精通 LLM 的候选人交集，这是一个极其微小的群体。这导致了长达六个月的失败招聘，而大家还在纳闷 AI 工程师都去哪儿了。

针对 Agent 类产品，生产环境下最常见的投诉通常是某种形式的“它忘记了我们刚才说的话”。这种投诉往往出现在第 8 轮、第 15 轮或第 30 轮——绝不会在第 2 轮出现。团队的第一反应往往如出一辙：扩大上下文窗口。但这其实是错误的直觉，因为 Bug 不在模型本身，而在于团队将对话历史视为了终端的滚动回放（scrollback）——追加一行、渲染尾部、满了就截断。实际上，他们不知不觉中构建的是一个读多写少的数据库，具有仅追加写入、热工作集、隐藏在截断规则中的淘汰策略，以及取决于所提问题类型的查询模式。一旦你接受了这一点，整个问题的本质就改变了。

滚动回放模式之所以如此诱人，是因为聊天界面看起来就像一份对话记录。消息向下流动，用户自上而下阅读，而喂给模型的自然方式就是将最新的 N 轮对话拼接到提示词中。这种数据结构感觉是“免费”的：没有 Schema，没有索引，没有查询——只需追加、渲染、重复。在最初的几轮对话中，任何架构都表现良好。模型拥有完整的上下文，费用低廉，演示效果极佳。

每个 LLM 团队最终都会收到主管发来的同一封邮件：“Anthropic 发布了新的 Sonnet。用我们的流量跑一下测试，周五前告诉我是否应该切换。”团队打开生产环境的追踪（trace）存储，调取上个月的请求，并针对新模型排队运行——但在运行三小时后，有人发现工具调用环节的差异评分看起来非常离谱。答案是：没有人以原始形式捕捉工具的响应。追踪记录忠实地记录了模型的“回复”，并存储了每个工具返回内容的一行摘要。回放这些请求并不能回放旧模型实际看到的内容；它回放的是一段被严重压缩的投射。迁移评估并不是在衡量新模型，而是在衡量新模型如何与一个不同的现实对话。

这就是我想讨论的失败模式。大多数生产环境的 LLM 日志都是“以输出为导向”的：它们能很好地回答“模型说了什么？”，但只能模糊地回答“模型看到了什么？”。这种不对称性在你需要针对新模型回放历史数据之前是隐形的——到那时，它就成了整个问题的关键，因为日志记录与实际发送内容之间的差距，正是真实评估与虚假评估之间的差距。

称之为反事实日志（counterfactual logging）：今天就捕捉那些你明天询问“如果用另一个模型处理这个完全相同的请求，它会做什么？”时所需的输入。标准不是“我们记录了请求”，而是“我们可以针对不同的模型重新执行该请求，并确信结果是有意义的”。

一家中型 SaaS 公司的资深工程师在上个季度花了整整两天时间去排查一个部署 bug，结果发现竟然是智能体的错。该智能体读取了一份最后更新于 2023 年的运行手册（Runbook），忠实地执行了第三步，并运行了一个在当前部署工具中已不再存在的命令。这份运行手册在 Wiki 中依然渲染良好——甚至截图也依然清晰可见——但它已经悄然变得对那些无法察觉环境已过时的读者充满敌意。人类作者完全没意识到，这份文档现在已经成了每个新员工的 AI 助手的关键输入。

这就是过去 18 个月里大多数工程团队中发生的悄然转变：内部 Wiki 累积了第二批受众。同样的 Confluence 页面、同样的架构图、同样的“我们如何部署”的 Gist，现在正由两个截然不同的消费者阅读——工程师本人和工程师使用的 AI 助手。这两类读者在完全不同的约束条件下消费同样的文字，并且当文档在编写时仅考虑了第一类读者时，会产生系统性的不同故障模式。

绿色 CI 并不意味着“这个提示词有效”。绿色 CI 的本质是“编写评测的工程师想不出这个提示词会如何出错”。这是两个截然不同的断言，而它们之间的差距正是生产事故的温床。一个评测套件并不是对模型的测量——它是对编写者的冰冷写照。他们的方言、领域知识、资历、偏好的失败模式，以及他们在编写测试用例时恰好使用的模型。根据构造，工程师没想到的测试内容统统未经测试。更糟糕的是：他们会从同一个视角不断扩展套件，因此随着套件的增长，盲点并不会缩小，反而会变得根深蒂固。

这就是评测作者单一化（eval-author monoculture）问题，也是当今 AI 工程中讨论最少、风险最高的可靠性问题。团队痴迷于裁判偏差、位置偏差、冗长偏差、泄漏和污染——但上游偏差其实是最初决定测试用例的人的偏见。其他任何评测误差来源都会被它放大。如果你的套件是由一个人编写的，那么你就拥有了一个带有性格的基准测试，而这种性格正是你的 CI 能够捕获风险的无形天花板。

商业计划书中每一个“如果需要，我们会直接更换供应商”的计划，其预算表中都有提示词改写的支出。但没有一个计划包含评估套件的预算。这就是问题所在。提示词是显性耦合——那是你编写的部分，你可以通过 grep 搜索到的部分，也是一个初级工程师在一个下午就能改写的部分。而评估框架（eval harness）则是隐性耦合，当你真正尝试迁移时，它会吞掉你四分之一的路线图进度。

这种模式在议价能力变得至关重要时就会显现。你的合同到期了。竞争对手发布了一个在你的领域基准测试表现更好的模型。输出 token 的定价发生了变化。你准备让候选模型跑一遍评估套件来做决定，结果不到一天你就发现，你无法信任该框架产生的任何评分，因为框架本身是针对现有供应商编写的。你不是在比较模型，而是在拿一个模型与一个针对另一个模型校准过的测量工具进行比较。

一位产品经理写下了一段话：“助手应当乐于助人、准确且简洁，绝不能让客户感到匆忙。”一位工程师读了这段话，打开一个 YAML 文件，编写了 47 个加权标准，以便 LLM-as-judge 能够为每一个追踪（trace）生成一个分数。六个月后，那个 YAML 文件成了产品的实际规范。每一次发布都受其把关。每一次回归警报都基于它触发。每一个“达到发布质量”的决策都通过它来路由。而产品经理从未读过它。

这是当今 AI 工程中最为常见的、无意间发生的产品所有权转移。评估准则（rubric）不是对规范的衡量 —— 它就是规范，就像编译器不是对语言的描述，而是它的运行真相。就像编译器一样，评估准则也有决定语义的实现细节。哪种失败模式得 0 分而不是 0.5 分？哪个标准的权重是 0.3 而不是 0.05？哪些行为在评估准则中缺失，从而完全未被计算？每一个都是产品决策。而它们都没有出现在最初的任务书中。

LLM 产品中最昂贵的失败模式并不是一次糟糕的发布。而是连续六次好的发布——从内部所有计分板来看都是如此——而与此同时，用户的信任却在悄悄流失。离线评估分数在每个周五的演示中稳步上升。每周业务回顾中的 CSAT 曲线先是持平，然后下降，接着没人知道它是什么时候开始下降的，因为没人在交叉分析这两张图表。等到复盘总结（postmortem）点出问题时，团队已经花了两个季度的时间，针对一个在第三个月左右就不再符合现实的数据集来调优提示词（prompt）。

这就是“评估集即模拟器漂移”（eval-set-as-simulator drift），也是我所知道的一个最典型的例子：一群跳过了必读清单的 LLM 团队，正以极其惨痛的代价重新发现一个古老的机器学习教训。评估套件（eval suite）并不是一个固定的基准。它是一个模拟器，而一个从未根据它声称要预测的系统进行重新校准的模拟器，最终预测的将是另一个不同的系统。

我合作过的一个团队曾有一个 JSON 提取提示词，其中包含 11 个手工调优的 few-shot 示例。在之前的模型上，这些示例将精确匹配准确率提升了 6 个百分点。模型升级后，同样的 11 个示例反而让准确率下降了 2 个百分点。没有人更改过提示词。没有人更改过评估集。这些示例就是失效了——而且更糟的是，它们开始产生误导。

这种退化并不是新模型的 bug。它是提示词本身的一种“腐化”模式。每当团队在迁移模型版本时将提示词视为固定资产，这种现象就会出现。Few-shot 示例并不是提示词独立的一部分，它们是“模型-提示词对（model-prompt pair）”的一部分。在不重新评估另一方的情况下迁移其中一方，会产生任何绑定在单一模型版本上的评估套件都无法捕捉到的退化。

上周二发布给用户的按钮标签从未经过文案人员之手，从未在 Figma 中评审过，从未进行过 QA，甚至在推理阶段（inference time）之前都不存在。它是由一个模型生成的，该模型在对话中途决定，收集送货地址的正确方式是渲染一个包含六个字段的内联表单，而不是再进行三轮文字交流。表单生效了，标签也没问题。团队中没有人能告诉你究竟是哪次模型运行生成了它，因为追踪记录（trace）已经从热存储中移出，而评估套件测试的是文本输出，而非组件图。

这就是生产环境中的生成式 UI（Generative UI）：模型不再仅仅是一个偶尔调用工具的文本生成器。它是一个输出为组件树的 UI 编译器，而设计系统现在是模型必须遵守的契约，而不仅仅是人类松散遵循的指南。这种转变打破了一整套假设——针对静态规范的 QA、固定布局的无障碍审计、最终字符串的文案审查、构建时的设计系统一致性检查——而大多数团队在替换掉这些旧流程之前，就已经发布了功能。

一个贷款审查工具标记了一份申请。审查员点击“解释”，得到了四个整齐的要点：过去六个月的收入波动、信用额度使用率超过 70%、最近的地址变更、两个信用记录较少的被抚养人。这些理由读起来就像一位细心的核保人员写的。审查员批准了覆盖操作并继续。

令人不安的部分是：模型从未利用这些信号做出决定。它们出现在解释中，是因为它们是那种 可以 证明标记合理性的因素——而不是因为标记源自它们。实际的计算是一种模型无法表达的狭窄潜在特征模式，加上一些解释中从未提及的相关性。这些要点是事后合理化（post-hoc rationalization），其编写目的是为了可信，而不是为了真实。

这就是空洞解释问题（hollow explanation problem），它与幻觉（hallucination）不同。该解释中的每一个单独主张在事实层面可能都是正确的。但用户的问题——你为什么这么决定？——被虚假地回答了。

你的延迟仪表盘显示一切正常。p95 的首字延迟（TTFT）低于 800ms 的目标。p99 的总生成时间也在 4 秒的预算之内。然而，一位资深 PM 转发了一个支持线程：“助手在回答中途卡住了大约三秒钟”，“它停顿了一下，然后突然吐出一整段文字”，“我以为它死机了”。本周有三位用户因为同样的投诉卸载了应用。团队中没人能在笔记本电脑上重现这个问题，而且你记录的每一项指标都显示系统运行健康。

能解释这个 Bug 的指标正是你没在测量的那个：连续 Token 之间时间间隔的分布。一个看起来很完美的 p95 总时长可能会掩盖这样一种流：其中 8% 的响应在生成中途包含一个 2.5 秒的停顿。对于一个看着字符实时出现的用户来说，这种停顿意味着系统出故障了，而不仅仅是慢。你的仪表盘测量的是电影的总时长，而你的用户正在观看电影。