[Day 28] RAG Reliability Engineering 從服務可用到品質可靠

服務上線，不代表系統可靠

透過 Kubernetes 管理 RAG 系統的部署與自動擴展，讓服務具備更完整的維運能力

但當系統真正進入 Production，仍然會遇到新的問題：

• API 可以正常回應，但回答內容卻是錯的
• 系統沒有發生錯誤，回應時間卻越來越長
• LLM API 暫時不可用，導致整個 RAG Pipeline 中斷
• 服務看起來穩定，但使用者持續回報檢索不到正確文件
• 團隊知道系統偶爾發生問題，卻沒有明確標準判斷是否達到可接受的服務品質

這些問題反映出一個重要觀念：

服務可用 (Availability) 不等於服務可靠 (Reliability)，HTTP 200 也不代表 AI 回答正確

對傳統 Web API 而言，我們通常會關注服務是否正常回應、延遲是否過高，以及錯誤率是否超標

但對 RAG 系統來說，除了基礎設施的穩定性，還必須考慮檢索品質、回答正確性、引用依據與知識更新等因素

因此，今天要從 Reliability Engineering (可靠性工程) 的角度，建立一套衡量 RAG 系統可靠性的思考方式

什麼是 Reliability Engineering

Reliability Engineering 是透過系統化的方法，分析服務可能發生的故障，建立可靠性目標，並持續監測與改善系統

它的目的不是保證系統永遠不會出錯，而是：

1. 定義什麼樣的服務表現才算合格
2. 透過數據判斷系統是否達到目標
3. 找出影響可靠性的主要風險
4. 在功能交付、成本與穩定性之間取得平衡
5. 當異常發生時，能夠快速偵測、復原與改善

因此，我們需要先建立清楚的服務目標

認識 SLI、SLO 與 SLA

SLI、SLO 與 SLA 是可靠性工程中非常重要的三個概念

SLI：Service Level Indicator

SLI 是服務水準指標，也就是用來衡量服務實際表現的數據

例如：

• API 成功請求率
• P95 回應延遲
• RAG 回答的 Faithfulness
• 檢索成功率
• LLM Timeout Rate

假設某一天 RAG API 收到 10,000 個有效請求，其中 9,950 個在指定時間內成功完成

若將「成功且在期限內完成的請求比例」定義為 SLI

這個數值描述的是實際觀測到的服務表現，而不是團隊希望達成的目標

SLO：Service Level Objective

SLO 是服務水準目標，也就是團隊設定的可靠性標準

例如：

• 月度 API 可用率至少 99.9%
• 95% 的請求在 2 秒內完成
• RAG Evaluation Dataset 的 Faithfulness 平均分數至少 0.90
• 關鍵測試案例的引用依據通過率達到指定標準

假設我們設定：

在每個月的有效請求中，至少 99.9% 必須成功，且在 2 秒內完成

這就是一個 SLO

但要注意，SLI 與 SLO 必須使用相同的統計口徑。不能拿全部請求計算目標，卻只用部分成功請求計算實際結果

SLA：Service Level Agreement

SLA 是服務水準協議，通常是服務提供者與客戶之間約定的服務條件，可能包含可用率、支援時間、違約處理或服務抵免等條款

例如：

若月度服務可用率低於合約約定的標準，將依合約規定提供相應的服務抵免

SLA 是否包含賠償、抵免或其他責任，取決於實際合約內容

如何為 RAG 系統設計 SLI

RAG 系統不能只使用傳統 API 的可用率作為可靠性指標，因為它包含 Retrieval、Reranking、LLM Generation 等多個環節

我們可以先從四個主要方向建立 SLI

Availability：服務可用率

最基本的指標是請求是否成功完成

但要先定義什麼叫做「成功」

例如，若 API 回傳 HTTP 200，卻因為 LLM 失敗而只回傳空字串，這是否算成功

對 RAG 系統而言，單純將 HTTP 200 當作成功可能過於寬鬆

更合理的做法是建立明確的成功條件，例如：

• 請求格式正確
• RAG Pipeline 完成執行
• 回應符合 API Schema
• 回應在指定期限內完成
• 沒有發生定義中的服務錯誤

如果系統提供「無法回答」的安全回覆，則應將它與真正的服務故障分開統計

Latency：回應延遲

使用者通常不只關心系統能不能回答，也關心需要等待多久

雖然大多數請求能在數秒內完成，但仍有少數請求耗時較久

如果只看平均延遲，這類長尾問題可能不容易被發現

因此，RAG 系統應同時觀察整體延遲與長尾延遲，並將它們與使用者體驗目標連結

Retrieval Quality：檢索品質

假設使用者詢問：「系統支援哪些作業系統」

理想情況下，Retriever 應找到包含支援版本的文件

但如果檢索結果只包含安裝步驟，沒有取得作業系統版本，即使 LLM API 正常，也可能產生不完整的回答

Answer Quality：回答品質

RAG 的核心價值，是讓 LLM 根據檢索到的知識產生有依據的回答

因此，需要追蹤：

• Faithfulness：回答是否受到提供的上下文支持
• Answer Relevance：回答是否回應使用者問題
• Citation Accuracy：引用是否正確支持對應的回答內容
• Abstention Quality：缺乏足夠證據時，系統是否適當地表示無法回答

這些指標通常需要 Evaluation Dataset、人工標註或評估模型輔助判斷，不一定能在每次線上請求結束後立即取得可信的分數

重要觀念：即時監控與離線品質評估需要互相配合

建立 RAG 的 SLO

有了 SLI 之後，下一步就是設定 SLO

這些數值只是設計範例，並不是所有 RAG 系統都應採用的標準

例如，內部文件助理可能可以接受數秒的回應時間；即時語音助理則可能需要更低的延遲

同樣地，不同風險等級的應用，也應設定不同的品質門檻

SLO 不應只看平均值

即使增加大量簡單案例，讓整體平均分數提高，也不代表原本回答錯誤的關鍵案例已經改善

因此，除了整體平均值，也應檢查：

• 關鍵案例是否通過
• 不同問題類型的表現
• 無法回答案例的處理能力
• 是否發生嚴重的引用錯誤
• 近期版本是否比上一版退步

對高風險應用而言，關鍵案例的通過條件可能比整體平均分數更重要

今天學到什麼

今天從 Reliability Engineering 的角度，重新思考 RAG 系統的 Production 品質

1. SLI、SLO 與 SLA 扮演不同角色 SLI 衡量實際表現，SLO 定義目標，SLA 則是對外的服務約定
2. 可靠性不只是 API 可用率 RAG 還需要考慮延遲、檢索品質、回答依據與安全性
3. Error Budget 協助團隊平衡開發與穩定性 當服務表現偏離目標時，可以依據預算消耗情況調整發布與改善優先順序
4. 可靠性需要持續驗證 Monitoring、Evaluation、Testing、Alerting 與 Deployment 必須形成持續改善的循環

我們已經逐步建立一套 RAG 智慧助理的完整工程思維

不只讓 AI 能回答問題，也開始衡量它是否能在真實環境中持續、穩定且有依據地提供服務

真正的可靠性，不是承諾系統永遠不出錯，而是能清楚定義目標、及時發現問題，並在問題發生後持續改善

Day 29：RAG Security 從 API 防護到 AI 應用安全

當智慧助理開始處理企業文件、使用者資料與外部工具呼叫，除了確保服務穩定，也必須考慮安全性

下一篇將探討 API Authentication、Authorization、Prompt Injection、敏感資料保護、RAG 文件存取權限與 Secrets Management，建立從傳統應用程式到生成式 AI 的多層安全防護

讓智慧助理不只可靠，也能在適當的權限與安全邊界內運作