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