真偽、選択、段階は、言語として足りるか

Noul、Choice、Score は、コードのための言語です。経費報告を使い、三つの問いがどう分かれるか、この言語がいつ足りなくなるかを示します。

Folkbench folkbench.com

共著者：folkbench.com （Folkbench は、AI API、モデルサービス、関連サイト向けの、検証できる評価・選定プラットフォームです。公開されたサービス情報、価格、可用性、レイテンシ、証拠の期間をもとに、利用者が経路を比較して選べるようにします。）

この一連は、十篇です。

この言語が足りるかは、何を言わせたいかによります。閉じた三つの問いは、速度を買い、組み合わせやすさも買います。代価は、広げる必要のあるものは、それが言えない、ということです。これは、コードのための言語です。人が読むためではありません。

文書と評価サイトの分け方は同じです。Noul、Choice、Score です。ページの上に、第四の種類はありません。

文書のなかの、三つの種類

Noul が問うのは、はいなかだけです。返すのは確率です。文書では、その数は 0 から 1 です。1 に近ければ、確信のあるはいです。0 に近ければ、確信のあるいいえです。0.5 の近くで止まれば、それは両側が同じようにあり得る、という意味だけです。「中くらいの程度」ではありません。文書は、この罠に名前を付けています。誰かが Python に強いかを問うと、0.5 は中くらいの水準ではありません。水準を実際に測りたいなら、Score へ切り替え、各段階がどう見えるかを書いてください。Noul は、別の確信度も付けません。確率が、信号です。

Choice は、固定された集合から一つの項目を選びます。戻るのは選ばれた項目で、分布の全体と確信度が付きます。確信度が見るのは、分布が鋭いかです。確率が広がっていれば、確信度は低く、コードはこの問いが不安定だと知ります。Jev におけるこの問いの基数の上限は、255 です。それを越えると、Jev は二段を取ります。二段とは、先に独立に採点し、それから明示的な選択をする、ということです。ときどき、少し遅くなります。遅さは余分な一歩であり、同じ狭い問いが急に高くなることではありません。

Score は、尺度の上の段階です。使い方では、2 から 10 段階の順序のある尺度です。文書は、少なくとも二段階と言い、インターフェースは多くても十を受け付けます。段階は、照合できる状況として書かなければなりません。「少し高い」や「まあ良い」とだけ書くと、モデルには照合するものがありません。スコアは、二段階のあいだに着地できます。その数は、各段階の位置にその確率を掛けたものの和です。二段階のあいだの小数は、正常です。計算が壊れたのではありません。スコアを返し、同時に、段階の上の分布と確信度を返します。同じスコアでも、すべてが中間の段階へ押し潰されていることも、両端で割れていることもあります。スコアだけを見ると、それらを同じものとして扱います。分布と確信度は、一緒に読んでください。

三つの答えのどれも、事前に与えたマスから出られません。同じ材料の上の問いは、互いに独立です。一つ足しても、一つ取り去っても、他の問いは変わりません。判断が幾つかのことに一緒に依存するなら、分けて問い、重みはコードに残してください。あとで方針を調整するとき、変えるのはこれらの数です。プロンプトの全体は、書き直しません。

経費報告を、分解する

公式の評価ページは、経費報告を玩具として使います。左は、人が書いた一段です。チームが書き留める種類の方針です。各報告は、領収を付けなければなりません。領収が読めなければ、従業員に別の一枚を求めてください。それから、支出が食事か、旅行か、備品かを見てください。食事が $75 を越え、記述が領収と一致しなければ、管理者が署名しなければなりません。他の報告は、承認として扱います。

右では、同じ一段が流れへ分けられます。方針の各文が、一つの問い、または一つのコードのルールです。領収が読めるかは、真偽です。読めなければ、コードが新しい一枚を求め、その一歩はモデルへ再び問いません。分類は単一選択を使い、選択肢は食事、旅行、または備品です。金額が $75 を越えるかは、コードが自分で比べます。モデルへもう一度問う必要があるのは、記述が領収と一致しない、という半文だけです。金額と一緒に、それが、管理者が署名するかを決めます。管理者の署名が要らない報告は、コードが承認として扱います。モデルは、ここで注釈を書きません。

評価ページの方向は、一文です。構造は、一つの大きなプロンプトより、常に良い。四つの例の流れを平均すると、workflow に乗ったどのモデルも、方針の全体を一つのプロンプトにするより精度が高く、支出と時間は低くなります。プロンプトの側は、方針の全体を渡し、一つの答えの内側でモデルに論理を歩かせます。workflow の側は、ルールとして書けるものをコードへ与え、狭い判断だけを問いとして残します。

最も安定した実在の流れは、通常、一つの大きな問いではありません。互いに独立な、多くの狭い問いです。振る舞いは確率に依存し、一つの離散的なラベルだけには依存しません。分類は定まったように見えても、他の選択肢が確率の分け前をまだ持っていることがあります。コードは、書いたしきい値でもう一歩取れ、分布を捨てなくて済みます。流れの外では、なお一つの分岐です。真ん中の層は、領域のエンジニアリングです。今回どの問いが使われないか、どの数が線を越えたと数えるかは、この業務のために書き留め、毎回同じように走らせなければなりません。狭い問いの答えがコードに入れば、重みとしきい値はこの層で定まります。

文字列の生成を捨てたあと

Jev は文字列の生成を捨て、引き換えに並列サンプリングを取ります。一回のリクエストのなかの問いは、一緒に計算されます。すべての出力が、一度に出ます。トークンごとではありません。チャットモデルは、一つのトークンのあとに次のトークンを育てなければならず、それぞれが前のものを見ます。こちらには、一字ずつの手順がありません。普通の狭い問いを幾つか足しても、時間はほとんど一緒に上がりません。余分な費用は、主に、その問い自身のトークンです。

公式の価格は、チャットのインターフェースの価格ではありません。入力は、100万トークンあたり $0.042 です。出力は FREE です。トークンで課金される、生成された語の長い連なりがなければ、出力は課金されません。遅延は 70–500 ミリ秒に着地します。その範囲は呼び出し鎖のためであり、チャット箱の内側で待つためではありません。

戻り値は、まっすぐコードへ行きます。Noul の確率は、if へ入れます。振り分けは、Choice のラベルを使います。採点のしきい値は、Score の位置を使います。先に解析しません。チャットモデルが Markdown の一片を返すなら、先に語を分けなければならず、余分な一文が形式を曲げ、残りが繋がらなくなることがあります。三つの問いはそのテキストを返しません。Jev がそれを生成しないからです。

この報告をなぜ拒んだかの説明は、三つの問いには入りません。謝罪も、交渉も同じです。人が読むために書かれた理由も、戻り値のなかにはありません。それらは、話せるモデルへ行きます。Jev は、判断で止まります。

足りないときの事例は、具体的です。選択肢が開いた世界の名前なら、会社名と製品名は出続け、集合は事前に固定できません。255 は基数の上限であり、無限の一覧ではありません。理由が原文の文を引用しなければならないとき、渡すべきそのような文はありません。ユーザーが人の文を待っているとき、インターフェースが欲しいのは読める語です。そのとき Jev を強いるのは、関節を口として扱うことです。

方針が真偽、単一選択、段階へ閉じられるとき、続くのは分岐であり、判断は同じコードへ組み立て戻されます。欲しいのが速度と、この種の組み合わせやすさなら、足りています。広げる必要のあるものは、言えません。速度と組み合わせやすさは、その交換が買うものです。

出典

シリーズ