1. 先從context-mode說起AI對話里最容易被忽略的隱形開關(guān)接觸大語言模型久了你會慢慢意識到一件事同樣一個模型有人用起來像神隊友有人用起來像人工智障差別往往不在模型本身而在于你怎么喂它上下文。這個怎么喂的背后就是今天要聊的context-mode——上下文模式。先說清楚它是什么。大語言模型本身不帶記憶它每一次回答都建立在你當前會話給它看的全部文本之上。這段能看到的文本就是上下文context而模型能處理的最大文本量就是上下文窗口context window。所謂 context-mode就是你管理和組織這段有效文本的方式是用全量對話記錄還是用壓縮摘要是只帶最近幾輪還是從知識庫里檢索最相關(guān)的片段塞進去是讓模型從頭到尾讀一遍還是分段、分層地引導(dǎo)它關(guān)注關(guān)鍵信息。這玩意直接影響什么最直接的三件事回答質(zhì)量、Token 成本和響應(yīng)速度。上下文給得準模型就能精準命中你的意圖給得雜它就抓不住重點甚至開始編給得太多還沒等它回答錢包先空了。這篇文章適合誰如果你平時重度使用 ChatGPT、Claude 這類對話工具或者你在做 AI 應(yīng)用開發(fā)、要自己管理大模型的上下文這篇內(nèi)容都能直接幫上忙。我會從底層原理講到實戰(zhàn)技巧把我踩過的坑和驗證過的方案一并整理出來盡量讓小白也能照著用。2. 理解 context-mode 的三個底層概念2.1 上下文窗口不是聊天記錄的長度而是Token 的預(yù)算很多人的第一個誤區(qū)是把上下文窗口理解成能聊多少句話。實際上模型對文本的處理單位是 Token而不是字符或句子。一個 Token 可以是一個完整的單詞也可以是單詞的一部分中文里一個 Token 大致對應(yīng)一個字到一個詞。不同模型的 Token 換算率差異很大英文大約 1 Token ≈ 4 個字符中文通常會更高一些。我自己習(xí)慣用一個更直觀的類比上下文窗口就像你的工作臺面。臺面就那么大你能攤開多少資料取決于你擺放的效率。對話歷史、系統(tǒng)指令、外部檢索到的知識、模型已經(jīng)生成的內(nèi)容全都要占用這張臺面的空間。你放一堆舊資料上去新資料就擺不下你為了省空間把所有東西都寫得很潦草找起來又費勁。context-mode 說白了就是規(guī)劃這張工作臺的策略。以主流模型為例GPT-4 系列早期的 8K 上下文窗口在現(xiàn)在看已經(jīng)算小了Claude 3 系列把窗口推到了 200KGemini 系列更是做到了 1M 級別。數(shù)字越大當然越好但能裝下和用得好是兩回事。模型對超長上下文的注意力分配是有偏向的它會更多地關(guān)注開頭和結(jié)尾的內(nèi)容中間部分容易被遺忘。這在實際使用中會體現(xiàn)為你在第 5000 輪對話里埋了一個關(guān)鍵信息模型可能根本接不住。所以哪怕窗口夠大也不能消極地把所有內(nèi)容一股腦往里塞。2.2 上下文的質(zhì)量比數(shù)量重要得多上下文窗口決定的是能不能裝下context-mode 要解決的是怎么裝才有效。這里有一個被我反復(fù)驗證過的經(jīng)驗給模型喂 10 條相關(guān)度一般的信息不如喂 3 條精準相關(guān)的信息。為什么因為模型在做生成時本質(zhì)上是在對上下文中的所有 Token 做注意力加權(quán)。如果上下文中充滿了無關(guān)信息這些噪音會分攤模型的注意力導(dǎo)致它在關(guān)鍵信息上的權(quán)重降低回答自然就偏了。打個比方你讓一個實習(xí)生去整理一份行業(yè)報告你給他 500 份相關(guān)行業(yè)的所有資料他會在里面翻很久還找不到重點但如果你精選 5 份核心報告并告訴他先看哪幾頁他的輸出質(zhì)量和速度都會明顯提升。大模型的注意力機制也類似它有走神的本能你要做的是幫它排除干擾。實操中我的習(xí)慣是每一次請求前都先問自己模型完成這個任務(wù)真正需要知道什么不需要什么帶著這個判斷去裁剪上下文而不是直接把整段對話歷史甩給它。2.3 context-mode 與傳統(tǒng)滑動窗口的根本區(qū)別如果你做過 NLP 相關(guān)的開發(fā)可能接觸過一個經(jīng)典方案滑動窗口sliding window。它的邏輯很簡單——只保留最近 N 輪對話超出范圍的舊內(nèi)容直接丟棄。這個方案實現(xiàn)成本低、Token 開銷可控但缺點也很致命它會忘掉早期建立的關(guān)鍵背景。真正的 context-mode 是滑動窗口的升級版它加入了一個核心動作壓縮與提煉。不是簡單地把舊內(nèi)容丟掉而是把舊內(nèi)容整理成摘要、關(guān)鍵結(jié)論或結(jié)構(gòu)化標簽再決定是否在下一次請求中攜帶。比如你聊了一個小時的需求背景中間很多細節(jié)屬于發(fā)散性討論但有幾條是硬約束——項目截止日期是月底數(shù)據(jù)源必須是內(nèi)部 API不能使用第三方存儲。把這些提煉出來比保留整段冗長的對話有效得多。這就是 context-mode 的精髓用更聰明的取舍代替簡單的丟棄用結(jié)構(gòu)化的組織代替平鋪的堆疊。下面我會講具體怎么操作。3. 核心細節(jié)解析context-mode 的四種常見形態(tài)3.1 全量模式最省心但最燒 Token全量模式就是字面意思把整個會話的所有消息都隨請求發(fā)送給模型。ChatGPT 和 Claude 的網(wǎng)頁版默認就是這個邏輯你每說一句話它們都會把之前的整個對話記錄重新發(fā)送一遍。這種模式的優(yōu)點非常明顯實現(xiàn)零成本模型能看到完整的歷史前后的邏輯連貫性有保障。但它的問題同樣突出——Token 消耗呈線性增長。你聊得越久每次請求發(fā)送的 Token 就越多費用會指數(shù)級上升。我用 API 做測試的時候算過一筆賬假設(shè)你的對話上下文平均是 5000 Token你問了 50 個問題那光上下文的消耗就是 25 萬 Token。按當下主流模型的價格這個成本夠你吃一頓好的了。另一個隱患是模型對超長上下文的迷失感。上下文越長模型越容易在開頭和結(jié)尾之間迷路。OpenAI 的官方文檔里也提到過這一點模型的注意力會隨著上下文長度增加而衰減。實際操作中你會發(fā)現(xiàn)對話超過一定輪數(shù)后模型開始重復(fù)你之前已經(jīng)糾正過的錯誤或者對早期設(shè)定的要求失憶這就是全量模式的天花板。所以我的建議是全量模式適合短對話、單輪任務(wù)或?qū)B貫性要求極高且上下文比較緊湊的場景。一旦發(fā)現(xiàn)對話變得冗長、模型開始犯重復(fù)性錯誤就該切換策略了。3.2 摘要模式用提煉代替記憶摘要模式是我個人在日常工作中用得最多的方案。它的核心思路很簡單不要保留全部對話而是定期把已有的對話壓縮成摘要之后每次請求只攜帶摘要 最近的幾輪完整對話。舉個例子你和模型討論一個數(shù)據(jù)分析項目的方案已經(jīng)聊了 20 輪。第 5 輪你確定了要使用 Python 和 Pandas第 8 輪你明確了輸入數(shù)據(jù)是 CSV 格式、字段有日期和銷售額第 12 輪你決定輸出格式要帶環(huán)比增長率。到了第 20 輪你問它幫我把最終的統(tǒng)計口徑整理一下這時候模型真正需要的是這些已確定結(jié)論而不是前 20 輪的完整記錄。實現(xiàn)方式很簡單你可以手動做也可以讓模型幫你做。手動做就是每隔一段時間對模型說請把我們已經(jīng)確認的所有關(guān)鍵結(jié)論整理成一個清單后續(xù)我只發(fā)送清單加最近的對話你能接受嗎模型會乖乖給你生成一份結(jié)構(gòu)化摘要下次你把它粘貼回去接著聊就行。在開發(fā)中這個方案有更工程化的實現(xiàn)——緩存摘要到內(nèi)存或數(shù)據(jù)庫每次請求前自動拼接。LangChain 的 ConversationSummaryMemory 就是干這個的它會自動對歷史對話生成摘要并管理。我自己在做一個客服機器人項目時用過它效果相當穩(wěn)上下文消耗能降到全量模式的 20%-30%而且模型對早期用戶訴求的把握并沒有明顯下降。3.3 檢索模式按需取用精準投放檢索模式適合上下文大而雜的場景比如你要讓 AI 基于一本產(chǎn)品手冊、一套企業(yè)制度或一批歷史工單來回答問題。把這些資料全部塞進上下文顯然不現(xiàn)實更聰明的做法是先把資料入庫根據(jù)用戶當前的問題檢索出最相關(guān)的幾個片段只把這些片段塞進上下文。這就是目前 AI 應(yīng)用開發(fā)里最火的 RAGRetrieval-Augmented Generation檢索增強生成架構(gòu)。它的流程通常是把文檔切分成小塊用 Embedding 模型把每塊轉(zhuǎn)成向量存入向量數(shù)據(jù)庫用戶提問時把問題也轉(zhuǎn)成向量在數(shù)據(jù)庫里做相似度搜索找出最相關(guān)的 Top-K 個片段把這些片段和問題一起發(fā)送給大模型讓它基于這些片段回答。我用這個方案做過一個企業(yè)內(nèi)部知識庫問答系統(tǒng)效果比全量模式好了不止一個量級。最直觀的感受是回答準確率大幅提升因為模型看到的都是和問題高相關(guān)的資料不再被無關(guān)信息干擾。同時 Token 消耗也降下來了一次請求通常只需要幾千 Token 就能完成高質(zhì)量回答。檢索模式的關(guān)鍵在于切分和檢索這兩個環(huán)節(jié)的質(zhì)量。切分不是簡單按字數(shù)硬切要考慮語義完整性比如按章節(jié)、按段落、按語義塊來切。檢索也不是簡單算余弦相似度還需要處理關(guān)鍵詞權(quán)重、元數(shù)據(jù)過濾、重排等問題。這塊展開講能寫一篇長文這里先記住一個結(jié)論檢索模式是處理大規(guī)模上下文的首選方案但它有工程門檻不適合零基礎(chǔ)用戶直接上手。3.4 結(jié)構(gòu)化模式給上下文搭骨架結(jié)構(gòu)化模式是我自己在處理復(fù)雜業(yè)務(wù)邏輯時總結(jié)出來的方法。它強調(diào)把上下文信息按照固定的結(jié)構(gòu)組織起來讓模型一目了然地知道哪些是事實哪些是要求哪些是待辦事項。具體做法是在上下文中使用明確的標記和格式把不同類型的信息區(qū)分開。比如【項目背景】 - 正在開發(fā)一個電商訂單管理系統(tǒng) - 技術(shù)棧Python FastAPI PostgreSQL 【關(guān)鍵約束】 - 訂單狀態(tài)流轉(zhuǎn)必須經(jīng)過審核節(jié)點 - 退款金額超過 500 元需要人工審批 【已完成事項】 1. 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計已完成 2. 訂單創(chuàng)建接口已開發(fā)完成 【當前任務(wù)】 - 需要設(shè)計訂單取消流程的狀態(tài)機這種結(jié)構(gòu)化的好處有兩個。第一模型更容易審題。它看到清晰的分類標簽?zāi)芸焖俣ㄎ坏疆斍叭蝿?wù)真正需要關(guān)注的信息而不是在一大段散文里找線索。第二后續(xù)做摘要、做檢索時也方便——你可以輕松提取某個區(qū)塊的內(nèi)容來做處理。我實際對比過同樣一個需求用一段散文描述和用結(jié)構(gòu)化清單描述模型第一次就理解正確的概率差距非常明顯。散文描述可能需要來回糾正兩三輪結(jié)構(gòu)化清單基本一次到位。這背后的原理不復(fù)雜——結(jié)構(gòu)化的信息降低了模型的解析負擔讓它可以更快地把注意力集中到核心內(nèi)容上。4. 實操過程一個完整的 context-mode 落地流程4.1 明確場景和上下文規(guī)模在進入任何 context-mode 方案之前第一步永遠是想清楚你的使用場景。我把常見的場景分成三類每類的處理策略完全不同第一類是對話式場景比如日常使用 AI 助手聊天、請教問題、頭腦風(fēng)暴。這類場景上下文規(guī)模通常不大幾十輪對話以內(nèi)就能解決問題重點在于保持連貫性。第二類是任務(wù)式場景比如讓 AI 寫一份長報告、分析一個數(shù)據(jù)集、整理一份合同。這類場景上下文里包含大量的輸入材料和中間產(chǎn)出規(guī)?？赡苎杆倥蛎浶枰鲃庸芾?。第三類是知識庫問答場景比如企業(yè)內(nèi)部的制度查詢、產(chǎn)品手冊問答、客服自動回復(fù)。這類場景的背景知識是相對固定的但總量很大必須靠檢索而不是靠硬塞。我的建議是先用最樸素的全量模式跑幾步觀察一下上下文膨脹的速度和模型表現(xiàn)的下滑點。比如你發(fā)現(xiàn)聊到第 15 輪之后模型開始犯重復(fù)性錯誤那 15 輪就是你的臨界點之后就必須切換策略了。4.2 搭建上下文管理的基本框架這里我分享一個可以直接套用的框架我在多個項目里驗證過簡單且可靠。這個框架包含四個層級第一層是系統(tǒng)級指令這是始終不變的部分包括模型角色設(shè)定、輸出格式要求、全局性約束。比如你是一名資深數(shù)據(jù)分析師回答需包含結(jié)論、數(shù)據(jù)依據(jù)和操作建議。第二層是會話級摘要這是隨對話推進而更新的部分記錄已經(jīng)確認的關(guān)鍵結(jié)論和待辦事項。每 5-10 輪對話更新一次。第三層是近期對話這是最近幾輪的完整記錄一般保留 3-5 輪就夠。這一層的存在是為了讓模型能理解當下的語境。第四層是即時輸入也就是用戶當前最新的一條消息。每次請求的上下文 系統(tǒng)指令 會話摘要 近期對話 即時輸入。這個結(jié)構(gòu)在工程上很容易實現(xiàn)在手動使用 AI 時也是清晰可操作的框架。4.3 用摘要模式實際改造一段對話下面我用一個具體的例子演示怎么操作。假設(shè)我要讓 AI 幫我寫一份產(chǎn)品競品分析報告分幾天來做每次對話都會隔一段時間。第一天我可能說幫我看一下這三家競品公司 A、B、C 的核心功能差異我想要一個對比表格。模型給了一份表格。然后我又追加了幾輪討論確定了報告的大綱結(jié)構(gòu)、需要包含的維度功能、定價、用戶體驗、市場定位。如果第二天我直接打開新會話模型會忘掉這些如果繼續(xù)舊會話上下文已經(jīng)亂七八糟。正確的做法是在第一天的對話結(jié)束時讓模型生成一份摘要請把本次對話中我們已確認的所有信息整理成一份結(jié)構(gòu)化摘要包括分析對象、報告大綱、已確定的對比維度、尚待完成的事項。模型會輸出類似這樣的內(nèi)容【分析對象】競品 A、B、C 【報告大綱】 1. 市場概況 2. 功能對比 3. 定價策略 4. 用戶體驗 5. 總結(jié)建議 【已確認維度】功能覆蓋、價格區(qū)間、用戶評分、更新頻率 【待完成】需要一個核心功能對比表和最終的建議章節(jié)第二天新開對話時把這份摘要粘貼進去再加上我們繼續(xù)昨天的話題先完成核心功能對比表模型就能無縫銜接。我實測下來這種方式比在舊會話里繼續(xù)聊的效果更好因為摘要已經(jīng)幫你把散落的信息歸攏成了結(jié)構(gòu)化的結(jié)論模型反而更容易抓住重點。4.4 開發(fā)場景中的自動化實現(xiàn)如果你在開發(fā) AI 應(yīng)用上面的流程可以自動化。我以 Python 為例簡單展示一個最小實現(xiàn)的思路from langchain.memory import ConversationSummaryMemory from langchain.chat_models import ChatOpenAI llm ChatOpenAI(modelgpt-4o, temperature0.7) memory ConversationSummaryMemory(llmllm, memory_keychat_history) # 每次對話后自動更新摘要 memory.chat_memory.add_user_message(今天討論了競品對比維度) memory.chat_memory.add_ai_message(已確認五個對比維度...) # 生成摘要 summary memory.predict_new_summary( messagesmemory.chat_memory.messages, running_summarymemory.running_summary )這一段代碼背后的邏輯是每次新消息進來系統(tǒng)會把已有的對話摘要 新消息一起發(fā)送給模型讓模型更新摘要然后只保存更新后的摘要。這樣每次請求攜帶的上下文就是壓縮后的結(jié)論而不是全部歷史。實際工程中還要考慮一個問題摘要本身也會越滾越長。所以更完善的做法是給摘要做一個分層歸檔——當摘要超過一定長度后對摘要再做一次二次摘要或者把低優(yōu)先級的背景信息移動到獨立的存儲中。我自己的做法是給摘要設(shè)定一個 1500 Token 的上限超過之后就把最早期的基礎(chǔ)背景比如項目背景、角色設(shè)定這類不會變的信息移出摘要放到固定的系統(tǒng)資料區(qū)。5. 常見問題與排查技巧實錄5.1 模型失憶了怎么辦這是所有人都會遇到的問題明明之前告訴過模型某些信息聊著聊著它就忘了。排查思路分三步第一步確認信息是否還在上下文里。如果你在使用檢索模式可能是檢索環(huán)節(jié)沒召回對應(yīng)的片段如果你在使用摘要模式可能是摘要生成時丟失了細節(jié)。最簡單的驗證方法是直接問模型你還記得我之前跟你說過的某某信息嗎看它的回答來判斷上下文里是否還有這段內(nèi)容。第二步確認信息的位置。前文說過模型對上下文開頭和結(jié)尾的內(nèi)容關(guān)注度更高中間段容易被忽略。如果你在一個很長的上下文的中間位置埋了關(guān)鍵信息模型失憶其實是一種必然。解決方法是把關(guān)鍵信息放到系統(tǒng)指令或者靠近結(jié)尾的位置。第三步確認信息的表達方式。模型對模糊表述的理解能力有限。你說我之前提過一個藍色的方案不如說我之前在第 3 輪對話中提出使用藍色主題的方案核心要素包括背景色 #1E90FF 和白色文字。越具體的信息越不容易被模型忽略。5.2 Token 超限報錯怎么處理用 API 開發(fā)時最常遇到的報錯就是 maximum context length exceeded。這個問題的本質(zhì)是你發(fā)送的輸入加上模型要生成的輸出超過了模型上下文窗口的允許值。處理方法有幾種按優(yōu)先級排序最直接的方法是裁剪輸入。把上下文里價值最低的部分刪掉——通常優(yōu)先刪早期對話、冗長的中間輸出、大段參考資料。我自己會先看系統(tǒng)指令和摘要是否重復(fù)很多時候這兩塊占了大量 Token 但信息密度很低。第二種是改用摘要模式或檢索模式這我在前面已經(jīng)講過了。如果上下文經(jīng)常超限說明你的使用模式本身有問題不是一個裁剪能解決的必須做結(jié)構(gòu)性調(diào)整。第三種是按需拆分任務(wù)。把一個大任務(wù)拆成多個小任務(wù)每個小任務(wù)只攜帶自己需要的上下文。比如寫一份長報告先讓模型寫大綱再分段執(zhí)行每段只帶大綱和相關(guān)材料而不是一次性讓模型讀完全部資料。這里有一個實用的 Token 估算方法用tiktoken這個 Python 庫可以精確計算文本的 Token 數(shù)。import tiktoken enc tiktoken.encoding_for_model(gpt-4o) text 這是一段示例文本 tokens enc.encode(text) print(len(tokens))在發(fā)送請求之前先估算一下輸入 Token 數(shù)確認在模型上限以內(nèi)可以避免很多無謂的報錯。5.3 上下文管理的最佳實踐速查表我把日常經(jīng)驗整理成一張速查表方便你對照使用場景推薦模式核心要點避坑提示短對話、單輪咨詢?nèi)磕Ｊ街苯影l(fā)送全部歷史10 輪以內(nèi)問題不大長對話、多輪任務(wù)摘要模式定期提煉結(jié)論摘要要結(jié)構(gòu)化不要散文式大量固定資料問答檢索模式向量檢索 重排切分質(zhì)量決定回答質(zhì)量復(fù)雜業(yè)務(wù)邏輯結(jié)構(gòu)化模式用標記分層組織標簽名稱要一致不要混用API 開發(fā)場景摘要 分層歸檔自動管理上下文設(shè)好 Token 上限和告警另一個我踩過很多次的坑模型輸出的內(nèi)容也會占上下文。所以在長對話中如果模型曾經(jīng)輸出過一大段冗長的分析而你不需要它了最好把這段輸出從上下文里移除而不是任由它占用空間。網(wǎng)頁版客戶端不一定支持這個操作但在 API 開發(fā)的場景里清理歷史消息是很基礎(chǔ)且很必要的一步。5.4 成本控制的幾個實戰(zhàn)技巧Token 就是錢這句話在 AI 應(yīng)用開發(fā)里是硬道理。我總結(jié)幾個能立刻降低成本的技巧第一個技巧是限制輸出長度。通過 API 的max_tokens參數(shù)控制輸出長度很多場景下模型的回答不需要 5000 Token給它設(shè)一個 500-1000 的上限就夠了。輸出一旦過長不僅費錢響應(yīng)也慢。第二個技巧是合理使用模型分層。復(fù)雜的任務(wù)用強模型簡單任務(wù)用輕模型。比如需要深度推理的用 Claude 3.5 Sonnet 或 GPT-4o簡單的文本改寫、翻譯用 GPT-4o mini 這類輕量模型。我在一個文檔處理項目里把部分任務(wù)從 GPT-4o 切到 GPT-4o mini成本直接降了 10 倍以上效果差異很小。第三個技巧是緩存。如果多個請求共用同一段上下文比如同樣的系統(tǒng)指令和知識庫片段你可以用 Prompt Caching提示詞緩存功能。OpenAI 和 Anthropic 都提供了這一能力緩存命中的輸入 Token 價格大幅降低而且響應(yīng)速度更快。前提是你要在工程上保證緩存前綴的一致性——把不變的內(nèi)容放在消息列表的前面。6. 工具選型主流框架如何選擇6.1 LangChain生態(tài)最全但學(xué)習(xí)曲線陡LangChain 是目前 AI 應(yīng)用開發(fā)里最主流的框架它內(nèi)置了多種上下文管理模式ConversationBufferMemory全量、ConversationSummaryMemory摘要、ConversationVectorStoreMemory檢索等。它的優(yōu)勢是生態(tài)齊全各種功能都能找到實現(xiàn)社區(qū)資料多遇到問題容易搜到解決方案。但它的問題也很明顯抽象層級太多框架迭代快API 變動頻繁。我見過不少開發(fā)者被它綁定得很痛苦——框架一升級代碼就要跟著改。如果你對 Python 生態(tài)比較熟可以嘗試如果你只是想快速做個原型我建議先看看更輕量的方案。6.2 輕量方案自己實現(xiàn)摘要記憶很多時候你并不需要引入整個 LangChain。自己實現(xiàn)一個簡單的摘要記憶機制只需要幾十行代碼邏輯倒是更清晰from openai import OpenAI client OpenAI() def compress_history(history, summary): messages [ {role: system, content: 請對歷史對話進行摘要更新保留關(guān)鍵結(jié)論、要求、待辦事項。}, {role: user, content: f已有摘要\n{summary}\n\n新增對話\n{history}} ] resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, max_tokens500 ) return resp.choices[0].message.content每次對話達到一定輪數(shù)后用這種調(diào)用生成最新摘要存入數(shù)據(jù)庫。下一次請求只帶摘要和最近的對話。這種方法的好處是邏輯完全透明你可以精確控制每一部分占用的 Token不依賴任何第三方框架的黑盒行為。6.3 向量數(shù)據(jù)庫檢索模式的數(shù)據(jù)底座如果你要處理大規(guī)模知識庫問答向量數(shù)據(jù)庫是繞不開的一環(huán)。主流的選擇有 Pinecone托管服務(wù)省心、Milvus開源功能強、Chroma輕量適合本地和小型項目、Weaviate自帶混合檢索等。我的選型建議很簡單如果數(shù)據(jù)量在百萬級以下且不想折騰運維用 Chroma 或者 Qdrant 都夠用如果數(shù)據(jù)量大、并發(fā)高再考慮 Milvus如果是企業(yè)級場景且不想自建Pinecone 的托管服務(wù)能省掉大量運維成本。選型時還要看一個關(guān)鍵指標是否支持混合檢索。純向量檢索有時候會漏掉關(guān)鍵詞精確匹配的結(jié)果比如產(chǎn)品型號、人名這類實體向量匹配的效果不一定好。支持向量 關(guān)鍵詞混合檢索并做重排的數(shù)據(jù)庫在知識庫問答場景下明顯更有優(yōu)勢。7. 經(jīng)驗之談context-mode 背后真正值得思考的事折騰 context-mode 這幾年我最大的感受是這個問題沒有銀彈只有不斷根據(jù)場景做取舍。全量模式適合任務(wù)短、要求高的場景摘要模式適合對話式的多輪交互檢索模式適合知識庫問答結(jié)構(gòu)化模式適合復(fù)雜的業(yè)務(wù)邏輯。大多數(shù)實際項目里這幾種模式是組合使用的沒有一個固定的配方。另外一個容易被忽略的點是context-mode 的設(shè)計會反過來影響你使用 AI 的方式。當你養(yǎng)成了定期讓模型整理摘要、保持上下文結(jié)構(gòu)化的習(xí)慣之后你與 AI 的協(xié)作效率會明顯提升。你會發(fā)現(xiàn)你不再被聊著聊著就亂了的問題困擾每次開啟新對話都覺得清爽利落。最后分享一個我自己一直在用的小技巧每次和 AI 開始一個新任務(wù)之前先在第一條消息里說清楚三件事——背景是什么、目標是什么、約束是什么。把這三件事放在最前面相當于給模型一個清晰的上下文導(dǎo)航它能更快進入狀態(tài)你后續(xù)的對話也能少走很多彎路。這個習(xí)慣配合摘要模式使用效果尤其明顯。工具是死的方法論的活。context-mode 說到底是在教我們一件事別讓 AI 把所有信息都讀一遍而是幫它找到真正需要的那一部分。想通了這一點你基本上就掌握了用好大模型的鑰匙。