離線評測回答「是否具備上線資格」
離線評測的主要價值不是預測所有上線結果，而是在版本發布前，用可重複的方法找出明顯退步、已知風險與邊界條件。對企業 AI 助理而言，一套實用的測試資料不應只收錄理想問題，還要涵蓋縮寫、錯字、資訊不足、權限差異、過期文件、相互矛盾的資料，以及使用者要求系統執行越權操作等情境。資料來源可以是經過去識別化的歷史問題、流程文件與工程團隊刻意設計的對抗案例，但必須保留情境分類，否則總體分數很容易掩蓋某一類高風險失敗。
評測項目也要對應系統架構。RAG 系統應分開檢查檢索結果、重排、答案生成與引用，而不是只判斷最後文字是否流暢。串接 ERP、CRM 或 LINE 的代理型系統，則要驗證工具選擇、參數、權限、重試行為與確認步驟。模型輸出可以由規則、模型裁判及人工審查共同評估，但模型裁判必須先以人工標註樣本校準；對法務、財務、資安或會改寫正式紀錄的工作，人工審查仍是發布閘門的一部分。
- 固定回歸集：保留關鍵流程與曾經發生過的錯誤，用來比較模型、提示詞、知識庫或程式碼版本。
- 分群觀察：依任務、資料來源、語言、權限與風險檢視結果，避免平均值掩蓋局部退步。
- 明確失敗定義：區分無法回答、答錯、缺少依據、格式錯誤、工具誤用與不當揭露，讓修正方向可執行。
- 版本可重現：記錄模型、提示詞、檢索設定、文件快照與評測程式，確保比較的是實際變更而非環境差異。
線上評測回答「在真實流程中是否有用」
即使離線表現穩定，系統進入真實環境後仍會遇到測試集沒有涵蓋的問題，例如公司內部新術語、文件更新延遲、使用者以多輪對話補充需求，或上游 API 回傳非預期資料。線上評測因此應觀察完整任務，而不只是對單一回答按讚或倒讚。較有用的訊號包括任務是否完成、是否需要人工接手、使用者是否反覆改寫問題、引用內容是否被開啟、工具操作是否被取消，以及結果是否遭後續人工修正。這些訊號仍需結合情境判讀；例如快速轉人工，可能代表模型失敗，也可能是風險控管正確運作。
線上實驗不一定等於立即對所有使用者做 A/B 測試。涉及付款、客戶資料、庫存、合約或設備控制時，可先採影子模式，讓新版本處理相同輸入但不回覆也不執行動作；接著再限制使用者、資料範圍或可呼叫工具，逐步放大。低風險的知識查詢可以較快進入受控流量，但仍要保留版本標記、輸入輸出、檢索文件、工具呼叫、延遲、錯誤與人工接手原因。沒有這些軌跡，團隊通常只能知道使用者不滿意，卻無法判斷問題來自模型、資料、整合服務還是流程設計。
依風險、可逆性與可觀測性分配責任
離線與線上的比重不應由模型類型決定，而應由錯誤後果決定。若輸出只是內部草稿，且使用者能在送出前檢查，團隊可以接受較快的線上學習節奏。若系統會自動更新 CRM、建立訂單、調整設備或回覆外部客戶，就需要更嚴格的離線情境測試、權限隔離、人工確認與小範圍發布。關鍵問題包括：錯誤是否容易被發現、動作是否可撤銷、影響範圍是否能被限制，以及異常發生時能否快速停用新版本。
發布條件最好寫成一份工程契約：哪些離線案例不得退步、哪些安全檢查必須通過、線上要監控哪些訊號、何種異常會停止放量，以及回滾時要還原哪些模型、提示詞、索引與服務設定。門檻不必永遠固定，但變更應有理由與紀錄。尤其在流量較少的企業流程中，單靠統計顯著性可能等不到結論；此時應結合任務級追蹤、專家審查、影子結果與具體錯誤分析，而不是把「尚未觀察到問題」當成安全證明。
把兩套評測接成持續改善閉環
成熟的做法不是維護互不相干的離線報表與線上儀表板，而是讓線上失敗回到離線測試。團隊可以定期抽樣人工接手、低信心回答、工具錯誤與使用者修正，在完成權限確認及資料去識別化後，轉成新的回歸案例。相反地，每個離線失敗類型也應對應線上警示或追蹤欄位，確保發布後能辨認相同問題。新增案例時要避免把正式測試答案混入提示詞或知識庫，否則分數上升可能只是資料洩漏。
最後，評測需要明確的共同責任：產品負責定義任務是否成功，領域專家判斷答案是否可採用，資料與 AI 工程師維護資料集和模型指標，平台團隊確保觀測、權限與回滾可靠。整合團隊的價值在於把這些要求落到同一條交付管線，讓每次模型、文件或系統介面變更，都能先離線驗證，再在線上受控觀察，並把新證據帶回下一輪開發。