一個程序員從零寫RAG系統：文檔質量比大模型更重要

我選擇了一條最笨的路：不看論文,不套框架,從零開始敲代碼,讓系統在我手里崩潰,然后修好它。

這個RAG系統是我的第二個實驗品。它不做花哨的事,只負責一件事——根據一份公司政策文檔回答問題。用文檔里的原話回答,不是靠模型腦補。聽起來簡單,但真正寫起來,到處都是坑。

整個流程分六步：把文檔拆碎、給碎片生成向量、存進數據庫、搜出相關部分、塞給大模型、要求它只用這些材料回答。每一步都看似直截了當,但每一步都藏著決策點,選錯一個,后續全歪。

拆分文檔：200字符的窗口能看到什么

我用了LangChain的RecursiveCharacterTextSplitter,把政策文檔切成200字符一塊,塊與塊之間保留50字符的重疊。這不是隨便拍的數字。

200字符大概是一條政策條款的長度。如果切太長,檢索精度下降,模型會看到一堆無關內容；切太短,上下文碎片化,模型看不懂某句話在說什么。50字符的重疊是為了不讓完整句被攔腰截斷在兩個塊里。

真正動手才意識到,拆分策略決定了整個系統的天花板。如果切分時把一個條款的前半截和后半截分到兩個塊,后續哪怕檢索全對,模型也拼不出完整意思。文檔本身的結構——標題層級、段落邊界——才是拆分的第一參考系,不能無腦按字符數切。

但200字符的窗口還有一個隱藏問題：它能裝下信息,卻裝不下語境。一個段落里如果有指代詞,檢索出來的那個塊可能根本不知道它在指什么。這是后話,也是我踩坑之后才想通的事。

向量化：把文字變成機器能比較的坐標

文本切好后,下一步是生成嵌入向量。我用了HuggingFaceEmbeddings里的sentence-transformers/all-MiniLM-L6-v2模型。這是一個輕量級模型,跑在本地不費GPU,生成的向量維度也不算高。

向量化的本質是把一句話映射到高維空間里的一個點。語義相近的兩句話,在空間里的距離就近。但這套邏輯只在模型的訓練數據范圍內有效。

我用的政策文檔里有不少公司內部術語,這些詞不在通用語義模型的訓練分布里。模型會給它們一個向量坐標,但這個坐標是不是真的反映了它們在文檔中的含義,很難說。這是測試階段才發現的問題：用某個術語搜,返回的塊根本不對路。

嵌入模型的選擇不是越強越好,而是和文檔類型匹配才重要。輕量模型通用性好,但遇到領域特化詞匯時,它在高維空間里的判斷可能跑偏。

向量數據庫：Chroma存了什么,沒存什么

生成的向量持久化存在Chroma里。我沒選復雜的分布式方案,因為數據量小,單機就夠了。Chroma的好處是API簡單,建索引、做相似度搜索幾行代碼搞定。

但簡單的東西同時意味著黑盒。每次檢索時,Chroma內部是拿我的查詢向量和庫里的文檔向量做余弦相似度比較,然后返回top-2。我設了兩個塊,不是三個,不是五個。

為什么是2？因為200字符的塊很小,兩個塊已經是400字符的上下文,加上模型提示詞,在我本地跑tinyllama時內存剛好夠用。這不是精心計算的數字,是資源限制下的妥協。

但妥協之后反而發現一個現象：top-2在大多數情況下夠用了。政策類問題通常只涉及一兩個條款,兩個塊恰好覆蓋相關內容。如果問題更復雜,需要跨段落回答,兩個塊就不夠。這是檢索精度和覆蓋范圍的經典權衡,沒法純靠調參解決。

提示詞：用嚴格限定換可靠性

我寫了一個很硬的提示模板。硬到什么程度？明確告訴模型：只能用檢索到的上下文回答,不能調用你訓練時學到的任何知識。如果上下文里沒答案,就回復“文檔中沒有相關信息”。

這個做法是在主動限制模型的能力。大模型的強項恰恰是記憶了大量知識,而我要求它假裝什么都不記得,只讀眼前的材料。這聽起來很反直覺,但反直覺的背后有一個現實判斷：在企業內網場景里,用私有文檔回答問題,比用模型記憶中的公開知識更可靠。

幻覺問題不只是模型在胡說八道,還在于模型會在正確回答里混入不應該出現的信息。比如問年終獎政策,模型不僅從上下文提取了條款,還順帶補了一句“具體以HR通知為準”。這句話可能來源于訓練數據中的通用表達,但它不在我的政策文檔里。

硬提示詞就是在杜絕這種情況。它把生成范圍鎖死在檢索結果內,損失的可能是回答的流暢度,換來的是信息可追溯。每句話都能對應回文檔中的某一句,這是企業場景下最底線的要求。

模型我用的是Ollama跑的tinyllama,本地部署。選它的原因很簡單：代碼是在本地寫的,調試的時候斷網也不能停。tinyllama的生成質量放在本地小模型里是可用水平,但一旦提示詞不準,它跑偏的速度比大模型快得多。

文檔質量決定天花板

系統搭完跑起來后,我發現一個詭異的現象：同一個問題,檢索過程完全一樣,但回答質量差別很大。排查了很久,發現源頭不是技術實現,而是文檔本身。

如果文檔里某句話存在歧義,無論我的檢索多精準,模型生成的答案也會帶著歧義。如果文檔結構混亂,條款散落在不同章節,200字符的切分窗口沒辦法跨章節理解邏輯。

不是每個問題都能通過優化技術解決。RAG的天花板在文檔質量,然后才是切分策略和檢索精度。文檔本身如果含糊,模型給出的答案就只能是含糊的投射。

這個發現讓我重新審視了所謂的“智能問答系統”。很多人以為裝上大模型就是智能化,但實際上,如果企業內部文檔本身缺乏結構,到處是口語化表述和模棱兩可的條款,RAG系統能做的事非常有限。

文檔質量還包括信息的組織方式。政策文檔如果按時間順序寫,但用戶提問是按主題維度,那么檢索出來的塊很可能在時間上有相關性,主題上卻對不上。這不是檢索的錯,是文檔結構和檢索邏輯不匹配。

這個問題暫時沒法用代碼解決。我能做的只是讓系統的失敗是可見的,而不是悄悄生成錯誤答案。

檢索精度：兩個塊夠用嗎

top-2的設置在實際測試中暴露出一個邊界情況。當答案涉及文件的附表或條款之間的交叉引用時,兩個塊完全覆蓋不到相關信息。

比如問“年假天數和入職年限的對應關系”,表格可能在第五頁,對應的計算規則在第一頁,兩個塊只能拿到其中一部分。模型拿到的上下文不完整,生成的結果自然也缺一塊。

這個問題要改的不是提示詞或模型,而是檢索策略。需要引入元數據結構,讓切分階段就保留文檔的層級關系,這樣檢索時可以從層級層面做補充,而不是僅靠相似度。

但引入元數據又會增加復雜度。文檔的類型不同,層級結構不同,寫一套通用的元數據提取邏輯非常容易過度設計。我在這個問題上暫時擱置了,留到多代理工作流的實驗里再去嘗試。

評估方法：怎么知道系統在變好

整個搭建過程中,最讓我困擾的其實不是技術細節,而是怎么評估這個系統好不好用。

我沒有用BLEU或ROUGE這類自動評分指標,因為政策問答的場景下,答案是否“正確”不是靠比對字面,而是看邏輯是否自洽、引用來源是否可靠。

目前用的方式是人工對比：把檢索到的兩個塊和生成的答案放在一起,一條條對應,看每個陳述有沒有出處。效率低,但能發現自動評估發現不了的問題,比如模型擅自添加了文檔中不存在的前提假設。

這不是最終的解決方案,只是在早期階段的一種務實做法。如果要往生產環境推,評估必須自動化,但自動化的前提是有結構化的測試集,這個測試集需要大量人工標注。

所以整個系統的建設順序反過來了：我原來以為API和模型是核心,但做完才發現,文檔整理和評估流程才是決定系統能不能落地的部分。模型反而是最后替換的零件。

從RAG到多代理：一個筑基步驟

這個項目是我多代理實驗之前必須做完的功課。RAG系統提供了一項基礎能力——讓模型有據可查,這是后續引入多個代理協作的前提。

如果一個代理生成的答案不可追溯,那多個代理一起工作時,出錯的問題會被成倍放大。RAG的檢索-生成鏈路,是在單代理層面建立起可控性,再逐步放開復雜度。

我下一步要做的實驗包括多代理工作流、MCP服務器、自動代理系統。這些聽起來比RAG酷得多,但每一個都需要建立在穩定的知識檢索之上。

代碼全部開源在GitHub上。不是因為它做得好,而是因為每一個踩過的坑都留在commit記錄里。如果有人要走同樣的路,看我的錯誤比看我的成果更有用。