Jev と LLM

同じ判断を、両方の書き方で

サポートチケットを 4 つのキューのどれかに振り分けます。それぞれの側がコードとして実際に何を要求するかを見てください。

const res = await llm.chat({
  messages: [{ role: "user", content:
    `Route this ticket. Reply with JSON: {"queue": "Billing"|"Technical"|"Account"|"Sales"}
     Ticket: ${ticket}` }],
  response_format: { type: "json_object" }
});

let queue;
try {
  queue = JSON.parse(res.content).queue;        // may not be JSON
} catch {
  return retry();                               // ...so there is a retry
}
if (!QUEUES.includes(queue)) return retry();    // may be a queue you never had
// and no idea how close the call was

const { answers } = await jev.systemOne({
  state: ticket,
  model: "jev-latest",
  questions: { queue: { type: "choice", instructions:
    "Which team should own this ticket?", criteria: QUEUES } }
});

const { choice, probabilities, confidence } = answers.queue;
// choice is one of QUEUES. It cannot be anything else.
if (confidence < 0.7) return humanReview(ticket, probabilities);
route(choice);

リトライループが決め手です。最初の版にそれがあるのは、答えがテキストとして届き、パースできないかもしれず、パースできてもリストになかったキューになりうるからです。2 番目の版では置き場所がありません。構成上、答えは必ず QUEUES のどれかです。代わりに現れるのはまったく別の分岐 — モデルの出力が壊れたときではなく、モデルが_確信を持てない_ときに発火する分岐です。

2 番目の版に見えるもの

あのチケットを実際に Jev に通したものです。勝者に意外性はありません。むき出しのラベルなら捨てていたのは次点のほうです。

技術が 87% で勝ちますが、アカウントが 13% を保持しています。そしてこれは正しい不一致です。SSO の障害は本当に両者の境界にあるからです。むき出しのラベルならこれを隠してしまったでしょう。振り分けを誤るコストがあるなら、13% こそがしきい値を置くべき数字です。

並べて比べる

送るもの

Jev

1 つの state と、型のある質問のマップ。

LLM

プロンプト。たいていスキーマとルールを散文として抱えています。

返ってくるもの

Jev

質問ごとに 1 つの型のある答え。選択肢すべてに確率つき。

LLM

テキスト。丁寧に頼み、そのモードがサポートされていれば JSON。

次の 1 行

Jev

自分の値のどれかにしかなりえない値への switch。

LLM

パースし、検証し、そのどちらかが失敗したときの分岐。

失敗の仕方

Jev

テキストの読み取りを誤ることはあります。定義していない形を返すことはありません。

LLM

形についても誤りえます。欠けたフィールド、並べたことのないラベル、JSON を包む散文。

10 個聞くとき

Jev

10 個の質問を 1 リクエストで、state に対して並列に評価。

LLM

詰め込まれた 1 つのプロンプト、または 10 回の呼び出し。

不確かさ

Jev

すべての Choice と Score に分布と確信度。

LLM

テキストが自分の確信について主張していること、それだけ。

数字

これらは TypeSafe が公表しているもので、ベンダー自身の数字です。こちらの計測ではありません。

こちらで計測できるのは次の点です。このサイトから行われた 14 回の実行で、往復時間の中央値は 329 ms。しかもその大半は 1 問ではなく 9 問を運んだリクエストでした。

LLM のほうが正しい道具であるとき

必要なのが言語であるなら、たいていそうです。Jev には説明できる意見も、語るべきことも何もありません。

• 散文が必要なとき。返信、要約、コミットメッセージ、判断そのものではなく判断の説明。
• コードや計画を書かせたいとき、あるいは呼び出し前に答えの集合が決まっていない自由度の高いもの全般。
• ありうる答えの集合が本当に無限のとき。任意の固有名を抽出するのは 255 個の選択肢に対する Choice ではありません。
• 検証できる推論の連鎖が必要なとき。Jev が返すのは判断であって、その背後の手順ではありません。
• 量が少なく、形もゆるいとき。1 日 2 回動くリトライループを設計で消す価値はありません。

この 2 つは競合するより組み合わさるほうが得意です。TypeSafe 自身の整理も、素早い構造化された判断をシステム 1 が担い、その後ろに普通のモデルをシステム 2 として置くというもの。Noul で入力をふるい、Choice で振り分け、残ったものを本当に書けるモデルに渡す。

続きを読む