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