Jev を評価モデルに:型付きの判定で LLM の回答を採点する
質問、参照情報、モデルの回答を貼り付けてください。Jev は、回答が参照情報と矛盾していないか、5 段階のルーブリックでどの程度の品質か、公開してよいかを返します。解析が必要な文章ではなく、コードでしきい値を設定できる確率として返ってきます。
自分のテキストで試す
例を編集して実行してください。アカウントは不要で、1 日 3 回まで無料で実行できます。
シナリオ
モデルの回答を参照事実と照らして採点し、出してよいかを判断します。
自由に編集できます。ここに入力した内容について、Jev がシナリオの質問に回答します。
この評価モデルがチェックすること
上の例では、サポートボットの回答を、本来参照すべきだったナレッジベースの抜粋と照合して採点しています。1 回の呼び出しで 3 つの質問を尋ねます。
| 質問 | 型 | 返ってくるもの |
|---|---|---|
correct | Noul | 回答が reference と矛盾しない確率 |
quality | Score | Wrong → Excellent 上の位置と信頼度 |
verdict | Choice | ship、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 回のチェックから採点ステップへ
- ラベル付きの例を集める。 人が良い・悪いを判定した実際の回答が 50〜200 件あれば、Jev の確率がそれらをどこで分けるかを確認できます。
- しきい値を 1 つではなく 3 つの帯にする。 Jev が確信している回答は通し、中間帯はより強力な評価モデルか人にエスカレーションし、残りはブロックします。公開パイロットでは、このパターンによって Jev 単独でキューの約 80% を処理できました。
- モデルバージョンを記録する。 すべてのレスポンスには
jev-1.13.0のようなmodelフィールドが含まれます。判定ごとにこれを記録し、変わったときはしきい値を見直してください。JevStation がモデルを固定するため、リクエストごとに選ぶ必要はありません。 - パイプラインから呼び出す。 同じ評価を 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 から呼び出せます。