--- title: "MixLMとは？LinkedInのLLMランキングの採点件数を10倍にした埋め込み混合入力の仕組みとSGLangでの組み方" url: "https://www.issoh.co.jp/tech/details/10321/" published: 2025-12-18 updated: 2026-11-10 categories: ["LLM・RAG"] publisher: "株式会社一創" --- # MixLMとは？LinkedInのLLMランキングの採点件数を10倍にした埋め込み混合入力の仕組みとSGLangでの組み方 MixLMは、LinkedInの研究者らが2025年11月25日にarXivで公開したLLMベースのランキング手法です（[arXiv:2512.07846](https://arxiv.org/abs/2512.07846)、改訂版v2は2026年1月31日）。候補文書の本文をあらかじめ埋め込みトークンに圧縮しておき、推論時はクエリのテキストと混ぜてランカーLLMに入力します。中央値で約900トークンある求人の説明文を埋め込み1トークンに置き換え、同じ遅延予算のもとで、要約テキストを入力する従来方式の10.0倍、全文入力の75.9倍の候補を採点しました。 この記事では、論文v2の数値で仕組み・学習・実験結果を整理したうえで、2026年2月に出た後続論文に書かれた本番での使われ方と、推論エンジンSGLangで同じ形の入力を組む方法までをまとめます。CRANで配布されている同名のRパッケージ「mixlm」（混合モデルANOVA用）は別物で、本記事では扱いません。 ## まとめ：MixLMの要点と検討すべき条件 - **何をするか**：候補文書をエンコーダLLMで埋め込みトークンに圧縮してニアラインキャッシュに保存し、推論時はクエリのテキストと埋め込みを混ぜた短い入力でランカーLLMに関連度を判定させる。 - **効果**：p99遅延500ms以内で1GPUあたり毎秒22,000件を採点。従来の本番方式（2,200件）の10.0倍、全文入力（290件）の75.9倍。NDCG@10は0.9239で、全文入力の0.9432との差は0.0193。 - **本番での位置**：LinkedInのセマンティック検索では、埋め込み検索で集めた候補の上位250件を再ランクする小型LLMの入力を短くする手段として使われている。MixLMを使ったセマンティック求人検索は、従来の求人検索とのA/BテストでDAUが0.47%増えた。 - **実装の現在地**：2026年11月時点の確認範囲では、MixLM論文に公式コードやモデル重みの公開先は記載されていない。推論側の部品はSGLangに入っており、Score APIで候補の特定トークンを事前計算した埋め込みに差し替えられる。エンコーダとランカーの同時学習は自前で組む必要がある。 - **RAGへの当てはめ**：論文はRAGで評価していない。1クエリで数百件以上を採点し、文書の埋め込みを複数の検索で再利用でき、ランキング用の学習データを用意できるときに検討する。上位20〜50件を並べ替えるRAGなら、既製のリランカーで遅延と精度を測るのが先。 ## MixLMが解いた問題：LLMランキングの入力長 ### LinkedIn求人検索で必要だった採点量 MixLMの適用先は、自然言語の質問から求人を探すLinkedInのセマンティック求人検索です。この検索のランキング層は、製品全体で毎秒約315万件の候補を採点する必要がありました（MixLM論文の付録9.4）。 LLMでクエリと求人の関連度を判定すると精度は上がりますが、求人の説明文が中央値900トークン、最大2,100トークンあり、入力の大半を占めます。LinkedInは前段の研究（[Behdinら、arXiv:2510.22101](https://arxiv.org/abs/2510.22101)）で、説明文のニアライン要約とモデルの枝刈りによって入力長を最大10分の1に縮め、限定トラフィックでLLMランキングを出していました。それでも全トラフィックへの展開には入力長が障害として残り、その解決策として作られたのがMixLMです。 ### クロスエンコーダ型ランキングのプリフィル負荷 クエリと文書を1つのプロンプトにまとめてLLMに読ませる方式は、[クロスエンコーダ](/tech/details/16051/)型のランキングです。クエリと文書の語同士が注意機構で直接作用するので精度は高い一方、候補1件ごとに長いプロンプトを処理します。出力は「Yes／No」の確率だけなので、計算のほぼすべてが入力を読むプリフィルに費やされ、注意機構の計算量は入力長の2乗で増えます。 クエリと文書を別々にベクトル化して内積で比べるバイエンコーダは、候補ごとにLLMを通さないので高速ですが、クエリと文書の語同士の作用を捉えません。論文の比較でも、LLMの判定を蒸留した埋め込み検索のNDCG@10は0.8380で、候補を粗く絞る第1段の役割にとどまります。MixLMは、文書側だけを事前計算して短くし、クエリとの作用はLLMの中に残す設計です。 ## MixLMの仕組み：テキストと埋め込みトークンの混合入力 ### エンコーダLLMとランカーLLMの2モデル構成 MixLMは、文書を圧縮するエンコーダLLMと、関連度を出力するランカーLLMの2つで構成されます。エンコーダは文書の本文を読み、最後のN個の入力トークンに対応する隠れ状態だけを取り出します（論文では「last N sampling」）。本番ではN=1、つまり文書1件を埋め込み1トークンにしています。この埋め込みはクエリに依存しないので、ニアラインで計算してキャッシュに置けます。 推論時は、システム指示とクエリのトークンの後ろに、キャッシュから取り出した文書の埋め込みと終端トークンを連結し、ランカーのTransformerに通します。2つのモデルは隠れ次元さえ一致すれば構造が違ってもよいとされていますが、LinkedInは学習効率のために両方とも0.6Bパラメータの同じ構造を使いました。 ### ランカーに渡すプロンプトの形 全文入力の教師モデルと、MixLMのランカーに渡すプロンプトは次のとおりです（論文4.1.2・4.1.3節）。違いは候補欄だけで、MixLMでは求人本文の代わりにエンコーダの出力が入ります。 ``` # 全文入力（教師モデル） [SYSTEM]: Output only 'Yes' or 'No' based on how well the item matches the query; no extra text. [QUERY]: [CANDIDATE]: yes or no ? # MixLM（ランカーLLM） [SYSTEM]: Output only 'Yes' or 'No' based on how well the item matches the query; no extra text. [QUERY]: [CANDIDATE]: # エンコーダLLMへの入力 Item information: ``` ランキングは点ごとの2値分類として扱い、「Yes」の確率をそのまま関連度スコアにします。複数の候補を一度に並べるsetwise・listwise方式は論文の対象外です。 ### 共有プレフィックスによるプリフィルの償却 1回の検索では、同じクエリに対して数百〜数千件の候補を採点します。文書が埋め込み1トークンまで縮むと、計算の大半は全候補で共通のクエリ部分になるため、クエリ部分のKVキャッシュを1回だけ計算して使い回します。論文は共有プレフィックスの計算を省く実装を2つ挙げています。 - **バッチ内プレフィックスキャッシュ**：最初のプロンプトのKV状態を再利用し、同じバッチの全候補でクエリ部分の計算を共有する。 - **マルチアイテム採点**：複数の候補を区切りトークンでつないで1本の系列にし、FlashInferのマスクで候補同士の注意を遮断する。SGLangの[プルリクエスト#10979](https://github.com/sgl-project/sglang/pull/10979)（2025年10月9日マージ）として実装された。 論文の試算では、候補250件・圧縮率450倍（約900トークンを2トークンへ）のとき、候補側の注意と線形層の計算量はおよそ450分の1になります。 ## 学習パイプライン：3段階の学習と蒸留損失 MixLMは、エンコーダの出力がランカーの入力埋め込みと同じ空間に乗るよう、2つのモデルを同時に学習させます。学習は3段階です（論文の表1）。 | 段階 | データ | 件数 | 最大系列長 | 学習対象 | | ------------------- | ----------- | ------ | ----- | ---------- | | I：ドメイン推論の微調整 | 判定LLMの推論過程 | 18万 | 2,048 | 事前学習済み0.6B | | II：教師ランカーの学習 | 全文のランキングデータ | 1,090万 | 2,048 | ランカー | | III：エンコーダとランカーの同時学習 | 同上（埋め込み入力） | 1,090万 | 2,176 | エンコーダ＋ランカー | 正解ラベルは、実ユーザーのログから取ったクエリと求人の組を社内の7Bの判定LLMが0〜4の5段階で採点し、0〜1に正規化したものです。第1段階で7Bモデルの推論過程を0.6Bモデルに蒸留し、第2段階で全文を読む教師ランカーを作ります。教師ランカーは入力が長すぎて本番には出せませんが、第3段階の手本になります。第3段階では、ランカーを第1段階のチェックポイントから、エンコーダを対照学習済みの0.6BのGTE（General Text Embedding）モデルから初期化します。 第3段階の損失は3種類です。正解ラベルとのKLダイバージェンス、教師ランカーの出力分布とのKLダイバージェンス（蒸留）、同じランカーに全文を入れたときと埋め込みを入れたときの最終隠れ状態・出力確率を近づける自己整合損失です。前半は整合の重みを大きくして埋め込み空間をそろえ、後半は蒸留の重みを大きくして関連度の予測を詰める2フェーズのカリキュラムで学習します。 小規模データでのアブレーションでは、ドメイン推論の微調整がNDCG@10を0.0185、蒸留が0.0091押し上げ、自己整合単体は0.0014でした。効きの大半は第1段階と蒸留が担っています。計算資源は、H100を8基積んだノード8台で、ランキング目的の700億トークンの学習に約700 H100 GPU時間です。 ## 実験結果：NDCG@10とスループットの比較 評価は、社内の判定LLMがラベル付けしたテストセットのNDCG@10（上位10件の順位品質を測る指標で、高いほど良い）と、p99のエンドツーエンド遅延500ms以内で1GPUが1秒に採点できる最大件数で行われました（論文の表3・表4）。 | 方式 | NDCG@10 | 件/秒/GPU | GPU | | --------------- | ------- | --------------- | ---- | | 全文入力のLLMランカー | 0.9432 | 290 | H100 | | 要約入力＋枝刈り（従来の本番） | 0.9218 | 2,200 | H100 | | MixLM | 0.9239 | 22,000 | H100 | | 埋め込み検索（第1段） | 0.8380 | 16億超（遅延100ms未満） | A100 | MixLMは従来の本番方式と同等以上の精度のまま、採点件数を10倍にしました。全文入力との差0.0193は、精度の上限を少し手放してスループットを買った分です。オンラインA/Bテストでは、従来のキーワード型求人検索と比べてDAUが0.47%増えました。この増分は、LLMランキングを全ユーザーに出せるようになった結果であり、ランキング精度そのものが上がった効果とは分けて読む必要があります。 推論最適化のアブレーション（論文の表10）では、入力圧縮だけの構成は毎秒3,000件、マルチアイテム採点を使う構成は20,000件、バッチ内プレフィックスキャッシュを使う構成は22,000件でした。全文入力では同じ最適化を使っても270件から290件にしか伸びません。入力を短くしたうえで共有プレフィックスの計算を削って、初めて桁が変わります。 精度を取り戻したい場合の調整つまみは、文書あたりの埋め込みトークン数（1から50に増やすとNDCG@10が+0.0198）と学習データ量（16万件から108万件で+0.0334）です。本番は遅延制約から1トークンに据え置いています。 ## LinkedInのセマンティック検索でのMixLMの位置づけ 2026年2月7日に公開された[「Semantic Search At LinkedIn」（arXiv:2602.07309）](https://arxiv.org/abs/2602.07309)は、求人検索と人物検索を含むLinkedInのLLM検索基盤全体を説明した論文で、MixLMはその部品の1つとして登場します。MixLM論文だけでは分からない、本番での使われ方がここに書かれています。 ### 上位250件を再ランクする小型LLMの入力圧縮 検索は2段構成です。GPUで全件を走査する埋め込み検索が候補を集め、小型言語モデル（SLM）のランカーが上位250件を再ランクします。このSLMは関連度とエンゲージメントを同時に予測するよう、複数の教師モデルから蒸留されています。MixLMは、構造化枝刈り・説明文の事前要約と並ぶ入力圧縮の手段として、このSLMの推論コストを下げる役割です。後続論文の記述では、MixLMは要約テキスト入力のSLMの約10倍、生テキスト入力の約76倍のスループットを同じ遅延予算で出し、LLMランキングを全面展開できるようにしたとされています。 ### 推論基盤：埋め込みの直接注入とCPU側の詰まり 推論エンジンは、テキストと埋め込みが混ざった入力をそのまま受け付けるよう拡張されています。埋め込みはバイナリで送られてモデル入力に直接差し込まれ、テキストだけのリクエストとも後方互換を保っています。文書が埋め込み1トークンになるとGPU計算は共有プレフィックスに比べて無視できるほど小さくなり、スループットはCPU側の処理で決まります。後続論文の表13（0.6Bランカー・H100・p99 500ms以内）は、次のように変わったと報告しています。 | 構成 | 件/秒/GPU | | ---------------------- | ------- | | gRPCサーバー1＋SGLangワーカー1 | 約10,000 | | 多プロセス（gRPC 6＋SGLang 6） | 約19,500 | | 多プロセス＋CUDAグラフ | 約22,000 | MixLM論文の側でも、PythonのgRPCサーバーがGILと単一のイベントループで頭打ちになったため前処理を複数プロセスに分けた、同じクエリの候補を1つのZMQメッセージにまとめて1バッチで扱わせた、デコードをしないのでリクエスト完了直後にKVキャッシュを解放した、といった対処が挙がっています。文書の埋め込みは、Flyteで組んだオフラインの定期再生成と、候補の追加・変更を取り込むニアライン生成の2経路で作られます。遅延を気にしなくてよい埋め込み生成と、リアルタイムの採点を分ける構成は、[オンライン推論とバッチ推論の分担](/tech/details/16347/)の典型です。 ### 運用面の上乗せ：スコアキャッシュと採点深さの調整 モデルの外側でも計算を減らしています。同じ利用者・クエリ・候補の組なら関連度スコアは同じなので、採点済みの結果をCouchbaseベースの分散ストアにキャッシュし、本番では採点リクエストの50%超がキャッシュから返ります。混雑時には、PID制御で1クエリあたりの採点件数を平均250件から130件に減らし（GPU計算は48%減）、空いている時間帯に深く採点します。学習側では、GPU利用率を見て設定を提案するエージェントをMixLMの学習に適用し、学習時間を13%（H100 64基で256 GPU時間）短縮しました。 ### システム全体の成果とMixLMの寄与の切り分け 後続論文は、従来のDLRM型ランキングと比べて求人検索でNDCG@10が7.73%改善、上位10件の不適合率（PMR@10）が46.88%減、人物検索でNDCG@10が10%超改善、公開以降のDAUが1.2%超増えたと報告しています。これはSLMの蒸留・枝刈り・要約・MixLM・推論基盤をすべて含めたシステム全体の数字です。MixLM論文のスループット10倍は方式間の比較ですが、DAU+0.47%はMixLMを含むセマンティック求人検索と従来検索の比較であり、MixLM単体の寄与を分離した数値ではありません。MixLMの効果として引用できるのは、同じ遅延予算で採点件数が10倍になったという方式間の比較です。 ## SGLangでのMixLM型採点の組み方：Score APIの埋め込み差し替え MixLMの重みは公開されていませんが、「候補を埋め込みで渡し、Yes／Noの確率で採点する」推論の形は、SGLangのScore APIで組めます。2026年4月9日にマージされた[プルリクエスト#20960](https://github.com/sgl-project/sglang/pull/20960)で、プレースホルダーにしたトークンの位置だけを事前計算したベクトルに差し替える機能が入りました。v0.5.23（2026年11月2日リリース）の`Engine.score()`には、`embed_override_token_id`（差し替え位置の目印にするトークンID）と`item_embed_overrides`（候補ごとの差し替えベクトル）の引数があります。 次の例は、v0.5.23のソースで引数名と型を確認して書いた呼び出しの形です（GPUでの実行は本記事では行っていません）。ランカーには隠れ次元1,024のQwen3-0.6Bを仮に置いています。MixLMのように学習したエンコーダとランカーの組でなければ、差し替えたベクトルにも意味のあるスコアは付かない点に注意してください。 ``` import sglang as sgl import torch from transformers import AutoTokenizer MODEL = "Qwen/Qwen3-0.6B" # 隠れ次元1024。本番ではMixLM方式で学習したランカーに置き換える tok = AutoTokenizer.from_pretrained(MODEL) llm = sgl.Engine(model_path=MODEL) PLACEHOLDER = tok.convert_tokens_to_ids("<|fim_pad|>") # 本文に出ない特殊トークンを差し替え位置にする EOS = tok.convert_tokens_to_ids("<|im_end|>") yes_id = tok.encode("Yes", add_special_tokens=False)[0] no_id = tok.encode("No", add_special_tokens=False)[0] prompt = ( "[SYSTEM]: Output only 'Yes' or 'No' based on how well the item matches the query; no extra text.\n" "[QUERY]: remote backend engineer python\n" "[CANDIDATE]: " ) query_ids = tok.encode(prompt, add_special_tokens=False) # ニアラインで計算済みの候補埋め込み（1候補1ベクトル、長さはランカーの隠れ次元） cached = torch.randn(3, 1024) # 例示用の乱数。実際はエンコーダLLMの出力を読み込む items = [[PLACEHOLDER, EOS] for _ in range(len(cached))] item_overrides = [[vec] for vec in cached] result = llm.score( query=query_ids, items=items, label_token_ids=[yes_id, no_id], apply_softmax=True, embed_override_token_id=PLACEHOLDER, item_embed_overrides=item_overrides, ) print(result.scores) # 候補ごとに [P(Yes), P(No)] llm.shutdown() ``` 候補を1本の系列にまとめて採点するマルチアイテム採点は、v0.5.23では`--enable-mis`で有効にします。アテンションバックエンドはFlashInferが必須で、CUDAグラフ・radixキャッシュ・chunked prefillは自動で無効になります。MixLM論文ではマルチアイテム採点の構成よりバッチ内プレフィックスキャッシュの構成のほうが速かった（20,000件対22,000件）ので、どちらが速いかは自分の候補数とモデルで測って決めます。 学習側は公開部品がありません。ランカーの入力埋め込み空間にエンコーダの出力を合わせる第3段階の同時学習と、教師ランカーからの蒸留を自分で実装することになります。推論の形だけ先に作り、学習データと判定基準がそろってから学習に進むのが現実的な順番です。 ## RAGのリランカーにMixLMの考え方を持ち込む判断 MixLMの論文が評価したのは求人検索のランキングで、RAGの回答品質や遅延は測っていません。RAGパイプラインのリランク段で使えるかは、次の条件で判断します。 ### MixLMの検討条件：多数候補と埋め込みの再利用 - **1クエリで採点する候補が数百件以上**：利得は共有プレフィックスの償却と掛け算で効くので、候補数が多いほど大きい。論文の試算も、LinkedInの本番の再ランク対象も250件です。 - **文書の埋め込みを再利用できる**：社内文書や商品カタログのように、採点前に文書をエンコードしておき、その埋め込みを複数の検索で使い回せる場合に向きます。 - **ランキング用の学習データと判定基準を持っている**：LinkedInは7Bの判定LLMで1,090万件のラベルを作っています。自社の関連度基準でランカーを学習させる体制が前提です。 ### 既製リランカーを優先する条件：少数候補と更新負担 - **上位20〜50件を並べ替えるだけのRAG**：この規模なら[既製のリランクモデル](/tech/details/4413/)で候補全件を採点し、文書長・同時リクエスト数・必要精度を含めて遅延と費用を測るのが先です。要件を満たせるなら、MixLMの学習基盤を自作する理由はありません。 - **文書が頻繁に入れ替わる、またはユーザーが都度アップロードする**：検索のたびに同期エンコードが必要になり、埋め込みを再利用できないなら生成費用と待ち時間が加わります。更新から検索までの猶予と再利用回数で判断します。 - **ランカーを頻繁に差し替える**：エンコーダはランカーの入力空間に合わせて同時学習しているため、エンコーダの重みや埋め込み仕様を更新したら、文書の埋め込みキャッシュを作り直す必要があります。既製モデルの乗り換えのような気軽さはありません。 RAGで遅延が問題になっているなら、まずリランク対象の件数を絞る、チャンクを短くする、[vLLM](/tech/details/15786/)やSGLangのプレフィックスキャッシュを有効にする、といった既存手段で足りるかを測ります。MixLMは、それでも候補数を減らせない大規模な検索・推薦で効く選択肢です。検索とリランクの構成を含めたRAGの設計から見直す場合は、[RAG構築支援](/service/ai/rag/)で要件の整理から相談できます。 ## よくある質問 ### MixLMのコードやモデルは公開されていますか？ 2026年11月時点で、論文に公式の実装リポジトリやモデル重みの記載はありません。推論側では、マルチアイテム採点（SGLangのプルリクエスト#10979）と埋め込み差し替え（同#20960）がSGLangに入っており、後続論文も採点向けの推論スタックをSGLangの一部として公開したと書いています。 ### RのmixlmパッケージとMixLMは同じものですか？ 別物です。[CRANのmixlm](https://cran.r-project.org/package=mixlm)はKristian Hovde Liland氏が保守する混合モデルANOVAと統計教育用のRパッケージ（2025年8月20日公開の1.4.3）で、lm()やglm()の式にr()を加えて変量効果を扱います。LLMとは関係ありません。 ### MixLMを使うとRAGの回答精度は上がりますか？ 上がるとは言えません。MixLMの目的は精度を保ったままスループットを上げることで、論文でもNDCG@10は全文入力の0.9432より低い0.9239です。同じGPUで採点できる候補数を増やすための手法です。 ### 文書1件は何トークンに圧縮されますか？ 本番では埋め込み1トークン（終端トークンを含めて2トークン）です。中央値約900トークンの求人説明文を置き換えています。小規模データの比較では埋め込みトークン数を1から50に増やすとNDCG@10が0.0198上がりましたが、遅延制約から1に固定しています。 ### ColBERTとの違いは何ですか？ [ColBERT](/tech/details/16049/)は、BERTで符号化した文書のトークンごとのベクトルを保存し、各クエリトークンに対する文書トークンの最大類似度を合計して採点します。候補ごとにランカーLLMへ入力を渡す処理はありません。MixLMは圧縮した文書の埋め込みをクエリと同じ系列に並べてランカーLLMに通すので、クエリと文書の作用はTransformerの注意機構の中で起きます。 ## 関連記事 - [クロスエンコーダとは？バイエンコーダとの違いと精度・速度の判断基準【2026年版】](/tech/details/16051/) - [リランクモデル（リランカー）とは？種類・2026年の代表モデルと選び方](/tech/details/4413/) - [ColBERTとは？遅延相互作用の仕組みとRAG検索精度への効果・導入判断【2026年版】](/tech/details/16049/) - [vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説](/tech/details/15786/) - [オンライン推論とは？バッチ推論との違いと遅延・コスト設計を実装目線で解説【2026年版】](/tech/details/16347/) --- 出典: [MixLMとは？LinkedInのLLMランキングの採点件数を10倍にした埋め込み混合入力の仕組みとSGLangでの組み方]()（株式会社一創）