做自研RAG項(xiàng)目最怕的不是寫代碼而是把彎路完整地走一遍。文檔解析、分塊、向量化、檢索、重排、提示詞裝配任何一環(huán)拍腦袋最后都要在問(wèn)答效果上還債。我自己帶團(tuán)隊(duì)做RAG落地時(shí)踩過(guò)一輪坑之后才意識(shí)到與其閉門造車不如把市面上成熟的開源RAG產(chǎn)品當(dāng)成免費(fèi)教材一件件逆向拆解再拼出適合自己業(yè)務(wù)的自研底座。這篇內(nèi)容想做的事情很簡(jiǎn)單從六款有代表性的開源RAG產(chǎn)品里逐層抽出值得復(fù)用的設(shè)計(jì)最終匯成一套可直接參考的自研RAG藍(lán)圖。不管你是剛接手RAG相關(guān)需求、團(tuán)隊(duì)里正在選型還是自研到一半發(fā)現(xiàn)效果不對(duì)這篇都能給你一個(gè)相對(duì)完整的參照系。1. 先回答一個(gè)核心問(wèn)題為什么自研RAG要先逆向開源產(chǎn)品1.1 自研RAG最常見(jiàn)的三種彎路先說(shuō)我在實(shí)際項(xiàng)目里看到的三類典型失敗路徑。第一類是重檢索、輕前處理。團(tuán)隊(duì)一上來(lái)就調(diào)Embedding模型、換向量庫(kù)、優(yōu)化召回策略但文檔根本沒(méi)處理好。拿到的PDF是掃描件OCR沒(méi)做表格被當(dāng)成普通文字切碎章節(jié)標(biāo)題和正文混在一個(gè)chunk里。結(jié)果檢索階段無(wú)論怎么調(diào)召回的內(nèi)容都是碎片LLM生成答案時(shí)自然只能瞎編。這類項(xiàng)目通常會(huì)在上線后一到兩周被業(yè)務(wù)方用幾個(gè)常識(shí)問(wèn)題問(wèn)倒。第二類是重實(shí)現(xiàn)、輕評(píng)估。代碼寫得很嗨召回接口、重排服務(wù)、知識(shí)庫(kù)管理后臺(tái)全都有但沒(méi)有一套評(píng)估集。上線之后怎么判斷效果變好還是變差全靠感覺(jué)。RAG這個(gè)系統(tǒng)鏈路長(zhǎng)任何一環(huán)微調(diào)都可能讓另一半更差沒(méi)有指標(biāo)幾乎是盲人摸象。第三類是重功能、輕成本。把各家開源產(chǎn)品的功能全部縫合到自己系統(tǒng)里實(shí)體抽取、意圖識(shí)別、多輪改寫、圖譜構(gòu)建全都上。功能列表很漂亮但每個(gè)模塊都在增加延遲和算力成本最后用戶問(wèn)一個(gè)問(wèn)題要等十幾秒而且復(fù)雜模塊之間的互相干擾很難排查。這三種彎路的共同根源是缺少一個(gè)從全局視角出發(fā)的、別人已經(jīng)驗(yàn)證過(guò)的參考架構(gòu)。而開源RAG產(chǎn)品恰好提供了這個(gè)參考。1.2 逆向工程在軟件領(lǐng)域?yàn)槭裁纯尚心嫦蚬こ讨栽赗AG領(lǐng)域尤其有效是因?yàn)镽AG本身并不是一個(gè)全新算法而是多個(gè)成熟技術(shù)的工程化組合。它涉及解析、存儲(chǔ)、檢索、排序、生成、評(píng)估等多個(gè)環(huán)節(jié)。每個(gè)環(huán)節(jié)單獨(dú)看都不神秘但組合起來(lái)卻有大量工程細(xì)節(jié)。這些細(xì)節(jié)論文里通常不會(huì)寫官方文檔也往往一帶而過(guò)——比如分塊時(shí)保留文檔原始層級(jí)比如查詢改寫要維護(hù)一個(gè)獨(dú)立于知識(shí)庫(kù)的提示詞體系比如重排模型的得分不能直接和相似度閾值比較。但開源產(chǎn)品的代碼里全是答案它們是開發(fā)團(tuán)隊(duì)用真實(shí)業(yè)務(wù)數(shù)據(jù)和線上反饋一點(diǎn)點(diǎn)調(diào)出來(lái)的。所以從六款開源產(chǎn)品里逆向出公共骨架本質(zhì)上是在吸收一群資深工程師踩坑后的沉淀。這比從零開始自己摸索要高效得多。2. 六款開源產(chǎn)品怎么選它們的架構(gòu)差異在哪里2.1 選樣標(biāo)準(zhǔn)覆蓋完整鏈路而不是只看名氣選這六款不是因?yàn)樗鼈冏罨鸲且驗(yàn)樗鼈兏髯越鉀Q了RAG鏈路里一個(gè)關(guān)鍵卡點(diǎn)并且互相之間有明顯差異。我的篩選標(biāo)準(zhǔn)有三個(gè)完整覆蓋RAG關(guān)鍵鏈路不是只有其中一兩環(huán)技術(shù)路線有差異能從不同角度提供啟發(fā)社區(qū)活躍、有大量真實(shí)部署案例避免紙面產(chǎn)品。我選了RAGFlow、Dify、FastGPT、QAnything、MaxKB、LightRAG/GraphRAG這兩個(gè)圖譜增強(qiáng)路線其中LightRAG和GraphRAG歸為一類來(lái)講因?yàn)樗鼈兘鉀Q的問(wèn)題相同思路也相近。加上它們剛好是六個(gè)維度。2.2 五條不同的技術(shù)路線這六類產(chǎn)品背后的路線差異我用一張表來(lái)總結(jié)產(chǎn)品主打定位核心差異化設(shè)計(jì)最值得自研借鑒的點(diǎn)RAGFlow深度文檔理解版面分析結(jié)構(gòu)化解析后再分塊文檔解析的完整流水線DifyLLM應(yīng)用平臺(tái)知識(shí)庫(kù)管理可視化編排API化檢索規(guī)則與知識(shí)庫(kù)生命周期治理FastGPT知識(shí)庫(kù)問(wèn)答問(wèn)題分類知識(shí)庫(kù)路由清晰引用讓路由環(huán)節(jié)獨(dú)立于生成QAnything兩階段檢索離線向量召回在線重排重排模型作為獨(dú)立服務(wù)層MaxKB輕量可嵌入式RAG一鍵部署、函數(shù)調(diào)用、嵌入業(yè)務(wù)系統(tǒng)輕量化交付與對(duì)話內(nèi)檢索GraphRAG/LightRAG知識(shí)圖譜增強(qiáng)LLM抽取實(shí)體關(guān)系社群社區(qū)化檢索全局性問(wèn)題的圖譜方案這五條路線的本質(zhì)差別在于對(duì)文檔上下文的組織方式不同。RAGFlow和MaxKB更重視文檔進(jìn)來(lái)之后怎么處理Dify更重視知識(shí)庫(kù)和上層應(yīng)用怎么銜接QAnything更重視召回之后怎么精排圖譜方案則走了一條完全不同的路——不再依賴向量相似度而是用實(shí)體關(guān)系網(wǎng)絡(luò)來(lái)做推理。這提醒我們自研時(shí)不要一開始就鎖定某一種路線而是先想清楚自己業(yè)務(wù)里的瓶頸在哪一環(huán)再去對(duì)號(hào)入座。3. 逐款拆解每一款產(chǎn)品最值得偷師的模塊3.1 RAGFlow文檔解析的盡頭是版面理解RAGFlow給我最大的啟發(fā)是它把文檔解析從預(yù)處理步驟提升到了核心能力的高度。大多數(shù)開源產(chǎn)品對(duì)PDF的處理還停留在按頁(yè)抽文字、按字符切分而RAGFlow在進(jìn)入分塊前先做了一套完整的版面分析識(shí)別標(biāo)題層級(jí)、段落邊界、表格區(qū)域、圖片位置還原文檔的原始閱讀順序。這套設(shè)計(jì)對(duì)自研的啟發(fā)有兩層第一解析結(jié)果的粒度決定了后續(xù)檢索質(zhì)量的上限。如果文檔解析時(shí)就把表格硬拆成一行行散文本那后續(xù)分塊和向量化做得再好檢索出來(lái)的也是斷裂內(nèi)容。RAGFlow的做法是表格先以結(jié)構(gòu)化單元Markdown或HTML保存正文按語(yǔ)義段落保存圖片通過(guò)視覺(jué)模型生成描述文字再統(tǒng)一進(jìn)入切塊流程。第二版面分析可以大幅提升引用溯源的準(zhǔn)確性。當(dāng)用戶問(wèn)這個(gè)數(shù)據(jù)來(lái)自哪個(gè)章節(jié)RAGFlow能定位到原始版面區(qū)塊而不是只拋出一段拼接文本。自研RAG如果不想一上來(lái)就做完整的版面分析可以先從保留標(biāo)題路徑開始——讓切出來(lái)的每個(gè)chunk都帶著章、節(jié)、小節(jié)的路徑信息這在召回展示時(shí)幫助很大。3.2 Dify知識(shí)庫(kù)管理和檢索編排的樣板Dify給我的感覺(jué)是平臺(tái)味最重的一個(gè)。它不只是RAG引擎更是一套圍繞知識(shí)庫(kù)的管理和編排層。它把知識(shí)庫(kù)生命周期的各個(gè)環(huán)節(jié)都做成了可配置項(xiàng)數(shù)據(jù)導(dǎo)入方式、分段規(guī)則、索引方式、檢索設(shè)置、召回策略、重排模型。這里有兩個(gè)點(diǎn)對(duì)自研特別有參考價(jià)值。一是檢索設(shè)置的精細(xì)化。同一套文檔不同場(chǎng)景對(duì)檢索的容忍度完全不同。業(yè)務(wù)問(wèn)答里用戶直接要答案召回精度優(yōu)先知識(shí)庫(kù)內(nèi)部檢索管理員想盡可能多地找到相關(guān)內(nèi)容召回率優(yōu)先。Dify把這些差異做成了知識(shí)庫(kù)級(jí)別和檢索參數(shù)配置top_k大小、相似度閾值、Score閾值、召回策略等。自研時(shí)把這些參數(shù)做成系統(tǒng)可配置項(xiàng)而不是寫死在代碼里能省掉大量后續(xù)調(diào)優(yōu)溝通成本。二是分段Chunking規(guī)則的半自動(dòng)化。Dify的系統(tǒng)默認(rèn)分段并不復(fù)雜但提供了很強(qiáng)的自定義空間包括文本分段標(biāo)識(shí)符、最大分段長(zhǎng)度、重疊長(zhǎng)度還支持父子分塊模式——父塊負(fù)責(zé)上下文語(yǔ)義子塊負(fù)責(zé)精確匹配。這讓知識(shí)庫(kù)管理員可以根據(jù)文檔類型去微調(diào)而不需要?jiǎng)哟a。Dify的另一個(gè)可借鑒點(diǎn)是它的知識(shí)庫(kù)隔離思路。多個(gè)知識(shí)庫(kù)之間可以設(shè)置獨(dú)立權(quán)限和獨(dú)立檢索范圍問(wèn)答時(shí)可以指定檢索某一個(gè)或某幾個(gè)。這種設(shè)計(jì)在自研系統(tǒng)里很容易被忽略——往往一個(gè)庫(kù)打天下后續(xù)權(quán)限、合規(guī)問(wèn)題全冒出來(lái)。3.3 FastGPT問(wèn)題分類與知識(shí)庫(kù)路由FastGPT這個(gè)名字暗示了它的路線快、直接、以問(wèn)答為目標(biāo)。它最打動(dòng)我的功能是問(wèn)題分類器和知識(shí)庫(kù)路由。RAG問(wèn)答系統(tǒng)里有一種常見(jiàn)場(chǎng)景用戶的問(wèn)題根本不需要走向量檢索。比如用戶問(wèn)的是你們支持哪些格式這個(gè)問(wèn)題的答案可能在系統(tǒng)配置里再比如用戶問(wèn)的是你是誰(shuí)這屬于閑聊還有一些流程類問(wèn)題需要走工作流而不是查知識(shí)庫(kù)。FastGPT通過(guò)一個(gè)前置分類模塊把問(wèn)題先做意圖分流再?zèng)Q定是否觸發(fā)知識(shí)庫(kù)檢索以及檢索哪個(gè)知識(shí)庫(kù)。這個(gè)設(shè)計(jì)解決了一個(gè)被很多人忽略的問(wèn)題不是所有問(wèn)題都適合向量檢索。對(duì)于一個(gè)垂直業(yè)務(wù)的自研RAG來(lái)說(shuō)問(wèn)題路由的價(jià)值比想象中大得多。它可以避免把閑聊問(wèn)題送進(jìn)檢索鏈路省掉無(wú)效計(jì)算把不同領(lǐng)域的問(wèn)題路由到對(duì)應(yīng)知識(shí)庫(kù)縮小檢索范圍提升精度為兜底回復(fù)留出空間當(dāng)所有知識(shí)庫(kù)的置信度都低時(shí)走人工轉(zhuǎn)接。自研時(shí)不必做一個(gè)獨(dú)立的模型來(lái)做路由。一個(gè)輕量分類提示詞讓LLM判斷問(wèn)題類型并輸出JSON結(jié)構(gòu)就足夠覆蓋大多數(shù)場(chǎng)景。關(guān)鍵是把這個(gè)環(huán)節(jié)放在檢索之前并讓它可配置。3.4 QAnything把重排當(dāng)一等公民QAnything是網(wǎng)易有道開源的項(xiàng)目。它的核心思路是兩階段檢索第一階段同時(shí)使用向量檢索和BM25關(guān)鍵詞檢索做多路召回第二階段用一個(gè)專門的Rerank模型對(duì)召回結(jié)果統(tǒng)一打分排序。這個(gè)設(shè)計(jì)在RAG產(chǎn)品里不算稀奇但QAnything把它做到了極致?；乜礃I(yè)界實(shí)踐許多自研RAG項(xiàng)目把重排當(dāng)成可選項(xiàng)甚至上線之初完全不加重排。這會(huì)帶來(lái)一個(gè)明顯問(wèn)題向量檢索的Top-K結(jié)果和用戶真正相關(guān)的尾部?jī)?nèi)容之間經(jīng)常存在錯(cuò)位。縮小chunk可以緩解但會(huì)引入更多的噪音chunk單純加大Top-K又會(huì)讓生成階段返回太多無(wú)關(guān)內(nèi)容擠占上下文窗口。QAnything把重排做成了標(biāo)準(zhǔn)服務(wù)并配套了雙向的Embedding和Rerank模型其中最值得借鑒的是召回重排的指標(biāo)分工召回階段看召回率盡量別漏重排階段看精度把最相關(guān)的內(nèi)容頂?shù)角懊?。自研鏈路里重排并不一定要自研模型從HuggingFace上選一個(gè)合適的Rerank模型比如BGE系列封裝成獨(dú)立服務(wù)就能獲得極大的效果提升。3.5 MaxKB輕量嵌入與對(duì)話內(nèi)檢索MaxKB走的是另一條路線把RAG能力做得足夠輕、足夠易嵌入讓它可以作為模塊被現(xiàn)有業(yè)務(wù)系統(tǒng)快速調(diào)用。它的默認(rèn)架構(gòu)不依賴龐大組件支持一鍵部署同時(shí)提供了函數(shù)調(diào)用能力和對(duì)話流程編排能力。對(duì)自研團(tuán)隊(duì)的啟發(fā)是邊界意識(shí)。很多自研項(xiàng)目容易把系統(tǒng)越做越重——為了支持某個(gè)邊緣功能拆出一個(gè)獨(dú)立服務(wù)然后這個(gè)服務(wù)又需要額外運(yùn)維。MaxKB的克制提醒我們RAG核心鏈路之外的功能能通過(guò)配置、函數(shù)、編排解決的問(wèn)題盡量不要做成核心模塊。MaxKB的對(duì)話內(nèi)檢索也很有意思。它不是一次性把知識(shí)庫(kù)結(jié)果全塞進(jìn)上下文而是允許在多輪對(duì)話中動(dòng)態(tài)追加檢索。這對(duì)應(yīng)了真實(shí)場(chǎng)景里用戶逐步明確需求的過(guò)程——第一輪問(wèn)你們產(chǎn)品的定價(jià)第二輪追問(wèn)那企業(yè)版呢。如果每次都是全量重檢索不僅成本高而且容易丟失對(duì)話焦點(diǎn)。3.6 GraphRAG與LightRAG讓RAG擁有全局視野圖譜方案針對(duì)的是普通向量RAG的一個(gè)硬傷局部強(qiáng)、全局弱。當(dāng)你問(wèn)這幾類產(chǎn)品之間的關(guān)聯(lián)是什么或如果A不成立B和C會(huì)怎樣這類問(wèn)題上純向量檢索幾乎無(wú)能為力因?yàn)榇鸢覆徊卦谀骋欢挝谋纠锒且ㄟ^(guò)多段知識(shí)之間的連接關(guān)系推理出來(lái)。GraphRAG的路線是用LLM從文檔中抽取實(shí)體和關(guān)系構(gòu)建知識(shí)圖譜再做社區(qū)聚類和社區(qū)摘要回答問(wèn)題時(shí)先在實(shí)體網(wǎng)絡(luò)上做局部搜索再結(jié)合社區(qū)摘要做全局推理。LightRAG在此基礎(chǔ)上做了簡(jiǎn)化通過(guò)局部全局雙層檢索用更低的算力成本拿到類似的效果。從自研角度看圖譜不是用來(lái)替代向量檢索的而是用來(lái)補(bǔ)位關(guān)系密集型問(wèn)題。它適合的組織結(jié)構(gòu)大致是知識(shí)庫(kù)內(nèi)容之間有強(qiáng)關(guān)聯(lián)、問(wèn)題普遍涉及多實(shí)體比較、需要推理鏈。如果只是做簡(jiǎn)單的FAQ問(wèn)答圖譜帶來(lái)的額外成本和復(fù)雜性可能不值得。更務(wù)實(shí)的做法是向量為主、圖譜為輔的融合架構(gòu)先向量召回一批相關(guān)內(nèi)容再用圖譜補(bǔ)充實(shí)體關(guān)系層面的信息最后一起交給LLM生成。這樣不會(huì)為了圖譜而犧牲時(shí)效性和簡(jiǎn)潔性。4. 六款產(chǎn)品背后的公共骨架自研RAG的五層結(jié)構(gòu)拆完六款產(chǎn)品我發(fā)現(xiàn)它們雖然形態(tài)各異但骨架高度一致。這個(gè)公共骨架可以濃縮成五層結(jié)構(gòu)這也是自研RAG時(shí)值得照抄的部分。4.1 文檔接入層解析、清洗、結(jié)構(gòu)化、分塊文檔接入層的目標(biāo)是把原始文件變成干凈的、語(yǔ)義完整的文本單元。它由四個(gè)步驟組成解析根據(jù)文件類型選擇不同解析器。PDF要處理掃描件識(shí)別與版面分析Word/HTML要提取正文和結(jié)構(gòu)表格要按行列結(jié)構(gòu)保存而不要拍平。清洗去掉頁(yè)眉頁(yè)腳、目錄、重復(fù)文案、無(wú)意義空白、水印文本。頁(yè)眉頁(yè)腳如果不去掉會(huì)變成每個(gè)chunk都帶一段重復(fù)噪音嚴(yán)重干擾向量相似度。結(jié)構(gòu)化保留標(biāo)題路徑、章節(jié)層級(jí)、表格Markdown表示、圖片描述。這步?jīng)Q定了后續(xù)引用溯源能力。分塊在結(jié)構(gòu)化基礎(chǔ)上按語(yǔ)義邊界切塊設(shè)置合適的分塊大小和重疊區(qū)間。父塊保存上下文子塊承擔(dān)精確匹配。這層的質(zhì)量基本決定了整個(gè)系統(tǒng)的上限。RAGFlow、Dify、FastGPT都在這層投入了大量工程但它們的實(shí)現(xiàn)思路可以各自借鑒。自研時(shí)可以先用成熟解析器比如Unstructured、PyMuPDF、Tika搭建流水線不要糾結(jié)于自研解析核心。4.2 索引層稠密向量稀疏關(guān)鍵詞的混合索引索引層負(fù)責(zé)把chunk變成可檢索的結(jié)構(gòu)。公共骨架里幾乎所有產(chǎn)品都在用混合索引而不是單純的向量索引。稠密向量索引chunk文本經(jīng)過(guò)Embedding模型轉(zhuǎn)成向量在向量數(shù)據(jù)庫(kù)里按相似度檢索。負(fù)責(zé)語(yǔ)義級(jí)召回。稀疏關(guān)鍵詞索引用BM25這類算法按詞頻檢索。負(fù)責(zé)精確關(guān)鍵詞召回尤其適用于人名、產(chǎn)品型號(hào)、特殊代碼等向量模型覆蓋不好的場(chǎng)景。自研時(shí)落地方案很多Elasticsearch既有BM25又有向量檢索能力Qdrant、Milvus可以搭配外置BM25服務(wù)最簡(jiǎn)單的方案是先用SQLite一個(gè)向量庫(kù)一個(gè)倒排索引把鏈路跑通。關(guān)鍵不是選哪個(gè)庫(kù)而是兩條召回路徑必須都存在最終的召回結(jié)果要合并、去重、重排。4.3 檢索層多路召回、查詢改寫與重排檢索層是六款產(chǎn)品差異最大的地方之一但思路的一致性很高不能讓第一次向量檢索的結(jié)果直接進(jìn)入生成階段。標(biāo)準(zhǔn)做法可以總結(jié)為三步查詢改寫用戶的原始問(wèn)題往往口語(yǔ)化、有指代、缺少上下文。LightRAG和Dify都有類似的查詢改寫機(jī)制——先把問(wèn)題擴(kuò)充成多組檢索詞同時(shí)保留原始問(wèn)題。比如用戶問(wèn)它的性能怎么樣需要先想辦法確認(rèn)它指代哪個(gè)產(chǎn)品再展開檢索。多路召回向量檢索、BM25關(guān)鍵詞檢索、圖譜檢索并行或串聯(lián)進(jìn)行每路召回Top-N然后合并。重排用交叉編碼器模型對(duì)合并的候選重新打分。交叉編碼器的精度高于向量相似度但速度慢只適合在候選集上做精排。一個(gè)可以立刻用的查詢改寫提示詞模板我放在下面這也是我在項(xiàng)目里實(shí)際用過(guò)的你是檢索詞改寫助手。根據(jù)用戶問(wèn)題和對(duì)話歷史生成最多三個(gè)獨(dú)立的檢索詞。 要求檢索詞面向知識(shí)庫(kù)檢索系統(tǒng)必須具體、完整、包含關(guān)鍵實(shí)體名稱。 輸出格式JSON數(shù)組如[檢索詞1,檢索詞2,檢索詞3]。 用戶問(wèn)題{question} 對(duì)話歷史{history}4.4 生成層上下文窗口管理、提示詞模板與引用溯源生成層決定了檢索出來(lái)的內(nèi)容是否能被正確使用。這里有幾個(gè)常見(jiàn)的坑把整個(gè)檢索結(jié)果一股腦塞給LLM不顧上下文窗口。正確做法是設(shè)置檢索結(jié)果的最大字?jǐn)?shù)占比保留給LLM推理的空間。比如限制最終進(jìn)入上下文的檢索片段不超過(guò)1500字超出部分寧可截?cái)唷Ｌ崾驹~模板太簡(jiǎn)單只寫根據(jù)以下內(nèi)容回答。效果更好的模板會(huì)明確要求優(yōu)先使用檢索內(nèi)容不編造信息不足時(shí)明確回答不知道引用的序號(hào)必須與檢索片段對(duì)應(yīng)。忘記引用溯源。用戶使用RAG產(chǎn)品時(shí)最需要的東西是他能回去翻原文。在生成結(jié)果時(shí)帶上引用序號(hào)并最終映射到原文頁(yè)和具體段落這個(gè)能力是所有評(píng)測(cè)里用戶滿意度最高的一個(gè)。4.5 評(píng)估優(yōu)化層離線指標(biāo)與線上反饋閉環(huán)最后一個(gè)公共模塊是評(píng)估。Dify、FastGPT都有相對(duì)完整的調(diào)試和質(zhì)檢界面QAnything也有評(píng)測(cè)報(bào)告模塊。真正讓我把它當(dāng)成必做項(xiàng)的是RAG系統(tǒng)在迭代中的特征任何一次修改效果都可能朝不同方向漂移離線不能評(píng)估就完全沒(méi)法迭代。做評(píng)估可以分兩步起步第一步做一套低成本人工評(píng)估集。選50-100條真實(shí)問(wèn)題標(biāo)注標(biāo)準(zhǔn)答案、支持性引用文檔、正確回答把忠實(shí)度、相關(guān)性、答案完整性三個(gè)維度做成打分表。第二步接入RAGAS這類開源評(píng)估框架讓LLM充當(dāng)裁判對(duì)回答質(zhì)量做自動(dòng)化評(píng)估。RAGAS提供了Faithfulness、Answer Relevancy、Context Precision等指標(biāo)可以直接對(duì)測(cè)試集批量評(píng)估。評(píng)估不是上線前一次性的動(dòng)作而是要固化在知識(shí)庫(kù)更新和檢索參數(shù)調(diào)優(yōu)的全流程里。沒(méi)有評(píng)估集后面所有優(yōu)化都像在黑夜里調(diào)音量。5. 逆向成果落地一套可復(fù)用的自研RAG藍(lán)圖5.1 分層架構(gòu)與數(shù)據(jù)流設(shè)計(jì)我基于上面五層結(jié)構(gòu)整理出一個(gè)較完整的自研RAG分層架構(gòu)。這里盡量保持簡(jiǎn)單強(qiáng)調(diào)可落地性。接入層文件上傳 → 解析 → 清洗 → 結(jié)構(gòu)化 → 分塊 ↓ 索引層Embedding向量化 ? BM25倒排索引 → 寫入向量庫(kù)/索引庫(kù) ↓ 檢索層查詢改寫 → 多路召回 → 合并去重 → 重排 ↓ 生成層上下文組裝 → 提示詞模板 → LLM生成 → 引用溯源 ↓ 應(yīng)用層問(wèn)答接口 → 管理后臺(tái) → 反饋收集 → 評(píng)估閉環(huán)各層之間通過(guò)標(biāo)準(zhǔn)接口連接接入層輸出統(tǒng)一的文檔單元對(duì)象包含內(nèi)容、標(biāo)題路徑、元數(shù)據(jù)和分塊關(guān)系檢索層輸出帶評(píng)分和來(lái)源的候選片段生成層只消費(fèi)候選片段和提示詞參數(shù)。這種數(shù)據(jù)流設(shè)計(jì)有兩大好處每一層可以由不同組件實(shí)現(xiàn)后續(xù)替換成本低。今天用PostgreSQL的pgvector明天換Qdrant不需要?jiǎng)悠渌麑?。每一層可以?dú)立驗(yàn)證。接入層可以單獨(dú)測(cè)試某一個(gè)PDF的切塊質(zhì)量檢索層可以單獨(dú)壓測(cè)召回率生成層可以單獨(dú)評(píng)測(cè)回答忠實(shí)度。5.2 組件選型對(duì)照自研與替換的邊界組件選型是自研團(tuán)隊(duì)每天都會(huì)面臨的問(wèn)題。我按踩過(guò)的坑給一份比較務(wù)實(shí)的選型對(duì)照表模塊可選方案自研邊界建議文檔解析PyMuPDF、Unstructured、Tika、RAGFlow的解析引擎優(yōu)先用現(xiàn)成庫(kù)只有在特定文檔格式合同掃描件、圖紙等時(shí)才自研專用解析器Embedding模型BGE-M3、Qwen-Embedding、OpenAI text-embedding-3先跑內(nèi)置測(cè)試集對(duì)比不要只看MTEB榜單分?jǐn)?shù)向量數(shù)據(jù)庫(kù)Qdrant、Milvus、pgvector、Chroma數(shù)據(jù)量小于百萬(wàn)級(jí)時(shí)pgvector或Chroma足夠不必引入分布式數(shù)據(jù)庫(kù)稀疏檢索Elasticsearch、Typesense、自建倒排索引中小知識(shí)庫(kù)可以直接用SQLite FTS5成本極低重排模型BGE-Reranker、Cohere Rerank封裝成獨(dú)立HTTP服務(wù)方便替換模型版本LLM本地Ollama部署開源模型或調(diào)用商業(yè)API先跑通鏈路再優(yōu)化模型選擇避免一開始被模型選型拖住編排框架LangChain、LlamaIndex或純手寫純Python實(shí)現(xiàn)對(duì)鏈路把控更穩(wěn)框架只用來(lái)做膠水很多人會(huì)在選型上糾結(jié)很久。我的經(jīng)驗(yàn)是選型的核心不是哪個(gè)最好而是替換成本夠不夠低。只要接口統(tǒng)一先隨便選一個(gè)跑通再根據(jù)評(píng)測(cè)結(jié)果替換才是最快路線。5.3 最小可用版本的實(shí)現(xiàn)路線如果從零開始做一個(gè)自研RAG的MVP版我會(huì)按這個(gè)順序推進(jìn)先用Python腳本接入開源解析庫(kù)實(shí)現(xiàn)PDF/Word/HTML → 清洗 → 遞歸字符分塊的流水線。分塊參數(shù)先用經(jīng)驗(yàn)值500字左右重疊100字。用BGE-M3生成向量寫入pgvector或Chroma同時(shí)用SQLite FTS5存一遍原文關(guān)鍵詞索引。實(shí)現(xiàn)一個(gè)檢索接口改寫查詢 → 向量召回Top-20 → BM25召回Top-20 → 合并去重 → 用BGE-Reranker重排取Top-5。寫一個(gè)生成接口把Top-5片段按提示詞模板發(fā)給LLM輸出時(shí)以[1]-[5]標(biāo)注引用序號(hào)。用RAGAS框架搭建離線評(píng)測(cè)導(dǎo)入50-100條業(yè)務(wù)問(wèn)答跑基準(zhǔn)效果。再根據(jù)評(píng)測(cè)結(jié)果回頭調(diào)分塊策略、召回?cái)?shù)量、提示詞。按這個(gè)順序走通常兩周內(nèi)就能跑出一個(gè)效果初步可用的RAG基礎(chǔ)版。如果團(tuán)隊(duì)里有人之前完全沒(méi)接觸過(guò)RAG這個(gè)MVP過(guò)程本身就是最好的學(xué)習(xí)路徑。6. 自研落地必須跨過(guò)的四個(gè)實(shí)操坑6.1 分塊大小該定多少?gòu)腞AG知識(shí)庫(kù)談起的參數(shù)調(diào)優(yōu)在看了大量開源項(xiàng)目的討論和實(shí)際案例后我可以說(shuō)根本不存在一個(gè)適用于所有場(chǎng)景的分塊大小。常見(jiàn)建議從200到800字都有關(guān)鍵是看你的文檔類型和用戶問(wèn)題的特點(diǎn)。如果文檔是產(chǎn)品說(shuō)明書每段本身語(yǔ)義完整直接按段落分塊優(yōu)于按固定字?jǐn)?shù)硬切。chunk大小可以放寬到800字。如果文檔是合同或制度文件條款之間有強(qiáng)引用關(guān)系更適合父子分塊。父塊是整個(gè)條款段落子塊是條款內(nèi)的句子。如果用戶問(wèn)題偏短、偏實(shí)體化比如型號(hào)A和型號(hào)B的區(qū)別chunk太大容易把答案淹沒(méi)在其他信息里需要更小的chunk配合重排。一個(gè)可行的經(jīng)驗(yàn)法則是先用固定字?jǐn)?shù)400-500字跑一遍基線再用評(píng)測(cè)集觀察失敗case然后針對(duì)失敗類型調(diào)整策略而不是一開始就追求最優(yōu)參數(shù)。6.2 圖片和表格到底能不能存進(jìn)RAG知識(shí)庫(kù)這個(gè)問(wèn)題在RAG知識(shí)庫(kù)相關(guān)討論里的出現(xiàn)頻率很高。我的回答是可以但不能用常規(guī)方式。純文本向量化對(duì)圖片天然失效。正確做法是有兩條路圖片輔助路徑用OCR或視覺(jué)語(yǔ)言模型比如Qwen-VL、MiniCPM-V提取圖片中的文字信息生成詳細(xì)的圖注和描述文本再把描述文本向量化。用戶后續(xù)的問(wèn)句中只要涉及圖片內(nèi)容就能通過(guò)描述文本檢索到。表格結(jié)構(gòu)化路徑表格不要轉(zhuǎn)成純文本行流要保留成Markdown表格或HTML按行列關(guān)系保存。檢索時(shí)把表格對(duì)應(yīng)的文字說(shuō)明作為主檢索單元表格本身作為附件隨候選片段一起返回。自研時(shí)最好設(shè)計(jì)一個(gè)多模態(tài)文檔單元一個(gè)單元可以同時(shí)包含文字塊和圖片/表格對(duì)象。這樣檢索只作用于文字描述生成時(shí)再按需攜帶圖片或表格進(jìn)上下文。6.3 知識(shí)圖譜不是銀彈kg與向量檢索的適用范圍邊界自打kg知識(shí)庫(kù)ontology rag這類熱度起來(lái)之后不少人也在問(wèn)我要不要給自研RAG直接上知識(shí)圖譜方案我的判斷標(biāo)準(zhǔn)是看問(wèn)題的密度。如果業(yè)務(wù)里的典型問(wèn)題都是XX是什么XX和YY誰(shuí)更適合我怎么做XX這類局部查詢向量RAG足夠了。但如果你經(jīng)常遇到為什么這個(gè)環(huán)節(jié)影響了那個(gè)環(huán)節(jié)哪些因素共同決定了這個(gè)結(jié)果這類跨實(shí)體推理問(wèn)題知識(shí)圖譜才有必要引進(jìn)來(lái)。另外還需要考慮成本。GraphRAG構(gòu)建圖譜的算力開銷比普通向量索引高很多倍而且需要定期隨文檔更新重建。更合理的起步方式是在向量檢索召回之后疊加一個(gè)關(guān)系補(bǔ)充環(huán)節(jié)對(duì)召回片段做一次輕量實(shí)體鏈接順便抽取相鄰實(shí)體關(guān)系補(bǔ)進(jìn)上下文。先用小成本驗(yàn)證圖譜對(duì)效果的增量再做完整圖譜模塊。6.4 macOS本機(jī)搭建RAG環(huán)境的可行性方案很多人習(xí)慣用自己的Mac本機(jī)先搭RAG試驗(yàn)環(huán)境。這事完全可行但要提前跳過(guò)幾個(gè)坑。最穩(wěn)的本地方案是Ollama跑Embedding和LLM模型搭配Chroma或Qdrant作為向量庫(kù)再用FastGPT或MaxKB作為界面和管理層。具體到Mac上實(shí)踐時(shí)有幾個(gè)經(jīng)驗(yàn)可以分享內(nèi)存是硬約束。7B量級(jí)的量化和13B量化模型在同一臺(tái)機(jī)器上同時(shí)跑Embedding和生成內(nèi)存16GB會(huì)比較吃緊。建議Embedding用輕量模型如BGE-Small生成時(shí)才切換大模型或者用遠(yuǎn)程API做生成。Python環(huán)境建議直接用虛擬環(huán)境管理工具不要直接在系統(tǒng)Python上裝依賴別問(wèn)我是怎么知道的。分塊、向量化、評(píng)測(cè)這些依賴一旦沖突排查起來(lái)特別費(fèi)時(shí)間。macOS上跑PDF解析注意掃描版PDF需要額外裝OCR相關(guān)庫(kù)。如果不裝解析出來(lái)全是空文本檢索結(jié)果會(huì)非常迷惑。如果在Mac上先把這套MVP跑通了后續(xù)遷移到服務(wù)器環(huán)境基本就是換一個(gè)向量庫(kù)連接字符串的事。最后再聊一點(diǎn)個(gè)人的實(shí)際感受。逆向這六款開源產(chǎn)品時(shí)我最大的體會(huì)是自研RAG真正難的地方不是某個(gè)算法環(huán)節(jié)有多高深而是如何把解析、切塊、索引、召回、精排、生成、評(píng)估這些看起來(lái)都會(huì)的模塊以正確的順序和正確的邊界組合在一起。開源產(chǎn)品把組合方式直接擺在了代碼里這是信息密度極高的參考素材。如果你現(xiàn)在正準(zhǔn)備自研RAG我的建議很明確不要從寫第一個(gè)函數(shù)開始先從拆第一份開源代碼開始。選一款和你業(yè)務(wù)最接近的產(chǎn)品把它的數(shù)據(jù)流畫一遍再對(duì)照這篇的五層結(jié)構(gòu)和選型表決定哪些環(huán)節(jié)自研、哪些環(huán)節(jié)用現(xiàn)成組件。先跑通MVP再談優(yōu)化。這樣走至少不會(huì)把彎路完整地走一遍。