详细内容或原文请订阅后点击阅览
PM 关于交付在生产中实际发挥作用的 AI 功能的手册
Production Death Valley 的演示如果您曾开发过 AI 功能，您就会知道这种感觉。你开始构建一些你感兴趣的东西，设定发布时间表。模型给出了完美的响应，原型神奇地工作了，房间里的每个人都在心里计算着这个产品将有多大 [...]
来源:O'Reilly Media _AI & ML死亡谷演示版
如果您曾开发过 AI 功能，您就会知道这种感觉。你开始构建一些你感兴趣的东西，设定发布时间表。模型给出了完美的响应，原型神奇地工作了，房间里的每个人都在心里计算着我们推出时这个产品会有多大。我去过那个房间很多次了，很有趣。
然后您在发货前尝试进行测试。
移动设备上的延迟飙升至 10 秒。该模型开始对恰好代表 15% 实际用户查询的边缘情况产生幻觉。您的 A/B 测试显示没有统计上显着的参与度提升，因为人工智能输出的差异使得传统的假设检验基本上毫无意义。安全团队在第一周标记了 340 个失败案例，而您现在每天都在调试不确定性案例，这些案例以创造性、新颖的方式失败。
通常，这不是一个模型问题，而是一个工程学科问题。交付人工智能产品与传统软件有很大不同。我费了好大劲才想通这一点。这本剧本分享了我的经验教训。
延迟预算
每个人工智能功能都伴随着延迟税。大型语言模型推理需要时间。我们谈论的是 500 毫秒到 5 甚至 50 秒，具体取决于模型大小、输入长度和基础设施设置。对于人们期望交互时间低于 200 毫秒的消费产品，这是您在设计时必须绕开的硬约束。
我最常看到的错误是团队仅测量 p50 延迟。 800 毫秒 p50 的功能听起来不错，直到您发现 p90 是 15 秒。这意味着每 100 个用户中就有 10 个用户坐在那里等待 15 秒以上。从规模上看，每天有数千次可怕的经历。
设计后备
所有这一切背后的设计原则是用户永远不应该遇到未处理的人工智能故障。每个故障模式都映射到一个特定级别，并且只要您可以管理，级别之间的转换就应该是不可见的。