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