Azure AI Search 内の統合データのチャンキングと埋め込み

  • [アーティクル]

重要

この機能はパブリック プレビュー段階にあり、追加使用条件の下で提供されます。 この機能は、2023-10-01-Preview REST API でサポートされます。

統合ベクター化によって、データ チャンキングとテキスト-to-ベクター埋め込みがインデクサーベース インデックス作成のスキルに追加されます。 テキスト-to-ベクター変換もクエリに追加されます。

この機能は、プレビューのみ段階です。 一般提供バージョンのベクトル検索と以前のプレビュー バージョンでは、データのチャンキングとベクター化が外部のチャンキングとベクターのコンポーネントに依存しており、アプリケーション コードが各手順を操作し、調整する必要があります。 このプレビュー版では、チャンキングとベクター化がスキルおよびインデクサーを通じてインデックス作成に組み込まれています。 テキスト分割スキルを使用してデータをチャンクするスキルセットをセットアップして、それから AzureOpenAIEmbedding スキルまたはカスタム スキルを使用して埋め込みモデルを呼び出すことができます。 インデックス作成時に使用されるあらゆるベクトル化を、テキストをベクターに変換するクエリで呼び出すこともできます。

インデックス作成の場合、統合ベクター化では以下が必要です。

クエリの場合:

  • インデックス スキーマで定義され、ベクター フィールドに割り当てられて、自動的にクエリ時に使用されてテキスト クエリをベクターに変換するベクター化。

ベクター変換は、テキスト-to-ベクターの一方向です。 クエリと結果にはベクター-to-テキスト変換がありません (たとえば、ベクター結果を人間が読み取り可能な文字列に変換することはできません)。

コンポーネント図

次の図は、 統合ベクター化の構成要素を示しています。

統合ベクター化ワークフロー内のコンポーネントのダイアグラム。

こちらが統合ベクター化のための構成要素のチェックリストです。

  • インデクサーベースのインデックス作成でサポートされているデータ ソース。
  • ベクター フィールドを指定するインデックスと、ベクター フィールドに割り当てられたベクター化定義。
  • データ チャンキングのためのテキスト分割スキルを提供するスキルセットと、ベクター化のスキル (AzureOpenAiEmbedding スキルと、外部埋め込みモデルをポイントするカスタム スキルのいずれか)。
  • オプションとして、チャンクしたデータをセカンダリ インデックスにプッシュするインデックス プロジェクション (スキルセットにも定義される)
  • 埋め込みモデル (Azure OpenAI でデプロイされているか、HTTP エンドポイントを通じて提供される)。
  • プロセスをエンドツーエンドで進めるためのインデクサー。 インデクサーでは、変更検出のスケジュール、フィールド マッピング、優先度も指定されます。

このチェックリストは統合ベクター化に重点を置いていますが、お持ちのソリューションはこのリストに限定されません。 AI エンリッチメントのためのスキルを増やし、ナレッジ ストアを作成し、セマンティック ランク付けを追加し、 関連性チューニングや他のクエリ機能を追加することができます。

可用性と料金

統合ベクター化の可用性は、埋め込みモデルに基づきます。 Azure OpenAI を使用している場合は、「リージョン別の提供状況」を確認してください。

カスタム スキルと Azure ホスティング メカニズム (Azure 関数アプリ、Azure Web アプリ、Azure Kubernetes など) を使用している場合は、リージョン別の製品ページで機能の可用性について確認してください。

データ チャンキング (テキスト分割スキル) は無料で、すべての地域のすべての Azure AI サービスでご利用になれます。

Note

2019 年 1 月 1 日より前に作成された一部の古い検索サービスは、ベクトル ワークロードをサポートしないインフラストラクチャにデプロイされています。 ベクトル フィールドをスキーマに追加しようとしてエラーが表示された場合、それはサービスが古いためです。 このような場合は、ベクトル機能を試すために新しい検索サービスを作成する必要があります。

統合ベクター化をサポートできるのはどんなシナリオですか?

  • 大きなドキュメントをチャンクに再分割すると、ベクターおよび非ベクターシナリオに便利です。 ベクターの場合、埋め込みモデルの入力制約に合わせるのにチャンクが役立ちます。 非ベクター シナリオの場合、チャット スタイルの検索アプリで GPT がインデックス作成したチャンクからの応答をアセンブルしています。 ベクトル化 (または非ベクトル化)されたチャンクをチャットスタイルの検索に使用できます。

  • フィールドのすべてがベクター フィールドであり、ドキュメント ID (検索インデックスに必要) が唯一の文字列フィールドであるベクター ストアを構築します。 ベクター ストアにクエリを実行してドキュメント ID を取得し、ドキュメントのベクター フィールドを別のモデルに送信します。

  • ベクターおよびテキスト フィールドを組み合わせて、セマンティック ランク付けを使用した (または使用しない) ハイブリッド検索にします。 統合ベクター化によってベクター検索でサポートされるシナリオのすべてが簡略化されます。

統合ベクター化を使用するのはどのようなときか

組み込み統合ベクター化サポートの Azure AI Studio を使用することをお勧めします。 この方法でお客様のニーズが満たされない場合は、Azure AI Search のプログラマティック インターフェイスを使用して統合ベクター化を呼び出すインデクサーとスキルセットを作成することができます。

統合ベクター化の使用方法

クエリ専用ベクター化の場合:

  1. インデックスにベクター化を追加します。 インデックスにベクターを生成するために使用したのと同じ埋め込みモデルになるはずです。
  2. ベクター プロファイルにベクター化を割り当て、それからベクター プロファイルをベクター フィールドに割り当てます。
  3. ベクター化するテキスト文字列を指定するベクター クエリを作成します。

より一般的なシナリオ - インデックス作成時のデータのチャンキングとベクター化:

  1. インデクサーベースのインデックス作成でサポートされているデータ ソースへのデータ ソース接続を作成します。
  2. チャンキング用のテキスト分割スキルと、AzureOpenAIEmbeddingModel またはチャンクをベクター化するカスタムスキルを呼び出すスキルセットを作成します。
  3. クエリ時のベクター化を指定し、それをベクター フィールドに割り当てるインデックスを作成します。
  4. データの取得からスキルセット実行まで、インデックス作成を通してすべてを進めるためのインデクサーを作成します。

オプションとして、チャンクしたコンテンツが 一方のインデックス上にあり、チャンクされていないコンテンツが別のインデックスにある高度なシナリオのためのセカンダリ インデックスを作成します。 チャンクしたインデックス (セカンダリ インデックス) は RAG アプリで役立ちます。

ヒント

Azure portal で新しい [データのインポートとベクトル化] ウィザードを試して、コードを記述する前に統合ベクター化を探索します。

あるいは、同じワークフローを実行するための Jupyter ノートブックをセルごとに構成して、各手順がどう機能するかを調べます。

制限事項

Azure OpenAI の埋め込みモデルのクォータと制限について理解します。 Azure AI Search には再試行ポリシーがありますが、クォータを使い果たすと、再試行が失敗します。

Azure OpenAI の 1 分あたりトークンの制限は、モデルごと、サブスクリプションごとに設けられています。 埋め込みモデルをクエリとインデックス作成の両ワークロードで使用している場合は、このことを覚えておいてください。 可能であれば、ベスト プラクティスに従ってください。 ワークロードごとに埋め込みモデルを用意して、それらを別々のサブスクリプションでデプロイするようにしてください。

Azure AI Search では、サービスの制限がレベルおよびワークロード別にあることを忘れないでください。

最後に、次の機能は現在サポートされていません。

統合ベクター化のメリット

統合ベクター化の重要メリットのいくつかを紹介します。

  • データ チャンキングとベクター化の分離したパイプラインがありません。 コードの書き込みと維持がより簡単です。

  • エンド ツー エンドのインデックス作成を自動化します。 ソース (Azure Storage、Azure SQL、Cosmos DB など) でデータが変更されると、インデクサーはこれらの更新を、パイプライン全体 (取得からドキュメントの解読まで) で、オプションの AI エンリッチメント、データ チャンキング、ベクター化、インデックス作成を通じて進めることができます。

  • チャンクしたコンテンツをセカンダリ インデックスに射影します。 セカンダリ インデックスは他の検索インデックス (フィールドや他のコンストラクトを持つスキーマ) のように作成されますが、インデクサーによりプライマリ インデックスと並行して作成されます。 各ソース ドキュメントのコンテンツが、同じインデックス作成実行中に、プライマリおよびセカンダリ インデックスのフィールドへ流れていきます。

    セカンダリ インデックスの目的は、データ チャンキングおよび取得拡張生成 (RAG) アプリです。 サイズの大きな PDF をソース ドキュメントとして想定すると、プライマリ インデックスには基本情報 (タイトル、日付、作成者、説明) があり、セカンダリ インデックスにはコンテンツのチャンクがあります。 データ チャンク レベルのベクター化によって、関連する情報を見つけて (各チャンクが検索可能である) 関連する応答を返すのが、特にチャットスタイルの検索アプリでは簡単になります。

チャンク後のインデックス

チャンキングとは、コンテンツをより小さな管理可能部分 (チャンク) に分割することで、それらを別々に処理できるようにするプロセスです。 チャンキングが必要になるのは最大入力サイズの埋め込みモデルや大型言語モデルでソース ドキュメントが大きすぎるけれども、それによって RAG パターンやチャットスタイル検索でインデックス構造がよくなると考えられる場合です。

次の図は、チャンク後インデックス作成の構成要素を示しています。

チャンクとベクター化ワークフローのダイアグラム。

次のステップ