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