企業 AI RAG 架構入門：知識庫怎麼蓋才不會幻覺

82%。這是 LLM 在沒有外部資料輔助時，最高被測得的事實錯誤率。

不靠檢索的純 LLM 會幻覺，這件事 2026 年沒有人會再爭論了。真正在公司裡掙扎的問題已經換了——同樣是要做 AI 客服、內部知識問答、智能合約查詢，為什麼隔壁公司用 RAG 把幻覺壓到 5% 以下，你們的 PoC 卻一路停在 25% 還在繞圈？答案幾乎都不在 LLM 本身，而是回到「知識庫怎麼蓋」這件最不性感、卻最關鍵的事。

根據 Gartner 2026 年的預測，超過 70% 的企業生成式 AI 專案會需要結構化的檢索 pipeline 來控制幻覺與合規風險，並有超過 30% 企業會導入向量資料庫來補強基礎模型。市場的方向已經很明確——RAG 的核心問題是怎麼做才不會做到一半變垃圾資料堆，「要不要做」反而早已不是議題。

這篇我們不講「RAG 是什麼」這種維基百科等級的內容，直接帶你走完一遍企業級 RAG 架構從 0 到上線會遇到的所有節點：資料清洗、chunking、embedding、向量檢索、re-rank、最後接 LLM 生成。每一段都附 2026 最新的 benchmark、踩坑案例，以及恆遠在自家秒發報價、開課王上實作 RAG 累積的經驗。看完你不會變成 RAG 工程師，但你會看得懂工程師的進度報告，知道哪裡是真的卡關、哪裡是在拖延。

先把 RAG 從神壇上請下來：它解決的就是一件事

RAG（Retrieval-Augmented Generation，檢索增強生成）的本質很單純——先把問題拿去你的資料庫找答案，再把答案塞進 prompt 給 LLM 整理輸出。做這件事的目的只有一個：讓 LLM 講話有依據，不要自由發揮。

為什麼非做不可？Google 的研究指出，RAG 在正確實作下可以讓 LLM 幻覺率下降 71%；MEGA-RAG 的學術 benchmark 也測得超過 40% 的幻覺降幅。但這些數字有個前提——「正確實作」。實作不對，幻覺率甚至比純 LLM 還慘，因為你給了它錯誤的資料還叫它根據資料回答。

我們在恆遠看過最痛的一次，是某客戶把自家 5 年的客服紀錄（裡面有大量錯誤訊息、過期政策、員工互相抱怨的內部訊息）一股腦丟進向量資料庫，然後問 AI「我們的退換貨政策是什麼」。AI 給出了 2021 年早就廢棄的版本，還引用得有模有樣。客戶當下覺得 AI 很爛，其實爛的是知識庫——garbage in, garbage out 不是新概念，但在 RAG 的世界裡放大十倍。

所以，蓋知識庫的真正關鍵是要先想清楚：誰來問、問什麼、答錯的代價多大；把文件丟到一個地方只是表面動作。代價越大（醫療、金融、法務），整個 pipeline 就要越嚴謹；代價輕微（FAQ 客服首問分流），可以從便宜的版本起步。這個判斷不做，後面所有技術選型都會變成蒙著眼睛抽籤。

企業真實踩過的雷：5 個你會在 PoC 後期才發現的坑

我們從 PTT、Reddit r/LocalLLaMA、知乎、IBM 的調查，整理出 5 個老闆最容易在 PoC 結束、準備上線時才發現的痛點。如果你的 RAG 專案進度卡住，幾乎一定是其中之一在搞事。

這 5 個痛點是 RAG 架構複雜度被低估的必然後果，而非工程師偷懶。Reddit 上有個常被提到的數字——根據從業者實測，80% 的 RAG 失敗源自 ingestion（資料攝入）和 chunking 階段沒做好，跟 LLM 強不強的關聯反而很小。也就是說，你買最貴的模型也救不了亂七八糟的知識庫。

企業級 RAG 架構六層拆解：每一層都有可能崩

我們先把整張地圖攤開來看。一個能撐住企業流量的 RAG 系統，從文件進來到答案出去，最少有六個關鍵階段。下面這張圖是恆遠在內部專案 SOP 上用的標準參考架構，每一格都對應一個會花錢、會出包、會被工程師偷工的環節。

看起來複雜，其實每一層的職責很清楚：左半邊（A→E）是離線的「蓋知識庫」，右半邊（F→K）是即時的「服務查詢」，最下面那條虛線是「持續改善」。三條軸缺一不可，少一條就會出問題——只蓋不查就是死資料、只查不改就是停滯品質。

Chunking 是整個 RAG 的命脈：切壞了後面再強都救不回來

Chunking 就是把長文件切成一塊塊餵進向量資料庫。聽起來很簡單，但 NVIDIA 的研究、Microsoft Azure 的 RAG 指南 都把 chunking 列為對檢索精度影響最大的單一變因——一個 2025 年的醫療臨床決策研究顯示，自適應 chunking 達到 87% 準確率，固定大小切片只有 13%。

先說結論：不要用 LangChain 預設的 RecursiveCharacterTextSplitter 然後就交差。那只是 demo 等級的入門配置，企業真實文件（合約、SOP、產品手冊）切完通常會把語意切碎到難以辨識。

三種主流 chunking 策略怎麼選

業界的共識是，chunk 大小落在 300-800 tokens、overlap 設 10-20% 是大多數場景的安全起步點。但這只是起手式，真實案例中我們經常需要為不同類型文件用不同切片策略，再合併進同一個向量庫。

以下是恆遠在客戶專案上常用的中文 chunking 程式範例（搭配 langchain + 自家寫的中文標點 splitter）：

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 為中文客製的分隔符優先序：句號 > 問號驚嘆 > 逗號 > 換行
zh_separators = ["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""]

splitter = RecursiveCharacterTextSplitter(
    chunk_size=600,            # 中文約 300-400 字
    chunk_overlap=100,         # 約 17%
    separators=zh_separators,
    keep_separator=True,
    is_separator_regex=False,
)

# 重點：metadata 要帶完整溯源資訊，方便之後做 row-level 權限與引用
chunks = splitter.create_documents(
    texts=[long_doc_text],
    metadatas=[{
        "source": "policy/refund_v3.pdf",
        "section": "退換貨條款",
        "version": "2026-Q2",
        "owner_dept": "客服部",
        "access_level": "internal",
    }],
)

Embedding 與向量資料庫：你不需要 Pinecone，除非你有那個量

Embedding 是把文字變成向量的步驟，也是大家最容易把錢花錯地方的階段。市面上主流選擇有 OpenAI text-embedding-3-large、Cohere embed v3、開源的 BGE-M3 與 multilingual-e5——選哪個，真正該看的是「中文支援度」與「能不能私有部署」，benchmark 高低反而是其次。

向量資料庫的選型則是另一個無謂被妖魔化的議題。LeanOps 2026 年的 Vector DB 成本比較 的數字很直白——10M 向量的規模下，Pinecone Serverless 約 $70/月、Qdrant Cloud 約 $65/月、pgvector 跑在 RDS 上 $45/月。但是規模拉到 100M，Pinecone 會直接衝到 $700+/月，自架 Qdrant 或 pgvector 還能壓在 $100/月以下。

恆遠絕大多數的客戶專案都是從 pgvector 起手，等規模超過 5M 向量再考慮遷移到 Qdrant。 原因很簡單——客戶通常已經在用 Postgres 存業務資料，pgvector 讓向量查詢可以直接 JOIN 業務表，省掉同步層的維運。在你還搞不清楚向量資料夠不夠多、查詢頻率多高之前，硬上 Pinecone 就是把錢丟進空調機裡。

檢索層的真相：純向量搜尋已經不夠用了

2024-2025 年大家都說「dense retrieval（向量搜尋）取代 BM25」，但 VentureBeat 2026 年 Q1 的調查 顯示企業導入 hybrid retrieval 的意願從一季前的 10.3% 跳到 33.3%——三倍成長。純向量搜尋在企業真實資料上會輸給好好調過的 BM25。

最有說服力的是金融文件 QA 的 最新 benchmark：在 23,088 個真實查詢上，hybrid（BM25 + dense）+ cross-encoder reranker 的兩階段管線，Recall@5 達到 0.816，比純 hybrid 高 17.4%、比純 BM25 高 26.7%、比純 dense 高 39%。

這代表什麼？dense retrieval 適合處理「同義詞、語意相近」的查詢；BM25 適合處理「精確關鍵字、產品型號、人名」的查詢。企業文件兩種需求都有，所以要兩種都用。實作上有幾個選擇：

• 用支援原生 hybrid search 的向量庫（Weaviate、最新版 Qdrant）

• 自行用 RRF（Reciprocal Rank Fusion）合併兩條檢索結果

• 上 Cohere Rerank v4.0 / BGE-Reranker-v2-m3 做最終 re-ranking

Reranker 是被低估的投資報酬率王者

根據前面提到的金融 QA benchmark，加上一層 cross-encoder reranker 帶來的提升是 MRR@3 +17.2pp、Recall@5 +12.1pp。這是整個 RAG pipeline 裡單筆投資 ROI 最高的環節之一——多花一個 API call 的錢，換到接近 +20% 的精度。

實務上 Cohere Rerank 的成本是每 1K tokens 約 $0.001，企業級流量下一個月通常落在 $50-300 區間，比起換更貴的 LLM、買更貴的向量庫，這一層的回報明顯。

LLM 生成層：prompt 寫不好，前面再強都白搭

檢索到對的資料，不代表 LLM 就會老實照講。如果你的 prompt 沒有明確要求「只能根據提供的資料回答、無法回答時要說『我不知道』」，LLM 還是會自由發揮——這也是為什麼 法律與醫療領域的 RAG 系統 還有 6-33% 的幻覺率。

以下是恆遠在多個客戶專案中演化出來的 RAG prompt 範本，真正的重點是把「該禁止什麼」講得夠清楚，寫得漂不漂亮反而是其次：

SYSTEM_PROMPT = """你是 {company_name} 的內部知識助理。

【嚴格規則】
1. 你只能根據以下標記為「資料庫片段」的內容來回答問題。
2. 如果資料庫片段中沒有問題的答案，你必須回答：
   「我在現有的知識庫中找不到這個問題的明確答案，建議您聯絡 {fallback_contact}。」
3. 不要根據你的訓練資料、常識、或推測來補充內容。
4. 每一個重要事實後面都要附上引用編號，例如 [1]、[2]。
5. 如果不同片段內容衝突，明確指出衝突，並列出各自來源。

【資料庫片段】
{retrieved_chunks_with_index}

【使用者問題】
{user_question}

請根據規則回答。"""

# 實作上的 grounding 檢查：生成後再用一個小模型驗證
def grounding_check(answer: str, chunks: list[str]) -> float:
    """回傳 0-1 分數，<0.7 就觸發 fallback 流程"""
    pass

Naive vs Advanced vs Modular RAG：你公司現在該蓋哪一種

RAG 架構這幾年演化得很快。Zilliz 與多家研究機構整理 把 RAG 分成三代：

我們的建議很直接：第一個 RAG 專案就用 Advanced RAG。 Naive RAG 看起來便宜，但幻覺率太高、PoC 過了上線就翻車。Modular RAG 又太重，沒有清楚場景就搞編排會做出維運惡夢。Advanced RAG 是企業 80% 場景的甜蜜點。

從恆遠自家專案看：知識庫蓋對能省多少業務成本

我們在 秒發報價系統 內部就跑了一套小型 RAG，用來回答業主常問的「合約條款怎麼寫」「報價單格式怎麼挑」。導入前後的數字很有感：

這套方案是恆遠用 pgvector + Cohere Rerank + Claude 自己組起來的，並非外購——成本一個月不到 NT$ 4,000，比聘一個半職客服便宜超過 90%。能做這件事，是因為我們把 RAG 當作客製化能力，不是套件。

我們的另一條產品線開課王也用了類似架構，差別是知識庫換成課程內容、學員問答歷史，回答的場景變成「這堂課適不適合我」「這個概念跟之前哪一節有關聯」。同一套架構、不同知識庫、不同 prompt，就能服務完全不同的場景——這也是 RAG 比 fine-tuning 更靈活的關鍵原因。

如果你還在糾結 RAG vs fine-tuning，可以先讀 AI 模型 Fine-tuning 跟 RAG 差在哪，先把成本邏輯搞清楚再決定要不要動工。

沒有評估就沒有改善：用 RAGAS 把品質量化

最後一塊大家最常省略的——評估。RAGAS（RAG Assessment） 已經是 2026 年事實上的業界標準，四個核心指標必須監控：

• Faithfulness（忠實度）：回答有沒有真的根據檢索到的資料。生產環境目標 > 0.9。

• Answer Relevancy（答案相關性）：回答有沒有真的回到問題。目標 > 0.85。

• Context Precision（上下文精度）：檢索回來的資料是不是真的相關。目標 > 0.8。

• Context Recall（上下文召回）：所有相關資料是不是都被找回來了。目標 > 0.8。

實作上不需要每個查詢都評估——我們的做法是每天從生產流量隨機抽 100 筆查詢，用較強的 LLM 當評審跑一次 RAGAS，週報自動產出。如果某項指標掉到目標以下，會回頭檢查是 chunking 出問題、retrieval 出問題、還是 prompt 出問題。沒有這套迴圈，RAG 上線後會慢慢腐爛而你不知道。

給老闆的 6 步落地清單：別讓技術人員自己決定一切

到這邊你應該對 RAG 有了完整的地圖。最後給決策者一份不會踩雷的落地順序，每一步都有「老闆要做的決定」與「工程師要做的事」：

這個流程裡，第 1 步和第 2 步是老闆責任，不能丟給工程師決定。 因為這兩步決定的是「值不值得做」與「能不能做」，技術人員只能告訴你「做得到、做不到」，但「該不該做」是商業判斷。

如果你公司還沒有 AI 工程師、或者你不想先養一個團隊就動手做這件事，找有客製化開發能力的接案公司是合理選擇——但要看對方有沒有真的在自家產品上跑過 RAG，不要找只會做 demo 的。延伸閱讀：客製化 AI 系統開發完整指南、Gemma 3 自架 LLM 指南、AI 導入 ROI 怎麼算。

企業 RAG 知識庫常見問題

結語：RAG 在本質上是知識資產管理問題，而非單純的技術問題

看到這邊你應該已經理解：RAG 的成敗 80% 在資料、20% 在技術。公司有沒有把 5 年累積的客服紀錄、SOP、會議紀錄、產品手冊整理乾淨，比你選 Pinecone 還是 Qdrant 重要十倍。技術選型可以慢慢試，但資料治理沒打底，再貴的架構都救不回來。

如果你已經想清楚要做、但團隊裡沒有人有實戰經驗，找一個真的在自家產品上跑過 RAG 的合作夥伴會比自己摸索快很多。我們在恆遠的秒發報價、開課王上實際運作的 RAG 系統，每天處理上千筆查詢，幻覺率穩定壓在 3% 以下——這套經驗能直接套到你公司的場景上。

延伸閱讀：企業 AI 導入完整指南 / Fine-tuning vs RAG 成本決策 / AI 導入 ROI 怎麼算 / 客製化 AI 系統開發指南 / Gemma 3 自架 LLM 指南。