1. 從“上下文模式”說(shuō)起一個(gè)被低估的工程概念“context-mode”這個(gè)詞乍一看像是某個(gè)框架里的配置項(xiàng)或者某個(gè)編輯器插件的開(kāi)關(guān)。但如果你在軟件工程、AI應(yīng)用開(kāi)發(fā)或者系統(tǒng)架構(gòu)領(lǐng)域待過(guò)一段時(shí)間就會(huì)發(fā)現(xiàn)它其實(shí)指向一個(gè)非常核心的問(wèn)題系統(tǒng)或組件在不同運(yùn)行階段應(yīng)該以什么樣的方式去理解和處理“上下文”。我第一次認(rèn)真對(duì)待這個(gè)概念是在做一個(gè)多輪對(duì)話系統(tǒng)的時(shí)候。當(dāng)時(shí)用戶反饋說(shuō)機(jī)器人“記性時(shí)好時(shí)壞”——有時(shí)候能準(zhǔn)確引用三輪之前的細(xì)節(jié)有時(shí)候連上一句說(shuō)了什么都忘了。排查了半天發(fā)現(xiàn)問(wèn)題不在模型本身而在于我們沒(méi)有明確區(qū)分“上下文模式”什么時(shí)候該用完整歷史什么時(shí)候該用摘要什么時(shí)候該只保留最近幾條。從那以后我開(kāi)始把context-mode當(dāng)作一個(gè)獨(dú)立的設(shè)計(jì)維度來(lái)看待。這篇文章想聊的就是圍繞context-mode展開(kāi)的一套完整實(shí)踐思路。它適合誰(shuí)看如果你正在做對(duì)話系統(tǒng)、智能助手、代碼補(bǔ)全工具或者任何需要“記住前面發(fā)生了什么”的軟件那這里的內(nèi)容應(yīng)該對(duì)你有用。如果你只是好奇“上下文模式”到底是什么意思我也會(huì)用最直白的方式把它講清楚。整篇內(nèi)容會(huì)從設(shè)計(jì)思路、核心細(xì)節(jié)、實(shí)操過(guò)程到問(wèn)題排查一步步展開(kāi)盡量讓你看完就能動(dòng)手改自己的項(xiàng)目。2. 內(nèi)容整體設(shè)計(jì)與思路拆解2.1 為什么需要專門設(shè)計(jì)context-mode很多人一開(kāi)始會(huì)覺(jué)得上下文嘛不就是把歷史記錄一股腦塞進(jìn)去嗎能有多復(fù)雜我最初也是這么想的直到實(shí)際跑起來(lái)才發(fā)現(xiàn)問(wèn)題一大堆。最直接的三個(gè)坑成本、延遲、準(zhǔn)確性。把全部歷史塞進(jìn)去token消耗線性增長(zhǎng)響應(yīng)越來(lái)越慢而且模型注意力被稀釋后反而容易忽略關(guān)鍵信息。但如果你粗暴地只保留最近幾條又會(huì)丟失長(zhǎng)期約定比如用戶十分鐘前說(shuō)“以后都用中文回答”結(jié)果五輪之后系統(tǒng)就忘了。所以context-mode的本質(zhì)是在信息完整性和資源消耗之間找平衡。從工程角度看context-mode至少需要回答三個(gè)問(wèn)題第一哪些信息算“上下文”第二這些信息以什么形式進(jìn)入處理流程第三什么時(shí)候切換模式這三個(gè)問(wèn)題沒(méi)有統(tǒng)一答案取決于你的場(chǎng)景。但有一套通用的拆解方法可以幫你快速定位自己需要哪種模式。2.2 常見(jiàn)的幾種context-mode類型根據(jù)我自己的實(shí)踐和觀察市面上常見(jiàn)的context-mode大致可以分成四類。我用一個(gè)表格來(lái)對(duì)比它們的核心特征這樣你一眼就能看出區(qū)別。模式類型核心思路適用場(chǎng)景主要缺點(diǎn)全量模式保留完整歷史每次全量傳入短對(duì)話、調(diào)試階段成本高、延遲大滑動(dòng)窗口只保留最近N輪實(shí)時(shí)聊天、客服機(jī)器人丟失長(zhǎng)期信息摘要模式對(duì)歷史做壓縮摘要長(zhǎng)對(duì)話、會(huì)議記錄摘要可能失真混合模式窗口摘要關(guān)鍵信息提取復(fù)雜助手、多任務(wù)場(chǎng)景實(shí)現(xiàn)復(fù)雜度高這四種模式?jīng)]有絕對(duì)優(yōu)劣關(guān)鍵看你的業(yè)務(wù)容忍度。比如一個(gè)代碼補(bǔ)全工具它可能只需要滑動(dòng)窗口就夠了因?yàn)榇a上下文通常就在光標(biāo)附近。但一個(gè)個(gè)人助理可能需要混合模式既要記住你剛才說(shuō)的話也要記住你上周設(shè)定的偏好。2.3 選型背后的權(quán)衡邏輯選context-mode的時(shí)候我一般會(huì)問(wèn)自己四個(gè)問(wèn)題。第一個(gè)是對(duì)話輪次預(yù)期用戶平均會(huì)聊多少輪如果超過(guò)十輪滑動(dòng)窗口就不太夠了。第二個(gè)是信息密度歷史里有多少是真正有用的如果大量是寒暄摘要模式更劃算。第三個(gè)是實(shí)時(shí)性要求能不能接受每次多等幾百毫秒如果能混合模式可以做得更精細(xì)。第四個(gè)是實(shí)現(xiàn)成本團(tuán)隊(duì)有沒(méi)有能力維護(hù)一套摘要生成和關(guān)鍵信息提取的流水線這四個(gè)問(wèn)題問(wèn)完基本就能鎖定一兩種候選模式。我自己的經(jīng)驗(yàn)是先從滑動(dòng)窗口做起再逐步疊加摘要和關(guān)鍵信息提取。不要一上來(lái)就搞混合模式否則調(diào)試起來(lái)會(huì)非常痛苦。先讓系統(tǒng)跑起來(lái)再根據(jù)實(shí)際bad case去優(yōu)化這樣迭代方向更明確。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 上下文邊界的定義方法定義“什么算上下文”是第一步也是最容易出錯(cuò)的一步。我見(jiàn)過(guò)不少項(xiàng)目把整個(gè)會(huì)話歷史都當(dāng)作上下文結(jié)果系統(tǒng)里混入了大量無(wú)關(guān)信息。我的做法是按來(lái)源分層第一層是當(dāng)前輪次的用戶輸入這是必須的第二層是最近幾輪的對(duì)話通常保留三到五輪第三層是長(zhǎng)期記憶比如用戶偏好、歷史任務(wù)狀態(tài)第四層是外部知識(shí)比如檢索到的文檔片段。每一層進(jìn)入context-mode的方式不一樣。當(dāng)前輪次直接拼接到最前面最近幾輪按時(shí)間倒序排列長(zhǎng)期記憶用鍵值對(duì)形式注入外部知識(shí)則根據(jù)相關(guān)性打分后截?cái)?。這樣做的好處是每一層都可以獨(dú)立控制長(zhǎng)度和格式不會(huì)互相干擾。舉個(gè)例子如果長(zhǎng)期記憶里有一條“用戶偏好簡(jiǎn)潔回答”那它應(yīng)該以系統(tǒng)指令的形式出現(xiàn)而不是混在對(duì)話歷史里。注意定義邊界時(shí)一定要和產(chǎn)品經(jīng)理對(duì)齊。技術(shù)上的“上下文”和產(chǎn)品理解的“上下文”經(jīng)常不一致提前對(duì)齊能省掉大量返工。3.2 上下文壓縮的常用手段當(dāng)歷史太長(zhǎng)時(shí)壓縮是繞不開(kāi)的。我常用的壓縮手段有三種。第一種是截?cái)嗪?jiǎn)單粗暴只保留最近N條。第二種是摘要用一個(gè)小模型或者規(guī)則引擎把歷史濃縮成幾句話。第三種是關(guān)鍵信息提取只保留實(shí)體、意圖、約束條件這些結(jié)構(gòu)化信息。截?cái)嗟膬?yōu)點(diǎn)是快缺點(diǎn)是丟信息。摘要的優(yōu)點(diǎn)是保留語(yǔ)義缺點(diǎn)是可能引入幻覺(jué)。關(guān)鍵信息提取的優(yōu)點(diǎn)是精準(zhǔn)缺點(diǎn)是需要定義schema。我一般會(huì)組合使用先用關(guān)鍵信息提取把硬約束抽出來(lái)再用摘要處理軟性對(duì)話最后用截?cái)喽档?。這樣即使摘要出了問(wèn)題硬約束還在系統(tǒng)不會(huì)完全跑偏。具體實(shí)現(xiàn)上關(guān)鍵信息提取可以用正則加規(guī)則也可以用一個(gè)小型分類模型。摘要?jiǎng)t可以用現(xiàn)成的文本摘要接口或者自己微調(diào)一個(gè)小模型。如果資源有限我建議先用規(guī)則做關(guān)鍵信息提取摘要暫時(shí)用截?cái)啻娴葮I(yè)務(wù)跑順了再升級(jí)。3.3 模式切換的觸發(fā)條件context-mode不是一成不變的它應(yīng)該根據(jù)對(duì)話狀態(tài)動(dòng)態(tài)切換。我通常設(shè)置三個(gè)觸發(fā)條件。第一個(gè)是輪次閾值當(dāng)對(duì)話超過(guò)五輪時(shí)從全量模式切到滑動(dòng)窗口。第二個(gè)是長(zhǎng)度閾值當(dāng)累計(jì)token超過(guò)模型上限的70%時(shí)觸發(fā)摘要壓縮。第三個(gè)是意圖變化當(dāng)用戶開(kāi)啟新話題時(shí)重置滑動(dòng)窗口但保留長(zhǎng)期記憶。這三個(gè)條件可以組合使用。比如一個(gè)對(duì)話既超過(guò)了五輪又超過(guò)了長(zhǎng)度閾值那就先摘要再滑動(dòng)。如果用戶突然說(shuō)“換個(gè)話題”那就重置窗口但長(zhǎng)期記憶里的用戶偏好不動(dòng)。這樣切換的好處是系統(tǒng)始終在成本和效果之間保持一個(gè)可接受的平衡。實(shí)操心得觸發(fā)條件不要設(shè)得太敏感。我一開(kāi)始把長(zhǎng)度閾值設(shè)成50%結(jié)果系統(tǒng)頻繁壓縮反而讓對(duì)話變得不連貫。后來(lái)調(diào)到70%到80%之間體驗(yàn)就自然多了。4. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與基礎(chǔ)框架搭建動(dòng)手之前先確認(rèn)你的技術(shù)棧。我用的是Python因?yàn)樯鷳B(tài)成熟調(diào)試方便。核心依賴包括一個(gè)對(duì)話管理框架比如Rasa或者自己寫狀態(tài)機(jī)、一個(gè)文本處理庫(kù)比如LangChain或者自己封裝、以及一個(gè)存儲(chǔ)層Redis或者SQLite都行。如果你用的是其他語(yǔ)言思路是一樣的只是工具不同。第一步是定義數(shù)據(jù)結(jié)構(gòu)。我一般用一個(gè)字典來(lái)表示上下文包含四個(gè)鍵current_input、recent_turns、long_term_memory、external_knowledge。每個(gè)鍵對(duì)應(yīng)一個(gè)列表或字典方便后續(xù)操作。然后寫一個(gè)ContextManager類負(fù)責(zé)加載、壓縮、切換模式。這個(gè)類不需要太復(fù)雜先實(shí)現(xiàn)基本功能后面再迭代。class ContextManager: def __init__(self, max_turns5, max_tokens3000): self.max_turns max_turns self.max_tokens max_tokens self.recent_turns [] self.long_term_memory {} self.mode full def add_turn(self, user_input, system_output): self.recent_turns.append({user: user_input, system: system_output}) if len(self.recent_turns) self.max_turns: self.recent_turns self.recent_turns[-self.max_turns:] self.mode sliding這段代碼只是骨架但已經(jīng)能跑通最基本的滑動(dòng)窗口邏輯。你可以先把它集成到你的對(duì)話流程里看看效果。4.2 上下文加載與壓縮的具體實(shí)現(xiàn)加載上下文的時(shí)候我習(xí)慣按優(yōu)先級(jí)順序拼接。先是系統(tǒng)指令然后是長(zhǎng)期記憶接著是摘要如果有最后是最近幾輪對(duì)話和當(dāng)前輸入。這樣模型看到的順序是“規(guī)則→背景→近期→現(xiàn)在”符合大多數(shù)模型的注意力習(xí)慣。壓縮的實(shí)現(xiàn)要分兩步。第一步是判斷是否需要壓縮判斷依據(jù)就是前面說(shuō)的長(zhǎng)度閾值。第二步是執(zhí)行壓縮我一般用一個(gè)小模型做摘要提示詞寫清楚“請(qǐng)用三句話總結(jié)以下對(duì)話的核心信息保留所有數(shù)字和專有名詞”。如果不想調(diào)模型也可以用TextRank或者LSA這類無(wú)監(jiān)督方法效果差一些但勝在穩(wěn)定。def compress_turns(self, turns): text \n.join([f用戶{t[user]}\n系統(tǒng){t[system]} for t in turns]) # 這里可以調(diào)用摘要模型也可以用規(guī)則截?cái)?summary summarize(text, max_length100) return summary壓縮完之后把摘要存到long_term_memory里然后清空recent_turns。下次加載時(shí)摘要會(huì)作為背景信息注入。這樣既控制了長(zhǎng)度又保留了關(guān)鍵信息。4.3 模式切換的代碼實(shí)現(xiàn)與參數(shù)調(diào)優(yōu)模式切換的核心是一個(gè)狀態(tài)機(jī)。我定義三個(gè)狀態(tài)full、sliding、summarized。初始狀態(tài)是full當(dāng)輪次超過(guò)閾值時(shí)切到sliding當(dāng)token超過(guò)閾值時(shí)切到summarized。每次加載上下文前先檢查當(dāng)前狀態(tài)再?zèng)Q定用哪種加載策略。def get_context(self, current_input): if self.mode full: context self._build_full_context(current_input) elif self.mode sliding: context self._build_sliding_context(current_input) else: context self._build_summarized_context(current_input) return context參數(shù)調(diào)優(yōu)方面max_turns我一般設(shè)成5到8max_tokens設(shè)成模型上限的70%到80%。這兩個(gè)值需要根據(jù)實(shí)際對(duì)話長(zhǎng)度分布來(lái)調(diào)整。我的做法是跑一百條真實(shí)對(duì)話統(tǒng)計(jì)輪次和token的分布取80分位數(shù)作為閾值。這樣既能覆蓋大多數(shù)場(chǎng)景又不會(huì)頻繁觸發(fā)壓縮。提示調(diào)參時(shí)一定要用真實(shí)數(shù)據(jù)不要拍腦袋。我見(jiàn)過(guò)有人把max_turns設(shè)成20結(jié)果token早就超了滑動(dòng)窗口根本沒(méi)機(jī)會(huì)觸發(fā)。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 上下文丟失與錯(cuò)亂的典型表現(xiàn)最常見(jiàn)的問(wèn)題就是“系統(tǒng)忘了”。表現(xiàn)有兩種一種是完全忘記比如用戶說(shuō)了三遍名字系統(tǒng)還是叫錯(cuò)另一種是錯(cuò)亂比如把A用戶的信息混到B用戶身上。前者通常是滑動(dòng)窗口太短后者往往是長(zhǎng)期記憶沒(méi)有做隔離。排查的時(shí)候我一般先看日志里實(shí)際傳入的上下文是什么。很多時(shí)候你以為傳了其實(shí)被壓縮掉了。然后檢查長(zhǎng)期記憶的鍵值設(shè)計(jì)是不是用了全局變量而不是按用戶ID隔離。最后看摘要生成的質(zhì)量如果摘要把關(guān)鍵信息丟了那就要調(diào)整摘要提示詞或者換模型。5.2 性能瓶頸的定位與優(yōu)化性能問(wèn)題通常出現(xiàn)在兩個(gè)地方摘要生成和上下文拼接。摘要生成如果調(diào)用外部接口延遲可能達(dá)到幾百毫秒甚至幾秒。優(yōu)化方法是異步生成或者用本地小模型。上下文拼接如果字符串操作太多也會(huì)拖慢速度。優(yōu)化方法是提前把固定部分緩存起來(lái)只拼接變化部分。我做過(guò)一個(gè)測(cè)試把摘要生成從同步改成異步之后平均響應(yīng)時(shí)間從1.2秒降到了400毫秒。另一個(gè)優(yōu)化是把長(zhǎng)期記憶的加載做成懶加載只有用到的時(shí)候才去查數(shù)據(jù)庫(kù)。這兩個(gè)改動(dòng)加起來(lái)整體吞吐量提升了將近三倍。5.3 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決思路系統(tǒng)忘記用戶偏好長(zhǎng)期記憶未注入檢查上下文拼接順序把長(zhǎng)期記憶放在系統(tǒng)指令后對(duì)話越聊越慢全量模式未切換查看token增長(zhǎng)曲線設(shè)置長(zhǎng)度閾值觸發(fā)壓縮摘要后信息失真摘要模型能力不足對(duì)比摘要前后關(guān)鍵信息換模型或改用關(guān)鍵信息提取多用戶信息串?dāng)_記憶未按用戶隔離檢查存儲(chǔ)鍵設(shè)計(jì)用用戶ID作為命名空間切換模式后不連貫觸發(fā)條件太敏感統(tǒng)計(jì)觸發(fā)頻率調(diào)高閾值或增加滯后這張表是我自己踩坑之后整理的基本上覆蓋了八成以上的常見(jiàn)問(wèn)題。遇到新問(wèn)題的時(shí)候先對(duì)照這張表排查能省不少時(shí)間。6. 進(jìn)階優(yōu)化與長(zhǎng)期維護(hù)建議6.1 上下文質(zhì)量評(píng)估指標(biāo)光把系統(tǒng)跑起來(lái)還不夠還得知道它跑得好不好。我一般用三個(gè)指標(biāo)來(lái)衡量上下文質(zhì)量。第一個(gè)是信息保留率關(guān)鍵信息在壓縮后是否還在。第二個(gè)是噪聲比例上下文里有多少是無(wú)關(guān)內(nèi)容。第三個(gè)是切換平滑度模式切換時(shí)對(duì)話是否自然。信息保留率可以用人工標(biāo)注加自動(dòng)檢測(cè)結(jié)合。噪聲比例可以用相關(guān)性打分來(lái)估算。切換平滑度比較主觀我一般靠用戶反饋和bad case分析。這三個(gè)指標(biāo)不需要每天看但每周復(fù)盤一次能發(fā)現(xiàn)很多潛在問(wèn)題。6.2 長(zhǎng)期記憶的存儲(chǔ)與更新策略長(zhǎng)期記憶不是一成不變的它需要更新。我的策略是增量更新加定期清理。每次對(duì)話結(jié)束后把新提取的關(guān)鍵信息合并到長(zhǎng)期記憶里。如果同一個(gè)鍵有新值就覆蓋舊值。同時(shí)設(shè)置一個(gè)過(guò)期時(shí)間比如三十天沒(méi)用的記憶就自動(dòng)清理。存儲(chǔ)方面我用Redis做熱存儲(chǔ)SQLite做冷存儲(chǔ)。熱存儲(chǔ)放最近活躍的用戶記憶冷存儲(chǔ)放歷史歸檔。查詢的時(shí)候先查熱存儲(chǔ)沒(méi)有再查冷存儲(chǔ)。這樣既保證了速度又控制了成本。6.3 從單模式到多模式演進(jìn)的路線如果你現(xiàn)在還在用單一模式想往多模式演進(jìn)我建議分三步走。第一步先把滑動(dòng)窗口做穩(wěn)確保基本對(duì)話不出錯(cuò)。第二步加入關(guān)鍵信息提取把硬約束抽出來(lái)。第三步再引入摘要處理軟性對(duì)話。每一步之間留出足夠的觀察期不要急著上下一步。演進(jìn)過(guò)程中最重要的是保持向后兼容。新模式的加入不應(yīng)該破壞舊模式的行為。我的做法是給每個(gè)模式打上版本號(hào)加載上下文時(shí)根據(jù)版本號(hào)選擇對(duì)應(yīng)的處理邏輯。這樣即使新模式有問(wèn)題也能快速回滾到舊模式。最后分享一個(gè)小技巧在上下文里加一個(gè)隱藏的“調(diào)試標(biāo)記”記錄當(dāng)前模式和關(guān)鍵參數(shù)。這樣排查問(wèn)題時(shí)一眼就能看出系統(tǒng)當(dāng)時(shí)用的是哪種模式省去了翻日志的麻煩。這個(gè)標(biāo)記不會(huì)影響模型輸出但對(duì)開(kāi)發(fā)人員非常友好。6.4 實(shí)際項(xiàng)目中的取舍經(jīng)驗(yàn)做了這么多項(xiàng)目我最大的體會(huì)是context-mode沒(méi)有銀彈。每個(gè)業(yè)務(wù)場(chǎng)景都有自己的特點(diǎn)別人的最佳實(shí)踐搬到你的項(xiàng)目里可能完全不適用。所以不要迷信任何一套方案包括我上面說(shuō)的這些。先理解原理再結(jié)合自己的數(shù)據(jù)去調(diào)才是正道。另外不要過(guò)度設(shè)計(jì)。我見(jiàn)過(guò)一些團(tuán)隊(duì)一開(kāi)始就搞了非常復(fù)雜的混合模式結(jié)果維護(hù)成本極高效果還不如簡(jiǎn)單的滑動(dòng)窗口。先從最簡(jiǎn)單的做起遇到問(wèn)題再優(yōu)化這樣迭代出來(lái)的系統(tǒng)反而更健壯。上下文管理本質(zhì)上是一個(gè)工程問(wèn)題不是算法問(wèn)題穩(wěn)定和可維護(hù)比炫技重要得多。