Improving Factuality with Explicit Working Memory

生成日: 2026-05-24 02:20

# Improving Factuality with Explicit Working Memory

- 長文生成における hallucination を、生成中に外部検索と fact-checking の結果を受け取る明示的な作業記憶で抑える研究である。
- 提案手法 Ewe は、検索文書や検証結果を KV cache として複数の memory unit に保持し、文生成の途中で更新しながら次の出力に反映する。
- LongFact、Fava、AlpacaFact、Biography の四つの長文 factuality 評価で、VeriScore F1 をおおむね 2〜6 ポイント改善し、応答の有用性を大きく損なわなかった。

## Abstract（日本語訳）

大規模言語モデルは、hallucination と呼ばれる事実と異なる内容を生成することがある。近年の研究は、retrieval-augmented generation を基盤として、反復的なプロンプトにより factuality を改善してきたが、これらの方法は従来型の RAG 設計に制約されている。この課題に対処するため、本論文では Ewe（Explicit Working Memory）を導入する。これは、外部資源からリアルタイムのフィードバックを受け取る作業記憶を統合することで、長文テキスト生成の factuality を高める新しい手法である。この memory は、オンライン fact-checking と検索からのフィードバックに基づいて更新されるため、Ewe は生成過程で誤った主張を修正し、より正確で信頼できる出力を得ることができる。実験では、Ewe が四つの fact-seeking な長文生成データセットにおいて強い baseline を上回り、応答の有用性を犠牲にせずに、factuality 指標である VeriScore を絶対値で 2〜6 ポイント向上させることを示した。さらに分析により、memory 更新規則の設計、memory unit の構成、検索 datastore の品質が、モデル性能に影響する重要な要因であることが分かった。

## 論文の面白いところ

この論文の中心は、RAG を「入力の前に文書を貼る仕組み」としてではなく、「生成中に更新される作業記憶」として扱う点にある。通常の RAG は、最初に検索した文書をプロンプトへ入れてから一続きの回答を作る。回答が長くなるほど、途中で必要になる情報や、生成済みの文に含まれる誤りを扱いにくくなる。Ewe はそこで、文を生成した後にいったん止まり、その文の claim を検査し、必要なら検索結果や fact-checking の反証情報を memory に入れ直す。誤りが見つかった文は取り消され、更新後の memory を参照して再生成される。

技術的には、外部情報を生のテキストとしてプロンプトへ継ぎ足すのではなく、Transformer の key-value cache として保持する。これにより、複数の検索文書や検証結果を並列の memory unit として扱える。すべての情報を毎回エンコードし直す必要がないため、反復検索系の方法より柔軟に情報を差し替えられる可能性がある。論文はこの設計を、vanilla RAG や FLARE を含むより一般的な枠組みとして位置づけている。実装上は素朴な FIFO 更新でも効果が出ており、複雑な memory policy を入れる余地も残している。

## 問題設定

対象は、事実を問うプロンプトに対して、数段落程度の長い回答を生成する場面である。人物の略歴、物品や概念の説明、複数の事実を含む質問では、回答中に多数の claim が現れる。大規模言語モデルは流暢な文章を作れるが、名前、日付、場所、数量のような細部で誤りを混ぜることがある。RAG は外部文書を参照させる有効な手段だが、最初の検索だけでは、生成が進むにつれて必要になる細かい情報を十分に補えない場合がある。

既存の反復型 RAG は、低確率トークンや自己批評を手掛かりに検索をやり直す。しかし、その多くは検索したテキストを再び入力文字列として扱うため、文脈長、再エンコード、不要な情報の蓄積といった問題を受ける。さらに、検索だけでは「今出した文が誤っている」という明示的な信号をモデルへ伝えにくい。本論文は、検索と fact-checking から来る異なる種類のフィードバックを、生成中に保持し直せる形で入れることを問題にしている。評価では、factuality だけでなく、正しいが役に立たない回答になっていないかを見るために helpfulness も測る。

## 提案手法

Ewe は、生成中に一定間隔で停止し、直近に生成した文を検査する。検査では VeriScore の claim extraction と verification を用い、文中の検証可能な claim が外部情報で支持されるかを見る。誤った claim がある場合、その反証や正しい情報を fact-checking feedback として取得する。同時に、元の質問と生成中の文を query として Contriever により C4 と Wikipedia から関連 passage を検索する。これらの検索結果と検証結果が、作業記憶の中身になる。

作業記憶は k 個の memory unit からなり、各 unit は一定長の feedback text を Transformer でエンコードした KV cache を保存する。生成時には、通常の文脈だけでなく、各 memory unit と結合した self-attention の結果を集約して次トークン予測に使う。memory の更新は本論文では FIFO を基本とし、新しい feedback が来ると古い unit が置き換わる。もし直近の文が非事実的と判定されれば、その文を削除して前の時点へ戻り、更新後の memory に基づいて再生成する。このため、Ewe は検索、検証、修正を一つの生成過程に組み込む形になる。

## 結果

主実験では、Llama-3.1 70B と 8B を基盤モデルとし、LongFact、Fava、AlpacaFact、Biography の四つの fact-seeking long-form generation dataset で評価した。factuality は VeriScore F1、helpfulness は AlpacaEval の win rate により測った。70B では、Ewe は LongFact 75.9、Fava 61.0、AlpacaFact 66.9、Biography 49.7 の VeriScore F1 を示し、単純な retrieval augmentation、DRAGIN、CoVe、Nest をすべての dataset で上回った。基盤モデル単体から見ると、各 dataset でおおむね 2〜13 ポイントの改善があるが、abstract では強い baseline との差として 2〜6 ポイントの改善が要約されている。

helpfulness では、Ewe の出力は 70B 基盤モデルに対する AlpacaEval win rate がほぼ 50% であり、factuality を上げる代わりに応答品質を大きく落としたとは読めない。8B でも傾向は似ており、Ewe が最も高い factuality を示したが、改善幅は 70B より小さい。著者らは、小さいモデルでは feedback を使って正しい文へ再生成する能力が弱い可能性を指摘している。分析では、memory unit が多すぎると古い情報が残り precision を下げること、短い unit は precision に、長い unit は recall に寄りやすいことが示された。検索 datastore も重要で、LongFact と Biography では C4 と Wikipedia の併用が有効だった。

## 具体例

たとえば利用者が「Bird of Paradise という植物の育て方を、湿度、光、水やりを含めて詳しく説明してほしい」と尋ねたとする。通常のモデルは、もっともらしい園芸文を書きながら、「乾燥した空気を好む」といった誤った claim を混ぜることがある。Ewe では、回答を一文ずつ作り、一定の間隔でその文を fact-checking に回す。検証器が「Strelitzia は熱帯に近い 60〜70% 程度の湿度でよく育つ」という根拠を見つければ、直前の文は支持されないと判定される。すると Ewe はその誤った文を取り消し、この根拠と関連する検索 passage を memory に入れて、同じ箇所を再生成する。

期待される出力は、「乾燥を好む」ではなく、「湿度をある程度保つとよいが、過湿の用土は避ける」といった、根拠に沿った説明になる。間違えやすい点は、検索で得た一般的な観葉植物の説明と、Bird of Paradise 固有の条件を混同することである。Ewe の memory は、最初の検索結果だけでなく、生成中の誤りに対する反証を保持するため、この種の混同を後続の文にも引きずりにくくする。ただし、検証器や検索結果が誤れば、memory に入る情報も誤る。したがって、この手法の効果は外部 fact-checking と検索 datastore の品質に強く依存する。

Improving Factuality with Explicit Working Memory

長文生成における hallucination を、生成中に外部検索と fact-checking の結果を受け取る明示的な作業記憶で抑える研究である。
提案手法 Ewe は、検索文書や検証結果を KV cache として複数の memory unit に保持し、文生成の途中で更新しながら次の出力に反映する。
LongFact、Fava、AlpacaFact、Biography の四つの長文 factuality 評価で、VeriScore F1 をおおむね 2〜6 ポイント改善し、応答の有用性を大きく損なわなかった。

Abstract（日本語訳）

大規模言語モデルは、hallucination と呼ばれる事実と異なる内容を生成することがある。近年の研究は、retrieval-augmented generation を基盤として、反復的なプロンプトにより factuality を改善してきたが、これらの方法は従来型の RAG 設計に制約されている。この課題に対処するため、本論文では Ewe（Explicit Working Memory）を導入する。これは、外部資源からリアルタイムのフィードバックを受け取る作業記憶を統合することで、長文テキスト生成の factuality を高める新しい手法である。この memory は、オンライン fact-checking と検索からのフィードバックに基づいて更新されるため、Ewe は生成過程で誤った主張を修正し、より正確で信頼できる出力を得ることができる。実験では、Ewe が四つの fact-seeking な長文生成データセットにおいて強い baseline を上回り、応答の有用性を犠牲にせずに、factuality 指標である VeriScore を絶対値で 2〜6 ポイント向上させることを示した。さらに分析により、memory 更新規則の設計、memory unit の構成、検索 datastore の品質が、モデル性能に影響する重要な要因であることが分かった。

論文の面白いところ

この論文の中心は、RAG を「入力の前に文書を貼る仕組み」としてではなく、「生成中に更新される作業記憶」として扱う点にある。通常の RAG は、最初に検索した文書をプロンプトへ入れてから一続きの回答を作る。回答が長くなるほど、途中で必要になる情報や、生成済みの文に含まれる誤りを扱いにくくなる。Ewe はそこで、文を生成した後にいったん止まり、その文の claim を検査し、必要なら検索結果や fact-checking の反証情報を memory に入れ直す。誤りが見つかった文は取り消され、更新後の memory を参照して再生成される。

技術的には、外部情報を生のテキストとしてプロンプトへ継ぎ足すのではなく、Transformer の key-value cache として保持する。これにより、複数の検索文書や検証結果を並列の memory unit として扱える。すべての情報を毎回エンコードし直す必要がないため、反復検索系の方法より柔軟に情報を差し替えられる可能性がある。論文はこの設計を、vanilla RAG や FLARE を含むより一般的な枠組みとして位置づけている。実装上は素朴な FIFO 更新でも効果が出ており、複雑な memory policy を入れる余地も残している。

問題設定

対象は、事実を問うプロンプトに対して、数段落程度の長い回答を生成する場面である。人物の略歴、物品や概念の説明、複数の事実を含む質問では、回答中に多数の claim が現れる。大規模言語モデルは流暢な文章を作れるが、名前、日付、場所、数量のような細部で誤りを混ぜることがある。RAG は外部文書を参照させる有効な手段だが、最初の検索だけでは、生成が進むにつれて必要になる細かい情報を十分に補えない場合がある。

既存の反復型 RAG は、低確率トークンや自己批評を手掛かりに検索をやり直す。しかし、その多くは検索したテキストを再び入力文字列として扱うため、文脈長、再エンコード、不要な情報の蓄積といった問題を受ける。さらに、検索だけでは「今出した文が誤っている」という明示的な信号をモデルへ伝えにくい。本論文は、検索と fact-checking から来る異なる種類のフィードバックを、生成中に保持し直せる形で入れることを問題にしている。評価では、factuality だけでなく、正しいが役に立たない回答になっていないかを見るために helpfulness も測る。

提案手法

Ewe は、生成中に一定間隔で停止し、直近に生成した文を検査する。検査では VeriScore の claim extraction と verification を用い、文中の検証可能な claim が外部情報で支持されるかを見る。誤った claim がある場合、その反証や正しい情報を fact-checking feedback として取得する。同時に、元の質問と生成中の文を query として Contriever により C4 と Wikipedia から関連 passage を検索する。これらの検索結果と検証結果が、作業記憶の中身になる。

作業記憶は k 個の memory unit からなり、各 unit は一定長の feedback text を Transformer でエンコードした KV cache を保存する。生成時には、通常の文脈だけでなく、各 memory unit と結合した self-attention の結果を集約して次トークン予測に使う。memory の更新は本論文では FIFO を基本とし、新しい feedback が来ると古い unit が置き換わる。もし直近の文が非事実的と判定されれば、その文を削除して前の時点へ戻り、更新後の memory に基づいて再生成する。このため、Ewe は検索、検証、修正を一つの生成過程に組み込む形になる。

結果

主実験では、Llama-3.1 70B と 8B を基盤モデルとし、LongFact、Fava、AlpacaFact、Biography の四つの fact-seeking long-form generation dataset で評価した。factuality は VeriScore F1、helpfulness は AlpacaEval の win rate により測った。70B では、Ewe は LongFact 75.9、Fava 61.0、AlpacaFact 66.9、Biography 49.7 の VeriScore F1 を示し、単純な retrieval augmentation、DRAGIN、CoVe、Nest をすべての dataset で上回った。基盤モデル単体から見ると、各 dataset でおおむね 2〜13 ポイントの改善があるが、abstract では強い baseline との差として 2〜6 ポイントの改善が要約されている。

helpfulness では、Ewe の出力は 70B 基盤モデルに対する AlpacaEval win rate がほぼ 50% であり、factuality を上げる代わりに応答品質を大きく落としたとは読めない。8B でも傾向は似ており、Ewe が最も高い factuality を示したが、改善幅は 70B より小さい。著者らは、小さいモデルでは feedback を使って正しい文へ再生成する能力が弱い可能性を指摘している。分析では、memory unit が多すぎると古い情報が残り precision を下げること、短い unit は precision に、長い unit は recall に寄りやすいことが示された。検索 datastore も重要で、LongFact と Biography では C4 と Wikipedia の併用が有効だった。

具体例

たとえば利用者が「Bird of Paradise という植物の育て方を、湿度、光、水やりを含めて詳しく説明してほしい」と尋ねたとする。通常のモデルは、もっともらしい園芸文を書きながら、「乾燥した空気を好む」といった誤った claim を混ぜることがある。Ewe では、回答を一文ずつ作り、一定の間隔でその文を fact-checking に回す。検証器が「Strelitzia は熱帯に近い 60〜70% 程度の湿度でよく育つ」という根拠を見つければ、直前の文は支持されないと判定される。すると Ewe はその誤った文を取り消し、この根拠と関連する検索 passage を memory に入れて、同じ箇所を再生成する。

期待される出力は、「乾燥を好む」ではなく、「湿度をある程度保つとよいが、過湿の用土は避ける」といった、根拠に沿った説明になる。間違えやすい点は、検索で得た一般的な観葉植物の説明と、Bird of Paradise 固有の条件を混同することである。Ewe の memory は、最初の検索結果だけでなく、生成中の誤りに対する反証を保持するため、この種の混同を後続の文にも引きずりにくくする。ただし、検証器や検索結果が誤れば、memory に入る情報も誤る。したがって、この手法の効果は外部 fact-checking と検索 datastore の品質に強く依存する。