Netflix Pensive AI 让模型返回日志行号，用来诊断失败的数据任务

Netflix 用固定规则包裹 AI，诊断失败的数据任务

10 月 26 日，Netflix 技术博客发布了一篇关于 Pensive AI 的长文，介绍这套帮助工程师弄清数据和机器学习任务为何失败的系统。Netflix 说，在高峰日，Titus、Spark、Trino 和 Druid 等引擎上约有 10 万个工作负载失败。早先的 Pensive 会读取失败任务的日志，用正则表达式和手写的 Java 规则对错误分类，再把重试建议交给 Maestro 工作流调度器等工具。这让大约一半的失败可以由用户自助处理。在某个三个月的统计期内，它处理了约 700 万次分类，其中约一半落入“未知”类别。Pensive AI 就是为了补上这个缺口，同时保留已经有效的规则。

按行号提取，而不是整段复述

第一项功能是错误提取，在每个失败步骤上都会运行。设计上的关键是模型如何作答。Pensive 给每份日志的行编号，把“行号加文本”的记录交给模型。模型只返回两个整数，即错误的起始行和结束行，Pensive 再从自己保存的日志副本里还原文字。Netflix 给出两点理由：生成输出 token 比读取输入慢；显示的文字直接取自原始日志，减少了凭空编造。这里的 token 是模型处理文本的计量单位。模型仍可能选错范围，所以提取质量是评测的一部分。这个调用与 Maestro 对失败步骤后处理的 90 秒硬性上限共用一个截止时间，错过截止时间的单份日志调用会被舍弃，以便整体响应按时返回。Netflix 保留了旧的错误字段，并在旁边增加新字段。迁移尚未完成：Data Portal 中失败 Maestro 步骤的视图已读取新字段，而查询编辑器、笔记本和部分 Slack 客户端仍使用旧路径。

按需调试，按失败结果缓存

第二项功能是 Pensive AI Debugging，给出根因分析和修复建议，可通过 API、MCP 和 Data Portal 界面使用。一次回答需要几十秒到一分钟，所以 Netflix 只在有人要求时才运行，因为多数失败步骤从未被人打开。工作的单位是失败的步骤尝试，其结果被缓存，第二次请求就变成一次键值读取；条件写入可以避免两个调用方同时生成同一个答案；完成的响应在 90 天后过期。服务以流式方式返回答案，每个事件都携带到目前为止的完整文本，因此事件丢失后客户端也很简单。客户端断开连接时，生成仍会继续。

Netflix 如何检查质量

Netflix 把旧规则当作一份冻结的标注来源。一个模型评审判断已知错误是否仍被覆盖，另一个判断每条提取出的错误本身是否有意义。一个脚本会标出出现在约 30% 以上工作流中的重复行，每次调用的延迟也会被记录。日志在 7 到 30 天后过期，因此生产请求会把日志归档到 S3，评测则重放这些归档。每个拉取请求都部署到预览环境，精确率和包含率的阈值决定能否合并，相同的检查在发布晋级后和定期任务中再次运行。对调试答案的每一次“踩”，都会在工作时间内触发一条 Slack 提醒。

这些数字说明了什么，没有说明什么

Netflix 称，AI 提取现在覆盖 100% 的失败，包括旧规则标为“未知”的那些。覆盖率指的是每次都产出了提取结果，并不代表每一条都正确。文章还报告：没有人使用 Pensive AI 的失败尝试，手动查看调试日志的操作次数平均比有人使用的多 321%。Netflix 称这是观察性比较，而不是因果结论。文章没有给出准确率、问题解决耗时或成本，因此其他团队在照搬这一设计之前，应当用自己的失败数据测量这些指标。

对其他团队有什么借鉴

Netflix 的做法有几条可以迁移的原则：让模型输出尽量短、容易校验的内容，比如行号，再由确定性的程序还原文本；让新旧字段并存，分阶段迁移；按失败尝试而不是按用户来缓存，使不同入口看到同一份诊断；用旧规则作为回归基线，并为评测固定输入快照。这些原则并不依赖 Netflix 的具体平台。不过文章也说明，这套系统建立在已有的规则库、Maestro 调度器和日志存储之上，没有这些基础的团队不能指望直接复制同样的效果。