AI 回歸測試怎麼做？模型、提示、RAG 與 Agent 版本比較
AI 系統更新不像一般程式只看功能有沒有壞。換模型、提示、temperature、知識庫、切塊、檢索參數、工具或政策，都可能讓某些案例變好、另一些案例退步。回歸測試的目的不是證明新版永遠更好，而是讓團隊知道改了什麼、哪些情境倒退，以及是否仍在批准範圍。
建立不能被平均掉的固定回歸集
回歸集至少包含代表性正常任務、業務關鍵邊界、曾發生的重大錯誤、權限與安全案例、無答案、逾時、停止與人工轉接。每次事件或近失都應轉成可重跑案例，並保留修復後的預期行為。到AI 測試案例庫挑選起始模式，再依真實流程補上公司自己的資料與規則。
重大未授權動作、資料洩漏或不可逆錯誤必須獨立阻斷，不與一般成功率平均。其餘指標則依AI 評測指標資料庫分開追蹤任務、依據、安全、營運、成本與人工影響。
固定條件，逐次只解釋已知變更
比較前鎖定測試集版本、模型、提示、工具、索引、執行參數、環境與重跑次數。若更換測試資料或 rubric，就不能把新分數直接當成前後進步。對有隨機性的生成結果，應重跑代表性案例並報告變異，不只挑最好的一次。
NIST AI 800-2 初稿把評測協議、程式、執行、追蹤與除錯列為一組相連實務；結果要能重現，也要揭露協議與限制。它仍是初稿，不是正式標準，但版本化與可比較性原則很適合企業回歸流程。
看逐題差異，不只看總平均
報告至少分成：原本通過仍通過、原本失敗已修復、原本通過卻退步、新增案例、評測器分歧與無法判斷。依角色、語言、資料來源、類別與嚴重度分群，才能看見少數高風險案例被整體平均掩蓋。
模型評審可先標出語意差異，但高影響與分歧案例要人工複核。NIST AI 800-3 也提醒，benchmark 統計可能混淆不同表現概念或沒有正確量化不確定性；至少保存樣本數、變異與分析假設。
把回歸接到變更與發布閘門
定義哪些變更只跑冒煙測試、哪些跑特定風險集、哪些必須跑完整驗收。例如只改文案可跑格式與核心任務；換模型、索引或工具權限則應跑完整品質、安全與營運集。回歸失敗時建立新候選修正，不在同一份結果上事後移動門檻。
使用AI 驗收計畫產生器整理變更後的案例與停止條件，並把版本、結果、批准與回復方案連到AI 系統清冊。上線後若真實修正率、事件或成本偏離，再把新失敗加入下一輪回歸。