RAG 系統架構長怎樣?從一份文件到一個答案的完整資料流拆解

RAG(Retrieval-Augmented Generation,檢索增強生成)系統架構,是一套讓大型語言模型在回答前,先從企業自有知識庫檢索相關內容、再依據檢索結果生成答案的流程;它的核心是一條由「攝取 → 切塊 → 向量化 → 檢索 → 生成」五個階段串成的資料流。

這句話很好背。但真正麻煩的,是這條線上每一段都會壞,而且壞掉的地方通常不在你以為的那一段。

上個月我們在一家做設備維修的公司,看到一個典型現象:他們花大錢接了 GPT,做了 RAG,結果客服問「A 型號的保固條款」,系統回的是 B 型號的。工程師第一反應是「模型不夠聰明」,想換更大的模型。我們往回追,問題根本不在生成,在最前面——他們的 PDF 保固表是掃描檔,攝取階段只抽到亂碼。模型再聰明,也救不了它從沒讀到的東西。

所以與其談「RAG 有多神」,我們更想帶你走一遍完整的 RAG 系統架構,把每一段的失敗點標出來。

RAG 系統架構:一份文件到一個答案的五段資料流

想像一份 PDF 合約,要變成客服口中一句「你的保固到明年三月」。它得經過這五站:

第一站,攝取(Ingest)。 把原始文件從各種來源撈進來:PDF、Word、網頁、資料庫、Confluence、共享雲端。這一步做的是「把非結構化內容變成乾淨的純文字」。聽起來機械,卻是整條線最常被低估的地方。掃描件沒做 OCR、表格被拉平成一行、頁首頁尾的雜訊混進正文、Excel 的合併儲存格解析錯位——這些在攝取階段就注定了下游拿到的是垃圾。

第二站,切塊(Chunk)。 把長文切成一段一段,好讓後面能逐段比對。多數團隊隨手設個「每 500 字切一刀」,然後就出事了。一條保固條款被硬切成兩半,前半在 chunk 3、後半在 chunk 4,檢索時只撈到半句,答案自然殘缺。切塊不是切字數,是切「語意的完整單位」。

第三站,向量化(Embed)。 把每個 chunk 丟進 embedding 模型,變成一串數字向量,代表它的語意座標。這一步的隱形陷阱是:你用哪個 embedding 模型,決定了系統「懂不懂中文」。很多開源模型對繁體中文、對產業術語(料號、GMP、保單代碼)的理解很弱,語意相近的兩段話在向量空間裡卻離得很遠,檢索就開始漂。

第四站,檢索(Retrieve)。 使用者問問題,問題本身也被向量化,然後去向量資料庫裡找「最接近」的幾個 chunk。這是整個 RAG 品質的心臟。撈太少,漏掉關鍵段落;撈太多,把不相關的雜訊也塞進去。前面那家維修公司,就是檢索只靠純向量相似度,而「A 型號」和「B 型號」在語意上太像,系統分不清——這時需要的是關鍵字檢索與向量檢索混合(hybrid search),再加一層 rerank 重新排序,把真正對的那段頂上來。

第五站,生成(Generate)。 把檢索到的 chunk 連同問題,一起塞進 prompt 給 LLM,請它「只根據這些資料回答」。這一步的失敗點是幻覺與越界:檢索給錯了料,模型照樣一本正經地編;或是明明資料裡沒有,模型硬要補一句聽起來合理的話。好的生成階段會要求模型標出引用來源,查無資料時直接說「找不到」,而不是硬掰。

每一段最容易壞的地方

把上面這條線攤平成一張對照表,失敗點一目了然:

看懂這張表,你會發現一件事:當 RAG 答錯,九成的人怪模型,但故障點通常在攝取、切塊、檢索這三段——也就是模型還沒開口之前。換更大的模型,常常只是把錢花在最不需要的地方。

Demo 會過,生產不一定

RAG 的殘酷在於,它的 Demo 幾乎一定成功。你挑三份乾淨的文件、問五個你早知道答案的問題,現場漂亮得不得了。真正的考驗是把它接上那份塞了十年、格式混亂、版本重複、還夾著掃描件的真實知識庫,讓每天上百個五花八門的問題砸進來。準確率會從 Demo 的九成,掉到上線的五成。

這中間的差距,不是靠一個更強的模型補起來的,是靠在每一段資料流上做工:攝取要挑對解析器、切塊要照文件結構、embedding 要選懂中文的、檢索要 hybrid 加 rerank、生成要綁來源。一段一段地量、一段一段地修。

我們自己做企業 RAG 知識系統時,習慣先不碰模型,而是拉一批真實會被問的問題當測試集,從最前面的攝取開始逐段驗證檢索命中率——因為答案錯在哪,往往比答案本身更值得先弄清楚。Demo 很美不算數,接上那份髒亂的真實知識庫還答得準,才算真的上線。