建一條 RAG Pipeline 之前，你需要做的六個技術決策
一條 RAG pipeline 不難，難的是每一步都要做選型決策。Chunking 怎麼切、Embedding 用哪個模型、向量資料庫選哪家、搜尋策略怎麼配 — 六個技術決策的考量過程、選擇理由和 trade-off 完整記錄。
為什麼技術決策比實作更重要？
RAG pipeline 的程式碼本身不複雜。用 Python 寫一條「文件 → 切段 → embedding → 存向量資料庫 → 搜尋 → 組 prompt → LLM 回答」的 pipeline，幾百行就能跑起來。
但每一步都有選型要做，每個選擇都有 trade-off。選錯一個環節，後面的效果再怎麼調都有天花板。這篇記錄我在建置 RAG pipeline 時做的六個關鍵決策，重點不是最終選了什麼，而是為什麼這樣選、犧牲了什麼、什麼情況下該換別的方案。
Pipeline 架構長這樣：知識庫文件經過 chunker 切段、indexer 建立索引存入 ChromaDB，查詢時透過 Hybrid Search（向量 + BM25 + RRF 合併）找出最相關的段落，組成 prompt 交給 LLM 回答。
決策一：Chunking 策略 — 混合式切割
考慮了什麼
四種主流切割方式：
- 固定長度：每 N 個字元切一段。簡單暴力，但可能把一個完整概念切成兩半。
- 按標題切割：用 Markdown 的
##標題當分隔點。保留語義完整性，但如果標題下的內容太長或太短，段落大小差異會很大。 - 語義切割：用 embedding 偵測語義轉折點來切。效果最好但計算成本高，而且容易在短文件上過度切割。
- 混合式：先按標題切，超過上限的段落再用固定長度切。兼顧語義完整性和段落大小一致性。
選了什麼、為什麼
選混合式（Markdown 標題 + 固定 500 字元）。原因是我的知識庫有兩種截然不同結構的文件：中文 blog 文章是長段落、少標題，英文技術文件是短段落、多標題。純固定長度會把英文技術文件的標題結構打碎，純標題切割會讓中文長段落產生過大的 chunk。混合策略能兼顧兩者。
犧牲了什麼
比純固定長度多一層邏輯，而且部分段落可能在標題處被不自然切斷。但在中英文混合的知識庫裡，這是最平衡的選擇。
決策二：Chunk Size — 500 字元 + 100 字元 Overlap
考慮了什麼
Chunk 太大：每個段落包含太多主題，搜尋時容易匹配到段落裡的雜訊而非核心內容。而且大 chunk 佔用更多 context window。
Chunk 太小：失去上下文，一個段落可能只包含一個句子的碎片，語義不完整。搜尋到了也不知道它在講什麼。
Overlap 的作用：相鄰段落重疊一部分內容，確保被切斷的句子至少在某個段落裡是完整的。
選了什麼、為什麼
500 字元 + 100 字元 overlap 作為起步點。理由是中文每個字元的資訊量比英文高（一個中文字約等於 2 個英文字元的語義量），500 字元的中文大約等於英文 1000 字元的資訊量。加上最小 chunk 門檻設 50 字元，低於這個長度的碎片會被合併到前一段，避免產生無意義的索引。
犧牲了什麼
長段落的上下文可能被切碎。如果一個技術概念跨了 800 字元，500 字元的 chunk 會把它切成兩段，搜尋時只找到一半。這是後續優化的重點 — 要測試 300 和 800 字元的效果差異。
決策三：Embedding Model — multilingual-MiniLM
四個候選方案
| 模型 | 維度 | 中文支援 | 成本 | 備註 |
|---|---|---|---|---|
| all-MiniLM-L6-v2 | 384 | 弱 | 免費本地 | 英文最熱門，但中文效果差 |
| multilingual-MiniLM-L12-v2 | 384 | 良好 | 免費本地 | 50+ 語言支援，社群廣泛使用 |
| bge-m3 | 1024 | 優秀 | 免費本地 | 效果最好但模型大、速度慢 |
| jina-v3 | 1024 | 優秀 | API 付費 | 效果好但需要外部 API 呼叫 |
選了什麼、為什麼
選 paraphrase-multilingual-MiniLM-L12-v2。四個理由：第一，中英文雙語支援良好，我的知識庫是中英混合；第二，384 維向量夠輕量，在 CPU 上 22 秒就能處理 1,880 個 chunks（85.8 chunks/s）；第三，完全免費本地執行，不需要 API key；第四，社群廣泛使用，踩坑的機率低。
犧牲了什麼
效果不如 bge-m3 或 jina-v3。384 維的向量在語義細節上的表達能力不如 1024 維。但在 PoC 階段，速度和免費比效果更重要 — 先跑通再說，確認 pipeline 可行後再升級模型。
決策四：向量資料庫 — ChromaDB
三個候選
| 方案 | 特性 | 適合場景 | 成本 |
|---|---|---|---|
| FAISS | 純 library，要自己管儲存 | 嵌入到現有系統 | 免費 |
| ChromaDB | 輕量資料庫，本地跑，內建持久化 | PoC、小型專案 | 免費 |
| Pinecone | 雲端託管，免運維 | 生產環境、大規模 | 付費 |
選了什麼、為什麼
選 ChromaDB（PersistentClient）。理由：本地免費、Python 原生整合好（一行 code 就能建 collection）、內建持久化不用自己管資料儲存、在 PoC 規模（< 10K 文件）下效能完全夠用。1,880 個 chunks 的 ChromaDB 只佔 11.2 MB。
犧牲了什麼
不適合生產環境大規模部署。如果未來知識庫成長到百萬級文件，需要換到 Pinecone、Weaviate 或 Qdrant。但在驗證階段，花錢上雲端服務是浪費 — 先確認 RAG 在你的場景有效，再投資基礎設施。
決策五：搜尋策略 — Hybrid Search（向量 + BM25 + RRF）
三個選項
- 純向量搜尋：只用 embedding 的語義匹配。擅長同義詞和意思相近的查詢，但對特定名詞（API 名稱、版本號）可能失準。
- 純 BM25：只用關鍵字匹配。對精確名詞很強，但語義歧義致命 — 同一個中文詞在不同語境含義完全不同。
- Hybrid：向量 + BM25 各自找 top-20，用 RRF（Reciprocal Rank Fusion，k=60）合併成最終 top-K。
選了什麼、為什麼
選 Hybrid。在之前的 baseline 實驗中，純關鍵字搜尋在中英文混合知識庫上只拿 59 分（滿分 100），跨文件問題崩壞到 1.80 分。語義歧義是致命傷。Hybrid 讓向量搜尋處理語義、BM25 處理精確匹配，RRF 合併時只用排名不用分數，繞過了兩種搜尋分數量級不同的問題。
BM25 實作用 rank_bm25（BM25Okapi），輕量純 Python，不需要額外服務。RRF 的 k=60 用原論文建議值，沒有針對本知識庫調優。
犧牲了什麼
比純向量多一層 BM25 計算和 RRF 合併，但在 1,880 chunks 的規模下完全感受不到延遲。真正的犧牲是 BM25 的索引不支援即時更新，每次新增文件需要重建 — 在 PoC 階段可以接受，生產環境可能需要換 ElasticSearch。
決策六：Top-K — 先用 5
三個選項的 trade-off
- Top-3：資訊量少、噪音低。適合答案集中在單一段落的問題。但跨文件問題幾乎不可能只用 3 段回答完整。
- Top-5：平衡點。大部分單一文件問題夠用，部分跨文件問題也能覆蓋。
- Top-10：資訊量大，跨文件覆蓋率高。但噪音也多 — 不相關的段落可能誤導 LLM。
選了什麼、為什麼
初始選 Top-5。向量搜尋和 BM25 各自取 top-20 做為 RRF 的候選池，RRF 合併後取最終 top-5 送進 LLM。5 是一個安全的起步點 — 在之前的 baseline 中，top-5 的關鍵字搜尋已經能處理大部分 Type A 問題，只是在跨文件問題上不夠。
犧牲了什麼
如果答案分散在超過 5 個段落中（Type B 跨文件問題常見），會遺漏關鍵資訊。這是後續優化的第一個方向 — 增加到 top-10 看跨文件問題是否改善。
實際數據：Pipeline 跑起來長什麼樣
| 指標 | 數值 |
|---|---|
| 知識庫文件數 | 200（成功處理 199，1 個因 Windows 長檔名跳過） |
| 總 chunks 數 | 1,880 |
| 平均 chunk 長度 | 308 字元 |
| Embedding 維度 | 384 |
| Embedding 耗時 | 約 22 秒（CPU，85.8 chunks/s） |
| ChromaDB 大小 | 11.2 MB |
整條 pipeline 從文件到可查詢狀態，不到一分鐘。這就是在 PoC 階段選擇輕量方案的好處 — 快速迭代，發現問題馬上調整，不用等半小時的 embedding 跑完。
我的觀點
六個決策裡，有一個共同的邏輯：先選能跑的，再選跑得好的。
Embedding 用 multilingual-MiniLM 而非 bge-m3，因為先要驗證 pipeline 可行。向量資料庫用 ChromaDB 而非 Pinecone，因為 PoC 不該花錢在基礎設施上。Chunk size 用 500 開始，因為要有一個 baseline 才知道調大調小會怎樣。
每個「先用這個」的背後，都有一個「什麼時候該換」的判斷。當 multilingual-MiniLM 的語義精度不夠時，升級 bge-m3。當 ChromaDB 的查詢效能在百萬級文件下變慢時，換 Pinecone。當 top-5 讓跨文件問題遺漏太多時，增加到 top-10。
技術選型不是一次性決策，而是一系列「目前最佳 + 已知的升級路徑」。怕的不是選錯，怕的是選了之後不知道什麼時候該換。
常見問題 FAQ
這些選型適用於所有 RAG 專案嗎？
不是。這些選型是針對一個 200 份文件、中英文混合、PoC 階段的知識庫。如果你的知識庫是純英文、百萬級文件、需要即時更新，每個決策的最佳選擇都會不同。但決策框架是通用的：先搞清楚你的資料特性，再選方案。
為什麼不直接用最好的模型和工具？
因為 PoC 階段的目標是驗證可行性，不是追求最佳效果。用最好的模型但 pipeline 設計有問題，效果一樣差。先用輕量方案跑通整條路，確認瓶頸在哪，再針對瓶頸升級。這比一開始就全上頂配然後發現方向錯了要省時省錢。
Hybrid Search 比純向量搜尋好多少？
在我的測試中，Hybrid Search（77 分）比純關鍵字搜尋（59 分）高 18 分。跟純向量搜尋的比較還沒做，但從 baseline 數據推斷，純向量在精確名詞搜尋上會比 Hybrid 弱。Hybrid 的成本（多一層 BM25）在千級 chunks 規模下可以忽略，所以預設選 Hybrid 幾乎沒有缺點。