Azure AI Search 内の統合データのチャンキングと埋め込み
垂直統合は、Azure AI 検索のインデックス作成とクエリ パイプラインの拡張機能です。 これは、次の機能を追加します。
- インデックス作成中のデータ チャンク
- インデックス作成中のテキストからベクトルへの変換
- クエリ中のテキストからベクトルへの変換
データ チャンクは厳格な要件ではありませんが、生のドキュメントが小さい場合を除き、モデルを埋め込むというトークン入力要件を満たすためにチャンクが必要です。
主な利点は、垂直統合により、構成および管理する外部コンポーネントが少なくなるため、開発が高速化され、データ インジェストとクエリ時間中のメンテナンス タスクが最小限に抑えられることです。
ベクトル変換は、テキスト-to-ベクトルの一方向です。 クエリと結果にはベクトル-to-テキスト変換がありません (たとえば、ベクトル結果を人間が読み取り可能な文字列に変換することはできません)。
統合データ チャンキングとベクトル化が一般公開されました。
インデックス作成中の垂直統合の使用
データ チャンクとテキストからベクトルへの変換では、次のコンポーネントに依存します。
インデクサー。サポートされているデータ ソースから生データを取得し、パイプライン エンジンとして機能します。
ベクトル インデックス。チャンク化され、ベクトル化されたコンテンツを受け取ります。
スキルセット。次のために構成されます。
テキスト分割スキル。データのチャンクに使用されます。
ベクトル配列の生成に使用される埋め込みスキル:
AzureOpenAIEmbedding スキル: Azure OpenAI 上の text-embedding-ada-002、text-embedding-3-small、text-embedding-3-large に付属しています。
Custom スキル: Azure または別のサイト上の、別の埋め込みモデルを指します。
Azure AI Vision スキル (プレビュー): Azure AI Vision のマルチモーダル API を指します。
Azure AI Studio 内のモデル カタログを指す AML スキル: モデル カタログ内の選択したモデルを指します。
クエリでの垂直統合の使用
クエリ中のテキストからベクトルへの変換では、次のコンポーネントに依存します。
1 つ以上のベクトル フィールドを指定するクエリ。
クエリ実行時にベクトルに変換されるテキスト文字列。
ベクトル化。インデックス スキーマで定義され、ベクトル フィールドに割り当てられて、テキスト クエリをベクトルに変換するためにクエリ時に自動的に使用されます。 設定するベクトライザーは、コンテンツのエンコードに使用される埋め込みモデルと一致する必要があります。
コンポーネント図
次の図は、 統合ベクトル化の構成要素を示しています。
ワークフローはインデクサー パイプラインです。 インデクサーは、サポートされているデータ ソースからデータを取得し、テキストからベクトルへの変換やその他の処理のために Azure OpenAI または Azure AI サービスあるいはカスタム コードを呼び出すことによって、データ エンリッチメント (または Applied AI) を開始します。
この図は垂直統合に重点を置いていますが、ご使用のソリューションはこのリストに限定されません。 AI エンリッチメントのためのスキルを増やし、ナレッジ ストアを作成し、セマンティック ランク付けを追加し、 関連性チューニングや他のクエリ機能を追加することができます。
可用性と料金
統合ベクトル化は、すべてのリージョンとレベルで使用できます。 ただし、Azure OpenAI と Azure AI のスキルとベクトライザーを使用している場合は、Azure AI マルチサービス アカウントが Azure AI 検索と同じリージョンで使用できることを確認してください。
カスタム スキルと Azure ホスティング メカニズム (Azure 関数アプリ、Azure Web アプリ、Azure Kubernetes など) を使用している場合は、リージョン別の Azure 製品ページで機能の可用性について確認してください。
データ チャンキング (テキスト分割スキル) は無料で、すべての地域のすべての Azure AI サービスでご利用になれます。
Note
2019 年 1 月 1 日より前に作成された一部の古い検索サービスは、ベクトル ワークロードをサポートしないインフラストラクチャにデプロイされています。 ベクトル フィールドをスキーマに追加しようとしてエラーが表示された場合、それはサービスが古いためです。 このような場合は、ベクトル機能を試すために新しい検索サービスを作成する必要があります。
統合ベクトル化をサポートできるのはどんなシナリオですか?
大きなドキュメントをチャンクに再分割します。ベクトル シナリオと非ベクトル シナリオに便利です。 ベクトルの場合、埋め込みモデルの入力制約に合わせるのにチャンクが役立ちます。 非ベクトル シナリオの場合、GPT がインデックス作成したチャンクから回答を作成するチャット スタイルの検索アプリが考えられます。 ベクトル化されているチャンクも、ベクトル化されていないチャンクもチャットスタイルの検索に使用できます。
フィールドのすべてがベクトル フィールドであり、ドキュメント ID (検索インデックスに必要) が唯一の文字列フィールドであるベクトル ストアを構築します。 ベクトル ストアにクエリを実行してドキュメント ID を取得し、ドキュメントのベクトル フィールドを別のモデルに送信します。
ベクトルおよびテキスト フィールドを組み合わせて、セマンティック ランク付けを使用した (または使用しない) ハイブリッド検索にします。 統合ベクトル化によってベクトル検索でサポートされるシナリオのすべてが簡略化されます。
統合ベクトル化を使用するのはどのようなときか
組み込み統合ベクトル化サポートの Azure AI Studio を使用することをお勧めします。 この方法でお客様のニーズが満たされない場合は、Azure AI Search のプログラマティック インターフェイスを使用して統合ベクトル化を呼び出すインデクサーとスキルセットを作成することができます。
統合ベクトル化の使用方法
クエリ専用ベクトル化の場合:
- インデックスにベクトル化を追加します。 インデックスにベクトルを生成するために使用したのと同じ埋め込みモデルになるはずです。
- ベクトル プロファイルにベクトル化を割り当て、それからベクトル プロファイルをベクトル フィールドに割り当てます。
- ベクトル化するテキスト文字列を指定するベクトル クエリを作成します。
より一般的なシナリオ - インデックス作成時のデータのチャンキングとベクトル化:
- インデクサーベースのインデックス作成でサポートされているデータ ソースへのデータ ソース接続を作成します。
- チャンクキング用のテキスト分割スキルと、チャンクをベクトル化する AzureOpenAIEmbeddingModel または別の埋め込みスキルを呼び出すスキルセットを作成します。
- クエリ時のベクトル化を指定し、それをベクトル フィールドに割り当てるインデックスを作成します。
- データの取得からスキルセット実行まで、インデックス作成を通してすべてを進めるためのインデクサーを作成します。 スケジュールに従ってインデクサーを実行し、変更されたドキュメントまたはスロットリングのために見逃されたドキュメントを取得することをお勧めします。
オプションとして、あるインデックス上にチャンクされたコンテンツがあり、別のインデックス上にチャンクされていないコンテンツがある高度なシナリオのためにセカンダリ インデックスを作成します。 チャンクしたインデックス (セカンダリ インデックス) は RAG アプリで役立ちます。
ヒント
Azure portal で新しい [データのインポートとベクトル化] ウィザードを試して、コードを記述する前に統合ベクトル化を探索します。
ベクトライザーとモデルへの接続をセキュリティで保護する
アーキテクチャでインターネットをバイパスするプライベート接続が必要な場合は、クエリ時にベクトライザーとインデックス作成中にスキルで使用される埋め込みモデルへの共有プライベート リンク接続を作成できます。
共有プライベート リンクは、Azure から Azure への接続でのみ機能します。 OpenAI または別の外部モデルに接続する場合は、接続はパブリック インターネット経由である必要があります。
ベクトル化シナリオでは、以下を使用します。
Azure OpenAI リソースでホストされている埋め込みモデルの
openai_account。カスタム スキルまたはカスタム ベクトライザーとしてアクセスされる埋め込みモデルの
sites。sitesグループ ID は、App Services と Azure Functions 用です。これは、Azure OpenAI 埋め込みモデルの 1 つではない埋め込みモデルをホストするために使用できます。
制限事項
Azure OpenAI の埋め込みモデルのクォータと制限について理解します。 Azure AI Search には再試行ポリシーがありますが、クォータを使い果たすと、再試行が失敗します。
Azure OpenAI の 1 分あたりトークンの制限は、モデルごと、サブスクリプションごとに設けられています。 埋め込みモデルをクエリとインデックス作成の両ワークロードで使用している場合は、このことを覚えておいてください。 可能であれば、ベスト プラクティスに従ってください。 ワークロードごとに埋め込みモデルを用意して、それらを別々のサブスクリプションでデプロイするようにしてください。
Azure AI Search では、サービスの制限がレベルおよびワークロード別にあることを忘れないでください。
統合ベクトル化のメリット
統合ベクトル化の重要メリットのいくつかを紹介します。
データ チャンキングとベクトル化の分離したパイプラインがありません。 コードの書き込みと維持がより簡単です。
エンド ツー エンドのインデックス作成を自動化します。 ソース (Azure Storage、Azure SQL、Cosmos DB など) でデータが変更されると、インデクサーはこれらの更新を、パイプライン全体 (取得からドキュメントの解読まで) で、オプションの AI エンリッチメント、データ チャンキング、ベクトル化、インデックス作成を通じて進めることができます。
バッチ処理と再試行のロジックが組み込まれています (構成不可)。 Azure AI 検索には、埋め込みモデルのトークン クォータが Azure OpenAI エンドポイントの上限に達したために発生するスロットリング エラー用に、内部の再試行ポリシーがあります。 ただし再試行ポリシーにかかわらず、Azure OpenAI エンドポイントによってスロットルされた呼び出しをインデクサーが処理できるように、インデクサーにスケジュール (たとえば 5 分ごと) を設定することをお勧めします。
チャンクしたコンテンツをセカンダリ インデックスに射影します。 セカンダリ インデックスは他の検索インデックス (フィールドや他のコンストラクトを持つスキーマ) のように作成されますが、インデクサーによりプライマリ インデックスと並行して作成されます。 各ソース ドキュメントのコンテンツが、同じインデックス作成実行中に、プライマリおよびセカンダリ インデックスのフィールドへ流れていきます。
セカンダリ インデックスは、質問と回答、またはチャット スタイルのアプリを対象としています。 セカンダリ インデックスには、より具体的な一致に関する詳細な情報が含まれていますが、親インデックスにはより多くの情報が含まれており、多くの場合、より完全な回答を生成できます。 セカンダリ インデックスで一致が見つかった場合、クエリでプライマリ インデックスから親ドキュメントが返されます。 たとえば、サイズの大きな PDF をソース ドキュメントとして想定すると、プライマリ インデックスには基本情報 (タイトル、日付、作成者、説明) が含まれているのに対し、セカンダリ インデックスには検索可能なコンテンツのチャンクが含まれています。