[Day 19] RAG 從「看見問題」到「主動發現問題」

這解決了一個重要問題：

「系統現在發生了什麼」

但如果真的部署到 Production，又會遇到下一個問題

如果沒有人看 Dashboard，我們可能完全不知道

所以今天要再往前一步：

讓系統自己發現異常，並主動通知維運人員

Monitoring 與 Alerting 有什麼不同

這兩個概念很容易混在一起

可以簡單理解系統告訴你現在怎麼樣或需要注意的細節

這才是一個比較完整的 Production 監控流程

RAG 到底要怎麼設定 Alert

不是所有資料都需要 Alert

如果什麼東西都通知：

最後反而會造成 Alert Fatigue

因此應該先找真正重要的指標。

先理解 Threshold

Alert 最基本的概念就是 Threshold (門檻)。

但實際 Production 不建議只用單次數值判斷

因為可能只是短暫波動

所以更常見的方式是：

連續一段時間超過門檻才觸發 Alert

這樣可以降低誤報

Trigger Alert 後，下一步就是：

通知誰

如果系統提供 Webhook，就可以將 Alert 包裝成 JSON

import requests


def send_webhook_alert(
    webhook_url,
    alert
):
    payload = {
        "title": "RAG Production Alert",
        "severity": alert["severity"],
        "metric": alert["metric"],
        "value": alert["value"],
        "threshold": alert["threshold"]
    }

    response = requests.post(
        webhook_url,
        json=payload,
        timeout=10
    )

    response.raise_for_status()

這裡先把 Webhook 當成通用介面

實際串接哪一個服務，取決於 Production 環境

不要讓同一個 Alert 一直狂發

這是實際做 Alerting 很容易遇到的問題

系統每分鐘檢查一次

最後可能收到幾十則一模一樣的通知

這就是典型的 Alert Storm

因此需要加入：

Cooldown

如果距離上一次 Alert 還不到 10 分鐘

這機制是避免相同期間，產生重複的異常通知

Alert 不應該只看單一 Metric

如果單一數值偏低，不一定代表系統真的發生嚴重問題

所以 Production Alert 可以進一步加入條件

這樣可以避免低流量情況下的誤報

這就是今天真正要建立的觀念：

Monitoring 是觀察，Alerting 是主動告警，而 Incident Response 才是後續處理

這已經不只是 RAG 技術，而是完整的 AI System Operations

但 AI System 還有一個特別的問題：

系統可能「正常運作」，但回答品質卻變差

這代表：

API 沒有壞，但 AI 品質可能已經發生問題

但這裡有一個重要差異，Production 不一定需要對每一筆 Query 都即時做完整 Evaluation

這樣才能兼顧成本與監控能力

Alerting 解決了：

「發現問題之後通知誰」

但收到 Alert 之後，還有一個更重要的問題：

「到底發生了什麼且我要怎麼找到原因」

下一步就需調查是 Retrieval 變慢，還是 Reranking、LLM API

Day 20：RAG 追蹤一次 Request 的完整生命週期

讓我們不只是知道：

「系統有問題」

而是開始回答：

「問題究竟發生在哪一個環節」