[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-open-source-rag-stack-build-plan-zh":3,"article-related-open-source-rag-stack-build-plan-zh":31,"series-tools-4130de62-a037-464c-883d-5fbf8dd75789":83},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":23,"views":27,"created_at":28,"published_at":29,"topic_cluster_id":30},"4130de62-a037-464c-883d-5fbf8dd75789","open-source-rag-stack-build-plan-zh","開源 RAG 堆疊把混亂變計畫","\u003Cp data-speakable=\"summary\">我把七層開源 \u003Ca href=\"\u002Ftag\u002Frag\">RAG\u003C\u002Fa> 堆疊拆成可執行的 build plan，最後附可直接複製的模板。\u003C\u002Fp>\u003Cp>我做 RAG 做到有點火大了。表面上看起來很簡單：挑一個向量資料庫、接個 retriever、上個 \u003Ca href=\"\u002Ftag\u002Fllm\">LLM\u003C\u002Fa>、交差。真的下去做，才知道整包東西根本不是一個架構決策，而是七個決策硬塞成一個故事。前端一亂，信任就掉；ingestion 一爛，後面全是垃圾；retrieval 一弱，大家就怪模型笨。最煩的是，很多教學都把這些問題講得像「選工具」而已，彷彿換個框架世界就會自己變整齊。\u003C\u002Fp>\u003Cp>所以我看到 Sarah Morino 這篇 \u003Ca href=\"https:\u002F\u002Fplainenglish.io\u002Fartificial-intelligence\u002Fthe-open-source-rag-stack-a-complete-guide-to-building-retrieval-augmented-generation-systems\">Plain English 的文章\u003C\u002Fa>時，第一個反應是：終於有人不裝了。她把開源 RAG 拆成七層，從 ingestion、embedding、vector DB、retrieval、LLM orchestration，到 model layer 和 frontend，還把常見工具一層一層點名出來。這篇不是在賣夢，是在畫地圖。這種東西才有用。\u003C\u002Fp>\u003Ch2>RAG 不是一個系統，是七個地方都可能爛\u003C\u002Fh2>\u003Cblockquote>“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.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：你不要再問「哪個 RAG 工具最好」，你要先問「到底是哪一層在搞我」。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780872500382-6ang.png\" alt=\"開源 RAG 堆疊把混亂變計畫\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前也犯過這種錯。看到答案不準，我先去調 prompt；prompt 沒救，再去換 model；model 還是不行，就開始懷疑自己選錯框架。結果最後發現是 PDF ingestion 把表格拆爛了，chunk 切得像碎紙機，retriever 當然只能撈到垃圾。模型只是照著垃圾回答，背鍋背得很冤。\u003C\u002Fp>\u003Cp>這篇文章最有價值的地方，就是它逼你用分層思維看 RAG。不是一坨 AI，不是一個黑盒，而是七個可以逐一驗證的環節。只要你接受這件事，很多選型爭論會瞬間安靜下來。\u003C\u002Fp>\u003Cp>我自己的實操方式很簡單：先畫出資料\u003Ca href=\"\u002Fnews\u002Fhow-to-build-akiraos-wasm-apps-for-zephyr-zh\">怎麼\u003C\u002Fa>進來、怎麼切、怎麼嵌入、怎麼檢索、怎麼排序、怎麼餵給模型、最後怎麼讓使用者看見。每一層都要能單獨測，不然你只是在做一個更貴的幻覺機器。\u003C\u002Fp>\u003Cul>\u003Cli>先別問哪個工具潮，先問哪一層失敗成本最高。\u003C\u002Fli>\u003Cli>先把資料流畫出來，再決定模型。\u003C\u002Fli>\u003Cli>每層都要有可觀測的失敗訊號，不然壞了也不知道壞哪裡。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>前端先做，不是花俏，是在建立信任\u003C\u002Fh2>\u003Cp>這篇很妙的一點，是它先講 frontend。它列了 \u003Ca href=\"https:\u002F\u002Fnextjs.org\u002F\">Next.js\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkit.svelte.dev\u002F\">SvelteKit\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fstreamlit.io\u002F\">Streamlit\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fvuejs.org\u002F\">Vue\u003C\u002Fa>。很多人會覺得奇怪，RAG 不是後端和檢索先嗎？我反而覺得這順序對，因為使用者第一眼看到的就是介面。\u003C\u002Fp>\u003Cp>也就是說，frontend 不是裝飾品，它直接決定使用者怎麼提問、怎麼理解答案、怎麼判斷這系統值不值得信任。你如果把 citation 藏起來，把失敗狀態藏起來，把來源藏起來，最後只會得到一個看起來很會講話、實際上很難被採用的工具。\u003C\u002Fp>\u003Cp>我之前做過一個內部知識助手，後端其實沒那麼差，但 UI 做得像倉庫管理系統，大家根本不想碰。後來換成一個很土的 Streamlit 介面，至少把來源、段落、查詢、回饋都攤開，採用率反而上來。這件事很煩，但是真的：人類不是因為模型準就信你，是因為他看得懂你怎麼得出來才信你。\u003C\u002Fp>\u003Cp>我會這樣落地：\u003C\u002Fp>\u003Cul>\u003Cli>內部工具先用 \u003Ca href=\"https:\u002F\u002Fstreamlit.io\u002F\">Streamlit\u003C\u002Fa> 快速驗證流程。\u003C\u002Fli>\u003Cli>要正式上線、要 auth、要 routing，就用 \u003Ca href=\"https:\u002F\u002Fnextjs.org\u002F\">Next.js\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>如果團隊偏輕量，\u003Ca href=\"https:\u002F\u002Fkit.svelte.dev\u002F\">SvelteKit\u003C\u002Fa> 會比你想的舒服。\u003C\u002Fli>\u003Cli>不管哪個框架，答案旁邊一定要顯示來源。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>前端不是最後一哩路。它是使用者決定要不要相信你的一哩路。\u003C\u002Fp>\u003Ch2>向量資料庫不是倉庫，是記憶篩子\u003C\u002Fh2>\u003Cp>文章提到 \u003Ca href=\"https:\u002F\u002Fweaviate.io\u002F\">Weaviate\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fmilvus.io\u002F\">Milvus\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\">pgvector\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.trychroma.com\u002F\">Chroma\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.pinecone.io\u002F\">Pinecone\u003C\u002Fa>。這一層最容易被講成「選一個能存 vector 的東西」而已，但那是偷懶說法。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780872505484-0xqu.png\" alt=\"開源 RAG 堆疊把混亂變計畫\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>白話講，vector DB 決定的不是你把資料放哪裡，而是系統怎麼記得事情。它影響過濾、相似度、查詢延遲、metadata schema、更新策略，甚至影響你能不能優雅地做 hybrid search。這不是倉庫，這是記憶篩子。\u003C\u002Fp>\u003Cp>我看過不少\u003Ca href=\"\u002Fnews\u002F5-reasons-openrag-fits-rag-teams-zh\">團隊\u003C\u002Fa>為了「聽起來先進」去選一個很大牌的向量資料庫，結果後來才發現自己真正需要的是 Postgres 整合、filtering、版本控管，或是更簡單的維運。最後整個架構變得很貴，還不一定比較好用。老實說，這種選型很常見，也很沒必要。\u003C\u002Fp>\u003Cp>我自己的判斷方式是反過來：\u003C\u002Fp>\u003Cul>\u003Cli>資料本來就在 Postgres，就先看 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\">pgvector\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>要 schema-aware、要比較完整的平台能力，就看 \u003Ca href=\"https:\u002F\u002Fweaviate.io\u002F\">Weaviate\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>規模是主問題，就看 \u003Ca href=\"https:\u002F\u002Fmilvus.io\u002F\">Milvus\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>想先跑起來、少折騰，就用 \u003Ca href=\"https:\u002F\u002Fwww.trychroma.com\u002F\">Chroma\u003C\u002Fa>。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>不要先問「哪個最強」。先問「哪個最不會讓我之後痛苦」。\u003C\u002Fp>\u003Ch2>Retrieval 才是 RAG 真正的地雷區\u003C\u002Fh2>\u003Cp>這篇把 retrieval 和 ranking 放在一起，我很同意。因為實務上，這一層就是在處理 chunking、filtering、scoring、reranking、hybrid search，外加一堆看起來不起眼但會把答案搞爛的細節。工具像 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffacebookresearch\u002Ffaiss\">FAISS\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.deepset.ai\u002Fhaystack\">Haystack\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fweaviate.io\u002F\">Weaviate\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.elastic.co\u002Felasticsearch\">Elasticsearch\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fjina.ai\u002F\">Jina AI\u003C\u002Fa> 都是在解這個問題，只是路線不同。\u003C\u002Fp>\u003Cp>翻譯一下就是：retrieval 不是「找相似文字」這麼簡單，而是「在錯誤答案出現之前，把對的上下文撈回來」。如果這一層爛，模型就會很有自信地胡說八道。這比直接拒答還糟，因為使用者會以為你有答案。\u003C\u002Fp>\u003Cp>我踩過最常見的坑，是團隊花一堆時間調 prompt，結果真正的問題只是 retrieval 回來五段高度重複、但都不對的內容。模型不是笨，是你餵它的上下文本來就爛。這種時候再怎麼加系統提示詞都只是心理安慰。\u003C\u002Fp>\u003Cp>我的實操建議：\u003C\u002Fp>\u003Cul>\u003Cli>要快、要可控，就看 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffacebookresearch\u002Ffaiss\">FAISS\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>要 keyword + vector 混用，就看 \u003Ca href=\"https:\u002F\u002Fwww.elastic.co\u002Felasticsearch\">Elasticsearch\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>想要模組化 pipeline，就用 \u003Ca href=\"https:\u002F\u002Fwww.deepset.ai\u002Fhaystack\">Haystack\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>retrieval 先做對，再談 prompt engineering。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>很多時候，retrieval 品質比 model 大小更重要。這句很煩，但是真的。\u003C\u002Fp>\u003Ch2>LLM orchestration 只是膠水，不是魔法\u003C\u002Fh2>\u003Cp>文章提到 \u003Ca href=\"https:\u002F\u002Fwww.langchain.com\u002F\">LangChain\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.llamaindex.ai\u002F\">LlamaIndex\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.deepset.ai\u002Fhaystack\">Haystack\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fhuggingface.co\u002F\">Hugging Face\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fsemantic-kernel\u002F\">Semantic Kernel\u003C\u002Fa>。這一層的工作是把 prompt、memory、tools、retrieval 串起來。\u003C\u002Fp>\u003Cp>也就是說，這些框架的價值是減少我手寫膠水碼，不是替我想架構。很多人一上來就把框架當成產品本體，結果一層抽象疊一層，最後連自己到底在做什麼都講不清楚。這種專案通常很快就會進入「看起來很完整，實際上很難改」的狀態。\u003C\u002Fp>\u003Cp>我不是反對框架。我只是反對把框架當信仰。你要的是可維護的流程，不是漂亮的 \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa> 名字。框架應該讓你少寫重複碼、少處理雜事、少踩坑，但它不能替你決定產品邏輯。\u003C\u002Fp>\u003Cp>我會這樣選：\u003C\u002Fp>\u003Cul>\u003Cli>工具呼叫、agent 流程多，就看 \u003Ca href=\"https:\u002F\u002Fwww.langchain.com\u002F\">LangChain\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>文件索引和 RAG 結構是核心，就看 \u003Ca href=\"https:\u002F\u002Fwww.llamaindex.ai\u002F\">LlamaIndex\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>想要比較完整的管線，就看 \u003Ca href=\"https:\u002F\u002Fwww.deepset.ai\u002Fhaystack\">Haystack\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>如果你本來就在 Hugging Face 生態裡，就直接吃它的整合。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果框架開始反過來規定你的產品形狀，停一下，通常是你太早複雜化了。\u003C\u002Fp>\u003Ch2>模型層最容易燒錢，也最容易被高估\u003C\u002Fh2>\u003Cp>文章列了 \u003Ca href=\"https:\u002F\u002Fwww.llama.com\u002F\">LLaMA\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fmistral.ai\u002F\">Mistral\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fai.google.dev\u002Fgemma\">Gemma\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fproject\u002Fphi-2\u002F\">Phi-2\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.deepseek.com\u002F\">DeepSeek\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fqwenlm.github.io\u002F\">Qwen\u003C\u002Fa>。這一層通常最容易吸引注意，因為大家都愛聊模型，但實務上它常常不是最該先動的地方。\u003C\u002Fp>\u003Cp>白話講，只要 retrieval 做對，很多情境根本不用最大模型。你要的是能聽懂指令、吃得下上下文、回得出格式、延遲和成本也還行的模型。不是越大越好，是夠用就好。\u003C\u002Fp>\u003Cp>我看過太多團隊在模型選型上吵半天，結果 ingestion 還沒穩、chunking 還沒對、retrieval 還沒測。這順序很怪。你先把上下文做乾淨，再來談模型，不然你只是花更多錢讓錯誤看起來更像答案。\u003C\u002Fp>\u003Cp>我自己的做法是：\u003C\u002Fp>\u003Cul>\u003Cli>先用最小可行模型驗證流程。\u003C\u002Fli>\u003Cli>拿真實檢索回來的 context 測，不要拿玩具 prompt 測。\u003C\u002Fli>\u003Cli>同時看 latency、cost、answer quality。\u003C\u002Fli>\u003Cli>只有在任務真的需要時，才升級模型。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>模型不是產品。系統才是。\u003C\u002Fp>\u003Ch2>Ingestion 是最無聊的部分，也是最決定成敗的部分\u003C\u002Fh2>\u003Cp>最後一層是 ingestion 和 data processing，文章點到 \u003Ca href=\"https:\u002F\u002Fopensearch.org\u002F\">OpenSearch\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.deepset.ai\u002Fhaystack\">Haystack\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.langchain.com\u002F\">LangChain\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fnifi.apache.org\u002F\">Apache NiFi\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fairflow.apache.org\u002F\">Apache Airflow\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.kubeflow.org\u002F\">Kubeflow\u003C\u002Fa>。很多人最想跳過的就是這層，因為它不酷，沒有 demo 感，還很像資料工程。\u003C\u002Fp>\u003Cp>但翻譯一下就是：你 RAG 的上限，取決於你能不能把原始資料整理乾淨再送進索引。PDF 解析、OCR、表格抽取、metadata 正規化、去重、版本更新，這些都不是雜務。它們就是地基。地基歪了，後面再漂亮都沒用。\u003C\u002Fp>\u003Cp>我遇過最氣的狀況，是文件更新後系統還在撈舊 chunk，使用者問新政策，答案卻在講舊版本。大家第一時間又是怪模型。其實根本不是模型，是 ingestion 沒把版本管理做好。這種錯誤很常見，而且很貴。\u003C\u002Fp>\u003Cp>我會這樣做：\u003C\u002Fp>\u003Cul>\u003Cli>有排程、有依賴，就用 \u003Ca href=\"https:\u002F\u002Fairflow.apache.org\u002F\">Apache Airflow\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>資料流很複雜、很多系統要接，就用 \u003Ca href=\"https:\u002F\u002Fnifi.apache.org\u002F\">Apache NiFi\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>如果你本來就在 ML pipeline 裡，就看 \u003Ca href=\"https:\u002F\u002Fwww.kubeflow.org\u002F\">Kubeflow\u003C\u002Fa>。\u003C\u002Fli>\u003Cli>搜尋和索引本來就要一起管，就考慮 \u003Ca href=\"https:\u002F\u002Fopensearch.org\u002F\">OpenSearch\u003C\u002Fa>。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我現在都把 ingestion 當成產品面來做，不是資料前處理。差很多。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Open Source RAG Stack Build Plan（可直接改成你的版本）\n\n## 1. 先定義你要解的問題\n- 你的使用者是誰\n- 他們會問什麼\n- 哪些答案必須可追溯來源\n- 哪些錯誤不能接受\n\n## 2. Frontend\n選一個：\n- Next.js：正式產品\n- SvelteKit：輕量互動頁面\n- Streamlit：內部工具 \u002F 快速原型\n- Vue：團隊熟悉 Vue 生態時使用\n\n前端責任：\n- 接收查詢\n- 顯示來源與引用\n- 顯示失敗狀態\n- 收集使用者回饋\n\n## 3. Ingestion\n選一個或多個：\n- Apache Airflow：排程與工作流\n- Apache NiFi：資料流整合\n- Kubeflow：ML pipeline\n- LangChain loaders：應用層載入\n- Haystack parsers：文件處理\n- OpenSearch：索引與搜尋前處理\n\ningestion 責任：\n- 拉資料\n- 清洗與正規化\n- 擷取 metadata\n- 切 chunk\n- 去重與版本控管\n\n## 4. Embeddings\n選一個：\n- Sentence Transformers\n- Hugging Face embeddings\n- Jina embeddings\n- Nomic embeddings\n\nembeddings 責任：\n- 把 chunk 轉成 vector\n- 固定模型版本\n- 模型變更時重新 embedding\n\n## 5. Vector DB\n選一個：\n- pgvector：Postgres-first\n- Weaviate：schema-aware\n- Milvus：大規模部署\n- Chroma：快速原型\n- Pinecone：託管服務\n\nVector DB 責任：\n- 存 vector 與 metadata\n- 支援 similarity search\n- 支援 filter\n- 更新要可觀測\n\n## 6. Retrieval \u002F Ranking\n選一個或組合：\n- FAISS：快速 similarity search\n- Elasticsearch：keyword + vector hybrid\n- Haystack：模組化 retrieval pipeline\n- Weaviate：內建 retrieval\n- Jina AI：neural \u002F multimodal search\n\nRetrieval 責任：\n- top-k 檢索\n- metadata filter\n- rerank\n- 去重\n- 記錄 retrieval 品質\n\n## 7. LLM Orchestration\n選一個：\n- LangChain：tool use \u002F agent\n- LlamaIndex：文件導向 RAG\n- Haystack：端到端 pipeline\n- Semantic Kernel：Microsoft 生態\n- Hugging Face：模型整合\n\nOrchestration 責任：\n- 用檢索結果組 prompt\n- 管理 memory（如果需要）\n- 呼叫工具（如果需要）\n- 控制輸出格式\n\n## 8. Model Layer\n選一個：\n- LLaMA\n- Mistral\n- Gemma\n- Phi-2\n- DeepSeek\n- Qwen\n\nModel 責任：\n- 根據 context 生成答案\n- context 不足時拒答\n- 控制 latency 與 cost\n\n## 9. 最小驗收清單\n- 檢索回來的是對的 chunk\n- 答案有來源\n- 缺資料時不亂編\n- 更新後能正確反映\n- 前端有清楚失敗狀態\n- 延遲在可接受範圍\n\n## 10. 建置順序\n1. 先把 ingestion 做對\n2. 再做 embeddings\n3. 再存進 vector DB\n4. 再做 retrieval \u002F ranking\n5. 再接 LLM orchestration\n6. 再做 frontend\n7. 最後補 evaluation \u002F monitoring\n\n## 11. 一句話原則\n先修壞掉的那一層，不要急著換模型。\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板我會直接丟給團隊用。它不炫，但很實際。你如果照這個順序做，至少不會一開始就把自己帶進死胡同。\u003C\u002Fp>\u003Cp>我喜歡這篇 Plain English 的地方，是它把 RAG 的地圖畫出來了；我加上的部分，是把這張地圖變成可以開工的順序。你不需要一次選對所有東西，你只需要先把最容易壞的那層修好。\u003C\u002Fp>\u003Cp>來源：\u003Ca href=\"https:\u002F\u002Fplainenglish.io\u002Fartificial-intelligence\u002Fthe-open-source-rag-stack-a-complete-guide-to-building-retrieval-augmented-generation-systems\">https:\u002F\u002Fplainenglish.io\u002Fartificial-intelligence\u002Fthe-open-source-rag-stack-a-complete-guide-to-building-retrieval-augmented-generation-systems\u003C\u002Fa>。七層拆解與工具\u003Ca href=\"\u002Fnews\u002Fgithub-rag-production-list-battle-tested-tools-zh\">清單\u003C\u002Fa>主要來自 Sarah Morino；上面的 build plan、判斷順序和模板是我自己的整理與改寫。\u003C\u002Fp>","拆開七層開源 RAG 堆疊，從 ingestion 到 frontend，直接拿去做自己的 build plan。","plainenglish.io","https:\u002F\u002Fplainenglish.io\u002Fartificial-intelligence\u002Fthe-open-source-rag-stack-a-complete-guide-to-building-retrieval-augmented-generation-systems",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780872500382-6ang.png","tools","zh","267be20a-b87f-45fd-a6ec-79d136955b91",[17,18,19,20,21,22],"RAG","retrieval","vector database","LangChain","Haystack","ingestion",[24,25,26],"RAG 不是單一架構，而是七層要逐一排查的系統。","前端、ingestion、retrieval 往往比模型本身更決定成敗。","先修壞掉的那層，再換模型；這份模板可以直接拿去開工。",2,"2026-06-07T22:47:55.345265+00:00","2026-06-07T22:47:55.334+00:00","c3c88dd2-a940-438a-b359-0e5a24562273",{"tags":32,"relatedLang":42,"relatedPosts":46},[33,35,37,38,40],{"name":17,"slug":34},"rag",{"name":20,"slug":36},"langchain",{"name":18,"slug":18},{"name":21,"slug":39},"haystack",{"name":19,"slug":41},"vector-database",{"id":15,"slug":43,"title":44,"language":45},"open-source-rag-stack-build-plan-en","Open Source RAG Stack Turns Chaos Into a Build Plan","en",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"4f0b90ab-f554-474e-9efd-ecec55257302","github-rag-production-list-battle-tested-tools-zh","GitHub 49 星 RAG 生產清單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780870666920-t0hc.png","2026-06-07T22:17:20.22268+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"698981d2-c844-4ee0-ba64-cc9a328deb3c","how-to-build-akiraos-wasm-apps-for-zephyr-zh","怎麼做 AkiraOS WASM 應用","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780862577242-1x6z.png","2026-06-07T20:02:24.454909+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"92c5ded8-bdc6-4214-b78f-2f4f94cea6b4","foundry-mcp-remote-tools-agent-endpoint-zh","Foundry MCP 把工具收斂成一個端點","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780848206168-1rf3.png","2026-06-07T16:02:57.749167+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"cf222858-e879-4aef-9dab-1a7c80871f27","leverage-meaning-no-more-buzzword-mistakes-zh","Leverage 讓你少講廢話","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780804995915-2q93.png","2026-06-07T04:02:47.319705+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"34162763-ffe3-416d-a719-e450ba87ac3d","llm-leaderboard-2026-300-models-ranked-zh","2026 LLM 排行榜：309 模型怎麼選","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780776191145-786j.png","2026-06-06T20:02:36.847112+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"09c2902c-97a8-433c-94de-874a7f55d2ff","llama-benchy-api-benchmark-zh","llama-benchy 把 API 也納入基準測試","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780775303246-184z.png","2026-06-06T19:47:53.968325+00:00",[84,89,94,99,104,109,114,119,124,129],{"id":85,"slug":86,"title":87,"created_at":88},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":125,"slug":126,"title":127,"created_at":128},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":130,"slug":131,"title":132,"created_at":133},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]