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

一位产品经理写下了一段话：“助手应当乐于助人、准确且简洁，绝不能让客户感到匆忙。”一位工程师读了这段话，打开一个 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 秒的停顿。对于一个看着字符实时出现的用户来说，这种停顿意味着系统出故障了，而不仅仅是慢。你的仪表盘测量的是电影的总时长，而你的用户正在观看电影。

当今大多数智能体 (agent) 产品都达成了一个简单的契约：模型决定做什么，用户点击“批准”。对于低风险的消费者聊天场景 —— 预订餐厅、摘要收件箱、起草非正式回复 —— 这确实是正确的形式。但对于法律起草、财务咨询、医疗分诊和事件响应来说，这却是灾难性的错误。在这些场景中，用户承担着模型永远无法承担的问责，而且错误 计划 的成本远高于任何单个 步骤 的成本。

反向智能体翻转了这种极性。用户将计划构思为一系列命名的、可重新排序的步骤。模型按需执行每个步骤 —— 拥有完整的上下文、工具访问权限和推理能力 —— 但绝不决定下一步该做什么。模型可以提供建议，但建议仅供参考，不具有自主性。这并不是一个更糟糕的自主智能体；它是一个完全不同的产品，虽然其成本和延迟表现绝对更差，但信任度绝对更高，专门针对那些否则会完全拒绝采用自主版本的用户。

团队一直在犯的错误是将“自主性”视为默认的努力方向。它其实是一个你在每个界面上选择的 UX 维度。如果搞错了极性，你交付的功能就会被那些承担最高风险的用户悄悄拒绝使用。

一个回归告警在周一早晨响了。你的留出评估集的忠实度（Faithfulness）在周末从 0.86 掉到了 0.78。没人发布新模型，没人动过提示词，也没人改过检索索引。值班工程师花了三个小时排查才发现，唯一改变的是裁判模型——自动评估器静默滚动到了一个更新的快照，它捕捉到了旧版本放过的细微委婉语。同样的答案，同样的模型，更低的分数。真实的数字，虚假的回归。

这就是评估困境：随着你的 LLM-as-judge（以 LLM 作为裁判）变得更敏锐，你在固定系统上的得分会下滑，而那个本应检测回归的仪表盘开始制造回归。没注意到这一点的团队会花上几个季度去追逐完全存在于“尺子”里的“质量偏移”。

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

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

我上个季度合作的一个团队看着他们的 LLM-as-judge 分数在六周的提示词（prompt）迭代中从 78% 飙升至 91%。他们发布了产品。但用户却非常讨厌它。新的提示词产生了更长、格式更丰富、听起来更自信的回答 —— 而评委（judge）爱死了每一个回答。团队并没有构建出更智能的提示词。他们只是对评委的偏见进行了逆向工程。

这是团队中没人审计的失败模式。LLM-as-judge 有据可查的系统性偏见：无论质量如何，更长的回答得分更高；在两两比较中，第一个选项胜出的概率高于随机概率；且看起来像评委自身训练分布的输出得分高于不符的。如果你在十二个月前接入了一个 LLM 评委，且从未针对人类进行重新验证，那么你的分数就不是质量信号 —— 它们衡量的是你的提示词学会如何操纵其评估器的程度。

令人沮丧的是，捕捉这一点的审计方法很直接，防止它的校准纪律也很廉价，但几乎没有团队会执行其中任何一项。

当你第一次用经典的 SRE 复盘（Postmortem）模板来分析 LLM 事故时，模板赢了，而事故输了。时间线、诱因、缓解措施、预防措施 —— 每个字段都填好了，每个复选框都勾选了，但在文档的最后，没人能回答唯一重要的问题：究竟是哪个变量发生了变动？不是部署事件。不是基础设施故障。不是代码变更。而是 Prompt 的修订、路由选择的模型切片、未触发报警的 Eval 评分所用的 Judge 配置、质量投诉发生时的检索索引状态、规划器（Planner）正在组合的工具 Schema 版本，或者是异常时间段内的流量组合。这些在模板里都没有对应的一行。

SRE 模板并不是为那些“事实来源是观察到的行为而非代码路径”的系统设计的。在 LLM 技术栈中默默变动的变量，正是模板从未需要列举的变量。强行借用模板，只会产生那种被归类为“持续调查中”的“我们不知道发生了什么变化”的复盘报告。

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

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