OllamaでJevを動かす：文章ではなく分類と確率を受け取る

返金の問い合わせと決済エラーが同じキューに入ると、担当者は本文を読んでチームを選びます。チャットモデルに「どのチームが担当すべきか説明して」と頼めば自然な文章は得られますが、その後の自動処理が文章をもう一度解釈しなければなりません。説明を書くことと、決まった候補から一つを選ぶことは別の作業です。

System Oneは後者の作業に向いたリクエスト形式です。問い合わせを共通のstateとして送り、質問ごとに候補と判断の指示を決めます。Ollamaの`/v1/systemone`は2026年9月28日公開の0.35.0で追加されました。0.34.x以前で同じアドレスが使えると考えず、まずバージョンを確認してください。この例では、決済キューに届いた問い合わせ一件を`billing`または`technical`に分類します。

始める前にOllamaがインストールされて実行中であること、モデル用のディスク容量と実行メモリがあることを確認します。Bespoke Labsが案内するNimble 9Bの元のBF16¹重みは約18GBですが、Ollamaの`nimble`タグは形式や量子化²が異なる場合があります。`ollama list`のSIZE列でダウンロードしたサイズを確認し、実行中のメモリ使用量と同じと考えないでください。Ollama 0.35.0のリリースは、特定のMacやGPU³の最低メモリやこのエンドポイントの遅延を保証していません。

入力と質問を固定すると、失敗の原因を切り分けやすくなります。下のリクエストは「今朝から決済画面で500エラーが出る」という問い合わせを、サーバーエラーの担当チームか決済の担当チームに分類します。候補の説明は区別すべき内容を、`instructions`は今回判断する質問を示します。説明を変えると分類の境界も変わるので、実際の運用基準に合った言葉を使ってください。

`choice`の質問には2〜26個の候補を設定できます。結果には最も確率の高い候補のキーと、全候補の確率が含まれます。`curl`は一度リクエストを送り、完成したJSONを表示します。このAPI⁴はストリーミングに対応していないため、チャットのようにトークン⁵が順番に出るわけではありません。

応答の`model`、`answers.route.choice`、`answers.route.probabilities`、`answers.route.confidence`、`usage`を確認します。`choice`は最も確率の高いキーです。確率は入力した候補の間で正規化され、合計が1になりますが、候補の不足は補えません。`billing`と`technical`しか指定しなければ、挨拶やアカウント乗っ取りの通報もどちらかに分類されます。例外の経路が必要なら、別のルールや候補を設計してください。

担当チームを一つ選ぶなら`choice`を使います。「緊急障害か」のような真偽の判断には`noul`を使え、標準の候補はfalseとtrueです。必要なら`criteria`に文字列で二つの候補の意味を記述できます。答えは真偽値ではなくtrueの確率なので、アプリ側で基準を決めて真偽に変換します。

優先度など複数の段階から選ぶなら`score`を使い、基準の配列を低い段階から並べます。応答の`score`は0始まりの候補インデックスに確率を掛けて足した値で、整数とは限りません。0・1・2段階の確率が0.2・0.3・0.5なら、`0×0.2 + 1×0.3 + 2×0.5 = 1.3`です。1.3は第四のカテゴリではありません。等級に変換するなら、サービス側で別の境界を決めます。

一つのリクエストに複数の質問を入れると、それぞれが同じstateを独立に評価します。最初の答えが次の質問の入力へ自動で渡されるわけではありません。一回の通信で複数のフィールドを得られますが、質問間の会話や依存関係ではない点に注意してください。送信前に質問名を空でない一意のキーにし、候補数が2〜26個の範囲にあるか確認します。

確率が一つの候補に集中するとconfidenceも高くなります。これは候補分布のエントロピーから計算した集中度で、正解確率として校正された値ではありません。未知の問い合わせを自信を持って誤分類する場合もあります。検証データなしに「confidenceが0.9を超えたら正解」といったルールを作らないでください。

運用前に、過去の問い合わせから代表的な種類と例外を含む検証用セットを作ります。人が実際の担当チームを確認し、同じstateと候補の説明で繰り返し実行します。全体の正解率だけでなく、決済の問い合わせが技術チームへ送られる割合と、技術障害が決済キューに埋もれる割合も別に数えてください。どの誤りの影響が大きいかによって、自動配分、人の確認が必要な範囲、再質問の経路が変わります。

検証用の問い合わせが100件なら、100件中の正解数に加えて、実際の決済問い合わせ40件のうち誤送信した件数など、分母を分けて記録します。これは計算方法の例で、モデルの測定結果ではありません。正解率や遅延を掲載するなら、データセット、モデルのタグとrevision、実行機器、Ollamaのバージョン、反復回数を記録する必要があります。Ollama 0.35.0のリリースはNimbleの`/v1/systemone`の処理性能比較を提供していません。

出力がおかしいときは、まずエンドポイントとOllamaのバージョン、次にモデルタグがSystem One対応のNimbleまたはTevかを確認します。`type`はchoice・noul・scoreのいずれかで、質問ごとの候補数も対応範囲内にします。この実装では簡単な文字列の候補と基準の配列から始めてください。TypeSafeの参照APIで使える複雑な候補の説明がすべてOllama 0.35.0でも使えるとは限りません。実際に受理されるJSONを基準にします。

System Oneは選択とスコア化に向いており、顧客への理由説明や返金案内文を書く道具ではありません。担当チームを決めた後に返信が必要なら、分類結果をアプリの処理へ渡し、別のチャットリクエストを使えます。二つの役割をコードで分けると、候補の分類ミスと文章の問題を別々に確認できます。

すべての種類が既存のルールで区別でき、人が本文を読む必要もないなら、モデルを追加する理由はないかもしれません。ルールでは処理できない表現の違いが検証セットで繰り返し現れ、モデルの分類が人の作業を減らすことを確認してから導入します。最初は自動転送せず結果だけ保存し、人の判断と比較するshadow modeから始めるのが安全です。

速度を測るならリクエストを固定し、モデルがすでにメモリにあるwarm実行と、最初に読み込むcold実行を分けます。分類では一件の実時間の遅延に意味がありますが、通常のチャットの出力tokens/secondだけでは比較できません。準備実行後に同じサンプルを3回以上送り、中央値とエラー数を記録すると、モデルや候補の説明を変えた影響を確認できます。

APIの経路とフィールドの意味は、Ollama 0.35.0、Ollama PythonクライアントのSystem One説明、現在のOpenAPI定義に基づいています。対応モデルや候補の種類はバージョンで変わり得るため、使う前にインストール済みバージョンの公式文書を確認してください。