你让 AI 帮忙查一次任务失败，它很快给出解释：“可能是内存不足。”麻烦在于，这句话究竟来自哪一行日志，还是模型自己补出的合理故事？对值班人员来说，不能复核的答案，往往只是多了一条需要调查的线索。Netflix 的 Pensive AI 想解决的正是这个问题：让 AI 协助诊断，同时把结论指回原始证据。
这里的“工作负载”（workload），就是交给计算系统执行的一项任务，例如处理日志、训练模型或生成数据表。Netflix Technology Blog 称，其数据与机器学习从业者每天会在 Titus、Spark、Trino、Druid 等系统上运行数百万个工作负载；高峰日约有 10 万个失败。失败之后，人仍要翻查多份日志，判断问题来自自己的代码还是平台，再决定重试、修改配置或交给平台团队。
老规则管已知，AI 补未知
Pensive AI 的前身 Pensive 并不是大模型产品。它是一套自动诊断与修复系统：用正则表达式和人工编写的 Java 规则，从日志里提取、分类错误，再向 Maestro 等产品给出重试或修复建议。Maestro 属于编排系统——它按依赖关系和时间安排任务，例如先完成数据清洗，才启动下游报表。
据 Netflix Technology Blog，原有 Pensive 让约 50% 的故障可以由用户自助处理，其中一部分还能自动处理。但规则只能识别已经见过的模式。每增加一种故障，都要有人先读懂日志、写出规则，并在日志格式变化后继续维护。
这个缺口并不小。博客称，在某个三个月周期内，Pensive 处理了约 700 万次作业故障分类，其中约一半落入“unknown”。Netflix 因而没有推翻旧系统，而是保留确定性规则，再用 AI 增加错误提取，以及更聚焦的诊断和修复建议。
不让 AI 复述证据
Pensive AI 最值得注意的设计，是限制模型能做什么。为了避免模型把错误日志改写成一段听起来合理、却并非原文的话，系统让模型只返回错误片段的起止行号，再从自己的日志副本中取回对应文本。
这像让调查助手指出档案的页码，而不是凭记忆抄写证词。用户看到的证据来自原始日志，模型也少生成了大量 token——也就是模型处理和输出文本时使用的基本单位。这里的“可验证诊断”，不是保证 AI 一定判断正确，而是让值班人员能沿着行号回到现场，检查它依据了什么。
响应时间也受到约束。Maestro 留给后处理的时间是 90 秒，因此系统会并行分析不同日志源；没有及时完成的调用会被舍弃。换句话说，设计目标不只是“尽量回答”，还包括让产品行为及时且可预期。
评测也要保存案发现场
故障诊断的评测还有一个容易忽视的问题：现场会消失。据 Netflix Technology Blog，用于诊断的生产日志最快 7 天、最迟 30 天便会过期。如果不同模型或提示词在不同日期读取日志，比较结果就可能受到输入变化影响。
团队因此让生产请求异步保存当时的日志快照到 S3，并禁止覆盖已有对象。以后比较模型或提示词时，各候选版本读取同一份日志。这样既固定了评测输入，也避免实验反复访问线上日志系统，并可把模型升级纳入 CI/CD——持续集成与持续交付的自动发布流程——的质量门禁。
为什么值得关注
Pensive AI 展示的重点，不是让模型自由阅读更多日志，而是给它划定边界：证据由原系统取回，评测使用固定现场，线上响应服从时间限制，原有规则继续处理确定问题。AI 在这里更像搜集和组织证据的助手，而不是拥有最终解释权的裁判。
这也把“可靠”拆成了几件可以检查的事：提取范围是否受限，输入能否复现，响应是否及时，质量检查能否从本地开发延续到生产环境。相比一句笼统的“AI 能诊断故障”，这些工程约束更具体，也更容易复核。
局限与未知
- 现有材料全部来自 Netflix Technology Blog，尚无论文、代码仓库或外部报告交叉验证。
- 材料没有披露所用模型、评测数据集、准确率、误诊率、人工基线或线上收益，因此不能据此断言诊断效果已经得到量化证明。
- “约 50% 可自助处理”和“约 700 万次分类”的分母、成功标准与统计口径并不完整；700 万次分类也不等于 700 万个独立故障。