Architecture & Scaling Deep Dive · arXiv:2610.30755
Raw-RAG 如何管理日漸膨脹的對話與向量索引？
基於 Litmeb/RAW-RAG (rag_adapter.py / rag_pgvector_store.py) 原始碼與本機實測數據：寫入端採用 Append-Only 增量尾部切塊（零表徵損失），讀取端採用 常數預算兩階段漏斗 + 時序重排展開（隔離 LLM Context 膨脹）。
寫入端單步計算複雜度
O(ΔL) · 0 LLM Calls
僅重切與嵌入最後一個未滿 256 tokens 的尾部區塊，歷史區塊完全鎖定不重算。
寫入期資訊流失 (Representation Loss)
0.0% (零有損壓縮)
對比複雜記憶系統在寫入期因 LLM 摘要/萃取直接損失 21.9% 狀態演進證據。
讀取端 Reader LLM 上下文上限
常數 O(k) ≈ 3.8K tokens
無論歷史膨脹至 32K、197K 或百萬 tokens，永遠只取 Top-128 → Rerank Top-15。
百萬級長對話 RAM 保護
pgvector + 暫態釋放
支援外部 PostgreSQL 向量庫與單次檢索後立即釋放 RAM 快取 (gc.collect())。
1 架構對比：為什麼不在寫入端用 LLM 壓縮對話？
主流複雜記憶系統試圖在寫入時用 LLM 萃取「原子事實」或「摘要」來控制膨脹，實測卻造成永久表徵損失與碎片數量反向暴增 5.38 倍；Raw-RAG 則將「儲存增長」與「讀取視窗」徹底解耦。
傳統複雜記憶系統 (Mem0 / MemOS / Atomic Facts)
寫入端有損壓縮
1. 持續膨脹的對話流 (N tokens)
每輪對話進入系統，觸發寫入期記憶管理管線。
↓
2. 寫入期呼叫 LLM 萃取 / 合併 / 覆寫
將原始對話拆解為原子事實或滾動摘要（建庫耗時暴增 655×，約 89.2 秒）。
↓
副作用 A：永久表徵損失 (R − C = −21.9%)
跨回合的狀態演進因果鏈在寫入時被截斷，即使全庫塞進 LLM 也無法救回。
副作用 B：細碎物件反向膨脹 (5.38×)
原本 24 個 256-token 區塊被拆成 129 條細碎事實，檢索噪音反而更大。
Raw-RAG 架構 (Litmeb/RAW-RAG)
讀取端固定預算漏斗
1. 持續膨脹的對話流 (N tokens)
每輪對話進入 RAGAdapter.add_incremental_message。
↓
2. 寫入期：零 LLM 呼叫、增量尾部切塊 O(ΔL)
原文 100% 保留於 256-token 區塊（overlap 32），建庫僅需 0.14 秒。
↓
優勢 A：零表徵損失 + 完整演進路徑保留
所有歷史修改紀錄、時間戳記與雙向對白原封不動保留在索引中。
優勢 B：讀取端常數上限 (Top-128 → Top-15)
透過兩階段檢索漏斗，送入 Reader LLM 的 Context 永遠鎖定在 ~3.8K tokens。
2 寫入端機制：增量尾部切塊與嵌入 (Incremental Tail-Only Update)
當對話逐句增加時，RAGAdapter.add_incremental_message 不會重切或重算整段歷史。前 N-1 個已填滿 256 tokens 的區塊被標記為 stable_chunks（不可變），每次只重算最後一個未滿區塊與新延伸出的 tail_chunks。
對應實作：rag_adapter.py :: RAGAdapter.add_incremental_message (L335-L500)
增量日誌：rag_incremental_updates.jsonl
3 讀取與狀態演進管理：兩階段常數漏斗 + 時序重排 + 動態回合展開
既然資料庫不刪除舊狀態，當使用者反覆變更狀態（例如：台北 → 台南 → 取消改台中）時，Raw-RAG 如何避免舊資料誤導 Reader？關鍵在於「檢索時用 256-token 緊湊區塊，送給 LLM 前依原始時間排序並動態還原為完整對話回合」。
時序過濾：_filter_chunks_for_question_date (L1021-L1065)
時序重排：_selected_chunk_time_sort_key (L750-L766)
動態展開：_expand_chunk_to_turns (L1612-L1650)
4 儲存與記憶體防爆：本機暫態釋放 vs. PostgreSQL pgvector
當單一評估集或對話膨脹至數百萬 tokens 時，若將所有浮點向量常駐於 RAM 或寫入單一 JSON 檔會導致記憶體與磁碟爆滿。Raw-RAG 提供兩條分流路徑：
5 實測邊界：Raw-RAG 在哪些膨脹場景勝出？何處觸及極限？
根據我們在 MEME (32K-Filler) 六大任務的實測分解，固定 Top-15 視窗能完美解決「局部狀態演進」，但在「跨超過 15 個區塊的全局統計聚合 (Aggregation)」會觸及視窗與計數瓶頸：