SemIfがブラウザ内での選択肢スコアの読み出しを実演、判断に用いる確率には別途校正が必要

9月18日にHacker Newsで議論されたOpenJevのブラウザ実験は、現在、SemIfという名称でローカルでの意思決定推論を実演している。同じモデルで、許可された選択肢のスコアを直接読み出す方法と、確率を含むJSONをトークン単位で生成する方法の2つを比較する。プロジェクトはTypeSafeとは無関係であると明示しており、技術的な焦点は回答テキストの生成コストを省くことにある。[議論の記録](https://news.ycombinator.com/item?id=49752041)、[実験ページ](https://openjev.com/)

直接読み出す方法では、回答の選択肢をAからTなどのラベルに対応付け、logitsを取得した後、ユーザーが提示した選択肢の間だけでsoftmaxによる正規化を行う。この処理の流れから、入力コンテキストの処理は引き続き必要だが、完全なJSONを出力するためにデコードを繰り返す必要はないと考えられる。分類やワークフローのルーティングにおいて、測定する価値のある実装の方向性を示している。ただし、判断に長い推論を要するタスクでは、生成ステップの省略が品質に影響するかどうかを別途検証する必要がある。[手法の説明](https://openjev.com/)

実行基盤にはwllamaとバージョンを固定したGGUF形式の重みを採用している。wllamaはllama.cppのWebAssemblyバインディングで、WebGPUに対応しており、n_gpu_layersでGPUにオフロードするレイヤー数を調整できる。上流プロジェクトは、一部のブラウザ互換モードでは性能が大幅に低下することも注意点として挙げている。そのため、テスト結果にはブラウザ、モデルの量子化方式、ハードウェア条件を明記する必要があり、パラメータ数だけからレイテンシを推定することはできない。[wllamaドキュメント](https://github.com/ngxson/wllama)

上流プロジェクトはさらに、ダウンロードの改善とメモリ不足の軽減のため、大容量の重みを1ファイル最大512 MBに分割することを推奨している。量子化については、Q4、Q5、Q6から要件に応じて選ぶことを勧めている。こうしたデプロイ条件を踏まえると、1回の判断が高速でも、初回ダウンロードやモデルの常駐に必要なリソースが利用体験を左右する可能性がある。小規模なモデルも、ロードに成功しただけでタスクに適しているとは判断できない。[モデル準備ガイド](https://github.com/ngxson/wllama)

ページでは、ダウンロード、ロード、ウォームアップ、入力処理、生成の所要時間を個別に表示する。2つの方法は順番に実行され、直接読み出す方法が先に動く。これによりGPUの同時利用による競合は避けられるが、キャッシュや実行順序が比較に影響していないかは確認が必要だ。さらに重要なのは、選択肢間の確率が校正されておらず、選択肢にない回答も除外されている点である。値が1に近くても、そのまま回答の信頼性を保証するものとは見なせない。[測定と制約](https://openjev.com/)

開発者がこのような読み出し方式を本番のルーティングに組み込む場合は、独立したラベル付きデータセットを使い、誤り率、選択肢の順序に対する感度、回答を拒否する閾値を検証し、繁体字中国語や専門用語についても別途テストする必要がある。今回の確認時には、サイトからリンクされている実装説明が404を返しており、評価手順を完全に再検証するための情報はまだ不足している。現時点では、実際に試せる推論実験として捉えるのが適切であり、これを根拠にJevと同等の能力を持つ、あるいは信頼度の校正が実運用に耐える水準に達していると判断することはできない。