今回の論文
今回取り上げるのは、Xiang Lisa Li、Ari Holtzman、Daniel Fried らによる論文「Contrastive Decoding: Open-ended Text Generation as Optimization」です。2022年10月27日に arXiv で公開された論文で、公開元は arXiv、研究分野は自然言語生成、推論手法、言語モデルデコーディングです。URL は https://doi.org/10.48550/arXiv.2210.15097 です。
この論文を選んだ理由は、モデルを再学習せずに推論だけで出力品質を改善する、実装上かなり使いやすい発想だからです。LLM アプリではモデル本体の差だけでなく、どう出力させるかが品質を大きく左右します。Contrastive Decoding はその代表例で、RAG の回答生成、エージェントの長文出力、文章作成支援などに応用しやすい技術です。
どんな技術か
Contrastive Decoding は、1つの大きな言語モデルだけで次トークンを決めるのではなく、大きなモデルと小さなモデルを比べながら出力を選ぶ推論手法です。
基本の考え方は単純です。大きいモデルが高く評価するが、小さいモデルはそこまで高く評価しないトークンを優先します。逆に、小さいモデルでも簡単に出せてしまうありがちな続きや、繰り返しやすい続きは下げます。これによって、大きいモデルの強みを活かしつつ、小さいモデルに出やすい「安直な続き」を避けようとします。
論文が狙っているのは、長文生成でよく起きる2つの失敗です。1つは同じ表現を繰り返すことです。もう1つは、サンプリングで話が脱線してまとまりを失うことです。Contrastive Decoding はこの間を取り、もっともらしさを保ちながら、単純すぎる続きを避ける方向に推論を誘導します。
課題
この技術が解決しようとしている課題は、LLM のデコーディング戦略が長文品質を大きく左右するのに、既存手法には一長一短があることです。
何が難しいのかというと、言語モデルの「最も確率が高い出力」をそのまま選ぶと、短くて反復的な文章になりやすいからです。greedy decoding や beam search は局所的には筋が通っていても、長文では単調になりやすく、同じ語句をなぞり続けることがあります。
一方で、top-k や nucleus sampling のようなサンプリング系手法は多様性を出しやすいですが、長く生成すると話題が流れやすくなります。つまり、単調さを防ぐためにランダム性を入れると、今度は文脈一貫性が崩れやすくなります。
なぜこの課題を解く必要があるのかというと、実際の AI システムでは「一文だけ正しい」よりも「数段落を通して破綻しない」ことのほうが重要な場面が多いからです。たとえば文章作成支援、RAG の回答生成、エージェントの手順説明、レポート下書きなどでは、途中で話題が飛ぶ、同じ説明を繰り返す、といった問題がそのまま UX の悪化につながります。
既存の方法ではこの問題に対して追加学習や特殊な訓練を入れることもありますが、それは導入コストが高くなります。Contrastive Decoding は、既存の2つの言語モデルを凍結したまま使えるので、モデル再学習なしで改善したい実装現場と相性がよいです。
用語解説
- デコーディング
- 言語モデルの次トークン分布から、実際にどのトークン列を出力するかを決める推論戦略です。同じモデルでもデコーディング次第で品質が大きく変わるため、この論文の中心テーマになります。
- greedy decoding
- 各ステップで最も確率が高いトークンをそのまま選ぶ方法です。安定しやすい反面、長文では反復や単調さが出やすく、Contrastive Decoding が改善したい対象の1つです。
- nucleus sampling
- 確率質量が一定値に達するまでの上位候補からサンプリングする方法です。多様性は出しやすいですが、文脈から外れたトークンも選びうるため、長文では話題逸脱が起きやすくなります。
- expert model と amateur model
- Contrastive Decoding で比較対象として使う大きいモデルと小さいモデルです。大きいモデルの判断を活かしつつ、小さいモデルにも出しやすい無難な続きは相対的に下げる、という構図を理解するために重要です。
- plausibility constraint
- 大きいモデルから見て十分もっともらしい候補だけを残す制約です。単純に確率差だけを見ると不自然な低確率トークンが上位に来ることがあるため、その暴走を防ぐ役割があります。
技術の仕組み
Contrastive Decoding の仕組みは、単なる「2モデル平均」ではありません。大きいモデルが好む続きを採用しつつ、小さいモデルでも説明できてしまう安直な続きを差し引く形でスコアを作ります。
基本アイデア
論文の基本アイデアは、小さいモデルの失敗傾向を「ノイズの方向」として使うことです。小さいモデルは、大きいモデルよりも反復、話題逸脱、自己矛盾のような望ましくないパターンを起こしやすいと考えます。
そこで、ある候補トークンについて、大きいモデルの対数確率から小さいモデルの対数確率を引いた値を評価に使います。大きいモデルだけが相対的に強く支持する候補は上がり、小さいモデルでも出しやすい候補は下がります。
スコアリングの考え方
系列全体では、生成した続き全体に対して次のような目的を最大化します。
「expert が高く評価する度合い」-「amateur も高く評価する度合い」
実際の推論では系列全体を厳密に探索するのは難しいので、各ステップのトークンスコアに分解して beam search で近似します。論文の実装では、各ステップで候補トークンを絞り、その中で contrastive score が高いものを選んでいきます。
plausibility constraint の役割
ここで重要なのが plausibility constraint です。もし確率差だけで選ぶと、大きいモデルでもほとんど確率を置いていない変なトークンが、小さいモデルではさらに低確率だったせいで高スコアになることがあります。
これを防ぐために、まず expert model から見て十分高い確率を持つ候補だけを残します。論文では、その時点の最尤トークン確率に対して一定比率以上の候補を V_head として採用しています。つまり、「大きいモデルが plausible だと思っている範囲の中だけで差分を取る」という設計です。
false positive と false negative への対処
この制約は2種類の失敗を防ぎます。1つ目は false positive で、変なトークンが差分だけで浮上する問題です。2つ目は false negative で、本来正しい簡単なトークンが、大きいモデルでも小さいモデルでも高確率なために差分が小さくなり、不当に不利になる問題です。
Contrastive Decoding は、expert が非常に自信を持っているときほど候補集合を小さくし、簡単な決定ではほぼ expert に従うようにしています。つまり、いつでも差分を強く効かせるのではなく、「迷いやすい場面だけ contrastive にする」設計です。
モデル構成
この手法に特別な新規モデル構造は必要ありません。必要なのは、同じ系列を読める大きな言語モデルと、その下位互換のように振る舞う小さな言語モデルです。
論文では、GPT-2 XL を expert、GPT-2 small を amateur にする組み合わせや、OPT-13B を expert、OPT-125M を amateur にする組み合わせを使っています。ポイントは、同じファミリー内でサイズ差をつけることです。著者らは、amateur が小さすぎて完全に無関係な失敗ばかりすると、expert の欠点補正としては役に立ちにくいと述べています。
学習方法
学習は不要です。既存モデルをそのまま凍結して推論時に組み合わせます。ここが実務上の大きな利点です。
LoRA や追加ファインチューニングを回さずに改善余地を作れるので、API 利用や推論基盤の工夫で品質を上げたいケースに向いています。特に、モデルそのものを触れない環境でも、ローカルに置いた小型モデルを amateur として併用する形は考えやすいです。
推論の流れ
推論フローを簡単に言うと、次の順番です。
1. expert model が次トークン候補の確率分布を出す
まず大きいモデルが次トークンの確率を計算します。
2. plausible な候補だけを残す
expert の最有力候補に対して十分高い確率を持つ候補だけを残します。
3. amateur model でも同じ候補を評価する
小さいモデルの確率も計算し、各候補について expert と amateur の対数確率差を求めます。
4. 差分が大きい候補を選ぶ
大きいモデルは支持するが、小さいモデルはあまり支持しない候補を優先します。
5. これを各ステップで繰り返す
beam search と組み合わせながら、系列全体の続きを組み立てていきます。
実験と結果
論文では、Contrastive Decoding が本当に長文生成の品質を上げるかを、自動評価と人手評価の両方で検証しています。
何を検証したのか
主な検証点は、繰り返しを抑えつつ、多様性と一貫性をどこまで両立できるかです。比較対象としては、greedy decoding、top-k sampling、nucleus sampling、typical decoding、contrastive search などが使われています。
対象ドメインは Wikipedia、ニュース、ストーリー生成の3種類です。各サンプルでは先頭32語をプロンプトにして、256トークンの続きを生成しています。つまり、かなり長めの open-ended generation で比較しています。
どんなデータセットや評価指標を使ったのか
データセットは、ニュース領域で Wikinews、Wikipedia 領域で WikiText-103、ストーリー領域で BookCorpus の Project Gutenberg split を使っています。
評価指標は大きく3つです。1つ目は diversity で、n-gram の反復率を集約した指標です。2つ目は MAUVE で、生成文集合が参照文集合にどれだけ近い分布かを見る指標です。3つ目は coherence で、プロンプトと生成文の埋め込み類似度を SimCSE ベースで測っています。
さらに、人手評価では fluency と coherence の2軸で比較しています。評価者は同じプロンプトに対する2つの生成結果を読み、どちらが自然で一貫しているかを選びます。
どのような結果が出たのか
自動評価では、Contrastive Decoding は GPT-2 XL と OPT-13B の両方で、3ドメインすべてにおいて MAUVE と coherence で最良でした。たとえば OPT-13B では、Wikipedia の coherence が nucleus sampling の 0.55 に対して CD は 0.69、story ドメインでは 0.48 に対して 0.62 でした。GPT-2 XL でも、Wikipedia の MAUVE が nucleus sampling の 0.87 に対して CD は 0.92、story の coherence は nucleus sampling の 0.46 に対して CD は 0.64 でした。
diversity だけを見ると、typical decoding や nucleus sampling のほうがやや高い条件もあります。ただし論文では、その差は「無作為に散ること」で得た多様性であり、CD は一貫性を維持したまま十分な多様性を保てていると解釈しています。特に search 系手法の中では、CD は大きく多様性を改善しています。
人手評価でも、Contrastive Decoding は coherence で強い結果を出しました。著者らによる集計では、平均すると CD は nucleus sampling より 2.6 倍、typical decoding より 6.4 倍多く coherence で好まれました。fluency でも、nucleus sampling より 1.4 倍、typical decoding より 3.5 倍好まれています。
結果から何が言えるのか
この結果から言えるのは、長文生成では「確率最大化」か「ランダムサンプリング」かの二択ではなく、別サイズモデルの差分を使って出力を整える第三の選択肢が有効だということです。
また、推論時だけの工夫でも品質改善余地がかなりあることが分かります。モデル本体を大きくするだけではなく、どのトークンを採用するかの意思決定を工夫することが、プロダクト品質に直結するという示唆があります。
何に使える？
Contrastive Decoding は、長文をある程度安定して生成したい場面で使いやすいです。
RAG の回答生成
RAG では、取得した文書に基づいて数段落の回答を返すとき、話題逸脱や繰り返しが起きると信頼感が落ちます。Contrastive Decoding を使うと、ランダム性を入れすぎずに、単調な繰り返しも抑えられる可能性があります。特に、説明文や比較文のような長めの生成で相性がよさそうです。
AI エージェントの行動説明
エージェントが実行計画や作業ログを文章でまとめる場面でも有効です。手順説明は長くなりやすく、同じ表現を繰り返すと読みづらくなります。Contrastive Decoding は、無難な反復を減らしつつ、文脈に沿った説明を保つのに役立つ可能性があります。
ライティング支援や下書き生成
メール下書き、記事草案、仕様説明などでは、temperature を上げすぎると脱線し、greedy だと硬すぎることがあります。Contrastive Decoding はその中間案として使えます。文章のまとまりを重視する B2B 向け支援ツールでは特に扱いやすいはずです。
モデル比較や推論A/Bテスト
推論基盤を持っているチームなら、expert と amateur の組み合わせを変えて品質比較するだけでも知見が得られます。どの小型モデルが「悪い癖」をうまく炙り出せるかを見ることで、モデル族ごとの失敗傾向の分析にもつながります。
低コスト品質改善
追加学習や大規模評価ループを回す前に、推論戦略の調整でどこまで改善できるかを見る用途にも向いています。プロダクト初期では、学習コストをかける前に推論だけで UX を底上げできるかを検証する価値があります。
開発や事業へのヒント
この論文から得られるヒントは、LLM プロダクトの差別化はモデル選定だけでなく、推論設計にも大きく依存するということです。
まずは学習より推論を見直す
出力が単調、長文で脱線する、といった問題に対して、すぐファインチューニングへ進む前にデコーディング改善を試す価値があります。Contrastive Decoding のような手法は、モデル再学習なしで効く可能性があるため、PoC 段階では特に費用対効果が高いです。
小型モデルを補助輪として使う発想
多くの現場では小型モデルを「代替品」として考えがちですが、この論文では「大きいモデルの欠点を炙り出す補助輪」として使っています。この発想は面白く、分類器やリランカー、異常検知でも「弱いモデルとの差分」を品質制御に使えるかもしれません。
RAG や社内文書生成に向く
事業用途では、創造性よりも整合性が重要なケースが多いです。社内ナレッジ検索、FAQ 自動応答、報告書ドラフト生成などでは、奇抜さより一貫性が価値になります。Contrastive Decoding はその方向に寄せやすいので、エンタメ生成より業務文書系で先に刺さる可能性があります。
推論レイヤーをプロダクト資産にする
API 経由で同じ基盤モデルを使うサービスが増えるほど、差は「前処理」「検索」「デコーディング」「後処理」に移ります。Contrastive Decoding のような推論レイヤーの工夫は、そのままプロダクト独自性になりえます。モデルそのものを持てないチームでも競争余地を作れるポイントです。
限界
Contrastive Decoding にも注意点があります。まず、推論時に expert と amateur の両方を走らせるので、単一モデルより計算コストは増えます。論文では小さい amateur を使うことでオーバーヘッドを抑えられるとしていますが、レイテンシが厳しい本番環境では要検証です。
次に、この手法は open-ended generation で強い一方、必ずしも事実性やタスク正答率を直接保証するものではありません。出力が自然でも、知識そのものが誤っていれば間違った説明を流暢に出す可能性は残ります。
また、amateur model の選び方に依存します。小さすぎるモデルや、expert と性質が離れすぎたモデルを選ぶと、差分が有効な補正として働かないことがあります。論文でも、同一ファミリー内で十分なサイズ差を持たせる構成が良いと報告しています。
さらに、beam search ベースでの実装やハイパーパラメータ調整が必要になるので、単純な sampling より実装難度は上がります。特に、API だけで完結する商用 LLM では内部確率や複数モデルの同時評価が取りにくく、完全再現は難しい場合があります。
最後に、この論文の評価対象は主に英語の open-ended text generation です。日本語、対話特化、コード生成、ツール呼び出し前提のエージェントなどでは、同じ効果がどこまで出るかは個別検証が必要です。この点は推測ではなく、論文の評価範囲から見た妥当な留保です。
よくある質問
Q. Contrastive Decoding は Contrastive Search と何が違うのですか？
A. Contrastive Search は同一モデル内部の表現や履歴との関係を使って反復を抑える考え方ですが、Contrastive Decoding は大きいモデルと小さいモデルの確率差を使います。つまり、別サイズモデル間の「能力差」を直接デコーディングに使う点が大きな違いです。
Q. 既存の LLM アプリにすぐ導入できますか？
A. 自前でモデル推論を持っていて、両モデルのトークン確率を取得できるなら比較的導入しやすいです。一方、閉じた商用 API しか使えず、内部確率や補助モデルを扱えない構成では実装しにくいです。
Q. なぜ小さいモデルをわざわざ一緒に使うのですか？
A. 小さいモデルは失敗しやすいので、その失敗方向を罰則として使えるからです。expert だけでは見抜きにくい「ありがちな続き」や「単調な繰り返し」を、amateur との比較で浮かび上がらせるのが狙いです。
Q. RAG の hallucination 対策としてそのまま使えますか？
A. 一部の改善は期待できますが、根本的な hallucination 対策としては不十分です。Contrastive Decoding は主に出力の一貫性や退化抑制に効く手法なので、事実性を高めるには検索品質、根拠参照、引用制御などと組み合わせる必要があります。
Q. 小規模チームでもこの考え方を活かせますか？
A. 活かせます。大規模研究のように多数モデルを比較しなくても、まずはローカルの小型モデルを補助的に使い、長文出力の品質差を A/B テストするだけでも価値があります。特に、業務文書生成や説明文生成では試す余地があります。
今日の学び
この論文は、長文生成で起きやすい反復や話題逸脱という課題を扱いました。そこに対して、大きな言語モデルと小さな言語モデルの確率差を使い、plausibility constraint で不自然な候補を除きながら出力を選ぶ Contrastive Decoding で解こうとしました。
ここから得られるヒントは、LLM の品質改善は学習だけでなく推論設計でも進められるということです。特に、RAG、エージェント、業務文書生成のように長文の安定性が重要なプロダクトでは、デコーディング自体を開発対象として見る価値があります。