Azure AI 検索のインポート ウィザード

Azure AI 検索には、インデックス作成とオブジェクト定義を自動化する 2 つのインポート ウィザードがあり、すぐにクエリを開始できます。 Azure AI 検索を初めて使用する場合、これらのウィザードは、お客様にとって自由に使える最も強力な機能の 1 つとなります。 Azure AI Search のほとんどの機能を実行できる、インデックスや強化パイプラインを最小限の労力で作成できます。

データ インポート ウィザードでは、非ベクトル ワークフローがサポートされます。 生のドキュメントから英数字テキストを抽出できます。 また、画像ファイルや非構造化データから構造を推論してテキスト検索可能なコンテンツを生成する、応用 AI と組み込みのスキルを構成することもできます。

データのインポートとベクトル化ウィザードはベクトル化をサポートしています。 埋め込みモデルの既存のデプロイを指定する必要がありますが、ウィザードによって接続が作成され、要求が作成され、応答が処理されます。 テキストまたは画像コンテンツからベクトル コンテンツを生成します。

概念実証のテストにウィザードを使用する際により効果的に使用できるように、この記事ではウィザードの内部動作について説明します。

この記事では、ステップ バイ ステップでは説明しません。 組み込みのサンプル データでのウィザードの使用については、次を参照してください。

• クイックスタート: 検索インデックスを作成する
• クイックスタート: テキスト翻訳とエンティティ スキルセットを作成する
• クイック スタート: ベクトル インデックスを作成する
• クイック スタート: 画像検索 (ベクトル)

ウィザードの開始

1. Azure portal でダッシュボードから検索サービス ページを開くか、サービスの一覧でご自分のサービスを見つけます。

2. 上部にあるサービスの概要ページで、[データのインポート] または [データのインポートとベクトル化] を選択します。

   

   ウィザードがブラウザー ウィンドウで完全に展開され、作業するための領域が増えます。

3. [データのインポート] を選択した場合は、[サンプル] オプションを選択して、サポートされているデータ ソースの事前構築済みデータ サンプルを使用できます。

   

4. ウィザードの残りの手順に従って、インデックスとインデクサーを作成します。

[Import data (データのインポート)] は、Azure Cosmos DB、Azure SQL Database、SQL Managed Instance、Azure Blob Storage を含む、他の Azure サービスから起動することもできます。 サービスの概要ページの左側にあるナビゲーション ウィンドウで、[Add Azure AI Search] (Azure AI Search の追加) を見つけます。

ウィザードで作成されるオブジェクト

ウィザードでは、次の表のオブジェクトが出力されます。 オブジェクトが作成されたら、ポータルで JSON 定義を確認したり、コードから呼び出したりすることができます。

メリット

コードを記述する前に、このウィザードをプロトタイプ作成と概念実証テストに使用できます。 ウィザードでは、外部データ ソースに接続し、データをサンプリングして初期インデックスを作成します。次に、データを JSON ドキュメントとして Azure AI Search のインデックスにインポートし、必要に応じてベクトル化します。

スキルセットを評価する場合、ウィザードで出力フィールド マッピングを処理し、使用可能なオブジェクトを作成するヘルパー関数を追加します。 解析モードを指定すると、テキストの分割が追加されます。 ウィザードで画像コンテンツとテキストの説明を再結合できるように、画像分析を選択すると、テキストの結合が追加されます。 ナレッジ ストア オプションを選択した場合に有効なプロジェクションをサポートする Shaper スキルが追加されました。 上記のすべてのタスクには学習曲線が付きます。 エンリッチメントを初めて使用する場合は、これらの手順を処理させる機能により、時間と労力を費やすことなく、スキルの価値を測定できます。

サンプリングはインデックス スキーマを推論するプロセスであり、これには制限がいくつかあります。 データ ソースが作成されると、ウィザードによってドキュメントのサンプルがランダムに選択され、データ ソースの一部である列が決定されます。 非常に大規模なデータ ソースの場合はこの処理に時間がかかる可能性があるため、すべてのファイルが読み取られるわけではありません。 ドキュメントが選択されると、フィールド名や種類などのソース メタデータを使用して、インデックス スキーマにフィールド コレクションが作成されます。 ソース データの複雑さに応じて、正確さを求めて初期スキーマを編集したり、完全を期すために拡張したりすることが必要になる場合があります。 インデックスの定義のページで、変更をインラインで行うことができます。

概して、ウィザードを使用する利点は明らかです。要件が満たされていれば、数分以内にクエリ可能なインデックスを作成できます。 JSON ドキュメントとしてのデータのシリアル化など、インデックス作成の複雑な処理の一部は、ウィザードによって行われます。

制限事項

このウィザードには、制限がないわけではありません。 制約は次のとおりです。

• このウィザードでは、イテレーションと再利用はサポートされていません。 ウィザードをパススルーするたびに、新しいインデックス、スキルセット、およびインデクサー構成が作成されます。 ウィザード内で保持および再利用できるのは、データ ソースのみです。 他のオブジェクトを編集または調整するには、オブジェクトを削除してからやり直すか、REST API または .NET SDK を使用して構造体を変更します。

• ソース コンテンツは、サポートされているデータ ソース内にある必要があります。

• サンプリングは、ソース データのあるサブセットについて行われます。 大規模なデータ ソースの場合、ウィザードでフィールドが見逃される可能性があります。 サンプリングが不十分な場合は、スキーマを拡張するか、推論されたデータ型を修正することが必要になる場合があります。

• ポータルで公開されている AI エンリッチメントは、組み込みのスキルのサブセットに限定されています。

• ウィザードで作成できるナレッジ ストアは、いくつかの既定のプロジェクションに限定され、既定の名前付け規則が使用されます。 名前またはプロジェクションをカスタマイズする場合は、REST API または SDK を使用してナレッジ ストアを作成する必要があります。

セキュリティで保護された接続

インポート ウィザードは、ポータル コントローラーとパブリック エンドポイントを使用して送信接続を行います。 プライベート接続または共有プライベート リンク経由で Azure リソースにアクセスする場合、ウィザードを使用することはできません。

制限付きパブリック接続経由でウィザードを使用できますが、すべての機能を使用できるわけではありません。

• 検索サービスでは、組み込みのサンプル データをインポートするにはパブリック エンドポイントが必要であり、ファイアウォール規則は必要ありません。

  サンプル データは、特定の Azure リソースについて Microsoft によってホストされます。 ポータル コントローラーは、パブリック エンドポイント経由でこれらのリソースに接続します。 検索サービスをファイアウォールの内側に配置した場合、組み込みのサンプル データを取得しようとすると、"An error has occured." の後に Import configuration failed, error creating Data Source のエラーが表示されます。

• ファイアウォールによって保護されているサポート対象 Azure データ ソースでは、適切なファイアウォール規則が設定されている場合にデータを取得できます。

  Azure リソースは、接続で使用されるデバイスの IP アドレスからのネットワーク要求を許可する必要があります。 また、リソースのネットワーク構成で、信頼できるサービスとして Azure AI 検索をリストに含める必要があります。 たとえば、Azure Storage では、信頼できるサービスとして Microsoft.Search/searchServices をリストに追加できます。

• 指定した Azure AI マルチサービス アカウントへの接続時、または Azure AI Studio または Azure OpenAI にデプロイされた埋め込みモデルへの接続時に、パブリック インターネット アクセスを有効にする必要があります。 これらの Azure リソースは、データ インポート ウィザードで組み込みのスキルを使用するとき、またはデータのインポートとベクトル化ウィザードで垂直統合を使用するときに呼び出されます。

  • データのインポートとベクトル化ウィザードのエラーは "Access denied due to Virtual Network/Firewall rules." です

  • データ インポート ウィザードでは、エラーは表示されませんが、スキルセットは作成されません。

ファイアウォール設定によってウィザードのワークフローが成功できない場合は、代わりにスクリプトまたはプログラムによるアプローチを検討してください。

ワークフロー

このウィザードは、次の主な 4 つの手順で構成されています。

1. サポートされている Azure データ ソースに接続します。

2. ソース データのサンプリングによって推論されるインデックス スキーマを作成します。

3. 必要に応じて、内容と構造を抽出または生成するために応用 AI を追加します。 ナレッジ ストアを作成するための入力は、この手順で収集されます。

4. ウィザードを実行してオブジェクトを作成し、必要に応じてデータをベクトル化し、データをインデックスに読み込み、スケジュールやその他の構成オプションを設定します。

ワークフローはパイプラインであるため、一方向となります。 作成したどのオブジェクトもウィザードを使用して編集することはできませんが、更新が許可されている場合は、インデックスやインデクサー デザイナーなどの他のポータル ツール、または JSON エディターを使用することができます。

ウィザードでのデータ ソースの構成

ウィザードは、Azure AI 検索インデクサーによって提供される内部ロジックを使用して外部のサポートされるデータ ソースに接続します。Azure AI 検索インデクサーでは、ソースのサンプリング、メタデータの読み取り、内容と構造を読み取るためのドキュメントの解読の機能を備え、その後の Azure AI 検索へのインポートのために JSON として内容をシリアル化することもできます。

別のサブスクリプションまたはリージョンでサポートされているデータ ソースに対する接続を貼り付けることができますが、[既存の接続を選択します] ピッカーはアクティブなサブスクリプションが対象になります。

すべてのプレビュー データ ソースがウィザードで使用できることが保証されているわけではありません。 各データ ソースには、他の変更を下流に導入する可能性があるため、スキルセット定義やインデックス スキーマ推論など、ウィザードのすべてのエクスペリエンスを完全にサポートしている場合にのみ、データ ソースの一覧にプレビューのデータ ソースが追加されます。

インポート元として指定できるのは、単一のテーブル、データベース ビュー、または同等のデータ構造体のみですが、構造体には、階層または入れ子になったのサブ構造体を含めることができます。 詳細については、複合型のモデル化の方法に関するページを参照してください。

ウィザードでのスキルセットの構成

データ ソースの種類によって特定の組み込みのスキルが使用可能かどうかが通知されるため、データ ソース定義の後にスキルセットの構成が行われます。 特に、Blob Storage からファイルのインデックスを作成する場合、これらのファイルの解析モードの選択によって、感情分析を使用できるかどうかが決まります。

ウィザードによって、選択したスキルが追加されます。 また、求める結果を得るために必要な他のスキルも追加されます。 たとえば、ナレッジ ストアを指定した場合、ウィザードによって、プロジェクション (または物理データ構造) をサポートするための Shaper スキルが追加されます。

スキルセットはオプションなので、AI エンリッチメントが不要な場合は、ページの下部にあるボタンを使用してスキップすることができます。

ウィザードでのインデックス スキーマの構成

ウィザードによってデータ ソースがサンプリングされ、フィールドとフィールドの種類が検出されます。 データ ソースによっては、メタデータのインデックスを作成するためのフィールドが用意されている場合もあります。

サンプリングは不正確な演習であるため、次の考慮事項についてインデックスを確認してください。

1. フィールドの一覧は正確ですか。 データ ソースにサンプリングで含められなかったフィールドがある場合、サンプリングされなかった新しいフィールドを手動で追加し、検索エクスペリエンスに値を追加しないものと、フィルター式にもスコアリング プロファイルにも使用されないものをすべて削除できます。

2. データ型は受信データに適していますか。 Azure AI Search では、Entity Data Model (EDM) データ型がサポートされています。 Azure SQL データについては、同等の値を示しているマッピング表があります。 詳細な背景については、フィールドのマッピングと変換に関する記事をご覧ください。

3. "キー" として使用できるフィールドが 1 つありますか。 このフィールドは、Edm.string でなければならず、ドキュメントを一意に識別する必要があります。 リレーショナル データの場合は、主キーにマップされていることがあります。 BLOB の場合、metadata-storage-path であることがあります。 フィールドの値に空白またはダッシュが含まれている場合は、インデクサーの作成手順の [詳細オプション] で [Base-64 エンコード キー] オプションを設定し、これらの文字の検証チェックを抑制する必要があります。

4. 属性を設定して、インデックスでのこのフィールドの使用方法を指定します。

   インデックス内のフィールドの物理的な表現が属性によって決定されるため、この手順に時間をかけてください。 後で属性を変更するときは、プログラムで行う場合も、ほとんどの場合にインデックスを削除して再構築する必要があります。 Searchable や Retrievable などのコア属性では、ストレージへの影響は無視できる程度です。 フィルターを有効にして suggester を使用すると、ストレージの要件が増えます。

   • Searchable では、全文検索が有効になります。 自由形式のクエリまたはクエリ式で使用されるすべてのフィールドに、この属性が必要です。 Searchable としてマークしたフィールドごとに、逆インデックスが作成されます。

   • Retrievable の場合、検索結果にフィールドが返されます。 検索結果にコンテンツを提供するすべてのフィールドに、この属性が必要です。 このフィールドを設定しても、インデックス サイズに大きな影響はありません。

   • Filterable は、フィルター式でフィールドを参照できるようにします。 $filter 式で使用されるすべてのフィールドに、この属性が必要です。 このフィルター式は完全一致用です。 テキスト文字列はそのまま残るため、逐語的なコンテンツに対応するには、追加のストレージが必要です。

   • Facetable は、ファセット ナビゲーションにフィールドを使用できるようにします。 Filterable としてもマークされているフィールドのみを、Facetable としてマークできます。

   • Sortable は、並べ替えでフィールドを使用できるようにします。 $Orderby 式で使用されるすべてのフィールドに、この属性が必要です。

5. 字句解析が必要ですか。 Searchable である Edm.string フィールドの場合、言語拡張インデックス作成とクエリの実行が必要な場合は、アナライザーを設定できます。

   既定値は標準 Lucene ですが、不規則名詞や動詞形式の解決など、高度な字句処理のために Microsoft のアナライザーを使用する必要がある場合は、Microsoft の英語を選択できます。 ポータルでは、言語アナライザーのみを指定できます。 カスタム アナライザーや、キーワード、パターンなどの非言語アナライザーを使用する場合は、プログラムで作成する必要があります。 アナライザーの詳細については、言語アナライザーの追加に関する記事をご覧ください。

6. オートコンプリートまたは候補の結果の形式の先行入力機能が必要ですか。 [Suggester] チェックボックスを選択し、選択したフィールドで先行入力クエリ候補とオートコンプリートを有効にします。 suggester は、インデックス内のトークン化された用語の数を増加させるため、より多くのストレージを消費します。

ウィザードでのインデクサーの構成

ウィザードの最後のページでは、インデクサーの構成に関するユーザー入力が収集されます。 スケジュールを指定したり、データ ソースの種類によって異なるその他のオプションを設定したりできます。

内部的には、次の定義もウィザードによって設定されます。これらの定義は作成されるまでインデクサーに表示されません。

• データ ソースとインデックスの間のフィールド マッピング
• スキルの出力とインデックスの間の出力フィールド マッピング

次のステップ

ウィザードの利点と制限事項を理解する最善の方法は、これを段階を追って実行することです。 次のクイックスタートで、それぞれの手順について説明します。