執筆のきっかけ
業務で、RAGシステムの構築をしているのですが、クエリ拡張（ユーザーの質問文をLLMが理解できるように補足する）に最適な軽量なモデルを探していました。
ちょうどそのタイミングでAzure OpenAIのアップデートで多様なユースケースに適したLLMを選択してくれる『モデルルーター』というものがあるとのことだったので、さっそく使ってみました。
モデルルーターとは？
公式いわく、モデルルーター自体がLLMモデルであり、GPT-4 のような単一の基本モデルを使用する場合と同様に、Completions API を使用してモデル ルーターにアクセスできるとのこと。
早速使ってみた
いつものAzure AI Foundryのモデルカタログ画面にさりげなく『モデルルーター』がいました。
このモデルをクリックして、次画面で『このモデルを使用する』をクリックします。
『リソースを作成してデプロイする』をクリックしてデプロイします。
デプロイが完了したら『プレイグラウンドで開く』をクリックします。
実際にプレイグラウンドで質問してみると、以下のような回答が来ました。
↓回答内容
Azure AI Foundry
| gpt-4.1-nano-2025-04-14
AI-generated content may be incorrect
RAG（Retrieval-Augmented Generation）システムにおいて、クエリ拡張のためのモデル選定は非常に重要です。ご要望に沿った最適なモデルについてご提案します。
【要望のポイント】
あいまいな質問や専門用語を含む質問を理解しやすく変換できる能力
軽量で高速な応答
実績があり信頼性の高いモデル
おすすめのモデル
1. Sentence-BERT（SBERT）を用いたクエリエンコーディングと類似クエリ拡張
概要：SBERTは、質問の意味を捉えるための文エンコーディングに優れており、クエリの意味理解と類似クエリの抽出に適しています。
用途：ユーザークエリと補助用の拡張クエリや補助語を生成しやすくなる。
メリット：
軽量で高速（特にdistilBERTベースのモデル）
実績があり、多くの応用例が存在
既存の類似検索やクエリ拡張タスクに適用可能
2. T5（Text-to-Text Transfer Transformer）の軽量版（例：T5 SmallやT5 Base）
概要：T5は多用途のシーケンス変換モデルで、質問の補助や拡張に用いることができる。
用途：あいまいな質問や専門用語を含む質問を「理解しやすい形式」に変換するタスクに適用。
メリット：
実績豊富（多くのNLPタスクで成功）
事前学習済みで、微調整次第で高性能を発揮
軽量版を選べばレスポンスも速い
3. GPT-3.5 Turbo（OpenAI API）
概要：高性能な大規模言語モデル。質問の補助や拡張を行うことに優れる。
用途：あいまいな質問や専門用語を含む質問の意味理解と自然な拡張
メリット：
実績が非常に高い
API経由で容易に導入可能
高速化や制御も柔軟
ただし、コストやレスポンス速度の観点からは、GPT-3.5 Turboはやや重めになる場合もあります。
推奨アプローチ
軽量・高速を重視：
**SBERT（DistilBERTベース）**を用いたクエリエンコーディング + ルールやルックアップによる拡張候補の生成
その後、T5 Smallを使って、拡張クエリの自然言語変換を行う
高い性能と実績を重視：
GPT-3.5 Turboを用いて、クエリの理解と拡張を行う。APIを活用しやすく、柔軟な対応が可能。
まとめ
要望 推奨モデル 備考
高速・軽量 DistilBERT/SBERT + T5 Small 低コストでレスポンス速く、実績も豊富
高性能・実績 GPT-3.5 Turbo 高い理解力と柔軟性、導入容易
---
### 補足
クエリ拡張の具体的な方法：
SBERTでクエリの類似語や補助語を探索
T5であいまいな質問や専門用語を自然言語で補完・変換
生成されたクエリをLLM（例：GPT-3.5 Turbo）に渡し、回答生成の補助
ご検討の際は、システムの規模やコスト、レスポンス要件に応じて選択を調整してください。
Copilotと比較
同様の質問をCopilotにしてみました。
以下Copilotでの回答結果です。
RAG（Retrieval-Augmented Generation）における「クエリ拡張」に最適なLLMモデルについて、以下の3つの観点からおすすめを整理しました：
---
### ✅ 要件整理
| 要件 | 内容 |
|------|------|
| ① | あいまい・不足・専門的な質問を、LLMが理解しやすい形に変換できる |
| ② | 軽量でレスポンスが速い |
| ③ | 実績があるモデル |
---
### 🔍 推奨モデルとアプローチ
#### 1. **Multi Query Retriever + GPT-4o**
- **概要**：ユーザーのクエリを複数の視点から再構成し、検索精度を向上させる手法。LangChainなどで実装可能。
- **実績**：HEROZ社の検証では、通常のRAGに比べて**26.32%精度向上**、処理速度もほぼ同等[1](https://techblog.heroz.jp/entry/2024/03/29/154808)。
- **モデル**：GPT-4o（OpenAI）を使用。軽量かつ高速で、マルチモーダル対応。
- **特徴**：
- あいまいな質問に対して複数の明確なクエリを生成。
- 専門用語の言い換えや補足も可能。
- LangChainで簡単に組み込み可能。
#### 2. **Query Transformation + Claude 3 Haiku**
- **概要**：ユーザーのクエリを意味的に再構成し、検索精度を高める手法。
- **モデル**：Claude 3 Haiku（Anthropic）— 軽量で高速、商用利用実績も豊富。
- **特徴**：
- 文脈強化や意味補完に強い。
- 日本語対応も良好。
- RAGの前処理として最適[3](https://hdkworks.com/archives/35288)。
#### 3. **GPT-3.5 Turbo + Prompt Engineering**
- **概要**：軽量モデルでクエリ拡張を行う場合の定番。
- **モデル**：GPT-3.5 Turbo（OpenAI）— コストパフォーマンスに優れ、応答速度も速い。
- **特徴**：
- Prompt Engineeringでクエリの明確化を支援。
- Azure OpenAI Serviceでも利用可能。
- 実績多数、導入しやすい[2](https://zenn.dev/microsoft/articles/rag_textbook)。
---
### 🛠 実装のヒント
- **LangChain**や**LlamaIndex**を使えば、Multi Query RetrieverやQuery Transformationの実装が容易。
- クエリ拡張は「Augment」フェーズで行うのが一般的ですが、「Retrieve」フェーズの前処理としても有効。
- 軽量モデルを使う場合は、**チャンクサイズの最適化**や**メタデータフィルタリング**と併用すると効果的です。
---
### 🎯 まとめ：おすすめ構成
| 構成 | モデル | 特徴 |
|------|--------|------|
| 高精度・高速 | GPT-4o + Multi Query Retriever | 精度・速度・柔軟性のバランスが良い |
| 軽量・高速 | Claude 3 Haiku + Query Transformation | 軽量で意味補完に強い |
| コスパ重視 | GPT-3.5 Turbo + Prompt Engineering | 実績豊富で導入しやすい |
---
ご希望のユースケースや予算に応じて、さらに具体的な設計支援も可能です。
どの構成が気になりましたか？また、現在のRAG環境（使用モデルや検索基盤など）も教えていただければ、より詳細な提案ができます！
比較してみると、以下の違いがありました。
- Copilotが推奨モデルとアプローチについて回答しているのに対して、モデルルーターは、モデルのみを回答している
- Copilot側が知名度の高い新しめの汎用モデルを提案しているのに対して、モデルルーターは専門的なモデルを提案しているがやや古いモデル（Sentence-BERT、T5ともに2019年、GPT-3.5 Turboは2023年のモデルだが1106/0125バージョンは2025年9月に提供終了予定されている）
モデルルーターが提案するモデルがAI Foundryで使用できるか追加で質問をしてみました。
上記モデルはAI Foundryで使用できますか？
結果として以下の回答を得ました。
どうも、AI Foundryで使用できるモデルに限定して提案しているわけではないようです。
AI Foundryは、特定のAIモデルやフレームワークをサポートするクラウドプラットフォームやソリューションです。モデルの導入やカスタマイズ性はそのプラットフォームの仕様に依存します。
1. AI Foundryでのモデル使用について
サポートされるモデル：
一般的に、AI Foundryは特定の事前学習済みモデル（例：OpenAIのAPI、Hugging Faceのモデルなど）を統合できる場合があります。
外部モデルのインテグレーション：
カスタムモデル（例：SBERT、T5の自己ホスティング版）をAI Foundryに組み込むには、以下の条件が必要です。
モデルのホスティング：モデルをAPI化して外部アクセスできる状態にする。
API連携：AI FoundryからそのAPIを呼び出す設定が可能である。
2. 具体的なモデルの対応状況
OpenAI GPT-3.5 Turbo：
多くのプラットフォームとAPI連携が可能なため、AI FoundryからOpenAI APIを呼び出す構成にすれば利用可能です。
Hugging Faceのモデル（SBERT、T5など）：
これらは自己ホスティングまたはHugging Face Hubを利用してAPI化すれば、AI Foundryから呼び出すことができます。
3. 結論
AI Foundryで直接動かせるか：
既存のモデルを「直接」インストールして動作させるのは難しい場合があります。ただし、API経由での連携は一般的に可能です。
推奨：
OpenAIのAPIを使う場合は、そのまま連携可能です。
Hugging Faceの自己ホスティングモデル（SBERTやT5など）をAPI化して、AI Foundryから呼び出す設定にすれば使えます。
4. 補足
具体的な導入可否や設定方法は、AI Foundryの運用ポリシーや対応範囲によります。
プラットフォームのドキュメントやサポートに問い合わせることをおすすめします。
もし具体的な環境や要件があれば、それに合わせてより詳細なアドバイスも可能です。
モデルルーターが提案するモデルが古いので、モデルルーターに対してさらに質問をしてみました。
2024年以降のモデルだとどう？
返答としては、以下でした。
モデルルーターの知識範囲が2023年10月までとのこと。。。
2024年以降のモデルについての情報は、私の知識の範囲（2023年10月まで）では限定的ですが、一般的なトレンドと予測を踏まえてお答えします。
1. 最新モデルの特徴と動向
より高度なAPI連携：
2024年以降のAIモデルは、より高度なAPIやSDKを提供し、クラウドプラットフォームとの連携も強化される見込みです。これにより、外部モデルの統合やカスタムモデルの利用がより容易になる可能性があります。
自己ホスティングとプライバシー：
より多くの企業や研究機関が自己ホスティング可能なモデルをリリースし、カスタマイズ性やプライバシー保護を重視したソリューションが増加しています。
マルチモーダル対応：
画像、音声、動画なども扱えるマルチモーダルモデルが進化し、多様なデータタイプの統合が進むと予想されます。
2. AI Foundryの対応状況（2024年以降のモデル）
APIベースの接続：
既に多くのクラウドプラットフォームは、API経由で最新モデルを呼び出す方式を採用しています。2024年以降もこの傾向は続き、AI Foundryも同様にAPI連携を重視する可能性が高いです。
自己ホスティングモデルのサポート：
最新モデルの中には自己ホスティング可能なものも増えており、それらをAI Foundryと連携させるには、API化やDockerコンテナ化などの仕組みを整える必要があります。
モデルのカスタマイズ性：
より柔軟にカスタムモデルを組み込める仕組みが整備されている場合、SBERTやT5のような自己ホスティング型モデルも利用しやすくなるでしょう。
3. 具体的なモデル例と対応可能性
OpenAI GPT-4やGPT-5（2024年リリース予定含む）：
これらはAPI経由での利用が基本となるため、AI FoundryからのAPI呼び出しで対応可能です。
MetaのLlamaシリーズやGoogleのPaLMシリーズ：
これらは自己ホスティングやAPI提供によって連携できる可能性があります。
ハイブリッドモデル：
例えば、最新の大規模モデルと既存のカスタムモデルを組み合わせて使うことも想定されます。
4. まとめ
2024年以降の最新モデルは、より多様な連携方式（API、自己ホスティング、プラグインなど）をサポートする方向に進むと考えられます。
AI Foundryもその流れに合わせて、API連携や自己ホスティングの支援を強化している可能性が高いです。
5. 最終的な推奨
最新モデルを使いたい場合は、そのモデルのAPI提供状況や自己ホスティングの可否を確認してください。
AI Foundryのサポート範囲やドキュメントをチェックし、API連携やカスタムモデルの取り込み方法を事前に把握することをおすすめします。
所感
知識範囲が2023年10月までなのは、若干残念だなぁと。
プレイグラウンドのチャットUI部分に『gpt-4.1-nano-2025-04-14』と記載があったので、これをベースにモデルの知識を入れてファインチューニングされているとは予想されます。
モデル案内の方便として、ファインチューニングが最適だったのかなぁと感じてしまいました（ファインチューニングだとどうしても古い情報になりがちなので）。
Discussion