Actionsによるデータ検索
感じたこと
ま、そうだよね...という感じ。
SaaS、RDS、ベクトルDBへのデータアクセスという構造化はわかりやすい 概要
GPTのアクションで最も一般的なタスクの1つは、データ検索です。アクションは以下のようなことを行うかもしれません。
キーワード検索に基づいて、データを取得するためのAPIにアクセスする
構造化されたクエリに基づいてレコードを取得するための、リレーショナルデータベースにアクセスする
セマンティック検索に基づいてテキストチャンクを取得するためのベクトルデータベースにアクセスする このガイドでは、様々なタイプの検索統合に特有の考慮事項を探っていきます。
APIを使用した、SaaSへのデータ検索
多くの組織では、重要なデータを保存するために第三者のソフトウェアに依存しています。顧客データにはSalesforce、サポートデータにはZendesk、内部プロセスデータにはConfluence、ビジネス文書にはGoogle Driveなどが使われています。これらのプロバイダは、外部システムが情報を検索して取得できるようにするRESTAPIを提供していることがよくあります。
プロバイダのREST APIと統合するアクションを構築する際は、まず既存のドキュメントを確認することから始めます。いくつかの事項を確認する必要があります。
検索方法
検索
各プロバイダはさまざまな検索セマンティクスをサポートしますが、一般的には、キーワードまたはクエリ文字列を受け取り、一致するドキュメントのリストを返すメソッドが必要です。例として、Google Driveのfile.listメソッドを参照してください。
取得
一致するドキュメントが見つかったら、それらを取得する方法が必要です。例として、Google Driveのfile.getメソッドを参照してください。
認証方式
例えば、Google Driveは、ユーザーを認証し、利用可能なファイルのみが取得できるようにするためにOAuthを使用しています。
OpenAPI仕様
一部のプロバイダは、アクションに直接インポートできるOpenAPI仕様ドキュメントを提供しています。例として、Zendeskを参照してください。
GPTがアクセスしないメソッドへの参照を削除したい場合があります。これにより、GPTが実行できるアクションが制約されます。
OpenAPI仕様ドキュメントを提供していないプロバイダの場合は、OpenAIが開発したActionsGPT（GPT）を使用して独自に作成できます。
目標は、GPTがアクションを使用して、ユーザーのプロンプトに関連する文脈を含むドキュメントを検索し、取得することです。
GPTは、この目標を達成するために、提供された検索および取得メソッドを使用するための指示に従います。
リレーショナルデータベースを使用したデータ検索
組織は、ビジネスに関連するさまざまなレコードを保存するためにリレーショナルデータベースを使用します。これらのレコードには、GPTの応答を改善するのに役立つ有用な文脈が含まれている場合があります。たとえば、保険金請求のステータスを理解するのに役立つGPTを構築しているとします。GPTが請求番号に基づいてリレーショナルデータベース内の請求を検索できる場合、GPTはユーザーにとってはるかに役立つでしょう。
リレーショナルデータベースと統合するアクションを構築する際は、いくつかの点に留意する必要があります。
REST APIの可用性
多くのリレーショナルデータベースは、クエリを処理するためのREST APIをネイティブに公開していません。その場合、GPTとデータベースの間に位置するミドルウェアを構築または購入する必要があるかもしれません。
このミドルウェアは次のことを行う必要があります。
フォーマルなクエリ文字列を受け入れる
クエリ文字列をデータベースに渡す
返されたレコードを要求者に返信する
パブリックインターネットからのアクセス可能性
パブリックインターネットからのアクセスを目的として設計されているAPIとは異なり、リレーショナルデータベースは従来、組織のアプリケーションインフラストラクチャ内で使用するように設計されています。GPTはOpenAIのインフラストラクチャでホストされているため、公開するAPIがファイアウォールの外部からアクセスできることを確認する必要があります。
複雑なクエリ文字列
リレーショナルデータベースは、関連するレコードを取得するためにSQLなどのフォーマルなクエリ構文を使用します。つまり、サポートされているクエリ構文を示す追加の指示をGPTに提供する必要があります。良いニュースは、GPTは通常、ユーザー入力に基づいてフォーマルなクエリを生成するのが非常に得意だということです。
データベースの権限
データベースはユーザーレベルの権限をサポートしていますが、エンドユーザーがデータベースに直接アクセスする権限を持っている可能性は低いでしょう。サービスアカウントを使用してアクセスを提供することを選択した場合は、サービスアカウントに読み取り専用の権限を与えることを検討してください。これにより、既存のデータを誤って上書きまたは削除することを回避できます。
目標は、GPTがユーザーのプロンプトに関連するフォーマルなクエリを作成し、アクションを介してクエリを送信し、返されたレコードを使用して応答を拡張することです。
ベクトルデータベースを使用したデータ検索
GPTに最も関連性の高い検索結果を提供したい場合は、上述のセマンティック検索をサポートするベクトルデータベースとGPTを統合することを検討するかもしれません。市場には、マネージドソリューションとセルフホストソリューションが多数存在します。部分的なリストについては、ここを参照してください。 ベクトルデータベースと統合するアクションを構築する際は、いくつかの点に留意する必要があります。
REST APIの可用性
多くのリレーショナルデータベースは、クエリを処理するためのREST APIをネイティブに公開していません。その場合、GPTとデータベースの間にミドルウェアを構築または購入する必要があるかもしれません（ミドルウェアの詳細は後述）。
パブリックインターネットからのアクセス可能性
パブリックインターネットからのアクセスを目的として設計されているAPIとは異なり、リレーショナルデータベースは従来、組織のアプリケーションインフラストラクチャ内で使用するように設計されています。GPTはOpenAIのインフラストラクチャでホストされているため、公開するAPIがファイアウォールの外部からアクセスできることを確認する必要があります。
クエリの埋め込み
上述したように、ベクトルデータベースは通常、（プレーンテキストではなく）ベクトル埋め込みをクエリ入力として受け入れます。つまり、ベクトルデータベースにクエリを送信する前に、埋め込みAPIを使用してクエリ入力をベクトル埋め込みに変換する必要があります。この変換は、GPTがプレーンテキストのクエリ文字列を送信できるように、REST APIゲートウェイで処理するのが最適です。
データベースの権限
ベクトルデータベースは完全なドキュメントではなくテキストチャンクを保存するため、元のソースドキュメントに存在していたユーザー権限を維持することが難しい場合があります。GPTにアクセスできるユーザーは誰でもデータベース内のすべてのテキストチャンクにアクセスできることを忘れずに、それに応じて計画を立ててください。
ベクトルデータベース用のミドルウェア
上述したように、ベクトルデータベース用のミドルウェアは通常、次の2つのことを行う必要があります。
REST APIを介してベクトルデータベースへのアクセスを公開する
プレーンテキストのクエリ文字列をベクトル埋め込みに変換する
https://scrapbox.io/files/662f52e550edcc0025ac8fd4.png
目標は、GPTがベクトルデータベースに関連するクエリを送信してセマンティック検索をトリガーし、返されたテキストチャンクを使用して応答を拡張することです。