上线之后 — 面板全绿而顾客在流失,日志该记什么、告警该怎么改写
这一章讲三件事: 为什么传统那套运维监控在这里整套失效; 日志里该记哪六组东西,而其中一组一拉出来就会颠覆你的优化优先级; 以及提示词为什么该像代码一样打版本号。
它在全书链条里的位置: 第 17 章测「上线前对不对」,第 18 章管「跑得快不快」。 这一章管上线之后——怎么知道它今天还是对的。 第 20、21 章讲最后一类失效:任何指标都不显示的那一类。
1. 顶层全景:凌晨三点四分的账单告警
这一章的主走查从一条短信开始:
「紧急:AI 聊天机器人账单告警——本月 47000 美元。系统正在失效。」
收到这类半夜告警的人,书给了名字:一位叫 Sarah Chen 的工程师和她的团队—— 后面「面板全绿而顾客在流失」「把监控整个重建一遍」都是她那条线上的事1。 说明一句:书把这两幕分开写在两处(账单告警在开篇,Sarah 那通半夜投诉电话在讲监控那一节), 我们把它们并成了同一条走查,因为它们是同一个系统的同一场事故的两面。
① 打开监控面板:**可用率 99.9%、平均响应 200 毫秒、HTTP 错误 0** —— 全绿
▼
② 而顾客投诉:机器人告诉他六个月前买的东西可以全额退款
→ 打电话给客服才知道政策是 30 天
→ **深挖下去发现,它已经这么答了好几个星期**
▼
③ 翻日志,拉出一次真实交互:
**356 个输入词元 + 891 个输出词元 = 1247 个,这一次花了 0.32 美元**
▼
④ 把这一次请求分段计时:
取资料 + 找相似 + 后处理 加起来 **不到 500 毫秒**
**模型吐字 1.65 秒 —— 占 89.3%**
▼
⑤ 成本上更极端:
**模型吐字 0.004193 美元,其余全部加起来 0.00001 美元 —— 占 97%**
▼
⑥ 所以要降 30% 的成本,动的是**提示词、让回答变短**,不是换基础设施
▼
⑦ 把告警整个改写:
「每秒词元数低于 20」/「错误按用户类型聚集」/「每词元成本比基线涨 50%」
▼
⑧ 再加一条成本异常检测:**当前这一小时,超过上周同一小时的 2 倍就报高危**
图说:①② 是「传统监控为什么失效」,③⑤ 是「钱花在哪」,⑥⑦⑧ 是「那该怎么办」。
**47000、99.9%/200 毫秒、1247 个词元 / 0.32 美元、89.3% / 97%、
以及那三条告警和 2 倍规则,全部是书里的原数。**
2. 为什么老一套监控在这里整套失效
这一节讲这一章存在的理由,而书给了两条独立的原因。
原因一:同一个输入,可能成功 99 次、第 100 次失败
和产生一致错误的传统 bug 不同,这类系统的失败是不确定的: 同一个输入可能成功 99 次,在第 100 次失败。2
这一条直接废掉了传统排障的第一步。 传统 bug 的做法是「复现它」 ——而这里你复现不了:同一句话再问一遍,它可能是对的。
原因二:它可以一边跑得很顺,一边给出微妙错误的答案
传统应用也会有隐藏的 bug,但一个基于语言模型的系统可以一边运行得非常顺畅, 一边给出微妙错误的答案、产出不一致的结果、或者泄露敏感信息。3
这就是第 01 章那句「系统可以 99.99% 可用同时自信地答错」的第二次出现。 那里它是全书的立论,这里它变成了一个具体的运维难题。
走查第 ①② 步:面板全绿,顾客在流失
监控面板显示:
可用率 99.9% ✓
平均响应 200 毫秒 ✓
HTTP 错误 0 ✓
同时正在发生的事:
**机器人连着几个星期在告诉顾客,六个月前的订单可以全额退款**
(真实政策是 30 天)
图说:**这三个绿灯,和那件正在发生的事,一个格子都对不上。**
**系统在技术上非常健康,同时在系统性地损害客户关系。**
(这三个数和这个场景都是书里的原样。)
这门手艺有名字
在生产里管理这类模型的这套工程实践,书给了它一个名字:LLMOps (由「大语言模型」的英文缩写 LLM 和「运维」的英文缩写 Ops 拼成, 就是「把这类模型养在生产环境里的那一整套活」)。 它是从传统的运维和机器学习运维那边长出来的,但针对语言模型的四个特点做了调整: 行为不确定、对上下文敏感、成本会波动、失效模式无法预料。
书还把它和上一代划清了界限。先说清上一代那几样东西是什么。
上一代的日常是「重训模型」——拿新收上来的数据,把模型再训一遍,让它跟上变化。 为此还要养一个特征库:一个专门的仓库,存的是**「喂给模型的那些输入变量」** (比如「这位用户过去 30 天下过几单」)。
另外还要养一条数据流水线——把原始数据一步步洗干净、整理好、送进去的那一串处理。
这几样在这一套里的分量都轻了4:
| 传统的机器学习运维 | 这一套 | |
|---|---|---|
| 重心在 | 模型重训、特征库、数据流水线 | 提示词管理、检索流水线的评测、用量与成本监控 |
这张对照表最有用的地方是它告诉你「该配什么工种」: 这里的日常工作不是训模型,是管提示词和算账。
3. 用现成接口还是自己部署:三个代价和一张清单
这一节讲一个每个团队都要做的决定,而书的开场对比很扎人。
电梯里的说法听着很简单:「我们直接用现成接口,三行代码。」 六个月后,你盯着一张五万美元的月账单, 向董事会解释为什么供应商宕机时你们的 AI 功能停了四个小时。5
用现成接口的三个代价
① 成本会爆,而且爆的原因和你测试时想的不一样。
书给了一次真实交互的账:一位用户写了一段 350 词的详细排障请求 (季度董事会演示、区域报表崩了、换了三个浏览器都不行、涉及 7.5 万条记录)。
这一次交互:
输入 356 个词元
输出 891 个词元
合计 1247 个词元 → **0.32 美元**
图说:**书点破的那句话才是重点:**
**「当你的测试场景假设的是 30 个词元的问题,而真实用户写的是 350 个词元的长篇,
成本就会爆炸。」** ——**30 和 350 之间差一个数量级,而账单是按这个走的。**
(1247、0.32 美元、350 词都是书里的原数。)
② 你的数据会流经别人的机器。 敏感的顾客对话经过外部服务, 可能和数据保护法规或者内部治理要求冲突。
但书在这里给了一个很平衡的反驳,值得原样留下6:
主流接口供应商在合规认证和数据隔离上的投入, 往往超过大多数组织能独立负担的水平。 本地跑模型是把合规负担完全转移到你的团队—— 你必须自己完全理解并执行数据保护义务,没有供应商的合规基础设施托底。
这一段之所以重要:它挡住了一个很常见的想当然——「自己部署所以更安全」。 自己部署换来的是控制权,同时也接过了全部责任。
③ 供应商会悄悄换模型。 书说:即使你用了明确的版本别名, 生产里也可能出现意料之外的行为变化7。
自己部署要准备什么:一张让人清醒的清单
| 要准备的 | 具体是什么 |
|---|---|
| 显卡 | 每个实例每月 3000 到 8000 美元以上 |
| 服务栈 | 专门跑模型推理的那套软件 |
| 负载均衡 | 把请求分到多个实例上 |
| 模型管理 | 下载、存储、给几十 GB 的权重做版本管理 |
| 监控 | 显卡利用率、显存、延迟、错误率 |
| 扩缩容 | 按需自动扩,同时管好冷启动时间 |
「每实例每月 3000–8000 美元」这个数有参照物:上面那次交互是 0.32 美元。 一个月三千美元,大约相当于九千多次那样的交互——低于这个量,自己部署就不划算。 (这笔换算是我们算的,书只给了两个数。)
书给的第三条路是混合: 本地小模型答短的事实性问题、 细微或者有风险的查 询发给大模型、延迟或者负载超过阈值时回落到现成接口。
而书自己给这段代码打了补丁8:
这里展示的关键词匹配做法是为了讲清楚而刻意简化的。 生产上纯靠字符串匹配路由很脆:用户有无数种表达方式。
这是这本书第四次给出同一个诊断了(护栏、判意图、模型路由、这里)。 它推荐的替代也一样:把查询转成一串数看它离哪个话题近,或者用一个又快又便宜的模型先分类。
4. 每天必须回答的四个问题
这一节给监控定方向,而书这四问的顺序有讲究。
| 问题 | 它管什么 | 书的原话里最狠的那句 |
|---|---|---|
| ① 顾客能不能很快得到帮助? | 响应时间、可用性、基础设施 | 「机器人要 30 秒才回,顾客不管答得多好都会走」 |
| ② 答案真的有用吗? | 语义正确性 | 「大多数团队栽在这里。你的 AI 可能瞬间给出自信、排版漂亮、但完全错误的文字」 |
| ③ 顾客满意地离开了吗? | 用户行为 | 问题解决了吗?要不要追问?升级到人工了吗? |
| ④ 这会不会把我们搞破产? | 成本 | 「一次低效的提示词改动就能让月账单翻倍,而所有技术指标毫无变化」 |
第 ④ 行那句话值得单独停一下: 它说的是成本和技术指标之间没有联动。 你改了一句提示词, 回答长了三倍,账单翻倍,而延迟、错误率、可用率一动不动。 ——所以成本必须被当成一个独立的监控维度,不能指望别的指标替你发现它。
5. 日志里该记什么:六组字段,以及其中一组会颠覆你的优先级
这一节是这一章的核心。
六组字段,各回答一个问题
| 记什么 | 它回答什么问题 |
|---|---|
| ① 请求追踪 | 请求编号、时间戳(这次请求发生在哪一秒)、用户、会话——顾客抱怨某条回答不好时,你能找到确切的那一次 |
| ② 基本网络指标 | 常规运维那一套 |
| ③ 词元与版本 | 输入 / 输出词元数、每秒词元数、模型名与版本、提示词版本、随机度设置 |
| ④ 分段计时 | 取资料 / 转成一串数 / 找相似 / 模型吐字 / 后处理,各花了多久 |
| ⑤ 资源指标 | 显存、处理器、缓存命中率 |
| ⑥ 成本拆分 | 这一次到底花了多少,花在哪 |
第 ③ 组里「每秒词元数」这个指标值得单独说,书给了判据:
2 秒生成 89 个词元,也就是每秒 48 个,是健康的。 要是掉到每秒 5 个,你就知道有问题了。9
48 和 5 就是彼此的参照物——而这正是下一节告警改写的依据。
第 ④ 组一拉出来,优先级当场颠倒
这是走查第 ④⑤ 步,也是这一章最有价值的一个发现。
一次真实交互的分段计时:
转成一串数 + 找 相似 + 后处理 合计 **不到 500 毫秒**
**模型吐字 1.65 秒**
────────────────────────────────────────
模型吐字占总时间: **89.3%**
同一次交互的成本拆分:
模型吐字 **0.004193 美元**
其余全部操作加起来 **0.00001 美元**
────────────────────────────────────────
模型吐字占总花费: **97%**
图说:**注意两个比例的差距:时间上是 89%,成本上是 97%。**
**成本比时间更极端**——因为别的步骤虽然也花时间,却几乎不花钱。
(这几个数都是书里的原数。)
书直接给出了推论,而它逆着大多数人的第一反应10:
优化你的向量数据库或者缓存层,对延迟有好处,但对月账单几乎没有影响。 降成本的努力应该放在:缩短输出长度、提高提示词效率、做智能的模型路由 ——而不是改基础设施。
走查第 ⑥ 步就是这条推论的落地: 那个团队要降 30% 成本时,做的是用提示词把回答改短,而不是昂贵的基础设施改造。
判断(我们的,不是书里的): 这一节真正的价值不是那两个百分比, 是它证明了「凭直觉去改」会系统性地改错地方。 工程师的本能是去优化自己写的那些代码(检索、缓存、数据库), 而账单的九成七在一个你只是「调用」的东西上。 凡是没拉过分段计时的团队,几乎一定在优化那不到 3% 的部分。 如果错,会错在: 这组比例是在一个「取资料 + 生成」的客服系统上量的。 如果你的系统取资料那一步特别重(比如每次要扫上百万份文档),比例会明显不同。 判据是:自己拉一次分段计时,别信书里的百分比。
6. 告警要整个改写
这一节讲主走查第 ⑦⑧ 步,而它是全章最能直接抄走的一块。
三条改写
| 传统写法 | 该改成 | 为什么 |
|---|---|---|
| 「延迟超过 5 秒」 | 「每秒词元数低于 20」 | 抓到真的性能问题,同时忽略长回答期间的临时尖峰——一条长回答本来就该花更久 |
| 「错误率超过 1%」 | 「错误按用户类型或者问题话题聚集」 | 散落的随机错误通常是噪声;聚集的错误说明有系统性问题 |
| 「处理器使用率高」 | 「每词元成本比基线上涨 50%」 | 处理器忙可能只是流量变多(好消息);而效率退化永远意味着真问题 |
三条的共同点是同一个思路:从「绝对阈值」改成「模式和上下文」。11
绝对阈值的毛病: 一条 800 词的长回答,天然就比一条 20 词的慢
→ 「超过 5 秒就报警」会把正常的长回答天天报出来
→ 报多了就没人看了
换成「每秒多少个词」: **长回答和短回答被放到了同一把尺子上量**
→ 只有真的变慢了才报
图说:**这就是「模式而不是绝对值」的确切含义。**
第二条(聚集 vs 散落)和第三条(效率 vs 绝对量)是同一个思路的另外两种形态。
成本异常检测:三条规则
书给了三条,每条都带一个理由12:
| 规则 | 危险等级 | 为什么这么定 |
|---|---|---|
| 当前这一小时的成本 > 上周同一小时的 2 倍 | 高 | 「和上周同一小时比」是为了消掉自然的用量波动——周一上午本来就比周日凌晨忙 |
| 24 小时的趋势斜率 > 0.5 | 中 | 「每天涨 50% 一开始看着不大,但不管的话几周 就复利成破产级别的成本」 |
| 每词元成本超过历史效率阈值 | 中 | 「即便总成本稳定,每词元成本恶化说明系统在退化,迟早会打到成本或性能上」 |
而书还加了一条做法上的讲究:每条告警都附带一张「可能的原因」清单 (提示词改动 / 流量激增 / 模型路由出问题)—— 书说这比笼统的「成本很高」通知更快找到根因。
这套东西真的抓到过三件事13:
① 一次让回答长了 **3 倍** 的提示词改动
② 一个把**所有**查询都发给最贵模型的 bug
③ 用户的问题**逐渐**转向更贵更复杂的话题
图说:**注意这三件事在传统面板上全部隐形。**
① 和 ② 不影响可用率和错误率,③ 甚至根本不是故障——**它是业务在变。**
面板要连到业务结果
书的原话:他们展示的是「每个满意顾客的成本」,而不只是「总成本」; 跟踪的是「无需升级到人工就解决的问题数」,而不只是「响应时间」。14
这一条的意思是:同样一笔钱,分母不同,结论完全相反。 总成本涨了 20% 但满意顾客涨了 50%,那是好事;而只看总成本你会去砍它。
7. 输出质量的三层防御
这一节把第 17 章那套评测,改造成能在生产里连续跑的东西。
第一层:**按规则自动过滤**(最快,最便宜)
· 空回答
· **不必要的拒答**(第一次尝试就说「 抱歉我不能」)
· **错误信息泄漏**(回答里出现两次以上「Error」)
· **过度自信**(给出了具体主张,却一句缓和的措辞都没有)
▼
第二层:**统计式的质量监控**(看分布的变化,不看单条)
· **回答长度突变**(客服机器人突然从 50 词变 500 词,多半不是好事)
· **拒答率突然飙升**(可能是安全过滤设得太保守了)
· **重复检测**(模型有时会陷进循环)
· 语言一致性
▼
第三层:**让模型当评审**,1 到 5 分打分(最准,最贵)
图说:**三层按「快 → 准」排,和第 21 章那套安全检查是同一个结构。**
第一层和第二层的区别在于:**第一层看单条回答,第二层看一批回答的分布。**
第二层那个「 回答长度突变」值得记: 它是一个不看内容就能发现内容出问题的指标——而且它正好能抓到上一节那条 「一次让回答长了 3 倍的提示词改动」。
8. 提示词是一份生产质量合约
这一节讲一个态度上的转变,而它由一个具体的故障引出。
先看现象:同样的问题,不同用户拿到矛盾的建议
一个法律文档助手,对同样的问题给不同用户矛盾的建议。
书的诊断很准:问题不在模型,而在一个含糊的提示词留下了太多解读空间。 「准确回答法律问题」这句话对人来说似乎很清楚, 但它没有给 AI 任何关于语气、具体程度、免责声明、或者回答长度的指引。15
「留下了太多解读空间」这句话是这一节的钥匙: 提示词含糊,不会让它报错,只会让它每次自己挑一种解读。
做法一:给提 示词打版本号
像 customer_support_v1.0 / v1.1 / v2.0 这样。理由书说得很实在16:
| 打了版本号,你就能 | 具体怎么用 |
|---|---|
| 定位 | 质量指标一变,你能精确知道是哪个版本引入的 |
| 回滚 | 必要时退回上一版 |
| 灰度 | 把新版本先推给一小部分流量、量它的影响、有问题快速回退 |
做法二:黄金数据集
一组精挑的问题,但它和传统测试用例有一个根本区别:
每条附带的不是标准答案,而是「期望出现的要素」和「质量标准」。17
问:「怎么重置密码?」
期望出现的要素: ["邮件链接", "账号设置", "24 小时"]
质量标准: { 最长 200 词,
必须包含 ["重置", "密码"],
语气:helpful }
图说:**注意这里没有一个「正确答案」。**
**书自己点破了原因:和传统软件测试期望完全一致的输出不同,
这里盯的是回答的质量模式和必备要素。**
**用途也说得很具体:要是密码重置的回答突然不再提邮件链接、或者开始超长,
你就知道系统里有东西变了。**
(这组要素和标准是书里的原样。)
做法三:上线前先并行跑一遍
做法:新模型或者新提示词版本上线之前,让候选和现在这个并行跑真实用户查询, 候选的回答不给用户看,只记下来做对比。这叫影子测试。 它是异步跑的(在旁边另开一条线单独跑,不占用户那条线),所以不给用户请求增加延迟。
书给的成本警告很直接18:
影子测试在评估期实际上让模型成本翻倍,因为每个查询都跑两个模型。 要为这笔开销做预算,并且把它限制在一个有代表性的时间窗口内,不要无限期地跑。
这套东西在生产里跑在哪: 书点名了一个开源的可观测性平台 ——它专门为这类应用做了优化,能把一次交互的检索、生成、后处理三段的词元数和耗时串成一条线, 还挂上「这次用的是哪个提示词版本」和一个质量分。19 书说它不只是个日志器,是一个反馈引擎:面板、单次交互的细节、提示词版本管理、 模型评审、影子测试工具,全在一处。
书给的案例是一家求职管理平台的简历生成功能: 它靠这套东西盯住每月数万次简历生成,把「盲发提示词」变成了「先看下游影响再发」。
9. 什么时候该换模型:四个信号
这一节是这一章的收尾,书给的四条可以直接当检查表用20:
| 信号 | 具体表现 |
|---|---|
| ① 质量随时间退化 | 黄金数据集的分数在下滑、满意度下降、升级到人工的比例上升——而提示词和数据都没改 |
| ② 成本效率 | 更新更便宜的模型,在影子测试里达到了相当的质量 |
| ③ 供应商公告 | 你依赖的那个模型被排期弃用(官方宣布「不再推荐用、将来会停」)或者退役,要在截止日之前很久就有迁移计划 |
| ④ 能力缺口 | 产品路线图需要当前模型做不好的东西(固定格式输出、更长的上下文、看图) |
书自己的结论:关键是把选模型当成一个持续的运营决策,而不是一次性的架构选择。
第 ① 条最值得停一下:「提示词和数据都没改,分却掉了」—— 这在传统软件里根本不该发生。 而在这里它是常态, 因为供应商会悄悄换模型(第 3 节那条),而用户的提问方式也在慢慢漂。 这两条正是第 08 章那两种漂移在生产层面的样子。
10. 作 者的判断与证据
书里给了证据的:
| 说法 | 证据是什么 |
|---|---|
| 89.3% 的时间、97% 的成本在模型吐字这一步 | 一次真实交互的完整分段拆解——这是全书证据最硬的一处 |
| 一次交互 1247 个词元 / 0.32 美元 | 一笔完整的账,而且给了那次请求的具体内容 |
| 每秒 48 个词元健康、掉到 5 个有问题 | 一对互为参照的数 |
| 三条告警改写 | 每一条都配了「为什么这么改」的机制说明 |
| 成本异常的三条规则 | 每条都带阈值和理由 |
| 那套系统抓到的三件事 | 三个具体的案例 |
| 自己部署每实例每月 3000–8000 美元 | 一个具体的区间,但书没说是按什么配置算的 |
作者的推测或没给证据的:
| 说法 | 它是什么 |
|---|---|
| 那位工程师和她团队的整个故事 | 一个叙事化的案例。 人名、公司、数字都可能是构造出来讲道理的,书没有说明它是真实案例还是虚构 |
| 「大多数团队栽在第二个问题上」 | 一句判断,没有调查数据 |
| 三层质量防御各自的检测规则 | 一组工程建议(比如「出现两次以上 Error」),阈值都是拍的 |
| 换模型的四个信号 | 一张经验清单 |
11. 边界与局限
-
成本异常的三条规则,阈值全是拍的。 为什么是 2 倍不是 3 倍、为什么斜率是 0.5, 书一个字没解释;
-
没有讲告警的误报代价。 「每秒词元数低于 20」——如果你的模型本来就慢呢? 书没有讲这些阈值该怎么按自己的系统去校准;
-
黄金数据集的规模没给。 多少条算够?多久更新一次? 产品变了之后旧的期望要素怎么办?书全没讲;
-
影子测试只说了「代表性的时间窗口」。 多长算代表性?跑够多少条能下结论?没有;
-
三层质量防御和第 17 章那套评测的关系没有理清。 两处都在讲「让模型当评审」, 但一处是离线批量跑,一处是在线连续跑——它们该共用一套标准吗?书没有回答;
-
那个 47000 美元最后怎么降下来的,没有交代。 开场吊了一个很足的胃口 (账单告警),中间讲了「改提示词降 30%」,但那 30% 是不是就把 47000 解决了,书没有收口。
12. 可带走的
全章那条走查,一行写完: 凌晨三点四分,账单告警 47000 美元 → 面板全绿(99.9% 可用、200 毫 秒、零错误)→ 而机器人已经连着几周答错退款政策 → 翻日志:一次交互 356 输入 + 891 输出 = 1247 个词元,0.32 美元 → 分段计时:其余全部不到 500 毫秒,模型吐字 1.65 秒,占 89.3% → 成本上推理占 97% → 所以降 30% 成本靠改提示词让回答变短 → 告警改写成「每秒词元数低于 20」「错误按用户类型聚集」「每词元成本涨 50%」 → 再加「当前小时超过上周同一小时 2 倍就报高危」。
- 失败是不确定的:同一个输入可能成功 99 次、第 100 次失败——传统排障的第一步「复现它」直接失效;
- 系统可以一边跑得很顺,一边给出微妙错误的答案——这是第 01 章那句话的运维版;
- 这套工程实践的重心和上一代不同: 不是重训模型,是管提示词和算账;
- 用现成接口的三个代价: 成本按真实用户的长度爆炸(测试假设 30 词元、真实 350 词)、 数据流经外部、供应商会悄悄换模型;
- 「自己部署更安全」是想当然: 它换来控制权,同时把全部合规责任接了过来;
- 每天要回答四个问题: 快不快、有没有用、顾客满不满意、会不会破产;
- 成本和技术指标不联动: 一次提示词改动能让账单翻倍,而延迟错误率一动不动;
- 日志六组字段里最容易漏的三样:每秒词元数、提示词版本号、分段计时;
- 最该记住的一组数:模型吐字占 89.3% 的时间、97% 的成本;
- 它的推论:降成本要改提示词让回答变短,不是优化数据库和缓存—— 没拉过分段计时的团队,几乎一定在优化那不到 3% 的部分;
- 告警要从「绝对阈值」改成「模式和上下文」: 每秒词元数、错误聚不聚集、每词元成本;
- 成本异常要和上周同一小时比,为的是消掉自然的用量波动;
- 告警要附带「可能的原因」清单,比笼统的「成本很高」快得多;
- 质量防御三层按快→准排:规则过滤 → 看分布变化 → 模型评审。 第二层不看内容就能发现内容出了问题;
- 提示词是生产质量合约:含糊的提示词不会报错,只会让它每次自己挑一种解读;
- 给提示词打版本号,才谈得上定位、回滚和灰度;
- 黄金数据集配的是「期望出现的要素」而不是标准答案——因为两次回答本来就不一样;
- 新版本上线前先影子测试,代价是评估期成本翻倍,所以要限时;
- 换模型的四个信号: 质量退化(而你什么都没改)、更便宜的模型质量够了、 供应商要弃用、能力缺口。
13. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 开场那条账单告警 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:13(搜「billing alert」) |
| 「成功 99 次、第 100 次失败」 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:22(搜「Unlike traditional bugs」) |
| 「一边跑得顺一边微妙地错」 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:60(搜「an LLM-based system」) |
| 和上一代运维的分工 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:53(搜「model retraining, feature stores」) |
| 「三行代码」那段反差 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:85(搜「elevator pitch sounds simple」) |
| 一次交互 1247 个词元、0.32 美元 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:142(搜「1,247」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:143(搜「Cost: $0.32」) |
| 合规那条平衡的反驳 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:148(搜「handing your data to a third party」) |
| 供应商会悄悄换模型 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:157(搜「model control problem」) |
| 自己部署的基础设施清单 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:205(搜「actually requires」) |
| 混合方案与那条自我补丁 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:306(搜「hybrid pattern balances」) |
| 面板全绿而顾客在流失 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:317(搜「full refund for a」) |
| 每天四个问题 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:332(搜「The four questions」) |
| 日志六组字段与每秒词元数 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:392(搜「request_id」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:403(搜「tokens_per_second」) |
| 89.3% 与 97% | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:363(搜「89.3%」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:372(搜「0.004193」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:374(搜「97% of the total expense」) |
| 三条告警改写 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:451(搜「tokens per」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:454(搜「errors cluster by user type」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:457(搜「cost per token increases 50%」) |
| 成本异常三条规则与抓到的三件事 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:497(搜「same hour last week」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:505(搜「caught three major cost issues」) |
| 面板连到业务结果 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:532(搜「connecting technical metrics to business outcomes」) |
| Stack Overflow 那个钩子与三支柱 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:736(搜「ban ChatGPT-generated answers」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:747(搜「Traditional software quality assurance」) |
| 含糊的提示词与版本号 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:766(搜「contradictory advice」) · text/13-ch10-chapter-10-deploying-and-monitoring.txt:793(搜「Version tracking enables」) |
| 黄金数据集 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:812(搜「THE GOLDEN DATASET」) |
| 影子测试与成本翻倍 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:889(搜「SHADOW TESTING」) |
| 换模型的四个信号 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:931(搜「WHEN TO CONSIDER UPGRADING」) |
| 那个可观测性平台与求职平台案例 | Chapter 10: Deploying and Monitoring | text/13-ch10-chapter-10-deploying-and-monitoring.txt:971(搜「feedback engine」) |