データベース

AlloyDB で自然言語がサポートされ、リアルタイムデータを活用した生成 AI アプリの構築が可能に

2024年4月23日

https://storage.googleapis.com/gweb-cloudblog-publish/images/Next24_Blog_blank_2-04.max-2500x2500.jpg

Google Cloud Japan Team

※この投稿は米国時間 2024 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI を活用すれば、AI/ML に関する専門知識がなくても、インタラクティブでパーソナライズされた、完成度の高いエクスペリエンスをユーザーに提供できるようになります。基盤モデルが市場に浸透するようになってから、可能性の範囲に留まっていた各種の機能が、急速に現実味を帯びたものになっています。デベロッパーはどのようにして、正確性、関連性、安全性に優れたエンタープライズグレードのエクスペリエンスを実現できるでしょうか。

運用データは、トレーニング済みの基盤モデルと実際のエンタープライズアプリケーションの橋渡しをするものです。トレーニング済みモデルによってフランスの首都を調べることはできても、どのような商品が在庫にあるかはわかりません。つまり、こうしたモデルを基盤として構築された生成 AI エクスペリエンスの良否は、デベロッパーが基盤として使用するデータとコンテキストアプリケーションによって決まるということです。そして、オペレーショナルデータベースには最新のデータが含まれているため、このデータが優れたエクスペリエンスを創出するうえできわめて重要な役割を担うことになります。

今週の Google Cloud Next ‘24 では、デベロッパーがリアルタイムの運用データを生成 AI アプリケーションに組み込めるようになる、AlloyDB for PostgreSQL での自然言語のサポートが発表されました。これにより、データに対して自然言語を使用して正確にクエリを実行するアプリケーションを構築できるようになり、柔軟性と表現力を最大限に高められます。生成 AI アプリは、より広範な予測できない質問にも対応できるようになります。

また、このような新しいアクセスパターンに対応するための、生成 AI フレンドリーな新しいセキュリティモデルも発表されました。AlloyDB には、エンドユーザーデータへのアクセスをデータベースレベルでロックダウンする新しいデータベースビューである、パラメータ化されたセキュアビューが導入されました。それにより、プロンプトインジェクション攻撃に対する保護が可能になっています。今回発表された AlloyDB の進化は、リアルタイムデータを生成 AI アプリに統合する新しいパラダイムを提示するものです。精度やセキュリティを犠牲にすることなく、エンドユーザーのあらゆる質問に対応できる柔軟性が実現します。

エンドユーザーアクセス制御や NL2SQL プリミティブなどの機能をはじめとする AlloyDB AI の自然言語サポートは現在、ダウンロード可能な AlloyDB Omni エディションのテクノロジープレビューで利用可能です。

高い柔軟性に対するニーズ

データは正確かつ適切な回答を返す上できわめて重要であるため、生成 AI アプリケーションにデータを組み込むためのさまざまな手法が登場しています。

Google は昨年、AlloyDB と Cloud SQL のベクトルデータベース機能を発表しました。それにより、生成 AI アプリでデータを取得するための最も一般的なパターンである検索拡張生成（RAG）が可能になっています。非構造化データに対するセマンティック検索を実行して関連する情報を取得する RAG は、ナレッジベースや構造化されていないユーザー入力（チャット履歴など）を検索して、基盤モデルが必要とするコンテキストを取り出す際に特に役立ちます。

AlloyDB のエンドツーエンドのベクトルサポートを利用すれば、これをきわめて簡単に行えます。数行のコードを追加するだけで、オペレーショナルデータベースを、自動のベクトルエンべディング生成や、SQL を使用したベクトルクエリを簡単に行える、ベクトルデータベースに変換できます。Google はさらに、AlloyDB の ScaNN により、主要な Google サービスでも活用されている最先端の ScaNN アルゴリズムを AlloyDB に組み込み、ベクトルパフォーマンスを強化しようとしています。

リアルタイムデータを取得するもう一つの一般的な手法としては、SQL をパッケージ化するカスタム LLM 拡張機能やプラグインに簡単な構造化クエリをパッケージ化する方法が挙げられます。この手法では、API に LLM オーケストレーションフレームワークを接続することで、必要な情報を適切に取得できるようになります。この API は LLM に代わって、構造化 SQL クエリやベクトル検索などのあらゆるデータベースクエリを実行できます。予測可能であり、保護が簡単であることが、この手法の利点です。AlloyDB の LangChain 統合によって、データベースを基盤とした API を簡単に構築して統合し、一般的な質問やアクセスパターン向けに使用できるようになります。

ただ、ユーザーとの会話形式のやり取りで高い自由度が求められることもあり、そのような場合は、ユーザーの質問や必要な API を事前に予測することが困難になります。そのような状況に対処するために、SQL を臨機応変に生成できるモデルを採用するデベロッパーが増えています。これは当初はうまく機能するように見えます。基盤モデルによる SQL の生成は効果的ではありますが、さまざまな課題もあります。

第一に、生成される SQL が構文的に正しいだけでなく、意味的にも正しいものになるようにする必要がありますが、これを高い信頼度で保証することが非常に困難です。たとえば、ニューヨーク行きのフライトを検索する場合には、JFK 空港行きのフライトに絞り込む実行可能な SQL クエリを生成することは、構文的には正しいと言えます。しかしクエリを意味的に正しいものにするには、同じくニューヨークにあるラガーディア空港行きのフライトも含まれていなければなりません。

第二に、生成された SQL をどのようなものでも実行できる機能をアプリケーションに実装すると、プロンプトインジェクション攻撃やサービス拒否攻撃に対して脆弱になるという、セキュリティ上の課題が生じます。

要するに、カスタム API は正確で安全ですが、エンドユーザーの質問すべてに対応できるほど柔軟ではありません。そして新しい natural-language-to-SQL（NL2SQL）の手法ははるかに優れた柔軟性を備えていますが、セキュリティと精度の点で問題があるということです。

AlloyDB の自然言語サポートの導入

AlloyDB AI は、精度、セキュリティ、柔軟性を兼ね備えています。そのため、生成 AI エクスペリエンスにリアルタイムの運用データを簡単に組み込めるほか、それをエンタープライズ環境でも実現できます。

自然言語がサポートされることで、デベロッパーは最高度の柔軟性をもってデータを扱えるようになります。きわめて使いやすいフォームが用意されており、それに曖昧な質問や不明確な質問なども含め、自然言語で書かれたあらゆる質問を入力できます。回答は的確であり、必要に応じて、質問を明確にするためのフォローアップの質問も返されます。この新しいインターフェースを活用して、質問に回答するための単一の LLM 拡張機能を作成できます。複数のデータセットをまたいだ柔軟なクエリによって正確なデータを取得できるほか、適切な分析情報も得られます。データベースの結合、フィルタ、集計を実行して、分析を改善することも可能です。

回答の精度

AlloyDB AI には、回答の精度と関連性をあらゆる状況下で改善する機能が数多く組み込まれています。たとえば次のようなものです。

インテントの明確化: ユーザーが不正確な言葉で質問をすることはよくあります。AlloyDB AI には、ユーザーのインテントをインタラクティブに明らかにするメカニズムが組み込まれています。解釈が難しい質問が与えられると、AlloyDB AI は推測を行うのではなく、フォローアップの質問を返します。質問をユーザーに戻してインテントを明確にしてから結論を導き出すため、最終的な回答の精度が向上します。
スキーマを超えたコンテキスト: AlloyDB AI はビジネスやデータセットに関するセマンティック情報を活用して、自然言語による入力内容をデータベースで実行可能なクエリに翻訳します。この情報には、既存のインデータベースのメタデータやベースラインとしてのコンテキストなどが該当しますが、ナレッジベース、サンプルクエリ、その他のビジネスコンテキスト情報のソースを追加して、結果を改善することも可能です。

次の例について考えてみましょう。カスタマーサービス chatbot を使用してフライトを予約するとします。その場合、「Cymbal Air のサンフランシスコ発ニューヨーク行きの次のフライトはいつ出発する？」のように質問するかもしれません。これは単純な質問のように見えますが、最高水準の NL2SQL テクノロジーでも、これを正しく解釈することはできません。その理由は 2 つあります。

第一に、質問が曖昧です。運行ダイヤ上の出発時刻を質問しているのか、実際に推定される出発時刻を質問しているのか不明瞭です。フライトに遅延が発生した場合には、不正確な情報が返される可能性があります。このような状況で、AlloyDB AI は単に結果を返すのではなく、「探しているのは運行ダイヤ上の出発時刻ですか？それとも実際に推定される出発時刻ですか？」といったフォローアップの質問を返します。

第二に、データベーススキーマそのものに、質問に正確に回答できるだけの情報がすべて含まれているわけではありません。データベース管理者が、スキーマにエンコードされていないセマンティック情報を持っている場合もあります。たとえば、運行ダイヤ上の時刻が「flights」テーブルにあるが推定される時刻は「flight status」テーブルにあるという情報や、航空会社 Cymbal Air が「flights」テーブル内の航空会社コード「CY」に対応しているという情報などが考えられます。AlloyDB AI のコンテキストサービスを使用することで、デベロッパーはデータセットに関するこのセマンティック情報を簡単に組み込めるようになります。

生成 AI のための新しいセキュリティモデル

ほとんどのアプリケーションには、ユーザーデータを保護するためのきめ細かいアクセス制御機能が求められます。アクセス制御は従来はアプリケーションレベルで適用されていましたが、これは、データベースにヒットするすべての SQL クエリをアプリケーションデベロッパーが作成していた場合のみ可能なものです。

しかし（AlloyDB を含む）デベロッパーやベンダーが臨機応変に SQL を生成し、LLM に代わってこれを実行する場合には、新しいセキュリティモデルが必要になります。LLM だけを信頼してデータアクセスを適用することはできません。

AlloyDB の新しいパラメータ化されたセキュアビューを使用すれば、データベース自体におけるアクセスを簡単にロックダウンできます。従来型の行レベルのセキュリティとは異なり、パラメータ化されたセキュアビューでは、エンドユーザーごとに一意のデータベースユーザーを設定する必要がありません。代わりに、ユーザー ID などのパラメータの値に基づいて、データベースビューの特定の行に対するアクセスが制限されます。それによってアプリケーション開発は簡単になります。また、エンドユーザー識別とアプリケーション接続の既存のメカニズムとの互換性があり、より堅牢なセキュリティが実現します。アプリケーションデベロッパーは引き続き接続プーリングを活用して、パフォーマンスを強化できます。

自然言語サポートの仕組み

AlloyDB AI にはきわめて使いやすいフォームが用意されており、そのインターフェースに曖昧な質問や不明確な質問なども含め、自然言語で書かれたあらゆる質問を入力できます。回答は正確であり、また上述のような質問を明確にするためのフォローアップの質問も返されます。デベロッパーはこの新しいインターフェースを活用して、想定外の質問に回答するための単一のツールを作成できます。複数のデータセットをまたいだ柔軟なクエリによって正確なデータを取得できるほか、適切な分析情報も得られます。データベースの結合、フィルタ、集計を実行して、分析を改善することも可能です。

AlloyDB AI ではより高度な開発を可能にするために、コアプリミティブをデベロッパーが直接利用できるようにして、さらに幅広く自然言語を使用したやり取りで構造化データを扱えるようにしています。これらの構成要素により、イノベーターはインテント明確化やコンテキスト使用に関する機能強化と柔軟性が得られます。分散された断片を必要に応じてつなぎ合わせて、アプリケーションの特定のニーズに応えられるようになります。

使ってみる

AlloyDB の自然言語サポートは、Google Cloud の AlloyDB、および AlloyDB Omni で近日中に利用可能になります。それまでは、基本的な NL2SQL のサポートやパラメータ化されたセキュアビューなどの一部のプリミティブが、AlloyDB Omni のテクノロジープレビューとして本日から利用できます。