上下文視窗並非記憶：AI智慧體開發者需要理解的關鍵點

在本文中，你將深入瞭解大上下文視窗為何不等同於智慧體記憶，以及檢索、壓縮和摘要等技術如何在智慧體的認知棧中各自扮演獨特角色，共同實現有效的上下文管理。文章透過辦公室隱喻，幫助開發者直觀理解這些概念。

首先，上下文視窗被比喻為辦公桌表面或臨時便籤。AI模型本質上是完全無狀態的，每次API呼叫都從零開始。將大量對話歷史塞入上下文視窗，模型並非真正“記住”，而是快速重讀整個“宇宙”。長期依賴此策略會帶來三大陷阱：模型像懶學生一樣只關注提示的開頭和結尾，忽略中間內容；對話增長導致雪球效應，每次步驟必須重發所有歷史，包括最早期無關的輪次；延遲方面，面對巨大文本牆，模型需要較長時間才能開始生成第一個詞。文章透過程式碼示例展示了雪球效應的具體體現：第47步時，整個44步歷史必須重新傳送，僅為了回答關於第1步的問題。

檢索增強生成（RAG）系統好比辦公室裡的書架，能即時獲取相關資料。但在智慧體迴圈中，向量相似性不一定等於語義真相。例如，使用者先要求將會議改到週五，後因Alice生病取消週四會議，RAG可能同時返回矛盾資訊。更可靠的模式是在生成前解決衝突，例如根據時間戳選擇最新指令。文章給出了一個簡單的程式碼片段：透過比較時間戳選擇最新相關塊，從而避免智慧體錯誤地重複過時指令。

壓縮類似於將檔案壓縮為ZIP，透過演算法減少令牌數，同時保持關鍵資料完整。例如，將15000令牌的JSON有效載荷壓縮到5000，為模型騰出工作空間。實踐中，可以在大型有效載荷到達主提示之前，透過壓縮模型（如LLMLingua）進行預處理。壓縮後的事實原樣保留，僅縮小了“桌面”上的佔用空間。

摘要則不同，它刪除原始資料並替換為抽象，是不可逆的單向過程。良好的實踐是使用分支儲存：將原始記錄存入廉價儲存（如S3），只在活動提示中傳遞合成摘要。文章提供了兩層儲存模式的示例程式碼：第一層持久化原始轉錄，第二層生成摘要並僅將摘要放回上下文視窗。這樣，後續步驟如需細節，可從S3檢索，無需從活動提示中重建。

記憶持久化需要智慧體作為資料庫管理員，而非資料庫本身。例如，使用者說“我的狗叫Goofy，但可能改名為Pluto”，智慧體應顯式觸發工具呼叫更新實體圖。無論底層是SQL表、知識圖譜還是Redis，智慧體應在每輪開始時查詢當前狀態，並在結束時提交更改。文章展示了實現該迴圈的示例函式：先查詢實體圖獲取當前狀態，然後生成響應，最後根據響應中的工具呼叫更新實體圖。

總之，文章的核心教訓是：別再試圖購買一個千萬令牌的巨大“桌子”，而是給智慧體一支鉛筆，教它如何開啟檔案櫃並有效利用其中的內容。