Part B · 横切深挖 · B10

Tracing a quality regression上线后的质量回溯

口述 2 min 追问 7 层 适合 垂直 Agent 研发, FDE, Solutions
Prompt 题面

先想清楚再开口

你刚讲完 A02 的深度研究 Agent，面试官接着问：「上线两个月后，分析师开始抱怨报告质量变差了。可是没有任何报错，延迟也正常。你怎么查？」

题面为本书自拟的训练题，不代表任何公司的真实面试题或真实系统。场景沿用 A02 的研究 Agent（虚构练习设定）。

约束

约束取值（练习设定）
系统A02 的研究流水线：拆子问题 → 网页与内部文档检索 → 证据卡抽取 → 综合成报告 → 分析师签发
症状分析师签发前的修改率，三周内从约 15% 升到约 30%；没有报错，延迟和 token 用量正常
这三周里的变更模型网关上的模型别名指向了新版本；内部文档索引重建了一次；综合步骤的 prompt 改过一版；另外有几个常用网页来源改了版式
数据trace 里会出现内部文档和客户资料，属于机密；日志要脱敏，访问按项目组授权
留存trace 按合规要求留存 30 天
时效业务方希望本周内止血
答到一半再点开：面试官补了一句

「完整的 trace 载荷只留了 7 天，而问题是三周前开始的；你只剩下元数据。」

Answer 参考回答

先口答，再展开

展开参考回答

该先问的问题

  1. 「变差」具体是什么？修改集中在哪一类：事实错误、漏了来源、引用对不上，还是结构和措辞？这决定先查哪个阶段。
  2. 变差是普遍的，还是集中在某类问题、某个项目组、某种来源上？这决定先分层还是先查全局变更。
  3. 这段时间有哪些变更，有没有记录：部署、模型版本、索引、prompt、配置、外部来源？没有变更日志的变化，要从 trace 里的版本字段反推。
  4. trace 记了什么、留了多久、谁能看？能不能在冻结的输入上重放？这决定能做对照实验，还是只能看相关性。
  5. 止血的手段有哪些：能不能钉住模型版本、回滚 prompt 或索引、临时提高人审比例？这决定止血和诊断能不能并行。

一句话框架

从用户看到的结果往回查，逐个阶段找第一个出错的地方；每个阶段的 trace 都要记下实际版本和输入输出哈希，用来定位变化，但判断对错要看内容；归因靠在冻结输入上一次只改一个因素的对照，而不是看时间线猜。

设计取舍表

从用户结果往回查，找第一个出错的阶段 用户结果 / 人审 症状在这里出现 签发前修改、推翻、投诉 审核人动作 + 理由码 生成 / 综合 模型节点 实际模型版本（不是别名） prompt 版本哈希、输出长度、引用数 证据抽取 模型节点 抽出的字段、归源置信 抽取失败与「无法判断」的计数 检索 / 工具调用 不经过模型 查询、索引版本、文档 ID + 内容哈希 工具版本、返回码、内容质量信号 权限决定 不经过模型 允许 / 拒绝、依据的 ACL 与策略版本 被过滤掉的文档数 输入 / 规划 任务从这里进入 输入哈希、任务类型与分层标签 配置版本、拆出的子问题 每个 span 共用一个 trace ID；正文按字段脱敏， 哈希只能定位变化；载荷抽样存受控存储，≤30 天到期清理 模型节点 不经过模型 人工节点
六个阶段与各自该记的字段。症状出现在最上面的用户结果，原因可能在下面任何一层；诊断就是从上往下找第一个输出已经不对的阶段。颜色沿用全书图例。
设计点采用否决的备选什么证据会让我改
trace 结构每个任务一个 trace ID，每个阶段一个 span；所有 span 记元数据（版本、哈希、计数、耗时、决定）；完整载荷按比例抽样，存进按项目组授权的受控存储，和 trace 一样最多留 30 天，到期清理（含备份），支持按数据主体删除。哈希和计数只能说明「变了」，说明不了「错了」只记最终输出；或者把全部原文写进普通日志存储成本或合规不允许存载荷时，只留哈希和指针，并接受有些问题无法复现（见追问 2）
版本钉住每个 span 记解析后的实际版本：模型版本（而不是「latest」这类别名）、prompt 版本哈希、索引版本、工具版本、配置版本只记别名，或者靠部署记录去对不改；版本不在 trace 里，归因就只能靠猜
定位方法从修改和推翻最多的样本出发，逐个阶段检查输出，标出「第一个出错的阶段」，再按阶段汇总。只有载荷还在、或能按权限回源重取的样本才判得了；只剩元数据的样本标「疑似阶段」，单独统计；同时把质量指标按任务类型、项目组、来源分层盯着总体分数，对着变更时间线猜原因失败集中在某一层时，先在那一层内查，不必逐阶段全查
因果确认在冻结的输入上重放，一次只改一个因素（模型版本、prompt、索引），每个配置重复跑几次，比较受影响样本上的结果看哪个变更和质量下降时间吻合，就认定是它输入或来源已经取不回（网页变了、载荷过期）时，退回到分层相关性，并在结论里写明只是相关
止血与诊断并行：能定位到的因素先回到已知好的版本（比如钉住旧模型版本）；定位不了时，临时提高人审比例或收窄功能等查清原因再动回滚之后指标没有恢复，说明归因错了，回到对照实验
权限与脱敏trace 继承被处理数据的 ACL 与分级；字段级脱敏后再落盘；调试访问要限时审批并留审计把 trace 当普通运维日志，所有工程师都能看不改；trace 本身就是一份机密数据的副本
闭环事故样本按版本标注后加入评测集（按 B06 的口径）；给出错的阶段加检查或告警；模型、prompt、索引的变更先在影子流量上对比再放量修好就结束同类问题第二次出现，说明检查加错了地方，回到阶段归因
Two-minute English 口述

两分钟，先结论后展开

展开 2 分钟英文口述稿

I'd start from what users actually see, not from the dashboards. Analysts are editing more reports, so I pull the most-edited ones, walk each through the pipeline stage by stage — input, permissions, retrieval, extraction, synthesis — and mark the first stage whose output was already wrong. Then I aggregate: is it mostly retrieval, mostly synthesis?

At the same time I slice quality by task type, project, and source, because a regression is often concentrated in one slice.

This only works if every span records the resolved versions — the actual model version, not an alias, plus prompt hash, index version, and tool version — and fingerprints of inputs and outputs. Hashes tell me something changed, not whether it's wrong. Payloads are sampled into access-controlled storage within the thirty-day retention limit; the rest is redacted metadata.

Three changes landed in the same window, so timing alone proves nothing. I replay frozen inputs and change one factor at a time — model, prompt, index — running each configuration several times.

I stop the bleeding in parallel: pin the last known-good version if I can, otherwise raise the human review rate.

Finally, the incident cases get labeled and added to the eval set, the failing stage gets a check, and future model or prompt changes go through shadow comparison before rollout.

Follow-ups 追问

一层一层往下问

  1. 为何不用备选为什么不直接回滚到上一版，先把质量拉回来再说？
    先口答，再展开要点
    • 回滚是止血，不是诊断；而且这里的「上一版」不唯一：模型别名、索引、prompt 三处都变了，只回滚一处可能没用，全部回滚又会把有用的改动一起扔掉。
    • 该做的是两件事并行：能确定的因素先回到已知好的版本，同时临时提高人审比例兜底；另一边在冻结输入上做单因素对照。
    • 触发改变的条件：如果重放显示单一因素就能解释大部分受影响样本，就只回滚它；如果回滚后指标没恢复，说明归因错了。
  2. 需求变化完整载荷只留了 7 天，问题是三周前开始的。你只剩元数据，还能查吗？
    先口答，再展开要点
    • 元数据还能回答「在哪里」：修改率按版本字段、任务类型、来源分层，看变化集中在哪个版本组合或哪类来源上。
    • 回答不了「为什么」：没有输入，就没法重放三周前的任务。改为用最近 7 天的样本复现：如果同样的分层里仍然能看到问题，就在这些新样本上做对照。
    • 内部文档可以按文档 ID 和版本从源系统重新取（按请求人的权限）；网页可能已经变了，取回来的不是当时的内容，这部分结论只能标为「相关」。
    • 之后调整采集策略，但不突破 30 天：在批准的 30 天内提高有代表性的载荷抽样比例；分析师标记修改或推翻时，把那个任务的载荷立即采进受控的事故样本库，趁它还没过期先标注、先重放。
    • 确实需要保存超过 30 天（比如为了长期回归集），要先取得合规的明确例外，或者做不可识别化处理并经合规认定；即使获批，也保留项目组 ACL、按数据主体删除和到期清理，备份同样适用。
  3. 失败反证你把问题归因到模型版本升级，钉住旧版本后，质量没有回来。
    先口答，再展开要点
    • 说明当时的归因是相关不是因果：模型升级和索引重建落在同一周，时间线分不开。
    • 回到冻结输入上单独换索引版本，结果显示受影响的主要是一批重建时被切坏的长文档：检索没召回，综合步骤就只能用二手来源。
    • 教训：多个变更同时上线时，时间吻合不算证据；归因要有阶段证据（这里是检索 span 里召回的文档 ID 变了），再加单因素重放。
  4. 安全trace 里有内部文档和客户资料。谁能看？怎么防止 trace 变成泄露通道？
    先口答，再展开要点
    • trace 继承被处理数据的 ACL 和分级：按项目组授权，跨组查看要审批。
    • 落盘前做字段级脱敏；原文只存哈希和文档指针，需要看原文时按查看人的权限回源系统读取。
    • 调试访问限时、留审计；导出 trace 也要走同样的出站校验。trace 汇集了所有阶段的数据，它本身就是高价值目标。
  5. 归因每个阶段自带的检查都是绿的，可质量还是变差了。怎么办？
    先口答，再展开要点
    • 阶段检查只挡特定错误（格式、引用是否存在、返回码），挡不住「合法但更差」的输出。
    • 这时看分布变化：检索返回的来源构成、每份报告的引用数和一手来源占比、输出长度、「无法判断」的比例，和基线时期逐项对比。
    • 再从修改最多、载荷还在的样本里抽一批，由人按「第一个出错的阶段」标注，这比任何一个自动指标都直接；只剩元数据的样本最多标到「疑似阶段」。
  6. 静默变化没人发版，但几个常用网页来源改了版式，抓回来的是 cookie 提示页或登录墙。工具返回码全是成功。
    先口答，再展开要点
    • 工具「成功」不等于内容可用：抓取 span 要记内容质量信号，比如正文长度、模板文字比例、是否命中常见的拦截页特征。
    • 按来源监控抓取的有效内容率，某个来源突然下降就告警，并在报告里把这个来源标为「未取到」，而不是让综合步骤拿拦截页去写。
    • 这类变化不会出现在自己的变更日志里，所以外部依赖要当成随时可能变化的输入来监控。
  7. 评估闭环查清楚之后，怎么防止同类问题再发生？
    先口答，再展开要点
    • 事故样本按版本和失败阶段标注后加入评测集（口径同 B06：专家标注、分层、写样本量），模型、prompt、索引的变更都要先过这批样本。
    • 在出错的阶段加检查或告警；如果问题出在检索，就补一个召回率的回归集。
    • 变更管理：模型版本钉住，升级时先在影子流量上对比新旧输出，差异大的样本交人看过再放量。
Failure Modes 失败模式

这些地方最容易栽

只记别名，不记实际版本
  • 症状：质量突然变了，却说不清这段时间模型、prompt 或索引有没有变；不同人给出不同的时间线。
  • 根因：trace 里只写了「latest」这类别名，或者版本只存在部署记录里，没有落到每个 span 上。
  • 防线：每个 span 记解析后的实际版本和哈希；变更日志与 trace 版本字段定期对账；模型版本默认钉住，升级是一次显式变更。
工具「成功」返回了垃圾
  • 症状：抓取或检索的返回码全部正常，报告却越来越依赖二手来源、引用越来越少。
  • 根因：只监控调用是否成功，不监控返回内容是否可用；外部来源改版、拦截页、索引切坏，都会产出「合法但无用」的结果。
  • 防线：工具 span 记内容质量信号；按来源监控有效内容率；取不到的内容在报告里显式标出，不让下游硬用。
把时间吻合当成因果
  • 症状：回滚了「嫌疑最大」的变更，指标没有恢复；团队接着回滚下一个，来回折腾。
  • 根因：多个变更落在同一窗口，只看时间线，没有阶段证据，也没有单因素对照。
  • 防线：先用阶段归因定位到出错的阶段，再在冻结输入上一次只改一个因素重放；结论写明是因果还是相关。
Cross-references 回链

原理去哪里补

  • A02 深度研究 Agent：本卡沿用的场景，证据卡与归源字段就是 trace 的一部分
  • A01 改代码的 Agent：测试和 diff 本身就是天然的阶段证据
  • A05 浏览器 Agent：页面改版和拦截页是最常见的静默变化
  • B06 Agent 怎么评估：离线与线上评估体系，事故样本回流的标注口径
  • B08 错误恢复与幂等：出了错之后怎么重试和补偿
  • AI 6.1 可观测性：LLM 应用的 tracing 与质量监控指标 · AI 系统工程手册
  • AI 6.4 Eval Pipeline：离线、在线与回归测试三层 · AI 系统工程手册
  • AI 6.5 降级与回退：上游变化时的止血手段 · AI 系统工程手册
  • DV ch16 调试与错误处理 · CCDV 备考手册
  • AR ch14 可靠性工程：升级与人工介入 · CCAR 备考手册
Your Turn 本人填写

只写真实经历

只写真实经历，没有就空着，不编。公开版只有空表；填好的版本存在自己的私用练习记录里。

场景当时发生了什么我亲自做了什么（团队 / AI 做了什么）怎么发现的，结果和证据之后怎么防
线上质量变差，但没有任何报错
以为找到了原因，回滚后才发现不是它

练习记录

日期口述用时脱稿？答不上的追问下一轮修正（≤2）