Azure AI Searchのインデックス・インデクサー・スキルセット概要とAOAI連携
Azure AI Search
インデックス
フィールド名は自由につけることができる。インデクサーにてマッピングを行う。
スキルセット
作成したスキルセット
{
"@odata.context": "https://dummysearch.search.windows.net/$metadata#skillsets/$entity",
"@odata.etag": "\"0x8DC585B91B8669F\"",
"name": "skillset-template",
"description": "A description makes the skillset self-documenting (comments aren't allowed in JSON itself)",
"skills": [
{
"@odata.type": "#Microsoft.Skills.Text.KeyPhraseExtractionSkill",
"name": "KeyPhrase",
"description": "",
"context": "/document",
"defaultLanguageCode": "en",
"maxKeyPhraseCount": null,
"modelVersion": "",
"inputs": [
{
"name": "text",
"source": "/document/content"
}
],
"outputs": [
{
"name": "keyPhrases",
"targetName": "keyPhrases"
}
]
}
],
"cognitiveServices": null,
"knowledgeStore": null,
"indexProjections": null,
"encryptionKey": null
}
公式としてのお作法に加えて、より概要レベルで何をしているのかを知りたい場合には、以下の記事が非常に有用。上記で作成したスキルの各キーで入力すべき内容も記載があるので一読すべし。
AI Searchから利用できる組み込みのスキルセット
AI Searchからは、ベクトル化やOCRなどのスキルセットが利用できる。
AI Searchとして保有するスキルを利用するというよりは、OpenAIや他のAIサービスを呼び出して利用するイメージが正しいようである。以下のイメージ。
TIPSとして、AI Searchから接続方式について記載しておく。
-
マネージドID
OpenAIにはマネージドIDでの接続が可能。AI services multi-service account（AIサービス）には利用できない。 - 共有プライベードアクセス
OpenAIには利用可能。
ただし、現時点でAIサービスには利用できない。Azure Portal上からは作成できてしまうのだが、実際には動作はサポートされていないらしい（MSサポート確認済み）
AI SearchからOpenAIへのプライベート接続方法は、以下のサポートブログでも説明されているので確認してもよい。
pull型とpush型
インデックスを作成する際には、データソースから定期的に更新・削除を取得してインデックスを作成するpull型
開発者側（場合によってはトリガーによるAzure Functionsでの実施）がインデックスを作成してプッシュするpush型が存在する。
| 作成方法 | 利用シーン |
|---|---|
| pull型 | データが大量に存在し第三者などコントロールできない範囲で定期的に更新される場合。 データが頻繁に更新される場合 定期的なジョブによるインデックスの更新で問題ない場合(※1) |
| push型 | インデックスに変更がプッシュされるタイミングを制御したいとき データがアプリケーション内で生成され外部ソースへのアクセスが不要な場合 データの更新頻度が低い場合 |
※1：最低5分からインデクサー（pull型でのインデックス作成する機能）の実行間隔を指定できる。
インデクサー
インデクサーは、非構造データからのドキュメント解析をデフォルトで担う。インデクサーだけでは実施できることに限りがある。
キーワード抽出やベクトル化を行う場合には、スキルセットを利用する必要がある。AIエンリッチメントが不要な場合は、スキルセットは必須ではない。例えば、単純にPDFからテキストを抽出するだけであれば、インデクサーの組み込みスキルで可能なため、スキルセットは不要である。
単純に非構造データからのテキスト抽出の場合
作ったインデクサーは以下の通り
{
"@odata.context": "https://dummysearch.search.windows.net/$metadata#indexers/$entity",
"@odata.etag": "\"0x8DC6782C7A0DFD5\"",
"name": "pureindexer",
"description": null,
"dataSourceName": "vector-1712305528228-datasource",
"skillsetName": null,
"targetIndexName": "source",
"disabled": null,
"schedule": null,
"parameters": {
"batchSize": null,
"maxFailedItems": null,
"maxFailedItemsPerBatch": null,
"base64EncodeKeys": null,
"configuration": {}
},
"fieldMappings": [
{
"sourceFieldName": "content",
"targetFieldName": "title",
"mappingFunction": null
},
{
"sourceFieldName": "metadata_storage_name",
"targetFieldName": "hash",
"mappingFunction": null
}
],
"outputFieldMappings": [],
"cache": null,
"encryptionKey": null
}
-
skillsetNameがnullになっているため利用していないことが分かる。 - データソースとしてはBlobにPDFを格納している。Blobからのデータ検索としては、テキストは
contentフィールドに保存される。 - それ以外にも、例えばファイル名は
metadata_storage_nameのフィールドに保存される。インデックスに対してマッピングを行う。（インデックス名も同じ名前にする場合はマッピングは省略してOKのようである）
https://learn.microsoft.com/ja-jp/azure/search/search-howto-indexing-azure-blob-storage - カスタムメタデータの記述があるが、ストレージアカウントには自由にメタデータを付与できるのでそれのこと。
実行結果は以下の通り。コンテンツとドキュメント名がインデックスに出力されていることが分かる。
スキルセットを利用した場合のインデクサー
{
"@odata.context": "https://dummysearch.search.windows.net/$metadata#indexers/$entity",
"@odata.etag": "\"0x8DC585BACD951AC\"",
"name": "indexer1712499885183",
"description": null,
"dataSourceName": "jsontest",
"skillsetName": "skillset-template",
"targetIndexName": "testkey",
"disabled": null,
"schedule": null,
"parameters": {
"batchSize": null,
"maxFailedItems": null,
"maxFailedItemsPerBatch": null,
"base64EncodeKeys": true,
"configuration": {}
},
"fieldMappings": [],
"outputFieldMappings": [
{
"sourceFieldName": "/document/keyPhrases",
"targetFieldName": "keyPhrases"
}
],
"cache": null,
"encryptionKey": null
}
-
skillsetNameでカスタムスキルセットを指定している。 -
outputFieldMappingsでAIエンリッチメント後のインデックスを指定している。
実行結果は以下の通り。キーフレーズ抽出結果がインデックスにマッピングされていることが分かる。
デバッグセッション
インデクサー/スキルセットを用いてデータソースから抽出して正しくインデックスにマッピングできているかデバッグできる。
スキルセットでの実行結果がどこに格納されているか（後続でのインプットがどこに格納されているか）を確認することもできる。
キャプチャだと、キーフレーズ抽出の結果が、document/keyPhrasesに格納されていることが分かる。
パスのkeyPhrasesは、ユーザ側でスキルセットにて定義したtargetNameによって変化する。
例えば、keyPhrasesv2とした場合は、document/keyPhrasesv2に格納される。
このパスを、インデクサー側のsourceFieldNameに指定することで、インデックスとのマッピングが可能になる。
→ スキルセットでのoutputは、インデクサーでのインプット（厳密にはinputというフィールド名ではなくsourceFieldNameに指定）という対応関係になる。
データのインポートとベクター化
チャンク分割とベクトル化のスキルセット（2023年12月時点でプレビュー機能）
簡単にチャンク分割とベクトル化に対応したインデックスを作成可能。
- データソース(Blobストレージ)の選択
- ベクトル化を行うOpenAIリソースの選択
- インデックス作成の間隔スケジュール
実施後確認すると、チャンクはインデックスに格納されているのが分かる。ベクトルはOpenAIを使って計算したものが格納されていることが分かる。
検証時に発生したエラー
- 1つ目のエラー
- インデクサーでインデックスとのマッピングが記載していなかったことが原因
- 2つ目のエラー
- スキルセットでは、言語（enやjp）の抽出を入れていたが、キーフレーズ抽出だけでは言語抽出に対応していないために、実施できないスキルとしてエラーが発生した。
- 実施する場合には、別途スキルセットを組み合わせる必要がありそう。
使った資料
→ 実際にキーフレーズ抽出を実施した。
→ スキルセットの結果がどこに格納されるかの参考にした。
Azure OpenAI
on your dataにおける検索データソース
on your dataとはオーケストラの機能である。
利用者からの質問に対して、「AI Searchなどの検索システムから情報を取得」し、「AOAIに回答作成」の依頼の流れをうまく交通整理してくれるイメージ。
on your dataでは、AI Searchのみがデータソースとして現時点で対応している。
on your dataの利用方法
データソースとしては以下のような、Blob StorageやUpload Filesも選択が可能である。 CosmosDBをデータソースとした場合の利用例。
先ほど、AI Searchのみがデータソースとして対応していると記載したが、これらを選択した場合には最終的にはAI Searchで検索可能な状態になる点は変わらない。
チャンク分割やインデックス化の面倒な処理を自動化してくれるメリットがある。細かな調整ができないのはデメリットとしてあるので、いずれかを利用するかは要件次第である。
プライベート接続について
設定
「on your data」をプライベート接続で利用したい場合が出てくると思う。
執筆時点（2024/05)では、一部のリソースのみプライベート接続の設定を行えばいいわけではなく、AOAI/AISearch/ストレージアカウントにおいてプライベート接続を、以下のドキュメントに沿って全て実施する必要がある。
単純にネットワーク的に絞りたい場合でも、マネージドID（注意点を後述）の有効化などが必要になる点が注意。
申請が必要になる
AOAIからAI Searchに対してプライベート接続を行う際には申請が必要になる。見落としがちなので注意。
Azure OpenAI リソースから Azure AI 検索リソースへのアクセスを許可するには、申請フォームを送信する必要があります。 申請は 5 営業日以内に確認され、結果のお知らせはメールで届きます
AI Searchのリソース画面としては、プライベートエンドポイント自体は自由に作成できる。
利用者で作成可能なのは、例えばApp ServiceからAI Searchへの閉域アクセスを行う際のプライベートエンドポイントになる。
1つ目がAOAI以外から閉域アクセスを行う場合で、2つ目がAOAIからの閉域アクセスを行う場合のエンドポイントである。
2つ目のエンドポイントは、申請完了後の連絡からリンクを押すと有効化されるらしいので、事前に作っておく必要は無いようである。
マネージドIDの利用について（インデックス作成時）
プライベートな環境でAOAIで具備されているベクトル化スキルを利用してインデックスを作成する際に、AOAIにもマネージドIDと権限付与が必要になる。
疑義はあるのだが、今後詰まったときの確認ポイントとしてTIPS残しておく。詳細は以下を参照。
Discussion