Azure OpenAIのRAG(Retrieval Augmented Generation, 検索拡張生成)機能であるAzure OpenAI On Your Dataを検証していたが、期待通りに独自データの検索ができない場合がある。
独自データはAzure AI Searchに保存されるため、テキスト検索であればAzure OpenAIに入力されたプロンプトを形態素解析し、その結果でAI Searchの検索をしているのだろうと想像。
AI Searchの検索クエリのログが確認できないか調べたところ、上手くいったのでメモ。
- Azure OpenAI On Your Dataについて
- AI Searchの検索クエリの確認方法
- 期待通りに検索できない状態のトラブルシューティング
- Azure OpenAI On Your Dataについて
- AI Searchの検索クエリの確認方法
- 期待通りに検索できない状態のトラブルシューティング
- 振り返り
Azure OpenAI On Your Dataについて
こちらの記事に詳しい。
AI Searchの検索クエリの確認方法
Azure AI サービスのリソースにて、Log Analyticsによるリソースログの診断設定を有効にすればいい。
Azure AI サービスの診断ログを有効化
以下のドキュメントに記載あり。
手順内ではストレージへのアーカイブを行っているが、ここでは省略し、Log Analyticsへの送信のみ設定。
事前に診断設定の送信先となるLog Analytics ワークスペースを作成しておく。
- Azure Portalにて、該当のAzure AI サービスのリソースを開く
- 左のナビゲーションメニューより、監視 > 診断設定を選択
- 診断設定の追加を選択し、以下のように設定
- 診断設定を保存
診断の有効化まで、最大2時間程度かかるとのこと。
Log Analytics ログに対してクエリを実行
先のドキュメントのLog Analytics ログを表示するに記載あり。
Azure Portal左のナビゲーションメニューから、Log Analyticsを開き、診断設定の送信先にしたLog Analyticsワークスペースを選択。
左のナビゲーションメニューからログを選択し、以下のクエリを実行する。
AzureDiagnostics | where OperationName == "Query.Search" | sort by TimeGenerated
クエリの詳細は以下のドキュメントに詳しい。
また、クエリ結果に含まれる Query_s をJSONに変換し、AI SearchにJSONモードでリクエストすると、レスポンスの確認が可能。
以下ドキュメントの「クエリの 2 つの方法」にて、JSON ビューを用いたリクエスト方法の記載がある。
このレスポンスがAzure OpenAIに渡され、その情報を基に応答が生成される模様。
期待通りに検索できない状態のトラブルシューティング
これで検索クエリの確認ができるようになったので、うまく検索できない場合にどのようなクエリが投げられているかを確認した。
なお、Azure OpenAIのモデルには gpt-3.5-turbo-16k を使用している。 gpt-4 だとまた違うかもしれないが、コスト的に利用を断念。
検索結果が返らない
AI Searchに保存されているはずなのに、検索結果が0件になる場合があった。
経験則として、システムプロンプトに「入力は日本語なので、データの検索および回答も日本語で行ってください」のような指示を追加するとうまくいくため、ユーザープロンプトの入力が英語に翻訳されているのではないかと考えていたが、AI Searchのログを見るとその通りだった。
おそらく想像。
AI Searchの検索クエリのログが確認できないか調べたところ、上手くいったのでメモ。
- Azure OpenAI On Your Dataについて
- AI Searchの検索クエリの確認方法
- 期待通りに検索できない状態のトラブルシューティング
- Azure OpenAI On Your Dataについて
- AI Searchの検索クエリの確認方法
- 期待通りに検索できない状態のトラブルシューティング
- 振り返り
Azure OpenAI On Your Dataについて
こちらの記事に詳しい。
AI Searchの検索クエリの確認方法
Azure AI サービスのリソースにて、Log Analyticsによるリソースログの診断設定を有効にすればいい。
Azure AI サービスの診断ログを有効化
以下のドキュメントに記載あり。
手順内ではストレージへのアーカイブを行っているが、ここでは省略し、Log Analyticsへの送信のみ設定。
事前に診断設定の送信先となるLog Analytics ワークスペースを作成しておく。
- Azure Portalにて、該当のAzure AI サービスのリソースを開く
- 左のナビゲーションメニューより、監視 > 診断設定を選択
- 診断設定の追加を選択し、以下のように設定
- 診断設定を保存
診断の有効化まで、最大2時間程度かかるとのこと。
Log Analytics ログに対してクエリを実行
先のドキュメントのLog Analytics ログを表示するに記載あり。
Azure Portal左のナビゲーションメニューから、Log Analyticsを開き、診断設定の送信先にしたLog Analyticsワークスペースを選択。
左のナビゲーションメニューからログを選択し、以下のクエリを実行する。
AzureDiagnostics | where OperationName == "Query.Search" | sort by TimeGenerated
クエリの詳細は以下のドキュメントに詳しい。
また、クエリ結果に含まれる Query_s をJSONに変換し、AI SearchにJSONモードでリクエストすると、レスポンスの確認が可能。
以下ドキュメントの「クエリの 2 つの方法」にて、JSON ビューを用いたリクエスト方法の記載がある。
このレスポンスがAzure OpenAIに渡され、その情報を基に応答が生成される模様。
期待通りに検索できない状態のトラブルシューティング
これで検索クエリの確認ができるようになったので、うまく検索できない場合にどのようなクエリが投げられているかを確認した。
なお、Azure OpenAIのモデルには gpt-3.5-turbo-16k を使用している。 gpt-4 だとまた違うかもしれないが、コスト的に利用を断念。
検索結果が返らない
AI Searchに保存されているはずなのに、検索結果が0件になる場合があった。
経験則として、システムプロンプトに「入力は日本語なので、データの検索および回答も日本語で行ってください」のような指示を追加するとうまくいくため、ユーザープロンプトの入力が英語に翻訳されているのではないかと考えていたが、ログを見るとその通りだった。
自然言語を形態素解析のように分割するためのプロンプトが別にあり、それが英語で記述されているため、システムプロンプトを記述しないと英語に翻訳される、とかだろうか?
結果の加工を行うようなプロンプトの場合、検索結果がおかしくなる
結果を加工するような長めのプロンプトを書いて実行すると、結果が安定しない。ログを見ると、検索クエリとして渡される文字列の段階で加工が行われており、ユーザープロンプトの入力とは異なる文字列で検索されていた。
1回ですべての処理を行うのではなく、RAGによる結果を返す短めの処理と、RAGを使わずに先の結果を加工する処理の2回に分けることで解消した。
会社名やサービス名、プロダクト名で検索できない
タイトル通り、会社名やサービス名、プロダクト名でうまく検索ができない場合があった。一般的な名称ではない場合、検索クエリに含まれなかったり、うまく分割されない場合があった。
この場合、システムプロンプトとして対象の名称のリストを渡してやることで解消。
振り返り
ログを見るといろいろと学びがあった。あまり複雑なことはせず、RAGはRAG、結果の加工は加工で処理を分けたほうがよさそう。
ただ、今回の問題はLLMがgpt-3.5-turboなことも原因だと思う。gpt-4を使うようにすれば、英語に翻訳されて検索される、あたりはいちいちシステムプロンプトで日本語を使うよう指定しなくても、ユーザープロンプトが日本語なところから判断してくれるのではないかなと思う。
