Ollama、互換APIのサンプリング既定値の上書きを修正

Ollamaは11月3日、v0.40.14-rc0のプレビュー版を公開しました。生成の一貫性に影響する修正が含まれており、互換APIの使用時にクライアントが指定しなかったサンプリングパラメーターは未設定のまま保持され、モデルに組み込まれたパラメーターが有効になります。この修正は10月31日にマージされ、今回ダウンロード可能なプレビュー版に入りました。リリースノート

メンテナーによると、従来の互換エンドポイントは省略されたtemperatureとtop_pに1.0を設定していました。また、/v1/completionsでは2種類のペナルティパラメーターを0にしていました。リクエストのオプションは最後に適用されるため、これらの補完値がモデルパッケージの設定を上書きしていました。たとえば、組み込みの温度が0.1のLFM3を互換エンドポイント経由で呼び出すと、実際には1.0で実行される可能性がありました。この修正はチャット、テキスト補完、Responsesの3種類のエンドポイントを対象とし、明示的に渡された値は引き続き優先されます。値が0の場合も同様です。修正の説明

この違いはモデルのデプロイ方法に直結します。OllamaのModelfileではPARAMETERを使って実行パラメーターを保存できます。温度とtop_pは生成の多様性に影響します。そのため、エンジニアが同じ重みとプロンプトを使っていても、インターフェースを切り替えた際に既定値が書き換えられると、出力の分布が変わる可能性があります。モデルパッケージの設定は、ollama show --modelfileで確認できます。Modelfileのドキュメント

既存の連携で確認すべきなのは、クライアントがパラメーターを実際に送信しているかどうかです。公式の互換インターフェースの例では、モデルとメッセージだけを指定できます。こうしたリクエストは、修正後に生成の挙動が変わる可能性があります。修正の仕組みから考えると、フレームワークがサンプリング値をすでに補っている場合、サーバーはその明示的な値を引き続き採用します。アップグレードだけでモデル設定に戻るわけではありません。互換インターフェースのドキュメント

確認時点で、このバージョンは引き続きプレビュー版と表示されており、公開情報には修正前後の品質ベンチマークもありません。エンジニアリングチームは、モデルのバージョンとテストケースを固定し、パラメーターを省略する場合と明示する場合の両方を比較するとともに、正式版の公開状況を確認してください。現時点で確認できるのはパラメーターの優先順位が修正されたことまでであり、あらゆるタスクの精度が向上するとまでは言えません。