评测、监控与 token 账单 —— AI 翻车了为什么没人知道
普通课约 40 分钟
本课导读
上一课拆了 ByteByteGo 那张「Why AI demo fails in production」的数据侧三个原因——脏数据、检索失败、数据漂移，回答的是「AI 应用为什么会坏」。本课拆剩下五个，回答两个更扎心的问题：「坏了为什么没人知道」（评测过期、监控失明），以及「没坏也能拖垮你」（token 成本、prompt 耦合、级联失败）。
继续用上一课的假想项目当例子：学径的 AI 助教「小径」。预计 40 分钟。
原因四：评测集过期——95 分的假信心
图中第 3 条：Outdated evals create false confidence（过期的评测制造假信心）。
先补名词：eval（evaluation，评测）就是给 AI 应用出的考试卷——一组「标准问题 + 期望答案」，每次改动后跑一遍，看得分。对标你熟悉的东西：它就是 AI 界的回归测试（上个单元 DX 工具链的第六层），或者说——学径的 Quiz 就是给人出的 eval，eval 就是给 AI 出的 Quiz。
信息图里画的翻车现场：团队拿着一套老测试集反复跑，仪表盘常年 95 分，一片绿——但线上真实用户的问题在演变（上一课的数据漂移！），而这些新问题从来没有被加进评测集。于是出现魔幻一幕：评测 95 分，用户天天被错误答案折磨。
拿学径类比一秒钟就懂：如果古诗文 Track 上线后，你考核「小径」的卷子还是三个月前只有编程课时出的那套——它文言文答得一塌糊涂，卷面分照样 95。卷子没更新，考的永远是去年的题。
提示
规则一句话：评测集必须从生产流量里持续采样回填——用户真实问过、尤其是答砸了的问题，要不断补进卷子。评测集是活的，冻结的那天就是假信心开始的那天。
原因五：传统监控只看「活着没」，不看「答对没」
图中第 4 条：Standard monitoring misses AI failures（标准监控漏掉 AI 故障）。
你部署学径用的 Vercel 仪表盘，监控的是传统三件套：服务活着没（uptime）、报错率（5xx）、响应快不快（延迟）。这套体系有个隐含假设：请求成功 = 结果正确。传统软件里这基本成立——代码逻辑错了通常会炸出异常。
AI 应用把这个假设打碎了：模型返回错误答案时，HTTP 状态码是 200，延迟正常，无异常抛出——在传统监控眼里这是一次完美的请求。信息图里那条链路特别讽刺：模型胡说 → 静默失败 → 没有告警 → 仪表盘全绿。这类故障有个专名：silent failure（静默失败）——系统坏了，但每个仪表都显示正常。
解法是给监控加上 AI 专属指标层：答案质量抽检（定期抽样人工或用另一个模型打分）、幻觉率、拒答率，还有一个特别聪明的信号——用户改写率：用户把同一个问题换着法子重问，就是在用行为投差评，这比任何指标都诚实。
注意
一句话记牢：传统监控回答「服务还活着吗」，AI 监控必须回答「它还说真话吗」。仪表盘全绿从来不等于用户没在受苦——上一课说 AI 的正确性是统计性的，那么监控它的方式也必须是统计性的。
原因六：token 成本——demo 一次调用，生产复利计费
图中第 5 条：Token costs compound at scale（token 成本随规模复利）。
LLM 按 token（词元，约等于半个到一个汉字/单词）计费，输入输出都算钱。demo 阶段一次调用几分钱，感知约等于零——这正是陷阱：它是你用过的第一种「每次调用都计费、且调用量会自我放大」的资源。
放大来自三个乘数，信息图里那条陡峭的曲线就是它们乘出来的：
| 乘数 | demo 时 | 生产时 |
|---|---|---|
| 用户量 | 你一个人点两下 | 全量用户天天用 |
| 调用次数 | 一问一答，1 次调用 | Agent 模式反复试错重试，一个任务几十次调用 |
| 上下文长度 | 短提问 | RAG 塞资料 + 历史对话越滚越长，每次都重复计费 |
第二个乘数你有切身体会：你在 Claude Code 里发一句话，背后是模型读文件、跑命令、看报错、改代码的几十次调用——Agent 的强大和烧钱是同一件事的两面。
对策有个专名叫 FinOps（成本工程）思路：缓存重复问题的答案、小模型分流（简单任务交便宜模型，难题才上贵的）、上下文瘦身（别把整本手册塞进每次请求）。核心心法：成本要在架构设计时算，不能等账单来了再算——因为它是复利的。
原因七：prompt 和代码焊死——改一个字，重新部署
图中第 7 条：Prompt coupling causes deployment risks（prompt 耦合带来部署风险）。
prompt 就是发给模型的那段指令文本（「你是学径的助教，请基于以下资料回答……」）。它长得像配置，团队却常把它当代码——硬编码在业务逻辑中间。后果：想把「回答口吻再亲切一点」这种文案级改动上线，也要走完整的代码部署流程；信息图里画的更糟——prompt 和逻辑代码混在一次提交里合并，一个 minor change 引发 deployment failure，想回滚 prompt 还得连着代码一起回滚。
这个坑你其实早就用架构躲过一次了：学径的课程内容住在 content/，站点逻辑住在 src/——改课程错别字从来不用动代码。prompt 的正确待遇一模一样：它是内容/配置，不是逻辑，应该独立存放、独立版本管理、独立发布（改完不用重新部署代码），甚至独立做 A/B 测试。业界管这个方向叫 prompt management，工具名不重要，记住分层：逻辑归代码管，措辞归内容管。
原因八：级联失败——流水线上没有质检员
图中第 8 条：Cascading failures break pipelines（级联失败击穿流水线）。
「小径」的一次回答是条流水线：输入 → 检索 → 生成 → 最终回复。信息图指出的要害是：步骤之间没有任何验证检查（no validation checks between steps），于是第一个环节的错误一路畅通无阻——检索空手而归？照样把空上下文递给模型；模型基于空资料开编？照样把编好的答案端给用户。最终产出还是最危险的那种：sounds confident but is wrong——听起来自信满满，但是错的。
注意这跟上一课「检索失败导致幻觉」的关系：那一课讲的是第一张骨牌为什么会倒，这一条讲的是为什么后面没有任何东西能拦住它。
解法就是传统工程的防御性编程，在步骤间安插质检员：检索结果为空或相关度过低？——别硬答，直接回「资料里没找到」；生成的答案引用了资料里不存在的内容？——拦下重试。每道检查都是一次「宁可承认不知道，不要自信地胡说」的机会——对 AI 流水线来说，「诚实的失败」是需要专门设计才能得到的特性，默认拿到的是「自信的失败」。
雷达收束：八个坑，八门老手艺
两课讲完，把 ByteByteGo 整张图收进一张表：
| # | 翻车原因 | 对应的老学科 |
|---|---|---|
| 1 | 脏数据 | 数据工程 |
| 2 | 检索失败 → 幻觉 | 信息检索 |
| 3 | 评测集过期 | 测试工程（回归测试） |
| 4 | 监控失明 | 可观测性 |
| 5 | token 成本复利 | 成本工程（FinOps） |
| 6 | 数据漂移 | 统计监控 |
| 7 | prompt 耦合 | 配置管理、内容与逻辑分离 |
| 8 | 级联失败 | 流水线设计、防御性编程 |
看出规律了吗？八个坑没有一个是「模型不够聪明」——全是老牌软件工程问题穿了 AI 的新马甲。这就是「AI 工程」这个单元名的含义：模型能力是买来的，工程能力才是你的。方法论跟本 Track 一贯的一样：别背案例，遇到 AI 翻车故事，先问它对应表里哪一行——问完，扫盲就完成了。
下一课换第二张图：AI 能替你写出能跑的应用了，但离「能上线」还差最后一公里——那又是另一组工程问题。
够用判断线
一句话总结：AI 应用翻车往往无人知晓（评测集不更新就是假信心、传统监控只看活着没不看答对没），不翻车也可能被拖垮（token 成本三重乘数复利、prompt 焊死在代码里、流水线没有质检员）——八个坑全是老牌工程学科的新考题。 到这个深度，你已经能在任何 AI 项目评审里问出最致命的三个问题：「评测集多久更新一次？」「怎么发现模型在胡说？」「千人规模时账单是多少？」。值得深学的信号：等你真的维护一个有真实用户的 AI 功能时，从「评测集回填」和「步骤间校验」这两件性价比最高的事做起。
随堂测验
1. 「评测 95 分，用户天天被错误答案折磨」——这种假信心是怎么造成的？
2. 为什么传统监控（uptime / 报错率 / 延迟）抓不住 AI 应用的故障？
3. token 成本从 demo 到生产会「复利式」膨胀，下面哪些是推高它的乘数？（多选）多选
4. 「小径」检索空手而归，模型却基于空资料编了个自信的答案端给用户——按本课的说法，根因是什么？
划选正文任意文字可高亮、批注或加入复习卡
讨论
载入中…