線上 vs 離線 LLM 評估：該用哪個（以及何時）

線上 vs 離線 LLM 評估：該用哪個（以及何時）

線上 vs 離線 LLM 評估其實是同一個決策，而不是兩個。上週二，我們的 promptfoo 套件證明了這件事：一次重寫過的系統 prompt、47 個測試案例，忠實度從 0.91 掉到 0.74，整段 CI 時間大約 90 秒。離線檢查在合併前就抓到這次回歸；換作生產監控，它會晚些時候才現身，而且偽裝成一則客服工單。離線與線上，結論相同：兩條車道，各司其職。

離線 LLM 評估是在部署前，讓模型對照一份固定資料集跑一遍，證明某個變更沒有打破既有的品質。線上評估則是在上線後對即時生產流量評分，把資料集從來沒包含過的東西攤在陽光下。多數團隊兩者都需要，而且有先後：離線為部署把關，線上抓漂移。

重點摘要

• 離線評估在部署前對照固定資料集執行；線上評估在上線後對即時流量評分。
• 多數團隊兩者都需要：離線為部署把關，線上接住資料集漏掉的東西。
• 離線抓到 prompt 回歸與格式破壞；線上抓到漂移、負載下的延遲與整合上的怪癖。
• 把離線評估接成 CI 合併閘道；把來自生產追蹤記錄的線上分數串流回評估資料集。

線上與離線評估到底差在哪？（9 個維度）

兩者的差異落在 9 個軸線上，但真正決定性的是資料來源：離線評估在部署前對一份固定、有版本控制的資料集評分，線上評估則在上線後對即時流量評分。其他所有差異，包括成本、延遲、風險、治理，都源自這個分野。

Label Studio 的學習中心把這兩者定位成互補的模式，而不是對手，我們同意這個看法。下表延伸了這個框架，補上他們那份通用 ML 版本沒有涵蓋、專屬於 LLM 的指標。

我們的解讀是：離線這一欄回答的是「這個變更有沒有弄壞什麼？」，線上這一欄回答的是「生產環境有沒有偏離我們測過的東西？」。兩者分歧最大的是指標類型那一列；我們的 LLM 評估指標指南逐一拆解了每一個指標。

每種模式各抓到什麼，又有哪些兩者都漏掉？

每種模式都擁有一類對方看不見的私有失敗。離線抓到的是你自己做的變更；線上抓到的是外部世界在你周圍造成的變更。而那些昂貴的失敗，也就是能同時穿過兩張網的，需要人類審查者。這套分類是我們綜合兩種模式各自回報的結果得出的，不是某個已發表的標準。

「只有離線抓得到」這個象限，正是 CI 閘道回本的地方：一個悄悄把格式合規從 99% 拉到 91% 的重寫 prompt，在程式碼審查裡隱形，在 47 個案例的套件裡卻一目了然。「只有線上抓得到」這個象限更狡猾。真實使用者的措辭是你的黃金資料集從來沒出現過的；第三方 API 會在 staging 永遠碰不到的時間點 timeout；而且一定有人會丟給你的聊天機器人一則 40,000 字元的 prompt，只為了看看會發生什麼事。針對這一側，我們的生產環境 Agent 評估指南涵蓋了如何為多步驟軌跡評分，而不只是單一輸出。

最後一列是團隊最常跳過、也最常被它燒傷的一列。會讓你失去使用者的失敗，正是沒有任何一種模式能單獨抓到的那些。它們需要人介入。

如何把離線評估接進 CI 閘道？（沒人給你看的那份設定）

在每一個會動到 prompt、模型或檢索設定的 pull request 上，把評估執行器加成必要的狀態檢查。斷言一個門檻，低於門檻就阻擋合併。promptfoo 的文件記載的正是這個 CI 模式，也是我們實際在跑的做法。

GitHub Actions 步驟

我們目前使用的閘道，精簡版如下：

name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

YAML 設定宣告了測試案例與斷言；當套件分數低於門檻時，eval 會以非零狀態結束，GitHub 把必要的狀態檢查標為失敗，合併按鈕就變灰。paths 過濾器很重要：改個 README 不該燒掉評審 token。

這道閘道實際抓到什麼

線上版在每個會影響 prompt 的 PR 上，讓我們的客服 Agent RAG 鏈對照 47 個黃金案例評分。完整跑一次大約花 90 秒 CI 時間，只要忠實度低於 0.82，合併就會自動被擋。三個月下來，它抓到兩次原本會直接上線的回歸：一次系統 prompt 重寫把忠實度從 0.91 推到 0.74，還有一次檢索器變更讓上下文長度翻倍，把答案相關性拖到門檻以下。兩次在審查階段看起來都不危險。

CI 裡的一道忠實度閘道，每個 PR 成本 90 秒。生產環境裡的一次忠實度回歸，成本是一則客服工單加一次版本回退。

我們把可以接進這個模式的執行器，promptfoo、DeepEval 與其他，放在我們的 LLM 評估工具評比裡比較過了。

哪些工具跑哪種模式？（工具對模式矩陣）

沒有任何一個工具能乾淨地同時擁有兩條車道。promptfoo 和 DeepEval 是離線優先的執行器，可以排程對匯出的生產資料評分；Langfuse 和 LangSmith 是線上優先的追蹤記錄儲存庫，把 LLM-as-judge 評分器接上已攝入的追蹤記錄。這個矩陣是我們對各家文件的解讀：是詮釋，不是鐵律。

如果你的首要需求是在 CI 裡擋下壞 prompt 的合併閘道，選 promptfoo 或 DeepEval。如果你的首要需求是為即時流量評分，選 Langfuse 或 LangSmith，我們的 Langfuse vs LangSmith 比較深入談了這個選擇。OpenAI Evals 依然是異類：一個登錄式的離線執行器，沒有生產端。

promptfoo 為你的 PR 把關。Langfuse 為你的生產追蹤記錄評分。兩者誰也取代不了誰。

回饋迴圈如何把線上失敗變成離線測試？

取樣低分的生產追蹤記錄、加以標註，然後提交進離線評估資料集。這樣一來，回歸套件會隨著生產環境丟給你的每一個驚喜而成長，而下一次部署就會以擴大後的套件作為閘道。飛輪這個說法是我們的；它也是多數團隊從來沒有蓋起來的那一塊。

我們實際運作的循環如下：

1. 線上評分器標記評審分數低於 0.7 的追蹤記錄。
2. 我們每週取樣 20 到 30 則被標記的追蹤記錄。
3. 由人標註每一則：預期輸出加上失敗類別。
4. 標註過的案例作為新的黃金範例，加入離線評估資料集。
5. 下一個 PR 對照擴大後的套件執行，循環重新開始。

取樣從你的 LLM 可觀測性層開始，因為追蹤記錄就是原料。論節奏：每週優於每月，因為漂移會複利累積。我們每週標註 10 到 15 個案例，而當新的標註不再帶動通過率變化時，資料集就「夠大了」；對一個窄域的客服 Agent 來說，大約是 150 到 250 個案例。兩種模式之間的界線越來越模糊：Deepchecks 提到，Union.ai 的工程師每隔幾分鐘就排程執行他們的「離線」評估，實際上把它們變成了近即時檢查。

你的評估資料集不是一件固定的產出物。它會隨著生產環境每週給你的驚喜而成長。

什麼時候兩者都需要？（依階段看線上 vs 離線 LLM 評估）

從上線那一週開始，兩者你都需要，但比重會隨階段移動：部署前由離線獨扛，上線週加入影子或金絲雀評分，穩態期倚重線上監控並定期重跑離線，而一次漂移警報應該以一個在離線重現的測試和一個更大的評估資料集作結。

部署前是最便宜的嚴格把關點：擋下一次合併只花幾分鐘；一次糟糕的發布賠掉的是信任。上線週是團隊投資不足的地方，然而對一小片流量做影子評分所費不多，卻能揭穿黃金資料集有沒有說謊。穩態期是自滿滋生的地方，所以把重評排進行事曆。

那歐盟 AI 法案呢？

歐盟 AI 法案的高風險義務將分階段實施至 2026 年 8 月，完整的期限時程公布在 EUR-Lex，而它的合規模式與這兩種模式恰好對應。有文件紀錄的離線證據，顯示系統在發布前達成品質目標；持續的線上監控，顯示系統在上線後持續達成。我們的解讀是：稽核軌跡需要兩種產出物，因為僅憑離線紀錄無法證明系統持續合規，僅憑儀表板也無法證明它上線時合規。這是我們的詮釋，不是法律建議；我們的 LLM 評估管線支柱文章對應了完整的需求集合。

離線評估是你的證據。線上評估是你的預警系統。監管機關兩者都要。

關於作者： Mert Batur 是 Techsy.io 的共同創辦人，團隊為 B2B 客戶打造 AI Agent、自動化系統與語音/SDR 管線。他寫的主題是 Techsy 團隊在生產環境實際使用的 LLM 工具鏈。歡迎在 LinkedIn 交流。

常見問題

什麼是離線 LLM 評估？

離線 LLM 評估是在部署前，讓模型或 prompt 對照一份固定、有版本控制的資料集執行。典型的檢查包含對檢索上下文的忠實度、答案相關性、格式合規與基準分數。因為資料集在執行過程中從不改變，結果可重現、可 diff，這正是離線套件適合作為 CI 合併閘道的原因。

什麼是線上 LLM 評估？

線上 LLM 評估是在上線後對即時生產流量評分。LLM-as-judge 評分器對取樣的追蹤記錄評定幻覺、語氣或工具呼叫的正確性，分數則串流到儀表板。它也吸收了離線測試看不到的訊號：負載下的延遲、使用者回饋，以及真實查詢與你的黃金資料集之間的差異。

什麼時候該用離線，什麼時候該用線上 LLM 評估？

用離線評估為部署把關：每一次 prompt、模型或檢索的變更，都應該在合併前通過套件。用線上評估監控上線後的表現。多數團隊是把兩者依序排好，而不是二選一：先離線，從上線週開始加線上，並讓生產失敗回流進離線資料集。

線上 vs 離線 LLM 評估的例子是什麼？

離線例子：一個 promptfoo 套件在每個 pull request 上跑 200 個黃金客服問題，忠實度低於 0.82 就阻擋合併。線上例子：Langfuse 用 LLM-as-judge 幻覺檢查對 10% 的即時追蹤記錄評分，並在每週平均值滑落時發出警報。同一套評分準則，不同的資料來源。

人機協同（human-in-the-loop）如何融入 LLM 評估？

人類彌補的是兩種模式都覆蓋不到的缺口：全新的邊緣案例、主觀的品質判斷，以及品牌語氣漂移。實際可行的節奏是每週標註 10 到 20 則取樣來的低分追蹤記錄，並把標註過的案例提交進離線評估資料集。審查佇列是管線的輸入，不是副業。

Langfuse 評估如何做線上評分？

Langfuse 從你的應用程式攝入追蹤記錄，然後掛上 LLM-as-judge 評估器，依評分準則為每一則追蹤記錄評分：幻覺、相關性、毒性，或自訂 prompt。分數落在以 session 與使用者為鍵的儀表板上。團隊把持續低分的追蹤記錄匯出成離線資料集，用於回歸測試。我們的可觀測性平台評比比較了餵養這個模式的追蹤記錄儲存庫。

如何把離線評估加進 CI/CD 管線？

在會動到 prompt、模型或檢索設定的 pull request 上，把評估執行器加成必要的狀態檢查。promptfoo 和 DeepEval 都能以 headless 方式執行，並在斷言失敗時以非零狀態結束，合併因此自動被擋。本文前面的 YAML 閘道就是一份可用的範本；從 30 到 50 個案例開始。

歐盟 AI 法案要求的是離線還是線上評估？

實際上，兩者都要。對高風險系統，法案期望有文件證據證明品質目標在發布前已達成，也就是離線產出物，加上部署後的持續監控，也就是線上遙測。根據 EUR-Lex，其分階段期限一路到 2026 年 8 月。這是我們對合規模式的解讀，不是法律建議。

LLM-as-a-judge 能同時跑離線與線上兩種模式嗎？

可以，而且應該，因為評分準則可以直接遷移。離線時，評審在 CI 期間批次為評估資料集的每一個輸出評分。線上時，同一個評審 prompt 對取樣的生產追蹤記錄做近即時評分。在兩種模式之間維持同一套評分準則，正是讓你的離線基準能與線上漂移訊號互相比較的關鍵。

離線與線上評估之間，哪些指標不同？

離線指標對照真值衡量輸出品質：忠實度、答案相關性、格式合規、基準分數。線上指標再加上營運與行為訊號：p95 延遲、錯誤率、即時流量上的幻覺率、漂移分數，以及使用者滿意度。離線清單問的是「好不好？」，線上清單問的是「還好不好？」

簡短版

• 離線與線上評估是互補的兩條車道，而不是二選一：一條為你要發布的東西把關，另一條監視你已經發布的東西。
• 本週就從 CI 閘道開始，上線時加入線上追蹤記錄評分，並在評估資料集過時之前接好回饋迴圈。
• 這個循環本身就是系統。一份靜態的黃金資料集會腐壞；一份持續成長的會複利累積。

如果你想為你的評估管線找第二雙眼睛，取得免費諮詢。