企業の多様なリクエストを1つの自社運用LLMに集約する方法

導入

企業が大規模言語モデルを導入する際、問題はモデルの性能だけではない。データレジデンシーの要件から自社運用が必要になる一方、新しいモデルへ移行しても、互換性やリスク管理のために旧モデルをすぐ廃止できない場合がある。その結果、限られたGPUプールが複数のモデルやサービスに分散する。今回の取り組みは、こうした構成を見直し、200以上の社内アプリケーションからのリクエストを1つの自社運用モデルへ集約しようとするものだ。

手法のポイント

• 本番エラーを学習目標にする。 チームは本番分析から、指示追従、関数呼び出し、社内タスクの分布という3つの不足を抽出した。オフライン評価も本番トラフィックに合わせて層別化している。
• 目的ごとにGRPO専門家を作る。 すべての目標を1つの報酬で同時に最適化すると、領域間の報酬干渉が起こりうる。そこで、3つの軸ごとに別々の専門モデルを学習した。
• 失敗パターンを分けて扱う。 指示追従では意味の崩壊、関数呼び出しでは過剰なツール呼び出し、社内タスクでは冗長な出力による評価攻略が問題になる。共通の修正ではなく、領域ごとの対策が必要になる。
• SLERPで統合する。 複数の専門家を維持する代わりに、2段階のSLERPによってパラメータを統合し、混在する企業リクエストを処理する単一モデルを構成した。
• 検証方法を使い分ける。 明確な正誤判定が可能なタスクには決定論的な検証器を使い、それ以外は校正済みのLLM評価者で採点する。

結果と意味

非推論モードでは、統合モデルの社内Arenaスコアは69.6で、総パラメータ数が約7倍のベースラインの65.8を上回った。指示追従は0.85対0.83、関数呼び出しは0.79対0.77だった。資料によれば、一般対話ベンチマークも改善し、実運用ではプラットフォームの50％、月間1億1,600万リクエストを処理している。

この結果は、小さいモデルが常に大きいモデルより優れるという主張ではない。重要なのは、企業固有のリクエスト分布に合わせたモデルなら、同じ計算資源からより大きな実用価値を引き出せる可能性がある点だ。ルーティング、監視、ロールアウト、容量計画を簡素化でき、複数の旧モデルを維持することによるGPUの分断も抑えられる。

注意すべき点

企業内のトラフィックは固定されない。新しいツールやプロンプトが追加されれば、評価データが現実から遅れる可能性がある。したがって、ある時点のカバレッジだけでなく、リクエスト分布の変化に対して再評価と再学習がどれだけ速いかが重要になる。

また、LLM評価者の設計にも注意が必要だ。最適化に使ったデータと評価データが近すぎると、モデルが利用者の役に立つのではなく、評価者の好みに合わせる可能性がある。難しい事例での人手評価との一致率や、新しく流入するトラフィックへの性能を継続的に確認する必要がある。

本研究の価値は、ポストトレーニングを一度きりのモデル更新ではなく、本番データ、評価、サービス運用を結ぶ継続的な保守工程として捉えたことにある。

出典：Hugging Face Daily Papers