What people are building with Jev

iwashi / Yoshimasa Iwase

@iwashi86

Jevの内部アーキテクチャを推測している技術記事(Jev’s Architecture Unmasked)からメモ。 ・本記事はJevのAPIを約1万回の呼び出して、内部構造を推測したもの ・従来の言語モデルを用いた分類やルーティングでは、トークンを1文字ずつ逐次生成するために膨大な無駄な計算コストが発生していた。 ・JevはLLMの膨大な知識をそのまま保持しつつ、テキスト生成を完全に排除して内部表現から直接確率を出力する ・システム全体の構造は、共通の文脈をエンコードする共有状態、並列に処理される質問群、そして確率を直接読み出すヘッドの3要素から成立 ・モデルは入力を左から右へ読む事前学習済みの因果トランスフォーマーであり、プロンプト処理の直後に推論を終了する ・テキスト生成ループは存在しない ・だから、単語の綴りやJSONのフォーマットを出力するためのステップが一切不要 ・APIレスポンスに含まれる出力トークン数という項目は、単に返却された文字列の長さから、後で計算された課金用の指標にすぎない ・選択肢が2個の場合でも200個の場合でもサーバーの処理時間はほぼ変化せず、モデルがトークンを逐次生成していない事実を強く裏付けている ・入力データは共有状態と複数の質問に分割され、問い合わせ本文などの共通コンテキストは一度だけKVキャッシュに保存される ・複数の質問は同じ共有キャッシュを参照するため、質問数が増加しても共有状態を何度も再計算する必要がない ・それぞれの質問はお互いの存在や指示が見えないようになっている ・質問同士が干渉することなく完全に隔離された状態で推論される ・ある質問内に秘密のコードを記述しても別の質問からは参照できない ・共有状態に置いた場合のみ全質問から認識可能 ・約100個の質問まではリクエストの処理時間がほとんど増加せず、共通状態を一度だけ計算して並列処理する設計の恩恵が明確に現れている ・Jevが持つ高度な知識水準を考慮すると、双方向エンコーダを新規開発したのではなく、既存の因果デコーダ型LLMを再利用した可能性が極めて高い ・トークナイザの挙動は既存の公開モデルと完全には一致しない ・数字の分割方法やチャンク処理に独自の工夫が見られる ・選択肢の並び順に関する実験では、判断の根拠となる情報が選択肢リストの末尾に配置されていてもモデルは正しく正解を選択できた ・質問に含まれる各選択肢は独立して採点されるのではなく、リスト全体が互いに文脈として影響を及ぼし合った上で判断される ・無関係なダミーの選択肢を追加すると既存の選択肢間の相対的なオッズ比が変化した ・このことから、選択肢同士が相互作用していることが実験的にわかる ・リスト全体を一括して読み込む設計のおかげで、上記のどれでもないといった他の選択肢に依存する回答も適切に処理できる ・選択肢の提示順序を逆転させると出力確率に若干の変動が生じるため、実務で特定の閾値を用いて自動処理を行う際は順序バイアスへの配慮が求められる ・学習手法にはRLCDと呼ばれる独自のアプローチが採用されている ・強化学習の枠組みを用いて真の結果に即した予測確率を出力するように調整されている ・モデルの出力は対数損失やブライア損失といった適格スコアリングルールで最適化され、正直な不確実性を反映した確率分布を形成する ・ベンチマークの検証結果において予測確率と実際の正解率は高精度に一致しており、期待キャリブレーション誤差は0.0313という極めて低い値を記録した ・難易度の高い数学問題ではモデルが提示する正解確率自体が低下する ・なので、自身の知識の限界に応じた不確実性を表現できている ・APIが返す信頼度スコアは学習された固有値ではなく、得られた確率分布の最大値から算術計算で求めた便宜的な数値にすぎない ・Jevのバックボーンには、必要な専門モジュールのみを選択的に起動するスパースなMixture of Expertsが採用されていると推測される ・テキスト生成を行わないプロンプト処理のみのタスクでは計算負荷がボトルネックとなるため、疎な構造による演算量削減が大きな効果を発揮する ・約3万トークンの入力をわずか160ミリ秒程度で処理する速度性能は、巨大な密結合モデルではなくMoEを採用している推測ともあう ・質問枝はチャットのような逐次的会話ではなく独立したバッチとして処理されるため、GPUリソースを最大限に活用した一括計算が可能 https://archerhume.com/posts/jevs-architecture-unmasked