jevals：LLM審査員の代わりに型付き判定を使うエージェント評価

jevalsのREADMEが述べていること

jevalsは、GitHubのopenlayer-aiで公開されているオープンソースのPythonライブラリです。READMEは「エージェント向けのevalとガードレール」と説明し、LLM審査員ではなくJev型の判定モデルを使う点を強調しています。主張の中心はコストと速度です。1つのエージェントトレースに対するすべてのevalが、1回のリクエストにまとめて送られます。READMEによると、そのリクエストの費用は1セントの数千分の1で、応答は数百ミリ秒で返ります。そのためすべてのトレースに対して実行でき、エージェントのループの中でも使える、というのがREADMEの言い分です。

この記事はREADMEだけを根拠にしています。ツールをインストールしたことも、実行したこともありません。以下の数字はすべて作者自身の主張です。READMEが自ら「推定」や「例示」と記している箇所は、その旨を明記します。

READMEにある主な事実

モデルの考え方。 READMEによると、Jevはテキストを生成しません。状態と、型付きの質問(はい/いいえ、選択肢から1つ、ルーブリックによる採点)を渡すと、1回の順伝播で各質問に対して較正済みの確率を返します。質問は互いに独立に並列で評価されるため、40個尋ねても、1個尋ねるのとほぼ同じ待ち時間で済みます。価格は入力100万トークンあたり0.042ドルで、出力トークンはなし。Vercelのゲートウェイ経由で、1リクエストあたりp50が244ms、p95が371msと測定されています。 クイックスタート。 `evaluate()`を1回呼び、メッセージとツールのスキーマ、そして`ToolChoice`、`UsedToolResult`、`Grounded`、`StayedInScope`、`AnswerRelevancy`、`Completeness`、`IndirectInjection`、`PHI`のようなevalオブジェクトのリストを渡します。READMEは、8つのevalが1回のHTTPリクエストで済み、1,388トークン、0.00006ドル、0.33秒だったと報告しています。 バックエンド。 ライブラリは環境変数からバックエンドを選びます。選択肢は、`TYPESAFE_API_KEY`によるJevへの直接接続(READMEによれば現時点ではウェイトリストへの参加が必要)、Vercel AI Gateway経由のJev、セルフホストのKev、Apple Silicon上でプロセス内実行するLaya、そしてOpenRouter経由の通常のチャットLLMです。最後のものは、確率を返すようプロンプトで頼むことでエミュレートします。READMEは、バックエンドを切り替えたら`jevals calibrate`をもう一度実行するよう注意しています。確率はモデルをまたいでは揃わないためです。 evalの一覧。 READMEは、エージェント系(`ToolChoice`、`Grounded`、`StayedInScope`、`LoopDetection`、`GoalCompletion`、`ToolCallRisk`など)、セキュリティ系(`PromptInjection`、`IndirectInjection`、`Jailbreak`、`PII`、`PHI`、`SecretsExposure`など)、Ragas風の品質指標(`Faithfulness`、`AnswerRelevancy`、`ContextPrecision`、`ContextRecall`など)を挙げ、合計37個のevalがあるとしています。

ベンチマーク表。 READMEは、小さなRAGデータセットの同じ20行でjevalsとRagasを比較しています。測定日は2026-09-20です。gpt-4.1-miniを使うRagasは、1サンプルあたりLLMリクエスト6.0回と埋め込み、1,000サンプルあたり約2.60ドル、20サンプルで22〜35秒です。Jevを使うjevalsは、1サンプルあたり1.0リクエスト、1,000サンプルあたり約0.03ドル、0.8秒です。gpt-4.1-miniでJevをエミュレートしたjevalsは、1.0リクエスト、1,000サンプルあたり0.46ドル、4秒です。Kev-4BとLayaの行は推定値と明記されています。実測した3行では、faithfulnessが0.90〜0.92、context precisionとrecallが1.0で一致しました。

evalとゲートの仕組み

evalは3つのメソッドを持つクラスです。`state()`はモデルに見せる内容を選び、`questions()`は何を尋ねるかを決め、`reduce()`は返ってきた確率をスコアに変えます。複数のevalを`evaluate()`に渡すと、READMEによれば状態が統合され、質問は1つのリクエストにまとめられます。evalはサンプルだけに依存するので、同じクラスをオフラインの指標、本番トレースの監視、エージェント内部のゲートのいずれにも使えます。

ゲートは、eval1つとポリシー1つの組み合わせで、回答を許可、エスカレーション、ブロックのいずれかに対応づけます。READMEにはツール呼び出しのリスクを扱うYAMLのゲートが示されています。`action.approve >= 0.85`かつ`grounded >= 0.7`なら許可、`action.block >= 0.6`ならブロック、それ以外はエスカレーションというポリシーです。接続例として、OpenAI Agents SDK、素のasyncループ、LangGraph、Claude Agent SDKの`PreToolUse`フックが示されています。再試行してもバックエンドが復旧しない場合、ゲートは既定で呼び出しを通します。取り消せない操作の前では`on_error="block"`を指定して逆にできます。

PIIとPHIについて、READMEは2段階の方法を説明しています。まずエンティティを検出し、次にモデルへ1つ質問します。これは特定できる個人の健康情報なのか、それとも問い合わせ用のメールアドレスなのか、という質問です。READMEは、エンティティ検出だけではこの2つを区別できず、それがPII誤検知の大半の原因だと述べています。

背景と私たちの読み

*この節は私たちの分析であり、READMEの内容ではありません。* LLM審査員とは、汎用のチャットモデルに出力を採点させる方法で、通常は推論と JSON の回答を求めるプロンプトを使います。READMEの論点は、審査員が下す判断の大半は3種類の質問に収まり、最終的に手元に残るのはラベルだという点です。小さなモデルが1回の計算で確率つきのラベルを返せるなら、はるかに高い頻度で回せます。これはevalの使い道を変えます。夜間のサンプリングが全トレースへのチェックになり、全トレースへのチェックがリクエストの経路に入ることもできます。

READMEはばらつきにも触れています。LangChainの比較を引用し、同一トレースでGPTとClaudeの審査員のスコア分散はJevの92倍から913倍だったとしています。私たちはその記事を読んでいません。また、確率は文章と違ってしきい値を決められるので、操作ごとにトレードオフを調整できます。READMEの`jevals calibrate`の例は、しきい値ごとの「誤って通した割合」と「通し損ねた割合」を並べており、返金と照会が同じしきい値を共有すべきではないとして、モデルごとではなく操作ごとにしきい値を決めるよう勧めています。

READMEの例が示す、複数の指標を回す意味も見ておきます。ツールは今日の予報しか返していないのに、エージェントは「今週はずっと晴れ」と答えました。`grounded`はこの文にp=0.05を付け、`answer_relevancy`は0.84のままでした。READMEは、RAG型の指標だけならこのトレースは通っていただろうと結論づけています。

限界と未解決の点

READMEは自らの限界について率直です。プロジェクトはalphaで公開から1週間、土台のモデルも1週間だと書かれています。TypeSafeへの直接バックエンドは、文書化された通信形式に合わせて書かれ、モックに対してテストされただけで、まだ実際には動かしていません。フレームワークのアダプターもSDKのドキュメントに沿って書かれ、偽物に対してテストされています。表のKevとLayaの行は、それぞれのモデルの作者が公表した数字から掛け算した推定です。出力例のいくつかには「Illustrative output」、つまり例示の出力というラベルが付いています。さらにREADMEは、テストセットの生成はせず、ダッシュボードもなく、多段階の推論や文章での講評が必要な仕事ではLLM審査員の代わりにならないと述べています。

精度について、READMEは独立したベンチマークJevBenchを引用しています。分類タスクでのJevの精度は最小クラスのLLMと同程度(Banking77とCLINC150で83〜87%)で、較正の出来はタスクによって異なるとのことです。LangChainの評価で500回の繰り返しにわたり人間と100%一致し、Claudeは80%だったという結果は、5件のトレースでの話だとREADMEは注記しています。また、ある実行中にゲートウェイが一部の接続で止まり、その実行のp95が1分になったものの、クライアントが再試行して実行は完了したとも報告されています。 READMEにはささやかな不整合も見つかりました。冒頭の例は8つのeval、1,388トークン、0.33秒ですが、長いほうの例は9つ、1,423トークン、0.50秒です。本文は「100分の6セント」と書いていますが、表示されている費用は0.00006ドルで、これは1,000分の6セントにあたります。別々の実行に由来する表現上のずれに見え、深刻な問題ではありませんが、数字は自分で測り直すべきだという注意になります。 私たちの読みでは、節約の大きさは、自分の質問が3つの型に収まるかどうかと、データが表に使われた小さなサンプルに似ているかどうかで決まります。最も鋭い注意はREADME自身が書いています。分類器を認可者にしてはいけない、ということです。返金を実行すべきかどうかは、モデルには見えないアカウントの状態や権限に左右されます。

読者への実用的な示唆

1. すでに一部のトラフィックにLLM審査員を使っているなら、READMEのLLMエミュレーション用バックエンドが、このAPIを試す最も手軽な方法です。READMEは、今日から使えるが、返る確率は較正済みの値ではなく0.00か1.00になると述べています。2. 自分のトレースの一部にラベルを付け、`jevals calibrate`を実行してから、しきい値を信頼してください。READMEは、較正用のデータが最も役に立つ貢献だと述べています。3. 取り消せない操作には人間を置き、その前段のゲートには`on_error="block"`を指定してください。4. READMEの書き方のコツに従います。

1つの質問では1つのことだけ尋ねる。選択肢は名前だけでなく説明を付ける。状態は小さく保つ。状態に答えがない可能性があるときは「証拠不十分」の選択肢を加える。5. フレームワークのアダプターは、誰かが実際に動かすまで粗い部分が残るものとして扱い、コスト表は作者の主張として扱ってください。計画に組み込む前に、自分のトレースで比較をやり直してください。