NetflixのPensive AI、ログの行番号を返させて失敗したデータジョブを診断

Netflix、固定ルールをAIで包み、失敗したデータジョブを診断

Netflix Technology Blogは10月26日、データと機械学習のワークロードがなぜ失敗したかを技術者が把握するための仕組み、Pensive AIについて長い解説記事を公開した。Netflixによると、ピーク日にはTitus、Spark、Trino、Druidなどのエンジン全体で約10万件のワークロードが失敗する。従来のPensiveは、失敗したジョブのログを読み、正規表現と手書きのJavaルールでエラーを分類し、再試行の助言をワークフロー管理のMaestroなどに渡していた。これにより失敗の約半数は利用者が自力で対処できるようになった。ある3か月の間に約700万件の分類を処理したが、その約半数は「不明」に入った。Pensive AIは、すでに機能しているルールを捨てずにこの空白を埋めるために作られた。

丸写しではなく、行番号で抽出する

最初の機能であるエラー抽出は、失敗したステップごとに動く。設計上の要点は、モデルの答え方にある。Pensiveは各ログの行に番号を振り、行番号とテキストの組をモデルに見せる。モデルが返すのはエラーの先頭行と末尾行の二つの整数だけで、文章はPensiveが保持する元のログから復元する。Netflixは二つの理由を挙げる。出力トークンの生成は入力の読み取りより遅いこと、そして表示される文章が元のログから直接取られるため、でっち上げが減ることだ。ここでのトークンはモデルが文章を処理する単位である。モデルが範囲を誤る可能性は残るので、抽出の質は評価の一部になっている。この呼び出しは、失敗ステップの後処理にMaestroが課す90秒の厳格な上限の内側に置いた共通の締め切りを持ち、間に合わなかったログの呼び出しは捨てられ、全体の応答は時間内に返る。Netflixは旧来のエラー欄を残し、その隣に新しい欄を加えた。移行は未完了で、失敗したMaestroステップを表示するData Portalの画面は新しい欄を読むが、クエリエディタ、ノートブック、一部のSlackクライアントは旧経路を使い続けている。

要求に応じて診断し、失敗ごとにキャッシュする

二つ目の機能Pensive AI Debuggingは、根本原因の分析と修正案を出す。APIとMCP、Data Portalの画面から使える。回答には数十秒から1分かかるため、Netflixは誰かが求めたときだけ実行する。失敗したステップの大半は誰にも開かれないからだ。作業の単位は失敗したステップの試行で、結果はキャッシュされる。二回目の要求はキー・バリューの読み取りになり、条件付き書き込みによって二人の呼び出し側が同じ回答を同時に生成することを防ぎ、完了した応答は90日で失効する。サービスは回答をストリームで返し、各イベントはそこまでの全文を運ぶので、イベントが落ちてもクライアントは単純なままでよい。クライアントが切断されても生成は続く。

Netflixの品質確認の方法

Netflixは旧来のルールを、固定した正解ラベルの供給源として使う。一つのモデル判定は既知のエラーが引き続き含まれているかを確かめ、もう一つは抽出した各エラーがそれ自体で意味を持つかを確かめる。スクリプトは約30%を超えるワークフローに現れる行を洗い出し、すべての呼び出しの遅延も記録する。ログは7日から30日で失効するため、本番のリクエストはログをS3にアーカイブし、評価はそのアーカイブを再生して行う。プルリクエストごとにプレビュー環境へ配備し、精度と包含の基準が合流の可否を決め、同じ検査は本番昇格後と定期実行でも走る。デバッグ回答への「低評価」は、勤務時間中にSlackの通知を送る。

数字が示すものと示さないもの

Netflixは、旧ルールが「不明」と分類したものを含め、AIによる抽出は現在すべての失敗を対象にしていると述べる。対象とは抽出結果が出るという意味であり、個々が正しいという意味ではない。記事はまた、誰もPensive AIを使わなかった失敗の試行では、使った試行に比べて手動のデバッグログ操作が平均で321%多かったと報告する。Netflixはこれを因果ではなく観察に基づく比較だとしている。記事には正答率も、解決までの時間も、費用の数字もない。他のチームは設計を真似る前に、自分たちの失敗事例でそれらを測る必要がある。