前言

實務應用中，RAG（Retrieval-Augmented Generation）系統不只是「模型表現」的問題，而是一整條查詢流程的效能與穩定性問題；再加上Agent成為Agentic RAG後，可想而知的是系統會更加複雜。
那今天如果系統查太慢、回太慢、或答案不穩定，使用者體驗不佳的狀況下，我們要怎麼知道複雜系統是哪個環節出了問題呢?
因此，不論是RAG或是Agentic RAG，建立**監控機制（Observability）**都是讓系統真正落地的關鍵。

🔍 RAG Pipeline 為什麼需要監控？

RAG 系統是一條多階段的流程：

使用者問題 → 向量化 (Embedding) → 向量檢索 (Retrieval) → 回答生成 (Generation)

可想而知，每一個環節都可能出現延遲、錯誤或品質下降的問題，例如：

• 向量模型太大導致 embedding 延遲；
• 向量資料庫壓力過高導致檢索緩慢；
• Retrieval準確度不夠導致Recall低；
• LLM 回答時間過長或產生不穩定輸出；
• 整體 RAG latency 不穩定導致用戶體驗不佳。

要找到這些瓶頸，監控是唯一能提供客觀數據的手段。

🧩 Agentic RAG 與 MRKL 架構的挑戰

在傳統 RAG 中，一次請求通常只會執行「檢索 → 生成」一次。
但在 Agentic RAG 或 MRKL（Modular Reasoning, Knowledge and Language） 框架中，系統可能會多輪推理，每輪都可能再次調用 RAG 模組作為 tool。

舉例來說：

使用者問題 → Agent 分解子任務
├─ Tool 1：檢索 A 主題 → 生成中間結果
├─ Tool 2：再次檢索 B 主題 → 整合資訊
└─ Tool 3：生成最終回答

這意味著每個子步驟都依賴前一步的正確性。
若每一步的準確度僅有 80%，經過 3 次推理後，整體正確率可能只剩下：

0.8 × 0.8 × 0.8 = 0.512（約 51%）

甚至在某些複雜推理場景下，錯誤會疊加放大，導致最終結果偏離真實答案。
因此在 Agentic RAG 中，監控不只是看「延遲」，更要追蹤每次 tool 調用的準確度與成功率。

⏱️ RAG 的三大監控面向

1. Embedding 層面

• 指標： embedding_latency
• 觀察重點：
  • 單次向量生成時間（毫秒）
  • 批次處理 throughput（每秒生成向量數）
• 潛在瓶頸：
  • 模型過大或缺乏 GPU 加速；
  • 請求併發量過高導致延遲累積。

2. Retrieval 層面

• 指標： search_latency, hit_ratio
• 觀察重點：
  • 查詢延遲（檢索速度）
  • 檢索結果數與命中率
• 潛在瓶頸：
  • 向量索引未優化；
  • 查詢維度過高；
  • 向量資料庫負載過重。

3. Generation 層面

• 指標： total_rag_latency, token_count
• 觀察重點：
  • 從接收問題到回覆的整體延遲；
  • Token 數量與生成速率；
• 潛在瓶頸：
  • 模型 context 長度過大；
  • Prompt 結構不佳；
  • Temperature 或 top_p 設定導致生成不穩定。

📊 常見監控指標示例

效能指標 (Performance Metrics)

檢索品質指標 (Retrieval Quality Metrics)

Agent 指標 (Agent-Specific Metrics)

🧠 除了效能，也要監控「品質」

效能監控能讓系統穩定，但還不夠。
RAG 系統的價值在於「正確回答」，因此品質監控同樣重要：

生成品質指標 (Generation Quality Metrics)

• 回答正確率（accuracy）：

  • 以人工標註或 LLM-as-Judge 方式比對生成內容與標準答案
  • 可使用 GPT-4 等強模型進行自動化評估

• 回答完整性（completeness）：

  • 檢查是否回答了問題的所有面向
  • 避免遺漏關鍵資訊

• 事實一致性（faithfulness/groundedness）：

  • 驗證回答是否忠於檢索到的原始文件
  • 防止模型「編造」不存在的資訊
  • 這是 RAG 最關鍵的品質指標

• 相似度評估（semantic similarity）：

  • 比較回答與原文片段的語意距離（如 cosine similarity）
  • 檢測答案是否偏離原文過多

• 回答相關性（answer relevance）：

  • 評估回答是否直接針對使用者問題
  • 避免答非所問或過度發散

使用者體驗指標 (User Experience Metrics)

• 使用者回饋（explicit feedback）：

  • 蒐集 👍/👎 或 1-5 星評分
  • 作為品質信號的黃金標準

• 隱式回饋（implicit feedback）：

  • 對話輪次（過多可能表示未解決問題）
  • 重新提問率
  • 會話放棄率

• 可解釋性（explainability）：

  • 提供引用來源（citation）
  • Agent 決策過程透明度

Agent 推理品質 (Agent Reasoning Quality)

• Agent tool trace：

  • 紀錄每次 tool 調用的輸入、輸出、執行時間
  • 用來分析 reasoning 鏈中的誤差來源
  • 建立 tool call 的成功/失敗模式庫

• 推理路徑分析（reasoning path analysis）：

  • 識別常見的成功/失敗模式
  • 優化 prompt 或 tool 設計

• 錯誤傳播追蹤（error propagation tracking）：

  • 追蹤單一錯誤如何影響後續步驟
  • 量化錯誤累積效應

🚀 小結

今天整理了許多的觀測指標，筆者建議可以依照使用場景的不同去決定要使用哪些指標來監控系統，只要記得這些指標是要幫助你回答三個核心問題：

1. 我的 RAG 應用為什麼慢？
2. 它慢在哪裡？
3. 在多輪推理下，錯誤是如何逐步累積的？
   從監控的目的出發，而不是做出一個玲瑯滿目的儀表板。

下一篇我們將介紹：**如何用 Prometheus + Grafana 建立 Agentic RAG 的效能與準確度監控儀表板。