- ユーザーが要件を一度で完全に書けない状況では、15種類のLLMのマルチターン・不完全命令での性能は、シングルターン・完全命令より大きく低下し、6つの生成タスク平均で90%から65%まで落ちた
- 実験は既存のシングルターンベンチマーク命令を複数の断片に分ける**シャーディング(sharding)**方式で構成され、対話が進むにつれて条件や文脈が少しずつ明らかになるようにした
- 性能低下は単純な能力不足よりも不安定性の増加の影響が大きく、20万件以上の対話でモデルは初期の仮定や早すぎる最終回答の試みに過度に依存した
- テスト対象にはLlama3.1-8B-InstructからGemini 2.5 Proまでが含まれ、Code、Database、Actions、Math、Data-to-Text、Summaryなど、プログラミングと自然言語生成タスクをあわせて用いた
- 実際の人間-AI対話を単純化したシミュレーションではあるが、すべての対話が課題解決に十分な情報で終わるよう設計されているため、観測された低下幅は実際の不完全なマルチターン対話より小さい可能性がある
シングルターン評価と実際の対話利用のギャップ
- LLMはChatGPT、Gemini、Claudeのような対話型インターフェースで使われ、ユーザーは最初から要件を完全に特定できなくても、複数ターンを通じて要求を定義・探索・修正できる
- 既存のLLM評価は主にシングルターン・完全命令環境に集中してきたが、LLMの対話ログではユーザー指示の不完全性が頻繁に現れる
- 既存のマルチターン評価の多くは、対話を独立に評価可能な下位課題の配列として扱うepisodic方式に近い
- ターン間の文脈理解をある程度要求するが、不完全なユーザー指示から情報を能動的に統合する状況とは異なる
- こうした課題は、マルチターン対話でのLLM性能を実際より高く見せる可能性がある
シャーディングで作った不完全なマルチターン対話
- 実験では、高品質なシングルターンベンチマークの完全な命令をsharded instructionに変換した
- 最初のshardは課題の高レベルな意図を提示する
- その後のshardは、元の命令に含まれる追加条件や文脈を1つずつ提供する
- すべてのshardを合わせると、元の完全命令と同じ情報を含む
- 例としてGSM8Kの雪玉問題では、単一の問題文で「1時間あたり20個作る」「15分ごとに2個溶ける」「合計60個必要」といった条件をすべて与えるが、sharded版ではこれを複数ターンに分けて公開する
- シャーディングの過程は半自動で行われ、GPT-4oが候補を作成・検証した後、研究者が確認・修正した
対話シミュレーションの構造
- マルチターンシミュレーションには3つの主体がある
- 評価対象のassistant: 性能を測定するLLM
- user simulator: 完全なsharded instructionを把握しており、各ターンで次のshardを公開するLLM
- system: assistantの応答を分類し、回答の試みを評価する構成要素
- 最初のターンでuser simulatorは最初のshardだけを公開し、assistantは自由テキストで応答する
- assistantの応答は7種類の戦略のいずれかに分類される
- clarification
- refusal
- hedging
- interrogation
- discussion
- missing
- answer attempt
- answer attemptと分類されると、answer extractorがコード片、数値、SQLなど評価に必要な回答範囲を抽出し、課題別evaluatorが採点する
- 対話は次のいずれかの条件で終了する
- assistantの回答試行が正解と評価される
- 新しいターン開始時に、これ以上公開するshardがない
- user simulator、strategy classifier、answer extractorは、プロンプトベースのGPT-4o-miniで実装された
- 数百件の対話を手動アノテーションした結果、user simulator・classifier・extractorの誤りは調査した対話の5%未満で発生し、assistantモデルに不利に働いた誤りは2%未満だった
比較した5種類のシミュレーション
- FULLは元の完全命令を最初のターンで提供するシングルターンシミュレーションで、基本性能のベースラインとして使われる
- SHARDEDはshardを複数ターンにわたって公開するマルチターン・不完全対話で、中核となる評価環境である
- CONCATはshard群を1ターンのbullet-point命令としてまとめて提供する
- FULLのように不完全性は除去される
- SHARDEDのように、シャーディング過程で生じた言い換えは維持される
- FULLとCONCATでは成功するのにSHARDEDで失敗するなら、原因は情報損失よりもマルチターン性・不完全性そのものかもしれない
- RECAPはSHARDED対話の後、最後にすべてのshardをまとめて再提示し、LLMに最終回答の機会を与える
- SNOWBALLは各ターンで新しいshardと、それまでに公開されたすべてのshardをあわせて言い直し、ターンごとに累積要約を提供する
使用した課題とベンチマーク
- 実験は、プログラミングと自然言語生成のユースケースをともに含む6つの生成タスクで構成された
- 各タスクごとに90〜120件のsharded instructionを用意し、全体では600件のinstructionとなる
- タスク構成:
- Code: HumanEval、LiveCodeBenchベースのPython関数作成
- Database: Spiderベースのtext-to-SQL生成
- Actions: Berkeley Function Calling LeaderboardベースのAPI関数呼び出し生成
- Math: GSM8Kベースの初等数学文章題の解法
- Data-to-Text: ToTToベースの表データ説明文生成
- Summary: Summary of a Haystackベースの文書群要約と引用生成
- 評価指標は元のベンチマークの指標を再利用した
- CodeとDatabaseは実行ベースの正確性
- ActionsとMathは参照回答との意味的等価性または数値の正答
- Data-to-TextはBLEU
- Summaryは情報網羅性と出典帰属の正確性を測るLLM-as-a-judgeの“Joint Score”
- 二値精度も0〜100の範囲にマッピングし、すべてのタスク得点を同じスケールで集計した
性能、能力、不安定性の測定
- LLM出力は確率的であるため、同じinstructionとシミュレーション種別に対してN=10回の反復実行を行った
- 各実行は0〜100の範囲のスコアで評価された
- 3つの指標を用いた
- 平均性能 P: 反復実行スコアの平均
- aptitude A90: スコアの90パーセンタイルで、上位10%実行におけるbest-case性能の推定
- unreliability U90-10: 90パーセンタイルと10パーセンタイルの差で、best-caseとworst-caseのあいだのギャップを測る
- シングルターンではaptitudeが高いモデルほど信頼性も高い傾向があったが、マルチターンではaptitudeに関係なく、すべてのLLMで高いunreliabilityが見られた
大規模実験の結果
- メイン実験は600件のinstruction、3種類のシミュレーション種別(FULL、CONCAT、SHARDED)、15種類のLLMを対象に実施された
- 各組み合わせを10回ずつ繰り返し、20万件以上の対話をシミュレーションした
- すべてのシミュレーションは基本temperature T=1で実施され、temperatureがaptitudeとreliabilityに与える影響は別の補助実験で扱われた
- 全体として、マルチターン・不完全対話の平均性能は**65%で、最初から完全な命令を受け取るシングルターン性能90%**より25ポイント低かった
- 小規模なopen-weightモデルから最新モデルまで、マルチターン性能の低下が共通して見られた
- テスト対象にはLlama3.1-8B-Instructのような小規模open-weightモデルと、Gemini 2.5 Proのような最新モデルが含まれる
- Figure 1にはClaude 3.7 Sonnet、Deepseek-R1、o3、GPT-4.1、Gemini 2.5 Proが例として示されている
- 6つの生成タスク平均での性能低下は**39%で、Figure 1ではマルチターン設定で約-35%**の性能低下が示されている
なぜ道に迷うのか
- 性能低下は2つの要素に分けられる
- aptitudeの低下: best-case性能そのものが一部低下する
- unreliabilityの増加: 実行間の品質差が大きく広がる
- Figure 1基準では、マルチターンでaptitudeは**-15%低下し、unreliabilityは+112%**上昇した
- モデルは不完全な初期情報だけを見て誤った仮定を作り、対話の早い段階で最終回答を試みる傾向を示した
- その後に新しい情報が与えられても、以前の誤った回答試行に過度に依存し、方向修正に失敗する
- マルチターンの不完全対話で、一度誤った方向に入ると回復できない現象をlost in conversationと定義している
限界と実務的含意
- 完全自動シミュレーションは、実際の人間-AI対話をそのまま代表するものではない
- 実験環境は単純化・理想化されている
- 対話は課題を解くのに十分な情報で終わることが保証される
- 実環境で起こりうる脱線のような予期しない挙動は制限される
- こうした設計のため、観測された性能低下は、実際の不完全なマルチターン人間-AI対話で起こる低下を過小評価している可能性がある
- LLMベースの対話製品を作る組織とエンドユーザーは、マルチターン信頼性をシングルターン能力とあわせて評価すべきである
- 最初から不完全な要件を完全に書くのが難しい初心者ユーザーにとって、マルチターン性能の低下はAIシステム利用の普及を妨げる要因になりうる
1件のコメント
Hacker Newsの意見
LLMツールを使ったことがある人なら、ヒューリスティックにすでに知っていたことを論文が確認してくれるのはうれしい。クリーンな文脈の維持が重要であり、「会話」は製品インターフェースが作り出した構成物にすぎず、LLM自体の応答品質には害になる。文脈が一度汚染されると回復しないので、新しいチャットでやり直す必要がある
2週間の終わりごろには、LLMはずっと散漫でなくなり、フォーラムスレッドやStack Overflowの投稿全文を入れても、「これはここで見ている現象ではない。理由は[以前の文脈や発見]による」と区別してくれた。行き止まりは私が論理的に除外して伝える必要があったが、最終的には原因を見つけた
LLMは複雑な情報を単純に圧縮するのは得意で、単純なアイデアを複雑なものへ拡張するのは苦手だ、という話にも合っているように見える。入力が出力より大きいか複雑なときは、結果に満足できた
LLMなしでもできたが、序盤から入れておいた事実を忘れていたり、新しい文脈で素早く思い出せなかったりするときに、保存庫のように助けになったし、大きなログファイルの時間パターンを見つけるのにも役立った。1つの問題を直しただけでなく、複数の設定も最適化でき、かなり多くを学べた。現在のパラメータ状態をたまに取り違えることはあったが、簡単に修正できた。どこへ向かっているかを理解したうえで道具として扱えば助けになるが、意思決定を委ねたり、間違った方向に引っ張らせたりしてはいけない
全体の使用量は350kトークンほどだった。関連するブログ記事は https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/ にあるが、この特定の問題と直接一致するわけではない。WireGuardの推薦は遠慮する
誰かが最近プロンプトを調整して白人虐殺に関する見方を指定した可能性が高く、完璧なチャットボットなら別の話題を聞いたときには重要でないはずだが、実際には重要になる。それが文脈の一部なので、今ではその話をするようになっている
よく知られた過信と自己省察不能の一側面のように見える。事前確率が低すぎると、もっと詳しい情報を求めるべきだと気づけない。推論モデルの出力を見ると、説明を求める質問をすべきだという発想がほとんど出てこず、混乱したときにはユーザーが何を意味していたのかを延々と推測するだけだ
これは「人間のプログラマー代替」という考えの賢明さにも含意がある。この仕事の難しい部分の1つは、利害関係者とやり取りしながら、曖昧でしばしば混乱したアイデアを正確な仕様に変換することだからだ
たいていの場合、ユーザーは映画脚本文書のUserキャラクターの台詞を書いていて、LLMアルゴリズムは定期的にChatbotキャラクターの未完成の台詞をオートコンプリートしているだけだ
DraculaBotという吸血鬼にインタビューすることはできるが、そのキャラクターは「血を渇望する」とか「コウモリの群れに変身する」といった浅く虚構的なやり方でしか「自己省察」できない
だからオートコンプリートが悪くなり始めたら、最初からやり直す必要がある。そこには何の概念もなく、訓練テキストが示した単語と、そのありうる後続テキストの巨大な塊があるだけだ
ときどきLLMに、ここまでの議論をプロンプト形式の簡潔な要約にしてくれと頼む。それを適切に編集して荷物のない新しい会話を始めるのに使うと、とても効果的だった。たぶんすぐ自動化されると思う
そのため、TSCE（Two-Step Contextual Enrichment）が作られた。GPT-35-turboで300件のタスクを混ぜてテストしたところ、30ポイント向上があった
無料公開のフレームワークで、リポジトリで直接試せる: https://github.com/AutomationOptimization/tsce_demo
人々が嫌う目立つ「em-dash」を取り除く作業で、gpt-4.1でもう一度300回テストした。単一パスのベースラインとTSCEを、同じ指示とプロンプト「Remove the em-dashes from my linkedin post. . .」で比較した
300回のうち、ベースラインは149/300回でem-dashの除去に失敗し、TSCEは18/300回失敗した。実際に動作し、すべてのデータとテストスクリプト全体がリポジトリにある
text.replace("—", "-")は聞いたことがないのだろうかシステムプロンプト:
"Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."ユーザープロンプト:
Temperature: 0.0
この問題を解く取り組みをかなりうまく進めていて、近いうちにさらに共有する予定だ。システムは2つあり、1つ目はLLM自体、もう1つは一種の思考キュレーターのように動作する
文脈の一部を動的に出し入れし、明示的な定義に基づくのではなく、LLMが「空白を埋める」能力に依存する。このシステムは、LLMが問題を小さなタスクに分解するのを助け、その小さなタスクが最終的に全体のタスクとして集約される
今後はこうしたメモリ階層の区分がより明確になっていく気がする。学習データの一次メモリ、文脈の二次メモリ、RAGの三次メモリのように分けられるかもしれない
主要なチャットツールで分岐/フォークが中核機能ではないのは驚きだ。応答の編集はできるが、その場合ほかの文脈がかなり失われる
自分の流れはだいたい 1) 計画 2) 実装 3) 分岐（機能や奇妙な依存関係の問題で） 4) 2に戻る、だ。プロンプトの剪定と分岐は、どんなLLM利用でも一級のツールであるべきだ
単一ターン対話中心でLLMインターフェースを作ると、目立つ問題がある。ほとんどの人は線形の会話を期待する
LLM向けの汎用UIとしてTelegramボット http://t.me/experai_bot を作ったが、機能はやや絞り、「返信でないメッセージは新しい会話」という考えを中心に設計した。文脈を維持したければ、ボットの返信に対してそのまま返信し続ければよい。上級ユーザーでない人には、この発想が難しい
OpenAIモデルが同じ質問に答えるとき、ごく小さなシステムメッセージがあるだけでも性能が悪化するのも見た。たとえば返信内の選択肢リストが短くなった。3.5と4oではそうだったが、最新モデルは分からない。なので基本的にシステムメッセージは入れないことにした。それでも必要なら追加でき、オンオフしながら組み合わせることもできる
今のLLM分野は、同じ問題を何度も繰り返し解いている人たちで満ちている感じがする
これが、私がpromptdownを作った主な理由だった。毎ターンチャット履歴全体を編集できるようにしたかったが、追記一辺倒の標準的なチャットインターフェースではそれが簡単ではない
https://github.com/t-kalinowski/promptdown
「プロンプトエンジニアリング」という言葉への揶揄は、人々が初期プロンプトの重要性を過大評価し、進行中の文脈管理の重要性を過小評価していることから来ている面もあると、ずっと感じていた
経験を通じて、どうモデルを操縦するか、いつ新しい会話を始めるべきかの勘が身についてくる。システムプロンプトや初期プロンプトも重要だが、無邪気に会話を長く引き延ばしすぎると、何も救ってくれない