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

在 AI 产品开发中，有一个常见的假设：如果一个模型能处理难题，它就一定能处理附近的简单任务。这个假设是错误的，它导致了一类生产环境下的失败，而无论你读多少基准测试报告都无法为此做好准备。

这一潜在现象的研究术语是“破碎边界”（jagged frontier）——AI 的能力边界并不是一条平滑的线，并非难题在界外、简单任务在界内。它是一个参差不齐、不可预测的形状。AI 系统可以编写生产级别的数据库查询优化器，却仍然会算错图中两条线段是否相交。它们可以通过博士级别的科学考试，却在涉及空间关系的儿童谜题上失败。它们可以综合 50 页的文档，然后对自己刚刚读过的一段文字产生充满自信的幻觉。

产品团队已经开始直接将分析问题路由给 LLM：“是什么导致了流失率激增？”“为什么重新设计后转化率下降了？”“我们应该把留存预算重点花在哪个群体上？”输出结果出现在高管汇报幻灯片中，驱动着路线图决策，并向投资者展示。模型以优雅的文字和具体的数字自信地作答。然而，这些答案中有很大一部分是以一种不易察觉的方式出错的。

这并不是对用 LLM 处理数据工作的全面批评。在某些任务中，它们确实很有帮助。问题在于其失败模式是隐形的——模型不会留有余地，不会说明局限性，也不会区分“我是根据你的数据计算出来的”和“我生成了一个听起来像这个数字应该是多少的东西”。了解故障发生位置的从业者可以捕捉到真正的价值并避开雷区。

模型路由是大多数团队首先采用的优化手段：将简单查询路由到小型廉价模型，复杂查询路由到大型强力模型。它在控制成本和吞吐量方面效果良好。但当云端推理的物理限制与 100ms 以内的延迟需求发生碰撞时，路由便无能为力了。从中间层数据中心发出的一次网络往返，在生成第一个 token 之前就已消耗 30–80ms。此时路由毫无意义——你要么需要将模型运行得更靠近用户，要么需要运行一个规模大幅缩减的模型。这两条路都需要压缩决策，而大多数团队对此并没有清晰的框架。

本文是一份做出这些决策的指南。量化、知识蒸馏和端侧部署这三种技术解决的问题有所重叠，但它们的成本结构、质量表现和运营影响各不相同。

你的单次请求错误率看起来很正常。延迟在 SLO 范围内。LLM 裁判对输出的评分是 87%。接着，一位用户提交了支持工单：“我把账号告诉了机器人三次，它却一直重复问我。”另一位用户说：“它先是同意退款，两轮对话后又否认该政策的存在。”

单轮失败是显而易见的。请求进来，模型出现幻觉或拒绝回答，你的评估 (eval) 捕捉到了它，然后你修复提示词。反馈循环很紧密。多轮失败则完全不同：会话开始时表现良好，随后逐轮恶化，而你的监控从未报警，因为每个单独的回复在技术上都是连贯的。问题出在整个会话上——而几乎没有团队为此建立观测机制。

对主要前沿模型（Claude 3.7 Sonnet、GPT-4.1、Gemini 2.5 Pro）的研究显示，从单轮转向多轮对话时，平均性能会下降 39%。这个数字掩盖了真相：只有大约 16% 的下降是由于能力损失。另外 23 个百分点则是一场可靠性危机——随着对话长度增加，模型在同一任务上的最佳表现与最差表现之间的差距翻了一番。你得到的不仅是质量更差的输出，还有极不稳定的输出。

大多数 AI 产品都是为单一用户、单一意图、单一对话线程和单一身份构建的。当产品是个人生产力工具（如写作助手、代码补全引擎、摘要生成器）时，这运作得足够好。但当团队开始协作使用 AI 时，情况发生了变化：产品会以难以诊断且更难修复的方式悄然失效。两个用户同时向 AI 提问，其中一个输入消失了。五个工程师共享的上下文窗口充满了重复的历史记录。AI 使用用户 B 的权限回答用户 A 的问题。没有人为这些情况做过设计，因为交付多用户共享上下文意味着要面对现代 AI 基础设施中最难的分布式系统问题之一。

本篇文章将探讨为什么同步多用户 AI 会话如此困难、生产团队尝试了哪些方案，以及新兴的架构模式是什么。如果你正在构建协作 AI 功能并疑惑为何它感觉复杂得离谱，这就是原因。

你的监控显示一切正常。延迟处于正常水平。错误率平稳。然而，你的客服 AI 刚刚告诉 10,000 名用户退货是免费的——且是永久免费——而这根本不是公司的政策。没有触发任何报警。没有进行任何部署。模型只是自己决定这么做了。

这就是 AI 系统轮值（on-call）的现状：这类生产环境故障不会触发你构建的报警，无法追溯到某行代码，也无法通过回滚上一次部署来修复。标准的事件响应手册——检查日志、确定提交（commit）、回滚更改、验证恢复——是为确定性系统设计的。应用到 LLM 时，它们完全无法捕捉到真正的失败模式。

以下是真正有效的方法。

你的 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 的工程师。