学习追踪、指标、反馈和调试工作流，从而解释模型故障，并在客户环境中运维生产级 AI。
由 前沿部署编辑团队审阅
面试官会就你描述的任何生产系统提出一个问题，而这个问题能区分真正运维过系统的人和只搭建过系统的人：“你怎么知道它坏了？”可观测性就是答案。它是一种插桩手段，能把一个你只能希望它在正常工作的系统，变成一个你能看见它在正常工作、并且在它不正常时可以调试的系统。本页按照业界的实际方式来教授它：通过完整走一遍一个调试事件，因为只有当你亲身经历过插桩所针对的故障之后，这些插桩才有意义。
一个事件：昨天给出的错误答案
以检索演练中的研究资料库助手为例，它已在客户处上线运行了几个月。（下面的事件是示意性的：请求、文档、耗时和分数都是虚构的；值得研究的是它的形态。）一天早上，一位顾问来信写道：
“昨天助手告诉我们对欧洲工业板块的观点是中性。我们五月份已经上调为增持。它还有哪些地方出错了？”
这是典型的投诉，而且表面上无法调试。你当时不在场，答案已经消失，而最后那个问题——它还有哪些地方出错了——正是信任开始流失的声音。确定性系统的本能是先复现再修复，但在这里行不通：你现在可以问助手同样的问题，但概率系统并不保证给你相同的输出。如果今天的答案是对的，也证明不了昨天的答案如何；如果是错的，你仍然看不出原因。所以你要调试的是被记录下来的那次实例，而不是一个可能永远拿不到的复现。昨天的答案唯一可调试的版本，就是系统当时记录下来的那份记录。这份记录就是一条追踪。
调取追踪
你按用户和时间查找昨天的请求，调出它的追踪：该单次请求经过每个阶段的完整路径，包括每个阶段接收了什么、产出了什么、耗时多久。
trace_id: 9f3c-0212 2026-06-09 14:12 UTC total: 2,279 ms
[input] question received (t=0)
"What's our current outlook on European industrials?"
[retrieval] top 3 chunks by vector similarity (87 ms)
index build: 2026-01-30
[1] 0.81 eu-industrials-2026-01.pdf, p.2
"We remain neutral on European industrials;
order books are soft and pricing power limited…"
[2] 0.77 global-sectors-2026-01.pdf, p.9
"…industrials positioning unchanged this quarter…"
[3] 0.72 eu-macro-2026-01.pdf, p.4
"Euro-area manufacturing surveys remain weak…"
[guardrail] input pre-check (injection scan, topic scope) (12 ms)
result: pass
[model] model: frontier-large-2026-05, prompt: v14 (1,940 ms)
tokens: 3,180 in / 210 out
"The house view on European industrials is neutral,
reflecting soft order books and limited pricing
power [1], unchanged positioning [2], and weak
manufacturing surveys [3]."
[groundedness] answer supported by retrieved chunks? (240 ms)
score: 0.96 — pass
[response] returned to advisor
stage sum: 87 + 12 + 1,940 + 240 = 2,279 ms从追踪中读出的诊断
按顺序阅读各个阶段，故障就会自行定位。护栏预检查通过了，而且是正确的：问题在范围内。模型表现正常：它的答案是对它拿到的恰好那三段文字的忠实、带引用的总结。事实核查也通过了，同样是正确的，而这个结论值得停下来想一想：事实核查是把答案与检索到的内容进行比对，所以它永远无法发现检索本身出错。检索之后的每个阶段都各司其职，只是输入本身是坏的。
故障出在检索阶段的两行记录里。排在最前面的分块是一月份版本的工业报告，也就是顾问说在五月份已被取代的那份，而它上面的一行说明了原因：索引最后一次构建是在一月底。五月份的报告确实存在于客户的文档库中，只是从未被嵌入和索引过。检索无法召回索引从未见过的文档。
如果没有追踪记录，这起事故会以“模型产生了幻觉”结案——一个既无法修复也无法证伪的结论，还会让你失去顾问的信任。有了追踪记录，它就是一个陈旧索引的 bug,修复只需一行操作：重新运行数据摄取任务，让索引反映当前的语料库。两个后续动作能体现一名操作者的水准。第一，把重建任务纳入定期调度，因为靠手动刷新的索引迟早会再次过时。第二，把顾问的这个问题，连同五月份报告中本应回答它的那段内容，一起加入评测套件,这样下次索引过时时，会在每日运行中表现为分数下降，而不是出现在顾问的收件箱里。这起事故属于部署页面所围绕的“静默回归”一类：行为发生了变化，却没有任何代码差异，而其中讲授的版本化索引和定期评测正是本可以提前几周发现它的手段。追踪记录是你事后找到这类故障的方式；部署规范则是让你不再以这种方式与它相遇的方式。
这起事故的普遍意义
这次调试会话用到了一路观测数据，并暴露出还需要另外两路。一个 AI 系统的生产可观测性由三路数据流构成，这起事故说明了每一路的用途。
追踪记录——调试的基本单元
一条追踪记录了单个请求的完整路径：输入、检索返回了什么以及相应的分数、触发了哪些护栏、确切的模型和提示词版本、输入和输出的 token 数、每个阶段的耗时，以及最终响应。它是概率系统调试的基本单元，因为相同的输入可能产生不同的输出，所以被记录下来的那次实例是唯一可调试的对象。这里的管道是标准工程：普通服务的分布式追踪约定可以直接套用。OpenTelemetry 是厂商中立的标准，而各类 LLM 专用追踪产品也建立在同样的理念之上，只是补充了这起事故所依赖的检索、提示词和 token 字段。
质量信号——在用户察觉之前先发现
事件中最糟糕的事实在于它到达的渠道：一条用户投诉，而且是在答案已经过时数周之后。这几周里没有任何运维指标发生变化。延迟平稳、错误率平稳、正常运行时间干净，因为这些指标都不读取答案的内容。要察觉质量衰减，需要为此专门构建的信号：针对固定问题集运行的在线评测给出的每日评分，以及来自真实流量的行为代理指标，比如点踩率、人工纠正或覆盖输出的频率、升级率和任务完成率。如果评测集当时已经包含一道由工业报告回答的问题，过时的索引会在一天内以评分下降的形式暴露出来。离线评测分数与这些在线信号之间的差距本身就是一个值得关注的数字：差距扩大意味着现实已经偏离了你的测试集。如果你了解回归的唯一途径是客户投诉，那你就没有可观测性。
运维指标 —— 每次请求的成本与延迟
第三条数据流其实一直就在追踪记录里：每个阶段都带有耗时，模型阶段还带有 token 计数。跨请求聚合之后，它们就构成了运维数据流：每次请求的成本和延迟分布，读取 p50 和 p99 而非平均值，因为尾部才是用户真正感受到的（成本与延迟对两者都有涵盖）。在规模化场景下，两者中任何一项的小幅回归都意味着一笔大账单或一个支持队列，而且这些指标也是预警渠道。延迟飙升或成本跳涨往往会在质量信号变化之前，先暴露出一个缺陷、一次检索循环或一个过大的提示词。
差 / 好 / 卓越 —— “如何调试上周二的一个错误答案？”
差 —— “我会在 playground 里尝试复现。” 这是确定性系统的条件反射，而且在两个方向上都证明不了什么：一个概率系统今天可能答对，尽管上周二失败了；即使复现成功，你也只能看到错误的输出，却看不出是哪个阶段产生了它。在这里耗上一个下午，你对那个真正失败的请求仍然一无所知。
好 —— “我会调取那个请求的日志。” 反射方向正确，去查记录下来的数据，但服务日志记录的是存活状态：状态码、延迟、错误计数。对于一个错误答案，日志只会显示一个在正常时间内正常返回的请求，因为从运维角度看什么都没失败。一条不携带答案内容的日志，无法说明系统声称了什么、这个声称又来自哪里。
很好——“我会调取该请求的追踪记录，逐个阶段地阅读。” 带有分块和分数的检索、护栏判定结果、包含提示词版本和 token 数的模型调用、接地性评分：每个阶段都有其输入和输出，这样故障就能定位到某个具体阶段，而不是笼统地归咎于“模型”。在上面的事故中，这样阅读最终会定位到来自旧索引构建的过期分块；补救措施是重新建立索引、安排定期重建，并将这个失败的问题加入评测套件，以便下次每日运行时能捕获整类问题。
面试中可以带上的要点
当面试官问“你怎么知道它出问题了？”，或者更尖锐的版本：“一位用户说上周二它给出了错误的答案；请讲讲你会怎么做，”就按照本页的思路来回答。调取已记录请求的追踪记录，逐个阶段地阅读，直到故障被定位。然后说出那些本可以在用户之前就暴露问题的质量信号——每日评测分数、纠正率和升级率——以及你持续跟踪的成本和延迟。对质量以及存活状态都进行监测，才能让系统在你之外的人手中也可运营，这正是每次合作结束时都会发生的交接。
相关： 评测（质量信号）、成本与延迟（运营指标）、护栏（让拒绝行为可观测）。
下一篇： 成本与延迟——在任何质量指标之前，客户最先感受到的两个数字。