長對話中，AI 還記得你說過什麼嗎？

tags: AI, LLM, RAG, Claude

category: AI

description: 對話長到 120 萬 token 時，AI 還記得你說過什麼嗎？RAG、結構化記憶與百萬 Context 的實測

created_at: 2026/11/07 22:00:00

properties: ai-written

前言

聲明： 這篇文章是透過 AI 協助整理我這幾天的實驗結果所產生的 summary。文中的數字都對照過實驗紀錄，但部分細節仍可能需要勘誤，大方向的結論是對的。網路上也許已經有人用更大規模、更嚴謹的方式比較過這些做法，但那些不在這篇的討論範圍內——這裡只呈現我自己這幾天實驗出來的結果。

最近一直在想一個問題：跟 AI 聊得越久，它要怎麼記得使用者以前說過的事？

直覺上有幾種做法：

1. 每次都把整段對話塞給模型，反正現在都有百萬 context 的模型了，塞就對了 (?
2. 讓 AI 一邊聊一邊做筆記，回答時看筆記(結構化記憶)
3. 回答前先去對話紀錄裡「搜尋」相關的片段，只把找到的那幾段給模型(RAG)

預防針

• 每種設定只跑一次，題目也只有 25 題，差 1~2 題可以當成雜訊。
• 題目是英文的公開資料集，結果不能直接和官方 benchmark 的數字比較。
• 文中的 token 數大多是程式估算的，實際交給 Claude 的量大約是估算值的 1.35 倍(後面會說明)。
• 這篇是記錄與心得，不是懶人包，但最後有一段小結論。

參賽選手

這次比較了下面幾種做法，回答問題的模型都是同一個(Claude Sonnet 5.5)，差別只在「給它看什麼」。

RAG 是 Retrieval-Augmented Generation 的縮寫，意思是「先檢索、再生成」：回答前先去資料裡找相關的片段，再把找到的片段交給模型回答。

後面常出現的 @1,500、@8,000 是預算，也就是挑出來的內容最多能用多少 token(估算)。1,500 大約可以放 17 則使用者訊息。

實驗怎麼做

題目

用的是 LongMemEval(ICLR 2025，MIT 授權)，一個專門測「長期對話記憶」的資料集。每一題都有一大段使用者與 AI 的歷史對話，最後問一個問題，例如：

• 「我之前的職業是什麼？」
• 「我收藏了幾枚 1920 年以前的美國硬幣？」
• 「和第一個客戶簽約時，我的網站上線幾天了？」

答案就藏在歷史對話的某幾句話裡，而且常常只是順帶一提。中間則塞滿了和題目無關的對話(干擾)。

我挑了 25 題，涵蓋資訊更新、時間推理、跨對話、單段事實、偏好，以及 4 題「對話裡根本沒提過」的無答案題。

把對話拉長

同樣 25 題，用四種長度：約 1.5 萬、12 萬、50 萬、120 萬 token(估算)。拉長的方式是加入更多資料集本身提供的干擾對話，題目和答案不變。

120 萬那組，每題有 327~476 段對話、1,641~2,568 則使用者訊息。

怎麼算對錯

回答由固定的評分模型判定(同樣是 Sonnet，另外呼叫一次)，判定的指示沿用 LongMemEval 官方的評分 prompt。每個方法、每個長度都用同一套。

跑多久

全部用 Claude Max 的訂閱方案跑，最後留下的紀錄約 2.2 萬次模型呼叫，兩條線同時跑，前後約 65 小時，中間還碰到好幾次額度上限，只能一直等 5 小時... 幸好有 t3code 幫我自動重試。

結果：一張圖看懂

幾個重點：

1. RAG 原文·融合檢索 @1,500 幾乎不受長度影響：22 → 21 → 21 → 21。對話長了約 80 倍，每題實際送進模型的量卻一直在 2,450~2,470 token 之間。
2. 長 context 在 120 萬時崩了：1M 模型在 50 萬時放得下全文，答對 21 題；到 120 萬放不下，只能放最近約 65 萬，掉到 10 題。
3. 結構化記憶比較早開始下滑：21 → 20 → 17 → 17。

把 120 萬那組的「每題送多少」和「答對幾題」放在一起看，差距更明顯：

融合檢索每題只送約 2,500 token 就答對 21 題；1M 模型每題送約 87 萬，只答對 10 題。送了 350 倍的量，答對不到一半

用一題來看：硬幣到底有幾枚？

光看數字有點抽象，挑一題實際看看各做法給了模型什麼。

題目是 120 萬 token 那組的：

How many pre-1920 American coins do I have in my collection? (我收藏了幾枚 1920 年以前的美國硬幣？)

正確答案是 38 枚，要結合兩句話：

• 5/22：「...I have a total of 37 coins in that collection...」(有 37 枚)
• 5/23：「...I just added a new coin to my collection of pre-1920 American coins - a 1915-S Barber quarter.」(剛加了一枚)

而提問是 6/5，這兩句離提問分別隔了約 86 萬和 68 萬 token 的其他對話，前後還有 2,000 多則無關訊息。

這題剛好把三種做法的特性都展示出來：

• RAG：只要搜得到，給的就是原話，模型可以自己推理。
• 結構化記憶：重點都在，但被濃縮成一句一句之後，少了原本的上下文。
• 長 context：證據在窗口裡就沒問題，不在就完全看不到。

RAG 具體怎麼做？

以「我之前的職業是什麼？」這題(120 萬那組)為例，一步一步看。下面的分數和名次，都是用實驗的程式對這題重算出來的。

用到的東西都在本機跑，不需要呼叫 Claude：

• @huggingface/transformers(Transformers.js)：在 Node.js 裡直接跑 Hugging Face 上的模型。
• Xenova/multilingual-e5-small：把文字轉成向量的模型，支援多語言，輸出 384 維的向量。
• Xenova/bge-reranker-base：重排用的模型。
• SQLite 的 FTS5 全文搜尋：Node.js 內建的 node:sqlite 就能用。

兩個模型都用 q8 量化版，CPU 就跑得動。

步驟 1：準備要搜尋的資料

這題的對話來自 LongMemEval：一位虛構的使用者和 AI 助理在約 10 天內的 461 段對話，總共約 116 萬 token(估算)。聊的內容五花八門，例如：

• I'm planning a party at my place soon and I need some help with decora...
• I actually tested my car's new suspension setup at GingerMan Raceway...
• I'm also wondering if I need to update my social security card...

而答案需要的證據只有一則，就是提到前一份工作的那則訊息(下一步會看到原文)。

把使用者說過的每一則訊息當成一筆資料(同一個人連續說的話先合併成一則)，AI 的回覆不放進來，這題約有 2,300 則。最近的 2 輪對話不參與搜尋，最後會直接附上。

步驟 2：語意檢索，把文字變成向量

向量就是一串數字，意思相近的句子，轉出來的數字也會相近。e5 這個模型規定，問題前面要加 query:，資料前面要加 passage:：

import { pipeline } from '@huggingface/transformers';

const extract = await pipeline('feature-extraction', 'Xenova/multilingual-e5-small', { dtype: 'q8' });
const output = await extract(
  ['query: What was my previous occupation?', 'passage: I worked as a marketing specialist at a startup before.'],
  { pooling: 'mean', normalize: true },
);
const [question, passage] = output.tolist();
// 向量已經正規化，內積就是餘弦相似度(cosine similarity)，越接近 1 越像
const similarity = question.reduce((sum, x, i) => sum + x * passage[i], 0);

實際算幾句話和這題的原始問題 What was my previous occupation? 的相似度。第二句是資料裡真正的證據；第一句和第三句是我為了對照自己寫的句子，不在資料裡：

這裡有兩件事值得注意：

1. 完全無關的句子也有 0.747，分數擠在很窄的範圍裡，所以要看排名，不要看絕對值。
2. 真正的證據因為整則訊息的主旨在講 Trello，分數反而比較低。

語意檢索就是把 2,300 則都算一次，由高到低排，再依序放進預算。這題的證據排在第 1,040 名(第 1 名是 0.848)，1,500 的預算只放得下前 17 則左右，當然就沒看到了。

步驟 3：關鍵字檢索(BM25)

把問題拆成詞：what、was、my、previous、occupation(中文沒有空格，就用相鄰的兩個字，例如「之前」「職業」)，用 FTS5 找出含有任一個詞的訊息，再用 BM25 打分數。BM25 簡單說就是：命中的詞越少見，分數越高，像 my、was 這種到處都有的詞幾乎不加分。

import { DatabaseSync } from 'node:sqlite';

const db = new DatabaseSync(':memory:');
db.exec('CREATE VIRTUAL TABLE docs USING fts5(id UNINDEXED, body)');
// ... 把每則訊息 INSERT 進去
const rows = db.prepare('SELECT id, bm25(docs) AS score FROM docs WHERE docs MATCH ? ORDER BY score')
  .all('"what" OR "was" OR "my" OR "previous" OR "occupation"'); // FTS5 的 bm25() 越小越相關

這題有 1,146 則至少命中一個詞，證據靠著 previous 排到第 6 名。不過第 1 名是一則在講賽車場測試懸吊的訊息，關鍵字也會撈到不相干的內容，所以不能只靠它。

步驟 4：RRF 合併兩份排名

RRF(Reciprocal Rank Fusion)不管原本的分數，只看名次：每份排名給 1 / (60 + 名次)，加起來就是新的分數。

證據的分數是 1/(60+6) + 1/(60+1040) ≈ 0.0152 + 0.0009 = 0.0161，合併後排第 22 名。只要在其中一份排名夠前面，就能被拉上來。取前 60 名進入下一步。

步驟 5：重排(Rerank)

把「問題＋訊息」成對交給 bge-reranker-base。它和步驟 2 不一樣，不是各自轉成向量再比較，而是同時讀兩段文字再給一個相關分數，所以讀得出「這半句話在回答這個問題」。這個模型的分數常常是負的，一樣只看相對大小。

60 則重新排序之後，證據變成第 3 名(-6.53)。它也不完美，第 1 名是一則和問題無關的短句 what was the resistance met?，但只要證據排得夠前面，放得進預算就夠了。

步驟 6：放進 context

依排名把訊息一則一則放進去，直到 1,500 token 用完(放不下的那則就跳過，試下一則)。每則都附上日期和序號，讓模型自己判斷先後，例如硬幣題放進去的第一則是：

- 先前的訊息（05/22 週一 22:45，第 626 則）：By the way, I was thinking of organizing my pre-1920 American coins ...

最後再附上最近 2 輪對話和使用者的問題，交給 Sonnet 回答。

整理一下：語意檢索只做步驟 1、2、6；融合檢索做完整的 1~6 步。

為什麼融合檢索比語意檢索穩？

同樣是 RAG，只用「語意」搜尋的版本在 120 萬時就掉了不少，連預算加到 8,000 都從 50 萬的 22 題掉到 18 題。原因可以從證據被排在第幾名看出來(需要兩句證據的題目，取排得比較後面的那句)：

預算 8,000 大約只放得下前 100 則。對話從 50 萬變成 120 萬，干擾變多，證據就被擠到 100 名之後，自然就放不進去了。

原因就是上一節看到的：證據常常只是長訊息裡順帶一提的半句話，語意檢索看的是整則訊息的主旨，加上分數擠在很窄的範圍裡，干擾一多就被擠到後面。融合檢索多了關鍵字比對和重排兩道把關，同一題排到第 3 名，所以 1,500 的預算就夠了。(預算加到 8,000 反而沒有比較好，多放進去的大多是相關度較低的內容。)

那做筆記(結構化記憶)沒用嗎？

先釐清一件事：「記憶＋原文」其實也是 RAG，只是搜尋的資料除了原話，還多了模型抽出來的筆記。所以它答得好，本身就是 RAG 的功勞；真正要問的是：多做一份筆記，值不值得？

筆記的價值比較像索引。同一題「我之前的職業」，抽出來的筆記是：

In my previous role I was a marketing specialist at a small startup, ...

這句話整句就在講職業，和問題的相似度是 0.885，直接排第 1 名。所以「記憶＋原文·語意 @8,000」在 120 萬時也答對 21 題，和融合檢索打平。

不過把 120 萬的幾組放在一起看，筆記的幫助其實很有限：

• 搜尋方式已經夠好(融合)的時候，加了筆記也沒有比較好(21 vs 20)。
• 只有搜尋方式比較弱(語意)、而且預算給到 8,000 時，筆記才把差距補回來；預算只有 1,500 時是 17 題。

換句話說，「記憶＋原文」的好成績，是用抽筆記的成本，去彌補比較弱的搜尋。同樣 21 題，融合檢索不用抽筆記，每題送的量也只有它的五分之一左右(約 2,500 對 11,000 token)。

而抽筆記的代價不小：

• 要先請模型把對話一批一批抽成筆記，四個長度加起來 19,717 次呼叫，光 120 萬那組就 12,071 次。
• 「記憶＋原文」和「只有原文」逐題比較 16 次(4 種設定 × 4 個長度)，沒有一次有顯著差異。
• 單用筆記(結構化記憶)會遇到硬幣題那種狀況：重點都在，但事實之間的關係不見了。

以這個資料集來說，用比較好的搜尋方式，不做筆記也能得到差不多的結果。

百萬 Context 呢？

1M 模型的結果可以分成兩種情況：

放得下的時候，1M 模型和 RAG 一樣準，只是每題要送約 270 倍的量。放不下的時候，被切掉的那段就完全看不到了。

再換個角度，把每題分成「答題需要的證據有全部放進去」和「沒有全部放進去」：

(不含 4 題無答案題。)

證據放進去了，各做法都能答對大部分；證據沒放進去，幾乎都答不出來。所以重點從來不是 context 有多大，而是答案需要的那幾句話有沒有被放進去。

塞得越多，會不會越容易失焦？

常聽到一種說法：context 上限雖然很大，但塞得越多，模型越容易被不相關的內容帶偏。這次的資料也看得到類似的趨勢。下面三組都是把整段對話全部放進去，答案需要的證據一定都在裡面，差別只在塞了多少：

左欄的對話長度是程式的估算值，右欄是 Claude 實際計算的值，所以送進去的看起來比對話還長。兩者差了約 1.35 倍：估算規則把英文算成 4 個字元 1 個 token，Claude 實際上大約 3 個字元就算 1 個；每次請求另外還有幾百 token 的固定開銷。

同一題逐題比，1.5 萬答對、50 萬答錯的有 3 題，反過來是 0 題。50 萬答錯的那幾題，模型不是找不到資料，比較像是在大量相似的內容裡挑錯了。例如問「我幾天前說過為朋友煮了什麼？」(答案是巧克力蛋糕)，它列了好幾道料理和甜點，就是沒提到巧克力蛋糕。

不過這只能算「方向一致」，還不能說證明了：

• 三組不是同一輪跑的(1.5 萬和 12 萬沿用先前的結果)。
• 干擾對話來自資料集的不同版本。
• 3 : 0 在統計上還不顯著。

要證明，需要固定題目和證據，只改變塞進去的干擾量，再做一次控制實驗。

那 Compact 救得回來嗎？

用過 Claude Code 之類工具的人應該對 compact 不陌生：對話太長時，把前面的內容壓縮成一段摘要，再接著聊。

剛好我跟 AI 一起跑這次實驗的對話本身就被 compact 了 6 次，翻了一下紀錄：

• 壓縮前從約 10 萬到 93 萬 token 都有。
• 壓縮後都只剩約 3.4 萬~4.7 萬 token，其中摘要本身大約 1 萬~1.6 萬字元，其餘主要是系統提示、工具定義這些每次都會帶著的內容。

也就是說，93 萬 token 的對話被濃縮成了幾千 token 的摘要。

所以我又補跑了一個小實驗：1M 模型照樣放最近約 65 萬，另外把放不下的那一段(每題約 55~84 萬 token)交給模型壓縮成摘要，一起放進去。摘要的指示要求保留使用者的事實：數字、日期、人物、更正前後的值。

挑了 8 題：6 題是原本「證據在窗口外所以答錯」的，2 題是證據在窗口內的對照題。

老實說，結果比我預期好，我原本猜頂多救回 1~2 題。

救回來的 4 題，答案都是一個明確的事實，例如摘要裡寫著「Previously a marketing specialist at a small startup」。

沒救回來的 2 題則很有代表性：

• 硬幣題：摘要寫成「37 pre-1920 US coins; ... added 1915-S Barber quarter」，兩件事被放在同一行、同一個日期底下，看不出「新增」是發生在「37 枚」之後，模型還是只答 37 枚。
• 看過幾位醫生：原文是家庭醫師已經開了抗生素(看過了)，摘要卻寫成「plans follow-ups with ... a primary care physician」(打算回診)，模型就沒有把家庭醫師算進去。

這兩題錯的方式和結構化記憶一樣：濃縮成短句的時候，事實之間的關係和狀態最容易走樣。

另外，這 8 題總共用了約 1,280 萬 token、跑了 24 分鐘：每次壓縮都要讀 55~84 萬 token、花約 2~3 分鐘，回答時每題也還是要送約 87 萬 token。

這個小實驗只有 8 題、各跑一次，只能說明「compact 確實救得回一部分」，不能精確估計比例。

換個模型呢？

這次的長度實驗，回答、抽筆記、評分都用 Sonnet，沒有換模型比較。比較接近的只有更早的一個先導實驗：題目是 12 題中文自製題目(6 段短對話，每段 2 題)，回答一樣用 Sonnet，只把抽筆記和寫摘要的模型換成比較小的 Haiku。

216 個回答裡只有 10 個判定不同，整體差不多。比較明顯的差異是：

• Haiku 寫的摘要漏了一個看牙的日期，摘要組在三種預算下都因此答錯同一題。
• Haiku 的輸出約是 Sonnet 的 3 倍長，單次反而比較慢。

所以小模型拿來做「整理」不一定差很多，但細節還是可能漏。至於換掉回答的模型會差多少，這次沒有測，之後有機會再補。

中間踩到的坑

簡單記錄幾個，不然好像都很順：

1. 被安全機制擋下來：有兩題的干擾對話裡，剛好有一段資安課程的 Windows 練習(建立管理員帳號、找 flag)，抽取筆記時每次都被模型的安全機制擋掉。內容本身沒有惡意，最後是把這段干擾對話換掉，兩題的所有做法重跑。
2. 模型會「自我更正」：要求只輸出 JSON，模型偶爾先輸出一份，再補一句「Wait — ... Corrected output:」又輸出一份，整段就解析失敗了。後來改成解析失敗時，取最後一份合法的 JSON。
3. 估算的 token 比實際少：程式估算和 Claude 實際計算差了約 1.35 倍。如果照估算值把 1M 模型塞到 100 萬，實際會超過上限，所以長 context 組的預算有先換算過(估算 65 萬，實際約 87 萬)。

結論

回到一開始的問題：對話很長的時候，AI 要怎麼記得使用者說過的話？以這次的實驗來說：

1. 先做好檢索，比加大 context 重要。融合檢索只送約 2,500 token，從 1.5 萬到 120 萬都維持在 21~22 題。
2. 只用語意搜尋，在長對話會漏掉「順帶一提」的資訊。加大預算只能延後問題。
3. 結構化記憶比較適合當索引或補充，不適合取代原文。濃縮的時候容易遺失事實之間的關係。
4. 長 context 只在對話確定放得下時才好用。放不下時，只放最近的部分效果最差；加上 compact 摘要可以救回一部分，但成本還是比檢索高兩個數量級。

當然，這只是 25 題英文題目、各跑一次的結果。之後想再補幾件事：重跑幾次看結果穩不穩、把訊息切成句子再搜尋、加入中文的題目。有新的結果再來分享。

後記

和上一篇文章一樣，這篇文章也是透過 AI 協助整理實驗結果而成，文中數字都對照過實驗紀錄，但部分細節仍可能需要勘誤。

嘗試請 AI 參考我的文章風格產生文章後，真的回不去，不過畢竟實驗細節是他做的，他是擁有實驗細節的領域專家(?)，所以由他產生後，我來審核、整理和補充(如果我有能力的話)，才能確保內容的正確性和完整性。

總之我覺得這次嘗試下來，RAG 應該是未來處理長對話、長文本的主要方向，尤其是在 context 無法完全容納所有訊息的情況下，也不應該完全依賴模型的長 context，而是要結合檢索和結構化記憶等輔助方式。

應該盡可能讓 context 保持乾淨，只放最相關的訊息，其他的透過檢索或結構化記憶補充。

就好比剛開始使用 AI Agent 協作時，我還保有一點軟體工程師的矜持(?)，我會給予他比較具體的目標(不是步驟)，以及他所需要知道的背景和限制，讓他能在這些框架下自主完成任務。

比起讓他到處亂搜，不只可以省點成本，也能提高效率，讓他專注在最重要的任務上。

雖然在純開發上，RAG 似乎比較沒有硬需求，但如果在做公司內的知識傳承或長期專案的資料管理，RAG 就會變得相當有用。透過檢索和結構化記憶，可以讓新進同事快速掌握過去的討論和決策，避免重複問同樣的問題，也能保留關鍵的上下文資訊。

而這時如何讓 RAG 能夠 精準地檢索到相關資訊，就成為關鍵。

也許未來會有機會研究相關的設計。

所以我到底什麼時候可以上岸.... 尋找研發替代役中