最近一年里我陸續(xù)參與了好幾個RAG相關(guān)項(xiàng)目發(fā)現(xiàn)一個挺有意思的現(xiàn)象大家一開始都是用最樸素的“向量檢索大模型生成”路線跑通demo之后就忍不住開始加?xùn)|西——加查詢改寫、加檢索路由、加多輪對話記憶、加Agent循環(huán)、甚至上多Agent協(xié)作。而那次經(jīng)歷讓我印象特別深刻一個同事問我為什么他的RAG系統(tǒng)檢索結(jié)果總是不準(zhǔn)明明top-k都取到10了大模型還是答非所問。我看了他的架構(gòu)其實(shí)就是最傳統(tǒng)的embedding檢索說實(shí)話問題根源不是k值而是整套檢索鏈路壓根沒有“決策”能力。于是就有了這篇文章的主題復(fù)雜架構(gòu)怎么取舍具體就是Agentic RAG、LLM Wiki與Multi-Agent這三條演進(jìn)路徑。這篇文章適合兩類人一類是已經(jīng)在做RAG但效果卡殼、想搞清楚下一步往哪走的工程師另一類是對架構(gòu)設(shè)計(jì)有選擇困難、想知道什么場景該上多復(fù)雜方案的技術(shù)負(fù)責(zé)人。我會結(jié)合實(shí)操經(jīng)驗(yàn)把這三種架構(gòu)的核心原理、實(shí)施方法、成本和坑點(diǎn)一次性講透。1. 從傳統(tǒng)RAG到復(fù)雜架構(gòu)演進(jìn)背后的真實(shí)動因1.1 傳統(tǒng)RAG的瓶頸到底在哪傳統(tǒng)RAG的流程所有人都很熟悉先把文檔做切分embedding之后存向量庫用戶問題來了直接用問題的embedding去向量庫召回top-k段落然后把用戶問題和召回段落拼到上下文里丟給大模型生成答案。這套流程在小規(guī)模、單一知識域、問題模式固定的場景下是可以工作的而且工程成本很低幾行代碼就能跑起來。但它有三個繞不開的瓶頸。第一召回策略是固定的不管用戶問的是“XX功能的配置參數(shù)”還是“XX方案的整體設(shè)計(jì)思路”它都拿同一個embedding去向量庫里找相似片段?？蓪?shí)際問題類型差異巨大有的該做關(guān)鍵詞檢索、有的該做全文檢索、有的最好用圖譜檢索傳統(tǒng)RAG沒有能力動態(tài)選擇。第二召回結(jié)果沒有任何校驗(yàn)top-k是根據(jù)相似度硬截?cái)嗟南嗨贫鹊?、但其?shí)包含關(guān)鍵答案的文檔很容易被丟掉而相似度高、但實(shí)際不相關(guān)的噪聲文檔卻會被塞進(jìn)上下文大模型被干擾之后只能胡編。第三多輪對話場景下非常笨用戶說“那第二個方案呢”系統(tǒng)不知道“那”指代什么只能把上一個問題重復(fù)檢索或者盲目擴(kuò)大召回范圍效果自然一塌糊涂。這些問題的共同點(diǎn)就是整個檢索鏈路是靜態(tài)的、沒有自適應(yīng)能力。傳統(tǒng)RAG把“生成”這個環(huán)節(jié)交給了大模型但“檢索”環(huán)節(jié)依然是開發(fā)者手寫的固定程序。要解決這類問題升級方向就變得很自然讓模型參與檢索決策把知識組織成更合理的形態(tài)或者干脆讓多個模型分工協(xié)作——這正是Agentic RAG、LLM Wiki、Multi-Agent三條路線的出發(fā)點(diǎn)。1.2 三條路線的核心差異一句話說清我自己的理解是這三條路線的側(cè)重點(diǎn)完全不同不是互相替代的關(guān)系。Agentic RAG解決的是“怎么檢索”的問題。它把檢索策略從開發(fā)者寫死變成模型動態(tài)決策——模型決定是直接向量檢索、還是先改寫問題、還是多種檢索組合、以及召回結(jié)果是否足夠回答當(dāng)前問題。本質(zhì)是給RAG裝上了一個“策略大腦”。LLM Wiki解決的是“知識怎么組織”的問題。它把平坦的文檔切片集合升級為有結(jié)構(gòu)的、可導(dǎo)航的知識網(wǎng)絡(luò)讓檢索器可以精準(zhǔn)定位知識節(jié)點(diǎn)而不是盲找相似片段。本質(zhì)是給RAG換了一套更合理的“記憶存儲結(jié)構(gòu)”。Multi-Agent解決的是“任務(wù)怎么分工”的問題。它把復(fù)雜的用戶請求拆解成多個子任務(wù)由多個Agent并行或串行處理各司其職最后匯總產(chǎn)出。本質(zhì)是從單線程作業(yè)升級為分布式團(tuán)隊(duì)協(xié)作。理解了這個差異后面選型就有框架了先判斷問題出在“檢索策略”“知識組織”還是“任務(wù)分工”再決定上哪套架構(gòu)。接下來我會逐一展開。2. Agentic RAG把檢索決策權(quán)交給模型2.1 Agentic RAG到底改變了什么設(shè)計(jì)邏輯先看一段傳統(tǒng)的RAG調(diào)用邏輯這是很多初版系統(tǒng)的寫法def rag_answer(question): query_embedding embed(question) chunks vector_db.search(query_embedding, top_k5) context \\n\\n.join(chunks) prompt build_prompt(question, context) return llm.chat(prompt)這段代碼的核心假設(shè)是用戶問題不需要處理、檢索方式不需要變化、召回結(jié)果不需要驗(yàn)證。在一個受控的demo場景里沒問題但在真實(shí)業(yè)務(wù)中問題千奇百怪這套假設(shè)就集體崩塌了。Agentic RAG的設(shè)計(jì)邏輯完全不同它把“檢索”這件事從單次函數(shù)調(diào)用改成了一個帶決策循環(huán)的任務(wù)。最基礎(chǔ)的流程長這樣收到問題先讓模型判斷該用什么檢索方式再按計(jì)劃執(zhí)行檢索拿到結(jié)果之后讓另一個模型判斷結(jié)果夠不夠回答不夠就觸發(fā)額外的檢索動作換個關(guān)鍵詞、換個索引、或者搜一下原文的引用來源足夠就進(jìn)入生成階段。這一步設(shè)計(jì)上的改變是把“檢索策略的選擇”從代碼邏輯轉(zhuǎn)移到了模型推理上。換句話說模型不再只是用搜索結(jié)果生成文本而是要先學(xué)會“如何搜索”。實(shí)際項(xiàng)目中這個改變往往比想象中更有效。我做一個內(nèi)部知識庫問答時最初固定用向量召回準(zhǔn)確率在60%左右徘徊后來加上了一個路由模塊讓模型對常見配置類問題走“關(guān)鍵詞檢索全文檢索”讓方案設(shè)計(jì)類問題走“向量檢索摘要索引召回”準(zhǔn)確率一下拉到了80%以上。2.2 最小可用的Agentic RAG怎么落地我強(qiáng)烈建議不要一上來就搞復(fù)雜的agent框架直接用一個路由驗(yàn)證的最簡方案就足夠解決80%的問題。我常用的結(jié)構(gòu)是三個模塊Planner負(fù)責(zé)解析問題、制定檢索計(jì)劃、Retriever按計(jì)劃執(zhí)行多種檢索方式、Grader驗(yàn)證召回內(nèi)容是否切題決定是否需要二次檢索。模塊間用結(jié)構(gòu)化JSON傳遞消息把決策過程暴露在日志里方便排查。以下是一個可以直接跑通的最小設(shè)計(jì)class AgenticRAG: def run(self, question, history): # 1. 路由決策判斷該用哪種檢索策略 plan self.planner(question, history) # 2. 執(zhí)行檢索計(jì)劃 chunks self.retrieve(question, plan) # 3. 校驗(yàn)召回結(jié)果 for round in range(2): need_more, refine_query self.grader(question, chunks) if not need_more: break chunks self.retrieve(refine_query, plan) # 4. 生成最終回答 return self.llm.chat(build_prompt(question, chunks))路由決策的prompt我最常用的一種設(shè)計(jì)核心是讓模型從幾個固定選項(xiàng)里選擇一個而不是自由發(fā)揮你要判斷用戶問題的最佳檢索策略?？蛇x策略vector_search默認(rèn)、keyword_search適合查配置信息、專有名詞、fulltext_search適合查長文檔細(xì)節(jié)、multi_search適合復(fù)雜對比問題。請從上述選項(xiàng)中選擇一個輸出JSON形如{strategy: keyword_search, reason: ...}Grader的prompt也很關(guān)鍵它決定多輪檢索是否繼續(xù)我常寫請判斷已有檢索內(nèi)容是否足夠回答用戶問題。如果信息不充分指出缺少什么并給出一個用于補(bǔ)充檢索的查詢詞。輸出JSON{sufficient: true/false, missing: ..., refine_query: ...}這套結(jié)構(gòu)跑通之后效果提升是明顯可感的。但要特別注意Planner和Grader的本質(zhì)是大模型推理它自己也會犯錯——尤其當(dāng)路由選項(xiàng)設(shè)置不合理時比如兩種策略實(shí)際召回的片段高度重合加不加路由幾乎沒有區(qū)別。所以任何路由判斷都要留一個默認(rèn)兜底我一般在路由預(yù)測置信度不高時直接切vector_search而不是讓模型自由發(fā)揮。2.3 隱性成本延遲和Token消耗比你想的更貴Agentic RAG的工程成本不只在代碼實(shí)現(xiàn)上更在線上運(yùn)行時的開銷。每一次路由決策和驗(yàn)證都是一次LLM調(diào)用都會增加延遲。如果多次檢索響應(yīng)時間可能從傳統(tǒng)RAG的2秒漲到8秒以上在面向終端用戶的場景里這個體感差異很大。Token消耗也是重要問題。Agentic RAG的調(diào)用次數(shù)比傳統(tǒng)RAG多每次還有system prompt、歷史記錄、召回片段累計(jì)起來一次完整請求的成本可能是傳統(tǒng)RAG的3到5倍。我的經(jīng)驗(yàn)是給Planner和Grader用更小、更快的模型比如一個7B級別的模型只在最終生成階段用大模型。這樣既能控制成本又不會明顯損失路由判斷質(zhì)量。還有一個值得試的技巧就是給Planner和Grader的結(jié)果加一層緩存對同一問題或高度類似的查詢直接復(fù)用之前的檢索計(jì)劃。3. LLM Wiki知識組織形態(tài)對效果的影響比想象中大3.1 LLM Wiki不是簡單文檔庫而是一種知識網(wǎng)絡(luò)說到LLM Wiki很多人第一反應(yīng)是一個用LLM搭建的wiki系統(tǒng)但這只是表面。在RAG語境下LLM Wiki更深層的價值是一種知識組織方式——把原本扁平化的文檔切塊升級為以“概念”和“實(shí)體”為中心的知識網(wǎng)絡(luò)。我經(jīng)歷過一個項(xiàng)目知識庫里有幾千篇技術(shù)文檔用傳統(tǒng)切分方式建索引之后檢索結(jié)果有一個通病文檔片段本身是相關(guān)的但答非所問。后來拆開分析發(fā)現(xiàn)原因是切分粒度太粗召回單位是“大段落”而答案往往埋在段落的一句話里向量相似度帶著大量無效信息干擾了定位。傳統(tǒng)RAG把知識切成一堆互不關(guān)聯(lián)的碎片檢索時靠“余弦相似度”硬找相似片段本質(zhì)上丟失了文檔結(jié)構(gòu)信息、概念層級信息、以及不同文檔之間的關(guān)聯(lián)。數(shù)據(jù)組織方式?jīng)Q定了檢索質(zhì)量的上限這個問題用“知識的導(dǎo)航地圖”這個類比最好理解文檔倉庫里幾千篇文件沒有目錄、沒有索引、沒有鏈接關(guān)系一個新人進(jìn)去找資料只能掃描。向量檢索相當(dāng)于給了新人一個“語義搜索引擎”能搜到相關(guān)區(qū)域但搜出來的是一堆樓層照片不一定能找到具體房間。LLM Wiki要做的是把資料室改造成一個帶目錄、帶門牌號、帶指路牌的圖書館。3.2 三層知識節(jié)點(diǎn)讓檢索器像人一樣先定位再閱讀在實(shí)操中我傾向于把知識層組織成三層結(jié)構(gòu)摘要節(jié)點(diǎn)、概念節(jié)點(diǎn)、原文片段節(jié)點(diǎn)。總結(jié)一下就是先通過摘要和概念節(jié)點(diǎn)快速縮小范圍再通過指向關(guān)系定位原文中的具體段落。摘要節(jié)點(diǎn)每個核心知識點(diǎn)對應(yīng)一條精煉摘要它可以是一句話或一小段概括某篇文檔或某章內(nèi)容的核心信息。概念節(jié)點(diǎn)這是整個體系的關(guān)鍵庫里的專有名詞、技術(shù)概念、產(chǎn)品名、功能名都作為單獨(dú)的節(jié)點(diǎn)并記錄它在哪里被詳細(xì)解釋、在哪篇文檔里使用過。原文片段節(jié)點(diǎn)保留完整的原始文檔切塊但切分粒度更小盡量控制在300~500字避免一大塊全混在一起。這套三層的設(shè)計(jì)讓檢索路徑變成兩步先用摘要節(jié)點(diǎn)和概念節(jié)點(diǎn)定位相關(guān)主題再沿鏈接去讀取具體的原文片段。我自己的實(shí)現(xiàn)方法并不復(fù)雜構(gòu)建時用LLM給每篇文檔生成摘要然后做一次關(guān)鍵的實(shí)體/概念抽取把概念和文檔片段做成一張關(guān)系表檢索時第一輪還原是召回摘要節(jié)點(diǎn)和概念節(jié)點(diǎn)然后把對應(yīng)片段撈出來再送入生成模型。這個方法在小規(guī)模知識庫上效果提升非常明顯。參數(shù)上我常用的切分策略和選擇理由如下參數(shù)推薦值原因chunk_size300~500字更精確地定位答案避免噪聲過多chunk_overlap50~80字保持段落間語義銜接防止信息斷裂summary節(jié)點(diǎn)數(shù)每文檔1~3條覆蓋全文核心信息又不過度碎片化concept節(jié)點(diǎn)數(shù)按實(shí)體抽取不設(shè)硬性上限概念節(jié)點(diǎn)是導(dǎo)航索引越多路徑越豐富3.3 LLM Wiki要做多少投入才算合理很多人聽說LLM Wiki效果好一上來就想把整個知識庫全量重構(gòu)結(jié)果發(fā)現(xiàn)不僅要做摘要還要抽實(shí)體、建關(guān)聯(lián)工作量巨大。我的建議是不需要一上來就全量重建先在問題最集中、檢索最差的模塊上做試點(diǎn)。比如一個項(xiàng)目知識庫里最常用的是“API參考手冊”。那我就只對API手冊部分做摘要節(jié)點(diǎn)和概念節(jié)點(diǎn)其他部分保持傳統(tǒng)切分。這樣改動范圍小、構(gòu)建成本可控還能直接對比新舊效果。做了之后發(fā)現(xiàn)跟API相關(guān)的問答準(zhǔn)確率提升很明顯用戶明顯感覺回答更準(zhǔn)確了而其他部分沒動也不影響大局之后可以按周分批擴(kuò)展。還有一個小技巧LLM Wiki的構(gòu)建過程本身可以用Agent化處理批量讀取文檔依次生成摘要、抽取實(shí)體、標(biāo)記關(guān)聯(lián)跑一個定時任務(wù)就能慢慢把庫建設(shè)起來。不用手工逐條維護(hù)不過仍需要人為抽檢質(zhì)量的環(huán)節(jié)否則概念節(jié)點(diǎn)會越來越臟。4. Multi-Agent協(xié)作不是堆Agent數(shù)量而是設(shè)計(jì)分工4.1 什么場景真的需要Multi-Agent什么時候不需要Multi-Agent可能是這三條路線里被濫用最多的一個。我一向建議能用單Agent解決的問題絕對不要上Multi-Agent。單Agent最省心通信開銷小邏輯鏈路清晰出bug也好查。那什么場景確實(shí)需要呢我總結(jié)兩個強(qiáng)信號任務(wù)可以被清晰拆解且各步驟之間目標(biāo)差異大或者單Agent的上下文太長導(dǎo)致決策質(zhì)量明顯下降。我實(shí)際驗(yàn)證過一個場景用戶的問題經(jīng)常包含多個子問題比如“對比A、B兩種方法的適用條件再給出C的使用步驟和D的風(fēng)險規(guī)避”。如果全部塞給一個Agent處理模型容易在長上下文里迷失優(yōu)先處理最后一個問題而忽略前面的。拆成“對比Agent”“步驟Agent”“風(fēng)險Agent”三個專職Agent由主控Agent分配查詢內(nèi)容再匯總結(jié)果整體輸出質(zhì)量會高不少。說白了Multi-Agent的價值不是“解決單Agent解決不了的問題”而是在復(fù)雜任務(wù)中通過專業(yè)化分工提升精確度和可控性。一個Agent做所有事就像一個全棧開發(fā)者既要寫前端、又要寫后端、還要管運(yùn)維容易在復(fù)雜場景下出錯分工之后反而各自都更專業(yè)。4.2 主控、路由、執(zhí)行一套清晰的角色拆分模板Multi-Agent系統(tǒng)的核心不是每個子Agent有多聰明而是主控Agent的任務(wù)分解和結(jié)果匯總能力。我把角色模板拆成三類主控Agent負(fù)責(zé)任務(wù)理解、分解、調(diào)度、匯總、路由/檢索Agent負(fù)責(zé)與知識庫、向量庫、API等外部工具交互、評審Agent負(fù)責(zé)對中間結(jié)果做質(zhì)量校驗(yàn)。這個模板的實(shí)用性很強(qiáng)幾乎可以套用到大部分知識問答場景。一個可以復(fù)用的通信協(xié)議案例我通常用結(jié)構(gòu)化JSON作為Agent間的消息格式每個消息包含task_id標(biāo)識任務(wù)、agent_name產(chǎn)生消息的Agent、status進(jìn)行中/完成/失敗、data實(shí)際數(shù)據(jù)、metadata上下文信息。這樣每個Agent只關(guān)心自己消費(fèi)的字段調(diào)試時也能明確追蹤是哪一環(huán)出了問題。任務(wù)分解上常見做法是主控Agent先把用戶問題拆成若干子任務(wù)并為每個子任務(wù)指定執(zhí)行Agent和期望輸出格式。比如{ tasks: [ {task_id: 1, action: compare, target: [A方法, B方法], assignee: compare_agent}, {task_id: 2, action: steps, target: C方法, assignee: howto_agent}, {task_id: 3, action: risks, target: D方法, assignee: risk_agent} ] }匯總階段主控Agent不直接把所有子模塊的原始輸出拼起來而是要求各Agent把結(jié)果壓成“要點(diǎn)證據(jù)”結(jié)構(gòu)主控再把要點(diǎn)按邏輯重新組織成完整回答。這樣最終輸出有邏輯層次而不是幾個模塊輸出堆在一起的大雜燴。4.3 最常見的失控模式與兜底策略Multi-Agent系統(tǒng)的常見問題我在項(xiàng)目里幾乎都踩過。最典型的是子Agent之間互相踢皮球A把任務(wù)轉(zhuǎn)給BB覺得自己沒權(quán)限又轉(zhuǎn)回A來回循環(huán)最后超時——這需要給每個Agent的響應(yīng)范圍做硬性約束不能自由轉(zhuǎn)派任務(wù)任何轉(zhuǎn)派都必須經(jīng)過主控Agent其次是使任務(wù)越拆越細(xì)、越拆越碎本來一個問題三句話能答完拆成五個Agent之后多了一堆中間產(chǎn)物最終答案反而更零碎——這需要在任務(wù)分解時就嚴(yán)格控制子任務(wù)數(shù)量如果不超過三個子問題根本不需要多Agent單Agent足夠。還有一個是共享上下文爆炸——每個Agent都要攜帶完整的聊天記錄和文檔片段token消耗失控需要讓子Agent只接收完成本任務(wù)必要的輸入不傳遞全量上下文相關(guān)的基礎(chǔ)信息統(tǒng)一放在一個共享狀態(tài)區(qū)里按需讀取。我在實(shí)際項(xiàng)目中給主控Agent設(shè)計(jì)過一個兜底指令效果很好“如果你發(fā)現(xiàn)子Agent返回的結(jié)果彼此沖突不要自行取舍把沖突內(nèi)容原樣保留并在最終回答中如實(shí)說明同時標(biāo)注需要用戶確認(rèn)?！边@個兜底讓模型在沖突場景下不會強(qiáng)行編造一致性回答反而更可信。5. 三種架構(gòu)怎么選基于場景的取舍框架5.1 先回答三個問題再選型做技術(shù)選型不要先看哪個架構(gòu)更高級而是先回答三個問題第一我的查詢類型有多少種變化如果用戶問題模式固定傳統(tǒng)RAG用規(guī)則路由就夠了Agentic RAG的意義不大。如果問題類型繁多、經(jīng)常有復(fù)合型問題才需要給檢索做決策能力。第二我的知識庫規(guī)模和組織復(fù)雜程度如何幾百條純文本可以直接向量檢索但幾千篇含大量概念關(guān)聯(lián)的知識文檔不做結(jié)構(gòu)化的知識組織檢索效果很難上去這時候LLM Wiki的收益最大。第三我的任務(wù)是否需要多個不同能力協(xié)作如果一個請求可以被拆成多個子任務(wù)且各子任務(wù)需要不同信息和策略那才考慮Multi-Agent。如果任務(wù)本身鏈?zhǔn)骄€性單Agent夠用。這三個問題會導(dǎo)向完全不同的架構(gòu)路線傳統(tǒng)的“先進(jìn)架構(gòu)優(yōu)先”思路往往造成大量不必要的復(fù)雜度。5.2 一張選型對照表按需取用架構(gòu)最適合的場景主要成本典型延遲維護(hù)復(fù)雜度推薦前提傳統(tǒng)RAG簡單知識問答、小規(guī)模庫、問題模式固定最低1~2秒低只作為baselineAgentic RAG問題類型多樣、需要多策略檢索和校驗(yàn)中高多次LLM調(diào)用3~8秒中傳統(tǒng)RAG效果明顯不達(dá)預(yù)期時LLM Wiki知識庫規(guī)模大、概念關(guān)聯(lián)復(fù)雜、要求精準(zhǔn)中構(gòu)建階段成本高2~4秒中檢索結(jié)果噪聲大、片段定位不準(zhǔn)時Multi-Agent任務(wù)復(fù)雜、可拆解、各步驟目標(biāo)差異明顯高通信和token成本高5~15秒高單一Agent輸出質(zhì)量不達(dá)預(yù)期時這張表我想強(qiáng)調(diào)一點(diǎn)這些架構(gòu)不是排他關(guān)系。我做過的一個項(xiàng)目最終形態(tài)是底層用LLM Wiki組織知識上層用Agentic RAG做檢索路由再疊加一個輕量Multi-Agent做復(fù)雜任務(wù)的拆解與匯總。三者是層次互補(bǔ)的關(guān)系不矛盾。選擇順序上我的經(jīng)驗(yàn)是先低成本優(yōu)化傳統(tǒng)RAG調(diào)切分、調(diào)embedding模型、調(diào)召回策略仍然不夠時上Agentic RAG同時評估是否需要補(bǔ)知識層結(jié)構(gòu)最后才考慮Multi-Agent。換句話說復(fù)雜度應(yīng)該像擠牙膏一樣逐步釋放而不是一次上全套。6. 實(shí)操過程中的常見問題與排查經(jīng)驗(yàn)6.1 檢索結(jié)果不理想時的排查順序很多項(xiàng)目出問題之后第一反應(yīng)是調(diào)prompt或者換大模型但我實(shí)測下來檢索階段的問題占了大多數(shù)。排查的時候我習(xí)慣按這個順序來先查召回內(nèi)容是否切題直接打印每次召回的top-3片段看一眼如果片段本身就跑偏生成結(jié)果一定跑偏這時候該修索引和知識組織再查路由判斷是否準(zhǔn)確確認(rèn)模型選用的檢索策略是否符合問題類型必要時把路由log加進(jìn)監(jiān)控最后才查生成階段的問題看prompt是否把信息用錯了、是否存在幻覺。實(shí)際操作中我強(qiáng)烈建議所有稍微復(fù)雜點(diǎn)的RAG項(xiàng)目都要加一個日志層把檢索計(jì)劃、召回段落、打分結(jié)果全部打出來。這個日志在調(diào)試時能幫你節(jié)省大量時間——很多時候一種錯誤的答案來自一個錯誤的檢索計(jì)劃而不模型本身的推理問題。6.2 Token開銷失控的治理方案復(fù)雜架構(gòu)帶來的一個直接結(jié)果就是Token成本上升。我治理Token開銷的辦法一是給子模塊用不同等級的模型路由、摘要、校驗(yàn)這些非生成任務(wù)完全可以交給便宜且快速的小模型只有最終面向用戶的答案才用大模型生成二是對中間結(jié)果做壓縮Agent間傳遞的內(nèi)容只保留關(guān)鍵結(jié)論和證據(jù)不傳遞整篇文檔三是控制檢索片段的數(shù)量Agentic RAG場景下每輪檢索維持top-3就夠了比傳統(tǒng)RAG的top-5到top-8少很多因?yàn)锳gent本身可以多次檢索第一次召回結(jié)果差后面可以通過精化的查詢詞再補(bǔ)召回沒必要在開始時貪多。我還專門設(shè)計(jì)過一個“是否值得多輪檢索”的token預(yù)算策略設(shè)定一個閾值如果Grader連續(xù)兩輪都提示信息不足就停止繼續(xù)檢索并且如實(shí)告訴用戶“當(dāng)前知識庫覆蓋不夠”而不是無限循環(huán)燒Token。6.3 警惕過度設(shè)計(jì)復(fù)雜架構(gòu)什么時候該叫停復(fù)雜架構(gòu)是好東西但最容易出現(xiàn)的錯誤是“為了復(fù)雜而復(fù)雜”。我看過一個項(xiàng)目團(tuán)隊(duì)花了兩周時間上了Multi-Agent框架每個Agent套了一個角色prompt結(jié)果用戶測試時發(fā)現(xiàn)答案和單Agent沒有本質(zhì)區(qū)別反而響應(yīng)慢了好幾秒。這類問題背后的原因往往是任務(wù)本身不夠復(fù)雜、各Agent分工沒有真正區(qū)分開、或者底層知識庫質(zhì)量太差——架構(gòu)再復(fù)雜也彌補(bǔ)不了知識庫本身臟亂差的問題。還有一個信號值得警惕如果團(tuán)隊(duì)里只有一到兩個工程師維護(hù)系統(tǒng)卻要撐起一個包含5個以上Agent的架構(gòu)成本會非常高。這種時候應(yīng)該優(yōu)先做減法把非核心鏈路用最簡單的方式實(shí)現(xiàn)只留下真正提升效果的那一環(huán)。我自己在幾個項(xiàng)目里來回試出來的一個體會是復(fù)雜架構(gòu)的收益曲線并不是線性增加的它早期會有明顯提升中期邊際收益遞減后期可能因?yàn)榫S護(hù)成本過高而出現(xiàn)負(fù)收益。找到那條曲線的拐點(diǎn)就是工程上最舒服的狀態(tài)。從實(shí)用角度看這篇內(nèi)容最值得帶走的一句話是先在能直接看到效果的地方做加法而不是為了架構(gòu)的完整性做加法。Agentic RAG幫你把檢索做聰明LLM Wiki幫你把知識理順Multi-Agent幫你把任務(wù)拆得恰到好處但它的前提是你確實(shí)遇到了對應(yīng)的卡點(diǎn)。沒卡點(diǎn)就不要動。我之前一直有個習(xí)慣做完一輪架構(gòu)升級之后會要求自己同時回答兩個問題效果到底提升了多少、成本增加了多少。如果提升不顯著哪怕架構(gòu)看起來更像“下一代”也會立刻回滾。畢竟對用戶來說他感受到的是回答是否準(zhǔn)確、是否快、是否穩(wěn)定而不是你用了多少個Agent。