Jev の state

有効な形式

最も単純なstateは「カードに二重請求されました」のようなプレーン文字列だ。案件が1つの文章だけなら文字列を使う。名前付きフィールド、関連レコード、アプリケーションのstateがある場合、たとえばメッセージと注文IDを渡すならJSONオブジェクトを使う。メッセージやレコードの並びにはテキスト配列を使う。Pythonでは、対応するstring、dict、listをclient.system_one(state=...)に渡す。

TypeSafeのstateページでは、各部分に説明的な名前を付けられるため、ほとんどのリクエストでオブジェクトを推奨している。サポート会話、2件の確定済み請求がある注文、返金ポリシーを1つのオブジェクトにまとめられる。それでもstateは1つだ。判断で各部分の比較が必要なら、関連情報をまとめて渡す。フィールド名に第2の質問を隠してはならない。

Jevが受け付けるのはテキストのみ。Stateは文字列、JSONオブジェクト、テキスト値の配列のいずれかでなければならない。画像、音声、動画には対応していない。主な学習言語は英語で、CJK文字を含む他言語も受け付けるが、精度は低下する。この言語上の注意点はモデルカードを参照し、画像は先にフィールドへ変換してリクエストにピクセルデータを入れないこと。

内容と質問を分ける

Stateには内容と判断材料を入れ、質問には判断項目を定義する。返金依頼とポリシーはstateに入れ、顧客が返金を求めたか、ポリシー上返金できるかを質問する。質問をstateのデータ塊にも貼り付けた場合、Jevは引き続きinstructionsフィールドへ回答するため、32kのstate＋最長質問の予算を消費する場所にプロンプトが重複する。

無関係な詳細で膨らんだ大きなstateは、jev-1.13で文書化されている失敗パターンだ。無関係な内容がノイズとなって精度が低下し、データ塊が肥大化すると、どのフィールドが誤答の原因か特定しにくくなる。まずコードで絞り込み、質問に必要なフィールドだけを送る。絞り込めない場合は、TypeSafeのRAG文章分類クックブックのように、主判断の前にNoulで文章の関連性を評価できる。

コンテキスト長には上限があります。Jev 1.13ではリクエスト全体に64kトークン、stateと最長の質問に32kトークンまで使えます。投機的fan-outは、絞り込んだstateに対して多数の短い質問をまとめます。最後の顧客メッセージと2行の請求情報だけで足りるときに、チケット履歴全体を添付するより低コストで正確です。

stateとしてのサポート記録

ドキュメント記載のオブジェクトでは、ticket.subject、from/textペアからなるticket.messages、order.id、amountとstatusを持つorder.charges、文形式のrefund_policyを使用します。これにより、重複請求のケースは、ポリシーを再記述させるチャットではなく、このオブジェクトを対象とする複数のNoulとChoiceになります。金額はコード側ですでに把握しており、Jevは返金を求める文面か、そのポリシー文が適用されるかを判定します。

Doomのようなゲームループでは、stateはフレームではなく、世界を表す構造化テキストです。TypeSafeのデモは、そのテキストを毎秒約10クエリで入力します。Wikiracingでは、stateはページ本文とリンク候補です。スマートホームアシスタントでは、stateはユーザーの発話と、メモリ内に保持している機器一覧です。どのデモもJevへピクセルを送信しません。

データベース内のフィールドが数値でも、判定が意味に関するもの（「この色は警告に見えるか」など）なら、名前付き区分または計算済みの数値を送り、16進数の計算はコード側で行います。jev-1.13は、英語の色名に比べてRGB値や16進カラー値の読み取りが苦手です。日付も同様に、Choiceで各要素を抽出してからコードで比較してください。

予算と言語

64kのリクエストウィンドウには、stateとすべての質問が含まれます。32kのウィンドウは、stateと最長の質問1件の合計です。20kのポリシーPDFをそのままstateへ入れると、質問マップに使える余地がほとんどなくなり、無関係な詳細による失敗も招きます。まず検索し、判定に必要な2段落だけを送ってください。

現時点では英語の精度が最も高くなっています。チケットが日本語や韓国語なら、サンプルを実行してNoulとChoiceのconfidenceをプロットし、そのヒストグラムが英語の場合と同等になるまでは人間による確認を挟んでください。モデルはテキストを受け付け、CJKだからといって黙って拒否することはありません。

テキスト配列はシーケンス用であり、第2のスキーマを紛れ込ませるためのものではありません。名前付きの要素が必要ならオブジェクトを、単一のまとまりが必要なら文字列を使います。画像URLを文字列に混ぜてもJevに視覚機能は加わらず、Jevが誤読しうるURLトークンが渡るだけです。ワーカー側で取得して内容を説明し、その説明を送ってください。

ログ専用のフィールドなら、stateには含めないでください。質問IDがすでに結合キーになります。Stateには、人間の審査パネルが読む証拠だけを入れるべきです。この原則を守れば、チケットのスレッドが長い場合でも、stateと最長の質問を合わせた32kの上限内に収めやすくなります。

凝ったエンコードより、名前付きフィールドが有効です。order_id、charges[].status、refund_policyは、開発者にもJevにも読み取れます。同じ事実を1本の文字列に連結しても有効ではありますが、品質は劣ります。ドキュメント記載のサポートチケットオブジェクトを雛形にして、ticket、order、policyを置き、その名前を参照する質問を続けてください。

判定に不要な個人情報は除去してください。Jevは顧客リクエストで学習されませんが、自社のログには残ります。stateを小さく保つことは、jaggednessの改善策であると同時に、プライバシー保護の習慣でもあります。

テキスト配列はシーケンスであり、名前付きスロットの集合ではありません。名前が必要ならオブジェクトを使ってください。