- 長期対話型チャットボットは、長いコンテキストウィンドウがあっても、過去の相互作用の核心を応答に安定して反映することが難しく、この研究は 再帰的要約メモリ によって一貫性の問題を減らす方法を扱う
- 中核となる手順は、短い対話から初期メモリを作成した後、セッションが追加されるたびに 以前のメモリと新しい対話 を一緒に要約して最新メモリへ更新する方式である
- 検索ベース方式は、必要な過去発話を正確に見つける検索器に依存し、既存のメモリベース方式では更新されていない 古い情報 が応答品質を揺るがす可能性がある
- Llama、ChatGLM、OpenAI GPT-3.5-Turbo など公開・非公開LLMでの実験では、自動評価と人手評価の両方で、既存アプローチより長期対話の 一貫性 が高く現れた
- この方式は長いコンテキストウィンドウや検索拡張LLMとも併用でき、対話全体の長さをやみくもに増やさずに 非常に長い対話文脈 を扱う実用的な選択肢になりうる
長いコンテキストだけでは不十分な長期対話記憶
- GPT-4、ChatGPT のようなLLMはさまざまな話題で動的かつ文脈に即した対話を行えるが、長期対話 では過去情報を取りこぼして一貫性のない応答を生成することがある
- 長いコンテキストウィンドウによって対話履歴全体を入力として処理できても、過去の相互作用を理解し、重要情報を応答に統合する能力は依然として限られている
- 過去対話の記憶が必要となる代表例は、個人向けAIコンパニオンと健康支援サービスである
- 個人向けAIコンパニオンは、関係形成のために以前の対話を思い出す必要がある
- 健康支援サービスは、診断結果を提供するために患者の問い合わせ履歴全体を考慮しなければならない
- Multi-Session Chat Dataset の例では、約20ターン後にユーザーが過去の「作曲」という話題に再び言及したとき、ChatGPT gpt-turbo-3.5-0301 バージョンは自分を「伝統的な意味での職業を持たないAI言語モデル」と答え、以前のペルソナと 不一致 な応答を生成した
検索ベース・メモリベースアプローチの限界
- 長期対話能力を強化する代表的アプローチは 検索ベース方式 と メモリベース方式 に分かれる
- 検索ベース方式は、過去発話をストレージに保存し、現在の対話と最も関連する履歴を検索器で見つけて応答生成に活用する
- 現在の対話に必要な意味を完全に捉える理想的な検索器を得るのは難しいという限界がある
- メモリベース方式は、別途学習したモデルや強力なLLMで過去対話を要約し、重要情報を保存する
- 反復更新メカニズムが不足すると、保持された 古い情報 が応答品質を直接損なう可能性がある
- MemoChat は話者のトピックごとに過去の対話履歴を再構成し、生成時に構造化メモリから検索するようLLMをプロンプトする
- MemoryBank は各対話セッションの要約をまず作成し、それをグローバル要約へ圧縮するメモリメカニズムを提案する
- 保存されたメモリが完全に固定されると、進行中の対話との一貫性を保証しにくい
再帰的に更新されるメモリ生成
- 提案方式は、LLM自体が要約を作成し、過去文脈を継続的に更新・見直しながら話者の リアルタイム情報 を保存するシンプルなプラグイン方式である
- 手順は3段階で構成される
- 生成系LLMが短い対話文脈を入力として受け取り、初期要約を生成する
- その後、以前のメモリと後続の対話を結合し、新しい要約またはメモリを継続的に更新する
- チャットボットは最新メモリを主要な参照として用い、現在の対話に応答する
- 生成された要約は対話全体よりはるかに短いため、最大入力長を高コストで拡張しなくても、複数セッションにまたがる非常に長い文脈を扱える
- 長期対話は複数セッションからなる Multi-Session Dialogue として定義される
- 過去セッション集合
S = {S1, S2, ..., SN} と現在セッションの対話文脈 Ct、正解応答 rt を用いる
- 目標は、過去セッションと現在文脈に基づいて、関連性が高く一貫した応答を生成することである
- メモリ
Mi は i番目のセッション終了時点で利用可能なメモリであり、全体の過程は各メモリが現在セッションと以前のメモリのみに依存する 逐次的過程 として定義される
メモリ反復と応答生成
- 提案方式は任意のLLMに2つの作業を担わせる
- メモリ反復: 長期対話の流れに従って重要情報を再帰的に要約する
- メモリベース応答生成: 最新メモリと現在の対話を組み合わせ、適切で一貫した応答を生成する
- メモリ反復は、チャットボットが利用する一貫性のある最新状態の要約を得る過程である
- 一部の既存研究では、要約に replace、append、delete のような「ハード演算」を適用してメモリを更新する
- こうした方式は、演算ラベル付きの高品質な対話に依存し、要約の意味的一貫性を損ね、長期的な管理にも適していない
- 提案方式は、対話文脈と以前のメモリを一緒に入力し、LLMにメモリまたは要約を再帰的に生成させる
- 以前の要約を活用することで、モデルは現在の対話文脈をよりよく消化し、高品質なメモリを作れる
- 例では、最初のセッション後に初期メモリが作られ、2番目のセッション後には以前のメモリに「ボットが最近24時間営業の新しいジムに加入した」という新しい性格情報が統合される
実験結果と適用可能性
- 実験は Llama、ChatGLM、OpenAI GPT-3.5-Turbo など最新の公開・非公開LLMで実装された
- 長期対話性能は、自動評価と人手評価の両方で既存の人気アプローチより高く現れた
- 明示的メモリを長期対話に使う効果と、提案方式で生成したメモリがLLMにとってより消化しやすいことを検証した
- インコンテキスト学習（ICL）を組み合わせると応答品質をさらに高められる
- 複数の
(対話, メモリ, 正解応答) 形式サンプルをLLMに提示する
- LLMが生成されたメモリをより柔軟に活用できるようにする
- text-davinci-003 では BLEU スコアが約 +3% 改善 した
- 提案方式は GPT-3.5-Turbo-16k、LongLoRA-8k のような長いコンテキストウィンドウLLMや、LLM-BM25、LLM-DPR のような検索拡張LLMを補完する
- 公開コードは qingyue2014/Rsum で提供されている
1件のコメント
Hacker News の意見
「テキスト空間」にメモリを積み上げるやり方は、どれもかなりハックっぽく感じる
モデルの意味を完全に保つには、要約を何度も再生成する継ぎ足しの手順より、密な埋め込み空間に保存するほうが自然に見える
また、モデルはメモリを認識して活用するように訓練されるべきで、できれば最初からそうした設定で学習されるのがよいと思う
結局、与えられた会話に次の単語をもう1つ付け足せと指示しているだけで、ある時点で終了トークンを出すと、アプリケーションが再びユーザーに制御を渡す構造になっている
潜在空間とテキスト空間は、思っているほど離れていないと思う。LLM はかなり鈍いが、話すことには非常に長けており、コードを書くのもそれに近いのでうまくできる一方、数学のように実際の抽象的思考が必要な領域では崩れる
こうしたテキスト空間のハックは実際によく効くことが多く、「段階的に考えよ」のようなプロンプトが一般的になったのもそのためだ
LoRA はあなたの言った方向性により近く、ごく少ないデータに多くの理解を圧縮するのに優れている。ただし、単一の会話のために重みを調整するのはまだ現実的ではないので、その用途ではテキスト空間を探索しているところだ
頭の中で何かを要約することが「ハックっぽい」と感じられるかもしれないが、実際の記憶の仕組みの大きな部分はそれに近いと思う
https://news.northwestern.edu/stories/2012/09/your-memory-is...
私の理解では、埋め込みは本質的に損失圧縮に近い。テキスト要約なら、少なくともエージェントがその要約が元の情報を正確に代表しているかを検証できる
CodeRabbit では、PR のインクリメンタルレビューとコード変更の文脈での会話のために、すでにこの方法を使っている
ボットが実際よりはるかに多くの文脈を持っているように見せられ、大きな PR（100 ファイル以上）にまで AI コードレビューを拡張するために使っているいくつかのコツの1つだ
各コミットごとにファイル別 diff を要約し、さらに要約の要約を作り、PR にコミットが追加されるたびに段階的に更新する。この要約の要約は PR コメント内に隠して保存され、各ファイルをレビューしたりユーザーの質問に答えたりする際に使われる
コードの一部はオープンソースで、再帰要約に使う関連プロンプトはここにある: https://github.com/coderabbitai/ai-pr-reviewer/blob/main/src...
[0]: coderabbit.ai
もしそうなら、自由テキスト出力をパースする代わりに function calling を試したことがあるのかも気になる
「コードとスクリプトは後で公開」という段階なら、今ではどんな主張も信じにくい
本当かもしれないし、たわごとかもしれないが、低コストで実験を再現する方法がなければ、こうした論文は著者が履歴書に載せるために書いたものだと見る
LLM 分野で「コードは後で公開」という論文を6か月以上待ってきたが、実際に公開される兆しはない。なかにはパーキングドメインにつながる壊れたリンクまで載せるほど厚顔な論文さえある
そろそろコミュニティは、この未公開コードの慣行をきちんと認識すべき時だ
以前、似たようなアイデアを API ダッシュボードでプロンプトだけ直接いじりながら試したことがあり、可能性はあったが API コストに見合う価値があるようには見えなかった。おそらくベクトル埋め込み方式のほうがずっと良い可能性が高い
個人的な事例として、会社には1時間、場合によっては丸1日かけて行われるオフラインのパネル「Briefings」が何千件もある
各ブリーフィングの要約には成功し、雑然とした文字起こしが5段落の要約としてうまく整理された
より関連が深いのは、各ブリーフィングをトピックとサブトピックに 1:N 分類した点だ。トピックには数十件のブリーフィングが、サブトピックには十数件のブリーフィングがまとまり、関連する要約の部分集合をさらに要約して広範にテストしたところ、LLM で非常に良い結果が出た
最初はこれがうまくいくか懐疑的だったが、非常によく機能した。十分に大きなコンテキストウィンドウがあればこうはしなかっただろうが、幸い問題にはならなかった
問題をマップリデュースのように分割するほうが、32k の巨大なコンテキストウィンドウにすべて押し込んで一度に解かせるより、はるかにうまくいくと思う
数か月前にオープンソースモデルで再帰要約メモリを作ってみたが、素朴に実装すると特定の話題に永遠に閉じ込められることが多かった
いくつかの断片がすべての要約ラウンドで生き残るため
どんなテキストブロックでも、情報を一切失わずにより小さなテキストブロックへ縮めることは不可能
それが可能なら無限圧縮が可能という意味で、どんなデータセットも1ビットに縮めてから完全に復元できなければならない。しかしそれはできない
会話を要約に圧縮すれば、必ず一部の情報は消える。どれだけチューニングし、畳み込み、賢いやり方を使っても、根本的に情報損失は発生する
しかもこのプロセスは再帰的なので、どこかの時点で要約の束を再び要約することになり、そのときもある程度の情報が失われる
だから些細なケースでは役に立つだろうが、再帰要約をプロンプトに入れるのはかなり愚かで、実際に有用なことをさせるとほぼ確実にうまく動かないと思う。再帰要約をあまり使わないうちは失う情報が少ないので動いているように見えるだけで、実際に使ってみればすぐ限界が露呈する可能性が高い
トラウマや発達過程だけでも人間の精神がどれほど簡単に軌道を外れるかを考えると、人間のようなAIという発想がどれほど希望的なものかを感じる
論文は少し期待外れ。手法の詳細は実質ほとんどなく、自分たちが使った方法論では良い結果が出るという表があるだけ
最近の科学ではよくあることだとは分かっているが、LLMを扱う開発者の立場では論文の価値はほとんどない。もちろん著者たちの学界内での名声は少し上がるだろうし、それが目的だった可能性が高そう
こういう感じで論文を何本か一緒に書いてみようかと思う。何本くらい書けば履歴書の一番上に「ML researcher」という肩書きを付けられるのか気になる
例とプロンプトにもっと多くの時間を割くべきだった
数週間前にも似たようなことを書いたが、人々は要約の部分を単純化しすぎている: https://news.ycombinator.com/item?id=37117515
長期記憶の価値はユースケースごとに微妙に異なる
ホームアシスタントを作るなら、NERで名前を識別し、その人にメッセージを送るときにどんな口調を好むのか、場所や移動手段を理解する必要がある
カスタマーサポートボットを作るなら、長い会話につながった問い合わせや、突然のカート離脱につながった問い合わせを識別する必要がある
一般的な要約レベルだけでも派手なデモは可能だが、今本当に有用な製品を作るにはもう一段進む必要がある
ここで何が新しいのかよく分からない
LLMベースのチャット履歴メモリ要約は、すでに多くのLLMフレームワークで実装されているよく知られた手法。論文のようにメッセージごとに要約すると大きな性能ボトルネックになり、チャットループにかなりの遅延を追加する
多くの実装は固定サイズのバッファを使い、バッファ外に押し出された古いメモリのまとまりを段階的に要約する。理想的にはこの処理もチャットループの外で行う
オープンソースの長期メモリストアであるZepの作者の一人で、私たちは要約をこの方法で実装した
0: https://github.com/getzep/zep
https://github.com/paul-gauthier/aider/blob/main/aider/histo...
https://www.deeplearning.ai/short-courses/langchain-for-llm-...
記事や議論からは少し外れる話だが、短いメモリが実際の限界であることは確か
ただしGPT-4の能力に対する批判の大半は、人間にも同じように、あるいはより強く当てはまると思う
逆チューリングテストの状況で、生身の誰かが自分はGPT-4だと私を納得させられるとは思えない。GPT-4の素早く整った回答だけでも人間の能力を圧倒する
たとえ人間のチームが各質問に60分ずつかけて答えられたとしても、興味深い質問に対するGPT-4の応答についていくのは難しいかもしれない。面白い競争になりそう
論文の実装は、実質的にはメモリのテキストをプロンプトの一部として付け加える方式
なぜコンテキストウィンドウのトークンを使わない保存・検索システムを使わないのか不思議。たとえば保存時、つまりユーザープロンプトが入ってきたときにデータをタグで自動分類し、検索時にはLLMが応答前に推定したタグでフィルタするクエリを投げられる
ハードコードされたタグ名やスタイルのような初期ルールがいくつかあるだけでも、かなり良い結果が出そうだという直感がある