マルチターン対話でLLMは道に迷う

• 大規模言語モデル（LLM） はマルチターン対話で性能低下と信頼性の低下を示す
• シングルターンと比べて、マルチターン環境では平均39%の性能低下が実験的に確認された
• 主な要因は、小さな適性低下と非常に大きな信頼性低下、すなわち結果の一貫性不足である
• LLMは早い段階で誤った仮定を立てたり、最終解答をあまりに早く試みたりする傾向がある
• その結果、LLMが対話の序盤でミスをすると、回復できずに対話の方向を見失う現象が発見された

---

ABSTRACT

• 大規模言語モデル（LLM） は対話型インターフェースとして、ユーザーの要求が完全に明示されていない場合でも、マルチターン対話を通じて要件を段階的に定義・探索・修正するのを助けられる可能性を持つ
• しかし、多くのLLM評価はシングルターンの完全指定プロンプト環境にのみ集中している一方で、実際の対話ログ分析では**指示の不完全指定（underspecification）**が頻繁に見られる
• 本研究では、シングルターン環境と**マルチターン（underspecified）**環境でのLLMの性能を大規模にシミュレーションして比較した
• その結果、15の主要LLMすべてで、マルチターン対話において平均39%の性能低下があり、これは適性のわずかな低下と信頼性の急激な低下として分析された
• LLMが対話初期に誤った経路を選ぶと、その後回復できずに方向を見失ってさまよう現象が確認された

Introduction

• 最新のLLM（例: ChatGPT、Gemini、Claude など）はマルチターン対話が可能なインターフェースである
• ユーザーが最初からすべての要件を明確に記述しなくても、反復的な質疑応答（underspecified → refined）によって段階的に要件を具体化できる
• 実際には多くのユーザーが対話の序盤で曖昧な要求を提示するにもかかわらず、ほとんどの評価はシングルターンの完全指定環境でのみ行われている
• 一部の先行研究はマルチターン評価を試みているが、対話の各ターンを個別のエピソードとして扱うことが多く、実際の人間の対話で一般的な曖昧さの影響を過小評価している
• 本研究はこのギャップを埋めるため、sharded simulation（情報を複数の断片に分け、各ターンで1つずつのみ公開する）という環境を提案し、マルチターンかつ不完全指定の指示状況を精密にシミュレーションする

主な研究結果の要約

• シングルターンでLLMが指示全体を一度に受け取る場合は90%の性能を示したが、マルチターンの不完全指定指示では65%まで低下した（平均25ポイント低下）
• この現象は、わずか2ターンの対話を経るだけでも現れ、オープン型・クローズド型・大規模・小規模のすべてのLLMで共通して観察された
• 性能低下の原因分析の結果、(1) 適性低下（aptitude loss）と (2) 信頼性（unreliability）の急増が挙げられる
  • シングルターンでは適性の高いモデルは信頼性も高かったが、マルチターンでは適性に関係なく信頼性が低い
  • つまり、LLMがマルチターン対話の途中で誤った方向に入り込むと回復不能になり、これを**「lost in conversation」**現象と名付けた
• 主な原因
  • 冗長な応答および最終解答の性急な試行
  • 曖昧な情報に対する誤った仮定
  • 以前の誤った試みに対する過度な依存
• 実際のLLM活用現場とモデル評価方式の間には大きなギャップが存在する
  • 初心者ユーザーほど序盤に不完全な指示を出すことが多く、この現象が実運用を難しくする主要因の1つとなっている
• 論文の構成紹介: 先行研究の要約、シミュレーション環境の説明、6つの生成タスクと評価指標、15のLLMによる大規模実験とその結果、そして実務・製品適用への示唆と具体的な推奨事項を提示する

Background and Related Work

• 過去世代の言語モデル（例: BART、GPT-2、T5）は実際にはマルチターン対話に対応していなかったため、シングルターン中心で評価されていた
• ChatGPTの登場以後、マルチターン評価への関心が高まり、MT-bench などのクラウドソーシング評価が行われた
• しかし、その大半の評価体系はエピソード型対話（各ターンを個別評価）にとどまり、実際の曖昧な対話の連続性が考慮されていない
• 現実では「最小努力の原則」に従って人間が曖昧に指示する、いわゆる underspecification がよく起こり、LLMも情報不足時の早期結論導出や適応不足などによって性能が低下する
• 本研究は、曖昧さが核心となる実環境により近い評価を目指して構成されている

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

• 元の完全指定の指示文を複数のshard（情報の断片）に分割する
  • 例: 1文の中にすべての条件を盛り込む代わりに、各ターンで1つの情報（状況設定、数値、条件など）だけを公開する
• 最初の shard は常に指示の上位目的を説明し、その後の shard が追加情報（文脈、条件など）をターンごとに段階的に提供する
• このshardingプロセスは、LLM（GPT-4o）による提案と検証、および手作業の補完によって、高品質なマルチターン指示データセットを構築した
• 各タスクごとに 90〜120 個の sharded instruction を作成した（数時間にわたる手作業レビューを実施）

3.2 Simulating Sharded Conversations

• 対話シミュレーションは3者の役割で構成される: 評価対象のLLM（assistant）、全 shard を知っている user simulator、応答の分類と採点を行うシステム
• 第1ターン: user simulator が最初の shard だけを assistant に渡す → assistant が応答 → その戦略（明確化、質問、正答の試行など）を分類し、回答を抽出 → 正答評価
• 次のターン: 残りの shard のうち1つだけを追加で公開して繰り返す / 各ターンで assistant は自由に応答する
• 対話終了: (1) 評価者が正解と判定したとき、または (2) これ以上提供する shard がないとき
• user simulator は LLM（GPT-4o-mini）で実装されており、自然な shard 提供と自動 rephrase の能力を持つ
• 全実験において、補助LLMの誤分類や抽出ミスは 5% 未満で、assistant に不利になるケースは 2% 未満だった
• assistant にはこの環境に関する特別な情報を与えず、デフォルト状態で評価した（実運用に近い形でシナリオ情報を別途付与しない）

3.3 Simulation Types

• FULLY-SPECIFIED（FULL）: シングルターンで指示全体を提供し、ベースライン性能を評価する
• SHARDED: 各ターンで1つの情報断片だけを公開する、本研究の中核となるマルチターン・不完全指定対話実験
• CONCAT: sharded instruction 全体を一度に bullet-point で提供し、指示情報の損失だけを評価する
• RECAP: sharded 対話の後、最後にすべての shard を要約して再提示する、単純な agent 的介入の一形態
• SNOWBALL: 各ターンで新しい shard を追加すると同時に、それまでに公開した shard 全体を繰り返して、assistant が情報を見落とさないよう想起を補強する（メモリ強化実験用）

Task and Metric Selection

4.1 Task Selection

• 全6タスク: プログラミング（Code）、データベース（SQL生成）、API関数呼び出し（Actions）、数学（Math）、表→テキスト（Data-to-Text）、質疑応答型要約（Summary）
  • 例: Python 関数の作成、自然言語→SQLクエリ変換など
• 各タスクごとに高品質ベンチマークから 90〜120 個の指示文を選別し、sharding 後に手作業で検証した
• 6タスクはいずれもプログラミング/非プログラミングを網羅する代表的な性格を持ち、long context を要する Summary など多様なシナリオを含む

4.2 Metric Selection

• 評価指標
  • 平均性能（P）: 複数のシミュレーションで得られた平均スコア（0〜100）
  • 適性（A90）: 上位10%の simulation 結果値（90th percentile、best-case）
  • 信頼性（U90_10）: 上位90%と下位10%のスコア差（結果の一貫性/変動性を測定）
• 例: box-plot の最上部が適性、上下の範囲が信頼性を表す
• 6タスクすべてで一貫した尺度によりスコアを集計した（正誤判定/類似性/BLEU など）
• すべての実験パラメータ、例示、サンプリングなどの詳細な方法とコードも付録/Appendix に収録されている

Simulation Scale and Parameters

• 合計600件の instruction を6タスク向けに構築し、FULL/CONCAT/SHARDED シナリオで実験した
• 15のLLM（GPT-4、Claude、Gemini など）について、各組み合わせごとに10回ずつシミュレーションし、20万回以上の実験データを生成した
• すべての実験は temperature 1（サンプリング）で実施し、追加実験（7.2）では temperature の効果も分析した
• この大規模シミュレーションデータにより、LLMのマルチターン underspecified 対話における行動様式と性能低下の主要因と類型を把握できる

Lost in Conversation Experiment

• 以降の本文では、実験設定、個別モデルの結果、性能低下の原因分析、補完手法（RECAP/SNOWBALL）の試行、実務的示唆・具体的勧告の順に詳しく説明する

[GN⁺]

Hacker Newsのコメント

• 実際にLLMツールを使ったことがある人なら誰でも経験的に知っていることを確認してくれる論文を見られてうれしい。会話という概念はプロダクトのインターフェースが生み出したもの。コンテキストをきれいに保つことが重要。コンテキストが汚染されると回復しないので、新しい会話としてやり直す必要がある

  • 私の経験もこの観察と似ているが、少し違う点もあった。2週間、GeminiでIPSECの問題をデバッグした。最初にOPNsenseとpfSenseのIPSECドキュメントを読ませ、全体的なコンテキストを与えた。その後で設定情報を共有し、質問と回答を続けた。最後の方ではLLMが散漫になることは減り、ときどきフォーラム投稿やSOの投稿を入れても、LLMが「これは今見ている現象とは違う」と言及することもあった。すべての行き止まりを論理的に排除できたし、LLMは内省を助けてくれはしたが、判断は人間がする必要があった。最終的に問題の原因を見つけられたし、他の人たちが言うように、LLMは複雑な情報を単純化するのは得意だが、単純な概念を複雑に拡張するのは苦手だと思う。入力が出力より複雑で長いときの方が結果に満足できた。LLMなしでもできたが、文脈を覚えていたり、すぐには再現できなかった事実を保存してくれる点が役立った。大量のログから時間的パターンを見つけるのにも助けになった。複数の設定も改善した。問題解決だけでなく多くを学べた。状況把握がたまに間違っていても、自分で修正するのは簡単だった。つまり、目標を理解したうえで道具として使えば有用だが、判断を委ねたり、間違った方向に引っ張られたりすると効果はない。35万トークン（約30万語）使った。関連するブログ記事もある。wireguardのおすすめは不要
  • 経験が完全に一致する。「汚染される」という表現がまさにぴったり。何かが間違うと、その後のすべての回答が悪くなり始める。だからChatGPTのmemory機能は好きではない。大きな問題は起きていないが、コンテキスト汚染がどう起こるのかを完全には理解できず不安になる
  • 最高のコツとして伝えたいのは、ChatGPTとClaudeにあるとても小さくて目立たない「編集」ボタンを積極的に使うこと。悪い回答が出たらそのまま流さず、立ち止まって修正してからより良い回答を得ること。そうしないとぐちゃぐちゃな状態が増殖し続ける
  • いつも会話をフォークして、さまざまな方向を試したいと思っている。有望な流れに取り返しのつかない汚染が起きるのを防ぎたい。ChatGPTではこの機能が使えないが、これを提供しているサービスがあるのか気になる
  • この問題の興味深い例が、まさに初期プロンプト。事実上永続的で隠れたコンテキストだ。TwitterのGrokボットが最近「White Genocide」に頻繁に言及しているが、これは誰かがその話題に合うようプロンプトを変更したため。完璧なチャットボットなら他の話題で影響を受けないはずだが、実際には受けてしまう。結局コンテキストが変わり、その話題に絶えず執着するようになる
  • それでFileKittyを作った。複数のソースコードファイルをすばやくMarkdown形式で結合するツール。LLMにソフトウェア開発を支援してもらうとき、コードベース検索をLLMに依存すると誤りの可能性が高まる。コンテキスト圧縮という損失のせいで、成果物が薄まることもある。特定のコンテキストを最初から明確にし、会話の途中でも更新していくのが最良の結果につながる。それでも会話の長さには気を配る必要がある。コンテキストをうまく抽出して新しいセッションに渡すプロンプトもある。含めるべきファイルを選んで新しいプロンプトに入れることもある。関連する議論はHNの別スレッドでも参照できる
  • いまでは自分のワークフロー自体にこうしたパターンが組み込まれている。ときどき「いい進み具合だ。次の段階に進みたいが、この会話で続けるべきか、それとも新しく始めるべきか？」とLLMに聞く。モデルが新しく始める方がよいと言えば、良い要約プロンプトを用意してくれるし、そのまま続けてもよいと答えることもある。「今後探索する初期値の集合」というノートをいくつも作ってある。RLベースのpost-training工程などのため、チャットボットは会話を続けたがる傾向がある。RLにおけるpost-trainingは本来のRLと違って、1回限りの選好ベースのメカニズムしか使わない。長期的な選好や会話では計算複雑性が指数的に増えるため、研究もあまり多くない
  • 会話履歴を「整理」するインターフェースの実装例があるのか気になる。会話の中の行き止まりや関係のない内容を片づける機能。全履歴は維持しつつ、トピックの流れに応じて不要な部分だけを剪定して整えるようなもの。要約というより有機的に整頓する感じ
  • LLMはオートコンプリート用途にしか使っていないが、LLMチャットUIに「メッセージ削除」ボタンやオプションを追加すればこの問題は解決できると思う。最後のLLMメッセージを削除すれば新しい回答を得られる。ランダム性の高い（temperatureの高い）LLMでは特に有用。他のメッセージを削除したときも、その後の回答に反映されるようコンテキストを更新すべきだ。これによって、ユーザーがLLMを知的だと錯覚することも正せるかもしれない。これがすでに標準なのかは知らない。もし違うなら、このアイデアはパブリックドメインに置いておく。もう一つの方向としては、「サブコンテキストLLM」を置いて主コンテキストを管理するのも実用的だ。つまり、応答が長すぎたり膨大だったりする場合に、下位LLMが要約や整理を行って会話全体のコンテキストを整える構造だ。あるいは単純に「メッセージ編集」ボタンを置き、人間が直接整理してもよい
  • コンテキストが汚染されると回復は難しい。LLMに特定の部分だけを定期的にリセットしたり浄化したりできれば改善するかもしれない。ただし、どの部分を整理するか、重要な情報を失わずに済むかが課題だ。より賢いコンテキスト管理は長い会話の一貫性維持に役立つかもしれないが、バランスを取るのは難しい。もしかすると別のエージェントがこれを自動化できるかもしれない
  • AIチャットボットにおけるchain-of-thought方式のプロンプトも、同じ理由で限界が見えている
  • 「会話」が単にプロダクトインターフェースの産物にすぎないという点について。RLのマルチターン評価データセット学習によって、この流れはすでに変わってきた。コンテキストウィンドウは毎回新しいが、各プロンプトをより長い会話の一部として解釈する傾向は強まっている。公開の場ではマルチターンのポストトレーニングはまだ広がっていないが、長期的にはより多くの目標達成のために導入されると思う
  • コーディングするときも、会話を続けずに頻繁に新しい会話を始め、現在のコードを持って再説明するやり方を取る。これは一つの会話で打ち続けるよりも良い結果になることが多い。手動コマンドで要約と忘却をモデルに明示すれば問題を解けそうだ。これは人間の仕組み（作業記憶と物語的／エピソード記憶）ともある程度一致している
  • ChatGPTで最もいら立つ機能の一つが「メモリ」だ。会話の汚染がチャット間にも持ち越されうる
  • 「汚染される」は本当に的確な用語だ。会話/APIに「バージョン管理」を導入して、以前の状態にロールバックしたり、新しい会話として複製したりできればいいのにと思う。タイプミスやメッセージ修正ですら、その後の応答に微妙なバイアスを与えるという点を考えると、なおさらだ
  • zedのチャットUXは本当に気に入っている。会話履歴全体をテキストファイルのように編集できるので、不要な部分を整理・削除・修正したうえで、ずっとクリーンで関連性の高いコンテキストで会話を続けられる。だからzedはプログラミング以外でも、LLMとの会話用の主要インターフェースの一つとして使っている
  • 汚染は、的外れな質問や回答、繰り返される「希釈」によっても起こる。コンテンツ生成でも、最初は明確だった指示が徐々に崩れていくのをよく経験する
  • 「会話とは単なるプロダクトインターフェースの産物だ」という点は常に意識しようとしているが、実際にはさまざまな「会話調」の手がかりのせいで簡単ではない
  • メモリをオンにしていたのを後悔した。どうでもいい情報で会話が汚染される
  • 驚くのは、モデルがいかに早い段階で誤った前提を立て、それに固定されてしまうかということ
  • 人間について考えてみても、こういうことはよく起こる
  • いまではChatGPTが「メモリ」によって過去の会話にもアクセスできるので、汚染が永続化する可能性がある。一度間違った考えをつかむと、ユーザー側が二度と触れないでくれと何度強調しても、それを回答に入れ続けることがある。内部プロンプト（「ユーザーは非常に不満、xyzを外すこと」）まで誤って出力され、その結果xyzばかり集中的に言及するという笑える状況まで起きる

• これはLLMのよく知られた過信傾向、自己省察の欠如、そしてより多くの情報を求めるべきときにそれを認識できないことに由来する現象だ。推論モデルの結果を見ると、混乱している場合でもLLMは追加説明を求めず、ユーザーが何を意味しているのかを推測し続けるだけだ。これは、人間のプログラマーを置き換えようという発想の現実的な限界を示している。本当に難しい部分は、曖昧な要求を明確化していく「ステークホルダーとの相互作用」だからだ

  • 自己省察できない能力について言えば、LLMには実際の主体はなく、ユーザーは一種の「信念維持ストーリー」に巻き込まれているだけだ。大半の場合、映画脚本のユーザー役としてテキスト入力を残すと、LLMはチャットボット役として不完全な筋書きをオートコンプリートしているにすぎない。たとえばドラキュラボットとのインタビューでは、自己省察を「血を渇望する」とか「コウモリの群れになる」といった表面的な形でしか真似できない
  • 情報が曖昧なオープンエンド問題の状況、とくにパラドックスで、LLMが明確に追加説明を求められないことには私も同じように失望している。DeepSeek-R1とClaude-3.7-Sonnetでテストし、関連する実験ブログもある
  • Gemini 2.5 ProとChatGPT-o3は、作業を実行する前に追加情報を求めることがよくある。Geminiは複数の選択肢を提示しながら私の入力を求めることもある
  • 本物のプログラマーは、実際にはたいていの時間を要件の明確化に費やしている。LLMはまだ推測そのものを一つの機能として扱っている
  • 皮肉なことに、初心者開発者と仕事をするときも似たようなものだ。作業を任せると、ひたすら一直線に進み、前提だけ置いて何も質問せず、最終的には救助隊が入って連れ戻さないといけないほど深い森に自分から入り込むことがよくある
  • これはかなり簡単に変えられると思う。chain of thoughtプロンプト方式で最後のトークンを「うーん」に変えるように、LLMが「たぶん〜だと思う」と言いそうになったら、「まず追加の説明を求めよう」にトークンを差し替えればいい
  • 追加情報の要求や自己省察も、求めさえすれば十分うまくできる

• LLMにここまでの議論を簡潔なプロンプト形式で要約させ、それを自分で修正・編集して新しい会話を始める手法をよく使う。この方法はかなり効果的で、近いうちに自動化されると思う

  • Cursorはこれを自動で試みていたが、（大きなコンテキストモデルを使わない限り）要約が細部を落としすぎて、実運用ではあまり良くなかった
  • Claude Codeには /compact コマンドがあり、会話を要約してトークン使用量を減らしてくれる

• TSCE（Two-Step Contextual Enrichment）を自分で考案した。GPT-35-turboで300件の課題に使ったところ性能が+30pp向上した。オープンフレームワークとして自由に使える。gpt-4.1でも300回の追加実験を行った。baselineはem-dashの削除に149/300回失敗し、TSCEは18/300回失敗した。全データとスクリプトも公開している

  • 単純なfind and replace作業にキロワット時が浪費されている。text.replace("—", "-") のようなものを使ってみたらどうだろう
  • baselineプロンプトを少し変えるだけで、GPT-4.1で100%の成功率が得られた。追加呼び出しやトークン消費、複雑なテクニックも不要だった

• 2つのシステム（LMM + 自動curator）で問題を解いた経験がある。一方はLLMそのもの、もう一方は「思考のキュレーター」としてコンテキストの一部を動的に差し替えて管理するものだ。明確なルールではなく、LLMの補完能力に依存している。問題を小さく分割して処理するのを助け、その結果を集めて最終目標を達成する

  • 面白いアイデアだ。いまやっていることは会話RAGに近く見える。将来的にはメモリ層の区別（トレーニングデータ / 現在のコンテキスト / RAG）がより明確になるだろう
  • 興味深いアイデアだと思う。簡単な形でも世界に共有すれば、多くの人が改善しながらコミュニティが自律的に育てていける
  • これはEmotion Machineで語られている内的批評システムに似ている
  • 作っているプロジェクトについて、もっと情報を知れたらいいのに。面白そうだ
  • つまり結果として、Map-Reduce-of-Thoughtとでも呼べそうだ

• メインのチャットツールでブランチ/フォークが標準になっていないのが不思議だ。回答を編集することはできても、この場合は別のコンテキストが多く失われる。私のワークフローは 1. 計画 2. 構築 3. ブランチ 4. 反復。プロンプトの枝分かれ／ブランチングはLLM活用の中核ツールであるべきだと思う

  • Google AI Studioには少なくともこの機能がある。ただ実装が分かりづらく、これがもっと普及していない理由の一つかもしれないと思う
  • 昔から自分でこういうものを作りたいと思っていた。BetterChatGPTは少なくとも履歴削除インターフェースが良いが、私もブランチングこそ次の段階だと思う

• LLMインターフェースがシングルターン会話中心に設計されると問題が起きる。ほとんどのユーザーは線形の会話を期待する。そこでTelegramボット experai_bot を作り、LLMのユニバーサルUIとして使い、「返信でなければ新しい会話」というアプローチを採用した。コンテキストを維持するには、必ず返信ツリー構造で続けなければならない。非専門家にはこの方式を理解するのが難しい。またOpenAIモデル（3.5、4o基準）は、同じ質問を繰り返すほど余白やオプションが短くなり、結果が徐々に不正確になる。システムメッセージは最小限にした方が比較的結果が保たれる。必要ならオプションでシステムメッセージを追加できる

• promptdownを作った主な理由は、チャット履歴全体をターンごとに完全編集できるようにするためだ。標準インターフェースの「追記専用」構造では、こういうことが難しい

• 現時点のLLM分野は、みんなが同じ問題を繰り返し解いている感じがする

  • マルチターン会話におけるLLMのように、みんなが同じ問題を繰り返している
  • 「学習」ではなく「猫追い」のような現象だが、一部のワークフローにはこれが合っている
  • みんな自分なりのプロンプトエンジニアリングの腕前を見せたがっている

• LLMは本当に瓶の中のジーニーみたいなものだ。3回までは質問に答えてくれるが、その後は妙なことばかり言い出す現象