AI 工程從零開始｜Phase 11 Part 2：RAG 系統與 LLM 評估 — 生產落地的最後一哩

大多數工程師遇到 LLM 幻覺，第一反應是把 Prompt 寫得更長、更詳細。 正確答案是：建立 RAG 管線讓模型說「我不知道」，而非瞎猜。 大多數團隊上線後才發現回答品質不穩，因為沒有評估管線。 正確答案是：在 CI/CD 中門控 Faithfulness ≥ 0.80，讓壞版本無法部署。

這篇給已經把 RAG demo 跑起來、但還說不出「回答為什麼錯」的工程師看。讀完你會能把 RAG 拆成 Indexing 與 Query 兩條管線並說出各自的延遲與瓶頸、依文件型態選 Chunking 與 Hybrid Search、判斷何時值得付 +80 ms 做 Re-ranking，並用 RAGAS 這類評估管線把 Faithfulness 門檻接進 CI/CD，讓「幻覺率從 15% 降到 5%」變成可量測、可門控的工程目標。

一、核心問題：LLM 幻覺與知識截止日期的工程解法

LLM 有兩個先天限制，工程師必須正視：

幻覺（Hallucination） — 模型會以高信心度生成看起來合理但事實上錯誤的內容。根源在於訓練目標是「預測下一個 Token」，而非「陳述事實」。當問題超出訓練分布，模型不會說「我不確定」，而是繼續生成流暢但錯誤的文字。

知識截止日期（Knowledge Cutoff） — 模型訓練資料有時間邊界。2024 年底截止的模型不知道 2025 年的法規修訂、產品更新、或內部文件。無論 Prompt 寫得多好，模型都無法回答它從未見過的資訊。

RAG（Retrieval-Augmented Generation） 是主流工程解法：把外部知識庫的相關片段即時檢索出來，附加在 Prompt 中，讓模型「有所依據地回答」而非憑空捏造。

但 RAG 帶來新問題：檢索品質如何保證？回答是否忠實於檢索內容？這需要評估管線來量化和監控。

二、何時該升級：從 Dense-only 到 Hybrid、Re-rank 與評估門控的觸發條件

「固定 512 token chunk + Chroma + Dense 向量 + 人工抽查 20 筆」這組起步配置，兩三天就能跑通，而且在文件同質、問題都是語意型的情境下可以用很久。該升級的訊號不是文件數，而是失敗型態：客服回報「聽起來合理但內容有誤」的比例穩定在兩位數、含型號／條號的查詢經常找不到正確段落（Dense 向量對精確字串的召回差，§五）、或是 Chunk 邊界切斷了「第三條…應視為無效」這類跨句語意（§四）。這三個訊號各自對應一個升級動作——加 BM25 做 Hybrid、換 Semantic/Hierarchical Chunking、建 RAGAS 評估集——而不是一次全上。

第二道門檻在高風險查詢與部署節奏：法規、數字對比這類答錯代價高的問題，Hybrid + 好的 Chunking 仍可能把正確段落排在第 4–10 名，此時才值得付 +80 ms 加 Cross-Encoder Re-ranker（§六）；而當每週都有文件或 Prompt 變更、沒人能保證改動不會讓 Faithfulness 退步時，就該把 RAGAS 門控接進 CI/CD（§七）。百萬級文件、500 QPS 的分片與托管向量庫是最後才需要考慮的事。

三、RAG 管線設計：Indexing vs Query 兩階段

RAG 系統分為兩條獨立管線，時序不同、瓶頸不同。

┌─────────────────────────────────────────────────────────────────┐
│  Indexing Pipeline（離線，批次處理）                              │
│                                                                 │
│  Raw Docs                                                       │
│     │                                                           │
│     ▼  ~5ms/doc                                                 │
│  Document Loader（PDF/HTML/Markdown parser）                    │
│     │                                                           │
│     ▼  ~10ms/doc                                                │
│  Text Splitter（Chunking strategy）                             │
│     │                                                           │
│     ▼  ~20ms/chunk（API call）                                  │
│  Embedder（text-embedding-3-small or BGE-M3）                   │
│     │                                                           │
│     ▼  ~2ms/chunk                                               │
│  Vector Store（Upsert + BM25 Index 更新）                       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│  Query Pipeline（線上，即時）                                     │
│                                                                 │
│  User Question                                                  │
│     │                                                           │
│     ▼  ~15ms                                                    │
│  Query Embedder（同 Indexing 的模型）                            │
│     │                                                           │
│     ├──▶ ANN Search（~30ms，Top-50 候選）                        │
│     └──▶ BM25 Keyword Search（~5ms）                            │
│                │                                                │
│                ▼  ~5ms                                          │
│         RRF Fusion（合併兩路結果）                               │
│                │                                                │
│                ▼  ~80ms（選用）                                  │
│         Cross-Encoder Re-ranker（Top-50 → Top-5）               │
│                │                                                │
│                ▼  ~600ms（含網路）                               │
│         LLM 生成（with context）                                 │
│                │                                                │
│                ▼  總計 P95 ~750ms（無 Re-rank）                  │
│                    P95 ~1,800ms（含 Re-rank）                    │
└─────────────────────────────────────────────────────────────────┘

各階段延遲細節：

Embedding 模型選型：開源 vs 閉源

Embedder 是兩條管線共用的元件（換模型就得全量重建索引），選擇直接影響召回品質和成本結構。

┌───────────────────────────────────────────────────────────────────┐
│  Embedding 模型選型決策樹                                          │
│                                                                   │
│  文件語言？                                                        │
│      │                                                            │
│      ├── 純英文 ──▶  text-embedding-3-large（OpenAI）             │
│      │               或 E5-large-v2（開源，MTEB 頂尖）             │
│      │                                                            │
│      ├── 中英混合 ──▶  BGE-M3（開源）                              │
│      │                或 text-embedding-3-small（閉源，多語言）    │
│      │                                                            │
│      └── 高隱私需求（不能送出 API）──▶  BGE-M3 自部署              │
│                                          或 E5-mistral-7b-instruct│
└───────────────────────────────────────────────────────────────────┘

主流 Embedding 模型比較

此表為 2024 年的模型與價格快照：Cohere 已推出 embed-v4，Qwen3-Embedding 等新一代開源模型也已進入 MTEB 前段。選型前請以當前 MTEB 排行與官方定價為準。

自部署 BGE-M3 成本估算（中等規模）：

• 1 台 A10G GPU（4 vCPU, 24GB VRAM）：~$1.5/hr（AWS g5.xlarge）
• 日均 200K 次 Embedding 查詢：~$36/day vs text-embedding-3-small $4/day
• 換算：API 每次約 $0.00002（$4 ÷ 200K），自部署是約 $36/day 的固定成本，損益平衡點約在 $36 ÷ $0.00002 ≈ 1.8M queries/day
• 建議：< 約 1.8M queries/day 用閉源 API 更划算；超過後自部署才開始有成本優勢（隱私或資料落地要求則不受此門檻限制）

Embedding 維度壓縮（Matryoshka Representation Learning）

OpenAI text-embedding-3 系列支援 MRL，可將 1,536 維向量壓縮為 256 維，犧牲 3–5% 精度但：

• 儲存成本降低 83%（1,536 → 256 維）
• ANN Search 速度提升 ~4x
• 適合起步階段、成本優先的場景

四、Chunking 策略：Fixed / Semantic / Hierarchical 的取捨

Chunking 是 RAG 效果最容易被低估的變數。切太小丟失上下文，切太大引入雜訊。

Fixed-size Chunking

每 512 Token 切一段，允許 64 Token overlap。

優點：實作簡單，索引速度快（~5ms/chunk）。
缺點：機械切割，句子可能被截斷；「根據第三條…」的前半段與「…應視為無效」的後半段被分到不同 Chunk，導致語意破碎。

適用情境：同質性高的短文件（FAQ、商品說明）。

Semantic Chunking

依句子邊界和段落結構切割，計算相鄰句子的 Embedding 相似度，在語意不連貫處切分。

優點：Chunk 語意完整，Faithfulness 提升 ~8%。
缺點：多一次 Embedding 計算，Indexing 成本 +20ms/chunk；Chunk 長度不固定，需設上限（建議 800 Token 上限）。

適用情境：法律文件、技術手冊、學術論文。

Hierarchical Chunking（Parent-Child）

建立兩層索引：Parent Chunk（1,024 Token，保留完整段落語意）和 Child Chunk（256 Token，精細化搜尋）。

查詢時用 Child Chunk 命中，但傳給 LLM 的是對應的 Parent Chunk。

優點：兼顧搜尋精度（細粒度）與上下文完整性（粗粒度）；Recall@5 最高。
缺點：索引大小 ~2x，查詢邏輯更複雜，維護成本高。

適用情境：高準確度要求、法規/合約問答。

Chunking 策略比較表

五、Hybrid Search：BM25 + Dense 向量的融合

Pure Dense Vector Search 對精確關鍵字（產品型號、法條編號、人名）命中率差；BM25 對語意相似（「退款」vs「退費申請」）命中率差。Hybrid Search 融合兩者優點。

┌─────────────────────────────────────────────────────────────────┐
│  Hybrid Search 架構                                              │
│                                                                 │
│  Query: "第14條第2款的違約金上限"                                │
│     │                                                           │
│     ├──────────────────────────────────────┐                   │
│     │                                      │                   │
│     ▼                                      ▼                   │
│  ┌─────────────────┐            ┌─────────────────┐           │
│  │  BM25 Index     │            │  Dense Vector   │           │
│  │  (Sparse)       │            │  Index (ANN)    │           │
│  │                 │            │                 │           │
│  │  精確：第14條    │            │  語意：違約金    │           │
│  │  Rank: [3,7,12] │            │  Rank: [1,4,9]  │           │
│  └────────┬────────┘            └────────┬────────┘           │
│           │                              │                     │
│           └──────────────┬───────────────┘                     │
│                          │                                     │
│                          ▼                                     │
│               ┌──────────────────┐                             │
│               │  RRF Fusion      │                             │
│               │  score = Σ 1/(k+r)│                            │
│               │  k=60（標準值）   │                             │
│               └──────────┬───────┘                             │
│                          │                                     │
│                          ▼                                     │
│               Top-5 Merged Results                             │
└─────────────────────────────────────────────────────────────────┘

Reciprocal Rank Fusion（RRF）公式

每個文件的 RRF 分數：

RRF_score(d) = Σ_r  1 / (k + rank_r(d))

• k = 60（常數，防止高排名文件過度主導）
• rank_r(d)：文件 d 在第 r 路檢索結果中的排名
• 對 BM25 結果和 Dense 結果各算一次，加總後重新排序

實際效果：

• Dense-only Recall@5：0.71
• Hybrid Recall@5：0.83（+12 個百分點）
• 專有名詞（型號、條號）命中率：0.54 → 0.79（+25pp）

何時用哪種搜尋

六、Re-ranking：Cross-Encoder 精排的工程成本

Bi-Encoder vs Cross-Encoder

Bi-Encoder（現有的 Embedding Model）：Query 和 Document 各自 Encode，計算 Cosine Similarity。速度快（~5ms），但因為 Query 和 Document 獨立編碼，無法捕捉深層交互語意。

Cross-Encoder：把 Query + Document 拼接後一起輸入模型，輸出一個相關性分數。能捕捉細粒度的語意交互，但每對 (Query, Doc) 都要跑一次前向傳播，Top-50 候選就要跑 50 次，+80ms 延遲。

Bi-Encoder：
  E(Query)  ──▶ [0.2, 0.8, 0.4, ...]
  E(Doc)    ──▶ [0.3, 0.7, 0.5, ...]
  Score = cosine_sim(E_q, E_d)  ← 快但粗糙

Cross-Encoder：
  [CLS] Query [SEP] Document [SEP]  ──▶  Score: 0.91  ← 慢但準確

ColBERT：中間路線

ColBERT 保留 Token 層級的向量（而非池化成單一向量），用 MaxSim 計算分數。延遲約 +25ms，精度介於 Bi-Encoder 和 Cross-Encoder 之間。適合 QPS 高但仍需要比 Bi-Encoder 更好準確度的場景。

Re-ranking 成本效益分析

Re-ranking 值得投入的信號：

• 當前 Faithfulness < 0.80（Re-ranking 是提升品質最直接的槓桿）
• 查詢是高風險類型（法規、醫療、財務）
• QPS < 100（延遲預算夠用）

七、LLM 評估框架：RAGAS / G-Eval / LLM-as-Judge

「如果你無法量化它，你就無法改善它。」評估框架是 RAG 系統的品質護欄。

RAGAS（RAG Assessment）

RAGAS 是針對 RAG 系統設計的自動化評估框架，核心四個指標：

RAGAS 成本：每筆評估約 $0.003（GPT-4o 為評判模型）；若改用 GPT-4o-mini 降至 $0.0004/筆，但準確度下降 ~6%。

G-Eval

G-Eval 使用 Chain-of-Thought 讓 LLM 先解釋評分理由再給分，對齊人類評審的方式更接近。

流程：

1. 定義評估標準（Faithfulness 的 1–5 分定義）
2. 讓 LLM 生成 CoT 推理：「這個回答引用了 Context 的第二段，但第三句話沒有來源…」
3. 基於 CoT 輸出分數

G-Eval 與人類評審一致率：Pearson 相關係數 ~0.82（RAGAS 約 0.74）。

LLM-as-Judge

把 LLM 當作評審，直接判斷「這個回答對不對」。實務設計要點：

1. Prompt 設計：給定評分 Rubric（1=完全錯誤，5=完全正確），加入 Few-shot 範例
2. 位置偏差（Position Bias）：LLM 傾向給第一個選項高分；解法是 A/B 互換後平均
3. 自我增強偏差：GPT-4o 評估 GPT-4o 輸出會偏高；考慮用不同家族模型交叉評估
4. 成本：GPT-4o-mini 評估，~$0.002/筆，批次處理可降至 $0.0008/筆

LLM-as-Judge vs 人類評審一致率（二元判斷：對/錯）：~85%，適合做初篩；最終高風險樣本仍需人工複審。

CI/CD 評估門控實作

# 偽代碼：GitHub Actions 評估門控
評估集：500 筆 QA pairs（每週更新）
觸發時機：每次 PR 合併到 main

if RAGAS_faithfulness < 0.80:
    block deployment
    notify #ai-eng-alerts

if answer_relevancy < 0.75:
    block deployment

if p95_latency > 2000ms:
    block deployment

建立評估集的三個來源：

1. 客服歷史問題 + 人工標注答案（最貴但最準）
2. 從文件自動生成（RAGAS TestsetGenerator，$0.01/筆）
3. 生產流量採樣 + LLM-as-Judge 自動標注

八、為什麼選 X 不選 Y

Chunking 與 Re-ranking 的取捨已在 §四、§六 的比較表中給出，這裡只留三個真正需要權衡的決策。

決策 1：Hybrid Search vs Dense-only

決策 2：Pgvector vs Pinecone vs Weaviate

決策 3：LLM-as-Judge vs 人工評估

九、系統效應：Naive RAG vs Advanced RAG 量化比較

以上為示意估算，非實測數據。

重要 Trade-off：Advanced RAG 的延遲比 Naive RAG 高（因為 Re-ranking），需要確保 P95 在 SLA 內（例如 2 秒）。如果延遲預算緊張，可考慮跳過 Re-ranking，用 Hybrid Search + 好的 Chunking 也能達到 Faithfulness 0.82。

十、生產常見問題與診斷流程

即使架構設計完善，生產環境仍會出現各種品質退化。以下是最常見的五個問題及對應的診斷鏈。

問題 1：Faithfulness 突然下降（0.85 → 0.70）

觀測信號：RAGAS Dashboard 顯示 Faithfulness 7 日均值跌破門檻，Slack 告警觸發。

診斷鏈：

Faithfulness 下降
    │
    ├── 查看同期是否有文件大批更新
    │       │
    │       └── 是 → 新文件 Chunking 是否破壞語意？
    │                   抽樣 20 筆，人工確認 Chunk 邊界
    │
    ├── 查看 Context Precision 是否也下降
    │       │
    │       └── 是 → 檢索品質問題，ANN Index 是否重建失敗？
    │               檢查 Embedding 模型版本是否被更改
    │
    └── Context Precision 正常，Faithfulness 仍低
            │
            └── LLM 模型本身問題（API 版本更新？Temperature 設定改變？）
                抽樣對比：舊版 vs 新版輸出

常見根因：

• 文件更新後未重建索引（Stale Index，佔 40% 案例）
• Embedding 模型靜默升級，向量空間不一致（佔 25%）
• LLM System Prompt 被意外修改（佔 20%）
• 新增了不相關文件污染索引（佔 15%）

問題 2：P95 延遲從 1.2s 飆升到 3.5s

觀測信號：APM（Datadog / Grafana）顯示 p95_latency_ms 持續超過 SLA。

診斷步驟：

常見解法：

• ANN Index 碎片化 → 觸發 HNSW Index Rebuild（離線執行）
• Re-ranker 沒有 Keep-Alive → 改用連接池，-40ms
• Candidate Set 太大（Top-100 Re-rank）→ 縮減至 Top-30，-35ms

問題 3：Context Recall 低（< 0.65）— 找不到該找到的文件

根因分析：

1. Embedding 模型與文件語言不匹配：中文文件用英文優化的 Embedding 模型，召回率可能低 20–30%。解法：改用 BGE-M3（多語言，MTEB 中文排名前 3）。

2. Chunk 過小（< 128 Token）：資訊被稀釋，每個 Chunk 的語意信號不夠強。解法：調整 Chunk size 至 384–512 Token。

3. K 值設太小：只取 Top-3 候選，但相關文件排在第 4。解法：Top-K 調為 10，Re-ranker 後取 Top-3。

4. 缺乏 Metadata 過濾：使用者問「2024年的條款」，但索引沒有年份 Metadata，無法有效過濾。解法：Indexing 時提取 Metadata，Query 時加入 Pre-filter。

問題 4：Answer Relevancy 低 — 回答正確但答非所問

此問題通常不在 Retrieval 端，而在 Prompt 設計端。

常見原因：

• System Prompt 過於開放（「請盡可能詳細回答」）→ 模型生成大量無關背景資訊
• 沒有明確要求「如果 Context 中沒有答案，請說不知道」→ 模型開始幻想
• Context Window 太多無關 Chunk（Context Precision 低）→ 模型被干擾

修復步驟：

# Prompt 優化前
"根據以下文件回答問題：{context}\n問題：{question}"

# Prompt 優化後
"你是法律文件助理。請嚴格根據以下 Context 回答問題。
如果 Context 中沒有足夠資訊，請直接說「根據現有文件無法確認」，
不要猜測或補充 Context 以外的資訊。

Context：
{context}

問題：{question}

請給出簡潔、直接的回答（3句以內）。"

修改後 Answer Relevancy 通常可提升 0.08–0.15。

問題 5：評估集過時，RAGAS 分數虛高

評估集是 6 個月前建立的，但文件已大幅更新，導致評估分數不反映真實品質。

評估集更新策略：

附錄：RAG 系統健康度檢查清單

在每次重要版本上線前，確認以下 15 個檢查項目：

Indexing 管線

• 文件格式全部被 Loader 正確解析（PDF 表格、圖片 OCR）
• Chunk 邊界抽樣確認，無句子被截斷超過 20%
• Embedding 模型版本鎖定，不受 API 靜默升級影響
• BM25 Index 與 Vector Index 同步，無 Stale 文件
• Metadata（來源、日期、類別）正確存入，支援 Pre-filter

Query 管線

• Hybrid Search RRF 融合正常，兩路結果都有貢獻
• Re-ranker 服務健康檢查通過，P99 延遲 < 150ms
• Context Window 不超過 LLM 上限（保留 1K Token 給輸出）
• 空結果處理：當 Recall 為 0，回傳固定的「找不到相關資訊」而非幻想

評估管線

• RAGAS 評估集版本與當前文件同步（< 30 天舊）
• CI/CD Gate 設定正確：Faithfulness < 0.80 確實 Block 部署
• Faithfulness / Relevancy / Latency 三項 Dashboard 在 Grafana 可見
• 每週抽樣 50 筆生產查詢加入評估集滾動更新

成本控制

• 每查詢成本上限設定（建議 $0.01/query 為警戒線）
• LLM API Rate Limit 監控，避免突發流量超限導致降級

相關文章與正典版本

• 評估指標的機制（正典）— FDE core topic — RAG Triad Metrics ；實作見 ChatPDF RAG 優化（三）：可觀測性與評估
• 混合搜尋與 RRF：機制與生產實作（正典）— FDE core topic — Hybrid Search & RRF：混合檢索與倒數排名融合 、RAGFlow Intro Part 4 — 混合搜尋、Rerank 與 GraphRAG/RAPTOR
• 重排與 Cross-Encoder（正典）— FDE core topic — Re-ranking & Cross-Encoder
• 切塊與向量資料庫選型（正典）— RAGFlow Intro Part 2 — DeepDoc 解析與 Chunking 策略 、RAG 完全指南（二）：Chunking 策略與向量資料庫選型
• 入門與導讀 — RAG 完全指南（一）：入門與導讀

系列導航

← Phase 11 Part 1：LLM 推論工程 — 從實驗到每秒千次請求

→ Phase 12 Part 1：Vision Transformer 與多模態融合架構

本文為「AI 工程從零開始」系列第 23 篇。系列涵蓋從基礎 ML 工程到 LLM 生產落地的完整路徑，適合想系統性建立 AI 工程能力的工程師。