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

你的 p99 延迟刚刚飙升到了 12 秒。警报在凌晨 3:14 响起。你打开运维手册 (runbook)，看到如下指令：检查数据库连接池、验证负载均衡器、重启服务。你三样都做了。延迟依然居高不下。服务并没有宕机——它正在运行且有响应。但有些地方不对劲。事实证明，由于最近的一次提示词 (prompt) 变更无意中开启了“啰嗦”模式，模型生成的响应比平时长了三倍。运维手册里没有关于这一条的说明。

这是工程团队尚未准备好应对的新一类值班事故：系统正在运行，但模型表现异常。传统的 SRE 运维手册假设的是二进制的故障状态。AI 系统是以概率方式失效的，其症状看起来不像停机，而更像“漂移”(drift)。

你的 AI 演示确实令人印象深刻。高管观众们纷纷点头，工程副总裁（VP of Engineering）直言“这就是未来”，试点项目也获得了真金白银的预算批准。六个月后，周活跃用户数（WAU）停滞在 12%。在全体会议上，这款工具会被客气地提及。没人忍心宣布它已经失败。这就是试点坟场（pilot graveyard）——优秀的演示项目最终消亡的地方。

这种失败并非个案。大约 88% 的企业 AI 试点项目从未进入生产阶段。只有 6% 的企业成功地将生成式 AI 项目从试点推向了具有一定规模的生产环节。从“会议室里令人惊艳”到“日常工作流中的支柱”之间的巨大鸿沟，正是大多数企业 AI 投资付诸东流的地方。

原因不在于模型，而在于演示之后发生的一切。

大多数构建 AI 功能的团队认为，一旦产品发布，用户反馈就会成为后续可以利用的资源。记录点赞和点踩信号，积累足够的量，最终进行微调。现实情况更为棘手：一年的反应记录并不等同于一年的对齐质量训练数据。这两者之间的差距，正是对齐技术——RLHF、DPO、RLAIF——要么拯救你，要么令你措手不及的地方。

这篇文章不是对对齐研究的综述。它是一份面向工程师的决策指南，旨在帮助你从数据收集的角度理解这些技术的需求，从而确保你今天部署的埋点确实能够支持你计划在六个月后进行的微调。

大多数团队都是在用户发现问题之后，才意识到自己的提示注入防御已经失效。你把"忽略所有先前指令"加入屏蔽词列表，然后上线。三个月后，攻击者将载荷进行 Base64 编码，或将指令藏在 RAG 检索到的 HTML 注释里，或使用错字混淆手法（"忽略所有之前的指示"），你的防御瞬间土崩瓦解。屏蔽词列表无济于事，因为提示注入的攻击面是无界的——不存在封闭的恶意输入词汇表。

在流量较低时，你可以承担为每个请求调用第二个 LLM 进行验证的成本。但在每天十万次请求的规模下，这笔账算不过来，延迟也会让用户明显感知。本文探讨的是当暴力解法失效后，架构应该如何设计。

大多数提示词迁移在预发布环境看起来都很顺利。90% 的测试用例通过，新模型的响应感觉更清晰，演示也运行得很流畅。然后你上线了，不到两天，结构化输出解析器开始在 12% 的响应中抛出异常，一个面向用户的分类流水线开始返回错误标签，一个工具调用 Agent 在一个之前能正常处理的 Schema 上陷入了循环。没有人改动过提示词。是模型变了。

这就是提示词-模型耦合陷阱：在某个模型上可靠运行的提示词，会悄然积累对该模型特定行为怪癖的依赖，而这些依赖在迁移日之前根本看不见。

你的评测集（eval suite）显示准确率为 94%。但用户反馈，对于名字不是 "John" 或 "Alice" 的情况，该功能是失效的。这两者都是事实，而它们之间的差距有一个专门的名字：你精心挑选的测试集只编码了你已经预料到的失败模式。

基于属性的测试（Property-based testing，简称 PBT）诞生于 1999 年，旨在揭示确定性软件中正是这一类的盲点。将其应用于 LLM 输出时，它会自动生成数以万计的对抗性输入变体，探测手写测试用例在结构上无法触及的领域边界。2025 年的一项 OOPSLA 研究发现，平均每个基于属性的测试发现的变异 Bug 数量大约是普通单元测试的 50 倍。另一项研究测量出，PBT 和基于示例的测试（EBT）在不同的 Bug 上会失败——将两者结合后，检测率从 68.75% 提高到了 81.25%。这 12.5 个百分点的差距并非舍入误差，它代表了单一方法无法察觉的整整一类故障。

本文面向那些已经拥有评测集，并希望找出那些评测集在结构上无法发现的 Bug 的工程师。

RAG 系统中存在一种常见的失败模式，数月内都不会被察觉：你的检索器（retriever）返回了错误的文档，但你的生成器（generator）足够擅长即兴发挥，以至于端到端的质量分数依然保持绿色。你不断调整提示词（prompt）。你升级模型。但都无济于事。这个 Bug 存在于上游三层，而你的指标对其视而不见。

这就是检索器评估反模式（retriever eval antipattern）——将整个 RAG 流水线作为一个整体进行评估，这让生成器吸收并隐藏了检索失败。其结果是，你无法区分是“生成器失败”还是“检索器失败”，从而使得系统性的改进几乎变得不可能。

大多数团队发现 Schema 问题的方式都是错误的：下游服务开始返回乱码，仪表盘充斥着垃圾数据，经过 20 分钟的调试才发现，LLM 在三周前就开始悄悄地将其 JSON 包装在 Markdown 代码块中。没人注意到，因为应用程序没有崩溃 —— 它只是在静默地消耗格式错误的数据。

修复方法只是修改了一行提示词。但造成的损失是数周的错误分析和一次非常尴尬的复盘。

Schema-first 开发是防止这种情况发生的准则。这意味着在你编写任何提示词 Token 之前，先定义 LLM 输出必须遵循的确切结构。这并不是为了限制创造力；而是将输出格式视为下游系统可以依赖的契约，就像你在编写消费者端代码之前会先对 REST API 进行版本化一样。

你的客服智能体稳定运行了三个月。一次例行模型更新在周二悄然上线。到周三下午，三个下游服务已在静默地解析智能体响应中的错误字段——JSON 键值发生了微妙变化，但没有任何报错。到周四，你追溯到订单完成率下降，原因是某个 JSON 字段从 "status" 被重命名为 "current_state"。模型更新了，智能体版本号仍是 v2.1.0，没有人收到告警。

这正是传统 API 设计从未需要解决的版本管理空白。语义化版本控制（Semver）在能够从规范中确定性地复现输出时才有效。AI 智能体无法做出这种承诺。然而下游服务对其行为的依赖程度，与对任何微服务 API 的依赖一样关键。"我们打了一个发布标签"与"下游消费者受到了保护"之间的鸿沟，从未如此之大。

你的红队刚完成了一次越狱扫描。他们发现了三个新型攻击向量，将其整理成文档，并把这些提示词放入共享提示词库，供其他人学习。一周后，安全团队运行基线评估，报告鲁棒性提升了 12%。所有人都在庆祝，却没人问为什么。

实际发生的是：安全团队的基线评估悄悄纳入了红队的攻击提示词。模型并没有变得更健壮——是评估被污染了。你的基准测试现在衡量的是对已知攻击的免疫力，而非对新攻击的泛化能力。

这就是共享评估基础设施污染问题，它比大多数团队意识到的要普遍得多。症状是指标被人为拉高，根本原因是把评估基础设施当生产基础设施来对待——优化了共享和效率，而非隔离性和保真度。

你的 AI 功能准时上线了。用户正在使用它。一切看起来都很正常 —— 直到一季度后，一张支持工单揭露了系统已经“一本正经地胡说八道”了好几周，你的评估套件（evaluation suite）什么也没抓到，而向量索引正悄无声息地返回过期结果。没有任何环节崩溃。系统全程返回 200 OK。

这就是 AI 技术债务的样子。它不像失败的单元测试或堆栈溢出，而是以一种温和且概率性的方式退化。你不会遇到崩溃 —— 你面对的是微妙的质量侵蚀。主要由三种不同的负债驱动：提示词债务（prompt debt）、评估债务（eval debt）和嵌入债务（embedding debt）。每一项都独立积累，每一项又都在加剧其他的债务。而大多数工程团队正同时背负着这三者。

你的测试套件通过了。CI 是绿色的。你发布了新的 prompt。三天后，一个用户反馈你的 API 正在返回带有尾随逗号的 JSON——而你的下游解析器已经静默丢弃数据长达 72 小时。你从没为此写过测试，因为 LLM 在开发环境中"总是"返回合法的 JSON。

这就是毁掉 LLM 驱动产品的失败模式：不是灾难性的模型崩溃，而是确定性测试套件在结构上无法捕获的安静、间歇性的降级。根本原因不是懒惰——而是当你的系统产生非确定性的自然语言时，"期望 == 实际"的整个范式就失效了。

修复这个问题需要重新思考你在测试什么，以及对于 LLM 驱动的 API 而言"通过"究竟意味着什么。那些弄明白这一点的工程师并没有编写更聪明的相等性断言——他们编写的是根本上不同类型的测试。