スコアリングは、ベンチマークを「JSONを目視で確認する」ものから客観的な数値へと変えます。各モデルの結果はゴールドリファレンス（期待される出力）に対して評価され、完全性、正確性、そして並べ替え可能な総合品質スコアを算出します。
スコアリングには、スコアリングの対象となるものが必要です。各シナリオはリファレンス出力、つまり固定された1つのエンティティに対する正解を保持します。強力なモデルで生成（Web検索＋信頼できる情報源のドキュメント）したり、既知の正しい結果を貼り付けたりして作成し、手作業で編集してください — そして信頼できると判断したら検証済みとしてマークします。検証済みのリファレンスはシナリオをベンチマークするために必須であり、常に評価対象が存在するようにします。後でリファレンスを編集した場合、またはシナリオのスコアリング設定を変更した場合、既存のスコアは再スコアリングするまで古いとしてフラグが立てられます。
リファレンスは自動的に更新もされます。検証済みのリファレンスであっても手作業で修正した下書きにすぎず、ベンチマークするモデルはそのレビュー担当です。ジャッジが候補の回答をリファレンスより優れている(またはリファレンスが誤りである)と判断した箇所、シナリオ自身のサンプルがリファレンスの誤りを証明した箇所、そしてリファレンスが空のままにした値をモデルが埋め、ジャッジがそれを確認した箇所では、結果に検出結果が記録されます。スコアリングパスの終了時には、採点されたすべてのモデルの検出結果が統合され — まずサンプルが証明した内容、次に最も多くのモデルが出した回答 — リファレンスに書き込まれます。あるパスで行われた編集が置き換えられるのはより強い根拠(サンプル、値が誤りという判定、またはパスをまたいで集計された賛同モデル数の多さ)がある場合のみで、モデルが1つ増えただけの意見では置き換えられません。そのため、モデルを1つずつベンチマークしても、最後に採点したモデルの方向へリファレンスが流されることはありません。これらの自動編集によってスコアが古い状態としてマークされることはなく(マークされるのはご自身で保存した場合のみです)、置き換えた内容と指摘したモデルとともに、すべてログに記録されます。
変更履歴として確認できます。シナリオのリファレンスビューでは、結果の隣に、リファレンス本体と各自動編集が該当箇所にハイライト表示されます。取り消し線付きの以前の値、新しい値、支持したモデルの数、そしてその理由が分かります。却下しない限り、すべての変更が採用されます。却下すると以前の値が復元され、そのパスは今後のパスの対象外になります。属性や根拠で絞り込み(モデル1つだけの編集は要確認です)、表示中の項目を選択して一括で却下できます。
中心的な問題:2つの正しい答えでも、書き方が異なる場合があります。俳優を「Robert Downey Jr.」ではなく「R. Downey Jr.」と表記するモデルが間違っているわけではありません。そのため、各フィールドは段階的なラダーで比較されます — 最も安価で確実なものを最初に、必要な場合にのみエスカレーションします:
同一の値は一致します。大文字・小文字、前後の空白、数値の精度のみが異なる値も一致します（「Acme」＝「ACME」、4.0＝4）。無料かつ完全に決定的です。
テキストの場合、候補と参照は埋め込みに変換され、コサイン類似度で比較されます。しきい値を超えると同一とみなされるため、「R. Downey Jr.」と「Robert Downey Jr.」のような正当な表記ゆれはエラーではなく一致となります。日付は例外で、類似度ではなく暦上の値として比較されるため、近いけれど誤った日付（「1972-03-14」と「1972-03-24」）は、見かけ上高いコサイン値ではなく明確な不一致として扱われます。ブール値も同様に、完全一致か不一致かのいずれかです。
類似度だけでは判断が難しい値 — 要約や説明のようなすべての自由記述フィールド、完全に一致しないすべての数値、そしてお客様のドキュメントや他の多くのモデルが裏付ける明らかに異なる値 — は判定モデルに送られます。判定はブラインドで行われます。判定モデルは2つの値をAとBとしてのみ見て、そのフィールドのスキーマ上の位置（親要素とその説明、型、どのリスト項目に属するか）と、シナリオにソースドキュメントがある場合はそのドキュメントを参照し、どちらがそのフィールドにより適しているか、両方とも正しいか、あるいは一方が誤っているかを判断します。リファレンスと同等以上と判定された候補、またはリファレンス自体が誤りと判定された場合は満点となり、劣る回答は部分点、誤った回答はほとんど、あるいはまったく得点になりません。数値は、フィールドが許容する場合には部分点が与えられ（分子量 273.37 と 273.35、半減期 12 と 15 など）、正確さが重要な場合には不正解となります（公開年 2020 と 2023 など）。リファレンスが空のままだった値は個別に判定されます。正しいと確認された場合、それはリファレンスが本来持つべきでモデルが見つけた値としてカウントされ、減点が免除されるだけでなくスコアが上がり、リファレンスにもその値が取り込まれます。
厳密度の設定は埋め込みしきい値を制御します。値が高いほど、異なる書き方の2つの値が同一とみなされるには、より高い類似度が必要になります。厳密度、オプションのジャッジモデル、埋め込みモデルはいずれもシナリオ側で設定され、採点のたびに選ぶわけではありません。そのため、すべてのモデルが同一に採点され、スコアの比較可能性が保たれます。
リスト（映画のキャスト、薬の副作用など）は、モデルによって最も差が出る部分です。小さなモデルが4人の俳優しか見つけられないところで、強力なモデルは15人を見つけることがあります。順序は問題ではなく、正しい項目をより多く見つけたほうが優れています。そのため、配列は位置ごとではなく集合として採点されます:
結果の行を展開すると、どの項目が一致、欠落、またはハルシネーションされたかを正確に確認できます。
単一の数値では隠れてしまう情報が多すぎるため、すべての結果にはサブスコアが付随します：
展開可能な行には、フィールドごとの内訳が表示されます。候補と参照の比較、どの段階（ラング）で判定されたか、そして該当する場合は類似度が示されます。
品質は全体の 3 分の 1 にすぎません。ベンチマークがスコアリングソースとしてモデル選択に使われる場合、モデルの順位は品質・速度・コストを組み合わせて決まり、その比率はお客様が決めます。設定 → 組織 → デフォルトでシナリオタイプごとに設定でき、合計は 100 で、既定では均等に配分されます。コストの比重を大きくすれば、安価でそこそこのモデルが優秀で高価なモデルを上回ります。これはワークロードによって正解にも不正解にもなるため、プラットフォーム側では判断しません。速度とコストは、シナリオ内の他の結果に対して対数スケールで評価されます。最速または最安のモデルが 100 点、10 倍遅い、または 10 倍高価なモデルが 0 点です。ただし、差が小さい場合に無理に範囲いっぱいまで引き伸ばすことはありません。$10 と $12 の 2 モデルは 100 点と 0 点ではなく、100 点と 92 点になります。
scenarioが同じmodelを複数回（繰り返し）実行する場合、各実行は個別に採点され、行には平均品質と一貫性の幅（各実行の最低〜最高）が表示されます。これにより、平均的には正しくても挙動が不安定なmodelを簡単に見分けられます。表示される出力は品質で中央値となる実行です。
ベンチマークはエンリッチメントに限りません。シナリオではサンプル生成（各モデルが同じ自由記述リクエストに対して例のJSONを考案）やスキーマ生成（各モデルが固定のサンプルをスキーマに変換）もテストできます。それぞれに独自の採点ルールがあります：
いずれの場合も、おなじみの列は同じ意味を保ちます。列ヘッダーにカーソルを合わせるとタイプ別の定義が表示され、行を展開すると詳細な内訳が表示されます。
スコアリングは保存済みの結果に対する独立したパスです。再エンリッチメントは行わないため、評価対象モデルの費用が再度発生することはありません。ただし値を比較するためにテキストの埋め込みを行い（シナリオにジャッジが設定されていればジャッジも実行します）、これにより使用量に応じてクレジットが消費されます。これはすべての実行中に自動的に行われ（各モデルは実行が完了し次第スコアリングされます）、再スコアリングのたびに再度実行されます。組織に埋め込みモデルが設定されていない場合（かつシナリオで上書き指定もない場合）、スコアリングは実行されますが完全一致のみにフォールバックし（表記ゆれは不一致として扱われます）、その旨が表示されます。ジャッジの失敗は扱いが異なります。ジャッジの呼び出しが失敗すると、スコアリングは明示的なエラーで停止し、該当モデルに部分的なスコアは残りません。結果は完全にスコアリングされるか、まったくスコアリングされないかのいずれかで、後から再スコアリングできます。ジャッジの回答は内容に基づいてシナリオ単位でキャッシュされます。別のモデルから同じ質問が出された場合も、繰り返しやパスが重なった場合も、料金が二重に発生することはありません。また、リファレンスが自動更新された後の再スコアリングでは、編集されたフィールドに関する質問のみが再度行われます。 ジャッジの動作はすべて公開されています。モデルに対するスコアリング処理は必ず履歴にスコアリングレコードを残します。ジャッジ呼び出しごとに 1 行で、プロンプト・回答・トークン・コストが記録され、失敗した呼び出しも含まれます。さらに、キャッシュが無償で回答した質問数も確認できます。結果テーブルには、各モデルのジャッジコスト・呼び出し回数・スコアリング時間が、そのレコードへのリンクとともに表示されます。 判定モデルを選ぶ際は、LLMの判定モデルが自身のモデルファミリーを優遇する傾向がある点に注意してください。ベンチマーク対象に含めていないプロバイダーの判定モデルを選ぶことをおすすめします。
モデル管理 → ベンチマークのシナリオエディタでリファレンスを設定して検証します（ジャッジモデル、埋め込みモデル、厳密度もここで選択します）。以降はすべての実行で成功した結果が自動的にスコアリングされ、並べ替え可能な品質列が追加の操作なしで埋まります。リファレンスやスコアリング設定を編集した後に再評価するには、結果を再スコアリング（ヘッダーのボタンまたは···メニュー）を使用します。リファレンスのステータス横にあるリファレンス更新バッジから、スコアリングパスによる変更のログを開き、エントリごとに取り消せます。