LLMとの会話で感じる違和感の正体:「ロストインコンバセーション」現象のナゾに迫る!


AX研究室の庄内です。

会話の迷子

会話での迷子

大規模言語モデル(LLM)とチャットしていて、ちょっと会話が長くなると、「あれ?なんか話が噛み合わなくない?」って感じることありますよね?なんか、意図がうまく伝わっていないような・・・

最新の研究論文を見ると、どうやらそれ気のせいじゃないみたいなんです。今回は、そのLLMが指示を一気に受け取るのと、会話みたいにちょっとずつ受け取るので、どうパフォーマンスが変わるのか、その理由について紹介したいと思います。LLMともっと上手に付き合うためのヒントになれば幸いです。

「ロストインコンバセーション」現象の発見

この研究で一番話題となった発見が、会話での迷子(ロストインコンバセーション)と名付けられた現象なんです。

要するに、LLMって、情報を全部まとめて、どんと渡される完全指定の指示だと、すごく賢くタスクこなすんですけど。でも、同じタスクなのに、情報を小出しに、会話みたいに何ターンかに分けて伝えると、なんとパフォーマンスが平均で39%も落ちちゃうらしいです。結構大きいですよね。

で、これ単なる数字じゃなくて、多分、あのLLMと話してて、「あれ?なんかとんでもない頓珍漢な方向に進んでるぞ」って感じる、あのフラストレーションの具体的な表れなのかなと。LLMがまだ、その文脈をずっと追い続けるスタミナみたいなものが十分じゃないってことかもしれませんね。

しかも驚くのが、例えば、GPT-4.1とかClaude 3.7 Sonnetみたいな、比較的新しいモデルだけじゃなくて、Llama 3.1-8Bみたいな、比較的小さなオープンソースモデルでも、軒並み30%から40%落ちちゃうらしいです。モデルの規模にあんまり関係なく起きるんです。

だから、この「会話での迷子」って、今のLLMに共通する、根深い課題かもしれないってことですよね。

研究手法:シャーディングプロセス

そもそも、研究ではどうやってその会話形式の状況を作り出したんでしょう?

研究者たちはシャーディングっていうプロセスを考案したんです。一つの複雑な指示を、もっと小さな情報の断片(シャード)に分割するっていう手法です。最初のシャードで、まあ大まかなゴールを伝えておいて、後のシャードで徐々に詳細情報を足していく。これって私たちが、普段人と話しながら情報をやり取りする形に、結構近いですよね。

それをシミュレートしようとした訳です。会話をなんかパズルのピースみたいに、一つずつ渡していく感じです。

なぜLLMは会話で迷子になるのか?

なんでLLMは、そんな風に会話の中で迷子になっちゃうんでしょうか?研究ではいくつか原因が挙げられてるんですが、一つは、情報が全部揃う前に、焦って、「あ、きっとこういうことだろう」って全体像を推測して、回答を始めちゃうことですね。

途中でちょっと間違った方向に進んじゃっても、それに妙に固執しちゃう傾向もあるみたいです。その結果、最終的な回答が、なんか不必要に長くなっちゃう(回答の肥大化、なんで呼ばれてます)。

例えば、あの、コード生成タスクだと、複数ターンで、なんとか正解にたどり着いたとしても、一回の指示で正解した場合に比べて、平均で27%も長いコードになったそうです。解決策の質自体が、落ちてる可能性を示唆しているってことです。

他にも原因としては、会話の最初と最後の情報に、強く影響されすぎちゃって、真ん中辺の結構大事な情報を見落としちゃう傾向とかが知られています。冗長な回答を生成しちゃって、その中にユーザーがいてもいないような仮定を含んでしまったりとか。

信頼性の問題

さらに重要な問題として、信頼性の話があります。LLMの応答には、ランダム性があり、同じこと聞いても、微妙に違う答えが返ってきたりします。それを抑えるために、温度(temperature)っていう設定値をゼロにすることがあるんです。

単発の指示なら、これで確かに信頼性は上がるんですが、会話だとそう単純じゃなくなります。驚くことに、複数ターンの会話だと、この温度ゼロの効果がかなり薄いってことがわかりました。

例えば、GPT-4Oっていう高性能モデルでさえ、ユーザー側とアシスタント側、両方の温度をゼロにしても、約30%もの応答の非信頼性が残ったと報告されています。

おそらく、会話の本当に最初の段階でのごくわずかな応答の揺らぎ、ブレみたいなものが、後のターンでこう雪だるま式にどんどん大きなズレを引き起こしちゃうからだと考えられているようです。

つまり、現状のLLMでは、複数回のやりとりが続く対話において、毎回ビシッと一貫して信頼できる結果を得るっていうのは、かなり難しいということなんです。

だから、同じようなことを聞いてるつもりでも、会話の流れ次第で全然違う答えが返ってきたり、「あれ、さっきと言ってること違うじゃん」って感じることがある。対話で時々感じるかもしれない、あのモヤモヤの背後には、こういうメカニズムがあったということなんです。

「会話の迷子」をまとめると

この研究が示しているのは、今のもう非常に強力だって言われているLLMでさえ、特に複数ターンにわたる情報のやりとり、つまり対話においては、まだ完璧なパートナーとは言えない。特に、信頼性という点で大きな課題を抱えているということですね。

なので、LLMの開発者にとっては、単に複雑なタスクをこなす能力、まあ言ってみれば適性みたいなものを高めるだけじゃなくて、安定して一貫した結果を出す能力、つまり信頼性をもっと重視していく必要です。おそらく、この辺りはLLMメーカー各社がすでに取り組んでいると思います。なぜなら、この無駄なやり取りがリソースを圧迫していて、これがなくなればもっとコスト削減できますからね。

解決策の紹介

で、その辺を論文で調べると、結構解決策はありましたので、軽く紹介します。

MemGAS (Multi-Granularity Memory Association and Selection)

論文: https://arxiv.org/pdf/2505.19549

このフレームワークは、LLMが長期的な会話記憶を維持できないという課題に直接対処することを目的としています。

方法の簡単な解説:

  • 多粒度記憶の関連付け: LLMを利用して、会話の「サマリー(要約)」や「キーワード」など、様々な粒度で記憶単位を生成します。新しい記憶が追加されると、ガウス混合モデル(GMM)を使用して、関連性の高い既存の記憶をクラスター化し、直接的な関連付けを確立します。これにより、人間のような記憶の統合を模倣し、連結された記憶構造を構築します。 
  • 適応的粒度選択: エントロピーベースのルーターが、クエリの関連性分布の確実性に基づいて、異なる粒度(セッション、ターン、サマリー、キーワード)に重みを適応的に割り当てます。エントロピーが低い(確実性が高い)粒度には大きな重みが与えられ、クエリに最も関連性の高い情報が強調されます。 
  • 記憶の検索とフィルタリング: 初期スコアに基づいて、パーソナライズされたPageRank (PPR) アルゴリズムをグラフ構造の記憶に適用し、文脈に応じた関連性の高い記憶を検索します。検索された記憶は、LLMベースのフィルタリングメカニズムによって冗長性やノイズが除去され、最終的な応答生成のために最も重要な情報のみが提供されます。

MemoryOS (Memory Operating System)

論文: https://arxiv.org/pdf/2506.06326

この論文は、LLMが固定されたコンテキストウィンドウと不適切なメモリ管理に起因する長期記憶能力の不足とパーソナライゼーションの限界という課題を解決するために、MemoryOSというメモリ管理のためのシステムを提案しています。

方法の簡単な解説:

  • 階層型ストレージアーキテクチャ: 短期記憶(STM)、中期記憶(MTM)、長期個人記憶(LPM)の3つのレベルの記憶単位からなる階層構造を採用しています。
  • 短期記憶 (STM): リアルタイムの会話データを「ダイアログページ」として格納し、会話の流れを追跡するために「ダイアログチェーン」を構築し、文脈の一貫性を維持します。
  • 中期記憶 (MTM): オペレーティングシステムのメモリ管理原則に触発され、同じトピックのダイアログページを「セグメント」にグループ化するセグメントページングストレージアーキテクチャを採用しています。セグメントの「ヒートスコア」(検索回数、総ダイアログページ数、時間減衰の組み合わせ)に基づいて更新および削除が行われます。
  • 長期個人記憶 (LPM): 特定のヒートしきい値を超えたセグメントがLPMに転送され、「ユーザートレイト」「ユーザー知識ベース(KB)」「エージェントトレイト」を更新し、パーソナライゼーションを可能にします。
  • 動的更新: STMからMTMへの更新は、ダイアログチェーンベースのFIFO(先入れ先出し)原則に従い、MTMからLPMへの更新は、セグメントページ編成戦略とヒートベースの優先順位付けを利用して行われます。
  • 応答生成: これら3つの記憶レベル(STM、MTM、LPM)から関連コンテンツを検索し、それらを最終プロンプトに統合することで、LLMは現在の対話に文脈的に一貫性があり、過去の対話の詳細や要約に基づき、ユーザーやアシスタントのアイデンティティに合わせた応答を生成します。

RAGシステムと意図ベースのハイブリッドフレームワーク

論文: https://arxiv.org/pdf/2506.02097

この論文は、LLMが多ターン会話の一貫性を維持することや、高い計算コストといった実世界の課題に直面していることを指摘し、RAGシステムと意図ベースの定型応答を組み合わせた新しいハイブリッドフレームワークを提案しています。

方法の簡単な解説:

  • 動的クエリルーティング: ユーザーのクエリの「意図の信頼度」を評価します。信頼度が高いクエリは、低遅延と効率性を実現するために事前定義された定型応答で処理されます。信頼度が低い、または曖昧なクエリは、外部知識から文脈的に豊かな応答を生成するためにRAGパイプラインにルーティングされます。
  • 対話コンテキストマネージャー: 以前のクエリと応答の埋め込みを含む「スライディングウィンドウ」を使用して対話履歴を追跡し、多ターン対話全体で一貫性を確保します。
  • フィードバック駆動型適応: 明示的(評価)および暗黙的(クエリの再調整)なフィードバックをログに記録し、システムが時間とともに適応するように、意図、定型応答、および信頼度しきい値を継続的に改善するために使用されます。
  • 応答生成: 定型応答とRAGの出力をLLMを用いて統合したり、ルーティングに基づいて直接ユーザーに渡したりします。

FlowKV: 分離型キー・バリューキャッシュ管理による多ターン会話コヒーレンス強化

論文: https://arxiv.org/pdf/2505.15347

この論文は、大規模言語モデル(LLM)が多ターン会話アプリケーションで直面する、KVキャッシュの線形的な増加による高い計算コストと、既存の圧縮戦略による初期の会話履歴の繰り返し圧縮が引き起こす情報損失と文脈の忘却という重要な課題を指摘しています。これらの問題は、LLMが長期にわたる対話で一貫性を維持する能力を著しく低下させ、指示追従やユーザー選好維持のパフォーマンスを劣化させます。FlowKVは、これらの「ロストインコンバセーション」問題(文脈の忘却、情報劣化)を軽減し、LLMが多ターン対話において首尾一貫した、文脈に沿った応答を維持できるよう設計された新しいメカニズムです。

方法の簡単な解説:

  • 多ターン分離メカニズム: FlowKVの中核となる革新は、以前のターンから蓄積された圧縮済みKVキャッシュの完全性を「維持・保存」する点です。これにより、過去の文脈が繰り返し再圧縮されることを防ぎ、壊滅的な忘却(catastrophic forgetting)を緩和します。
  • 選択的圧縮: 圧縮は、最新の完了したターンで新しく生成されたKVペアにのみ戦略的に適用されます。これは、従来の圧縮方法が、システムプロンプトを含む過去の履歴全体をターンごとに再圧縮することで情報劣化を引き起こすのに対し、FlowKVはすでに圧縮された部分を保護し、新しい部分のみを圧縮するという点で異なります。
  • 既存手法との互換性: FlowKVは、追加の訓練なしに、既存のあらゆるKVキャッシュ圧縮方法(SnapKV、StreamingLLM、ExpectedAttention、ChunkKVなど)と統合可能な汎用的なフレームワークです。
  • パフォーマンスの向上: FlowKVは、特に文脈の蓄積と圧縮の影響が顕著になる後の対話ターンにおいて、ベースライン戦略を一貫して大幅に上回る性能を示します。指示追従率(IFR)は平均で20%以上向上し、PrefEvalデータセットにおけるユーザー選好保持は、LLaMA-3.1-8Bで10.90%から75.40%へと大幅に改善しています。これにより、モデルは会話の関連性と創造性を維持し、新しい指示を正常に実行できることが示されています。
  • 堅牢性と効率性: FlowKVは、さまざまな圧縮率(0.1から0.9)において、情報フローを堅牢に保持できます。また、既存のKVキャッシュ圧縮技術の効率性を損なうことなく、無視できるほどのオーバーヘッドでシステム効率をさらに向上させることが可能です。

最後に

このように最新研究を追っていくと、まもなく、皆さんが利用しているLLMアプリもアップデートされ、「ロストインコンバセーション」問題は薄らいでいくのではないかと思われます。

つまり、根本的な対策はメーカーに任せる(開発してもいいけど物量で負けるのがオチかと)として、それまでの間は、この論文にあるように「良いプロンプトを投げて、1回で回答を得る」ことに尽きると思います。1回目が気に入らなかったら、会話を続けず、最初の文章に追加したプロンプトに切り替えて、新たな気持ちで指示を出すってことでしょうね。(向こうが忘れるなら、こっちも忘れてあげましょう・・・)