JevがArrowを話したらどうなるか？

JevがArrowを話したらどうなるか？ Ian Cook著 2026年9月29日 Jevは、自然言語とアプリケーションの状態を型付けされた意思決定に変換するTypeSafe AIの新しいモデルです。コンテキストを提供し、可能な回答を定義します。Jevは、コードが直接使用できるスコアと確率を返します。APIはその回答をJSONとして配信します。 最近Jevについて聞かないようにしていたとしても、あなたが隠れている岩は優れた防音対策が施されています。Jevは、AIの出力をコードで使いやすくするための広範な取り組みの一部です。Outlines from .txtのような他のツールは、制約付きデコーディングを使用して、既存の言語モデルにスキーマに準拠した出力を生成させます。TypeSafeは異なるアプローチを取りました。発表の中で、同社は新しいモデルアーキテクチャ、並列サンプラー、およびReinforcement Learning for Calibrated Decisionsと呼ばれるトレーニング方法について説明しています。Jevはトークンごとに回答を生成する手間を省き、並列に確率を生成します。TypeSafeは、意思決定ワークフローにおいて、汎用LLMと比較して速度とコストで大幅な改善を報告しています。 Jevは新しいプリミティブであり、その可能性の全範囲はまだ誰も知りません。この記事は現時点での私たちの考えを反映しており、進化すると予想しています。しかし、いくつかの強力なパターンはすでに明らかです。TypeSafeのドキュメントは、そのうちのいくつかを説明しています。 Speculative fan-outは、推測的なものも含めて一度に多くの質問をし、コードがどの回答が関連性があるかを決定できるようにします。Confidence-gated routingは、信頼度を2番目の決定軸として扱い、Jevが不確かな場合にコードが異なるパスを取れるようにします。Composite scoringは、複数の判断次元を単一のスコアに結合します。Intent routingは、ユーザーが何を求めているかを分類し、リクエストを適切なハンドラに送信します。これらを組み合わせることで、つい最近まで決定論的なものが実用的であると考えられていた場所に、根本的に確率的なワークフローとパイプラインへの道が開かれます。達成できる洗練度は驚くべきものです。 このようなパイプラインは大量の構造化データを移動させますが、それが構造とパフォーマンスと効率性を組み合わせた別のテクノロジーであるApache ArrowとJevがどのように連携できるかという疑問を私たちに抱かせました。Stop paying the JSON taxの記事で、ArrowがJSONへの変換と逆変換を回避することでデータパイプラインを高速化する方法を説明しました。ここではそれができるでしょうか？ Jevの回答をArrowとしてモデル化する その質問を探求するために、まずJevの回答を表すArrowスキーマを設計しました。Jevには3つの質問タイプがあり、それぞれ異なる回答形状を持っています。 質問タイプ | 返されるもの -----------|----------- Choice | 選択されたオプション、すべてのオプションの確率、および信頼度スコア。 Noul | はい/いいえの質問に対する回答が「はい」である確率。個別の信頼度フィールドはありません。 Score | 順序付けられたレベル上の位置。レベル間に位置することも可能。各レベルの確率、信頼度、およびレベルを説明する凡例。 各質問の回答をArrowカラムとして表現することを選択しました。質問の定義は、推論が開始される前にカラムのタイプを私たちに伝えます。ChoiceラベルとScore凡例は、可能な回答を説明するため、スキーマのフィールドメタデータに配置できます。予測と確率はデータバッファに入ります。 Arrow拡張タイプを使用すると、通常のArrowストレージタイプにその意味論的な意味を添付できます。 Choice struct< choice: uint8 not null, confidence: float64 not null, probabilities: fixed_size_list<item: float64 not null>[N] not null > not null metadata: {"labels":["returns","shipping","billing","other"]} Noul float64 not null metadata: {} Score struct< score: float64 not null, confidence: float64 not null, probabilities: fixed_size_list<item: float64 not null>[N] not null > not null metadata: {"legend":["Can wait","Within a few days","Today"]} Nは選択肢またはスコアレベルの数です。Choiceは、共有ラベルへの1バイトインデックスを格納します。固定サイズ確率ベクトルは行ごとのオフセットを必要とせず、64ビット浮動小数点数はTypeSafe Python SDKによって返される値を保持します。スキーマメタデータは、選択肢インデックスとスコアレベルの意味を提供します。値とメタデータを組み合わせることで、元の回答オブジェクトをそれぞれ再構築するのに十分です。 TypeSafe APIは今日、これらの回答をJSONとして返します。もしこのスキーマを使用して直接Arrowを返した場合、pandas、Polars、DuckDB、Apache DataFusionのようなツールは、JSONを逆シリアル化して型付きカラムを再構築する前に結果を消費できます。互換性のあるコンシューマーは、コピーせずにArrowバッファを使用できます。これは構造化データの交換方法として一般的です。Databricks、Snowflake、ClickHouseは、HTTP経由でArrow形式でクエリ結果を返すことができます。Hugging Face Datasetsは内部的にArrowを使用しており、直接Arrowテーブルを取得できます。JevにArrow出力オプションを提供することで、その回答を同じデータワークフローに参加させることができます。 1つの状態から多数へ Jevは今日Arrow出力を提供していないため、私たちの目標は、もし提供した場合のTypeSafe APIの使用方法をシミュレートすることでした。それはJevを運用レイヤー（1回のやり取りごとに意思決定を行う場所）から分析レイヤー（作業単位全体がテーブルである場所）に移行させることを意味しました。そこで、より基本的な問題に直面しました。リクエスト形式です。TypeSafe APIリクエストには、状態（評価するコンテキスト）と質問（それについて行う判断のマップ）が含まれています。APIは、1つの状態に対して複数の質問をすることに非常に適しています。しかし、独立した多数の状態に対して同じ質問セットを行うためのネイティブなバッチ操作がありません。例えば、ライブカスタマーインタラクションを考えてみましょう。意図を特定し、緊急度をスコアリングし、払い戻し資格を確認し、不正の兆候を探したい場合があります。コンテキストを一度送信し、それらの質問すべてをまとめて行うことができ、Jevはそれらを並列に個別に評価します。ドキュメントはこれをうまく活用しています。しかし、それらの判断をライブアプリケーションで信頼する前に、検証したいでしょう。その一部は、Jevが見る可能性のある状態の範囲全体で生成すべき確率を推論することです。しかし、履歴カスタマーインタラクションの代表的なサンプルに対して実行し、その回答を知られている結果と比較したいでしょう。それが私たちが関心のあるバルクワークロードです。多数の状態、固定された質問セット。Jevの速度と価格設定は、その作業に適しています。障害はAPIです。バルクエンドポイントがないため、状態ごとに数千または数百万の個別のAPI呼び出しを行う必要があります。 Jevaroの構築 実験を諦める準備ができていなかったため、Jevaroを構築しました。PythonとJavaScriptクライアントを備えた小さなPythonプロキシサーバーです。1つのリクエストで複数の状態と共有質問マップを受け取り、状態ごとにJevを呼び出し、上記のスキーマを使用してArrow IPCストリームを返します。結果は入力順に到着します。スキーマはすぐに送信され、回答は利用可能になり次第、その順序で続きます。 スループットの向上には、数回のチューニングラウンドが必要でした。新しい接続を繰り返し開くことは、ネットワークとTLSのセットアップ時間を追加します。次のリクエストを送信する前に各回答を待つと、呼び出しが重複するのを防ぎます。長寿命のHTTP/2接続プールを再利用し、非同期リクエストのウィンドウを保留状態にし、結果バッチを書き出す前にそれを補充しました。SDKの再試行は、切断された接続を回復し、レート制限と過負荷応答でバックオフします。これらすべてが結果の入力順序を維持します。 それでも、各状態は個別のアップストリームHTTPリクエストとJSON応答を必要とします。APIオーバーヘッドと繰り返しのリクエスト処理およびJSON変換をすべて回避することで、APIから直接Arrowストリームを返すネイティブなバルク呼び出しは、桁違いに高いスループットを達成すると予想されます。少なくとも、ボトルネックをAPIオーバーヘッドから推論自体に移行させることができます。 今のところ、Jevaroを使用すると、そのインターフェースを実験できます。リクエストロジックを各SDKに直接配置することもできましたが、バッチプロキシサーバーは、並行性、再試行、順序付け、およびArrowシリアライゼーションの実装を1つ提供します。ブラウザクライアントは、TypeSafeキーを受け取らずに使用することもできます。