1. 什么是 context-mode它到底在解決什么問題先說說我為什么會盯上這個概念。過去兩年我一直在做 AI 應(yīng)用相關(guān)的開發(fā)從最早的 API 調(diào)用、提示詞調(diào)優(yōu)到后來的 Agent 編排、知識庫問答幾乎每個項目都會遇到同一個問題模型記不住之前說過什么。用戶問了兩三輪之后模型就開始答非所問或者干脆把前面對話里的關(guān)鍵信息忘得一干二凈。這個場景你一定不陌生——跟 AI 聊天聊到第 5 句它還在聊到第 20 句它就糊涂了。問題不在模型本身而在于我們沒有把上下文當(dāng)回事。context-mode簡單說就是一套管理、組織、傳遞上下文信息的工作模式。它不是一個單一的技術(shù)而是一組策略的集合決定什么信息該進入模型的上下文、以什么形式進入、保留多長時間、超了限制怎么辦。這套邏輯在文檔里通常被籠統(tǒng)地稱為上下文管理但在真實工程里你會發(fā)現(xiàn)做得好的團隊基本都是靠一套明確的 context-mode 機制在運作。這個機制能解決什么問題往小了說它讓 AI 在長對話里保持記憶連貫往大了說它直接決定你的 AI 應(yīng)用是玩具還是產(chǎn)品。我見過太多團隊模型換了最強的、API 費用燒得飛快但用戶反饋依然是AI 像個傻子。根子就在 context 策略上。這篇文章我會把 context-mode 的底層原理、主流實現(xiàn)方式、以及我實際落地的一套完整方案都拆開講適合正在做 AI 應(yīng)用、做知識庫問答、做 Agent 開發(fā)的工程師參考。如果你只是對 AI 好奇也能從中理解為什么 ChatGPT 和 Claude 這類產(chǎn)品會給你越聊越懂你的體驗。2. 拆開 context-mode 的底層原理要理解 context-mode必須先弄明白模型處理上下文的機制。這里的核心單位是 token。平時我們說的上下文窗口本質(zhì)就是一個 token 數(shù)量上限——模型一次能看到的文本長度不能超過這個上限。以主流的商用模型為例窗口規(guī)格從 4K、8K到 128K、200K 不等看起來差距巨大但實際使用中真正能有效利用的遠(yuǎn)沒有宣傳的那么樂觀。2.1 上下文窗口不等于有效記憶很多人有個誤區(qū)只要窗口夠大就能把整個對話和歷史文檔全塞進去。理論上沒錯但工程上完全不是這么回事。第一窗口越大輸入成本越高API 按 token 計費塞進去的每一丁點內(nèi)容都在燒錢第二模型對長上下文的注意力會衰減這是 transformer 架構(gòu)的固有特性——距離當(dāng)前問題越遠(yuǎn)的內(nèi)容被模型想起來的權(quán)重就越低。我實測過當(dāng)上下文長度超過 100K token 時模型回答靠前部分信息的準(zhǔn)確率會明顯下降這不是玄學(xué)是注意力分布的自然結(jié)果。所以 context-mode 的第一個核心任務(wù)是在有限的窗口里決定什么內(nèi)容值得占位置。我自己的經(jīng)驗是用三層篩選邏輯來做這個決策相關(guān)性層內(nèi)容與當(dāng)前用戶問題的語義關(guān)聯(lián)有多強時效性層內(nèi)容是不是最近產(chǎn)生的越近的對話信息優(yōu)先級越高重要性層某些內(nèi)容比如用戶明確指定的事實、系統(tǒng)指令里強調(diào)的規(guī)則無論多久都要保留這三層邏輯聽起來簡單但真正落地時每一步都有講究。相關(guān)性判斷不能只靠關(guān)鍵詞匹配至少要用 embedding 語義檢索時效性要結(jié)合對話輪次和真實時間戳雙重判斷重要性則需要你在指令設(shè)計階段就給系統(tǒng)提示詞里的內(nèi)容設(shè)定不可覆蓋的標(biāo)記。2.2 token 計算context-mode 的地基所有上下文管理策略第一步都是精確計算 token。這里我要特別提醒一個新手幾乎必踩的坑不要用 API 返回的 usage 字段作為唯一依據(jù)更不要自己按字符數(shù)估算。中文環(huán)境下不同分詞器的 token 切分差異很大同一個句子在不同的模型編碼器下token 數(shù)能相差 30% 以上。我建議的做法是在當(dāng)前模型的官方 tokenizer 基礎(chǔ)上封裝一層本地計算服務(wù)。如果你用的是 OpenAI 兼容接口就用 tiktoken 庫配合對應(yīng)的編碼器名稱來做預(yù)計算。為什么要本地算因為你在做上下文裁剪、滑動窗口調(diào)整的時候需要高頻、零成本地估算 token 量每次都調(diào) API 既不現(xiàn)實也白白花錢。我封裝過一個小工具核心代碼大致是這樣import tiktoken def count_tokens(text: str, model: str gpt-4) - int: try: encoder tiktoken.encoding_for_model(model) except KeyError: encoder tiktoken.get_encoding(cl100k_base) return len(encoder.encode(text)) # 示例估算一段對話歷史的總 token conversation [ {role: user, content: 幫我查一下上季度的銷售數(shù)據(jù)}, {role: assistant, content: 好的我找到了相關(guān)報表需要我詳細(xì)解讀嗎}, ] total sum(count_tokens(msg[content]) for msg in conversation) print(total)這里有一個細(xì)節(jié)不同模型的編碼器不同gpt-4 和 gpt-3.5 用的是 cl100k_baseClaude 系列則是自己的 tokenizer。所以封裝的時候一定要做模型到編碼器的映射表別圖省事一股腦全用同一個。token 計算準(zhǔn)確了后面的所有管理策略才有意義。2.3 注意力衰減為什么塞得越多效果越差剛才提到注意力衰減我再展開說下這個現(xiàn)象的本質(zhì)。Transformer 模型在計算注意力時每個 token 會跟序列里的其他 token 做相關(guān)性打分但這個打分機制存在近因偏差——距離越遠(yuǎn)的 token在位置編碼和層疊計算中被稀釋得越厲害。你可以把它理解成一個開會開了一整天的人上午講的細(xì)節(jié)到下午已經(jīng)只剩模模糊糊的印象除非那件事特別重要被打了個標(biāo)簽否則很難精準(zhǔn)回憶。這對 context-mode 的啟示是不要試圖讓模型硬記而是讓它在需要時能看到足夠清晰的筆記。所以好的上下文管理不是把原始對話一股腦塞進去而是做內(nèi)容重構(gòu)——把長對話中真正有價值的信息抽取出來重新組織成精煉的摘要或結(jié)構(gòu)化數(shù)據(jù)再放入上下文。這相當(dāng)于幫模型做了一輪筆記整理讓它在有限的注意力預(yù)算里把力氣花在最值得關(guān)注的內(nèi)容上。3. context-mode 的三種主流實現(xiàn)策略理解了底層原理之后我們來看實際工程中常用的三種 context-mode 策略。這三種不是互斥的成熟項目里往往是組合使用只是側(cè)重點不同。3.1 滑動窗口模式簡單直接但不夠聰明這是最基礎(chǔ)、也是最多人在用的方案。思路很簡單維護一個對話歷史隊列只保留最近 N 輪或者最近 M 個 token的內(nèi)容超過部分直接丟棄。實現(xiàn)上就是一個先進先出隊列我見過不少項目用 deque 就能搞定from collections import deque class SlidingWindowContext: def __init__(self, max_rounds: int 10): self.max_rounds max_rounds self.history deque(maxlenmax_rounds) def add_message(self, message: dict): self.history.append(message) def get_context(self) - list: return list(self.history)滑動窗口最大的優(yōu)點是實現(xiàn)成本極低幾乎不會出錯。但缺點也很致命它沒有內(nèi)容價值的概念。用戶在第 3 輪提過一個關(guān)鍵事實比如我的預(yù)算是 5 萬到第 12 輪已經(jīng)被擠出去了模型完全不知道這個約束給出的建議全部偏離方向。實測下來這個模式只適合對話輪次少、關(guān)鍵信息密度低的場景比如單次客服咨詢。3.2 語義壓縮模式把歷史提煉成摘要為了彌補滑動窗口的失憶問題語義壓縮模式出現(xiàn)了。核心做法是當(dāng)對話歷史超過閾值時不是簡單丟棄舊消息而是調(diào)用模型把舊內(nèi)容總結(jié)成精煉摘要然后帶著摘要繼續(xù)對話。這相當(dāng)于人類在會議中途叫秘書把上午的討論整理成一份要點下午我們按這個來。我實現(xiàn)過一個簡單的壓縮邏輯思路如下設(shè)定一個觸發(fā)閾值比如累計 6000 token超過后把最早的一半消息打包發(fā)給模型做摘要然后刪掉原文、保留摘要繼續(xù)對話。這個方案比滑動窗口聰明得多能保留散落在長對話里的重要事實。但要注意幾個坑摘要本身也要占 token不能無限壓縮通常我會給摘要設(shè)一個上限比例比如原始長度的 20%壓縮是有損的壓縮頻率越高信息丟失越嚴(yán)重。我踩過最慘的一次用戶在第 20 輪提到取消周三的預(yù)約到第 25 輪我問周三的安排是什么模型完全答不上來因為在某次壓縮時這個信息被概括遺漏了要減少這種損失我建議在摘要指令里強制要求保留用戶明確表達的事實、數(shù)字、日期、決策——這些是壓縮過程中最不該丟的硬信息。3.3 RAG 增強模式與外部知識的協(xié)作第三種策略是 RAG檢索增強生成它解決的問題不是對話歷史太長而是模型知識庫之外的信息怎么進上下文。典型的場景是企業(yè)知識庫問答用戶問的是公司內(nèi)部的規(guī)章制度模型沒學(xué)過你得先從向量數(shù)據(jù)庫里檢索出相關(guān)片段拼進 prompt 里讓它回答。RAG 模式的 context-mode 核心是按需取用。對話窗口多少不重要重要的是你每次遞進給模型的內(nèi)容是不是用戶當(dāng)前問題真正需要的。我做過一個完整的企業(yè)知識庫助手流程是用戶提問 - 用 embedding 對整個文檔庫做向量檢索 - 找出 top 5 相關(guān)片段 - 拼接到系統(tǒng)提示詞后面 - 讓模型基于片段回答。整個過程中上下文里只出現(xiàn)和問題相關(guān)的信息無關(guān)文檔一概不占用。這里有個關(guān)鍵的度的問題檢索出來的片段越多模型回答越全面但被不相關(guān)片段干擾的概率也越高。我實測的結(jié)果是5 到 8 個片段每個 400 到 600 token是性價比最高的區(qū)間。少于 3 個信息可能不全多于 10 個模型容易東拉西扯把不相關(guān)的檢索結(jié)果也硬融進回答里。4. 實操過程搭建一套帶 context-mode 的問答系統(tǒng)下面把我最近做的一個項目完整復(fù)盤一遍。這個項目的需求是企業(yè)內(nèi)部智能問答用戶可以通過對話查規(guī)章制度、提交請假申請。核心需求就是三句話對話要連貫、知識要準(zhǔn)確、費用不能失控。這三點逼著我把三種 context-mode 策略整合到了一套流程里。4.1 整體架構(gòu)設(shè)計與選型理由先交代技術(shù)選型。我用的是 OpenAI 兼容的 API國內(nèi)可用渠道embedding 模型選用 text-embedding-3-small向量數(shù)據(jù)庫用 Chroma因為部署輕量、不依賴云端服務(wù)適合企業(yè)內(nèi)部離線場景。對話模型選的是 gpt-4o-mini精度夠用、成本可控。架構(gòu)上分四個模塊輸入處理、上下文管理、知識檢索、模型調(diào)用。上下管理模塊是核心它內(nèi)部維護兩個結(jié)構(gòu)——短期消息隊列和長期摘要緩存。短期隊列保存最近 6 輪對話原文用于保證實時連貫性長期摘要緩存保存前面所有內(nèi)容的壓縮摘要用于兜底重要信息。這套組合的本質(zhì)是短期內(nèi)讓模型看到原文長期內(nèi)讓模型看到提煉后的要點。選擇這種拆分而不是直接用一個超大窗口我的考慮很簡單成本。gpt-4o-mini 輸入價格雖然不高但企業(yè)內(nèi)部問答每天幾千次調(diào)用每次多塞 2000 token一個月下來也是一筆不小的開銷。而滑動窗口加摘要的組合能把單次請求的 token 消耗控制在一個穩(wěn)定區(qū)間費用可以提前預(yù)算。實測下來平均單次請求 token 從長窗口模式的 12000 降到了 6500 左右?guī)缀跹鼣亍?.2 核心代碼實現(xiàn)上下文管理模塊這個模塊是系統(tǒng)的調(diào)度核心我把它獨立成了一個類方便復(fù)用和測試。先看關(guān)鍵實現(xiàn)import json from typing import List, Dict, Any class ContextManager: def __init__(self, max_rounds: int 6, max_total_tokens: int 6000): self.short_history [] # 最近對話原文 self.summary # 長期摘要 self.max_rounds max_rounds self.max_total_tokens max_total_tokens def add_user_message(self, content: str): self.short_history.append({role: user, content: content}) def add_assistant_message(self, content: str): self.short_history.append({role: assistant, content: content}) self._maybe_compress() def _maybe_compress(self): # 估算當(dāng)前總 token current_tokens self._estimate_tokens() if current_tokens self.max_total_tokens: return # 觸發(fā)壓縮把最早一半的消息合并后做摘要 # 這里會調(diào)用 LLM 完成摘要實際項目中單獨封裝 messages_to_summarize self.short_history[: len(self.short_history) // 2] self.summary self._generate_summary(messages_to_summarize) self.short_history self.short_history[len(self.short_history) // 2:] def _estimate_tokens(self) - int: total 0 for msg in self.short_history: total count_tokens(msg[content]) if self.summary: total count_tokens(self.summary) return total def build_prompt(self, user_query: str) - List[Dict[str, str]]: messages [] if self.summary: messages.append({ role: system, content: f以下是對歷史對話的總結(jié)供參考\n{self.summary} }) messages.extend(self.short_history) messages.append({role: user, content: user_query}) return messages這段代碼有幾個關(guān)鍵設(shè)計點值得細(xì)說。壓縮觸發(fā)時機我選的是每次助手回復(fù)之后因為這時候?qū)υ捦暾囟嗔艘惠喪菣z查長度的好時機。壓縮時選擇最早一半消息做摘要保留了最近的精華內(nèi)容不動的策略是為了減少最近信息被壓縮工具遺漏的概率。summary 以系統(tǒng)角色放入 prompt為的是讓模型把它當(dāng)作全局背景知識來參照而不是當(dāng)作一段普通對話內(nèi)容來回應(yīng)。實際運行中我還會在 summary 里附上生成時間戳和來源輪次方便排查信息歸屬。這個細(xì)節(jié)幫我快速定位過不少問題強烈建議你也加上。4.3 檢索增強部分把知識庫接到上下文里有了對話上下文管理還不夠企業(yè)問答的核心是知識庫里的文檔。這部分我用 Chroma 做向量檢索流程拆解如下第一步離線階段把企業(yè)規(guī)章制度文檔切分成 500 token 左右的片段用 embedding 模型生成向量存入 Chroma。切分粒度很講究——太小100 token語義容易被截斷太大1000 token檢索噪音多精確匹配率下降。500 是我在多種切分下對比出來的平衡點好效果需要多試幾組不同大小的數(shù)據(jù)選準(zhǔn)確率最高的那個。第二步在線階段用戶提問后先用相同 embedding 模型給問題生成向量在 Chroma 里做相似度檢索取 top 5 條相關(guān)片段。第三步把這 5 條片段和上下文管理模塊生成的 messages 拼在一起調(diào)用對話模型。拼接順序上有個細(xì)節(jié)知識片段內(nèi)容放在用戶消息之前、系統(tǒng)摘要之后。這樣模型在讀到用戶問題之前已經(jīng)先接觸到了相關(guān)的背景資料更利于它形成基于資料回答的思維定式。放后面也不是不行但實測準(zhǔn)確率會掉幾個點。檢索代碼核心如下import chromadb class KnowledgeRetriever: def __init__(self, collection_name: str company_docs): self.client chromadb.PersistentClient(path./chroma_store) self.collection self.client.get_or_create_collection( namecollection_name, metadata{hnsw:space: cosine} ) def retrieve(self, query: str, top_k: int 5) - List[Dict]: result self.collection.query( query_texts[query], n_resultstop_k, ) docs [] for idx in range(len(result[documents][0])): docs.append({ content: result[documents][0][idx], metadata: result[metadatas][0][idx], }) return docs檢索出來的片段我會做一個簡單的去重和相關(guān)性過濾如果某條片段的相似度分?jǐn)?shù)低于 0.3直接丟棄。這個閾值是我基于多次測試定的低于 0.3 的片段基本是噪音強行拼進去反而會影響模型判斷。4.4 參數(shù)調(diào)優(yōu)與效果對比整套系統(tǒng)上線后我做了一輪參數(shù)調(diào)整這里分享幾個最有體感的發(fā)現(xiàn)max_rounds 設(shè)置 6 輪是最優(yōu)解。低于 4 輪時用戶多問幾個問題就斷片高于 8 輪時prompt 里的內(nèi)容太多模型回答速度明顯變慢。6 輪加摘要的組合既能保證連貫性又不拖慢速度。摘要壓縮時機設(shè)置在 6000 token 觸發(fā)。我試過 4000壓縮太頻繁摘要滿天飛歷史信息反復(fù)被碾碎和 8000單次請求費用偏高且長上下文注意力衰減明顯。6000 是一個費用和信息保留率的平衡點具體數(shù)字要根據(jù)你的模型調(diào)整。知識檢索的 top_k 從 3 調(diào)到 5準(zhǔn)確率從 78% 漲到 86%。繼續(xù)調(diào)到 8 反而因為引入過多噪音掉到 83%。每個知識庫都有它的最佳 top_k上線后拿真實問題跑一版對比不同數(shù)值下的準(zhǔn)確率很有必要。5. 常見問題與排查技巧實錄再好的設(shè)計上線后總會遇到奇奇怪怪的問題。我把這段時間踩過的坑整理成了一份排查手冊遇到類似現(xiàn)象可以按圖索驥。5.1 模型開始忘事了怎么定位是哪一環(huán)丟的這個問題出現(xiàn)時別急著調(diào)模型或者罵 API按順序排查。第一步先確認(rèn)消息是否真的發(fā)到了模型那里。在調(diào)用 API 之前打印完整的 prompt看你期望的關(guān)鍵信息在不在里面。我遇到過好幾次明明用戶在第 3 輪說了預(yù)算 5000 以內(nèi)第 5 輪問答時 prompt 里根本沒有這句話——因為壓縮模塊把最早的消息摘要后摘要生成時丟了這個數(shù)字。這就是壓縮損失問題需要在摘要指令里加硬性要求。我寫的是務(wù)必保留所有具體的數(shù)字、日期、人名、產(chǎn)品名、金額上限等硬性事實即使用戶沒有強調(diào)。第二步如果 prompt 里有但模型回答依然不對那就是注意力問題。雖然內(nèi)容在上下文里但它被埋在了長文本中段模型沒能注意到。這時候要調(diào)整位置——把核心信息放到 prompt 的開頭系統(tǒng)提示詞里或結(jié)尾靠近用戶消息的位置這兩個位置是注意力相對集中的區(qū)域。中間的容易被忽略這是 transformer 注意力分布的特征。第三步如果位置沒問題還可能是檢索部分返回了太多不相關(guān)片段稀釋了關(guān)鍵信息的權(quán)重。把檢索結(jié)果打印出來人工看一下很像。如果是這個問題調(diào)低 top_k 或提高相似度閾值。5.2 token 費用突然暴漲該查哪里這是每個讀賬單時心驚膽戰(zhàn)的開發(fā)者都會碰到的事。我總結(jié)的排查路徑是打印每次請求的完整 token 明細(xì)對比前后幾天同一類型請求的 token 量變化重點檢查 summary 的長度是否失控。我出過一次問題摘要模塊沒有限制輸出長度某次長對話壓縮出的 summary 竟然有 1800 token直接把預(yù)算打崩了。后來我給摘要指令加了總長度不超過 300 字的限制同時也加入了硬性截斷邏輯兜底檢查是否有重復(fù)注入。例如檢索模塊把同一篇文檔的多個片段都放進了上下文而這些片段 90% 的內(nèi)容重疊白白浪費 token。按文檔 ID 去重同一個文檔最多放 2 個片段5.3 用戶反饋我昨天跟你說過的事你今天就不記得了這種跨會話的記憶context-mode 處理不了因為上下文本來就是單次會話內(nèi)的概念。解決思路是把記憶持久化——把每次對話的重要信息抽取出來存進數(shù)據(jù)庫下次新會話開始時把與當(dāng)前用戶相關(guān)的歷史記憶重新注入上下文。我實現(xiàn)過一個輕量方案每輪對話結(jié)束后調(diào)用模型用固定格式抽取用戶畫像信息比如偏好、約束、歷史決策以 JSON 格式存入 MongoDB。新會話建立時把用戶的最近 20 條畫像記錄拼進系統(tǒng)提示詞。這個方案效果好得出乎意料用戶明顯感受到被記住了。當(dāng)然也有成本每次抽取畫像需要多調(diào)一次模型費用增加約 15%換取體驗提升是值的。謹(jǐn)慎評估后再決定要不要做。再補充一個容易被忽視的細(xì)節(jié)上下文管理模塊要記錄每次壓縮的日志包括壓縮時間、壓縮了哪些消息、生成的摘要原文。出了問題可以直接回溯那句話是在哪次壓縮時丟的定位效率翻倍。沒有日志的上下文管理系統(tǒng)上線等于裸奔這句話我反復(fù)對團隊講過。常見問題根因排查手段解法長對話后模型忘得離譜摘要丟失硬信息檢查 prompt 中是否含關(guān)鍵數(shù)字、日期摘要指令強制保留硬性事實回答被舊話題帶偏舊內(nèi)容干擾新問題打印完整 prompt 人工檢查提升短期歷史輪次、壓縮更早的內(nèi)容單次費用超預(yù)算summary 過長或片段重疊查看 token 明細(xì)限制摘要字?jǐn)?shù)、按文檔 ID 去重檢索出來的內(nèi)容答非所問相似度閾值過低打印檢索分?jǐn)?shù)提高閾值到 0.3 以上新會話不記得用戶信息上下文未持久化檢查數(shù)據(jù)庫畫像記錄增加記憶抽取與注入流程6. 一些基于我實際經(jīng)驗的小結(jié)與建議說句實在話context-mode 這個概念并不存在一條萬能的配置曲線它的每一項策略選擇都綁定在我們對具體業(yè)務(wù)場景的理解上。比如我給知識庫問答做的方案如果換到一個自由閑聊型應(yīng)用上摘要壓縮策略就要推翻重來——閑聊內(nèi)容更冗余更需要控制成本但信息準(zhǔn)確性要求低很多可以壓縮得更狠。我的一個體會是最先要想清楚的是產(chǎn)品和用戶場景然后設(shè)計上下文管理的目標(biāo)是成本的邊際、信息的保留率還是響應(yīng)的時延目標(biāo)一明確具體策略順理成章就出來了工程量也沒有想象的大。還有個小技巧想分享給大家。上線之后我習(xí)慣每兩周拿同一組真實用戶問題跑一遍回放測試。把這期間用戶真實問過的問題重新喂給系統(tǒng)對比模型回答和人工標(biāo)注的標(biāo)準(zhǔn)答案不斷發(fā)現(xiàn) context-mode 狀態(tài)不佳的地方。有一次復(fù)盤發(fā)現(xiàn)用戶問法里經(jīng)常出現(xiàn)那個、之前說的這類指代詞單純的歷史摘要和檢索都接不住這種隱含引用。后來我在預(yù)處理層加了一個指代詞消解邏輯如果檢測到之前說的/上次那個自動把最近的用戶消息和助手之前的回答重新拼接強調(diào)一次準(zhǔn)確率立刻回升。這類問題都是文檔里學(xué)不到的必須在真實數(shù)據(jù)里反復(fù)碰。context-mode 沒有一勞永逸的終點它是個需要持續(xù)打磨的環(huán)節(jié)。好的實現(xiàn)會像一個合格的助手從不打擾你但在你需要的時候永遠(yuǎn)清楚你之前說過什么、你需要什么。