Azure AI Search入門 - 基本概念理解からAzure OpenAI Searchとの連携まで

部内の勉強会（TechTalk）で共有をしたAzure AI Searchについての資料です。
Azure AI Searchを理解するための基本的な用語・概念から、Azure AI Search側からのAzure OpenAI Serviceとの連携部分についてまで扱っています。

1. Azure AI Search入門 基本概念理解からAzure OpenAI Searchとの連携まで 株式会社 電通総研 Xイノベーション本部 AIトランスフォーメーションセンター 山田 侑樹
2. 目次 第I部 - Azure AI Searchの基本概念理解編 • Azure AI Searchとは • Azure AI Searchを理解するための用語・概念整理 • 全文検索とベクトル検索の違い • Azure AI Searchの検索インデックスにデータを投入する方法 第II部 – インデクサーでのAzure OpenAI Serviceとの連携編 • Azure OpenAI Serviceと連携したRAGアーキテクチャ • インデクサーによるチャンク分割、ベクトル化、保存する方法 2
3. 第I部 - Azure AI Searchの基本概念理解編 • Azure AI Searchとは • Azure AI Searchを理解するための用語・概念整理 • 全文検索とベクトル検索の違い • Azure AI Searchの検索インデックスにデータを投入する方法 3
4. Azure AI Searchとは？ ▍ Azureのフルマネージドの検索サービス ▍ 全文検索、ベクトル検索、ハイブリッド検索、あいまい検索、 自動補完、geo検索など豊富な検索ソリューションに対応 ▍ 他のAzureサービスとの強力な統合機能を提供 ⚫ データソースから自動での検索インデックスへの保存処理（インデクサー） ⚫ OCRやテキストの翻訳などデータソースのコンテンツをAIで解析（スキル、エンリッ チメント、ナレッジストア） 4
5. Azure AI Searchに保存されるデータに関する用語と概念 5 用語 概要 検索インデックス 検索のためのデータのコレクション。 1つの検索インデックス内に複数のドキュメントが格納される。 ※単に「インデックス」と表記をする場合もあるが本資料内では「検索インデック ス」と表記する。 スキーマ 検索インデックスの構造を定義するもの。 スキーマは、検索インデックスに格納されるドキュメントにどのようなフィールド が含まれ、それぞれのデータ型など情報を含む。 ドキュメント 検索インデックス内に格納される個々のデータ項目。 Azure AI SearchではJSON形式で表現される。 フィールド ドキュメント内の個々の属性を示す。RDBの列に似たもので型が存在する。 フィールドによって検索結果の並び替えやフィルタリングが行える。
6. Azure AI Searchに保存されるデータに関する用語と概念 6
7. Azure AI Searchのスケーラビリティに関する用語と概念 7 用語 概要 SU （検索ユニット、 スケールユニット） Azure AI Searchサービスの課金単位。 SUの数はレプリカとパーティションの数によって決定される。 レプリカ Azure AI Searchでホストされるインスタンスの数。 各レプリカは検索インデックスの完全なコピーを持っており、独立でクエリの処理が可能。 レプリカ数を増やすことで負荷分散、高可用性を実現できる。 パーティション Azure AI Searchでのストレージの単位。 パーティションを増やすと書き込み性能が向上する。 シャード 検索インデックスを分割した単位。 Azure AI Searchでは各インデックスは事前にシャードの単位で分割され、パーティションごとに 均等に分散されて保存される。 なおシャードは実装の詳細であるためサービス利用者が意識する必要はない。
8. Azure AI Searchのスケーラビリティに関する用語と概念 検索ユニット（SU）は レプリカとパーティションの数によって決 まる 左図は以下のイメージで作成 - レプリカ数 1 - パーティション数 2 この場合はSUは2となる 8
9. Azure AI Searchのスケーラビリティに関する用語と概念 可用性に影響を与えるのは 「レプリカ数」 読み取り/書き取りで99.9%の可用 性が必要な場合は3つ以上のレプリ カが必要 パーティションは全てのレプリカ に適用されるため、レプリカ数が 多いリソースでパーティションを 増加させるとコストインパクトが 大きい 9
10. Azure AI Search のプランによる制限 作成可能な検索インデックスの数、ストレージの容量、スケール上限はプランによって決まっ ているので注意が必要 10
11. Azure AI Searchでサポートされる検索シナリオ Azure AI Search は「全文検索」と「ベクトル検索」のどちらにも対応し ている ❖ 全文検索 フルテキストインデックスによって作成された転置インデックスを利用してドキュメン トを検索する ❖ ベクトル検索 ベクトルの近傍検索によってドキュメントを検索する 11
12. 全文検索を理解するための用語と概念 12 用語 概要 転置インデックス 文書に含まれる各単語（トークン）とその単語が出現する文書IDの組み合わせによって構成 される索引（インデックス）。 これにより単語が含まれる文書を高速に探し出すことができる。 アナライザー 転置インデックスを構成する際に、文章を単語（トークン）の単位に分割する処理機能やコ ンポーネントを指す。 アナライザーでは単語分割（形態素解析）やノイズとなる単語（ストップワード）の除去、 小文字や原型への変換処理などが行われる。
13. 転置インデックスの作成処理 転置インデックスに格納される単語はアナライザーの種類によって 単語分割などの処理が異なる 13
14. 転置インデックスを利用した検索処理 検索クエリもアナライザーによる単語の分割が行われる 14
15. Azure AI Searchで利用可能なアナライザー 利用可能なアナライザーは大きく分けると2種類ある • 組み込みアナライザー 組み込みのアナライザーには標準Luceneのアナライザー、言語固有アナライザー、特殊 アナライザーがある。 言語固有アナライザーはLucene言語アナライザーとMictosoft 言語アナライザーがある。 • カスタムアナライザー ユーザー定義のアナライザー。 組み込みのアナライザーを拡張するようなこともできる。 15
16. ベクトル検索を理解するための用語と概念 16 用語 概要 Embedding （埋め込みベクトル、 分散表現） テキストなどのデータを多次元のベクトルとして表現したもの。 意味的に類似性の高いコンテンツはベクトル空間内で互いに近くに位置する。 vectorizer （ベクタライザー） テキストなどembeddingに変換するコンポーネント 最近傍検索 与えられたクエリポイント（ベクトル値）に最も近いデータポイントをベクトル空間から探索する 方法。 クエリポイントと各データポイントのベクトル間の距離を計算し、最も距離が小さいポイントを特 定する必要があるため大規模なデータほど計算コストが必要になる。 近似最近傍検索 与えられたクエリポイント（ベクトル値）に近似的に最も近いデータポイントをベクトル空間から 探索する方法。 正確さに犠牲にしパフォーマンスを向上させる方法であり、大規模なデータにも対応できる。
17. ベクトルによる検索処理 ベクトル検索ではユーザーのクエリをベクタライザーを用いて保存されているベクトルの次元 と揃えてから近傍検索を行う 17
18. ハイブリッド検索 Azure AI Searchは全文検索とベクトル検索を組み合わせたハイブリッド検索をサポートして いる ハイブリッド検索は「全文検索」と「ベクトル検索」の結果をReciprocal Rank Fusion (RRF) というアルゴリズムで再ランク付けするもの つまり内部的には全文検索とベクトル検索の両方が行われる 18
19. Azure AI Search を使った検索サービスを実現するまでの手順 Azure AI Searchにデータを保存するには最初に検索インデックスを作成する必要がある 19 本資料で紹介する範囲
20. 検索インデックスの作成 検索インデックスを作成する際は、検索対象のデータ特性とユースケースに合わせてスキーマ の設計を行う 20
21. フィールドの属性 フィールドはデータ型に加えて、検索時にフィールドがどのように使用されるかを示す属性を 定義する 21 属性 概要 searchable フルテキストインデックスを作成するかを制御する filterable $filterクエリで参照できるかを制御する sortable ソート対象に利用できるかを制御する facetable 検索結果の集約化に利用するかを制御する key ドキュメントの一意識別子となるフィールド このフィールドは文字列（Edm.string）で定義される retrievable 検索結果に含めるかを制御する Falseにしたフィールドはスコアリングの内部ロジックなどに応用できる
22. 検索インデックスのスキーマ設計時のポイント • ユースケースに応じてスキーマ設計を行う  検索可能フィールドは必要なものだけを定義する  フィルタやソートもインデックスサイズに影響を及ぼす • インデックスのサイズと検索パフォーマンスにはトレードオフがあることを理解する リッチなスキーマを定義することで強力な検索機能を実現できるが、より多くのスト レージを利用することになるため、高価なプランが必要になりコストが増加する場合も ある 22
23. インデックスへのデータの投入 インデックスへのデータ投入方法はPushモデルとPullモデルがある 23 • Pushモデル Azure SDK・REST APIを利用しインデックスにJSON形式のドキュメントをPushする方 法 • Pullモデル Azure AI Searchがサポートしているデータソースをクロールし、自動でインデックスに ドキュメントを作成する方法
24. Pushモデル vs Pullモデル • Pushモデルの利点  任意のデータソースから検索インデックスにドキュメントを登録できる  検索結果にリアルタイム性をサポートできる • Pullモデルの利点  スケジューリングによる自動更新のサポート  データソースの変更追跡によるドキュメントの最新化  スキルセットによるエンリッチメントのサポート 24
25. Pushモデルを利用する場合 Pushモデルは任意のプログラミング言語で検索インデックスへの ドキュメント保存処理を記述可能 25
26. その他のPushモデルの参考アーキテクチャ https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/architecture/automate-document- classification-durable-functions 26
27. Pullモデルを利用する場合 Pullモデルを利用する場合は、インデクサーを使って検索インデックスにドキュメントを保存 する 27
28. Pullモデルを理解するための用語と概念 28 用語 概要 データソース インデクサーのデータ抽出対象となるクラウド上のデータソース Azure Blob StorageやAzure Cosmos DBなどがサポートされる インデクサー インデクサーはデータソースのデータをAzure AI Searchの検索インデックスのスキーマ構造にマッ ピングする処理を行うコンポーネント 一般的な検索システムの「クローラー」のような処理を担う スキル インデクサーでコンテンツを検索インデックスに投入する際に、コンテンツを変換する単一の操 作を提供するもの スキルセット スキルセットは特定のインデクサーで利用するスキルの集合。少なくとも1つのスキルから構成さ れ、最大で30のスキルを含む。 エンリッチメント インデクサーの拡張機能で、画像などのテキスト情報を持たないデータを検索可能な構造に変換 するもの ナレッジストア エンリッチメントされたコンテンツを保存するストレージ Azure Blob StorageやAzure Table Storageを利用できる
29. インデクサーによる検索インデックスへのデータ投入の流れ Azure AI Searchにデータソース、スキルセットと作成し、それらを利用するインデクサーを 作成する 29
30. その他のPushモデルの参考アーキテクチャ https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/architecture/search-blob-metadata 30
31. 第II部 – インデクサーでのAzure OpenAI Serviceとの連携編 • Azure OpenAI Serviceと連携したRAGアーキテクチャ • インデクサーによるチャンク分割、ベクトル化、保存する方法 31
32. Azure OpenAI Serviceと連携したRAGアーキテクチャ Azure OpenAI ServiceでのRetrieval-Augmented Generation（RAG）実現のために Azure AI Searchが利用される 32
33. Azure OpenAI Serviceとの連携 RAGアプリを作成するのにAzure OpenAI ServiceとAzure AI Searchを組み合わせは Micrtosoftイチ押しの形 33 https://azure.microsoft.com/ja-jp/products/ai-services/ai-search
34. Azure OpenAI Serviceとの接続 インデクサーを使ってのAzure OpenAI Serviceとの連携はAzureポータルの「データのイン ポートとベクター化」から実施できる ※ 現状プレビュー版のためPython SDKからは作成不可 34
35. Azure OpenAI Serviceとの接続 35
36. この操作の裏側で行われていること 先の検索インデックスへのデータ投入の流れと同じことが裏側で行われている 36
37. 利用されるスキル - テキスト分割スキル（TextSplitSkill） チャンク分割をするスキル https://learn.microsoft.com/ja-jp/azure/search/cognitive-search-skill-textsplit 37 { "@odata.type": "#Microsoft.Skills.Text.SplitSkill", "name": "#1", "description": null, "context": "/document", "defaultLanguageCode": "en", "textSplitMode": "pages", "maximumPageLength": 2000, "pageOverlapLength": 100, "maximumPagesToTake": 1, },
38. 利用されるスキル - Azure OpenAI Embedding スキル （プレビュー） Azure OpenAIでEmbedding化を行うスキル https://learn.microsoft.com/ja-jp/azure/search/cognitive-search-skill-azure-openai- embedding 38 { "@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill", "name": "#2", "description": "Azure OpenAI Embedding Skill", "context": "/document/pages/*", "resourceUri": "https://*****.openai.azure.com", "apiKey": "*****", "deploymentId": "emebedding-ada-002", "authIdentity": null }
39. マッピングされる検索インデックスのスキーマ この機能を使ってマッピングされる対象の検索インデックスの スキーマには制限があり、既存のインデックスへのマッピングは不可 39
40. インデックスプロジェクション（プレビュー） 内部でのマッピング処理ではインデックスプロジェクションという機能も利用されている 通常インデクサーは1ファイルを1つのドキュメントにマッピングするがチャンク分割、ベクト ル化が必要で1対多のマッピングが必要 40
41. インデクサーの計算リソース インデクサーはAzure AI Searchのマネージド環境で実行される 41 環境 概要 プライベート環境 リソース固有の環境。 ここで実行されるインデクサージョブは最大24時間実行可能。 プライベート環境で実行可能なインデクサージョブの数は検索ユニットで1つ。 プライベートエンドポイント経由で他のリソースにアクセスする必要があるインデクサージョブはこの環境で実 行する必要がある マルチテナント マネージドな環境。 ここで実行されるインデクサージョブは最大2時間実行可能。 実行できるインデクサージョブの数は不確定。
42. インデクサーとプライベートエンドポイント接続 プライベートエンドポイント接続をするためには共有プライベートリンクを作成する必要があ る AIエンリッチメントなど計算リソースを消費するインデクサージョブのプライベートエンドポ イント経由での実行にはAzure AI SearchのS2/S3、L1/L2プランが必要 つまりコスト面、非機能要件面も視野に入れてプランを選択する必要がある 42
43. インデクサーによるAzure OpenAI Serviceとの連携まとめ ▍ 現状は内部でプレビュー版の機能が多く使われておりプロダクションでは使えない ▍ スキルなどのパラメータは十分カスタマイズ可能なものが設定されているので、SDKなど から操作がサポートされると安定して使えそうなビジョンはある 43
44. CONFIDENTIAL 44