Azure 生成AI RAG構築でハマるインデクサー定義10選

私は、システム開発で日々さまざまなプロジェクトに携わっています。最近はAzureの生成AIサービスとRAG（Retrieval-Augmented Generation）を組み合わせたシステムの構築が増加傾向にあり、特にAzure AI Searchのインデクサー定義の段階で多くの人がつまずくのを見てきました。

インデクサーは、データソース（ドキュメント）から情報を抽出し、ベクトル化や前処理を行い、最終的に検索インデックスに格納するまでの自動化されたパイプラインです。この定義が不適切だと、RAGの精度が大きく損なわれる原因となります。

今回は、私が実際に遭遇したり、多くの開発者がハマりやすいと感じた、インデクサー定義における10個の落とし穴と、その解決策を解説します。

1. データソースの接続情報ミス

インデクサーは、ドキュメントが格納されているデータソース（Azure Blob Storageなど）に接続できなければ始まりません。 * ハマりやすいこと: ストレージアカウントのキーやSASトークンの有効期限切れ、または接続文字列の誤り。 * 解決策: 常に最新かつ適切な接続情報を利用する。本番環境では、セキュリティを考慮してマネージドIDを使用し、接続情報のハードコーディングを避けることが推奨されます。

2. エンベディング（埋め込み）モデルの指定ミス

インデクサーは、テキストをベクトルに変換するためにAzure OpenAIのエンベディングモデルを利用します。

• ハマりやすいこと: インデクサーのスキルセットで指定したエンベディングモデル名が、Azure OpenAI Serviceでデプロイされているモデル名と一致しない。
• 解決策: デプロイ済みのAzure OpenAIエンベディングモデル（例: text-embedding-ada-002）の名前と、インデクサーのエンベディングスキルで指定する名前を完全に一致させる。

3. ドキュメントのチャンク分割設定の不備

RAGの性能は、ドキュメントのチャンク（断片）分割方法に大きく左右されます。

• ハマりやすいこと: ドキュメントを固定長で単純に分割してしまい、文脈が途中で途切れる。
• 解決策: Text Splitスキルを使い、text-splitterプロパティで適切な分割方法を指定する。より高度な分割を望む場合は、Azure Functionsなどを使ってカスタムの分割ロジックを実装し、インデクサーに組み込むことも検討しましょう。

4. メタデータの抽出漏れ

インデクサーは、ドキュメントのコンテンツだけでなく、ファイル名や作成日などのメタデータも抽出できます。

• ハマりやすいこと: コンテンツの抽出にばかり気を取られ、検索結果の絞り込みに役立つメタデータ（authorやcreated_dateなど）の抽出を忘れる。
• 解決策: インデクサーの定義で、fieldMappingsとskillsetの双方でメタデータプロパティを適切にマッピングする。これにより、ハイブリッド検索時にメタデータによるフィルタリングが可能になります。

5. インデックス定義との整合性エラー

インデクサーの出力フィールドは、格納先のインデックス定義のフィールドと完全に一致している必要があります。 * ハマりやすいこと: インデクサーの出力名とインデックスのフィールド名が異なる、またはデータ型が一致しない。 * 解決策: インデクサーを定義する前に、インデックスのスキーマを確定させる。特にプロジェクションマッピングで、スキルの出力をインデックスのフィールドに正しく割り当てることを確認する。

6. スキルのチェーン設定ミス

インデクサーの強力な機能の一つは、複数のスキルを組み合わせてパイプラインを構築できることです。

• ハマりやすいこと: スキル間で入力と出力の依存関係が正しく設定されておらず、処理が失敗する。
• 解決策: contextを理解し、各スキルの出力が次のスキルの入力として正しく渡されるよう、丁寧に設定する。例えば、Text Splitスキルの出力がエンベディングスキルの入力となるように指定する必要があります。

7. インデクサーの実行スケジュール設定

ドキュメントが頻繁に更新される場合、インデクサーのスケジュール設定は非常に重要です。

• ハマりやすいこと: スケジュールを全く設定せず、手動実行に頼ってしまう。
• 解決策: インデクサーの定義でscheduleプロパティを設定し、ドキュメントの更新頻度に合わせて自動実行するように構成する。これにより、常に最新の情報をRAG環境に反映させることができます。

8. 権限（ロール）の不足

インデクサーは、Azureの他のサービスにアクセスするための権限を必要とします。 * ハマりやすいこと: インデクサーにStorage Blob Data ReaderやCognitive Services Userなどのロールが付与されておらず、データにアクセスできない。 * 解決策: インデクサーに割り当てられたマネージドIDに対し、必要なロールを最小権限の原則に従って付与する。セキュリティの観点からも非常に重要です。

9. 処理の失敗とデバッグ方法の知識不足

インデクサーの実行中にエラーが発生することは少なくありません。

• ハマりやすいこと: エラーが発生しても、原因がわからず途方に暮れてしまう。
• 解決策: Azureポータルのインデクサー詳細画面で実行履歴を確認し、失敗したジョブのログ（statusDetailsなど）を分析する。エラーメッセージを丁寧に読むことで、原因を特定できることが多いです。
• dataToEmbedプロパティの誤解 dataToEmbedプロパティは、エンベディングスキルでベクトル化する対象を定義します。
• ハマりやすいこと: dataToEmbedにcontent以外の文字列（例: title）を指定してしまい、インデックスの埋め込みフィールドに意図しない情報が格納される。
• 解決策: RAGの回答生成に最も重要な「本文」がベクトル化されるように、dataToEmbedにはドキュメントのコンテンツ本体を指定する。ハイブリッド検索を前提とする場合、キーワード検索はcontentフィールドに任せ、ベクトル検索は埋め込みデータに任せるという役割分担を明確にすることが大切です。

まとめ

私は、インデクサー定義はRAG環境のパフォーマンスと安定性を大きく左右する重要な要素だと考えています。これらの落とし穴を事前に把握し、インデクサーとインデックスの定義を綿密に計画することで、より効率的で信頼性の高いRAGシステムを構築できるはずです。

もしあなたが、今インデクサー定義で悩んでいるなら、この記事が少しでもその解決に役立つことを願っています。