从惊艳 Demo 到稳定上线,AI 功能生产化的工程方法论
翻译:Transwan 校对:Carl Cui 从 Demo 到生产的“死亡之谷” 如果你做过 AI 功能,大概率有过这样的体验:团队在开发一个让人兴奋的新功能,发布排期已经敲定;模型能给出近乎完美的回答,系统原型看起来就像德芙那样丝滑。会议室里,每个人都开始想象它上线后会变成一个流行的产品,许多次,我曾坐在这样的会议室里,那种气氛确实很棒。 然后,你开始做发布前测试: 移动端延迟飙升到 10 秒;模型在占实际用户查询 15% 的边缘案例上开始产生幻觉。经过一番努力,你从 A/B 测试结果上看不到明显的提升,因为 AI 输出的方差太大,使得传统的假设检验基本上失效。安全团队第一周就标出了 340 个失败案例,而你每天都在调试那些以各种新颖方式失败的非确定性案例。 很多时候,这不是模型能力问题,而是工程规范问题。发布 AI 产品和交付传统软件很不一样,我吃了苦头之后才明白这一点。下面这份 playbook,就是我从这些经验里总结出来的经验教训。 延迟预算 每个 AI 功能都会带来额外的延迟开销。大语言模型推理需要时间,实际可能是 500 毫秒,也可能是 5 秒,甚至 50 秒,这取决于模型大小、输入长度以及基础设施配置。对 ToC 产品来说,用户往往期待低于 200 毫秒的交互响应,所以系统响应延迟不是一个上线后再优化的小问题,而是设计阶段就必须正面处理的硬约束。 我最常见到的错误,是团队只看 p50 延迟。一个 p50 为 800 毫秒的功能听起来还不错,直到你发现它的 p90 是 15 秒。这意味着每 100 个用户里,就有 10 个要坐在那里等 15 秒以上。放到规模化产品里,这就是每天成千上万次糟糕体验。 我的做法是按交互类型定义延迟预算,而不是给所有场景设一个统一标准: 同步交互,也就是用户盯着 loading 状态等待结果的场景,应该在 1 秒内完成 渐进式交互,也就是输出逐个 token 流式返回的场景,首个 token 应该在 500 毫秒内出现,完整响应最好控制在 5 秒内 异步交互,也就是用户可以继续做别的事的场景,可以在有进度提示的情况下放宽到 20 秒左右 冷启动也要单独测量。模型加载到内存后的第一个请求,可能比后续请求慢 10 倍。如果你的流量是突发型的,冷启动会特别惩罚那些在高峰时段进入产品的高活跃用户。 ...