概要
GitHub Models に含まれる簡単な評価ワークフローを使うと、開発者は、GitHub プラットフォーム内で大規模言語モデル (LLM) を比較し、プロンプトを調整して、データ主導の意思決定を行うことができます。 GitHub Models の構造化された評価ツールを使って、パフォーマンス、正確さ、コストを分析し、新しい機能を試したり、モデルの変更を検証したりできます。
ヒント
gh models eval コマンドを使うと、コマンド ラインから評価を直接実行できます。 UI と同じエバリュエータ (文字列一致、類似性、ジャッジとしてのカスタム LLM エバリュエータなど) が使われるため、.prompt.yml ファイルをローカル環境または CI でテストできます。
GitHub Models のユース ケース
モデルの動作は、プロンプト、入力、または構成によって大きく異なる場合があります。 GitHub Models は、次の場合に役立ちます。
- 現実的なユース ケースについて複数の LLM をテストして比較する。
- プロンプトの表現、温度、その他のパラメーターを最適化する。
- 構造化された反復可能なメトリックを使って、モデルの出力を評価する。
- AI 開発を開発ワークフローに統合する。
シナリオ例
サポート チケットを通じて送信された顧客フィードバックを要約する機能を構築するシナリオについて考えます。 これらの要約は内部レポートとチケットの生成に使われるため、出力は明確で、関連性があり、簡潔である必要があります。
目的:
- さまざまなモデルとプロンプトの構成を試します。
- 品質、一貫性、効率性に基づいて、パフォーマンスが最もよい構成を評価します。
- 再利用と共同作業のために構成をリポジトリに保存します。
プレイグラウンドでのプロンプトのテスト
GitHub Models でのプロンプトの作成と管理方法について詳しくは、プレイグラウンドでのプロンプトのテストに関する記事をご覧ください。
プレイグラウンドを使うと、モデルを並べて比べたり、パラメーターを調整したり、プロンプトのバリエーションをテストしたりできます。
このステップでは、カスタマー サポート フィードバックの要約を生成するようにモデルを構成します。 システム プロンプトを定義し、サンプル入力でテストして、簡潔で関連性がある出力になるように調整します。
システム プロンプトの定義
現在の目標に対するモデルの動作を定義します。 この場合の目標は、顧客からのフィードバックを要約することです。 [Parameters] で次のシステム プロンプトを入力します。
You are a helpful assistant that summarizes support ticket responses into concise summaries.
それ以外の設定は既定値のままにします。
ユーザー プロンプトの作成
モデルが設定されたので、[Prompt] ダイアログに次の顧客フィードバックを入力します。
The app crashes every time I try to upload a PDF from my phone. It works on desktop but not on mobile.
次に示すのはモデルによって生成される応答の例です。
The user experiences consistent app crashes when attempting to upload a PDF from their phone. Uploading PDFs works normally on desktop. They request an investigation into the issue.
入力変数の定義
この状態で、構成によって明確で簡潔な要約が生成されます。 [Parameters] 設定の下部にある [Create prompt.yml file] をクリックして、プロンプト ビューを開きます。 システム プロンプトが自動的に事前入力されます。
[User prompt] フィールドに、次のプロンプトを入力します。
Summarize the following: {{input}}
{{input}} 変数は、プロンプトを毎回変更することなく、さまざまな入力 (顧客からのフィードバック) をテストできるプレースホルダーとして機能します。 比較の実行時に、追加した各テスト入力で {{input}} が置き換えられます。
テスト入力の追加
プロンプト ビューの上部にある [Compare] を選んで、比較ビューに切り替えます。 このビューを使うと、複数のプロンプトまたはモデルに対して構造化された比較を実行し、エバリュエータを適用してパフォーマンスを測定できます。
比較ビューのテーブルの各行は、特定の入力と期待される出力を含む 1 つのテスト ケースを表します。 各列には、エバリュエータを使ってさまざまなモデルまたはプロンプト スタイルの実行方法を比較するための異なるプロンプト構成が表示されます。
[Add rows] をクリックして、テスト データを入力します。 入力は実際のサポート メッセージをシミュレートし、期待される出力はモデルが返す必要がある理想的な要約を表します。 次の表は、テスト入力のサンプルと、評価のための期待される出力を示したものです。
| 行 | 入力 | 想定される出力 |
|---|---|---|
| 1 | 携帯電話から PDF をアップロードしようとするたびにアプリがクラッシュします。 デスクトップでは動作しますが、モバイルでは動作しません。 | ユーザーは、PDF をアップロードしようとするたびにモバイル アプリはクラッシュしますが、デスクトップ バージョンは問題なく動作することを報告しています。 |
| 2 | 2 日前にサポートに問い合わせましたが、まだ連絡がありません。 アカウントの回復に関するサポートがすぐにでも必要です。 | ユーザーはサポートの対応を待っており、アカウント回復の支援を緊急に必要としています。 |
| 3 | ダーク モードを追加してください。 夜間の使用がとても困難です。 長く使うと目が痛くなります。 | ユーザーは、夜間使用時の目の疲れのためにダーク モードを要求します。 |
モデル パラメーターの調整
新しいプロンプト構成を追加するには、テーブルの右側にある をクリックします。
新しいプロンプト構成では、モデルを更新し、使用できるパラメーター設定を使ってその動作を微調整できます。 これらの設定は、モデルがテキストを生成する方法 (長さ、ランダム性、繰り返しなど) を制御します。
モデルの構成
[Model] ドロップダウンから PHI-4 を選んで、比較用の個別の構成を作成します。
次のパラメーターを調整して、モデルの出力に影響を与えることができます。
- Max Tokens: モデルが返すことのできるトークンの最大数を設定します。 値を大きくすると、出力が長くなります。
- Temperature: 応答のランダム性を制御します。 値を小さくすると (0.2 から 0.4)、より対象が絞られた確定的な出力が生成されます。 値を大きくすると (0.8 から 1.0)、創造性が高くなり、より多くのバリエーションが生成されます。
- Top P: 最も可能性の高い次の単語のプールから選ぶことで、出力の多様性を制御します。 値を小さくすると、温度を下げるのと同様に、ばらつきが低下します。
- Presence Penalty: モデルによる新しいトピックの導入を抑制します。 値が大きいほど、より強力なペナルティが適用されます。 通常、要約には値 0 が適しています。
- Frequency Penalty: 単語が繰り返される可能性を減らします。 値が大きいほど、より強力なペナルティが適用されます。 0 から 0.5 の値は、要約を明確に保ち、冗長性をなくすのに役立ちます。
- Stop: それが生成されたらモデルの応答を遮断する 1 つ以上の文字列を指定します。 過度に長い出力を防いだり、書式設定規則を適用したりするには、これを使います。
次に示す表は、モデルの比較で簡潔な要約を生成するためのパラメーター構成です。
| パラメーター | 値 | 理由 |
|---|---|---|
| 最大トークン | 128 | 応答を短くし、トピックから逸れないようにします |
| 気温 | 0.3 | 確定的で焦点を絞った出力になるようにします |
| 上位 p | 1.0 | 完全なボキャブラリを許可しますが、ガイドされた選択を維持します |
| プレゼンス ペナルティ | 0 | ペナルティなし: 要約にはトピックのバリエーションは必要ありません |
| 周波数ペナルティ | 0.3 | 表現の繰り返しを減らしてコンパクトな要約にします |
| 阻止 | (省略可能) | キーワードまたは記号の後で出力を終了したい場合に使います |
パラメーターを適用した後、列を追加して、さらに多くのモデルやプロンプト構成を並べて比較できます。
出力の評価
プロンプトを構成したら、構造化された評価を実行し、実際のデータと反復可能なメトリックを使ってモデルの出力を比較します。
モデルの評価は、実際の入力に対してさまざまなモデルとプロンプト構成がどのように実行されるのかを理解するのに役立ちます。 プロンプト ビューでは、複数のモデルを並べてエバリュエータを適用し、類似性、関連性、ラウンデッドネスなどのメトリックを確認できます。
次のエバリュエータを使用できます。
- Similarity: モデルの出力が期待または参照の応答とどの程度一致するかを測定します。 これは、モデルが既知の結果と一致する一貫性のある正確な応答を返すかどうかを確認する場合に役立ちます。 スコアの範囲は 0 から 1 で、値が大きいほど類似性が高いことを示します。
- Relevance: 応答で質問がどの程度有効に対処されているかを示します。 所定の情報のみに基づいて、応答の正確性、完全性、および直接的な関連性を評価します。 スコアの範囲は 0 から 1 で、値が大きいほど入力の意図との整合性が強いことを示します。
- Groundedness: 提供されたコンテキストに応答がどの程度結びついているかを測定し、そのコンテキストのみに基づいて関連性、正確性、完全性を評価します。 応答が、関連性のない情報や正しくない情報を含むことなく、どの程度完全に質問に対処しているかを評価します。 スコアの範囲は 0 から 1 で、値が大きいほど正確性が高いことを示します。
- Custom prompt: ある LLM に対する独自の評価基準を定義して、別の LLM の出力を評価できます。 これにより、独自のガイドラインに基づいてモデルの出力をスコア付けできます。 合格か不合格か、またはスコアによる評価のいずれかを選ぶことができ、標準のメトリックではテストの期待値がわからないシナリオに最適です。
評価の準備ができたら、[Run] をクリックし、すべてのプロンプト構成の出力を生成して比較します。 実行が完了すると、GitHub Models に各プロンプト構成からの出力とエバリュエータのスコアが表示されます。
テスト ケース: PDF のアップロードのクラッシュ
入力: The app crashes every time I try to upload a PDF from my phone. It works on desktop but not on mobile.
次の表は、各モデルの出力とそのエバリュエータ スコアを示したものです。
| モデル | 出力 |
|---|---|
| GPT-4.1 | ユーザーは、モバイルから PDF をアップロードするとアプリがクラッシュしますが、デスクトップではアップロードが動作すると報告しています。 |
| DeepSeek-R1 | |
| Phi-4 | アプリは、モバイル デバイスから PDF をアップロードしようとするとクラッシュしますが、デスクトップ バージョンでは正しく機能します。 |
| モデル | Similarity | 関連性 | グラウンデッドネス | 入力トークン | 出力トークン | Latency |
|---|---|---|---|---|---|---|
| GPT-4.1 | 100% | 50% | 100% | 61 | 20 | 918 ミリ秒 |
| DeepSeek-R1 | 50% | 50% | 75% | 52 | 128 | 2285 ミリ秒 |
| Phi-4 | 75% | 100% | 100% | 61 | 66 | 1117 ミリ秒 |
表面的な表現のレベルより詳しく応答を評価および比較するには、エバリュエータのスコアを使います。
Similarity
各モデルの出力が期待される要約とどの程度一致しているかを評価します。 次の表は、各モデルの関連性スコアを示したものです。
| モデル | 類似度スコア |
|---|---|
| GPT-4.1 | 100% |
| DeepSeek-R1 | 50% |
| Phi-4 | 75% |
入力からの重要な内容はすべてのモデルに含まれていましたが、DeepSeek-R1 の類似性スコアは、その冗長な内部的解説が期待される簡潔な要約形式から逸脱していたため、大幅に低くなっています。 これに対し、GPT-4.1 の応答は、参照出力の表現および構造と一致しています。
関連性
各モデルが入力の主要な意図をどの程度適切に把握しているかを評価します。 次の表は、各モデルの関連性スコアを示したものです。
| モデル | 関連性スコア |
|---|---|
| GPT-4.1 | 50% |
| DeepSeek-R1 | 50% |
| Phi-4 | 100% |
3 つのモデルすべてで、モバイルでの PDF のアップロード中にアプリがクラッシュするという主要な問題が認識されていました。 Phi-4 は、ユーザーの視点をより完全に反映しているため、高い関連性スコアを獲得しました。 DeepSeek-R1 は、元の入力では触れられていない技術的な原因を推測しているため、ポイントを失いました。
グラウンデッドネス
各モデルの出力が入力に忠実に従っており、サポートされていない情報を盛り込んでいないかどうかを評価します。 次の表は、各モデルの関連性スコアを示したものです。
| モデル | グラウンデッドネス スコア |
|---|---|
| GPT-4.1 | 100% |
| DeepSeek-R1 | 75% |
| Phi-4 | 100% |
DeepSeek-R1 では内部的な解説が追加されていますが、ありもしない事実が盛り込まれてはいません。 その最終的な要約文は、元の入力を正しく反映しています。
テスト ケース: ダーク モードの要求
入力: Please add dark mode. It's very hard to use at night. My eyes hurt after prolonged use.
次の表は、各モデルの出力とそのエバリュエータ スコアを示したものです。
| モデル | 出力 |
|---|---|
| GPT-4.1 | ユーザーは、アプリを夜間に使うと不快で目が疲れるため、ダーク モード機能の追加を要求しています。 |
| DeepSeek-R1 | |
| Phi-4 | お客様は、夜間に製品を使用する際の目の疲労を軽減するために、ダーク モード機能の追加を求めています。 |
| モデル | Similarity | 関連性 | グラウンデッドネス | 入力トークン | 出力トークン | Latency |
|---|---|---|---|---|---|---|
| GPT-4.1 | 100% | 75% | 100% | 57 | 18 | 1286 ミリ秒 |
| DeepSeek-R1 | 50% | 0% | 25% | 49 | 128 | 1946 ミリ秒 |
| Phi-4 | 100% | 75% | 100% | 58 | 20 | 899 ミリ秒 |
Similarity
各モデルの出力が期待される要約とどの程度一致しているかを評価します。 次の表は、各モデルの関連性スコアを示したものです。
| モデル | 類似度スコア |
|---|---|
| GPT-4.1 | 100% |
| DeepSeek-R1 | 50% |
| Phi-4 | 100% |
入力からの重要な内容はすべてのモデルに含まれていましたが、DeepSeek-R1 の類似性スコアは、その冗長な内部的解説のため、やはり大幅に低くなっています。
関連性
各モデルが入力の主要な意図をどの程度適切に把握しているかを評価します。 次の表は、各モデルの関連性スコアを示したものです。
| モデル | 関連性スコア |
|---|---|
| GPT-4.1 | 75% |
| DeepSeek-R1 | 0% |
| Phi-4 | 75% |
GPT-4.1 と Phi-4 はどちらも、夜間の目の疲れを減らして使いやすくするためのダーク モードの必要性というユーザーの要求の主な意図を把握していました。 DeepSeek-R1 は、実際の出力から注意を逸らす冗長な内部的解説のため、関連性スコアが 0% になりました。
グラウンデッドネス
各モデルの出力が入力に忠実に従っており、サポートされていない情報を盛り込んでいないかどうかを評価します。 次の表は、各モデルの関連性スコアを示したものです。
| モデル | グラウンデッドネス スコア |
|---|---|
| GPT-4.1 | 100% |
| DeepSeek-R1 | 25% |
| Phi-4 | 100% |
DeepSeek-R1 は、元の入力に存在しない勝手な推測を含む冗長な <think> ブロックのため、スコアが低くなりました。
構成を保存する
評価が済んだら、最後のステップとして、特定のユース ケースに最適なモデルを選びます。 上の例では、Phi-4 と GPT-4.1 は、すべてのエバリュエータについて強力で一貫した結果を提供しました。 DeepSeek-R1 は、推測が冗長で、焦点が散漫なため、スコアが低くなりました。
望ましいモデルとプロンプト構成を選んだら、プロンプト ファイルにわかりやすい名前を付けて、[Commit changes] をクリックします。 これにより、モデル、プロンプト、パラメーター設定、関連するデータセットが、再利用可能な構成ファイルとしてリポジトリ内に保存されます。
![変更をコミットするボタンのスクリーンショット。 [Commit changes] ボタンが強調されています。](/http/77726476706e69737468656265737421f4f8428f69376144761d8be29b5a2e/assets/cb-7631/mw-1440/images/help/models/github-models-commit-changes.webp)
プロンプト構成をコミットすると、モデルのセットアップ間での再利用、共同作業、反復処理が容易になります。 これにより、評価の再実行と、プロンプト構成のパフォーマンスの経時的な追跡が、いっそう簡単になります。