Production RAG 系統實戰：從 PoC 到上線的 8 個關鍵技術選型決策

你的 RAG 在 PoC 表現 87%、上線卻只剩 41%——是模型不夠強嗎？

這個問題答錯的公司，2026 年至少燒了 NT$ 200 萬以上。問題的根源是你在 PoC 階段用「乾淨的 50 份文件」測，到了生產卻塞了「2 萬份格式不一、版本混亂、編碼錯誤」的真實資料，模型本身並沒有錯。RAG 系統的成敗——80% 在資料工程，15% 在檢索策略，5% 才是 LLM 本身。

這篇要拆解的，不是又一篇「什麼是 RAG」入門文（我們已經有 企業 AI RAG 架構入門 把基礎概念講過了），而是 PoC 到 Production 之間，8 個會把專案推進地獄、也可能救回專案的關鍵技術決策。如果你正在規劃要不要外包客製化 RAG 系統、或內部團隊正在卡關，這篇是給技術主管和有技術背景的老闆看的。

PoC 跑得很好、上線就崩——9 成團隊踩過的第一個坑

典型的故事是這樣：團隊花 2 週用 50 份產品文件、500 個測試問題做 PoC，準確率 85%。老闆拍板「上吧」，工程師花 3 個月把 2 萬份文件灌進系統，上線第一週客服回報「答案不對」。團隊查了一週才發現問題不在模型——是 chunk 切錯、metadata 沒帶、retrieve 回來的根本不是相關文件。

看 LlamaIndex 官方 Production RAG 指南 的數據——從 PoC 到 Production，檢索準確率平均掉 38%、回答品質掉 24%、延遲增加 3.4 倍。如果你的團隊在 PoC 階段沒模擬「資料髒、量大、版本混亂」的環境，這 3 個指標下跌幾乎是必然。

決策 1：Embedding 模型選型——OpenAI、開源、自訓練的三選一

Embedding 是 RAG 的眼睛。眼睛看錯了，後面再怎麼努力都白搭。2026 年市面上的選擇大致分 3 派——

務實建議：90% 的中小企業用 BGE-M3 就夠。免費、中文 SOTA、可商用、能在 1 張 RTX 4090 上跑。除非你有強領域術語（如台積電的製程術語、醫療的特殊縮寫），不然不用考慮自訓練。OpenAI Embedding 適合「我就是想要最方便、token 費小事」的純技術 PoC 階段。

決策 2：向量資料庫——4 個主流選項對比

選錯向量資料庫，1 年後想換要遷移幾百萬筆向量資料，工程成本可能比一開始就選對多 10 倍。

我們最近 6 個客戶選了 4 種不同方案——選擇邏輯通常是：「已經在用 Postgres、量級不大」→ pgvector；「想用 SaaS 省事、預算夠」→ Pinecone；「要自架、追求性能」→ Qdrant。Weaviate 在台灣案例反而少，主要用在歐美做圖文混合檢索的場景。

決策 3：Chunking 策略——把文件切壞，後面再強都救不回

Chunking 是把長文件切成小片段塞進向量庫的過程。切壞了，檢索就會回給你「半個答案」。常見策略有 3 種——

• 固定大小切（Fixed-size）：每 500 token 切一刀。最簡單、最容易上線，但會把一句話切成兩半。適合 PoC 與規格固定的技術文件。
• 語意切（Semantic chunking）：用 embedding 相似度判斷「話題轉折處」切。品質最好，但需要先跑一次 embedding，速度慢、成本高。
• 階層切（Hierarchical / Parent-child）：父 chunk 大（如整章節）、子 chunk 小（如段落）。檢索時用子 chunk 找精準位置，回傳父 chunk 給 LLM 確保上下文完整。這是 2026 年 production 最常用的策略。

實務上我們的預設組合是：「階層切 + chunk 之間 overlap 10%」。Overlap 是為了避免「答案剛好在切割線上」的窘境。預算夠就上 Semantic Chunking，不夠就用固定大小但 chunk 設小一點（300 token）+ 大 overlap（20%）。

決策 4：檢索策略——光靠向量檢索是新手錯誤

這是 80% 團隊的盲點。光用「向量檢索 Top-K」做 RAG 是 2023 年的水準，2026 年的 production 系統一定要疊三層——

為什麼非要這樣？純向量檢索遇到「同義詞、罕見專有名詞、產品編號」會崩潰。例如使用者問「A-1024 規格」，純向量檢索可能找到一堆「規格相關」但不是 A-1024 的文件——因為向量模型對「A-1024」這種編號沒有語意理解。加上 BM25 關鍵字檢索後，A-1024 就能準確命中。

Reranker 的角色是「最後守門員」。用 BGE Reranker 或 Cohere Rerank 把 20 個候選排序，挑最相關的 Top 5 給 LLM。實測下來，加 Reranker 可以讓回答品質提升 35%，但會增加 100-300ms 延遲——大多數場景值得付這個代價。

決策 5：框架選擇——LangChain、LlamaIndex、DSPy、還是自己刻

這是技術主管問最多的問題。先說結論：2026 年的最佳實踐是「LlamaIndex 做資料層 + LangGraph 做 orchestration + 自寫一層薄薄的 wrapper」。

看 Pragmatic Engineer 2026 AI 工程趨勢 的觀察——大多數 production 團隊採用「LlamaIndex + LangGraph」混搭，並非 100% 選一個框架，因為兩者強項剛好互補。如果你要外包客製化 RAG 系統，問外包商「你們怎麼配 LlamaIndex 跟 LangGraph」就能快速判斷他們有沒有真正做過 production。

決策 6：監控——3 個指標不看，你不知道系統什麼時候在爛

RAG 系統上線後最危險的是「悄悄變爛」——回答品質慢慢下滑、使用者慢慢不信任、半年後才發現問題，crash 反而是其次。三個必看指標——

• 指標 1：檢索精度（Retrieval Precision@K）。每次回應抽樣 5%，問「Top 5 結果裡，真的跟問題相關的有幾個」。用另一個 LLM 自動評分。低於 0.7 就要警報。
• 指標 2：幻覺率（Hallucination Rate）。回應內容跟檢索到的文件是否一致。用 LLM-as-a-judge 評分，標準是「回應中每個事實聲明都能在文件找到對應」。幻覺率超過 5% 就要修。
• 指標 3：成本／請求（Cost per Query）。Embedding + 檢索 + LLM 的 token 加總。記錄每個查詢的真實成本，月底回頭看異常值——通常會發現有些長 prompt 在燒錢。

決策 7：RAG vs Fine-tuning——什麼時候該停止做 RAG

RAG 不是萬能的。有些場景 fine-tuning 才對。判斷標準有 3 條——

業界 RAG vs Fine-tuning 落地的觀察顯示，大約 80% 的需求其實只需要 RAG。需要 fine-tuning 的多半是「特定領域有大量範本」的場景——例如律師事務所要訓練 AI 寫起訴狀的特定格式、製造業要訓練 AI 寫技術規格書。AI 模型 Fine-tuning 是什麼？跟 RAG 差在哪？ 那篇把成本與決策邏輯拆得更細，可以對著看。

決策 8：客製化 RAG 系統的報價區間——3 個級距告訴你別被坑

如果你要外包做 RAG 系統，這是 2026 年台灣市場的真實報價——

被報過 30 萬以下、號稱「企業級 RAG」的，多半是把 ChatGPT 包一層 UI；被報過 800 萬以上、卻沒有明確 SLA 與監控指標的，多半是廠商在養人。中間區間 NT$ 80-250 萬最值得認真評估——這個區間能做出真正堪用的 production RAG。

實作參考：一個最小可運作的 Hybrid RAG 骨架

最後給一個 Python 骨架，你可以拿去當 PoC 起點。這個範例用 LlamaIndex + Qdrant + BGE-M3，跑得起來且具備 production 結構——

from llama_index.core import VectorStoreIndex, StorageContext, Settings
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
from llama_index.vector_stores.qdrant import QdrantVectorStore
from llama_index.core.retrievers import VectorIndexRetriever, BM25Retriever
from llama_index.core.postprocessor import SentenceTransformerRerank
from qdrant_client import QdrantClient

Settings.embed_model = HuggingFaceEmbedding("BAAI/bge-m3")
client = QdrantClient(host="localhost", port=6333)
vstore = QdrantVectorStore(client=client, collection_name="kb")
storage = StorageContext.from_defaults(vector_store=vstore)

index = VectorStoreIndex.from_documents(documents, storage_context=storage)

vec_retriever = VectorIndexRetriever(index=index, similarity_top_k=20)
bm25_retriever = BM25Retriever.from_defaults(docstore=index.docstore, similarity_top_k=20)
reranker = SentenceTransformerRerank(model="BAAI/bge-reranker-large", top_n=5)

# Hybrid 查詢
def query(q):
    vec_nodes = vec_retriever.retrieve(q)
    bm_nodes = bm25_retriever.retrieve(q)
    fused = dedupe(vec_nodes + bm_nodes)
    reranked = reranker.postprocess_nodes(fused, query_str=q)
    return reranked[:5]

這 30 行程式碼是 production RAG 的「最小可行架構」，但離真正可上線還差：(1) 監控、(2) 錯誤處理、(3) 快取、(4) 權限控制、(5) 評估 pipeline。這些往上加才是真功夫，也是「外包報價 60 萬 vs 180 萬」的差距所在。

Production RAG 常見問題

下一步：開啟 RAG 專案的 3 個務實建議

• 先選 1 個高價值場景做 PoC，例如「客服 FAQ 自動回應」或「技術文件問答」。把你最常被問的 100 個問題列出來，當 PoC 評估標準。
• PoC 階段就要灌真實髒資料，不要只用乾淨樣本。模擬「跨部門資料、不同版本、不同格式」的環境，這樣 PoC 數字才能反映 production。
• 選外包商時，問三個技術問題：(1) 你們怎麼處理 chunk overlap？(2) Reranker 用哪一個？(3) 監控指標怎麼設？能秒答的多半真有 production 經驗，支吾的就先別簽。

延伸閱讀：企業自建 LLM 完整技術路徑、LLM Evals 完整指南、MCP 是什麼？老闆採購 AI 系統必懂。