Genie ZeroOpsのご紹介：データとAIの運用をオートパイロットに

データやAIの業務には、常にメンテナンスの問題がつきまといます。データパイプラインは、コードの問題だけでなく、上流のスキーマ変更やデータの遅延到着といったデータ自体の問題によっても頻繁に破損します。MLモデルはドリフトし、劣化しているモデルは、エラーが発生するはるか前から、自信満々に誤った回答を返し続けます。本番環境でデータやAI資産を安定して稼働させ続ける負担はデータチームにのしかかっており、その負担は増すばかりです。LLMやエージェントツールの台頭により、パイプラインの構築やモデルのリリースはかつてないほど迅速になりました。その結果、データチームは構築よりもトラブルシューティング（火消し）に大半の時間を費やしていると報告しています。

Genie ZeroOpsによるエージェント型運用

データチームのこのような運用負荷を軽減するために、私たちはGenie ZeroOpsを開発しました。これは、データやAI資産（パイプライン、ジョブ、テーブル、MLモデルなど）を自律的に監視し、問題が発生する前、または発生した際に対処するバックグラウンドエージェントです。Databricks内で動作するため、以下に安全かつ簡単にアクセスできます。

• 完全なオブザーバビリティ：プラットフォームのオブザーバビリティレイヤーからのメトリクス、イベント、ログ、実行履歴。
• Unity Catalogによるデータリネージ：すべての資産の完全な依存関係グラフにより、障害の真の根本原因を追跡できます。
• サンドボックス環境：Genie ZeroOpsは、本番データを隔離された環境にシャロークローン（基盤となるデータを複製せずにメタデータを使用してテーブルクローンを作成）し、権限のガードレールとネットワークの隔離を適用した上で、本番環境に影響を与えることなく実際のデータに対して提案された修正案を検証します。

障害が発生するたびに、以下のプロセスが実行されます。

1. 検出：プラットフォームのオブザーバビリティへのアクセスによる継続的な監視。エラーが発生する前にデータ品質メトリクスに現れるサイレント障害も検出します。
2. 評価・分析：Unity Catalogのリネージにより、Genie ZeroOpsは完全な依存関係グラフを把握できます。これにより、障害の原因がコードのバグなのか、3つ上流のテーブルでのスキーマ変更なのか、あるいは別のパイプラインから混入した不正なデータなのかを追跡できます。
3. 修復：開発ワークフロー（GitHubのPR、Jiraチケットなど）をコンテキストとして考慮しながら、エージェントによるコード生成で修正案を作成します。
4. 検証：Genie ZeroOpsは、データのゼロコピークローン、スコープ設定された権限、ネットワーク隔離を備えた安全なサンドボックスを実行します。提案された修正案は、本番環境ではなく、そのサンドボックス内の実際のデータに対して実行され、ユーザーが承認するまで本番環境に適用されることはありません。
   

コーディングエージェントではデータやAIの運用を解決できない理由

なぜデータやAIの運用に特化したエージェントが必要なのでしょうか？ソフトウェア開発を支援するのと同じコーディングエージェントを使って、同様の結果を得ることはできないのでしょうか？その答えは「いいえ、それは困難です」です。

コーディングエージェントはソフトウェアエンジニアリング向けに構築されていますが、データエンジニアリングとAIは根本的に異なります。

• コンテキストにはコードだけでなくデータも含まれる：パイプラインの障害は、上流のスキーマ変更、依存関係チェーンを通じて伝播する不正なデータ、またはサイレントな破損によって発生することがよくあります。これらはコードだけでは特定できません。
• 障害はサイレントかつ永続的になり得る：データのバグは本番テーブルに何週間も潜み続け、下流のコンシューマーに悪影響を及ぼす可能性があります。発見したときには、すでにビジネス上の影響が顕在化しています。
• 本番データは機密性が高く、ガバナンスが適用されている：コードとは異なり、本番データを自由にコピーしたり、共有したり、外部ツールに渡したりすることはできません。

何かが破損した場合は、それを検出し、根本原因を評価・分析し、修正案で修復し、副作用なく動作することを検証する必要があります。

各ステップを検証すると、一般的なコーディングエージェントでは不十分であることがわかります。検出においては、テレメトリなどのコンテキストが不足していたり、Apache Spark™のログのような非常に大きなコンテキストの処理で行き詰まったりすることがあります。評価・分析（根本原因とその影響の特定）においては、リネージデータへのアクセス権がないことがよくあります。また、データやAIの業務に特化したハーネス（実行環境）がないため、プロセスにコストと時間がかかります。コーディングエージェントは修復のためのコードを書くことはできますが、適切に行うためのコンテキストが不足していることが多く、データ関連の問題を解決することはできません。しかし、コーディングエージェントにとって最も困難なステップは「検証」です。

検証を行うには、隔離された環境で実際の本番データに対してコードの修正をテストする必要があります。外部のエージェントに本番データへのアクセス権を与えることはできません。仮に与えたとしても、本番データに対してコードを実行すると、壊滅的な結果をもたらす副作用のリスクがあります。

エージェントが検証ステップを安全に処理するには、データプラットフォーム自体の一部である必要があります。Genie ZeroOpsはDatabricksプラットフォームの一部であり、だからこそコーディングエージェントが失敗する領域で成功を収めることができるのです。

特に機械学習のワークロードは、運用業務に特化したエージェントのメリットを顕著に示しています。

機械学習向けのGenie ZeroOps

本番環境のMLは、データエンジニアリングにさらなる課題をもたらします。パイプラインにエラーがなくても、モデルが不適切な予測を出力している可能性があるため、パイプラインを稼働させ続けるだけでは不十分です。モデルの出力が依然として信頼できるかどうかを監視する必要があります。

信頼できない場合、Genie ZeroOpsは原因を診断し、修正された候補を作成し、実際のトラフィックに適用する前に検証します。パイプラインの修正については、テーブルのシャロークローンに対して検証を行います。モデルについては、修正された特徴量で候補をトレーニングし、一般的なベンチマークではなく、本番モデルに適用されていたものと同じ評価スイートおよび基準で評価します。測定可能なレベルで改善されている場合にのみ候補を提示し、正式に切り替える前に実際のトラフィックで段階的に適用（ランプアップ）することができます。

これらの修正を信頼できるものにしているのは、コンテキストです。ML向けのGenie ZeroOpsは、Genie CodeやGenie Ontologyと同じ基盤の上に構築されており、DatabricksのMLスタック（Feature Store、MLflow、モデルサービング、ノートブック）とネイティブに統合されています。モデルがどの特徴量を使用しているか、チームがそれをどのように評価しているか、そしてビジネスにとって何が「適切」であるかを把握しているため、シニアMLエンジニアと同じように推論することができます。

常に管理権限を維持

Genie ZeroOpsが監視する資産と、その実行権限を設定できます。すべてがUnity Catalogのガバナンス下で実行されるため、ユーザー自身の資格情報が許可するデータにのみアクセスできます。課題はインボックス形式のUIに重大度順に表示され、それぞれに根本原因分析と提案された修正案が添えられます。ユーザーの承認なしに本番環境に適用されることはありません。

サンドボックスは、技術的な信頼レイヤーです。シャロークローンにより、修正案は実際のデータでテストされますが、本番環境に影響を与えることはありません。スコープ設定された権限とネットワーク隔離により、サンドボックス環境がその境界の外にアクセスすることはありません。テストされた内容がそのまま適用されます。

これがGenie ZeroOpsの価値です。運用を安全にスケールさせることができます。面倒な作業はエージェントが担当し、ユーザーは常に管理権限を維持できます。

Genie ZeroOpsは間もなく登場します

Genie ZeroOpsは、今後数週間以内にプライベートプレビューが開始される予定です。まずはジョブ、パイプライン、テーブル、MLワークロードのサポートから開始します。アプリやLakebaseデータベースもロードマップに含まれています。

早期アクセスをご希望の場合は、Databricksのアカウントチームにお問い合わせください。それまでは、Genie OneやGenie Codeなど、Genieファミリーの他の製品をご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事