Hugging Faceモデルのリポジトリコード変更を再現可能な方法で評価する

評価のポイント：モデルはテスト済みのリポジトリ変更を作成できたか？

リポジトリのコード変更を評価するなら、モデルに期待する一連の作業を評価しましょう。リポジトリの状態を理解し、パッチを提案し、関連するテストに合格することです。コード補完のスコアや見栄えのよい差分だけでは、その変更が実際の文脈で機能するとは判断できません。

実用的な比較では、各モデルに同じ未使用の課題、リポジトリの状態、プロンプトテンプレート、生成設定を使います。少なくとも次の2つの結果を分けて評価してください。出力をパッチとして適用できたか？、選定したテストに合格したか？ どちらの結果も、それだけで変更が正しい、または安全であることを証明するものではありません。

これは、ベンチマークに関するHugging Faceコミュニティの議論で示された基本的な考え方に沿っています。対象タスクを起点にし、同じ設定でモデルを比較し、失敗例を確認し、公開ベンチマークはタスク固有の改善を証明するものではなく補助的な評価として扱う、という考え方です。また、このスレッドでは、ほかの人が評価を再現できるよう、設定の詳細を記録することも推奨されています。出典：Hugging Faceコミュニティの議論「What’s your method for benchmarking?」

1. 未使用のリポジトリ課題を作成する

各課題には、リポジトリのコミット、簡潔な課題説明、テストコマンドまたは明示的な受け入れ確認方法を含めます。評価用の課題は、モデルの学習やプロンプト調整に使わないでください。同じ課題で繰り返しプロンプトを調整すると、その課題は開発用の例になり、独立した評価セットではなくなります。

関心のある変更を反映した課題を選びましょう。一般的なバグ修正、エッジケース、複数ファイルにまたがる変更、情報が足りないと報告するのが適切なケースなどです。意図した動作と既存の動作を区別できるテストがある課題を優先してください。既知の不足も記録します。テストスイートがセキュリティ、パフォーマンス、互換性、またはすべての回帰を網羅しているとは限りません。

各課題を再構成できるよう、マニフェストを用意します。

モデルごとにリポジトリの状態を気づかれないように変えてはいけません。リポジトリのライセンスやプライバシー要件を守りながら、マニフェストと課題入力を評価結果とともに保存します。

2. Hugging Faceモデルと生成設定を固定する

指定が変わり得る参照先ではなく、特定のモデルリビジョンを使用します。モデルID、リビジョン、Transformersのバージョン、トークナイザーとチャットテンプレート、ハードウェア、アダプターやマージ済み重み、量子化の使用有無を記録します。こうした選択によってモデルの動作が変わる場合があります。

次の例は、Transformersを使ってパッチ案を1つ生成するための説明用・未テストの設定です。プレースホルダーを置き換え、実行前にモデルが対応するアーキテクチャとチャットテンプレートを確認してください。これはテキストを生成するだけで、パッチの適用やテストは行いません。

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = "YOUR_HUGGING_FACE_MODEL_ID"
revision = "YOUR_PINNED_REVISION"

messages = [
    {
        "role": "user",
        "content": (
            "Given this repository context and issue, return a unified diff only. "
            "Do not claim tests passed.\n\n"
            "Repository context:\nYOUR_FIXED_REPOSITORY_CONTEXT\n\n"
            "Issue:\nYOUR_HELD_OUT_ISSUE"
        ),
    }
]

tokenizer = AutoTokenizer.from_pretrained(model_id, revision=revision)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    revision=revision,
    torch_dtype="auto",
    device_map="auto",
)

inputs = tokenizer.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_tensors="pt",
).to(model.device)

with torch.inference_mode():
    output = model.generate(
        inputs,
        do_sample=False,
        max_new_tokens=1200,
    )

new_tokens = output[0, inputs.shape[1]:]
print(tokenizer.decode(new_tokens, skip_special_tokens=True))

貪欲デコード（do_sample=False）を使うと、ばらつきの原因のひとつであるサンプリングをなくせます。ただし、あらゆるハードウェア、ライブラリ、カーネルで同一の出力が得られる保証はありません。正確な環境を記録してください。想定するワークフローでサンプリングを使う場合は、シードとサンプリングパラメーターを固定して記録し、出力のばらつきを把握する必要があれば複数回実行します。この例の設定があらゆるモデルに適しているとは限りません。

3. パッチを分離した環境で適用し、テストする

課題とモデルの各組み合わせについて、記録したコミットからクリーンなチェックアウトを用意します。解析する前に、モデルの生出力を保存します。使用可能な差分が含まれているかを検証し、使い捨てのworktreeまたはコンテナに適用して、事前に定めたテストコマンドを実行します。モデルの生成とテスト実行を分けることで、パッチの失敗をインフラやテストランナーの失敗と取り違えないようにします。

各結果を個別に記録します。

テストコマンドに合格したことは、記録された環境で選定したテストに合格したことを示します。それらのテストを超えて正しさを証明するものではありません。テスト環境のセットアップ失敗はモデルの失敗と分けて報告し、実行していないテストを合格として数えないでください。

4. 回帰を見えにくくせずにモデルを比較する

ベースラインモデルと候補モデルには、同じ課題、リポジトリのスナップショット、プロンプトを使います。課題数、パッチ適用率、テスト合格率、確認した課題数を報告してください。平均だけではなく、課題ごとの結果や失敗の概要も含めます。モデルによっては、限られた種類の修正で改善する一方、書式、変更範囲の制御、別の課題群では後退する場合があります。

評価セットが小さい場合、結果は一般的な順位ではなく、そのセットにおける結果として説明します。出典の議論では、小規模なセットのスコアは変動し得るため、複数回の実行が重要になる場合があると述べられています。出力に確率的なばらつきがある場合は、シードを記録したうえで複数回実行し、変動を報告してください。生成が決定的であっても、課題数が少ないときに広範な結論を出すのは慎重にしてください。

5. 結果とともに評価の限界も公開する

再現可能なレポートには、モデルとリビジョン、リポジトリのコミット、課題の選定方法、除外項目、プロンプト、生成パラメーター、ソフトウェアとハードウェアの環境、パッチパーサー、テストコマンド、採点ルールを含めます。評価対象外の項目も明記します。たとえば、テストされていない回帰、コードレビューの品質、セキュリティ特性、レイテンシ、パフォーマンスなどは、実測していない限り評価したとは言えません。

有用な結論は具体的です。記録した設定のもとで、今回の未使用のリポジトリ課題に対し、モデルはこのような適用結果とテスト結果を示すパッチを生成しました。 実際に知りたいのが、自分たちのコードベースでモデルが検証済みの変更を作れるかどうかであれば、これはリーダーボードのスコアよりも参考になります。