📝
なぜAIは会話を重ねると間違えるのか：マルチターン対話の落とし穴と実用化への示唆

harada
2025/11/21に公開
 はじめにこんにちは、PKSHA Technologyでアルゴリズムエンジニアをしている原田です。LLMの性能は、各種ベンチマークにおいて着実な向上を見せており、その能力の高さは客観的な指標によっても示されています。しかし、これらの指標が必ずしも実際のユースケースにおける性能と一致するとは限らない点は、AIを実用化する上で重要な視点です。
その一例として、マルチターンでの対話が挙げられます。LLMの性能はシングルターンのベンチマークで議論されることが多い一方、マルチターンの評価手法はまだ十分に整備されていないのが実情です。ユースケースを見ても、ある程度決まったタスクの自動化などシングルターンで十分な場合もあれば、エンドユーザー向けのサービスのようにマルチターンの対話が前提となる場合もあります。弊社もマルチターン対話の領域には注力しており、その性能や挙動を深く把握することは実用化の上でも重要です。
今回紹介する論文「LLMS GET LOST IN MULTI-TURN CONVERSATION」は、この問いについて深く掘り下げた研究になります。
https://arxiv.org/abs/2505.06120

 マルチターンの対話評価における課題LLMの評価は通常、最初から完全に明確な指示を与えるシングルターンで行われます。一方で、実際の対話では、ユーザーが最初から明確化された指示を出すのではなく、対話を重ねる中で明確になることが多いです。マルチターンの対話評価に関する既存研究も存在しますが、その多くはエピソード的な対話（各ターンは互いに関連しているものの、実質的に個別評価可能なサブタスクの連続とみなせる対話）に限られており、「不明確な指示」というマルチターンの対話の特性を捉えられていません。また、既存研究で不十分な点として以下も挙げられています。
評価対象のタスクをシングルターンとは別に定義しているため、マルチターンとシングルターンの直接的な性能比較が困難である
マルチターンの対話評価では、様々な対話シナリオを考慮する必要があり、難易度も上がるため、単純なタスクに限定されている
本論文では、これらの課題を解消した評価方法を提案し、マルチターン対話の性能について分析しています。

 実験設定
 マルチターン対話のシミュレーションマルチターンの対話評価を実施するにあたり、ユーザー役が必要になります。実際のユーザーを参加させることで最も現実の対話に近いデータを得られますが、多数の実験を人手で行うのは実験規模の面で困難です。そのため、本論文ではユーザーの応答をLLMに代替させる「ユーザーシミュレーター」を導入しています。
このシミュレーターに実現させたいのは、ユーザーがターンを重ねる中で曖昧な指示を徐々に明確化する対話です。この過程を実現するため、まず準備段階として、既存のシングルターンのベンチマークから「完全に明確な指示」を引用します。次に、その一つの指示を、「シャード」と呼ばれる複数の小さな要素へと分割します。シミュレーターには各ターンでシャードを1つずつ小出しにさせることで徐々に指示が明確になる対話を擬似的に実現します。なお、シャードの具体例としては、以下の図を参照ください。数学タスクの指示が分割された例です。


（図は論文より引用。以降も同様）
以上の準備のもと、シミュレーション対話は、シャードを使って以下のルールで進行します。まず、ユーザーシミュレーターは、タスクの全体的な意図を示すシャード（上の例ではShard1）をアシスタント（評価対象のLLM）に提示することから対話が始まります。アシスタントが応答すると、その内容が回答の試みであれば、タスクの最終的な正解と比較して評価されます。もし回答が正解であれば、その時点で対話は成功として終了します。対話が続く場合（不正解だったり、アシスタントが質問を返してきた場合）、ユーザーシミュレーターは、それまでの文脈に最も合う次のシャードを1つ選択します。その際、シャードをそのまま提示するのではなく、自然な会話文に整形してアシスタントに応答します。
このプロセスを繰り返し、アシスタントが正解できないままユーザーシミュレーターが全シャードを提示し終えた場合も、対話は終了となります。

 シミュレーションの種類マルチターンの性能を評価するにあたって、本論文では、以下のシミュレーションタイプを定義しています。

FULLY-SPECIFIED (FULL)

既存のベンチマークから引用した、元の「完全に明確な指示」をそのまま一度に与える、従来のシングルターンのシミュレーションです。ベースラインの性能となります。

SHARDED

先ほど説明した、シャードを1ターンに1つずつ小出しにする、本実験の主要なマルチターンのシミュレーションです。

CONCAT

シャードを箇条書き形式で連結し、最初のターンに全て与えたものです。シャードによる言い換えの影響がFULLとCONCATの差分、シャードを小出しにすることによる影響がSHARDERとCONCATの差分といえます。
さらに、著者らはマルチターンによる性能低下を軽減する介入策を検討するため、以下の2つのタイプも定義しています。

RECAP

SHARDED対話の最後に、全シャードをまとめて再提示する「要約ターン」を追加するタイプ。

SNOWBALL

毎ターン、新しいシャードだけでなく、それまでに提示された全てのシャードを雪だるま式に繰り返すタイプ。

 タスクと評価指標LLMの主要なユースケースを網羅するため、以下の6つの多様なタスクを選定しています。これらは全て、既存の高品質なベンチマークから引用されています。

Code: Python関数の生成

Database: 自然言語の質問からSQLクエリへの変換

Actions: ユーザーの要求に基づくAPI呼び出しコマンドの生成

Math: 算数の文章問題の解決

Data-to-text: 表データからの説明文（キャプション）生成

Summary: 約20件の文書に基づく引用付きの要約生成（長文脈における能力が必要となるタスク）
なお、評価指標としては、元のベンチマークと同様のものを使用します（1~4番目のタスクについては正解かどうかの二値評価、5番目はBLEUスコア、6番目はLLM-as-a-judge）。
また、マルチターンでの性能について深掘りするために、temperatureを1にして確率的に生成させた上で、1つの指示に対してシミュレーションを複数回実行し、以下の3つの指標を定義しています。

平均性能（Average Performance）: 単純な平均値です。

適性（Aptitude）: 上位10%のスコア。モデルがうまく出力できた時の性能を示します。

非信頼性（Unreliability）: 上位10%のスコアと下位10%のスコアの差です。性能の不安定さを示します。
この3つの指標で結果を出すことで、例えば「平均性能が低下した」という事象を観測した際に、その原因が「モデルのポテンシャル自体が落ちた（適性が低下）」のか「ポテンシャルは高いまま、不安定さが増した（非信頼性が上昇）」のかを、明確に切り分けて分析することが可能になります。

 実験結果
Average Performance（平均性能）に関する実験結果のまとめが上記のテーブルになります。まず主要な結果として、テストした全てのモデルにおいて、マルチターン対話（SHARDED）の性能がシングルターン（FULL）と比較して大幅に低下（平均39%）しています。この性能低下の原因を切り分けるのが、CONCAT（全シャードを一度に与える）です。FULLとCONCAT間の性能低下は軽微であったことから、この問題がシャード化による指示の言い換えではなく、まさしく「マルチターン」という対話形式そのものに起因することが示唆されます。
さらに注目すべきは、この性能低下がモデルの能力や規模に依らない普遍的な現象である点です。Claude 3.7 SonnetやGPT-4.1といった高性能なモデルも、小規模モデルと同様に大幅な性能低下を示しました。また、o3やDeepseek-R1といった推論モデル（reasoning model）においても改善は見られず、追加の推論処理がこの問題の解決には寄与しないことも確認されています。
また、上記の平均性能の低下をさらに深く分析するのが、「Aptitude（適性）」と「Unreliability（非信頼性）」です。その結果が上図になります（AptitudeとUnreliabilityはそれぞれ図中の上端と幅に対応）。シングルターン設定（FULL, CONCAT）では、適性が高いモデル（GPT-4.1など）ほど非信頼性が低く、安定している傾向が見られます。性能の高いモデルほど、多少の変化に対してロバストであるという一般的な直感とも一致する結果です。
しかし、マルチターン設定（SHARDED）ではこの関係が崩れます。どのモデルでも非信頼性が50%前後になっており、適性の低下と比較して非信頼性の急増が目立つ結果となりました。論文では、この不安定化を引き起こす主な要因として、以下の振る舞いを特定しています。
対話の初期段階で回答しようとして、間違った仮説を立ててしまう。そして一度間違った回答をすると、それに固執して、最初の間違いを前提とした回答をし続ける
最初と最後のターンには比較的従うものの、中間の指示を忘れる傾向がある
必要以上に長い回答を生成しがちで、その過程で余計な仮定を持ち出してしまう。
本論文のタイトルでもある「LLMs Get Lost In Multi-Turn Conversation」が表しているように、対話の初期段階で一度でも間違った仮定に陥ると、LLMはそれに固執してしまい、後からいくら正しい情報が提示されても軌道修正できなくなってしまうのです。

 実験結果の考察、示唆上記の結果を踏まえて、論文ではいくつかの観点で考察をしています。まず、今回のマルチターンでの性能低下の問題が、LLM本体で解決すべき問題なのか、LLMを利用するシステム側で解決できる問題なのか議論しています。これを見極めるために、SNOWBALLとRECAPでの実験結果について言及しています。下の表が示すようにどちらも一定改善効果があるものの、元のシングルターンの精度には及ばないことがわかります（RECAPは会話の最後のターンを事前に知っておく必要があるので、実用的ではないことにも注意が必要です）。
ここまでの議論を踏まえると、毎ターン、タスクを解くのに必要な全ての正しい情報（全シャード）を提示されているにもかかわらず性能が回復しないのは、LLMがその正しい情報よりも、対話の初期段階で自ら生成した間違った回答や仮定に過度に依存し、軌道修正できないためだと考えられます。この結果から、著者は、アプリケーション側での単純な対策では限界があり、LLM自体がネイティブに、マルチターンにおける対話能力を向上させるべきであると主張しています。
また、LLM本体の開発において、Aptitudeだけでなく、Reliabilityの向上も考慮すべきとも主張しています。その根拠として、temperatureを上記の実験で設定した1.0から0.5, 0に下げた場合の実験結果も挙げています。シングルターンでは期待の通り大幅にunreliabilityが低減しますが、マルチターンでは依然として30%近くのunreliabilityが残っています。なお、T=0でも最近のLLMにおいて完全に毎回同じ出力になるわけではないことには注意が必要です。本結果は、わずかな違いでもマルチターンでは連鎖的に出力が大きく変わることを示しています。そのため、T=0にしたからといって、マルチターンの対話においては結果は安定せず根本的な解決にはならないと言えます。
また、これまで見てきた迷子現象が全てのマルチターン対話で起こるわけではなく、どのようなタスクで起こりうるのかも述べています。迷子にならない対話として翻訳タスクの例を挙げています。具体的には、10文を翻訳させるタスクにおいて、1ターンに2文ずつ小出しにする実験を行っています。その結果、GPT-4oでもGPT-4o-miniでも、性能が全く低下しませんでした。論文は、その理由を、この翻訳タスクが「エピソード的」だからだと結論づけています。つまり、実質的に「文ごとの翻訳」というサブタスクに分解可能だからです。
翻訳タスクの特性は、新しいシャード（文）を翻訳し、それまでに生成した回答に追記するだけで完結する点にあります。これは、本実験で「迷子」になった他のタスクのように、新しい情報によってそれまでの回答全体を根本から見直す必要がある分解不可能なタスクとは根本的に異なります。著者らは、この「分解不可能である」という特性こそが、迷子現象を引き起こす要因であると考察しています。
そして、この特性に加え、「迷子」になりやすいタスクの条件を他にも述べています。上記の分解不可能な点と合わせて以下のように結論づけています。
生成的タスクである：分類のような単純なタスクとは異なり、モデルが混乱を招きやすい。
複数のシャードに分割できる程度に複雑である：単純すぎるタスク（例：「1+1を計算するコード」）だと、そもそも複数の情報に分割できない。
分解不可能である：新しい情報によって、それまでの回答全体を根本から見直す必要がある。
以上の3つの特性を持つタスクについては、対話で迷子になる可能性があると主張しています。

 終わりに今回は「LLMs Get Lost In Multi-Turn Conversation」という論文を紹介しました。本論文では、シングルターンと比較してマルチターンの性能が悪化することや、モデルの適性の喪失以上に信頼性の悪化が大きな要因であることを明らかにしました。マルチターン評価という困難な課題に対し、シャーディングという手法を使って、「対話での迷子」という現象を定量的に可視化した点は興味深いと思います。また、同一タスクでシングルターンとマルチターンの性能を比較するという評価アイディアは、LLMを用いた対話システムを評価する上でも参考になります。
一方で、この実験設定と現実の対話システムとの間には、認識しておくべきギャップも存在します。例えば、（論文でもギャップがあることには言及されてますが）ユーザーシミュレーターの振る舞いです。論文のシミュレーターは情報を小出しにする設定ですが、実際の人間はAIの間違いに気づけば指摘するはずです。その際にLLMが軌道修正できるかどうかは、実用化を考える上で、次に気になるところです。
また、論文では比較的シンプルな手法（SNOWBALL）ではソフトウェア側の対策に限界があることが示されました。これは、LLMを含むアプリケーションを構築する側として、LLM自身やプロンプトに対しマルチターン対話のためのより高度な制御方法を探求していくことの重要性を示唆しているとも言えます。本論文は、対話システムを構築するにあたって、LLMのデフォルトの振る舞いに頼るのではなく、私たち開発者が注意深く設計することの重要性を、実験データをもって改めて示してくれました。LLMの特性を深く理解し、その弱点を補うアーキテクチャを追求することこそが、社会実装を成功させる鍵となるのではないでしょうか。