Netflix如何用大模型做任务故障排查？Pensive AI实战

在大规模数据平台中，工作流报错排查向来是耗时耗力的脏活。调度系统每天运行数以万计的任务，只要底层计算引擎或依赖稍有异常，工程师就得一头扎进动辄数千行的日志堆里翻找根因。

过去，Netflix 依赖基于规则的系统 Pensive。工程师为已知的报错手写正则表达式：

规则很精确，但极度脆弱。只要底层引擎升级、日志格式微调，或者出现全新的未知错误，规则立刻失效。为此，Netflix 团队引入大语言模型，重构了故障诊断系统 Pensive AI。

他们没有盲目将整份日志直接塞给模型做长文本对话，而是通过一套兼顾延迟、成本与稳定性的工程架构，让 AI 排障真正具备了生产级的高可用性。

Pensive AI 架构
图 1：Pensive AI 整体架构。常驻错误提取与按需深度诊断互为补充，共用日志源、大模型网关、Tracing 链路与缓存层。

Pensive AI 采用了两条并行的处理路径：

常驻错误提取（Always-on Error Extraction）：低延迟、低成本。任务一旦失败自动触发，只负责从海量文本中挑出最核心的报错片段，为开发者提供排查切入点。
按需深度诊断（On-demand Debugging）：高智能、按需触发。当用户需要深入分析时，模型会结合多份日志与上下文进行多步推理，输出根本原因和修复建议。

绝大部分失败任务并不需要昂贵的大模型推理，这种动静结合的设计大幅压低了平台的日常运行开销。

大模型推理中，生成 Token（Output）的耗时和成本远高于读取 Token（Input）。直接让模型把报错堆栈逐字抄写一遍，不仅又慢又贵，还极易出现字符幻觉。

错误提取流程
图 2：错误提取机制。传统规则与大模型并行运行，共享执行死线，超时直接熔断。

Netflix 采用了一种极简且巧妙的方案：日志切行编号。

在将日志输入给模型前，系统会给每行打上序号，构造成 {lineNumber, text}。模型的任务被严格约束：只返回关键错误片段的起始行号和结束行号（两个整数）。

无论报错堆栈跨越几行还是几百行，模型只吐出两个数字。系统拿到行号后，直接从原始日志副本中切片渲染给前端。这带来了三个直接好处：

此外，调度平台对单次执行失败的后处理有严格的时间预算（90秒）。Pensive 对多份日志并行调用模型提取，并设置统一的全局死线。某个日志源的抽取一旦超时，直接丢弃该部分结果，确保主链路永不挂死。

完整的根因分析可能耗费几十秒，如果每次页面刷新都重调一次模型，不仅账单吃不消，团队协作时还会出现诊断结论不一致的问题。

按需排障机制
图 3：按需诊断流程。条件写锁抢占任务处理权，结果持久化入缓存，生成过程通过流式推送。

Pensive AI 将**单次失败尝试（Step Attempt）**设为诊断的最小实体，而非将「触发排障的人」作为实体。

分布式防击穿：当多名工程师同时点开同一个报错页面时，系统通过条件写入争抢生成权。一人触发生成，其他人等待同一份结果。
全局缓存：诊断结果写入缓存并保留 90 天。无论是网页端查看，还是通过 MCP（Model Context Protocol）由命令行接入，命中即返回。
连接解耦的流式推送：后端采用 SSE 生成，经由 GraphQL WebSocket 推送到前端。即便用户中途刷新或切走页面，后台推理依然会完整写进缓存；页面重载后直接轮询拿取最终状态即可。

大模型排障不能只靠几个 Demo 碰运气，系统升级、提示词微调、日志裁剪逻辑变更都可能导致召回率雪崩。Netflix 将评测体系完全嵌入了日常开发与发布链路：

冷冻规则作为基准底线：将多年积累的手写正则作为测试集底线，要求 AI 的提取结果必须覆盖原有规则识别出的关键信息。
挖掘历史排障记录：自动化检索内部技术支持群中已解决的问题贴，用另一套模型抽取「问题-结论」对，还原成带真实上下文的评测用例。
多维质量评测：
- 包容度（Inclusion）：模型判断 AI 提取内容是否涵盖了核心已知错误；
- 准确率（Precision）：评估提取片段是否真正具备排查指导价值；
- 去噪率（Noise Filtering）：统计在全量数据集中出现率超过 30% 的套话日志（如通用状态提示），一律拉入黑名单拦截；
- 硬性延迟门禁：质量提升如果伴随显著耗时增加，直接驳回。