RAG 和 Memory 是 Agent 開(kāi)發(fā)里最容易被混在一起的兩個(gè)概念。很多人做知識(shí)庫(kù)問(wèn)答時(shí)第一反應(yīng)是我用了 RAG是不是就不需要 Memory 了也有人反過(guò)來(lái)把會(huì)話歷史一股腦拼進(jìn)系統(tǒng)提示詞然后說(shuō)這就是 Memory。先說(shuō)結(jié)論這兩個(gè)東西解決的問(wèn)題根本不一樣。RAG 解決的是“Agent 不知道外部知識(shí)”的問(wèn)題Memory 解決的是“Agent 記不住剛才說(shuō)過(guò)什么、做過(guò)什么、用戶偏好是什么”的問(wèn)題。它們可以配合但不能互相替代。這篇文章適合正在選型 Agent 框架、準(zhǔn)備做知識(shí)庫(kù)問(wèn)答、或者想優(yōu)化多輪對(duì)話體驗(yàn)的開(kāi)發(fā)者。我會(huì)先幫你分清這兩個(gè)概念再給一套實(shí)際可用的選型判斷路徑最后說(shuō)落地時(shí)最容易踩的坑。重點(diǎn)不是堆功能而是讓你能在自己的場(chǎng)景里判斷現(xiàn)在該加 RAG該加 Memory還是兩個(gè)都加。1. 先分清問(wèn)題RAG 解決“信息缺失”Memory 解決“狀態(tài)遺忘”1.1 RAG 的本質(zhì)是給 Agent 裝一個(gè)可檢索的外部知識(shí)庫(kù)RAG 全稱是 Retrieval-Augmented Generation檢索增強(qiáng)生成。它的核心思路不是把知識(shí)寫(xiě)進(jìn)模型參數(shù)而是先從外部文檔里檢索出和用戶問(wèn)題相關(guān)的片段再把片段作為上下文交給語(yǔ)言模型讓模型基于這些片段生成回答。典型場(chǎng)景是企業(yè)內(nèi)部文檔問(wèn)答、產(chǎn)品手冊(cè)查詢、法律法規(guī)檢索、學(xué)術(shù)論文閱讀。這些內(nèi)容要么不在模型訓(xùn)練數(shù)據(jù)里要么更新很快。比如你的產(chǎn)品上周剛改了價(jià)格模型知識(shí)還停留在半年前這時(shí)候就算模型本身很聰明它也會(huì)答錯(cuò)。RAG 的價(jià)值就在于把答案的“依據(jù)”從模型內(nèi)部搬到外部知識(shí)庫(kù)每次回答前先查最新文檔。所以判斷一個(gè)場(chǎng)景要不要用 RAG可以問(wèn)自己一個(gè)問(wèn)題用戶問(wèn)題的答案是否需要依賴某個(gè)具體文檔里的準(zhǔn)確信息如果需要那就要考慮 RAG。如果只是常識(shí)性問(wèn)答模型本身就能回答沒(méi)有必要上來(lái)就做一套檢索鏈路。RAG 的關(guān)鍵組件包括文檔加載、切塊、向量化、向量存儲(chǔ)、檢索、重排序、生成。每一步都有參數(shù)要調(diào)后面我會(huì)專門(mén)講。1.2 Memory 的本質(zhì)是讓 Agent 記住交互歷史和狀態(tài)Memory 關(guān)注的是時(shí)間維度的信息。它包含短期的會(huì)話上下文也包含長(zhǎng)期的用戶畫(huà)像、偏好和任務(wù)狀態(tài)。舉幾個(gè)具體例子用戶上一輪說(shuō)了“我要訂明天早上九點(diǎn)的會(huì)議室”這一輪說(shuō)“改到十點(diǎn)”Agent 需要知道“這間會(huì)議室”指的是哪一間。用戶連續(xù)問(wèn)了五個(gè)問(wèn)題最后說(shuō)“結(jié)合前面幾條給我一個(gè)總結(jié)”Agent 不能只看到最后一句話。用戶已經(jīng)在系統(tǒng)里綁定過(guò)企業(yè) ID 和部門(mén)Agent 在后續(xù)回答中應(yīng)該默認(rèn)記住而不是每次重新問(wèn)。這些都是 Memory 的職責(zé)。實(shí)現(xiàn)方式也很多樣把最近幾輪對(duì)話拼進(jìn)系統(tǒng)提示詞、用摘要壓縮歷史、用向量庫(kù)存記憶條目、用外部數(shù)據(jù)庫(kù)記錄用戶屬性或者用專門(mén)的記憶模塊。判斷場(chǎng)景是否需要 Memory 同樣可以問(wèn)一個(gè)問(wèn)題用戶問(wèn)題的答案是否依賴剛才聊過(guò)的內(nèi)容或者用戶長(zhǎng)期信息如果是就需要 Memory。光靠 RAG 檢索外部文檔是不夠的因?yàn)橥獠课臋n里沒(méi)有“用戶剛剛說(shuō)過(guò)什么”這個(gè)信息。1.3 最容易出現(xiàn)的誤區(qū)把 RAG 和 Memory 混著用我在實(shí)際項(xiàng)目里見(jiàn)過(guò)兩種典型誤區(qū)。第一種把 RAG 庫(kù)當(dāng)成 Memory 用。有人把歷史對(duì)話也切塊存進(jìn)向量庫(kù)用戶提問(wèn)時(shí)同時(shí)檢索文檔和歷史。這么做不是完全不行但很容易失控。歷史對(duì)話噪聲多相關(guān)性不穩(wěn)定檢索出來(lái)的片段可能互相矛盾而且會(huì)快速消耗上下文空間。更關(guān)鍵的問(wèn)題是歷史對(duì)話里的很多信息根本不需要向量化比如“用戶剛說(shuō)了 OK”這句話沒(méi)有知識(shí)價(jià)值存進(jìn)向量庫(kù)只會(huì)干擾檢索。第二種把 Memory 當(dāng)成 RAG 用。有人為了省事把產(chǎn)品文檔全文塞進(jìn)記憶模塊每次請(qǐng)求都把文檔拼進(jìn)提示詞。如果文檔很短還能湊合文檔一長(zhǎng)很快超過(guò)上下文窗口模型反而抓不住重點(diǎn)延遲也上去了。正確思路應(yīng)該是RAG 的檢索對(duì)象是穩(wěn)定的知識(shí)型內(nèi)容Memory 的檢索對(duì)象是動(dòng)態(tài)的交互狀態(tài)和用戶事實(shí)。兩者可以在同一個(gè) Agent 里共存但定位完全不同。2. 從 Agent 工作流程看 RAG 和 Memory 到底放在哪個(gè)環(huán)節(jié)2.1 Agent 的典型執(zhí)行循環(huán)一個(gè) Agent 執(zhí)行任務(wù)時(shí)通常會(huì)經(jīng)歷這樣的循環(huán)接收用戶輸入結(jié)合上下文和記憶判斷是否需要外部知識(shí)調(diào)用工具或檢索生成回復(fù)最后更新記憶。在這個(gè)循環(huán)里Memory 是貫穿始終的。Agent 每一次做出決策都需要知道當(dāng)前處于什么狀態(tài)而 RAG 通常是在“需要外部知識(shí)”這個(gè)節(jié)點(diǎn)觸發(fā)不是每次提問(wèn)都要走一遍檢索。用偽代碼表示會(huì)更容易理解user_input receive() context memory.build_context(user_id, session_id) if need_external_knowledge(user_input): docs rag.retrieve(user_input) context docs response llm.generate(user_input, context) memory.save(user_id, session_id, user_input, response)這里 Memory 負(fù)責(zé)提供背景RAG 負(fù)責(zé)補(bǔ)充檢索片段。兩者都拼進(jìn)上下文但來(lái)源不同用途也不同。2.2 Memory 在整個(gè)會(huì)話中的角色Memory 在系統(tǒng)中通常分成短期記憶和長(zhǎng)期記憶兩層。短期記憶主要保存當(dāng)前會(huì)話的對(duì)話輪次、工具調(diào)用結(jié)果、臨時(shí)變量。它的特點(diǎn)是時(shí)效性強(qiáng)但也容易被新消息覆蓋。實(shí)現(xiàn)時(shí)最常用的是維護(hù)一個(gè)消息列表每次請(qǐng)求把最近 N 輪拼進(jìn)提示詞。N 一般由上下文窗口、模型能力和成本共同決定。長(zhǎng)期記憶則保存跨會(huì)話的穩(wěn)定信息。比如用戶姓名、公司、偏好、歷史訂單、訂閱狀態(tài)。這類信息往往需要結(jié)構(gòu)化存儲(chǔ)或者以記憶條目的形式寫(xiě)入獨(dú)立數(shù)據(jù)庫(kù)。長(zhǎng)期記憶要注意一個(gè)問(wèn)題用戶偏好會(huì)變化。不能把用戶半年前的選擇當(dāng)成永遠(yuǎn)不變的偏好需要給記憶條目加時(shí)間戳或者版本。配置 Memory 時(shí)常見(jiàn)的參數(shù)有會(huì)話 ID、保留最近對(duì)話輪數(shù)、摘要觸發(fā)閾值、記憶寫(xiě)入條件。不同框架參數(shù)名不一樣但你要關(guān)心的核心問(wèn)題是這些信息應(yīng)該在什么時(shí)候?qū)懭胧裁磿r(shí)候被清理。2.3 RAG 在任務(wù)中的觸發(fā)時(shí)機(jī)RAG 不是每次用戶提問(wèn)都要觸發(fā)。如果用戶只是在閑聊或者問(wèn)題本身在模型知識(shí)范圍內(nèi)走 RAG 反而增加延遲和噪聲。比較常見(jiàn)的做法是增加一個(gè)路由判斷先判斷用戶問(wèn)題是否需要外部知識(shí)?？梢杂靡?guī)則、分類器也可以讓模型自己決定。比如“查一下最新的政策文件”明顯需要走檢索“幫我寫(xiě)一段歡迎語(yǔ)”通常不需要。一旦確定要走 RAG流程一般是這樣理解用戶問(wèn)題必要時(shí)擴(kuò)展成多個(gè)子查詢。對(duì)查詢做向量化。在向量庫(kù)中檢索最相似的片段。對(duì)結(jié)果做重排序把真正相關(guān)的排名提前。把篩選后的片段拼接到提示詞中。讓模型基于片段生成答案并盡量給出引用來(lái)源。整個(gè)過(guò)程里切塊策略對(duì)效果影響最大。固定長(zhǎng)度切塊簡(jiǎn)單但容易把語(yǔ)義切斷按段落和標(biāo)題切塊更合理但不同文檔結(jié)構(gòu)差異很大。常見(jiàn)做法是先用文檔結(jié)構(gòu)粗切再對(duì)特別大的塊做二次切分。3. 到底怎么選先回答五個(gè)關(guān)鍵問(wèn)題再看決策表3.1 選型之前先問(wèn)自己五個(gè)問(wèn)題與其直接問(wèn)“RAG 和 Memory 用哪個(gè)”不如先把場(chǎng)景拆開(kāi)。我一般會(huì)先回答這五個(gè)問(wèn)題用戶的問(wèn)題是否依賴外部文檔或?qū)崟r(shí)數(shù)據(jù)用戶的問(wèn)題是否依賴剛才的對(duì)話歷史或用戶長(zhǎng)期信息外部知識(shí)的更新頻率高不高當(dāng)前模型的上下文窗口能容納多少內(nèi)容你更在意回答準(zhǔn)確率還是更在意交互的連續(xù)性和個(gè)性化第一個(gè)問(wèn)題指向 RAG第二個(gè)問(wèn)題指向 Memory第三個(gè)問(wèn)題決定你要不要做文檔同步第四個(gè)問(wèn)題影響你的方案復(fù)雜度第五個(gè)問(wèn)題決定你的優(yōu)化優(yōu)先級(jí)。舉個(gè)例子。一個(gè)產(chǎn)品手冊(cè)問(wèn)答機(jī)器人用戶的問(wèn)題大多數(shù)依賴外部文檔但是單輪問(wèn)答為主連續(xù)追問(wèn)的情況很少。這種情況 RAG 優(yōu)先Memory 只需要保留很淺的會(huì)話歷史就夠了。另一個(gè)例子。一個(gè)招聘助手用戶會(huì)連續(xù)交流自己的經(jīng)歷、求職意向、薪資期望。這些信息不是外部文檔里的知識(shí)而是用戶動(dòng)態(tài)提供的狀態(tài)。這種情況 Memory 優(yōu)先RAG 只在需要查詢崗位信息時(shí)觸發(fā)。3.2 一張表幫你快速選型場(chǎng)景推薦方案說(shuō)明產(chǎn)品文檔問(wèn)答RAG 優(yōu)先Memory 輔助答案依賴文檔知識(shí)需要及時(shí)更新多輪對(duì)話中的個(gè)性化推薦Memory 優(yōu)先RAG 按需需要記住用戶偏好商品庫(kù)查詢適合走 RAGAgent 執(zhí)行復(fù)雜任務(wù)兩者結(jié)合Memory 記錄任務(wù)狀態(tài)RAG 檢索操作手冊(cè)或規(guī)則客服機(jī)器人兩者結(jié)合Memory 保存用戶訂單和上下文RAG 檢索政策文檔純閑聊機(jī)器人只上 Memory不需要外部知識(shí)重點(diǎn)在上下文連貫單輪知識(shí)問(wèn)答只上 RAG沒(méi)有跨輪依賴Memory 成本可以省掉這張表是經(jīng)驗(yàn)判斷不是絕對(duì)規(guī)則。如果你的場(chǎng)景比較特殊按照自己的數(shù)據(jù)分布來(lái)調(diào)整。3.3 兩種常見(jiàn)組合模式除了上面這種表格我再給你一個(gè)更簡(jiǎn)單的版本。極簡(jiǎn)模式只使用 Memory加上模型自帶知識(shí)。適合簡(jiǎn)單客服、閑聊、任務(wù)型對(duì)話。優(yōu)點(diǎn)是開(kāi)發(fā)成本低缺點(diǎn)是沒(méi)有私有知識(shí)時(shí)模型容易編造答案。知識(shí)庫(kù)模式只使用 RAG做單輪問(wèn)答。適合文檔檢索場(chǎng)景比如搜政策、搜手冊(cè)。優(yōu)點(diǎn)是不用維護(hù)復(fù)雜歷史缺點(diǎn)是連續(xù)追問(wèn)效果很差用戶問(wèn)“剛才說(shuō)的那個(gè)條款呢”模型根本不知道?；旌夏Ｊ絉AG 和 Memory 一起用。這是真實(shí) Agent 場(chǎng)景中最常見(jiàn)的選擇。Agent 既需要私有知識(shí)又需要跨輪狀態(tài)。混合模式不等于把所有功能堆一起而是讓兩條鏈路各司其職。這里有一個(gè)很容易被忽視的判斷不要看到一個(gè) Agent 框架自帶 RAG 和 Memory 模塊就以為兩個(gè)都用一定更好。如果場(chǎng)景真的只需要文檔檢索強(qiáng)行加 Memory 反而會(huì)讓問(wèn)題復(fù)雜化。選型的第一步永遠(yuǎn)是看需求而不是看功能列表。4. 實(shí)際落地先從最小例子跑通再做混合方案4.1 環(huán)境準(zhǔn)備動(dòng)手之前先確認(rèn)你的運(yùn)行環(huán)境。不用一步到位但下面幾個(gè)條件要盡量提前準(zhǔn)備好。語(yǔ)言和框架Python 生態(tài)下常用 LangChain、LlamaIndex也可以自己用 FastAPI 搭接口。如果用的是 Dify、Spring AI 這類框架模塊會(huì)更多一些但核心思路一致。向量庫(kù)常見(jiàn)選擇有 Qdrant、Chroma、Milvus、pgvector。學(xué)習(xí)階段用 Chroma 最輕量生產(chǎn)環(huán)境再考慮 Qdrant 或 Milvus。嵌入模型和語(yǔ)言模型可以調(diào)云端 API也可以用本地模型。本地模型要額外關(guān)注顯存和內(nèi)存如果機(jī)器配置不高先把模型體積選小一點(diǎn)。輸入輸出格式明確你要處理的是 txt、Markdown、PDF 還是 Word 文檔以及對(duì)話結(jié)果的返回格式。注意原始材料里沒(méi)有給出版本號(hào)落地時(shí)請(qǐng)先確認(rèn)你所用的框架和依賴版本。不同版本的 API 變化很大不要拿舊教程直接套。4.2 先跑通純 RAG 的最小樣例我建議不要一上來(lái)就做混合方案。先把 RAG 單條鏈路跑通再考慮 Memory。最小步驟是加載一個(gè)文檔比如一份產(chǎn)品說(shuō)明的 txt 文件。按長(zhǎng)度切片比如每塊 500 字符重疊 50 字符。調(diào)用嵌入模型把每個(gè)切片轉(zhuǎn)成向量。把向量存入向量庫(kù)。輸入一個(gè)測(cè)試問(wèn)題檢索相似片段。把片段拼進(jìn)提示詞讓模型生成回答。# 偽代碼示例實(shí)際參數(shù)以你的環(huán)境為準(zhǔn) chunks split_text(text, chunk_size500, chunk_overlap50) embeddings embed_model.encode(chunks) vector_store.add(chunks, embeddings) question 這個(gè)產(chǎn)品的價(jià)格調(diào)整政策是什么 results vector_store.search(question, top_k3) prompt f基于以下資料回答\n{results}\n問(wèn)題{question} answer llm.invoke(prompt)跑通之后先驗(yàn)證三件事檢索結(jié)果是否相關(guān)回答是否基于檢索片段以及會(huì)不會(huì)出現(xiàn)“編造文檔中沒(méi)有的內(nèi)容”。如果回答看起來(lái)像模型在自由發(fā)揮說(shuō)明提示詞約束不夠或者檢索片段根本沒(méi)有被模型認(rèn)真使用。4.3 再跑通 Memory 的最小會(huì)話RAG 穩(wěn)定之后再單獨(dú)加 Memory。最簡(jiǎn)單的做法就是維護(hù)一個(gè)消息列表每次請(qǐng)求把最近幾輪拼進(jìn)提示詞。messages memory.get_recent(session_id, max_turns10) user_input 我叫張三 prompt build_prompt(messages, user_input) answer llm.invoke(prompt) memory.add(session_id, user_input, answer)測(cè)試時(shí)用一組連續(xù)問(wèn)題先問(wèn)“我叫張三”再問(wèn)“我叫什么”最后問(wèn)“我剛才說(shuō)了什么”。如果模型都能回答說(shuō)明最小會(huì)話記憶是通的。這里先不要急著做摘要。先用原始消息跑通觀察上下文長(zhǎng)度對(duì)回答質(zhì)量的影響再?zèng)Q定要不要把早期消息壓縮成摘要。摘要會(huì)省 token但也會(huì)丟失細(xì)節(jié)需要權(quán)衡。4.4 混合后的最小流程兩條鏈路都穩(wěn)定后再合并成一個(gè)流程# 偽代碼示例 messages memory.get_recent(session_id) if should_use_rag(question): docs rag.search(question) context format_docs(docs) format_messages(messages) else: context format_messages(messages) answer llm.invoke(question, context) memory.add(session_id, question, answer)這已經(jīng)是一個(gè)非常夠用的混合方案。它沒(méi)有復(fù)雜的路由模型沒(méi)有長(zhǎng)期用戶畫(huà)像但能覆蓋大部分場(chǎng)景有知識(shí)時(shí)檢索文檔有歷史時(shí)參考?xì)v史兩者都滿足時(shí)一起用。4.5 判斷標(biāo)準(zhǔn)混合方案跑起來(lái)之后不要只看“能回答”就結(jié)束還要盯幾個(gè)指標(biāo)單條響應(yīng)延遲。如果響應(yīng)變慢優(yōu)先看檢索耗時(shí)和上下文長(zhǎng)度。檢索命中質(zhì)量。隨機(jī)抽 20 個(gè)問(wèn)題看檢索結(jié)果是否真的覆蓋答案。上下文占用。連續(xù)對(duì)話到第 10 輪后提示詞占了多少 token如果超過(guò)模型窗口的 80%就要做摘要或限制輪數(shù)。是否重復(fù)引用同一段文檔。如果 top_k 里三塊內(nèi)容高度重復(fù)說(shuō)明切塊重疊太多需要調(diào)整。記憶是否準(zhǔn)確。用戶上一輪說(shuō)的事情這一輪是否被正確復(fù)用。5. 混合使用時(shí)的架構(gòu)要點(diǎn)和常見(jiàn)坑5.1 Memory 和 RAG 不要搶同一塊上下文混合方案最常出的問(wèn)題不是功能不夠而是上下文不夠用。RAG 檢索出來(lái)的片段可能很長(zhǎng)Memory 里又有十幾輪歷史。兩者都塞進(jìn)提示詞之后二十分鐘過(guò)去模型看到的大部分內(nèi)容都是歷史對(duì)話和檢索片段反而找不到當(dāng)前用戶問(wèn)題在哪。解決思路是給上下文做一個(gè)預(yù)算。比如模型上下文窗口是 8000 token你可以規(guī)定RAG 片段最多占 3000Memory 最多占 2500留給模型發(fā)揮的空間至少 2000。比例不一定固定但一定要有預(yù)算意識(shí)。Memory 側(cè)可以壓縮最近 2-3 輪保留原始消息更早的用摘要代替。RAG 側(cè)可以限制top_k 設(shè)成 3 或 5每段長(zhǎng)度通過(guò)切塊參數(shù)控制。不要以為檢索出 10 塊都有用很多時(shí)候 3 塊高質(zhì)量片段比 10 塊噪聲更有價(jià)值。5.2 記憶的寫(xiě)入和清理記憶不是存得越多越好。把所有對(duì)話原樣存下來(lái)很快會(huì)把存儲(chǔ)和上下文都拖垮。寫(xiě)入策略上我會(huì)優(yōu)先保存有狀態(tài)價(jià)值的信息。比如用戶明確說(shuō)過(guò)“我偏好某個(gè)品牌”“我下周要出差”“我已經(jīng)完成了第一步”這些信息值得寫(xiě)入記憶。而“好的”“嗯”“謝謝”這類消息價(jià)值很低不寫(xiě)反而更干凈。清理策略同樣重要。長(zhǎng)期記憶里要給每條記錄加時(shí)間戳當(dāng)用戶說(shuō)“我改主意了”時(shí)新記錄要能覆蓋舊記錄而不是讓模型同時(shí)看到矛盾信息。會(huì)話記憶里超過(guò)最大輪數(shù)的消息要么丟棄要么摘要不能無(wú)限累積。5.3 RAG 檢索質(zhì)量和切塊策略RAG 最容易翻車的點(diǎn)不是模型而是文檔加載和切塊。常見(jiàn)問(wèn)題包括PDF 里表格提取后亂掉、頁(yè)眉頁(yè)腳成為噪聲、掃描件沒(méi)有 OCR、文檔編碼不是 UTF-8。這些都會(huì)讓后續(xù)檢索質(zhì)量大打折扣。處理文檔時(shí)先人工抽查幾個(gè)片段別急著全部灌進(jìn)向量庫(kù)。切塊也不是只看字符數(shù)。固定長(zhǎng)度切塊最容易把一句話切成兩半導(dǎo)致檢索結(jié)果語(yǔ)義不完整。更好的辦法是按標(biāo)題、段落、列表先拆分再對(duì)超大塊二次切分。切塊長(zhǎng)度和重疊率是互相影響的一般先設(shè) 500-800 字符、10% 重疊再根據(jù)檢索結(jié)果調(diào)整。另一個(gè)容易忽略的點(diǎn)是引用溯源。企業(yè)級(jí) RAG 不能只給答案還要能說(shuō)明答案來(lái)自哪份文檔的哪一段。否則答錯(cuò)了沒(méi)法排查用戶也不敢采信。熱詞里提到的“RAG 的引用溯源與 groundedness”就是這個(gè)意思。5.4 混合方案排查鏈路混合方案出了問(wèn)題時(shí)按這個(gè)順序排查不要一上來(lái)就懷疑模型能力?；卮鹣駴](méi)讀過(guò)文檔先看檢索片段是否相關(guān)。如果片段本來(lái)就不對(duì)模型再?gòu)?qiáng)也答不對(duì)。連續(xù)對(duì)話答錯(cuò)先看 Memory 是否覆蓋了關(guān)鍵信息。有時(shí)候是保存了但模型沒(méi)有用上有時(shí)候是根本沒(méi)保存。提示詞超長(zhǎng)或響應(yīng)很慢先看上下文預(yù)算、檢索片段數(shù)量、歷史輪數(shù)。超長(zhǎng)通常不是模型問(wèn)題是策略問(wèn)題?；卮鹎昂竺芟瓤?Memory 里的舊信息和新信息是否沖突有沒(méi)有清理機(jī)制。RAG 命中但生成亂編先看提示詞是否明確要求“只能基于資料回答”并且允許模型在資料不足時(shí)說(shuō)不知道。5.5 值得關(guān)注的進(jìn)階方向如果你已經(jīng)跑通了基礎(chǔ)的 RAG Memory下一步可以關(guān)注幾個(gè)更細(xì)的方向。Agentic RAG 是一個(gè)思路不讓每次請(qǐng)求都固定走檢索流程而是讓 Agent 自己判斷什么時(shí)候需要調(diào)用檢索工具。這樣能減少無(wú)效檢索節(jié)省成本和時(shí)間。Memory Channel 也是一種參考把記憶拆分成不同通道比如會(huì)話記憶、實(shí)體記憶、任務(wù)記憶。每個(gè)通道存不同類型的信息檢索時(shí)按需取用。對(duì)復(fù)雜 Agent 場(chǎng)景來(lái)說(shuō)比單一大列表更穩(wěn)定。還可以考慮加入知識(shí)圖譜或 MCP 這類外部模塊但前提是你的基礎(chǔ)鏈路已經(jīng)穩(wěn)定。否則一次堆太多功能出了問(wèn)題很難定位。我的建議是先跑通最小閉環(huán)再逐步加能力。6. 幾個(gè)可以直接拿去用的選型經(jīng)驗(yàn)6.1 先區(qū)分“知識(shí)”和“狀態(tài)”這是整個(gè)選型最核心的一句話。如果信息是一個(gè)事實(shí)比如“發(fā)貨政策是 24 小時(shí)內(nèi)”“這座城市的面積是 1000 平方公里”往 RAG 方向走。 如果信息是動(dòng)態(tài)狀態(tài)比如“用戶剛剛選擇了 5 號(hào)商品”“用戶當(dāng)前登錄的是企業(yè)賬號(hào)”往 Memory 方向走。 如果一個(gè)信息既有知識(shí)屬性又有狀態(tài)屬性比如用戶選擇的產(chǎn)品型號(hào)是動(dòng)態(tài)狀態(tài)而該型號(hào)的官方技術(shù)參數(shù)是外部知識(shí)就要拆成兩段處理狀態(tài)放 Memory技術(shù)參數(shù)走 RAG。6.2 不要一開(kāi)始就追求大而全很多 AI Agent 框架自帶 Memory 和 RAG 模塊默認(rèn)配置不一定適合你的場(chǎng)景。我見(jiàn)過(guò)不少團(tuán)隊(duì)上來(lái)就配置了長(zhǎng)期記憶、向量數(shù)據(jù)庫(kù)、重排序、多輪摘要、工具調(diào)用結(jié)果系統(tǒng)看起來(lái)能力很強(qiáng)但用戶隨便問(wèn)幾個(gè)問(wèn)題就開(kāi)始亂答。原因就是鏈路太長(zhǎng)任何一個(gè)環(huán)節(jié)的噪聲都會(huì)被放大。更穩(wěn)的做法是先用最簡(jiǎn)單的方式跑通一個(gè)列表存歷史一個(gè)向量庫(kù)查文檔。驗(yàn)證核心鏈路之后再逐步加摘要、重排序、權(quán)限控制。6.3 用問(wèn)題反推方案我不太推薦先選框架再想場(chǎng)景。反過(guò)來(lái)先收集真實(shí)用戶問(wèn)題再做分類會(huì)更靠譜。把用戶問(wèn)題分成四類事實(shí)查詢答案能在外部文檔里找到典型如“這個(gè)品類的退貨標(biāo)準(zhǔn)是什么”。這類走 RAG。連續(xù)追問(wèn)答案依賴上一輪語(yǔ)氣和上下文典型如“剛才說(shuō)的那個(gè)方案預(yù)算改成 2 萬(wàn)怎么調(diào)整”。這類走 Memory。任務(wù)執(zhí)行需要 Agent 記住步驟和狀態(tài)同時(shí)可能要查操作手冊(cè)。這類 RAG Memory 都要。個(gè)性化推薦需要記住用戶偏好同時(shí)檢索內(nèi)容庫(kù)。這類也是混合方案。分類之后你會(huì)發(fā)現(xiàn)很多場(chǎng)景其實(shí)只需要其中一個(gè)不需要一上來(lái)就把所有能力全開(kāi)。6.4 一定要留可觀測(cè)性混合方案最怕“看起來(lái)能用但出了問(wèn)題不知道從哪里排查”。我建議每個(gè)請(qǐng)求都記錄三份信息這次有沒(méi)有觸發(fā) RAG檢索了哪些片段命中分?jǐn)?shù)多少M(fèi)emory 帶了哪些歷史是否做了摘要最終模型生成了什么答案有沒(méi)有引用來(lái)源。這些日志存在本地文件或數(shù)據(jù)庫(kù)里都可以關(guān)鍵是別省略。有了日志你才能判斷回答錯(cuò)誤是檢索問(wèn)題、記憶問(wèn)題還是模型問(wèn)題。否則用戶反饋一句“你回答錯(cuò)了”你連從哪里開(kāi)始查都不知道。我個(gè)人更建議把項(xiàng)目拆成兩個(gè)階段第一階段跑通單文檔 RAG 加會(huì)話 Memory確認(rèn)兩條鏈路都穩(wěn)定第二階段再做路由、摘要、長(zhǎng)期記憶和更復(fù)雜的 Agentic RAG。不要一開(kāi)始就把所有高級(jí)概念都堆上去。很多問(wèn)題不是工具能力不夠而是前置環(huán)境和輸入材料沒(méi)有處理干凈。先把基礎(chǔ)鏈路做扎實(shí)后面加什么功能都更容易判斷值不值。