モデルカタログでモデルを探索する

AIアプリケーションを構築する際、最も難しい部分の1つは実装ではなく、適切なモデルを選択することです。強力なプロンプトやクリーンなワークフローを持っていても、モデルがミスマッチであれば、品質とスピードの両方が低下します。

この章では、Visual Studio CodeのFoundry Toolkitを使用して、推奨事項からサイドバイサイド（並列）検証に至るまでの実践的な選定パスをたどります。

これは、裏付けのあるモデル選定と考えてください。

各ステップはそれ単体でも有用ですが、真の魔法は、ループ全体がエンドツーエンドで実行されたときに起こります。

学習内容

この章は、場当たり的な推測を行うのではなく、再現可能なモデル選定プロセスを構築することに関するものです。GitHub Copilotの推奨事項、モデルカタログのフィルタリング、モデルカードのレビュー、デプロイ、そしてプレイグラウンドでの比較を、再利用可能な1つのループに統合します。

この章では、以下の方法を学びます

• ショートリストの生成：GitHub Copilotを使用して、現実的な候補の初期セットを作成する。
• カタログの絞り込み：フィルターを使用して、モデルの選択肢を関連性の高いサブセットに減らす。
• 機能の検証：デプロイ前にモデルカードを確認する。
• 選択したモデルのデプロイ：選定した候補をFoundryプロジェクトにプッシュする。
• 動作の比較：プレイグラウンドで出力を並べて評価する。

ワークフローを実行する前に、この構造がなぜ重要であるかを明確にしておきましょう。

問題の定義：モデル選定はリスク軽減のプロセスである

モデル選定を「好みテスト」ではなく「リスク軽減」として扱うことが役立ちます。普遍的な「最高」のモデルを見つけようとしているのではありません。ワークロード、制約、地域に最も信頼性の高い形で適合するものを見つけようとしているのです。

その枠組みにより結果の評価方法が変わります。出力のスタイルと同様に、一貫性とデプロイ可能性が非常に重要だからです。

見た目の良い出力は素晴らしいですが、デプロイ可能な出力が勝ります。

これを適用する簡単な方法は、4つの実用的なチェック（機能適合性、地域の可用性、コストプロファイル、同じプロンプト下での動作品質）に対して各候補を評価することです。モデルがこれらのチェックですべて優れている場合、エンジニアリングおよび製品のステークホルダーの双方に対してその選択を説明・正当化しやすくなります。

前提条件

何かを比較する前に、環境の準備ができていることを確認しましょう。この章はローカルのツールとクラウドの可用性に依存しているため、今のうちに簡単なセットアップ確認を行うことで、後々の面倒なエラーを防ぐことができます。

これらの前提条件が整っていれば、この章のすべてのステップはUIに表示される内容と明確に一致するはずです。

• Visual Studio Code：拡張機能のワークフローやコマンドサーフェイスを利用できるようにインストールおよび更新されていること。
• Foundry Toolkit 拡張機能：インストールされており、アクティビティバーに表示されていること。
• Azure サブスクリプションとリージョン：デプロイの確認およびクォータを考慮したフィルタリングのために選択されていること。
• 接続された Foundry プロジェクト：リソース下の Foundry Toolkit で利用可能であること。

セットアップが確認できたところで、この章で何を学ぶのか、そしてそれが日々のモデル作業にどのように結びついているのかを正確に定義しましょう。

これにより、勘に頼った推測が、再現可能なループに置き換えられます。

なぜモデル選定が重要なのか

複数のプロバイダー、モデルファミリ、サイズ、機能フラグが存在する場合、モデル選定はすぐに圧倒的なものになり得ます。構造化されたプロセスにより、決定は証拠に基づいて行われ、チームが好みだけで最適化してしまうのを防ぐことができます。

また、これはトレーサビリティを生み出し、ステークホルダーに結果を説明する必要がある場合に重要となります。

たとえば、シナリオに画像入力とスウェーデン中部でのデプロイが必要な場合、全体的には優れていてもそのリージョンで利用できないモデルは実用的な選択肢ではありません。これこそが、規律あるフィルターと検証のワークフローが時間を節約する場面です。

実際には、このワークフローによって以下のメリットが得られます

• 迅速な絞り込み：詳細なテストを行う前に、大規模な候補セットを削減する。
• 信頼性の向上：コミットする前に機能と可用性を検証する。
• 明確なトレードオフ分析：同一のプロンプトで速度、スタイル、品質を比較する。
• より良い本番環境への適合：クォータ、リージョン、デプロイの制約に合致したモデルを選択する。

このワークフローを実際に実行する方法について説明します。

ステップ1：GitHub Copilotの推奨事項から始める

カタログに飛び込む前に、まずはGitHub Copilotの推奨事項から始めるのがおすすめです。これは、Copilotが機能要件とサブスクリプションおよびリージョンの制約を組み合わせながら、推奨事項を作成できるためです。

このステップでは、以下の3つの実用的な基準を満たすモデルのショートリストを求めましょう

• ツールキットのサポート：現在の Foundry フローからモデルにアクセスできるかどうか。
• リージョンのデプロイ可能性：ターゲットリージョンがそのモデルをサポートしているかどうか。
• 機能の適合性：画像処理やその他の必要な機能が備わっているかどうか。

したがって、Copilotへの適切なプロンプトは、以下のようにこれら3つの制約を1つのリクエストに組み合わせたものになります

Recommend two models for a marketing scenario that require image input support and are deployable in my subscription and region.

次に、このプロンプトを使用しましょう

1. Visual Studio CodeでGitHub Copilot Chatを開きます。

2. 推奨事項のプロンプトを貼り付けます。

3. ターミナルではなく、チャットでプロンプトを実行します。

   使用できるプロンプトの例は以下のとおりです

    Recommend two models for a marketing scenario that require image input support and are deployable in my subscription and region.
   

   

   図1：GitHub Copilotにモデルの推奨を求めるプロンプトの例。

4. 応答を確認し、推奨されたモデルをメモします。

   

   図2：GitHub Copilotの推奨事項による結果の例。

これは、何百ものモデルをあてもなくスクロールするよりも、はるかに優れたスタートラインです。

スタートラインが決まったところで、カタログに移動して、候補をフィルタリングおよび検証する方法を確認しましょう。

ステップ2：モデルカタログを探索する

モデルカタログは、Foundry Toolkitにおける中心的な発見サーフェイスです。これを使用して、複数のプロバイダーのモデルを比較し、機能を確認し、候補を決定する前にデプロイの制約を検証することができます。

次に、カタログを開いて、より詳細な調査のために候補セットを管理しやすい数に減らす方法を確認しましょう。

1. Foundry Toolkitを開きます。
2. 開発者ツールに移動します。
3. 特定のモデルをレビューする前に、モデルカタログを選択します。

すると、複数のプロバイダーやホスティングパスを含むモデルのリストが表示されます（下の画像のようになります）

図3：Foundry Toolkit内のモデルカタログ。

次のステップでは、フィルターを適用して、このリストを管理しやすい候補のセットに絞り込みます。

ステップ3：フィルターを使用して候補を絞り込む

フィルタリングは、要件を満たす管理しやすいモデルのセットに候補リストを絞り込むのに役立ちます。これは、ビジョン入力などの機能固有のニーズが要件に含まれている場合に特に便利です。

候補を管理しやすいセットに減らすために適用できるすべてのフィルタリング基準は次のとおりです

• ホスティングソース：実際にデプロイを予定しているホスティングパスに限定する。
• パブリッシャー：意図的に単一のプロバイダー内、または複数のプロバイダー間でモデルを比較する。
• 機能サポート：画像添付などの機能を必須とする。
• ランタイムタイプ：必要に応じて、ローカルのCPU、GPU、またはNPUのオプションを含める。
• ファインチューニングのサポート：適応要件に一致するモデルのみを残す。

次に、「興味深いリスト」から「実際の候補」へと進みましょう。

1. モデルカタログでフィルターパネルを開きます。

2. フィルターを次のように設定します

   ホスト元: Foundry パブリッシャー: OpenAI

   以下のような、絞り込まれた候補リストが表示されるはずです。

   

   図4：Foundry Toolkitのモデルフィルターパネル。ここでは、Hosted By: Foundry、Publisher: OpenAIを選択しています

   これにより、数十のエントリをスキャンする代わりに、数分で調査できる管理しやすい数に候補リストが削減されます。

その段階での次のステップは、各候補のモデルカードをレビューして、デプロイ前に機能、価格、制約事項を確認することです。

ステップ4：モデルカードを確認する

デプロイの前に、各モデルカードを開いて、プロバイダーが実際に何を保証しているかを確認してください。これにより、後々になって、特に価格、入力の制約、機能の前提条件に関する隠れたミスマッチを防ぐことができます。

これはデプロイ前のチェックと考えてください。

実際には、モデルカードのレビューによって次の問いに答えられる必要があります：このモデルは、私たちが求めることを、許容可能なコストで、期待される動作プロファイル通りに実行できるか？

• 機能：必要なモダリティと長所を確認する。
• ユースケース：シナリオが意図された用途に合致しているか確認する。
• 価格：想定されるトークンコストの挙動を理解する。
• 技術仕様：制限事項、コンテキストの詳細、運用上の制約を確認する。

モデルカードをレビューするには

1. フィルターされたモデルを1つ選択します。
2. そのモデルカードのページを開きます。
3. デプロイに進む前に、機能と価格を確認します。

モデルカードのレビューに納得したら、サイドバイサイド比較のために、候補をFoundryプロジェクトにデプロイする準備が整います。

ステップ5：選出されたモデルをデプロイする

デプロイにより、モデルの比較は理論から実践的なテストへと移行します。このステップでは、同一のプロンプトの下で評価できるように、2つのOpenAIの候補が同じFoundryプロジェクトにデプロイされます。

それでは、デプロイを開始しましょう。

1. モデルカードからデプロイを選択します。
2. 接続されている Foundry プロジェクトをデプロイ先として選択します。

これにより、数分かかるデプロイプロセスが開始されます。完了すると、デプロイされたモデルがFoundryプロジェクトに表示されます。

次のステップでは、プレイグラウンドで2つのデプロイ済みモデルを並べて比較し、同一のプロンプトの下での動作を評価します。

ステップ6：プレイグラウンドでモデルを比較する

モデル選定における重要なステップの1つは、同一のプロンプトの下で出力を比較することです。これにより、出力の違いがプロンプトのブレではなく、モデルの挙動に起因するものであることが保証されます。

この比較では、マーケティングテキスト用プロンプトとビジョン抽出用プロンプトという2種類のプロンプトを使用して、それぞれの異なる強みを引き出します。

比較に使用する2つのプロンプトは次のとおりです

テキストプロンプト:

Generate a short LinkedIn post for developer productivity with AI tools.

ビジョンプロンプト:

Extract text from an attached image.

次に、プレイグラウンドの比較モードを使用して、デプロイされた2つのモデルを並べて評価します。

この比較を行うには、以下の手順に従います

1. プレイグラウンドを開きます。
2. 比較モードを有効にします。
3. 各応答ペインに1つずつ、デプロイされたモデルを割り当てます。

出力を確認する際は、一貫した評価軸で評価してください

• レイテンシ：どちらのモデルがより速く使用可能な出力を返すか？
• スタイル：トーン、流暢さ、構造にどのような違いがあるか？
• 冗長性：タスクに対して応答が簡潔であるか、あるいは過度に長文であるか？
• シナリオへの適合性：どちらの出力が、ビジネスが実際に必要としているものに近いか？

候補を選定した後に、残された重要なステップが1つあります：プロンプトとパラメータの洗練です。

ステップ7：プロンプトとパラメータで動作を洗練させる

モデルの選択は品質の一部に過ぎません。システム指示や生成コントロールを使用して、出力の動作を形作る必要があります。

このステップでは、エージェントのワークフローへさらに深く進む前に、応答をトーン、オーディエンス、およびチャネルの制約に合わせます。

一般的な洗練プロセスでは、システムプロンプトを追加し、生成設定を少しずつ調整してから、同じシナリオプロンプトで再テストを行います。

• システムプロンプト：役割、トーン、および出力の境界を設定する。
• 最大応答トークン数：応答の長さを制御する。
• 温度：創造性と決定論的な制御のバランスを調整する。
• Top-p：トークンサンプリングの動作を調整する。

動作を調整するために使用できるシンプルな洗練ループは次のとおりです

1. プレイグラウンドにシステムプロンプトを追加します。
2. 生成設定を一度に1つずつ調整します。
3. 次の設定を調整する前に、それぞれの変更を評価します。

簡単な質問

2つのモデルが同様に優れたテキストを生成するものの、一方がターゲットリージョンで利用できない場合、どちらが本番環境としてより良い選択であり、その理由は何ですか？

回答

本番環境としてより良い選択となるのは、許容可能な動作とコストでターゲットリージョンにデプロイできるモデルです。必要な場所でデプロイできないわずかに優れた出力は、後で隠しきれない納品リスクを生み出します。本番環境への適合性には、単なる生の出力品質だけでなく、常に可用性が含まれます。

今後の展望

これで、モデル選定からエージェント開発へ移行する準備が整いました。次の章では、このモデル評価の基盤を使用して、より良い質問をし、ツールを効果的に使用し、評価や出荷がより容易な出力を生成するエージェントを構築します。

これにより、感覚ではなく、根拠に基づいてモデルの決定を下すことができるようになります。

詳細情報

この章の内容をさらに定着させたい場合、最適な次のステップは、この書き起こしガイド、製品ガイダンス、およびデプロイ詳細という3つの角度から同じワークフローを見直すことです。この組み合わせにより、概念の理解から実際のプロジェクトでの応用への移行がスムーズになります。以下のリンクを順番に使用すると、チュートリアルとリファレンスの両方の視点から、同じ「推奨から比較へ」の流れを確認できます。

• Visual Studio CodeにおけるGitHub Copilot：Visual Studio CodeのドキュメントでCopilotの機能とワークフローを確認する。
• 参考動画（オプション）：この章の完全版動画を視聴する。
• モデルカタログの概要：公式のモデルカタログドキュメントを確認する。
• Foundry SDK 開発ガイド：Azure AI FoundryのSDKベースの開発ガイドを探索する。
• モデルデプロイリファレンス：Azure AI FoundryでOpenAIモデルをデプロイする方法を確認する。
• 次のステップのエージェントクイックスタート：Azure AI エージェントのクイックスタートに進む。