AI は、災害が発生する前に開発者のコーディング エラーを予測して修正することを目指しています
Dynatrace の CTO によると、生成 AI をより従来型の人工知能と組み合わせることで、アプリケーションが本番稼働する前にコンピュータ システムがどのように故障するかを予測することができます。
生成 AI は、アプリケーション障害の原因を特定し、障害を予測できる DevOps システムと組み合わせられています。
Microsoft の GitHub Copilot がプログラミング コードを自動的に修正してくれると信じるのは時期尚早です。 Microsoft自身も、このプログラムはGitHubに月額10ドルのアドオンとして販売されており、「完璧なコードを記述しているわけではない」、「安全でないコーディングパターン、バグ、または古いAPIやイディオムへの参照が含まれている可能性がある」と述べている。
しかし、自動化の夢は、いつか人工知能が、機能を破壊したりシステムをダウンさせたりする可能性のあるプログラムの欠陥を予測し、コードが本番環境に入る前に開発者に警告するだけでなく、変更方法も指示するようになるだろうと示唆しています。問題を回避するコード。 AI がアプリケーション コードにアクセスして、プログラマーに代わって自動的に修正して、プログラマーの労力を大幅に節約できる可能性もあります。
このような未来の成り立ちは、DevOps と可観測性のための今日のツールに見ることができます。 DevOps ツールメーカーの Dynatrace は、プログラムがダウンする理由を特定し、どのように失敗するかを予測するために、「因果関係 AI」と「予測 AI」と呼ばれるものを長年構築してきました。
次の段階では、これらの可観測性ツールの周りに生成 AI をラップして、コードがどのように問題に遭遇するか、そしてそれを軽減する方法についてプログラマーに提案を提供します。
Dynatrace の最高技術責任者、Bernd Greifeneder 氏は、「CIO からの典型的な要求は、実際に障害が発生する前にシステムを修正してほしいというものです」と述べています。
「CIOからの典型的な要求は、実際に障害が発生する前にシステムを修復してほしいというものです」と、Dynatraceの最高技術責任者で共同創設者のBernd Greifeneder氏はZDNETのインタビューで語った。 Dynatrace は、DevOps および可観測性市場の商用ソフトウェア ベンダーであり、アプリケーション ライフサイクル管理用のツールを販売しています。
日常的なシステムの落とし穴を考えてみましょう。それは、Amazon の AWS のディスク容量が不足することです。
「まったく皮肉なことだ」とグライフェネダー氏は指摘した。 「超ハイテクの昨今でも、AWS のどこかのクラウド ディスクのディスク容量が不足するのは問題であり、サイズを変更するには API 呼び出しをトリガーする必要があります。私たちはサイズを変更したくありません。コストがかかるので、使用するものを最適化したいと考えていますが、使用パターンはクラスター内の顧客の数などに応じて変化する可能性があります。」
必要なのは、過去のパフォーマンスに基づいてディスク不足エラーが発生する可能性が高い場合に即座に動作するコードを作成することです。
この問題に対処するために、同社はまず因果関係 AI と予測 AI を組み合わせて、ディスク障害の「根本原因」を特定します。これら 2 つのツールは、大規模な言語モデルやその他の生成 AI に基づいていません。代わりに、厳密で一貫した結果を生み出すことが期待できる、より古く、より確立された形式の人工知能に依存しています。
因果的 AI の場合、プログラムは分位点回帰、密度推定、ランダム サーフィン モデルとして知られるものなど、いくつかのアルゴリズムを使用します。データ ポイント間の相関関係を検出するために静的なデータ セットでトレーニングされるニューラル ネットとは異なり、因果関係プログラムは、企業の IT システムの要素とその関係を表すグラフを横断するために使用されます。
「一般的な統計モデルやニューラル ネットワーク タイプの学習モデルは、より大きな範囲の動的な IT システムには機能しません。変数があまりにも変化するためです」とグライフェネダー氏は述べています。 「当社の顧客は数万から数十万のポッドを所有している可能性があり、それらの多くは相互接続されており、トラフィックのルーティング中に変更され、物事が拡張され、さまざまなバージョンが存在します。」
グライフェネダー氏が顧客の IT システム全体の「メモリ内リアルタイム モデル」と呼ぶものを構築するために、因果関係 AI プログラムは「多次元グラフのような、因果的で有向な依存関係を持つ多次元モデル」を構築します。すべてのエンティティ -- どのクラウド サービスであるか、どのバージョンの Kubernetes が使用されているか、どのアプリが実行されているかに至るまで。 Smartscape と呼ばれるそのモデルは、警報を発するシステム問題が発生するたびに参照され、「Smartscape モデルの調査に基づいて根本原因を推測」します。
ただし、その因果モデルはビジネスの変動を予測するものではありません。グライフェネダー氏は、「物事の根本原因は知っていますが、知らないのは、あなたのビジネス パターンが何かということです」と述べました。つまり、「月曜の朝 8 時に大きなスパイクが発生した」というような意味です。何らかの理由で使用中です。」
このような異常については、「何らかの形で歴史に基づいた学習が必要だ」とグライフェネダー氏は言う。
この履歴学習を実現するために、予測 AI コンポーネントは、自己回帰統合移動平均など、別のよく開発されたツール セットを使用します。これは、時間の経過とともにデータ内で発生するパターンをつなぎ合わせることに特に適したアルゴリズムです。
Dynatrace のカジュアルな予測 AI は、実績のあるさまざまなアルゴリズム アプローチを使用して、運用アプリケーションで何が起こっているかを示す信号を分析します。
重要なことは、予測 AI はサーバーなどのバックエンド システムのみを考慮しているわけではありません。また、ネットワーク内のエンドポイントから、エンドユーザーがどのように遅延やサービスの中断を経験しているかなどの信号も受信します。
「サーバー側のシステムだけを見るだけでは十分ではありません」とグライフェネダー氏は言う。 「たとえば、実際のユーザーの監視や API サービスの監視は、依存関係を理解する上で重要な側面です。」
CIO はシステムを最も重視しますが、サーバーが正常に動作している場合でもユーザーの問題が発生する可能性があるため、バックエンドとユーザー エクスペリエンスの両方を測定して比較する必要があります。
「時々、サーバーのことだけを気にする IT 専門の人に出会うことがあります。『ああ、サーバーが稼働しているよ』というようなことですが、実際には、ユーザーはイライラしています」と彼は言いました。 「その逆も存在します。CPU の 1 つが暴走したからといって、エンドユーザーが影響を受けるわけではありません。」
ディスク容量の例に戻ると、因果関係 AI と予測 AI は将来のディスクの問題を予測できます。 「クラスター内の過去数日、数週間の使用状況から推定して、『ああ、今から 1 週間以内にディスク容量が不足する危険性がある』 ことがわかります」と Greifeneder 氏は述べています。
これが、「Dynatrace の自動化エンジンからワークフロー アクションをトリガーして、AWS に API を呼び出してディスクのサイズを変更し、これが原因で過去に発生した停止を自動的に防止しましょう」といった、プロアクティブな措置を講じる原動力となります。
ここで、生成 AI がプロセスに組み込まれます。 Dynatrace の包括的なプログラムである Davis AI には、今年、因果関係システムと予測システムの上に乗る Davis CoPilot と呼ばれるコンポーネントが追加されました。
ユーザーはコパイロットに「実際にこの[ディスク停止を事前に]防ぐ自動化を作成してください」と入力できます。コパイロットは、因果的予測 AI に問い合わせを送信して、そのプロンプトでどのディスクが参照されているかを尋ねることができます。これに応じて、Davis プログラムは Smartscape と予測情報を使用して、現在の状態の IT システムを理解するために必要なコンテキストの詳細をすべて含むプロンプトを作成します。
そのプロンプトはコパイロットに送信され、詳細が与えられると、ディスクのサイズ変更を「自動化するためのワークフローのテンプレートが返される」とグライフェネダー氏は説明した。 「ユーザーは、これを確認して、『OK、これはほぼ正しい、ありがとう、90% を達成するのに役立ちました』と言えるようになります。これにより、ワークフローを最初から構築する場合と比べて、システム エンジニアの時間を節約できます。
次のステップは、Davis AI プログラムが、最初にアプリケーションをコーディングするときに、これらすべての観察結果をプログラマーに返すことです。アプリケーション開発の最終目標は、後から問題を修正するのではなく、アプリケーションを実稼働環境に導入する前に、障害の原因となるコーディングを防止することです。
アプローチの 1 つは、Dynatrace がガーディアンと呼ぶものです。 DevOps 担当者は、アプリケーションが実稼働環境に投入される前に、特定のアプリケーションのパフォーマンス目標を監視するガーディアンを作成するよう、自然言語でコパイロットに依頼できます。同社はこれを「コード内で品質目標を定義する」と呼んでいる。次に、因果要素と予測要素を使用して、コードが定義された目的を満たしているかどうかを検証します。
もちろん、Davis AI が潜在的に問題のあるコードを認識した場合、問題はそれを修正する方法です。 Davis CoPilot にコード修正の可能性をプログラマーにアドバイスさせることも可能ですが、これはまだ新しい分野です。
「私たちは、この Davis CoPilot を使用して、お客様のテクノロジー スタックに基づいて本番環境でこの脆弱性をどのように特定したかについての推奨事項を提供することを検討しています。Davis CoPilot は、コード内で修正するために確認する必要があるこれらの推奨事項を提供します」と Greifeneder 氏は ZDNET に語った。
グライフェネダー氏は、この種のコード修正の推奨に生成 AI を使用するのはまだ初期段階にあると述べた。因果予測 AI は信頼できるように設計されていますが、生成アルゴリズムには依然として「幻覚」現象が発生しており、プログラムが自信を持って不正確な情報を主張することになります。
「信頼できるのは、因果関係のある AI から得られるものです。それが正確なシステム状態だからです」と彼は言いました。 「つまり、私たちはそこに何があるのかを正確に知っています。信頼できないのは、コードを変更する方法に関する潜在的な推奨事項です。これは公開されている GPT-4 モデルからのものであるためです。」
したがって、修復のためのコード提案は有効な前提から始まる可能性がありますが、GitHub Co-pilot と同じ問題、つまりどのコードが適切であるかについて厳密な感覚を持たないという問題に遭遇します。生成 AI の提案に根拠を与えるために、大規模な言語モデルを Dynatrace などが提供するツールとより緊密に統合する必要があります。
GPT-4 とその類似品に関する正式な研究では、コードの脆弱性の発見と修正に関して非常に複雑な結果が報告されています。 GPT-4の導入に伴い3月にOpenAIが発表した技術文書では、同プログラムに依存しないよう警告していた。 GPT-4は「[…]特定された脆弱性に対するエクスプロイトの構築においてパフォーマンスが低かった」としている。
ペンシルバニア大学の研究者クリス・コッホ氏が2月に発表した、GPT-4の前身であるGPT-3に関する研究は勇気づけられるものだった。これは、GPT-3 が既知の脆弱性を対象に厳選された GitHub リポジトリ ファイルのコレクションから 213 件の脆弱性を発見できたことを示しています。この数は、ソフトウェアの脆弱性をテストするために一般的に使用される「静的アプリケーション セキュリティ テスト」 (SAST) の一種である Snyk という人気のコード評価ツールで見つかった 99 件のエラーをはるかに上回っていました。
しかし、Koch 氏は、GPT-3 と Snyk は両方とも多くの脆弱性を見逃していた、つまり知られているように、多くの「偽陰性」があったと指摘しました。
サイバーセキュリティ企業ピープルテックによるその後の研究は、コッホ氏の研究に基づいて行われ、8月にリリースされた最新のGPT-4をテストした。 GPT-4 では、同じファイル内で 4 倍の脆弱性が発見されたことがわかりました。
ただし、どちらの調査でも、合計 2,000 行をわずかに超えるコードに相当するファイルに対して GPT-4 がテストされました。これは、リンクされた多数のファイルにわたって数十万行から数百万行のコードが含まれる可能性がある完全な運用アプリケーションに比べれば、ごくわずかです。 GitHub ファイルの複雑な問題に対する成功が、このような複雑さまで拡張できるかどうかは明らかではありません。
その大きな課題のために言語モデルを拡張しようとする競争が進行中です。 Dynatrace に加えて、オープンソース ツールの商用バージョンを販売する英国の非公開企業 Snyk Ltd. も、同社が「DeepCode AI」と呼ぶものを提供しています。このテクノロジーは、他のツールと統合することで生成 AI のつまずきを回避できる、と Snyk 氏は主張しました。 「DeepCode AIのハイブリッドアプローチは、アプリケーションを保護するという1つの目的のために複数のモデルとセキュリティ固有のトレーニングセットを使用する」と同社は述べている。
生成 AI には、実際の運用 IT 環境の複雑さはさておき、単純な種類のプログラミングのデバッグと修正さえも解決する余地があることは明らかです。 AI による大きなシフトはまだ実現していません。
Davis Copilot とそれに類似した取り組みによって実現しようとしているのは、プログラマーがコードを出荷する前と後の両方で、より積極的に自分のコードを検査できるようにするための新しいインターフェイスとして生成 AI を使用することです。