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

你的团队上线了一个新的 LLM 功能。单元测试全部通过，CI 是绿色的，你部署了。然后用户开始反馈 AI "就是不好用"——回答格式奇怪，智能体选错了工具，在多步骤任务进行到一半时上下文丢失。你查看测试套件，它仍然是绿色的。每个测试都通过了。但这个功能是坏的。

这不是运气不好，而是当你把确定性测试哲学应用于概率性系统时必然发生的结果。经典测试金字塔——宽泛的单元测试底座、较小的集成测试中间层、狭窄的端到端测试顶端——建立在一个如此根本的假设之上，以至于没有人会把它写下来：代码每次都做同样的事情。LLM 在每个层面都违反了这个假设。建立在其上的测试策略需要从头重建。

前沿模型如今宣传的上下文窗口动辄 200K、1M 乃至 2M token。工程团队将其视为已解决的问题而继续前行。数字如此之大，我们应该永远不会触及上限。

然而，在一个自主研究任务执行六小时后，agent 开始产生幻觉，对它三小时前编辑过的文件路径一无所知。一个代码 agent 自信地打开了它在第四轮已删除的函数。文档分析流水线开始与它之前从同一文档得出的结论相矛盾。这些不是模型失败——它们是上下文预算失败：可预测、可测量，而且只要将上下文窗口视为它实际所是的稀缺计算资源，几乎完全可以预防。

AIOps 供应商圈子里没人愿意宣传的悖论是：投入超过 100 万美元用于故障响应 AI 工具的组织，其运维负担占工程工时的比例反而从 25% 上升到了 30%——这是五年来的首次增长。团队本以为自动化能替代手工劳动，结果却多出了一项新工作：在执行 AI 建议之前先验证它说的是否正确。旧的任务没有消失，反而在上面又叠加了一层验证层。

这并不是反对在故障响应中使用 AI 的论点。同样的数据显示，当 AI 被妥善整合时，平均故障解决时间（MTTR）可降低 40%，部分团队报告将排查时间从两小时缩短到了三十分钟以内。这里要表达的论点更为精准：AI 副驾驶的故障模式在性质上与传统 SRE 工具的故障模式截然不同，而大多数团队还没有做好识别这些故障的准备。

上个季度，你的团队上线了一个基于 RAG 的搜索功能。它需要向量数据库、嵌入模型、标注流水线、分块服务和评估框架。每个组件单独来看都合情合理。但六个月后，你发现这五个组件中有三个没有明确的负责人，有两个运行在工程师的个人云账户上，还有一个被供应商悄悄下线了，无人知晓。凌晨三点的告警来自一个没人记得是何时添加的组件。

这就是 AI 依赖足迹问题：每个 AI 功能所需基础设施的累积叠加，加上组织层面在上线前几乎不规划所有权的现实，共同造就了这一困局。

这里有一个令人不安的模式：你的团队计划在下个季度推出的 AI 功能，其实早在两年前就在公司里“死”过一次了。它当时以不同的名称发布，带着不同的提示词（prompt），解决一个略有不同的问题，并在经历了六个月的增长停滞后被悄然关停。没有人记录它，没有人把这些点串联起来。本可以拯救这个周期的领先指标，一直躺在那些随功能一起被归档的数据看板里。

大多数工程组织都是为了记住成功而设计的精妙机器。发布会有复盘、博客文章和内部庆祝。但那些被砍掉的功能——尽管有精美的演示，但周活跃用户仅为 12% 的功能；当 Token 成本在超预期的工具链中叠加时导致单位经济效益倒挂的功能；那些用户先是学会信任、随后失去信心、最后完全绕开的功能——几乎没有留下任何组织记忆。而这些“死亡”中蕴含的失败模式，恰恰是你的规划流程无法预估并纳入成本的。

一个法律团队的 AI 研究助手伪造了三个案例引用，并将它们混入了法庭文件中。这些引用看起来非常可信 —— 真实的法院、听起来很真实的案例名称、连贯的判决理由。在提交摘要之前，没有人发现它们。这一事件导致律所面临紧急听证会、公开道歉以及律师协会的调查。

那是 Sev-0 还是 Sev-2？答案取决于你使用的框架 —— 而传统的严重程度模型几乎每次都会给你错误的答案。

软件事故严重程度分类是为确定性系统构建的。服务要么有响应，要么没有。数据库查询要么成功，要么抛出错误。失败模式是二进制的，责任可以追溯到某个 commit，而修复方案则是回滚或补丁。AI 系统同时打破了这三个假设，如果组织将传统的严重程度框架应用于 LLM 故障，最终要么是对噪声感到恐慌，要么是将结构性故障视为偶然的异常。

当一名 on-call 工程师第一次以“模型刚才又表现得有点怪”为由关闭告警页面时，团队就已经悄然越界了。这句话同时表达了三层意思：它宣告了问题不可调查，它将未来类似的告警归类为噪音，并免除了轮值人员记录事件经过的责任。一周后，同样的特征再次触发告警，另一个人看到“之前已经关闭过一次”，于是真正的回归（regression）便会一直潜伏在生产环境中，直到有客户在 Twitter 上发帖投诉。

这种模式并不是因为懒惰。它是将标准的 SRE 直觉运行在一个不再表现出确定性的系统上所产生的必然结果。经典的 on-call 培训教导工程师将“输入相同但输出不同”的情况视为可观测性堆栈中的 Bug——这不可能是系统本身的 Bug，因为系统不会那样运作。但基于大语言模型（LLM）的系统正是在每一次请求中都以这种方式运作，这是其设计使然。如果建立 on-call 轮值机制时没有内化这一点，系统就会滑向两个极端：要么是瘫痪（每一个随机波动都是 P2 级事故），要么是虚无主义（模型总是很奇怪，别再给我发告警了）。

你的 AI 功能满意度评分是 4.2/5，用户点赞率高达 68%，A/B 测试显示任务完成率提升了 12%。团队决定上线。六周后，用户已悄然绕开它，遇到真正重要的事情时不再使用。

这就是指标表演。你优化的是看起来像成功的信号，而不是真正的成功。你收集到的反馈来自那 8% 愿意评分的用户——偏向极度满意和极度不满的两端，对那沉默的大多数一无所知——他们发现该功能时不时不可靠，于是悄悄停止信任它了。

构建 AI 功能需要一套与传统软件不同的度量哲学。你从第一天起就埋下的信号，决定了你是否能足够快地学习并改进，还是花六个月追着一个纹丝不动的满意度分数跑。

大多数团队衡量 AI 功能质量时只问一个问题："它答对的频率有多高？"而更有用的问题其实是："答错的时候，摧毁信任的速度是否超过答对时积累价值的速度？"这两个问题的答案并不相同——只有后者才能告诉你究竟该不该发布。

存在一个可靠性下限，低于这条线的 AI 功能所造成的伤害，比完全没有该功能还要大。在这条线以下，用户在遭遇足够多的错误后会学会不信任 AI；而这种不信任会泛化——即便 AI 给出了正确答案，他们也会绕开它，最终彻底放弃使用。届时，你发布的不是一个部分有用的产品，而是一个披着功能外衣的转化率与留存率杀手。

你会花一个下午的时间来调整提示词（prompt）。你会移动一个句子的位置，把“classify”（分类）换成“categorize”（归类），添加一条关于边缘情况的注释，并针对笔记本中记录的少量示例进行抽查。到这一天结束时，提示词有了略微的改善——你觉得是这样。但你无法证明这一点。你没有一个可重复的基准。一周后，一位同事改动了几个词，整个系统就退化了。

这就是目前大多数团队提示词工程的现状。DSPy 是斯坦福大学给出的答案。与其手动编写指令文本，你只需声明你的 LLM 程序应该做什么，定义一个指标，然后让优化器为你编译实际的提示词。MIPRO——多提示词指令提案优化器（Multi-prompt Instruction PRoposal Optimizer）——是一种让这种方法能与人工编写的替代方案竞争（且通常优于人工编写方案）的算法。

某公司在向整个工程团队全面推广 AI 编程助手三个月后，发现了一个令人不安的现象：代码审查通过率下降了 18%，迭代速度有所提升，但生产故障数量却在攀升。当他们在一次事后复盘中要求开发者解释最近一个由 AI 生成的模块时，在场的所有人都说不清楚——就连提交合并的那位工程师也不例外。

这就是认知外包陷阱。问题的根源不是 AI 工具本身，而是团队整合它们的方式。

大多数构建 AI 流水线的工程师都会孤立地评估每个组件：检索成功的频率是多少，LLM 做出正确判断的频率是多少，下游工具调用成功的频率是多少。如果每个答案都是"95%"，系统看起来相当稳固。

然而事实并非如此。三个各为 95% 的组件组合在一起，只能给你一个 86% 可靠的系统。再加第四个 95% 的组件，降到 81%。加第五个，低于 77%。那些看起来质量很高的独立组件，在你发布任何功能之前，就会组成一条五次请求中就有一次失败的流水线。

这就是复合故障问题——大多数 AI 工程团队在用户开始提交工单之前从未去做的那道数学题。