【2026 最新】Lossless Memory 教學：用時間軸＋原文回放設計 12 題 A/B Test

你叫 AI 記住「預算是 300」，隔天又更正成「其實是 350」。一週後再問，它卻很有自信地答 300——問題可能不在模型，而在記憶層把更正前後壓成了一句模糊摘要。這篇 Lossless Memory 教學不急著把「摘要會失真」或「原文一定太貴」當成結論，而是把兩個說法變成可以重跑的實驗。

截至 2026 年 9 月 22 日，Lossless Memory 的 Show HN 討論記錄了 55 points、20 comments；留言中有人追問 prompt cache 成本、日期到底有沒有幫助，以及原文不摘要時該怎麼淘汰。本文專為第一次做 AI 記憶評測的人寫：不假裝已經跑完一場不存在的 benchmark，而是帶你建出公平的兩組記憶、準備 12 題壓力測試，最後把答案、證據、token、延遲、磁碟與刪除成本一起記帳。

先說結論：Lossless 不是結論，而是一個待驗證的設計

一句話記住：可稽核記憶＝原文底片＋時間目錄＋按需回放。

Lossless Memory 的核心不是把全部舊對話重新塞進每一次 prompt，而是把原文保留在本機，以時間先縮小候選範圍，再把少量命中片段逐行回放。摘要組則把歷史壓成固定預算的記憶卡。真正公平的問題不是「哪一派比較潮」，而是：在同一批資料、同一組題目、同一回答模型與同一 context 預算下，哪一組能用較合理的總成本，交出較正確、可追溯、可刪除、可復原的答案？

Lossless Memory 是什麼？先分清楚「保存」與「送進模型」

Lossless Memory 官方 repository是一個本機、單使用者的長期記憶層：原始對話轉成每日 JSONL，精確搜尋用 SQLite FTS5，語意搜尋可選擇 sqlite-vec 與 sentence-transformers，再用單一 recall 入口查詢。官方把 raw log 定義為真相來源；索引是衍生資料，可以由原文重建。

這裡最容易誤會的一點是：保留 100 萬行原文，不等於每次推論都傳 100 萬行。它比較像圖書館。書都留在書庫，但你先用日期與目錄找到一小排書，再翻出相關頁面；LLM 最後只看到那幾頁。相反地，summary memory 像隨身攜帶一本濃縮筆記：便宜、快，但筆記沒寫到的細節無法憑空還原。

Lossless Memory 教學：摘要與原文各自會在哪裡失手

摘要不是壞東西。當你只想知道「這個專案大方向在做什麼」，一段短摘要通常比搜尋幾十次省事。但它有一個不可逆特性：只要「後來更正」「當時版本」「原句條件」在壓縮時被捨棄，回答模型就看不到它。這也是為什麼 AI 記憶稽核會把反事實與虛構側寫分開測，而不是只問「它看起來記得嗎？」

原文路徑則把問題移到別處：時間解析錯了、關鍵詞沒命中、索引過期、回放太多、刪除規則不完整，都可能讓「原文還在」卻「答案拿不到」。這類設計也不是自動比向量記憶更強；它只是讓失敗比較容易追到某一行、某一個時間窗或某一版索引。想先理解其他記憶形態，可搭配 Obsidian＋QMD 記憶工作流與 Datalog 記憶教學看不同取捨。

Lossless Memory 教學：先跑通最小 exact-search 路徑

為了讓你和本文使用同一版程式，以下固定到 2026 年 9 月 5 日的 commit cd34d5b0ea2fa259233f5145d5994c50fe843e96。官方 pyproject要求 Python 3.11 以上；先在專案自己的虛擬環境執行：

git clone https://github.com/aru-labs/lossless-memory.git
cd lossless-memory
git checkout cd34d5b0ea2fa259233f5145d5994c50fe843e96
python3.11 -m venv .venv
. .venv/bin/activate
pip install -e .
cp config.example.json config.json

把 config.json 的 raw_log_dir 指向 ./examples、data_dir 指向 ./logs、ingest_format 設為 plain，再跑：

python -m lossless_memory.ingest --format=plain
python -m lossless_memory.index_exact
python -m lossless_memory.recall "2026-09-02 budget"

這組指令來自官方 Quickstart。AlphaLab 另以 repository source path 做過最小 smoke check：範例匯入 20 筆、跨 3 個日期；日期加 budget 的 exact query 回傳 3 行時間排序原文，也保留 300 改成 350 的兩次敘述。這只確認 ingest → exact index → recall 路徑能走完，不是 summary vs raw 的完整 A/B 結果。

先不要急著建 semantic index。官方 Quickstart 把它列為選配，而且首次會下載 sentence-transformers 模型；12 題基準先從可重現的 exact path 開始，能少一個變因。等 baseline 固定後，再增加向量 fallback，並把它當成新的實驗版本。

怎麼建立公平的 Summary vs Raw temporal A/B Test

先複製一份完全相同的合成對話資料，分成 A、B 兩組。不要拿你的私人聊天當第一批 fixture；合成資料比較容易知道唯一正解，也能放心破壞索引。

1. A 組：Summary memory。固定 summarizer 的模型版本、system prompt、temperature、摘要頻率、最大字數與 prompt SHA。每日只產生一份摘要，回答模型只能讀摘要。
2. B 組：Raw temporal memory。保存同一批逐行原文與時間戳，先限定日期範圍，再由 exact index 回放片段。回答模型不能讀 A 組摘要。
3. 兩組共同鎖定。同一回答模型、system prompt、context 上限、題目順序、重試次數、temperature 與 seed（供應商有提供才記）。
4. 答案格式鎖定。每題輸出 answer、evidence、source_ts、confidence；找不到就明確輸出 unknown。

先做一份會「打架」的對話 fixture

測試資料若每句都一致，兩組幾乎都能過。你要刻意放入跨日更正、短暫例外、撤回、相似名稱與不存在的資訊。例如用 6 天對話埋入以下事實：

• 9 月 1 日：「印刷預算 300」；9 月 2 日：「更正為 350」。
• 9 月 2 日：「封面不要亮面」；9 月 4 日再次確認同一句。
• 9 月 3 日：「會議預設遠端」；9 月 4 日：「客戶 demo 例外，改實體」；9 月 5 日：「demo 取消，回到遠端」。
• 9 月 4 日先選紙張 A，同日晚間撤回，改選紙張 B。
• 資料裡從未出現發票編號，專門測模型是否會捏造。
• 再加入 30 行無關餐廳與天氣對話，測相關內容會不會被雜訊淹沒。

每一筆 JSONL 至少固定 ts、role、text。日期一律寫 ISO 8601；目前 repository 的相對時間解析以日文為主，而絕對日期可跨語言使用，這項範圍由官方限制說明明列。

Lossless Memory 教學：12 題分成召回、時間、維運三層

題型不是隨便想的。LongMemEval把長期記憶拆成資訊擷取、多 session 推理、知識更新、時間推理與拒答；MemoryAgentBench另外強調長距理解與 selective forgetting。把這些能力縮成個人也能重跑的 12 題：

第一組：召回與證據（第 1～4 題）

1. 精確數字：最終印刷預算是多少？Gold answer 是 350，證據必須含更正行。
2. 原句條件：封面材質的原句是什麼？答案要保留「不要亮面」，不能只寫「偏好霧面」。
3. 跨日期組合：最終預算與最終紙張各是什麼？必須同時拿到 9 月 2 日與 9 月 4 日晚間證據。
4. 拒答：發票編號是多少？Gold answer 是 unknown，任何具體號碼都算錯。

第二組：更新與時間（第 5～8 題）

5. 最新版：現在會議模式是什麼？Gold answer 是遠端。
6. As-of-time：如果站在 9 月 4 日下午，當時 demo 怎麼開？Gold answer 是實體。
7. 順序：紙張 A 與紙張 B 哪一個先被選、哪一個是最後決定？答案要說出 A → 撤回 → B。
8. 例外失效：客戶 demo 的實體例外還有效嗎？必須用 9 月 5 日取消行否定它。

第三組：維運與治理（第 9～12 題）

9. 定點刪除：在實驗副本刪掉「封面不要亮面」的原始行後，重建所有衍生資料，查詢不得再回傳原句或可逆片段。
10. 完整重建：把索引移到備份檔名後重跑建索引，12 題答案與證據 ID 應和重建前一致。
11. 壞索引復原：在實驗副本製造無法讀取的 exact index，確認監控能報錯，而不是靜默回答舊資料；重建後再過題庫。
12. 雜訊抗性：加入 30 行無關對話後重跑，相關證據不得被同主題但錯日期的片段取代。

不要只算答對率：一張完整成本帳要記什麼

12 題全對，仍不代表系統能上線。每一題至少記下七組資料：

• 答案正確：correct / 12，多欄答案要全部符合才算一題。
• 證據忠實：引用是否逐字存在、timestamp 是否吻合、是否拿錯版本。
• 更新錯誤：另外統計 stale answer，也就是把舊決定當現況。
• Token：記錄 input、output 與供應商實際回報的 cached input；不要從「檔案沒變」推論 cache hit。
• 延遲：每題至少重複跑相同次數，分別報 median 與 p95，並標記冷啟動。
• 儲存與建索引：用 du -sh logs 記磁碟，以 /usr/bin/time 記 ingest、index 與 rebuild。
• 人工修復：從發現錯誤到恢復 12 題全過，實際花了多少分鐘。

Prompt cache 特別容易算錯。raw log 在磁碟上的大小，不等於送給 API 的 input；索引命中，也不等於供應商快取命中。正確做法是保存每次最終 request 的 prompt hash、實際 input tokens、供應商 usage 欄位與回放片段數，再比較兩組。若 API 沒回報 cached tokens，就把欄位留空，不要補猜測值。

刪除與復原是 hard gate，不是加分題

Lossless Memory 的官方規格明確把 raw record 設計成不編輯、不刪除、不摘要。這是它追求完整回放的設計選擇，卻也表示：如果你的產品必須接受使用者定點刪除，不能把原專案直接視為已完成刪除治理。你需要在自己的儲存層定義刪除、備份、衍生索引、embedding 與 cache 的清理範圍，再用第 9 題驗收。

復原測試只在拋棄式副本做。先把 exact index 移開，再重建：

mv logs/index_exact.db logs/index_exact.db.broken-test
python -m lossless_memory.index_exact
python -m lossless_memory.recall "2026-09-02 budget"

官方 README 說索引可由 raw logs 重建；你的驗收標準還要更嚴格：重建前後答案、證據 timestamp 與題庫分數一致，而且舊索引失效時不能偷偷回傳 stale result。想把這種測法擴大成完整評測流程，可接著看 AI Evals 新手教學。

怎麼判讀結果？不要只選一個漂亮總分

選 Summary 路徑，如果：你的任務主要是主題延續與大意回顧，細節錯一個字不會改變行動，而且摘要的版本、prompt 與重建流程都能被追蹤。

選 Raw temporal 路徑，如果：你常問「當時怎麼說」「在某日以前知道什麼」「哪個決定後來被撤回」，而且願意支付本機儲存、索引與治理成本。

多數實務系統可以做 Hybrid：raw log 當底片，summary 當地圖。回答先用短摘要找方向，遇到數字、日期、姓名、規則或高風險行動，再回到原文核對。這和 OpenViking × Hermes 記憶 A/B強調的受控比較相通：不是先挑信仰，而是先定義哪一種錯誤最不能接受。

6 個最常讓 A/B 失真的坑

1. 摘要組一直改 prompt。每次改寫都等於換系統；請把 prompt 與模型版本寫入 run manifest。
2. Raw 組偷用更大的 context。兩組 context 預算不一樣，token 與正確率都不能直接比。
3. 用中文相對日期測目前 parser。此版明列日文 relative-time 支援；跨語言基準先統一 ISO 日期。
4. 只問最後答案，不留證據。答對也可能是猜中；沒有 timestamp 與原文行就無法稽核。
5. 讓回答模型看見 gold answer。題庫、判分檔與 production prompt 必須分開。
6. 把單次 latency 當結果。冷啟動、embedding 載入與 cache 會扭曲一次測量；固定重複次數並保留原始 trace。

FAQ：Lossless Memory 的 8 個直球問題

1. 「Lossless」代表一定不會忘嗎？

不代表。名稱描述的是保存原文的設計，不是端到端保證。時間解析、檢索、索引、context 截斷與回答模型都可能失敗；官方 README 也明列目前沒有公開 benchmark。

2. 原文記憶一定比較花 token 嗎？

不一定。若每次重播全部歷史，成本當然高；若只回放時間窗內少量片段，輸入可能很小。以實際 request usage 判斷，不要用磁碟大小代替 token。

3. 那摘要是不是都不該用？

不是。摘要很適合導航、主題延續與低風險回顧；問題是把它當唯一、不可追溯的真相來源。

4. 一定需要向量資料庫嗎？

不用。官方 Quickstart 的 exact recall 只靠 SQLite FTS5；semantic index 是可選 fallback。你可以先證明 exact baseline，再逐步加功能。

5. 可以直接拿真實私人對話測嗎？

第一輪不建議。合成 fixture 有唯一正解，能安全做刪除與壞索引測試，也不會把敏感資訊送進評測工具。

6. 專案現在適合多人或雲端服務嗎？

不能從目前範圍直接推到那裡。官方把現有實作限定為單使用者、單機器，並把 multi-device 列為待解問題；多人權限、租戶隔離與同步衝突需要另外設計。

7. 有第三方證據支持 raw retrieval 嗎？

有值得追蹤的早期研究，但不能替這個專案背書。2026 年 8 月的 ReFind 預印本研究 agent-controlled lexical search 與 raw-log retrieval；它支持「值得測」這個方向，並不等於 Lossless Memory 已在你的資料、模型與成本條件下勝出。

8. 新手最小可行版本是什麼？

先跑 exact-only 的 4 題。精確數字、最新更正、as-of-time、拒答各一題；確認證據格式與 manifest 都能重跑，再擴成 12 題與 semantic fallback。

給新手的 7 點驗收清單

• 固定 repository commit、Python 版本與依賴。
• 同一份合成資料複製成 A、B 兩組。
• 只更換記憶層，回答模型與 context 預算不變。
• 12 題各有 gold answer、證據 timestamp 與拒答規則。
• 保存每次 prompt hash、usage、latency 與檢索 trace。
• 刪除、重建、壞索引復原任何一題失敗，都不要只看總分放行。
• 結果寫成版本化 run manifest；更換 summarizer、模型或索引後全套重跑。

如果你還沒建立 Agent 的執行層，可先讀 AI Agent Harness 是什麼；想把這套 protocol 變成自動回歸測試，再接 AI Agent Harness 實作教學。需要一套從工具、Agent 到工作流的完整練習路徑，也可以查看 AlphaLab AI 課程。