Jev 1.13 のギザギザ

Jev 1.13 のギザギザ

Jev は完璧ではありません。ここでは jev-1.13 で把握しているギザギザな部分をいくつか挙げます。その多くは今後のバージョンで修正されます。

jev-1.13 は高速で、キャリブレーションされており、常識的な判断が得意ですが、完璧ではありません。jev-1.13 は System One のタスクで最もよく機能します。追加の間接参照の段階を要するタスクは苦手かもしれません。理解がかなり字義どおりになることがあります。数値の精度を要するタスクも苦手です。

失敗モードの詳細

字義どおりの読み

jev-1.13 は、あなたが意図した質問ではなく、あなたが書いた質問に答えます。スコープを表す語、否定、暗黙の条件は額面どおりに読まれます。質問は instruction に書かれた言葉に基づいて答えられますが、人なら instructions の背後にある意図を読み取るかもしれません。

代わりに： 正確な条件を instructions に書き出します。具体的に書きます。境界ケースは criteria に入れます。間違った答えを見て、本当に言いたかったことを説明したくなったとき、その説明こそ instruction に欠けていた半分です。解釈を避けられない場合は、2 つの字義どおりの質問に分け、コードで組み合わせます。

数学と数値

Jev は電卓ではありません。数学的なロジックはコードで実装することを強く勧めます。Jev は数学的な質問よりも意味的な質問のほうが得意です。

カウント

jev-1.13 は確実には数えられません。これは語中の文字数、パッセージ中の語の出現回数、長いリスト中の項目数にも当てはまります。モデルは数え上げるのではなく答えの形を認識するので、数える対象が大きくなるほど誤差が増えます。

カウントの質問をする前に、そもそもそのカウントにモデルが必要なのかを問い直してください。単位が正規表現やパーサで見つけられるものなら、カウントはコードに属し、モデルが付け加えるものは何もありません。

代わりに： コードで数えます。ある criteria に合う項目を数えたいときは、候補をコードで反復し、1 つずつ質問して、答えを自分で合計します。

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # up to you on what you want the threshold to be, depends on your usecase.

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

数値表現

jev-1.13 は数値表現よりも意味的な表現のほうが得意です。たとえば、色についての質問は、16 進数値を使うものより英語の色名を使うもののほうが成績が良くなります。RGB の三つ組や 16 進数値を与えても、2 つの値が近いかどうかを確実には判断できません。

同様に、高水準プログラミング言語についての質問は、低水準のアセンブリやバイナリ符号化された命令についての質問より成績が良くなります。

代わりに： 変換はコードで行い、計算した数値か名前付きのバケットのどちらかを渡します。モデルは、その色が警告として読めるかどうかなど、本当に判断に属する部分に残します。

score を使った計算

score の出力（たとえば期待値や確率）を使って、criterion の 2 つのレベルの間にある数の正確な大きさを計算しないでください。期待値は特定のしきい値を超えるかどうかの確認には使えますが、jev-1.13 の score のレベルは数値的なキャリブレーションが弱いです。最も近い 2 つのレベルの間を補間して正確な数値を再構成する助けにはなりません。

日付と時刻の比較

jev-1.13 は日付を順序付きの量ではなくテキストとして読みます。2 つの日付のどちらが先か、どれだけ離れているか、一方が期間内に入るかを尋ねるのは信頼できません。混在した形式、相対的な参照、四半期・決済期間・計上期間のようなドメインの境界があると、さらに悪化します。

代わりに： 作業を分けます。抽出は判断なので、モデルに任せます。算術は判断ではないので、コードに残します。

日付の各部分は小さな閉じた集合です。12 か月、最大 31 日、有限の年の範囲。これにより抽出は、自由形式のパースではなく、列挙された選択肢に対する Choice になります。明示的な「記載なし」の選択肢を置く場所もでき、欠けている部分は推測されずに報告されます。コードが各部分を実際の日付に組み立て、それ以降のすべて——順序、期間、オフセット、曜日——を担います。

実例は date extraction cookbook にあり、相対的な日付や信頼度によるゲーティングも含まれます。

間接参照

二重否定や複雑な間接参照を含む instructions は、あまり信頼できない答えになります。プロパティのプロパティについての質問や、複数ホップの推論を要するものは精度を損ないます。

代わりに： できるだけ直接的に instructions を書きます。可能なときは、state の関連する部分を名前で特定します。

無関係な詳細でいっぱいの大きな state

意思決定と無関係な内容で state が大きくなるほど、精度は下がります。無関係な詳細は気を散らすものとして働き、state が大きいと、入力のどの部分が誤った答えを生んだのかを見極めにくくなります。

代わりに： まずコードで取得とフィルタリングを行い、質問が必要とするフィールドだけを送ります。state をフィルタリングできないときは、Noul を使って関連性で絞り込めます。実例は classifying RAG passages cookbook にあります。

敵対的なコンテンツ

state はデータであり、jev-1.13 は既定ではそれを敵対的なものとして扱いません。モデルを敵対的に誘導するために書かれた内容——注入された instruction、意図的に誤解を招く枠付け、自らの分類を主張するテキスト——は答えを動かしえます。これは今後改善していく予定です。

代わりに： criteria で明示します。多くのユーザーにデプロイする前に、統合を徹底的にテストします。

矛盾する instructions と criteria

instructions と criteria が異なることを求めていると、jev-1.13 は混乱するかもしれません。最も良い成績は明確な言い回しから生まれます。たとえば、true が「いいえ」に、false が「はい」に対応する Noul は成績が悪くなります。平均的な人が読み理解しやすい instructions を目指してください。

代わりに： criteria を instruction の延長として扱います。明確で正確な言葉を使って両者を揃えます。

常識的な構造不変量

jev-1.13 は非常に一貫しているので、意味的に似た入力には量的に似た出力が期待できます。 しかし、成り立つだろうと想像されがちな構造不変量の多くは、モデルによって保証されているわけではありません。

たとえば「顧客は返金を求めているか？」を、チケット「サイズが合わなくて不満です。どんな選択肢がありますか？」に対して、Noul として尋ねた場合と、はい/いいえの Choice として尋ねた場合：

比較できる数値は noul と probabilities["yes"] で、Noul の質問に対して Choice の出力や信頼度をどう解釈するか、逆の場合も、明らかではありません。

同じ質問とその否定「顧客は返金以外の何かを求めているか？」を、チケット「同じ注文で二重に請求されました。誰か調べてもらえますか？」に対して 2 つの Noul として尋ねた場合：

P(noul) と 1 - P(not noul) が直接比較できない理由はたくさんあります。

代わりに： 期待される構造上の不変性に頼らず、意図をそのまま意味するように質問を言葉にします。Noul で調整したしきい値を Choice に持ち込まないでください。また、別々の質問の間に算術的な恒等関係をモデルに期待しないでください。選択肢に対する Choice と、選択肢ごとの 1 つの Noul は異なる質問に答えます。Choice は相対的で、どの選択肢かを決めますが、各 Noul は絶対的で、すべての選択肢で低くなることがあります。skill suggestion cookbook は同じ候補リストに対して両者を使い、Choice でスキルを選び、Noul 群でそもそも提案すべきかを決めます。

生成

jev-1.13 はテキスト生成を学習していません。choice を連鎖させれば無理に生成させることもできますが、うまくいかず、非常に遅くなります。データ抽出では、正規表現や生成モデルを使って候補となる選択肢を抽出し、jev-1.13 に正しい抽出を選ばせるほうがよいです。

代わりに： 答えの空間が有界なときは、値そのものを尋ねるのではなく、選択肢に対する Choice に抽出を変えます。本当にテキスト生成が必要なら……そのための別のモデルがあります。