Jev を評価モデルに:型付きの判定で LLM の回答を採点する

質問、参照情報、モデルの回答を貼り付けてください。Jev は、回答が参照情報と矛盾していないか、5 段階のルーブリックでどの程度の品質か、公開してよいかを返します。解析が必要な文章ではなく、コードでしきい値を設定できる確率として返ってきます。

自分のテキストで試す

例を編集して実行してください。アカウントは不要で、1 日 3 回まで無料で実行できます。

シナリオ

モデルの回答を参照事実と照らして採点し、出してよいかを判断します。

289 / 2,000

自由に編集できます。ここに入力した内容について、Jev がシナリオの質問に回答します。

この評価モデルがチェックすること

上の例では、サポートボットの回答を、本来参照すべきだったナレッジベースの抜粋と照合して採点しています。1 回の呼び出しで 3 つの質問を尋ねます。

質問型返ってくるもの
correctNoul回答が reference と矛盾しない確率
qualityScoreWrong → Excellent 上の位置と信頼度
verdictChoiceship、revise、reject それぞれの確率

質問が 3 つでも費用は 1 クレジットで、同じ state に対して並列に回答されるため、3 つすべてを尋ねてもレイテンシはほとんど増えません。例の回答は参照情報と矛盾しています(無料プランでは API にアクセスできないと述べています)。そのため注目すべき出力は、correct がどれだけ強く「no」に傾くか、そして verdict が reject と revise のどちらを選ぶかです。

うまく機能する評価用の質問の書き方

Noul 1 つにつき失敗パターンは 1 つ。 「この回答は良いか?」は、正確さ・口調・網羅性を 1 つの確率に混ぜてしまい、それでは行動に移せません。「回答は参照情報と矛盾しているか?」なら意味は 1 つです。気にかけている失敗ごとに Noul を追加してください。たとえば「回答は、ポリシーで認められていないことを約束しているか?」などです。

Noul に基準を与える。 true と false の説明によって、Jev に境界線の位置を伝えられます。

{
  "type": "noul",
  "instructions": "Does `answer` state or imply something that contradicts `reference`?",
  "criteria": {
    "true": "The answer asserts a fact the reference contradicts.",
    "false": "Everything the answer claims is supported by, or absent from, the reference."
  }
}

重大度が重要なら Score を使う。 出力の大半が「部分的に正しい」場合、各レベルに短い説明を付けた 5 段階のルーブリックのほうが、Yes/No よりもうまく回答を順位付けできます。

判断は Choice に任せる。 ship / revise / reject を直接尋ねると、アクションに対する分布が得られます。3 つの数値を自分で組み合わせるより、振り分けが簡単です。残りの 2 つの質問はログ記録としきい値調整に使いましょう。

質問の書き方について詳しくは、Jev が答えられる質問の設計 をご覧ください。

1 回のチェックから採点ステップへ

  1. ラベル付きの例を集める。 人が良い・悪いを判定した実際の回答が 50〜200 件あれば、Jev の確率がそれらをどこで分けるかを確認できます。
  2. しきい値を 1 つではなく 3 つの帯にする。 Jev が確信している回答は通し、中間帯はより強力な評価モデルか人にエスカレーションし、残りはブロックします。公開パイロットでは、このパターンによって Jev 単独でキューの約 80% を処理できました。
  3. モデルバージョンを記録する。 すべてのレスポンスには jev-1.13.0 のような model フィールドが含まれます。判定ごとにこれを記録し、変わったときはしきい値を見直してください。JevStation がモデルを固定するため、リクエストごとに選ぶ必要はありません。
  4. パイプラインから呼び出す。 同じ評価を API Key を使って System One API からも実行でき、プレイグラウンドと同じクレジットが消費されます。

信頼する前に確かめる

  • 例ではなく、自分のラベルと比較する。 他人のデータで機能するしきい値は、あなたのしきい値ではありません。
  • 言い回しをテストする。 Noul とその否定形、あるいは同じ内容を Noul と Choice で尋ねた場合では、異なる確率が返ることがあります。実際にリリースする質問そのものでしきい値を調整してください。
  • 中間帯に注目する。 大半の回答がしきい値の間に入るなら、質問が曖昧すぎます。分割してください。

Jev が評価モデルに向かない場面

  • 書かれた理由が必要な場合。 レビュー担当者向け、監査証跡、採点対象モデルへのフィードバックなどです。
  • 判定に数え上げ、計算、日付が絡む場合。 TypeSafe はこれらを弱点として文書化しています。
  • 採点される側のシステムが評価モデルに問い合わせられる場合。 安価で安定したスコアは、すり抜けるものを探る手がかりになってしまいます。

これらの限界の根拠と、このページで引用したパイロットの数値は、出典付きで 評価モデルとしての Jev:1 つの Yes/No 質問で見抜けること、見逃すこと にまとめています。

よくある質問

Jev は LLM-as-a-Judge の代わりになりますか?
正しいか否か、合格か不合格か、ルーブリックのどのレベルかなど、判定結果を事前に列挙できる場合はなります。Jev は講評や理由を書かないため、説明や自由形式のフィードバックが必要な場面では、生成型の評価モデルを残してください。
評価モデルとしての Jev の精度はどのくらいですか?
現時点で最も参考になる公開テストは、独立した AI コントロールのパイロット検証です。Jev に Yes/No の質問を 1 つだけ尋ねたところ、バックドア入りのコードを正常なコードより上位に順位付けし、AUROC は 0.976 でした。ご自身のタスクでの精度は質問の設計次第なので、しきい値に頼る前に、ラベル付きの自前データで測定してください。
1 回の判定にかかる費用は?
JevStation では、標準の評価は質問が 1 つでも 5 つでも 1 クレジットです。Jev の定価で計算すると、典型的なチェックのトークン費用は約 $0.00002 です。
採点される回答が判定を操作することはできますか?
Jev には指示チャネルがなく、state 内のテキストはコンテンツとして読まれます。公開パイロットでも、評価モデル宛てのメモが悪い出力を救うことはありませんでした。ただし、採点される側のシステムが評価モデルを繰り返し呼び出し、最高スコアの試行を残せる場合は、すり抜け方を学習できてしまいます。評価スコアを採点対象のシステムに公開しないでください。

関連

パイプラインに組み込む

新規登録で 200 クレジットを無料進呈。独自の質問セットを保存し、同じ評価を API から呼び出せます。