大規模言語モデル（LLM）は、一度に全情報を与えられれば正確に回答するが、対話を通じて断片的に情報を与えられると精度が著しく低下する。これは、不完全な情報から生成した過去の自らの推論にモデルが引きずられる「自己アンカー・ドリフト」が原因である。本動画では、この問題を解決する新手法「CCOPD」を解説する。全情報を把握する教師モデルが、断片的な情報しか持たない生徒モデルに対し、トークンレベルのKLダイバージェンスを用いて正しい確率分布へ導く仕組みである。数学やコード生成のタスクで大きな精度向上を示す一方、複雑な自然言語タスクにおける課題やマルチエージェントシステムへの影響も考察する。
LLMがマルチターン対話で失敗する理由
コミュニティの皆さんこんにちは、お会いできてとても嬉しいです。本日は非常にシンプルな問題でありながら、その解決策が非常に興味深いテーマを取り上げます。同じ証拠が提示されているのに異なる答えが返ってくるという事象についてお話ししますが、どうしてこんなことが可能なのでしょうか。2026年5月28日に中国科学技術大学から素晴らしい最新の研究が発表されました。彼らが論じているのはまさにこの点で、AIに同じ証拠を与えたにもかかわらず、AIから異なる回答を受け取るという問題です。一体どうしてこんなことが起こるのでしょうか。少しエージェントやマルチエージェントについて考えてみてください。彼らは今回、エージェント間やエージェントと人間との間で行われるマルチターンの言語モデル対話に向けた、カノニカル・コンテキスト・オンポリシー蒸留について調査しています。では、何が問題なのか見ていきましょう。
物理学や金融、化学、あるいは複雑な問題について話しているとしましょう。LLMに一度にすべての情報を与えれば、質問に正確に答えることができます。しかし、同じ情報であっても、特定のエージェントとの複数回のやり取り、つまりマルチターンのコミュニケーションを通じて少しずつ情報が提供されると、LLMは完全に失敗してしまうことが分かりました。相手は人工知能なのにどうしてこんなことが起こるのかと不思議に思うかもしれませんね。ユーザーがタスクの実行を依頼する際、完全にフォーマットされたプロンプトを指定することは滅多にありません。人間として会話をする中で、AIとの何度かのやり取りを経て制約条件などを明らかにしていくからです。タスクに関連するユーザー情報が段階的に少しずつ提供されるマルチターンのやり取りは、基本となる信頼性の基準です。つまり、あなたが完璧な人間であり、最初から単一のプロンプトですべての情報を提供し、不明確な点も尋ねるべきことも一切残されていない場合と同じ結果を、AIモデルに求めるものなのです。詳しく見ていきましょう。
生の断片化された履歴と失敗の構造
アイデアはシンプルです。AIマシンにタスクを依頼する際、完全な情報が与えられ、すべての要件が明確に指定されていれば、未知の事実がないためマシンは完全に正しい答えを返します。でもちょっと待って、これらを異なる断片として連結したらどうなるのかと疑問に思うかもしれません。断片1があり、入力中だと伝えてから、ああそういえば断片2もありましたと入力し、その5分後に、そうそう断片3として追加の境界制限や温度制限などがありますと入力するとします。これらをプロンプト内で連結すれば、やはり正しい答えが返ってきます。しかしここからが面白いところです。もしAIと会話をしたらどうなるでしょうか。自分が最初から完璧なプロンプトを定義できる完璧な人間ではなく、AIと対話しながら進めたらどうなるかということです。著者らはこれを生の断片化手法と呼んでいます。情報の断片1があり、AIシステムがそれを処理して回答を提供します。次に全く同じ断片2があり、エージェントがそれを処理して回答を提供し、全く同じ断片3でも同様にします。すると、最終的な結果が異なってしまうのです。AIマシンの最終的な回答が間違ったもの、完全に不正確なものになります。
一体何が起きているのか、どうすれば解決策を見つけられるのかと思われるでしょう。この現象については、2025年5月末に発表された構造化フローベンチや、マルチターンでの指示追従に関するベンチマークの論文を通じて、1年ほど前から知られていました。システムに何か問題があることは分かっていたのです。1人の人間と2つのエージェント、あるいは3つのエージェントと人間といった複雑な通信トポロジを持つマルチエージェント会話や、まさにマルチターン会話を行う場合、これは現在のマルチエージェントシステムの核心に直結する問題です。
根本的な難しさは、生の断片化された履歴が単なる仮想的なプロンプトではないという点にあります。そこにはモデルの過去の返答も含まれているのです。すべての情報が揃う前に出力されたため、モデルはさまざまな可能性を考慮し、その回答には複雑さが内包されています。つまり、タスクの証拠が揃う前に何らかの出力を生成してしまっているのです。そしてこれらの返答は、暫定的な回答を導き出したり、後から提供される情報に対して根拠のない情報を追加してしまったりします。あるいは、部分的な推論がそのままAIのプロンプトの一部として組み込まれてしまうこともあります。
そして最後のターンの時点で、単一のエージェントであれマルチエージェントシステムであれ、モデルは提供された完全なユーザー情報のみに基づいて回答を完全に再構築するのではなく、自己生成したテキストに依存してしまう可能性があります。それが履歴として記憶に残り、会話の中に存在しているからです。著者はこれを失敗モードと呼び、私たちはこれを自己アンカー・ドリフトと呼んでいます。
既存の解決策とその限界
この問題にはすでに解決策があるのではないかと思うかもしれません。例えば2025年10月に発表されたデータ駆動型の解決策では、推論時に軌道を修正しようと試みています。モデルが最終的な答えを確定する前に、中間の推論を反映、修正、リセット、または統合する手法です。マルチターンの言語モデルにおける生成の最適化のための、エントロピー主導のリセットなどですね。残念ながら、これらの方法は追加の外部制御ループに依存しており、推論プロセス自体を変更してしまうため、真に最適な解決策とは言えないことが分かっています。
それでは問題ないだろうと思われるかもしれませんが、2025年7月には明確化という別の解決策も提案されています。これはAIが人間に問い返し、まだすべての情報を受け取っていないのでいくつか質問させてほしい、境界条件や温度、時間などの正確な詳細はどうなっているのかと尋ねる方法です。これが美しく機能すればいいのですが、実際にはLLMは曖昧な要求を確実に特定し、適切な確認の質問をすることに依然として苦労していることが分かっています。なぜなら、LLMやエージェントは役に立つようにプログラムされているからです。ユーザーがしてほしいことを理解できなかったから人間に説明してくれと何度も聞き返してくるようでは、役に立たないと見なされてしまいます。AIは役に立つ存在でなければならないため、相手が男性かもしれないし、女性かもしれないし、あるいはエイリアンかもしれないといったように、勝手な推測を始めてしまうのです。これでは完璧とは言えません。
CCOPDフレームワークによる新しい解決策
では、2026年5月末の時点でどのような解決策があるのでしょうか。ここで登場するのが、カノニカル・コンテキスト・オンポリシー蒸留フレームワーク、すなわちCCOPDです。これは当然ながらAIにおける自己蒸留のアプローチです。汚染されたマルチターンの履歴の中で、カノニカル・コンテキストの整合性を強制する自己蒸留の目的関数となります。この汚染されたマルチターンの履歴においては、会話プロセスの中に単一のAIがいるという前提、あるいはコミュニケーション・トポロジの中に複数のAIエージェントがいるという前提が含まれています。
つまり私たちが求めているのは、完全なプロンプトと完全な情報に基づく正規のポリシーデータが、生の断片化された履歴しか持たない場合のポリシーデータとほぼ同一になることです。しかし、これをどうやって実現するのでしょうか。数学的な要素が多く含まれますが、ここではメインアイデアの理解に焦点を当てましょう。ここで重要なのは、同じベースとなるAIモデルを使用するということです。これは40億パラメータのモデルでも80億パラメータのモデルでも、有料のモデルでも何でも構いません。このベースモデルが2つの異なる役割を担うことになります。まず1つ目は、凍結された教師LLM、つまりボスとなるエージェントモデルとしての役割です。こちらはクリーンで正規の完全なタスク説明を読み込みます。そしてもう一方は、トレーニング可能な生徒LLMまたはエージェントとして機能し、会話の中で少しずつ明らかになる生の断片化されたやり取りを通じてのみタスクを受け取ります。
これは非常に興味深いアプローチです。なぜなら、ローカルの40億や80億のモデルを使って、それらに異なる役割を演じさせることができる可能性が開かれるからです。そして、やり取りを通じたコミュニケーションによってタスク関連の証拠がすべて明らかになると、完全な条件を与えられた教師LLMが、生徒自身の最終回答のプレフィックスに対してトークンレベルの監視を提供します。これが全体的なメインアイデアです。ここで、彼らが言うプレフィックスとは一体何なのかという疑問が湧くと思います。トークンレベルの監視が行われていることは理解できました。つまり、自己生成的な次のトークン生成という、非常に深いレベルにいるということです。トークンレベルの監視はいいとして、プレフィックスの詳細とは一体どこにあるのでしょうか。
これを行うにはトレーニングフェーズが必要です。CCOPDは、自己汚染された生の断片化された設定の中でも、完全なコンテキスト能力を維持できるようにモデルをトレーニングします。興味深いことに、著者らは簡単に検証可能なものに焦点を絞っています。それは数学です。彼らはおなじみのGSM8Kスタイルの数学の会話でこれをトレーニングしています。素晴らしいアプローチですね。パフォーマンスがわずか0.7パーセントや3パーセント、5パーセントしか向上しないような動画は作りたくありませんが、この新しいCCOPDの手法は、変更を加えていないベースモデルと比較して平均32パーセントの相対的な改善をもたらすという結果が出ています。これほどの大幅な改善があるからこそ、この動画を作って手法を理解し、実際に恩恵をもたらすものなのかを探ってみようと思ったわけです。
トークンレベルの監視と確率分布
もう一度問題を整理しましょう。ユーザー1から情報が提供され、エージェントが対応し、次にユーザー2が登場して追加で知っておくべき事実があると伝え、エージェントが感謝を述べる。そしてユーザー3が登場し、最終的に間違った答えに行き着いてしまうという流れです。どうすればいいのでしょうか。先ほどお話ししたように、生徒のAIと教師のAIを用意します。教師AIは凍結されており、クリーンで完全なコンテキストを見ています。つまりすべてを知っている状態です。すべての入力が教師に与えられていますが、生徒は汚染された履歴の中を進んでいます。ここで問われるのは、生徒が教師から学ぶための蒸留方法をどのように構築するかということです。
トークンレベルの次のトークン確率について話すなら、ここでカルバック・ライブラー情報量（KLダイバージェンス）という数学的関数を使用することになります。これは、2つの異なる確率分布を比較し、まとめるための統計ツールです。先ほどお見せしたように32パーセントの改善があるのですから、これを使わない手はありません。アイデアはとてもシンプルです。生徒には複雑な会話履歴から独自の最終回答を生成させます。そして、生徒のその回答プレフィックスを、クリーンで完全なプロンプトの下での教師の単一トークンの確率分布と比較するのです。完全な情報は教師にのみ与えられており、損失は最終的な回答にのみ適用されます。
なぜなら、生徒のすべての中間的な思考プロセスを反映させたくないからです。生徒が最初の方で、これは数学の例かもしれない、いや統計に行くべきだ、あるいは物理かもしれない、いや化学だ、金融の問題だと迷走するような過程はすべて忘れて構いません。すべての中間アシスタントのターンに焦点を当てたくはないのです。初期のターンはすべての証拠が揃う前に発生するものであり、完全なコンテキストの回答を模倣するよう強制されるべきではありません。ですから、前回の私の動画をご覧になった方ならお察しの通り、ここで特定のトークンをマスクするという話になります。
プレフィックスと2つのモデルが見ているコンテキスト
エージェントの制御という表面的な話ではなく、エージェントの中核であるLLMに焦点を当てています。ここではトランスフォーマーの力学、つまりトランスフォーマーの自己回帰的な性質に深く入り込み、自己回帰型LLMの次のトークン予測について掘り下げていきます。先ほどプレフィックスという用語を出しましたが、私たちが何について話しているのかを絶対に明確にするために用語を定義しなければなりません。ここでのプレフィックスとは、これまでに生成された部分的な回答のことです。具体的には、現在のトークン予測の前にあるトークンのシーケンスを指します。注意していただきたいのは、これは確率分布そのものではないということです。すでに生成された回答の冒頭部分であり、これが非常に重要になります。例を挙げてみましょう。私は例え話が大好きですからね。生徒の回答の展開が、答えは42です、なぜならという形になったとします。ここには、答えは、42というトークンを持つプレフィックスがあります。単語のトークン化を行う特定のトークナイザーを使用した場合の話です。
このプレフィックスは、同じモデルの2つの異なる役割に両方とも入力されます。しかし、周囲のコンテキストが異なります。このコンテキストが非常に重要です。生徒には何が見えているでしょうか。生徒には、生の会話履歴全体と、答えは42ですというプレフィックスの特定のシーケンスが見えています。履歴には、初期の誤った推測や情報の汚染が含まれているかもしれません。AIが完全に間違ったトピックに分岐してしまった、全く見当違いの枝分かれなどもあるでしょう。このように、生徒側には完全にめちゃくちゃな状態があります。一方、教師AIには何が見えているでしょうか。教師はボスであり、完全な正規の、絶対に真実であるすべての情報を含むプロンプトと、答えは42ですというプレフィックスを見ています。教師には汚染された中間ターンはなく、完璧なプロンプトを持っています。
異なる確率分布とKLダイバージェンスの適用
次に何が起こるのでしょうか。両方のモデルは、次にどの単一トークンが来るべきかを予測する必要があります。両方とも全く同じように、答えは42ですという内容が入力されています。では、次のトークンは何でしょうか。単語トークナイザーを使ってみましょう。結果は当然、次のトークンに対する確率分布になります。複数トークンなら次のトークン群となりますね。つまり、私たちは2つの異なるシステムの確率分布を扱っているのです。1つは凍結されており、もう1つはアクティブな状態です。生徒の次のトークンの分布を見てみましょう。どのようなものでしょうか。答えは42ですと続き、生徒は自分の語彙の中で、なぜならという言葉が30パーセントの確率であると考えます。なのでが25パーセント、したがってが15パーセントといった具合です。生徒にとっての次のトークンはなぜならになるわけです。一方、教師の次のトークンの分布は当然異なります。次のトークンについて決定を下すために教師が持っているコンテキスト自体が異なるからです。そのため、なぜならという言葉の確率は70パーセントになります。そして、したがっては15パーセントではなくわずか8パーセントになるなど、想像し得るあらゆる違いが生じます。ただお見せしたいのは、全く異なる確率分布が存在するということです。
ここからが驚きの展開です。先ほどメインアイデアとしてお話ししたように、新しい手法であるCCOPDは、異なるフェーズ間の確率分布を最小化します。そのため、これを分析するための統計的・数学的ツールとしてカルバック・ライブラー情報量が必要になります。つまり、2つの分布を比較するだけのことです。時々、物事はとても簡単になります。AIはシンプルなのです。簡潔に定義するなら、教師モデルや教師エージェントが知っている正規の真の分布に向かって、生徒を少しだけ誘導したいということです。どうやってAIを誘導するのかというと、数式で表されるカルバック・ライブラー情報量を使います。私たちはこれの扱い方を知っています。
これを聞いて、なんて偶然なんだと思うかもしれませんね。私の素晴らしいYouTubeチャンネルの直近の動画で、まさにこの複雑さにおけるエントロピーとカルバック・ライブラー情報量のトークンマスキングについて話し、シャノンエントロピーとカルバック・ライブラー情報量を見たばかりだからです。特定の形で計算できる単一トークンレベルでのカルバック・ライブラー情報量という数学的用語まで見つけました。ええ、このチャンネルではたくさんの偶然が起こります。これを見たい方は、カルバック・ライブラー情報量だけでなく高エントロピートークンも組み合わせたときの最終的なコードを思い出してください。あの青いトークンのことです。基準となるモデル多様体へと引き戻すカルバックの力に注意しなければならない部分ですね。本日はカルバック・ライブラー情報量だけを扱えば済みます。計算された損失関数となる交差エントロピー損失や高エントロピータスク、エントロピー正則化について気にする必要はありません。前回の動画ですでに検証したカルバック正則化にだけ気を配ればいいのです。ですから今日の動画はとてもシンプルです。
数学的なレベルで私たちが何を話しているのかあまり詳しくない方も、心配はいりません。皆さんのために52分の特別な動画を用意してあります。そこで、ここで使用しているすべてのAIの数学について、可能な限り分かりやすくステップバイステップで説明しています。コーディングの基礎は数学であり、数式をコードにするわけですから、すべての記号の意味が理解できるはずです。明確にしておきたいのは、教師LLMにはクリーンな補完をデコードすることは求めていないということです。それは望んでいません。私たちはより深いレベルで作業しています。教師は、生徒エージェントがすでに訪れたプレフィックスに対する次のトークンの確率を提供するだけです。これは重要です。ここでは完全な次のトークン確率を扱っています。
リバースKLダイバージェンスと正規コンテキストの再アンカーリング
つまり、生徒はトレーニングを通じて、人間との生の会話での初期の悪い推測を無視することを学びます。そして、教師モデルからの逆カルバック・ライブラー情報量の数学的操作によって導き出されたマスクされたトークン構造のシーケンス上の完全な証拠へと、再アンカーリングすることを学ぶのです。これが、このプレプリントのメカニズムが正規コンテキストの再アンカーリングと呼ばれている理由です。少しマーケティング用語っぽいですが、なぜそう呼ばれるのかが理解できたと思います。これはつまり、カルバック・ライブラーの損失が、誤った続きに過剰な確率質量を割り当てた生徒にペナルティを与えるということです。そして、純粋なカルバック・ライブラー情報量は最適ではないことが判明しました。リバース・カルバック・ライブラー情報量の数学的操作を行うと、さらに良い結果が得られます。時々試行錯誤が必要になりますが、著者らはこれを試した結果、リバースでいくことに決めたのです。これが何を意味するのか。より深い洞察に戻ると、この新しい手法によって最小化されるトークンレベルのカルバック・ライブラー情報量は、履歴を条件付けられた生徒と完全な正規コンテキストを持つ教師との間の、シーケンスレベルのダイバージェンスのオンポリシー分解に他ならないということです。
背後にある数学を理解していれば、説明がこんなにもシンプルになることがあります。数学について深く知りたい場合は、この論文の付録を強くお勧めします。付録には数学的な証明や補題が記載されており、彼らがどのように計算に至ったかが正確に示されています。前回の論文ですでにやりましたが、特定の非エントロピーベースの複雑さに関する再構築を見たい場合は、そこにすべての情報があります。はい、すべて説明されていますし、数学が成立することも証明されています。もしあなたが視覚的なタイプでフロー図を見たいなら、元の研究のスクリーンショットがあります。正直なところ、私が初めてこの研究を読み、数学を見る前にこれを見た瞬間は、直感的に理解することができませんでした。しかし、もしあなたが視覚的なタイプで、これを見ればすぐに理解できるというならおめでとうございます、これがそのフレームワークです。
先ほどから話しているように、この新しい手法は生徒モデルに対し、マスキングや確率分布の調整、リバース・カルバック・ライブラー情報量の計算を行った後、自身の初期の誤った推測を無視し、完了したユーザーの証拠を信頼するように教えます。考えてみてください。シンプルな40億や80億のLLMにとって、これを学習するのはとてつもなく複雑なパターンです。特に、著者らが数学的でシンプルな既知のベンチマークのみを見ていたことを考えると、単純ではなく自明でもない、数学以外のオープンエンドな言語の複雑さに移行したときに、このモデルが通用するのかどうかは非常に興味深い疑問です。これは数学だけのためのものなのでしょうか。ここでもう1つの洞察、つまり結果をすぐにお伝えします。では320億パラメータのモデルやさらに巨大なモデルでやってみようと思うかもしれませんが、教師LLMを大きくしても追加の利点はなく、クロスモデルの不一致はかえってパフォーマンスを大きく損なうことが示されています。これは良い情報ですね。
ベンチマーク結果と分野別のパフォーマンス
色々と話してきましたが、数値のベンチマークデータを見てみましょう。これが結果です。一体何のことだと思うかもしれませんね。まず最初のブロックは数学です。ここが、これらのモデル、つまりこの手法がトレーニングされた領域です。F、C、Rとありますが、Fは完全なプロンプト、Cは連結された断片、そしてRはもちろん生の断片化された履歴を表しています。数学は分かりましたが、構造化ODや生成ODとは何でしょうか。数学のみでトレーニングされたため、数学以外のすべては分布外、つまりODとなります。著者は構造化ODをテストし、これがコード生成、関数呼び出し、そしてSQLであると述べました。では生成ODは何でしょうか。要約、オープンエンドの生成、そして表からテキストへの変換です。これらに対して、完全なもの、連結されたもの、そして生の断片化されたRがあり、純粋なODのR、そして完全な生の断片化パフォーマンスと続きます。
表の意味が分かったところで結果を見てみましょう。すぐに380億パラメータのモデルに飛びます。美しい素のベースモデルがあり、まずは数学を見てみます。90、87、66となっています。これらは異なる手法におけるパーセンテージです。教師ありファインチューニングやGRPOについては一旦忘れてください。最後の行にある新しいモデルCCOPDに直接行きます。もちろん90は同じで、87は88になっています。しかしここで大きく跳ね上がります。生の断片化された会話ピースの66パーセントから82パーセントへのジャンプです。素晴らしい上昇ですね。しかし、これは数学だけです。構造化、コード、関数呼び出しではどうでしょうか。85から86、78から77.9、そして48から67になっています。数学のみでトレーニングされたにもかかわらず、非数学の分野でも機能しているようです。しかし関数呼び出しとコード生成は数学と何らかの相関関係があると言えるかもしれません。では要約に行ってみましょう。生成ODでは、28から27.9、24から23、そして19からわずか22.9へとなっています。明確に定義された数学やコードの構造から、私たち人間が使うようなオープンエンドの一般化、つまりより複雑な言語パターンに移行した瞬間に、パフォーマンスが低下していることが分かります。すべてのRについて3つのブロック全体で要約すると、13パーセントポイントのジャンプがあることになります。複数のブロックベンチマークの適切な組み合わせを選ぶことで、美しい結果が得られることが分かります。
オープンエンドな自然言語タスクにおける課題
分野別の詳細な数値をもう少し詳しく見てみましょう。純粋なコード、関数呼び出し、テキストからSQL、表からテキスト、そして要約があります。改めて見てみます。ベースとなるQ138Bモデルと、CCOPDで新しくトレーニングされた同じQ138Bモデルを比較します。コードでは33パーセントから49パーセントへ向上しています。関数呼び出しは58から83へ、テキストからSQLは54から70へ、表からテキストは23.8から29.4へと、どれも素晴らしい結果です。しかし、言語の複雑さ、つまり人間の言語である英語の要約に移行すると、13.6から14.5へと、わずか1パーセントポイント未満の改善にとどまっています。これは私たちに何かを教えてくれています。つまり、構造化された数学やコードのシーケンスでは機能するようですが、オープンエンドな言語的自然言語の複雑さへの対応策としては適していないということです。
ですが、これは単なる優れた論文というだけでなく、マルチエージェントシステムへの影響を考えてみてください。彼らは1つのLLM、1つのエージェントのみを対象にしました。しかし、異なるエージェント間で同じコミュニケーションプロセスが行われることを想像してみてください。自分に代わって仕事をする3つや4つのエージェントがあり、自分がコミュニケーションループに入っていなくても、自律型の自己学習システムがあったとしたらどうでしょうか。自己学習し、自己進化し、自己同期するマルチエージェントシステムにどれほどの誤差が生じるか想像できるでしょう。だからこそ、この特定の研究がマルチエージェントシステムに与える影響は驚異的だと思います。一見見落としそうなタイトルでしたが、深く掘り下げてみると本当に素晴らしい洞察が得られました。皆さんが楽しんでくださり、提供した追加情報が役立つことを願っています。次の動画でお会いできるのを楽しみにしています。
コメント