Jev と「LLM に JSON を頼む」の違い

2 つの異なる契約

チャットモデルはテキストを書きます。JSON モードや厳格な structured outputs を使っても、スキーマに向かってトークンをサンプリングしていることに変わりはありません — 形状が保証されるだけで、内容は生成されます。Jev は逆の発想です：内容が保証され（宣言した選択肢しか返せない）、モデルが付け加えるのは宣言した選択肢上の確率分布です。これは異なる契約であり、壊れ方も違います。

• JSON モードのチャットモデル：形状は正しく出ますが、宣言していないラベル（"billing" の代わりに "billingx"）を出したり、正規化が不安定になったり、ペイロードを文章で包んだりすることがあります。パーサー、アローリストチェック、リトライループを自分で書くことになります。
• 意思決定モデル：回答空間は送った criteria そのものです。3 選択肢の choice 質問は、その 3 つのうちのちょうど 1 つと、それぞれの確率を返します。生成されたものがないので、パースすべきものもありません。

LLM が本当に強い領域

生成タスク — メールを書く、チケットを要約する、SQL の下書き — はチャットモデルの領域です。より狭いモデルでは代替できません。structured outputs も、分岐の判断ではなくカスタムオブジェクト（ドキュメントから抽出したフィールド）が必要な場合には適しています。そのパイプラインはそのままにしておいてください。

継ぎ目となるのは、今 if (await classify(text) === "billing") となっているコードの行です。その行に必要なのは流れるようなテキストではなく、キャリブレーション済みの確率付きの有界な回答です。

信頼度の問題

チャットモデルに信頼度の数字を尋ねれば、返ってはきます — しかしそれは自分の文章の滑らかさについての自己申告であり、宣言した選択肢の上でのキャリブレーション済み確率ではありません。どちらも「85% 確信」と報告する 2 つの呼び出しが、まったく異なるレジームにあることもあります。意思決定モデルの確率は入力間で比較可能なので、1 つのしきい値（「0.8 未満は人に回す」）を設定して、何十万回もの呼び出しにわたって信頼できます。

具体例で比較する

3 つのキューへの意図分類 — billing、technical、sales — を例にします。

• チャットモデル方式：ラベルを含む 1 つのプロンプトを JSON モードで実行します。コストはシステムプロンプトと、毎回再送する全コンテキストに比例します。迷子のラベルにはアローリストで防御しますが、誤ルーティングは顧客が苦情を言うまで黙ったままです。
• 型付き判断方式：3 つの criteria 説明を付けた choice 質問。短いチケットは入力 300〜500 トークン — 最低 1 クレジット、Starter で $0.0001 です。誤ルーティングは、コードが間違ったラベルを黙って受け入れるのではなく、しきい値を設定できる高エントロピーの確率分布として現れます。

同じプロセスで両方を使う

• 創造性や理解が主眼となる部分では、LLM に自由に生成・抽出させます。
• コードが動く前に狭い質問を Jev に投げます：どのキューか、どのモデルティアか、出荷するかブロックするか。
• どちらの出力も法律・医療・金融上の判断として扱わないでください — しきい値を設定し、重要度の高い経路には人を残します。

本番システムの多くは最終的に両方を使います：繰り返される分岐は Jev、チャットモデルが唯一無二に得意なものはチャットモデルです。

失敗パターンを並べて見る

• 自由記述ラベルのドリフト：LLM は switch が "billing" を期待する場所で "billing-related" を返します。型付きの呼び出しは宣言したキーそのもので確率をインデックスするため、ドリフトは構造的に起きません。
• 幻覚フィールド：JSON モードは頼んでいないキーを追加することがあります。意思決定モデルにはできません — レスポンスのスキーマは質問タイプによって固定されています。
• 無言の誤ルーティング：下流のコードがデフォルトにフォールバックして通ってしまうドリフトのケースです。型付き判断では呼び出しごとに完全な確率分布をログに残し、二峰性のものをレビューできます。
• 信頼度の見せかけ：パースしてから断言する形式（「これが X だと確信します」）— 精密ではなく、キャリブレーションもされていません。Jev の confidence はすべての choice と score の回答に付き、人間レビューの経路を駆動します。

パーサーベースの分類器を移行する

移行は機械的な作業です：チャットモデルにラベルを尋ねるのをやめ、プロンプトで使っていたのと同じ文言のまま、同じ分類体系を choice 質問の criteria に入れます。ラベルを言い直したくなる衝動を抑えてください。既存のプロンプトの文言には、チームが培ってきた区別がすでに符号化されています。2 週間両方に尋ねて一致率をログに取り — 不一致が 2% 以下になったら、いくつかのケースを見てください。結末はいつも同じです：criteria の文言が曖昧だったか、ケース自体が本当に曖昧で、旧システムはどのみち黙って誤ルーティングしていたかのどちらかです。

同じリクエスト、2 つのやり方

同じチケットに対する 2 つの契約の姿は次のとおりです：

system: Classify the support message into billing, technical
or sales. Reply with {"queue": "..."}. Do not invent labels.
user: Charged twice for order A-104, please refund the duplicate.

{
  "state": "Charged twice for order A-104, please refund the duplicate.",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team handles this?",
      "criteria": {
        "billing":  "Payments, payouts, invoicing, refunds",
        "technical": "Bugs, outages, integrations",
        "sales":    "Pricing, upgrades, new accounts"
      }
    }
  }
}

前者は順調なら {"queue": "billing"} を返し、不調なら何を返してもおかしくありません。後者は billing を 0.97 のような確率で、3 選択肢すべての分布と confidence 値とともに返します — しかも失敗の契約は毎回同じです（error.code を含むエラー形状で、もっともらしい間違った回答を返すことは決してありません）。どちらの失敗ならデバッグしたいかで、下流のコードを設計してください。