RAG:讓 agent 查你自己的文件

RAG 分兩個階段。第一個是建庫:把你的文件切成一塊一塊,每塊算成一串代表語意的數字、也就是向量,存起來。第二個是查詢:使用者問問題,問題也算成向量,拿去找語意最接近的那幾塊。然後把撈到的塊,塞進模型的提示裡當小抄,讓它照著回答。所以模型不用「知道」答案,它照你文件裡的內容講就對。

第一個關卡馬上來。「算成向量」這一步,需要一個專門的模型,叫 embedding 模型,它跟聊天模型是兩回事。而很多免費的雲端服務,只給你聊天模型,沒有 embedding。所以自架 RAG 幾乎一定會用到本機模型 —— 我用的是 bge-m3。掛的時候有個小地雷:型別要選「Text Embedding」,選成聊天模型就白做了。

建好知識庫,把文件上傳,平台會自動幫你切塊、再用 embedding 模型算成向量。而且不只純文字,PDF、Word、Excel 都能解析切塊,你真的丟公司文件進去也行。要有個心理準備:本機的 embedding 在一般電腦上,每一塊要算好幾秒,一份文件切幾十塊就要等一下 —— 慢,但好處是你的資料完全沒出過這台機器。

這是很多人誤會的地方:RAG 不是只存一個向量庫,而是存兩個地方。左邊建庫:文件切塊、算向量,向量存進向量資料庫,文字存進一般資料庫。右邊查詢:問題算成向量,去向量庫找最接近的幾塊,拿到它們的編號,再用這個編號回到一般資料庫,把對應的真正文字撈出來,塞給模型。兩個庫,靠同一把編號對應起來。

為什麼要拆成兩個?因為一般資料庫擅長存文字跟關聯,但不會做向量的相似搜尋;而向量資料庫專門做相似搜尋、非常快,但不適合拿來當內容的真相來源。打個比方:一般資料庫是「圖書館裡的書」,存真正的內容;向量庫是「按語意排的索引卡」,幫你快速找到是哪本書。查到卡片,再回圖書館把書拿出來。分工很清楚。

而且這個向量庫是可以換的,靠一個設定就切換。如果你選 pgvector,向量就塞進一般資料庫的擴充,跟文字同一個庫,運維最簡單,中小量夠用。如果你用獨立的向量庫,在很大量、很多人同時用的時候,效能比較撐得住。同一套 RAG 邏輯,底層向量庫是可以抽換的零件 —— 這跟 agent 各層可替換是同一個道理。

這裡是 RAG 最重要的一條紀律:建好庫,先別急著接 agent。先用「命中測試」直接驗檢索 —— 輸入一個答案只在文件裡的問題,看它撈回哪幾塊、相似度分數多少。分數落在合理範圍、而且撈回的內容真的跟問題相關,才代表檢索有撈對。為什麼要先單獨驗?因為如果檢索本身就撈錯,後面 agent 答錯,你會以為是模型笨,其實是根本沒撈到對的內容。先驗檢索,再談生成。

接進對話流程後,我拿同一題問了三次,得到三個完全不同的答案 —— 差別只在一條線接了沒。第一次:上下文沒接、也沒約束,它就用腦袋裡的舊知識亂編,還編到別的國家去了。第二次:我加了一句「只能根據上下文、禁止編造」,它就不編了,但誠實說「文件裡查不到」。第三次:我把上下文接上檢索結果,它才答出文件裡真正的數字,而且還附上是哪份文件。

把這三個階段畫成一張圖就很清楚。同一個問題,先進到知識檢索、撈到內容,真正的分岔在這裡:LLM 的『上下文』,到底有沒有接上知識檢索?沒接,它就用腦內舊知識亂編;接了、但上下文是空的,它誠實說查不到;只有把上下文接上檢索結果,它才照文件回答、還附上出處。同一題三個答案,差別就在那一條線接了沒。

這就是 RAG 裡最容易漏、也最關鍵的一條線。很多人的知識檢索明明撈到了,可是 LLM 節點的「上下文」欄位是空的 ——撈回的塊,躺在檢索節點的輸出裡,根本沒被交給模型。你去看模型實際收到的提示,裡面連那塊文字都沒有,當然只能說查不到。把 LLM 節點的「上下文」設成「知識檢索的結果」,那條線才通,撈回的內容才進得了提示。這條線,就是整個 RAG 流程的命脈。

最後一個重點,特別重要。我故意在庫裡混了公司內部文件。這裡有個容易忽略的洩漏點:embedding 用本機,索引階段確實不出門;但如果你回答用的聊天模型是雲端的,檢索到的機密內容,會被塞進提示、送上雲。所以對機密資料的鐵律是:embedding 跟聊天模型,兩個都要用本機模型,資料主權才完整。這正是「為什麼要本機 RAG」的實戰理由 —— 不能只本機一半。另外,一個知識庫別混太多不相關的領域,不然檢索會互相干擾,真上線要一個領域一個庫。

留給你一句話:RAG 不難,難在順序 —— 先驗檢索,再接生成。先用命中測試確認撈對了,再把「檢索到 LLM 的上下文」那條線接上。撈對,加上接上,你才會得到一個「照文件回答、還附得出出處」的可信 agent。而不是一個講得很流暢、其實在編的機器。