審批人換了之後，企業 AI 測試如何保留可比性

2026年10月30日，微軟研究院介紹了合成企業評估環境，其中已經包含隨時間演變的組織歷史。原始公告

本文討論一個更窄的驗收問題：審批人按規定更換之後，團隊如何保留測試的可比性，並區分應當改變的答案與仍應穩定的業務事實？這是 Open Market Notes 的分析，不是認為微軟遺漏了時間維度。以下公司與流程均為假設示例，並非已披露的部署案例。

先固定一次判斷所處的組織狀態

假設一家設備供應商的銷售助理要回答：「這個客戶的折扣現在由誰批准？」舊郵件記錄著業務主管的意見，新的部門通知把審批責任移交給區域負責人。還有一份尚未生效的流程草案，提出下個月再次調整權限。三份文件都可能真實存在，文字也都說得通。

如果測試只保存一個問題和一個姓名作為標準答案，就會把組織判斷壓縮成字串比對。測試記錄至少需要說明提問時間、規則生效時間、員工身分，以及哪些材料在當時可以被看見。否則，模型答出了不同姓名，團隊無法判斷是檢索錯了、時間理解錯了，還是標準答案已經過期。

文件的上傳時間、內容描述的事件時間和政策的生效時間，可能分別落在三天。把最新上傳的文件一律當成最新規則，會讓一次補錄歷史資料改變現行流程。本文建議在測試中特別安排這樣的衝突，不要讓所有日期天然對齊。

保存變化，而不只是持續增加材料

一套可維護的測試環境，可以有穩定的起點，再附上明確的變更記錄。例如，第一版只包含原審批關係；第二版加入責任移交，但保留舊郵件；第三版再加入未來生效的草案。每次變更只修改少量條件，就能觀察回答在哪一步開始失去依據。

這並不要求完整複製現實公司。過多裝飾性細節會增加維護負擔，卻未必提高判斷價值。若主要風險是生效日期衝突，就優先保留日期、文件狀態與授權關係。餐廳名字、員工興趣等無關資訊可以很少。真實性應服務於要檢驗的錯誤，而不是成為生成資料越多越好的理由。

變更記錄還需要寫出預期保持不變的部分。審批負責人改變，不代表客戶報價也應改變；專案改名，不代表歷史合約自動失效。如果更新測試時同時重寫所有背景，系統的一次退步可能被新的答案掩蓋。保留一些跨版本仍應成立的判斷，有助於辨認這種情況。

身分變化會改變可回答的範圍

微軟的產品說明將存取範圍與使用者權限關聯。產品說明 對採用類似存取模型的企業助理而言，測試中的「使用者是誰」因此不能只是一個顯示名稱。

繼續上述假設：銷售人員可能可以讀取已發布的折扣政策，卻無權查看討論中的重組文件。系統在技術上遵守了存取邊界，仍可能因為缺少決定性材料而無法給出確定姓名。好的測試應允許它解釋依據不足、請求核實或轉交負責人，而不是強迫每一題都有完整答案。

也需要檢驗相反方向。使用者調離專案之後，舊聊天裡曾經出現過的內容是否仍被當作當前可用依據？這不是對某個產品漏洞的指控，而是一項值得設定的測試條件。把同一個問題放在身分變更前後執行，可以檢查團隊實際設定的工作流程。測試結果應記錄所用身分與設定，不能推廣成所有租戶的結論。

從測試環境到真實工作，還需要一段有邊界的試用

NIST 的 AI 風險管理框架把測量與部署情境聯繫起來。框架原文 本文據此提出的實施判斷是：合成測試適合先排除已知的邏輯錯誤；真實試用則需要回答這些錯誤是否涵蓋本公司的主要任務。

一種有限度的做法，是挑選一個低風險團隊和一種可撤回的工作，只讓助理提出建議，由現有負責人審核。記錄被退回的理由，區分來源缺失、政策衝突和使用者需求不清，再把具有代表性的失敗改寫為不含客戶資料的測試條件。這是一種設計方案，不是任意複製生產資料的許可；資料使用仍需單獨滿足機構的授權與保護要求。

試用也有取樣偏差。願意參加的團隊可能文件更整齊，任務更熟悉，審核人也更有耐心。一個部門順利運作，不能直接推出其他部門具備同樣條件。團隊應先說明哪些工作被納入、哪些未被涵蓋，以及停止試用的觸發條件，再解釋成功率。

維護責任應當進入驗收成本

組織一直變化，測試也需要有人更新。業務負責人判斷規則含義，技術人員保存版本和執行結果，審核人員確認標準答案是否仍然適用。如果這些責任被默認交給「模型團隊」，測試庫可能在無人明確負責的情況下逐漸脫離現實。

評估合成企業環境的價值時，可以同時看兩個問題：它是否幫助發現原先遺漏的錯誤，團隊能否以可承擔的成本保持它有效。後者不宜只用生成一批資料花了多久衡量，還應包括修改答案、處理爭議和回查舊結果所需的時間。

對準備部署企業助理的團隊，更有用的交付物是一份帶適用範圍的測試記錄：哪一版組織狀態、哪一種身分、哪一組任務得到了怎樣的結果，哪些變化需要重測。它不能保證未來不出錯，卻能在規則和人員變化時，告訴團隊上一份通過記錄在哪裡開始失去解釋力。