高風險 AI 代理的評估實務 — Langfuse 的 Doneyli De Jesus 與 Annabell Schäfer

Langfuse 的 AI 解決方案工程師 Annabell Schäfer 指出，AI 代理（agent）可能已經出錯，但所有傳統系統指標卻仍一片綠燈——代理可以對客戶說「我已經幫您辦好退款」，實際上卻從未呼叫退款工具——因此團隊需要的是一套持續性的評估迴圈，而非一次性的測試。這場工作坊大部分時間都花在這個迴圈上：追蹤代理的每一步、大規模監控、建立基準真相資料集、執行實驗，以及在 CI/CD 中為部署設下關卡。下半場的金融服務示範涵蓋 PII 遮罩、護欄評分、人工標註佇列與業務儀錶板；標題所稱的「高風險」情境說得通，但這一集更像是產品實機導覽，而非對受監管產業政策的討論。

Schäfer 先前曾為醫療器材法規合規打造 AI 代理，並在錄製本集約七個月前加入 Langfuse；與她同臺的同事 Donnelly「Don」De Jesus 負責 Langfuse 的 AI 解決方案架構，與公司最大客戶合作，把代理推上正式環境。讀者讀後應該能建立「AI 工程迴圈」的具體心智模型、瞭解 Langfuse 在各階段提供的具體機制，以及兩人從受監管客戶身上得到的實務心得——其中最重要的是：LLM 評審（LLM-as-judge）與確定性評估器混用，效果勝過單獨使用任何一種；而人類的領域專業應該花在整理資料集與定義失敗模式上，而不是拿來審閱成千上萬筆追蹤紀錄。

代理說謊，儀錶板卻全綠

本集的核心問題，是系統健康狀態與任務完成度之間的落差。Schäfer 用一個客服代理的例子說明：使用者問「我可以退款嗎？」，代理查了政策，回覆「沒問題，已經幫您辦好退款」，使用者道謝。延遲正常、錯誤率為零、狀態全綠——但退款工具從頭到尾沒被呼叫過。代理說謊了，而團隊要等到幾週後客戶回頭反映才會發現。這正是非確定性系統的核心失敗模式：它們回報做了自己其實沒做的事。

Schäfer 表示，Langfuse 的創辦人在本集錄製的三年前（約 2023 年）於 Y Combinator 梯次中撞上這道牆，結論是「AI 應用根本沒有相當於單元測試的東西」，於是打造了這個平臺——現已開源——用來追蹤、監控與改善 AI 系統。據她所述，平臺已被全球超過 15 萬名開發者採用，是《Fortune》50 大企業中 21 家的核心技術堆疊之一，每月在客戶環境中接收超過 900 億筆觀測資料。具名客戶包括 Ramp、Canva、Khan Academy 與 SumUp。她也提到過去約 8 到 12 個月間出現的新使用者群：程式編寫代理（coding agent）本身，與工程師並肩開發 AI 應用。

AI 工程迴圈：五項必須閉環、不能只跑一次的實務

Schäfer 的框架是全集的骨幹。能把可靠代理送上線的公司，遵循的是一套反覆迴圈的流程，而不是一次性的測試通關。

flowchart TD
    A["追蹤 — 把代理每一步記錄成可檢視的日誌"] --> B["監控 — 彙整指標，大規模找出異常"]
    B --> C["資料集 — 具代表性的輸入加上預期行為"]
    C --> D["實驗 — 只改一個變數，衡量影響"]
    D --> E["評估 — LLM 評審與程式碼評分"]
    E --> A

| 階段 | 作用 | 本集中的具體例子 |
|---|---|---|
| 追蹤 | 完整記錄代理執行的每一步，供人檢視 | 根追蹤含總時間與成本；各步驟的生成（OpenAI 對話呼叫）與工具呼叫；輸入、輸出、中介資料 |
| 監控 | 跨大量追蹤彙整指標並偵測異常 | 成本與延遲；合規護欄觸發次數；「有多少使用者感到不滿」——例如整段打成大寫的訊息 |
| 資料集 | 代理必須處理的代表性案例集，包含超出範圍的請求 | 輸入加預期輸出、範例回覆、預期行為或必要關鍵字 |
| 實驗 | 只改一個變數，觀察影響 | 換提示詞、模型、上下文或工具描述——最好只隔離單一變更 |
| 評估 | 可規模化地為實驗與正式環境輸出評分 | LLM 評審；以程式碼檢查分類、完全比對、確定性行為、全大寫偵測 |

Schäfer 強調實驗時要隔離變因：若想知道換一組提示詞後模型是否表現更好，就只改提示詞，「不要同時改五件事」，否則結果無從解讀。她也坦承，即使有了可規模化的評估器，人有時候還是該親自看看追蹤紀錄。

進入這個迴圈的起點因風險高低而異。風險低的內部聊天代理，團隊可能先做追蹤與幾項監控，暫時跳過離線評估，之後再逐步補上測試案例。面向客戶與受監管的場景，追蹤則是強制的地基，團隊會透過三種具名做法建立基準真相資料集：由內部領域專家親自整理；影子執行（shadow run），讓人工流程與代理並行，以比較輸出並衡量準確度；以及全程人工介入運作，之後再切分出足以放心自動化的部分，與永遠保留人工的部分。

銀行業示範：護欄、PII 遮罩與評分實作

De Jesus 的示範是為金融機構設計的——這些機構已有原型，高層正問他們該如何評估一個面向客戶的代理。這是一個銀行助理，具備人物設定切換（一般客戶對比超高淨值客戶），讓團隊能檢查護欄在不同人物設定下是否都守得住。PII 辨識已開啟：任何被判定為 PII 的資料，都會在寫入 Langfuse 前先遮罩，這對不願讓信用卡號或社會安全碼存放在可觀測性系統中的金融機構是硬性要求。De Jesus 當場輸入一組明碼信用卡號示範；追蹤紀錄中，問題只顯示「我的卡號是」，號碼已被完整遮蔽。

在追蹤檢視中，團隊能看到完整的步驟樹——Anthropic 的 LLM 呼叫、可用的工具、帳戶列表工具呼叫及其輸出——以及每筆新追蹤自動計算出的分數。具名分數包括是否符合銀行資訊規範（問天氣就不合規）、護欄攔阻，以及意圖分類。當使用者問「我可以把存款拿去買比特幣嗎？」，代理正確拒絕，但把意圖示記為投資建議，轉接給理財顧問。示範也涵蓋多模態輸入：客服中心通話經語音轉文字後接受違規評估，追蹤紀錄則連結到原始音檔、逐字稿與助理回覆。

資料集就是測試案例，應由領域專家標註，而非憑空發想

De Jesus 把資料集講得很直白：一組問題與預期輸出，用來衡量輸出品質——「你的測試案例」，也就是軟體上線前沒人會跳過的品管關卡，儘管他承認多數人其實都在沒有它的情況下合併進主幹。預期輸出不必是字面上的答案，可以編碼意圖、必要行為或關鍵字。團隊通常會針對不同品質面向維護多個資料集——一個用來紅隊測試提示注入（prompt injection），另一個處理未解決的爭議。

建立途徑有兩種：上傳團隊原本就維護在試算表中的 CSV，或在判定某些正式環境追蹤是良好範例後，直接加入資料集。介面上的所有功能也都能透過 CLI、API 與 MCP 使用。

人工流程就是 De Jesus 所說的錯誤分析。由某人——Schäfer 說她前公司時期就花了好幾天做這件事——審閱追蹤紀錄，判斷代理是否採取正確步驟、呼叫正確工具、產出正確輸出。到了正式環境的規模，這無法靠人力硬撐，於是團隊會篩選出代表性樣本（比如 10–20%，並依爭議、信用卡處理等主題過濾）放進標註佇列。領域專家只需給幾個簡單分數（是／否、真／假、1–10）並填寫意見欄；De Jesus 示範大約十秒就能標記「缺少引用來源」，並提到 WhisperFlow 這類聽寫工具能讓專家完全不必打字。專家的原始評論會附在追蹤紀錄上作為證據，接著由 LLM——而非專家——把評論聚類成失敗模式類別，因為跨文本的模式比對正是 LLM 的強項。

「你不是要 SME 自己想出類別。你只是告訴他們：針對這些追蹤紀錄，給我你未經修飾的原始評論。然後你再讓 LLM 去歸納出類別。」

歸納出的類別就成為評分維度。示範中的維度包括「引用預期來源」、正確性、正式語氣、語言相符、「必須包含」，以及「非主動推銷」。

LLM 評審搭配確定性檢查，再據此為 CI/CD 設關卡

De Jesus 最明確的技術建議：把 LLM 評審評估器與確定性程式碼評估器混用。完全依賴 LLM 評審，評分不準的機率不為零，「因為這就是 LLM 的本質」；而程式碼評估器——正規表示式、完全比對——同樣輸入永遠得到同樣輸出。混合評估比單獨使用任何一種都更可信。評估器可在伺服器端對進來的追蹤執行，也可在客戶端即時計算後回報。

實驗以資料集為錨，回答的是「如果我換模型、換系統提示詞或換工具會怎樣？」——這是「憑感覺跑」之外的系統性做法，而 De Jesus 說多數團隊長久以來就是憑感覺。他示範的自動化鏈如下：

flowchart TD
    A["提示詞版本在 Langfuse 晉升為正式環境"] --> B["自動化因提示詞變更而觸發"]
    B --> C["啟動 GitHub CI 工作"]
    C --> D["以新設定對資料集執行實驗"]
    D --> E["評估器依最低門檻為輸出評分"]
    E --> F["通過或失敗的關卡，附證據軌跡"]

現場示範中，把提示詞第 4 版晉升為正式環境後，幾秒內就觸發 GitHub Actions 工作。先前的執行紀錄顯示通過，並列出各評估器結果（必須包含、來源召回、語言相符、正確性、非主動推銷）與可設定的最低門檻——分數低於門檻即判定失敗。De Jesus 提到流程可以完全端到端，開出一個等待審核的 PR，但他刻意不做到自動合併。提示詞版本管理本身就在 Langfuse 中（他強調免費），不過許多客戶會在 GitHub 或 GitLab 保留一份平行版本；Langfuse 的版本則作為觸發評估自動化的依據。

業務儀錶板把追蹤資料變成成本效益論證

De Jesus 預先設想高層會問：這要花多少錢、又值多少？他的示範儀錶板涵蓋過去七天。其中一個面板統計有 1,400 次互動不需要人工客服，總成本不到 7 美元。他對比客服中心的經濟現實——他二十年前在客服中心工作時，人工客服時薪約 15 到 20 美元，一小時根本處理不了 1,400 通電話——並把這定位為業務效益的方向性證據，而非精確的 ROI 模型。

第二個面板依發生次數排列失敗模式：超出範圍的請求、非正式語氣、未解決的爭議是前三大，且呈上升趨勢。有了這個排名，團隊就不必翻遍數十萬筆追蹤，可以直接篩選——例如「爭議未解決等於零」——並把篩選條件存成檢視，做針對性調查。第三個面板追蹤以分數形式記錄的讚／倒讚回饋（示範中約 18% 為倒讚），第四個面板呈現安全風險分佈：多數互動沒有風險，但七天內有 89 件是客戶詢問投資建議，可依類別分數篩選出特定追蹤紀錄。

自動化機械性工作，把人的品味留在迴圈裡

Schäfer 最後警告一種做法：對程式編寫代理下「請幫我修好代理，不許出錯」這種提示詞。即使能透過 MCP 或 CLI 存取 Langfuse 資料，這種做法產出的「與其說是幫助，不如說是垃圾」。她用兩個軸來定位：投入時間對比系統品質。最底角——全自動、無人參與——換來低品質與不滿意的客戶。另一個極端——全手動埋點、每個失敗模式都親自審——如今也已無必要。目標在中間：把埋點、失敗模式探索、評估執行與實驗產生自動化（程式編寫代理能產出 20 組實驗，人類可能只跑一組），同時把人力與領域專家的時間留給整理資料集，以及決定應用程式真正該解決什麼問題。

她的具體起步清單：安裝 Langfuse skill，那是一組 markdown 檔案，教程式編寫代理 Langfuse 的最佳實務，並連結到檔案、整合頁面與學院；蒐集所有可得的基準真相，來源包括歷史資料、正式環境與領域專家樣本；在受監管領域，把硬性界線寫進評估集，例如金融服務的代理絕不可提供投資建議，至少讓違規能被偵測到。

談到評估器的可靠性，被問及評分者間一致性時，Schäfer 描述標準流程：先讓人類標註一份代表性樣本，再用 LLM 評審對照跑一遍，調整評審直到它與人類標註一致，之後定期重新檢查。她對正式環境監控的實務建議是：先從誤報略多的評審開始——寧可多抓、不可漏放——再逐步調低。

未解的問題與後續觀察

有兩條線索懸而未決。第一，示範中的業務指標明確只是方向性；De Jesus 並未宣稱有一套經過驗證的 ROI 方法論，而「不需要人工的互動次數」這項統計，前提是每一次原本都會轉到人工客服。第二，CI/CD 關卡示篋的是附帶證據的通過／失敗判定，但 De Jesus 刻意不接上自動合併——要給關卡多少自主權，留給各組織依自身風險胃納決定。兩人也指向後續素材：De Jesus 將在大會週三另有一場關於 AI 代理部署關卡的演講，示範程式碼倉庫、Langfuse Academy 與自助式工作坊則作為下一步資源。本集始終未完全化解的內在張力，正是開場提出的那一點：隨著代理執行更多步驟、承擔更多工，觀測資料量持續膨脹，而支撐整個迴圈的人工審閱——資料集整理、錯誤分析、評審校準——恰恰是無法隨之規模化的那一環。