Ollama v0.35.0、ローカルNimbleで分類・採点　Jev互換APIを追加

Ollamaは9月30日、Nimbleなどの決定モデルをローカルで扱えるようになったとXで紹介した。文章を書かせる通常のLLM呼び出しとは違い、用意した候補の選択、真偽の確率、段階評価を返す仕組みだ。チケットの振り分けやモデルのルーティングなど、「説明はいらないので判断だけほしい」処理を手元の環境に置ける。

自由文を作らず、許可した答えを採点する

Ollama v0.35.0のリリースで追加されたのは、Jev APIに基づくPOST /v1/systemoneだ。Bespoke LabsのNimbleとTogether AIのTev1に対応し、返り値は生成文章ではなく、選択結果と候補ごとの確率、またはスコアになる。

Nimbleの公式ページとモデルカードによると、Nimble 9BはQwen3.5-9Bを基にしたLoRAで、自由文や推論過程を生成する代わりに、許可された回答トークンを直接採点する。つまり、任意のJSONを書かせて後から形式を検査するのではなく、最初から決めた選択肢へ分類する役割だ。柔軟さは減るが、後工程が期待する答えの形は絞りやすい。

3種類の質問を、一度に最大64件

利用にはOllama 0.35.0以降と互換ローカルモデルが必要だ。stateに判定対象を入れ、questionsへ1〜64件の質問を渡す。Pythonクライアントの案内では、質問形式は次の3種類に分かれる。

choice：候補から一つを選ぶ
noul：真である確率を返す
score：順序付きの基準で評価する

たとえば一枚の問い合わせ票に対して、担当キュー、緊急度、レビュー優先度をまとめて尋ねる設計ができる。X投稿が挙げるチケット振り分け、モデル選択、コンテンツモデレーションは、この定型判断と相性がよい用途だ。

候補数と入力長には、先に境界線を引きたい

現行のOllama統合では、choiceとscoreは2〜26候補。応答は単一のJSONで、ストリーミングとクラウドモデルには対応しない。一方、Nimbleの最新チェックポイント自体は最大255候補を掲げているため、Ollama経由ではAPI側の上限が先に来る。

入力長の公式表示には不一致もある。9月30日に確認したOllamaのモデル一覧はnimble:latestを256Kコンテキストと表示するが、同じページの詳細注記とBespoke Labsのモデルカードはプロンプト上限を8,192トークンとし、超過時は拒否すると説明している。両者がモデル形式とAPIの実効上限を分けて示しているのかは、資料だけでは判別できない。長文を本番投入するなら、8,192を安全側の基準にして確認するのがよさそうだ。

なお、返されるconfidenceは候補間の確率分布がどれだけ集中しているかを示す値で、正答確率そのものではない。数字が高いことと判断が正しいことは別だ。ローカルで素早く定型判断を組み込めるのは魅力だが、候補設計と評価用データは引き続き必要になる。