生成 AI は運用と開発の分野で多くの機会をもたらしますが、セキュリティ ソリューションに生成 AI を組み込もうとする人にとっては多くの課題も生じます。
そのような課題の 1 つは、アプリケーションや API を詐欺や不正使用から保護するために使用されるセキュリティ ポリシーなど、サードパーティの AI サービスと共有することが許可されていない機密コンテンツに関する洞察を LLM (大規模言語モデル) を介して収集する方法です。
LLM の 2 つ目の課題は、特に LLM があまり知識のない主題に関連するコンテンツを分析または生成するように求められた場合に、幻覚を起こす傾向があることです。 これは、 DEX などのドメイン固有言語の場合によく見られます。これは純粋に機能的で、静的に型付けされ、チューリング完全ではない言語であり、明確に定義されているものの、広く使用されていません。
最初の課題であるデータのプライバシーは、最初は克服できないように思えます。 セキュリティ企業は、ポリシーを含むすべての顧客データのプライバシーとセキュリティを非常に真剣に受け止める必要があります。 したがって、LLM を使用してポリシーの洞察を明らかにすることは、運用プラクティスと顧客の両方にメリットをもたらしますが、サードパーティの LLM とデータを共有して LLM がデータを処理できないようにすることなく、機密データから洞察を収集できるソリューションが必要です。 2 番目の課題 (幻覚) は、特にポリシー、構成、コードに関する回答に関連して、業界全体が現在克服しようと奮闘している課題です。
人間はプログラムを文字列として認識しますが、コンパイラはそれを別のものとして認識します。 コンパイラにとって、DEX プログラムは AST (抽象構文木) と呼ばれるデータ構造の一種です。 このツリーは有向非巡回グラフであり、問題のポリシーはグラフとして表現するのに適していることを意味します。 したがって、私たちが見つけたソリューションは、グラフ データベース (Neo4j) を活用し、GPT エージェントを使用してそれに対して GraphQL クエリを生成します。 このアプローチは、GraphQL を使用して、サードパーティの LLM からプライバシーを保護しながら、データを含むグラフ データベースをクエリできるため、最初の課題にうまく対処します。
2 番目の課題である幻覚は克服するのがより困難ですが、私たちのアプローチは複数の AI 技術を使用してリスクを軽減することでここでも機能します。 さらに、GraphQL は広く使用され、十分に文書化されたクエリ言語であり、ほとんどの GPT モデルで使い慣れており、さまざまなツールを使用して簡単に構文を検証できます。 これにより、幻覚の可能性が低減され、使用前に正確性を確認する方法が提供されます。
AI 幻覚とは、生成 AI が実際のデータやパターンに基づかずに、捏造または歪曲された出力を生成する事例を指します。 こうした幻覚は、AI のトレーニング データの制限や偏りが原因で発生する場合や、AI がこれまで遭遇したことのない状況で出力を生成しようとしている場合に発生する場合がよくあります。 幻覚は、論理的に意味をなさない、あるいは入力データに当てはまらない、捏造された、あるいは無意味な内容や結論として現れることがあります。 たとえば、テキスト生成 AI は、一見もっともらしい文を生成するかもしれませんが、結局は意味をなさないか、提供されたコンテキストとは無関係な文を生成する可能性があります。
GraphQL は、API (アプリケーション プログラミング インターフェイス) 用のオープンソース クエリ言語であり、データに対して定義された型システムを使用してそれらのクエリを実行するためのサーバー側ランタイムです。 これは Meta (Facebook) によって開発され、従来の RESTful API よりも効率的で強力かつ柔軟な代替手段を提供するように設計されています。 GraphQL API は、クエリまたは変更できるデータのタイプを指定するスキーマによって定義されます。 この強力な型付けにより、より優れたツール、イントロスペクション、検証が可能になります。
生成 AI をセキュリティに安全に組み込むための当社のアプローチは、GPT エージェントの形をとります。 十分に文書化された言語を使用すると幻覚のリスクを軽減できますが、エージェントの出力スペースを、プログラムでエラーをチェックできる形式に制限し、同時に機密データを OpenAI に送信しない方法を見つける必要がありました。出力スペースとして GraphQL を使用すると、ほとんどの質問に答えるのに十分な表現力があり、既知のスキーマに対してプログラムでチェックできる抽象化でもあるため、ここではうまく機能します。
私たちはこのアプローチを DEX に適用しましたが、ソーシャル ネットワーク、ネットワークとインフラストラクチャのトポロジ、サプライ チェーン、地理空間 (マッピング) データなど、十分に相互接続されたリレーショナル データ セットであればどれでも機能します。
PC グラフ アーキテクチャは、DEX をグラフ表現に変換するコンポーネントで構成されています。 結果のグラフ データは Neo4j データベースに保存されます。 GPT エージェントからの出力は、API 経由で GraphQL Apollo サーバーに送信され、グラフ データベースに対してクエリが実行されます。
私たちのエージェントは、GPT4 を使用して、DEX で記述されたポリシーに関する情報に対する自然言語でのリクエストに応答します。エージェントは、pc-graph API を理解し、適切なクエリまたはミューテーションで応答することでこれを実現し、ユーザーはそれを確認および実行できます。
pc-graph API に加えて、当社のエージェントは、使用されるライブラリと DEX 言語に関するいくつかの概念も理解します。 この情報は、最適な結果を提供するために、実行時にコンテキストに含まれるように慎重に選択されます。
これがもたらす課題の 1 つは、エージェントがスキーマの関連部分と、ライブラリによって生成された追加の型、クエリ、ミューテーションを含む neo4j-graphQL ドキュメントなどの補足資料を保持するために大きなコンテキストを必要とすることです。 GPT4-8k を使用すると、適切なコンテキスト内学習を行う余地がなくなります。 32k コンテキストでは許容できる結果が得られますが、追加のコストも発生します。 たとえば、OpenAI へのリクエストごとに GraphQL SDL (スキーマ定義言語) を送信する必要があります。GPT4 会話モデルをスキーマで微調整して、コンテキストに含める必要がなくなれば、これは問題になりません。 ただし、これは現在 OpenAI ではサポートされていません。
GPT4 の結果を改善する 3 つの AI アプローチを見つけました。
最後のステップとして、GraphQL クエリの静的構文エラー チェックを提供するツールを利用して、最初の軽減策をすり抜けた可能性のある幻覚を検出します。
この設計は、最初に同じプロンプトで 3 つの潜在的な回答を生成することによってさらに改善されます。 これにより、特定のプロンプトの時間とコストが削減されるだけでなく、回答の正しい側面が発生する可能性が高くなるため、一貫性も向上します。 こうすることで、起こりそうにないが正確な選択肢を探るために、ランダムな変化を加える余地も生まれます。
私たちのアプローチの結果、個人データを共有することなく、ポリシーから洞察を得ることができました。 クエリ結果の品質と一貫性も著しく向上し、特に複数のフィルターや集計関数を含む大規模または複雑なクエリの構築を伴うタスクでは幻覚が著しく減少しました。
ある意味、私たちは両方を同時に手に入れることができます。創造的なエージェントと決定論的なエージェントのどちらかを選ばなければならない場合、私たちは単に両方を行うのです。