我最早被“失憶”坑到是在做一個(gè)客服機(jī)器人項(xiàng)目。線上跑了兩個(gè)月前20輪對話一切正常到第35輪左右機(jī)器人突然開始一本正經(jīng)地編造訂單狀態(tài)甚至把A用戶的數(shù)據(jù)安到B用戶頭上。我第一反應(yīng)是模型能力不行差點(diǎn)去換底座大模型。后來把請求日志翻出來對比才發(fā)現(xiàn)問題根本不在推理而在上下文——發(fā)給模型的消息列表里最早的約束已經(jīng)被擠出了窗口模型壓根沒“看見”它。從那天起我開始認(rèn)真研究context-mode也就是上下文管理模式。簡單說就是你決定“把哪些內(nèi)容放進(jìn)模型這一次請求里”的策略。它解決的核心問題不是模型會不會推理而是模型能不能拿到足夠且正確的信息來推理。這篇文章我會把我在實(shí)際項(xiàng)目里落地的幾種context-mode方案、代碼、量化對比和踩過的坑全部寫出來希望能幫正在做Chatbot、AI Agent、RAG應(yīng)用的人少走一點(diǎn)彎路。1. context-mode要解決的是哪個(gè)“失憶”問題1.1 一次讓我尷尬的項(xiàng)目事故先說前面提到的那個(gè)客服機(jī)器人。業(yè)務(wù)方要的是一個(gè)能處理“訂單查詢、退換貨、催開發(fā)票”的助手我們早期實(shí)現(xiàn)非常簡單把聊天歷史全部塞進(jìn)prompt丟給模型讓它回答。demo階段一切美好因?yàn)榇蠹覝y試最多聊十輪八輪。但上線后真實(shí)用戶不會按你的劇本走有人連著聊了五六天同一個(gè)會話里反復(fù)追問不同訂單的狀態(tài)。然后事故就來了。第30輪之后模型開始“忘記”用戶最開始強(qiáng)調(diào)的“我是白金會員所有優(yōu)惠都要按最高折扣算”。更離譜的是有一輪我手動翻日志發(fā)現(xiàn)模型把用戶A的收貨地址當(dāng)成用戶B的來比對。Root cause非常清晰模型一次請求的上下文窗口有限消息列表只能容納最近的十幾輪內(nèi)容早期關(guān)鍵信息被后面的對話給“擠沒”了。這個(gè)事故讓我意識到做AI應(yīng)用和做傳統(tǒng)后端完全不同。你不只是在寫一套接口你是在替模型決定“它應(yīng)該看什么材料”。這個(gè)決策本身就是應(yīng)用的核心邏輯。1.2 上下文窗口的本質(zhì)模型并沒有“記住”很多人對上下文窗口有個(gè)錯(cuò)誤理解覺得模型聊得多了就“記得”前面聊了什么。實(shí)際上大語言模型的上下文窗口更像是一個(gè)臨時(shí)的“閱讀稿”。它只在這一次推理時(shí)把窗口里的內(nèi)容全部讀一遍然后生成回復(fù)生成完了這次讀過的內(nèi)容就丟了。下次推理你又重新把材料遞進(jìn)去。所以所謂“長記憶”根本不是模型的能力項(xiàng)而是應(yīng)用層不斷把歷史內(nèi)容搬回窗口里。窗口總是有限的GPT-4o一類的模型常見上下文是128K token看著很大但真實(shí)業(yè)務(wù)里塞幾個(gè)長文檔、幾十輪歷史、一段工具返回結(jié)果很快就能吃滿。而且窗口越大單次請求的成本和延遲也跟著漲。context-mode的本質(zhì)就是在這個(gè)“有限的閱讀稿”里做取舍決策。它需要回答三個(gè)問題哪些內(nèi)容必須進(jìn)窗口哪些內(nèi)容可以降級處理哪些內(nèi)容可以直接丟棄1.3 context-mode的三個(gè)核心指標(biāo)我在項(xiàng)目里給自己定了三個(gè)可量化的指標(biāo)所有模式優(yōu)化都圍繞它們來評估信息保留率模型回答需要的關(guān)鍵實(shí)體、約束、指令最終是否還留在上下文里。我一般用一組構(gòu)造好的“必須知道”測試題來驗(yàn)證比如把用戶設(shè)置的折扣約束放進(jìn)第40輪歷史看第50輪模型還能不能復(fù)述出來。單輪token成本每發(fā)一次請求實(shí)際消耗的輸入token數(shù)量。這直接決定賬單大小特別是高頻客服場景成本差一倍月結(jié)單就完全不同。響應(yīng)延遲上下文越長prefill階段耗時(shí)越長。正常情況下幾百token和幾千token差距不大但一旦塞入上萬token首字延遲會明顯上升。所有context-mode方案本質(zhì)都是在三者之間找一個(gè)適合業(yè)務(wù)場景的平衡點(diǎn)。沒有最優(yōu)只有最合適。2. 三種主流context-mode的取舍滑動窗口、摘要壓縮、檢索增強(qiáng)2.1 滑動窗口把最近N輪留下滑動窗口是最容易想到的方案也是我當(dāng)時(shí)第一個(gè)實(shí)現(xiàn)的方式。思路很簡單每條消息按時(shí)間排序構(gòu)造請求時(shí)只取最新的若干條直到接近token預(yù)算就截止。它的最大優(yōu)勢是行為可預(yù)期。代碼量小邏輯直白不會出現(xiàn)“模型因?yàn)檎^擬合而胡說”的情況。你放進(jìn)去的就是原文模型讀到的東西沒有經(jīng)過二次加工信息失真風(fēng)險(xiǎn)低。但它有個(gè)非常致命的短板早期關(guān)鍵信息會被無差別丟棄?？头永锏陌捉饡T約束如果是第2輪說的第35輪已經(jīng)不在窗口里了模型根本不知道這個(gè)約束存在。所以滑動窗口只適合那種“最新內(nèi)容最重要”的場景比如閑聊機(jī)器人、短期任務(wù)助手。2.2 摘要壓縮把對話變成“工作筆記”摘要壓縮是我第二個(gè)嘗試的模式。它的動機(jī)很簡單模型真正需要的往往不是對話的逐字原文而是其中蘊(yùn)含的“事實(shí)和意圖”。與其保留每一句話不如定期讓模型把歷史對話整理成一份結(jié)構(gòu)化摘要下次請求時(shí)把摘要加原文一起放進(jìn)窗口。舉個(gè)例子用戶在第3輪說“我周五要去上海出差幫我訂虹橋附近的酒店”后面又聊了一堆茶葉價(jià)格之類無關(guān)話題。第20輪用戶說“幫我看看之前說的酒店”這時(shí)候模型需要的是“周五、上海、虹橋附近”這幾個(gè)信息而不是中間17輪閑聊。我的實(shí)現(xiàn)方式是滾動摘要每隔一段時(shí)間或一定token量把當(dāng)前摘要與新消息一起丟給模型生成更新的摘要。這類似工作里記筆記不斷往里補(bǔ)增量。摘要壓縮的優(yōu)點(diǎn)是信息保留率高能把大量歷史濃縮成幾百字并且保留全局語義。缺點(diǎn)也很明顯摘要本身有損壓縮過程中可能丟掉關(guān)鍵細(xì)節(jié)而且摘要調(diào)用本身也要花token和時(shí)間。2.3 檢索增強(qiáng)讓上下文不再連續(xù)而是“按需取用”檢索增強(qiáng)是我后來最常用的模式也就是把上下文從“連續(xù)的切面”變成“可查詢的知識庫”。核心思路是每條歷史消息都向量化存入向量數(shù)據(jù)庫當(dāng)用戶提出新問題時(shí)先對問題做語義檢索只把相關(guān)的歷史消息片段取出來放進(jìn)上下文。這個(gè)模式和RAG在外觀上很像但目的不同。RAG檢索的是外部知識庫檢索增強(qiáng)檢索的是對話自身的記憶。它解決的是“歷史很長但高度離散”的場景比如一個(gè)用戶零零散散地在不同時(shí)間問過多個(gè)不同訂單的問題每個(gè)問題之間沒有強(qiáng)關(guān)聯(lián)。檢索增強(qiáng)的優(yōu)勢是信息保留率可調(diào)你可以只取top-k相關(guān)片段也可以額外加一個(gè)關(guān)鍵詞過濾條件。它不會像滑動窗口那樣犧牲早期的關(guān)鍵信息也不會像摘要那樣把細(xì)節(jié)抽象掉。缺點(diǎn)是系統(tǒng)復(fù)雜度明顯上升需要維護(hù)向量庫、 embedding、檢索鏈路并且檢索質(zhì)量直接決定回復(fù)質(zhì)量檢索不到模型就真的不知道。2.4 三種模式的量化對比我把自己項(xiàng)目里的實(shí)測數(shù)據(jù)整理成了一張表方便你在方案選型時(shí)直接參考基于128K窗口、中文對話場景模式信息保留能力單輪token成本延遲影響實(shí)現(xiàn)復(fù)雜度典型適用場景滑動窗口低早期信息易丟低低最簡單閑聊、短期任務(wù)、客服的“最近意向”判斷摘要壓縮中高但細(xì)節(jié)有損中額外摘要調(diào)用中中等長會話總結(jié)、需要全局語義、關(guān)鍵約束密集檢索增強(qiáng)高但依賴檢索質(zhì)量低-中中檢索耗時(shí)較高知識密集、問題高度離散、長期多主題對話需要注意這三種模式不是互斥的。我在最終版本里做的是混合模式全局摘要保底 滑動窗口保近期 向量檢索補(bǔ)細(xì)節(jié)后面我會寫具體實(shí)現(xiàn)。3. 我的落地實(shí)現(xiàn)一套可切換的context-mode框架3.1 數(shù)據(jù)結(jié)構(gòu)給每條消息打上“標(biāo)簽”和“權(quán)重”在寫任何模式之前我先把消息數(shù)據(jù)結(jié)構(gòu)重新設(shè)計(jì)了。這一步非常重要后期所有策略都建立在消息的meta信息之上。我的每條消息包括五個(gè)字段dataclass class ChatMessage: role: str # system / user / assistant / tool content: str msg_id: str # 全局唯一 ts: float # 時(shí)間戳用于排序和時(shí)效判斷 category: str chat # chat / constraint / fact / tool_result / greeting retention: int 1 # 保留權(quán)重0可選丟棄1默認(rèn)2重要3絕不可丟category和retention是我自己加的。“constraint”是用戶明確的約束性指令比如“不要推薦含糖飲料”“fact”是事實(shí)型實(shí)體比如訂單號、日期、金額“tool_result”是工具返回的原始結(jié)果“greeting”是寒暄。retention用于告訴上下文構(gòu)造器這條消息的丟棄優(yōu)先級。有了這兩個(gè)字段構(gòu)造上下文時(shí)就靈活多了。系統(tǒng)約束永遠(yuǎn)保留retention3用戶明確指令保留retention2工具結(jié)果和事實(shí)按需保留retention1寒暄直接丟棄retention0。3.2 token預(yù)算的精確計(jì)算構(gòu)建上下文的第一步永遠(yuǎn)是算預(yù)算。我封裝了一個(gè)token計(jì)數(shù)器用tiktoken來估算import tiktoken enc tiktoken.encoding_for_model(gpt-4o) def count_tokens(text: str) - int: if not text: return 0 return len(enc.encode(text))然后定義預(yù)算結(jié)構(gòu)。核心原則是先留出模型回復(fù)的空間再裝system prompt再裝本次新消息最后剩下的空間才分給歷史內(nèi)容。def build_sliding_context( system_prompt: str, history: list, pending: list, max_tokens: int 16000, reserve_output_tokens: int 2000, ): budget max_tokens - reserve_output_tokens system_msg {role: system, content: system_prompt} budget - count_tokens(system_prompt) # 本次必須帶上的新消息 for msg in pending: budget - count_tokens(msg[content]) # 從歷史最末端最新的消息往回收集塞滿剩余預(yù)算 selected [] for msg in reversed(history): cost count_tokens(msg[content]) if budget - cost 0: break selected.append(msg) budget - cost selected.reverse() return [system_msg] selected pending有兩個(gè)細(xì)節(jié)容易被忽略。第一reserve_output_tokens不能設(shè)得太小否則模型生成到一半就被截?cái)唷Ｎ乙话愀鶕?jù)業(yè)務(wù)回答長度估算客服場景設(shè)2000長文生成場景至少4000。第二budget - cost 0才break而不是0這樣能盡量利用最后一點(diǎn)剩余空間避免白白浪費(fèi)。3.3 摘要壓縮的實(shí)現(xiàn)細(xì)節(jié)摘要模式我并沒有簡單地把整段歷史一次性丟給模型總結(jié)那樣很容易超窗口。我采用的是“分批滾動摘要”的方式def incremental_summary(prev_summary: str, new_messages: list, client) - str: content \n.join(f{m[role]}: {m[content]} for m in new_messages) prompt f你正在管理一段長時(shí)間對話的記憶。請合并以下兩部分內(nèi)容輸出一份新的結(jié)構(gòu)化摘要。 要求: 1. 保留所有用戶明確的指令、偏好和約束 2. 保留關(guān)鍵實(shí)體訂單號、日期、金額、人名、地址等 3. 去掉寒暄、重復(fù)表達(dá)和低信息量內(nèi)容 4. 摘要保持在300字以內(nèi)。 【已有摘要】 {prev_summary} 【新對話】 {content} resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content每次調(diào)用前我先統(tǒng)計(jì)新消息的總token量如果超過4000就自動切成多個(gè)小批然后循環(huán)調(diào)用incremental_summary把上一輪的摘要作為下一輪的“已有摘要”傳進(jìn)去。這樣做的好處是無論對話多長摘要調(diào)用的token開銷都是可控的不會出現(xiàn)“為了省token反而燒掉更多token”的尷尬。另外一個(gè)我踩出來的經(jīng)驗(yàn)摘要生成用mini模型就行不必用旗艦?zāi)Ｐ汀Ｒ驗(yàn)檎蝿?wù)本身對推理要求不高關(guān)鍵是提取準(zhǔn)確性。我個(gè)人用gpt-4o-mini實(shí)測信息保留率和旗艦?zāi)Ｐ拖嗖畈淮蟮杀镜土瞬畈欢嘁粋€(gè)數(shù)量級。如果你用的是開源模型做底座摘要生成也可以復(fù)用同一套模型只是速度會慢一些。3.4 自動切換策略什么情況用什么模式做了三種模式之后新的問題來了每次請求到底用哪個(gè)我最后寫了一個(gè)簡單的策略決策器規(guī)則不復(fù)雜但足夠有效def decide_mode(app_state): # 歷史占總窗口預(yù)算的比例 ratio app_state.history_tokens / app_state.max_tokens if ratio 0.4: return full # 歷史遠(yuǎn)沒到預(yù)算直接全量 if app_state.fact_density 0.2: return sliding # 事實(shí)密度低大多是無關(guān)聯(lián)的閑聊 if app_state.query_discrete: return hybrid # 問題之間離散單點(diǎn)查詢居多用檢索 return summary # 默認(rèn)用摘要壓縮這個(gè)決策器依賴兩個(gè)額外信號fact_density我給每條消息打了category標(biāo)簽統(tǒng)計(jì)最近N條消息里“fact”和“constraint”占比占比高說明這段對話信息密集不能隨便丟。query_discrete用戶在連續(xù)多輪里是否在問完全不同的問題。這個(gè)可以通過向量相似度來算如果相鄰問題間的平均相似度低于閾值就認(rèn)為是離散多頭查詢。hybrid模式是我最終推薦的方式系統(tǒng)約束全量保留近期消息用滑動窗口再疊加一層向量檢索補(bǔ)充細(xì)節(jié)。它稍微復(fù)雜一點(diǎn)但在長會話場景里效果最穩(wěn)。4. 實(shí)測中踩過的坑與優(yōu)化建議4.1 上下文污染摘要把工具輸出當(dāng)成了“事實(shí)”第一個(gè)坑出現(xiàn)在摘要模式上線當(dāng)天?？头C(jī)器人在查詢天氣工具時(shí)返回了“明日有暴風(fēng)雨”摘要把它記成了一條事實(shí)。第二天用戶問“明天適合戶外活動嗎”模型根據(jù)摘要里的“暴風(fēng)雨”給出否定建議。問題在于那條工具結(jié)果是2小時(shí)前的天氣早就變了。這種問題我稱為“上下文污染”模型把某個(gè)時(shí)刻的工具輸出當(dāng)成了永久事實(shí)。工具結(jié)果天然有時(shí)效性不能進(jìn)入長期摘要至少必須帶上時(shí)間戳。我的解決方案是給工具結(jié)果單獨(dú)設(shè)置categorytool_result并且默認(rèn)retention1。在做摘要壓縮時(shí)把tool_result排除在“摘要對象”之外只保留“這條工具結(jié)果回答了什么問題”這樣的元信息。比如不記“明日有暴風(fēng)雨”而是記“用戶詢問了明日天氣已返回預(yù)報(bào)結(jié)果”。等到需要精確數(shù)據(jù)時(shí)走檢索增強(qiáng)去拿原始記錄。4.2 摘要的“歧義塌縮”關(guān)鍵實(shí)體被抽象掉了第二個(gè)坑比較隱蔽也最難發(fā)現(xiàn)。在某次長會話里用戶先提到“張總”后來又提到“張經(jīng)理”其實(shí)指的是同一個(gè)人。摘要模型在壓縮時(shí)統(tǒng)一成了“張總”這沒問題。但另一段對話里“張經(jīng)理”是另一個(gè)部門的人摘要也統(tǒng)一成了“張總”。結(jié)果模型在回答“張經(jīng)理負(fù)責(zé)什么業(yè)務(wù)”時(shí)把兩個(gè)部門的信息混在了一起。這就是摘要壓縮的“歧義塌縮”。模型為了把內(nèi)容壓縮進(jìn)有限字?jǐn)?shù)會傾向于做實(shí)體合并而合并產(chǎn)生的歧義水平無法被下游輕易察覺。我的對策是雙重的第一摘要prompt里強(qiáng)制要求“實(shí)體出現(xiàn)時(shí)保留完整稱謂不縮寫不合并若不確定則并列保留”第二在摘要之外單獨(dú)維護(hù)一個(gè)“關(guān)鍵實(shí)體表”用正則和命名實(shí)體識別抽取出訂單號、人名、日期、金額這類數(shù)據(jù)不做壓縮始終原始保留。這個(gè)實(shí)體表非常值得單獨(dú)做。需要精確查詢時(shí)它比摘要可靠得多而且是結(jié)構(gòu)化數(shù)據(jù)可以直接參與規(guī)則判斷不一定要經(jīng)過模型。4.3 token成本失控摘要調(diào)用反而把賬單推高了第三個(gè)坑和錢有關(guān)。我最初設(shè)計(jì)是“每當(dāng)歷史超過閾值就觸發(fā)一次摘要”結(jié)果遇到一個(gè)話癆用戶幾乎每三四輪就觸發(fā)一次摘要調(diào)用而且每輪主請求還是全量發(fā)送。月底一看賬單摘要花費(fèi)占了總成本的35%。這個(gè)教訓(xùn)是摘要不能是“高頻操作”它應(yīng)該是“低頻兜底操作”。我把觸發(fā)閾值從4000token調(diào)高到12000token并且加了冷卻時(shí)間——兩次摘要之間至少間隔30分鐘或20條新消息。另外一個(gè)優(yōu)化是不把摘要結(jié)果立即放進(jìn)下一輪請求而是先讓它存儲在內(nèi)存只有當(dāng)歷史即將撐爆窗口時(shí)才加載。4.4 精心設(shè)計(jì)評估怎么判斷context-mode改好了還是改壞了context-mode做得對不對不能靠感覺。我后來搭了一套專門的評估集這里分享一個(gè)最值得做的“關(guān)鍵信息保持”測試準(zhǔn)備一組20個(gè)“關(guān)鍵約束”分別散布在對話歷史的第1、第10、第30、第50輪。讓測試腳本自動運(yùn)行對話到第60輪然后向模型提問每個(gè)約束對應(yīng)一個(gè)問題。統(tǒng)計(jì)答對率對比不同模式下的得分。我實(shí)測下來單純用滑動窗口時(shí)第30輪之前的約束答對率只有約40%摘要壓縮能到75%左右混合檢索模式可以穩(wěn)定在85%以上。這組數(shù)據(jù)很有說服力也很容易讓業(yè)務(wù)方理解“為什么需要做context-mode”。同時(shí)還要監(jiān)控兩個(gè)反向指標(biāo)回復(fù)的“串線率”把不同主題的信息混在一起的比例和每條消息的平均成本。有時(shí)候一個(gè)方案信息保留率很高但成本高得離譜那就得調(diào)整策略。5. 場景化落地建議不是所有應(yīng)用都需要最強(qiáng)模式5.1 先判斷你的業(yè)務(wù)屬于哪一型我見過很多團(tuán)隊(duì)一上來就上向量檢索結(jié)果項(xiàng)目跑了一個(gè)月發(fā)現(xiàn)瓶頸根本不在上下文而在意圖識別。這里我把常見應(yīng)用分成四類你可以對照著選模式應(yīng)用類型典型特征推薦context-mode客服輔助會話長、問題離散、事實(shí)密集混合模式摘要檢索個(gè)人助理短期任務(wù)多、最新意圖重要滑動窗口輕量摘要文檔問答外部知識為主、對話歷史短滑動窗口即可重點(diǎn)是RAG角色扮演/閑聊全局人設(shè)重要、細(xì)節(jié)容忍度高摘要壓縮這個(gè)表不是絕對標(biāo)準(zhǔn)但能幫你快速定位。最重要的是先量化你的歷史特征再選模式。我每次接到新項(xiàng)目都會先跑一遍真實(shí)對話日志統(tǒng)計(jì)平均會話長度、事實(shí)密度、問題相似度然后才動手設(shè)計(jì)。5.2 給初次落地的人一個(gè)靠譜的推進(jìn)路徑如果你是第一次做context-mode我建議不要直接堆復(fù)雜方案。按下面的順序演進(jìn)第一版只做滑動窗口但把消息加好category和retention標(biāo)簽。這步很快一兩天就能完成。上線后收集真實(shí)日志統(tǒng)計(jì)“最早出現(xiàn)的關(guān)鍵約束在第幾輪被擠出窗口”找到一個(gè)可復(fù)現(xiàn)的失憶案例。加入摘要壓縮配上實(shí)體表。先讓摘要只保留“關(guān)鍵指令和事實(shí)”不要貪全。如果還有離散查詢場景回答不好再上向量檢索。每一步都留出觀察時(shí)間至少跑一周真實(shí)流量用上一節(jié)說的評估集量化效果。不要跳步否則出了問題你根本沒法定位是摘要丟信息還是檢索沒召回。5.3 后續(xù)可以繼續(xù)擴(kuò)展的方向context-mode這套東西寫完并不代表一勞永逸。我接下來計(jì)劃做幾件事第一把摘要和檢索的觸發(fā)條件從規(guī)則改成可學(xué)習(xí)策略?，F(xiàn)在已經(jīng)積累了不少“哪些消息最終幫助正確回答”的日志數(shù)據(jù)后續(xù)可以用這些數(shù)據(jù)訓(xùn)練一個(gè)輕量級模型來決定上下文構(gòu)成而不是靠人工閾值。第二做跨會話記憶?，F(xiàn)在的context-mode只解決單會話內(nèi)部的消息管理但很多用戶會多次回訪下一次會話其實(shí)也應(yīng)該帶上之前會話的關(guān)鍵摘要。這個(gè)方向我已經(jīng)在規(guī)劃本質(zhì)上是把“會話級摘要”升級成“用戶級長期記憶”。第三把上下文預(yù)算做成可觀測的可視化儀表盤讓運(yùn)營人員能實(shí)時(shí)看到每一輪請求里“system占多少、歷史占多少、檢索片段占多少”這樣調(diào)參就有數(shù)據(jù)支撐。如果讓我重新來一次我會在項(xiàng)目第一天就加一個(gè)“輸入輸出token計(jì)數(shù)”的中間件把每條消息的類別和保留權(quán)重在入庫時(shí)打好。context-mode不是一個(gè)開關(guān)而是一套工程習(xí)慣在寫代碼之前先想清楚哪些信息不能丟哪些可以壓縮哪些壓根不用看。你把這個(gè)想明白了后面所有模式實(shí)現(xiàn)都會順很多。