開源 RAG 堆疊把混亂變計畫

我把七層開源 RAG 堆疊拆成可執行的 build plan，最後附可直接複製的模板。

我做 RAG 做到有點火大了。表面上看起來很簡單：挑一個向量資料庫、接個 retriever、上個 LLM、交差。真的下去做，才知道整包東西根本不是一個架構決策，而是七個決策硬塞成一個故事。前端一亂，信任就掉；ingestion 一爛，後面全是垃圾；retrieval 一弱，大家就怪模型笨。最煩的是，很多教學都把這些問題講得像「選工具」而已，彷彿換個框架世界就會自己變整齊。

所以我看到 Sarah Morino 這篇 Plain English 的文章時，第一個反應是：終於有人不裝了。她把開源 RAG 拆成七層，從 ingestion、embedding、vector DB、retrieval、LLM orchestration，到 model layer 和 frontend，還把常見工具一層一層點名出來。這篇不是在賣夢，是在畫地圖。這種東西才有用。

RAG 不是一個系統，是七個地方都可能爛

“This guide breaks down the seven essential layers of the open-source RAG architecture, highlighting the best tools for each stage — from data ingestion to frontend deployment.”

翻譯一下就是：你不要再問「哪個 RAG 工具最好」，你要先問「到底是哪一層在搞我」。

我以前也犯過這種錯。看到答案不準，我先去調 prompt；prompt 沒救，再去換 model；model 還是不行，就開始懷疑自己選錯框架。結果最後發現是 PDF ingestion 把表格拆爛了，chunk 切得像碎紙機，retriever 當然只能撈到垃圾。模型只是照著垃圾回答，背鍋背得很冤。

這篇文章最有價值的地方，就是它逼你用分層思維看 RAG。不是一坨 AI，不是一個黑盒，而是七個可以逐一驗證的環節。只要你接受這件事，很多選型爭論會瞬間安靜下來。

我自己的實操方式很簡單：先畫出資料怎麼進來、怎麼切、怎麼嵌入、怎麼檢索、怎麼排序、怎麼餵給模型、最後怎麼讓使用者看見。每一層都要能單獨測，不然你只是在做一個更貴的幻覺機器。

• 先別問哪個工具潮，先問哪一層失敗成本最高。
• 先把資料流畫出來，再決定模型。
• 每層都要有可觀測的失敗訊號，不然壞了也不知道壞哪裡。

前端先做，不是花俏，是在建立信任

這篇很妙的一點，是它先講 frontend。它列了 Next.js、SvelteKit、Streamlit、Vue。很多人會覺得奇怪，RAG 不是後端和檢索先嗎？我反而覺得這順序對，因為使用者第一眼看到的就是介面。

也就是說，frontend 不是裝飾品，它直接決定使用者怎麼提問、怎麼理解答案、怎麼判斷這系統值不值得信任。你如果把 citation 藏起來，把失敗狀態藏起來，把來源藏起來，最後只會得到一個看起來很會講話、實際上很難被採用的工具。

我之前做過一個內部知識助手，後端其實沒那麼差，但 UI 做得像倉庫管理系統，大家根本不想碰。後來換成一個很土的 Streamlit 介面，至少把來源、段落、查詢、回饋都攤開，採用率反而上來。這件事很煩，但是真的：人類不是因為模型準就信你，是因為他看得懂你怎麼得出來才信你。

我會這樣落地：

• 內部工具先用 Streamlit 快速驗證流程。
• 要正式上線、要 auth、要 routing，就用 Next.js。
• 如果團隊偏輕量，SvelteKit 會比你想的舒服。
• 不管哪個框架，答案旁邊一定要顯示來源。

前端不是最後一哩路。它是使用者決定要不要相信你的一哩路。

向量資料庫不是倉庫，是記憶篩子

文章提到 Weaviate、Milvus、pgvector、Chroma、Pinecone。這一層最容易被講成「選一個能存 vector 的東西」而已，但那是偷懶說法。

白話講，vector DB 決定的不是你把資料放哪裡，而是系統怎麼記得事情。它影響過濾、相似度、查詢延遲、metadata schema、更新策略，甚至影響你能不能優雅地做 hybrid search。這不是倉庫，這是記憶篩子。

我看過不少團隊為了「聽起來先進」去選一個很大牌的向量資料庫，結果後來才發現自己真正需要的是 Postgres 整合、filtering、版本控管，或是更簡單的維運。最後整個架構變得很貴，還不一定比較好用。老實說，這種選型很常見，也很沒必要。

我自己的判斷方式是反過來：

• 資料本來就在 Postgres，就先看 pgvector。
• 要 schema-aware、要比較完整的平台能力，就看 Weaviate。
• 規模是主問題，就看 Milvus。
• 想先跑起來、少折騰，就用 Chroma。

不要先問「哪個最強」。先問「哪個最不會讓我之後痛苦」。

Retrieval 才是 RAG 真正的地雷區

這篇把 retrieval 和 ranking 放在一起，我很同意。因為實務上，這一層就是在處理 chunking、filtering、scoring、reranking、hybrid search，外加一堆看起來不起眼但會把答案搞爛的細節。工具像 FAISS、Haystack、Weaviate、Elasticsearch、Jina AI 都是在解這個問題，只是路線不同。

翻譯一下就是：retrieval 不是「找相似文字」這麼簡單，而是「在錯誤答案出現之前，把對的上下文撈回來」。如果這一層爛，模型就會很有自信地胡說八道。這比直接拒答還糟，因為使用者會以為你有答案。

我踩過最常見的坑，是團隊花一堆時間調 prompt，結果真正的問題只是 retrieval 回來五段高度重複、但都不對的內容。模型不是笨，是你餵它的上下文本來就爛。這種時候再怎麼加系統提示詞都只是心理安慰。

我的實操建議：

• 要快、要可控，就看 FAISS。
• 要 keyword + vector 混用，就看 Elasticsearch。
• 想要模組化 pipeline，就用 Haystack。
• retrieval 先做對，再談 prompt engineering。

很多時候，retrieval 品質比 model 大小更重要。這句很煩，但是真的。

LLM orchestration 只是膠水，不是魔法

文章提到 LangChain、LlamaIndex、Haystack、Hugging Face、Semantic Kernel。這一層的工作是把 prompt、memory、tools、retrieval 串起來。

也就是說，這些框架的價值是減少我手寫膠水碼，不是替我想架構。很多人一上來就把框架當成產品本體，結果一層抽象疊一層，最後連自己到底在做什麼都講不清楚。這種專案通常很快就會進入「看起來很完整，實際上很難改」的狀態。

我不是反對框架。我只是反對把框架當信仰。你要的是可維護的流程，不是漂亮的 API 名字。框架應該讓你少寫重複碼、少處理雜事、少踩坑，但它不能替你決定產品邏輯。

我會這樣選：

• 工具呼叫、agent 流程多，就看 LangChain。
• 文件索引和 RAG 結構是核心，就看 LlamaIndex。
• 想要比較完整的管線，就看 Haystack。
• 如果你本來就在 Hugging Face 生態裡，就直接吃它的整合。

如果框架開始反過來規定你的產品形狀，停一下，通常是你太早複雜化了。

模型層最容易燒錢，也最容易被高估

文章列了 LLaMA、Mistral、Gemma、Phi-2、DeepSeek、Qwen。這一層通常最容易吸引注意，因為大家都愛聊模型，但實務上它常常不是最該先動的地方。

白話講，只要 retrieval 做對，很多情境根本不用最大模型。你要的是能聽懂指令、吃得下上下文、回得出格式、延遲和成本也還行的模型。不是越大越好，是夠用就好。

我看過太多團隊在模型選型上吵半天，結果 ingestion 還沒穩、chunking 還沒對、retrieval 還沒測。這順序很怪。你先把上下文做乾淨，再來談模型，不然你只是花更多錢讓錯誤看起來更像答案。

我自己的做法是：

• 先用最小可行模型驗證流程。
• 拿真實檢索回來的 context 測，不要拿玩具 prompt 測。
• 同時看 latency、cost、answer quality。
• 只有在任務真的需要時，才升級模型。

模型不是產品。系統才是。

Ingestion 是最無聊的部分，也是最決定成敗的部分

最後一層是 ingestion 和 data processing，文章點到 OpenSearch、Haystack、LangChain、Apache NiFi、Apache Airflow、Kubeflow。很多人最想跳過的就是這層，因為它不酷，沒有 demo 感，還很像資料工程。

但翻譯一下就是：你 RAG 的上限，取決於你能不能把原始資料整理乾淨再送進索引。PDF 解析、OCR、表格抽取、metadata 正規化、去重、版本更新，這些都不是雜務。它們就是地基。地基歪了，後面再漂亮都沒用。

我遇過最氣的狀況，是文件更新後系統還在撈舊 chunk，使用者問新政策，答案卻在講舊版本。大家第一時間又是怪模型。其實根本不是模型，是 ingestion 沒把版本管理做好。這種錯誤很常見，而且很貴。

我會這樣做：

• 有排程、有依賴，就用 Apache Airflow。
• 資料流很複雜、很多系統要接，就用 Apache NiFi。
• 如果你本來就在 ML pipeline 裡，就看 Kubeflow。
• 搜尋和索引本來就要一起管，就考慮 OpenSearch。

我現在都把 ingestion 當成產品面來做，不是資料前處理。差很多。

可抄的模板

# Open Source RAG Stack Build Plan（可直接改成你的版本）

## 1. 先定義你要解的問題
- 你的使用者是誰
- 他們會問什麼
- 哪些答案必須可追溯來源
- 哪些錯誤不能接受

## 2. Frontend
選一個：
- Next.js：正式產品
- SvelteKit：輕量互動頁面
- Streamlit：內部工具 / 快速原型
- Vue：團隊熟悉 Vue 生態時使用

前端責任：
- 接收查詢
- 顯示來源與引用
- 顯示失敗狀態
- 收集使用者回饋

## 3. Ingestion
選一個或多個：
- Apache Airflow：排程與工作流
- Apache NiFi：資料流整合
- Kubeflow：ML pipeline
- LangChain loaders：應用層載入
- Haystack parsers：文件處理
- OpenSearch：索引與搜尋前處理

ingestion 責任：
- 拉資料
- 清洗與正規化
- 擷取 metadata
- 切 chunk
- 去重與版本控管

## 4. Embeddings
選一個：
- Sentence Transformers
- Hugging Face embeddings
- Jina embeddings
- Nomic embeddings

embeddings 責任：
- 把 chunk 轉成 vector
- 固定模型版本
- 模型變更時重新 embedding

## 5. Vector DB
選一個：
- pgvector：Postgres-first
- Weaviate：schema-aware
- Milvus：大規模部署
- Chroma：快速原型
- Pinecone：託管服務

Vector DB 責任：
- 存 vector 與 metadata
- 支援 similarity search
- 支援 filter
- 更新要可觀測

## 6. Retrieval / Ranking
選一個或組合：
- FAISS：快速 similarity search
- Elasticsearch：keyword + vector hybrid
- Haystack：模組化 retrieval pipeline
- Weaviate：內建 retrieval
- Jina AI：neural / multimodal search

Retrieval 責任：
- top-k 檢索
- metadata filter
- rerank
- 去重
- 記錄 retrieval 品質

## 7. LLM Orchestration
選一個：
- LangChain：tool use / agent
- LlamaIndex：文件導向 RAG
- Haystack：端到端 pipeline
- Semantic Kernel：Microsoft 生態
- Hugging Face：模型整合

Orchestration 責任：
- 用檢索結果組 prompt
- 管理 memory（如果需要）
- 呼叫工具（如果需要）
- 控制輸出格式

## 8. Model Layer
選一個：
- LLaMA
- Mistral
- Gemma
- Phi-2
- DeepSeek
- Qwen

Model 責任：
- 根據 context 生成答案
- context 不足時拒答
- 控制 latency 與 cost

## 9. 最小驗收清單
- 檢索回來的是對的 chunk
- 答案有來源
- 缺資料時不亂編
- 更新後能正確反映
- 前端有清楚失敗狀態
- 延遲在可接受範圍

## 10. 建置順序
1. 先把 ingestion 做對
2. 再做 embeddings
3. 再存進 vector DB
4. 再做 retrieval / ranking
5. 再接 LLM orchestration
6. 再做 frontend
7. 最後補 evaluation / monitoring

## 11. 一句話原則
先修壞掉的那一層，不要急著換模型。

這份模板我會直接丟給團隊用。它不炫，但很實際。你如果照這個順序做，至少不會一開始就把自己帶進死胡同。

我喜歡這篇 Plain English 的地方，是它把 RAG 的地圖畫出來了；我加上的部分，是把這張地圖變成可以開工的順序。你不需要一次選對所有東西，你只需要先把最容易壞的那層修好。

來源：https://plainenglish.io/artificial-intelligence/the-open-source-rag-stack-a-complete-guide-to-building-retrieval-augmented-generation-systems。七層拆解與工具清單主要來自 Sarah Morino；上面的 build plan、判斷順序和模板是我自己的整理與改寫。