LLMなしでもSRE診断はここまでできる――Jev駆動パイプラインが障害の76%を特定
Jev-Driven SRE Diagnosis: What Worked and What Failed
LLMエージェントを使わず、Jevの高速判断だけでKubernetes障害を診断するパイプラインを構築。クラスタ証拠をプログラムで収集しJevに選択肢として提示、根本原因と証拠を推定させる。21種類の障害で105回中80回（76.2%）成功、診断時間中央値14.6秒、推論コストはわずか0.15ドル。全試行が同じ結果になるほど一貫性が高く、admission webhookのリソース制限書き換えなど複雑な障害も的中させた。
Jevは与えられた選択肢の中から選ぶだけで、コマンドを生成したり最終レポートを書いたりはしない。
HNでの議論
10- clintonb
> 最終的に、Jev駆動の診断をSREエージェントのワークフローに組み込むことは、System OneとSystem Twoモデルを効果的に組み合わせるための重要な一歩だと私たちは考えています。
なぜ？最終目標は何？コスト削減？分析の高速化？
私はSlack経由でページに応答するエージェントを設定しました。ClickStack（テレメトリ用）、Kubernetes、GitHubにアクセスできます。Sonnetモデルの1つを実行しています。コストは非常に低く、1日に十数件未満のページ（ほとんどが非常に敏感なエラー数アラームから）に応答するだけなので、Jevに切り替えるのは全く意味がありません。ましてや結果の信頼性が低いとなればなおさらです。
- beebmam
私には、Jevは入力コンテキストが少なく、多くの迅速な決定を下す必要がある場合に設計されているように思えます。SREの仕事は、おそらく入力コンテキストが多く、ごく少数の重要な決定を下すのに最適です。
- amne
私はローカルの「AI」音声コントロールのために決定モデルに切り替えました。faster-whisperがテキストを生成し、次にonnxがすべてのHAエンティティをスコアリングして、私がどれについて話しているかを判断します。その後、すべてのアクションをリストし、2回目のスコアリングラウンドで私が望むアクションを決定します。「10分間芝生に水をやって」のようなことを言う場合、数字を抽出するためのいくつかの正規表現があります。LLMと比べるとかなり馬鹿げていますが、levenshteinやそのような粗雑なアルゴリズムに頼らずに「手元で」セマンティックスコアリングができるようになったことを考えると、それがいかに賢く見えるかは驚異的です。
そして明らかな質問に答えると：レイテンシーのためです。これは2001年の8GB RAMのラップトップで、すべてラップトップ上でローカルに実行され、100ms未満でライトや水バルブをオンにします。