論文解説: 本番トラフィックから事後学習へ — 社内200アプリを1つの自前LLMに寄せる

データ所在地の制約で自前ホストせざるを得ない企業が、増え続けるモデル群を1つに畳む方法。本番の失敗を人手で分類し、弱い3軸それぞれにGRPO専門家を作り、SLERPで重みを混ぜる。3種類の報酬ハッキングの実例つき。

From Production Traffic to Post-Training: Building a Self-Hosted LLM That Covers the Corporate Request Mix

増え続けるモデルは、静かにGPUを食い潰す

この記事が扱う論文の原題は "From Production Traffic to Post-Training: Building a Self-Hosted LLM That Covers the Corporate Request Mix"（arXiv:2609.01572, T-Tech, 2026年9月1日）です。

要旨を日本語で言い直します。データ所在地の制約により企業はLLMを自前ホストせざるを得ないが、新モデルを採用しても旧モデルを退役させられないため推論用のモデル群が膨れ上がり、有限のGPUプールが断片化する。著者らは本番のエラー分析で見つかった品質のギャップを 命令追従・関数呼び出し・社内タスク分布 の3軸で埋め、200以上の社内アプリのトラフィックを1モデルに統合した。品質は本番トラフィックに層化したオフラインベンチマークで追跡し、決定的な検証器か較正済みLLM審判で採点する。すべての目的を同時に最適化するとドメイン間で報酬が干渉するため、軸ごとに別々のGRPO専門家を訓練し2段階のSLERPで統合する。各専門家の報酬は 意味的崩壊・過剰呼び出し・冗長化ハック という別々の失敗モードを露呈し、それぞれ専用の対処を要した。非推論モードで、総パラメータ数が約7倍のベースラインを社内Arenaで 69.6 対 65.8、命令追従で 0.85 対 0.83、関数呼び出しで 0.79 対 0.77 と上回りつつ、一般対話ベンチマークも押し上げた。このモデルはプラットフォームのトラフィックの50%、月1億1600万リクエストを、はるかに低い提供コストで捌いている。

社食にレーンが増え続ける話に似ています。麺のレーンを足した本当の理由が「カレーのレーンでは麺が出せなかった」だけなら、カレーのレーンが麺も出せるようになればレーンは1本で済む。移行を妨げている理由を本番ログから特定し、そこだけを事後学習で埋める。新アーキテクチャの論文ではなく、社内LLM基盤の運用記録です。

何が足りないのかを、人が数える

論文は推測から始めません。本番の応答から $n{=}2{,}500$ 件をサンプルし、3人のアノテーターが各応答の「主要な失敗」を6カテゴリのどれか1つに割り当て、多数決でラベルを決めました（一致度 Cohen's $\kappa=0.62$、§A.1）。

単独最大は分類ですが、書式と非書式の命令違反を合わせると 37.9% で分類を上回り、しかも決定的な検証器で機械採点できる。「最大かつ自動採点可能」だから専用の専門家を立てる、という論理です。やらない理由も明示されていて、分類の失敗は単一能力ではなく下流の症状の集合で綺麗な報酬信号が取れず、知識ベースの失敗はバックボーンの容量に依存するので制約型の報酬では動かせない。関数呼び出しは別枠で、ツール付きリクエストが全体の約12%。人手評価によれば失敗の主因は、ツール説明がロシア語であること（英語中心モデルには分布外）と、関数の選択ミスではなく引数をロシア語で埋められないこと でした (§A.1)。

本番に似たベンチマークをどう作るか

社内トラフィックは大半がテンプレート化されたリクエストです。論文は綱引きを2指標で定義します (§3)。多様性＝選んだ集合のTF-IDFベクトル間の平均ペアワイズ・コサイン距離、代表性＝本番プールからのJensen-Shannon距離を4次元（問い合わせ先モデル／プロンプト長／サービス／タスク分類）で測ったもの。素朴な手法は両極端に転びます。一様ランダムは分布を保つが重複テンプレートを引き継ぐ（多様性0.653）。貪欲max-minは多様性を追って代表性を壊す（サービス次元のJS距離が0.683まで悪化）。

テンプレート対応サンプラーはこうです。プロンプトを構造セグメントに分割し、数値・識別子・長い文字列リテラルをマスクして正規化。ほぼ同一の列をLSH（局所性鋭敏ハッシュ）でテンプレートにまとめ、テンプレート内では変数部分だけで貪欲max-minを回す。予算配分は件数の平方根 $\sqrt{\text{count}}$ に比例。つまり件数が100倍でも予算は10倍にしかならないブレーキで、頻出テンプレートが全部を占領することも消えることも防ぐ。結果は多様性0.953（全手法中最高）でJS距離ははるかに小さい (Table 1)。

審判は、タスクごとに変えないと人間と合わない

Arena-Hard-Auto を DeepSeek-V3-0324 を審判にして走らせたところ、一様な side-by-side（SBS）審判は専門アノテーターと $\kappa=0.62$ しか一致しませんでした (§3)。分類や情報抽出では審判も人間も同じ正解を参照すべきなのにSBSは「どちらが良いか」しか聞かない。要約やコンテンツ生成では「良い」が未定義で、両者が別基準で採点してしまう。

そこで各リクエストをLLMタスク分類器で振り分け（人間の合意との一致率 90.6〜99.6%）、セグメント別に採点します。分類・情報抽出（約63.2%）は、Kimi-K2.5が生成しアノテーターが検証した正解に対する参照ベース採点（正解はそれぞれ97.7%、85.2%が無修正で受理）。自由記述はペアワイズSBSにRubricHub式のチェックリストを併用。最適な採点レシピはタスクごとに違いました (Table 12)。

同じ審判モデルでも聞き方でこれだけ変わる。全体では $\kappa$ が参照ベースで 0.63 → 0.88、自由記述のコンテンツ生成で 0.57 → 0.72 に上がりました (Table 2)。LLM審判を入れたらまず人間との $\kappa$ を測る、というのが持ち帰るべき教訓です（LLM-as-a-Judge）。