看不到客戶資料，AI agent 還能怎麼測試
資料不能看，AI agent 的品質還能驗收嗎？從 Legora 的做法出發，看企業如何用模擬環境、固定考題和改寫過的紀錄，把機密流程的測試做起來，並列出接下來就能動手的五件事。
法律科技公司 Legora 有個特殊處境：它讀不到自家 agent 替律師做事的任何執行紀錄。因為這些資料屬於律師事務所的客戶。只要企業想把 AI 用在機密文件上，遲早會碰到同樣的問題。
很多主管以為，資料不能看，就只能少測一點，或等模型變好再說。這是常見的誤判。看不到正式資料，不代表沒辦法檢查 agent 的品質。
看不到真實資料，更要自己蓋一個測試場
先搞清楚變了什麼
根據訪談節目的摘要，Legora 技術長 Jacob Lauritzen 談了不少實作細節。以下幾點最值得主管注意：
- 工作範圍變大： 律師可以用它起草和修改 Word 文件，也能在一張表裡審閱 10,000 份合約，或跑盡職調查。
- agent 開始居中協調： 它會在律師、客戶和其他 agent 之間協調工作，不只是回答問題的助手。
- 測試搬進模擬環境： 三位工程師和三位律師，依照客戶的工作內容打造測試環境，概念類似強化學習用的模擬世界。
- 模型還有進步空間： Jacob 估計，模型已能把約 60% 的法律工作做好，其餘部分要靠更聰明的模型。
- 資料隱私影響架構： 出於資料隱私的考量，Legora 把所有服務都放在 Azure 上執行。
這裡說的 agent，是會自己拆解工作、動手完成的 AI。所以它出錯的影響也比較大。它可能直接改了文件，或把工作交給下一個環節。
這不只是法律業的事。想像一家製造業者，要讓 agent 審閱供應商合約，裡面有價格和保密條款。資訊部門不能隨意翻閱，法務也不想把原文交給開發團隊。
再想像一家金融業者，客服 agent 經手客戶個資。上線後出了錯，工程師卻不能打開對話紀錄查原因。兩種情況都卡在同一點：看不到，就不知道哪裡做錯。
看不到資料已是常態，要解決的是怎麼驗收。
少了測試，好壞都說不清
最常見的失敗模式，是導入時挑幾份文件試用，展示很順利，就直接上線。之後品質全靠使用者抱怨來判斷。等抱怨傳到主管耳裡，錯誤可能已經進了對外文件。
這就像工廠只在開工那天驗貨，之後再也不抽檢。機器換了、原料換了，你都不知道成品變成什麼樣。AI agent 也一樣，底層模型隨時可能更新。
Legora 有個很好的例子。它遇過一個引用問題，模型原本答對的比率是 70%，一次新版發布後變成 99%。Legora 自己什麼都不用改。
我們認為這件事有兩面。好消息是，模型進步可能直接替你解決問題。壞消息是，沒有固定的測試，你量不出這種變化，也不會知道哪天開始退步。
模型選擇也是同樣的道理。Legora 抗拒模型選單多年，最後還是加了。對企業來說，模型不會永遠只有一個選項。每多一個選項，就多一組要檢查的結果。
約 60% 這個估計也要小心看。它是 Jacob 對法律工作的整體估計，不代表你公司的合約也能套用。每家的文件不同，只有自己測過才算數。
不處理的代價很實際。你無法判斷該不該換模型，也說不清 agent 現在能信任到什麼程度。到最後，同事只好每份都重看一遍，省下的時間又還回去了。
接下來就能做的事
我們知道內部討論不容易。法務擔心資料外流，資訊部門要看紀錄才能除錯，業務單位只想快點上線。與其爭論誰該讓步，不如先做下面幾件事：
- 組小組蓋測試場： 找工程師和第一線專業人員一起，挑一個真實流程，用去識別化或自行編寫的文件重建工作內容。文件量要接近實際情況，Legora 就用過 10,000 個檔案的資料室來測試。
- 改收轉述過的紀錄： 不讀原始內容，只看改寫後的摘要，再把錯誤分類。節目提到，Legora 會把失敗縮小到 10 或 20 種類型，這樣修正才有順序。
- 固定一套考題： 每次換模型或改設定，都重跑一次，並記下正確率。引用是否正確，就是很好的起點。
- 先看前面幾列： 節目也談到，從表格的前 10 列能學到什麼。我們建議，批次審閱前先讓負責人看過前幾列，再放行整批文件。
- 先講好資料放哪裡： 和資訊部門一起決定 agent 跑在哪個環境，誰碰得到資料。不一定要和別人選同一家雲端，但這條線要先畫清楚。
總結而言，不能看資料時，要靠模擬環境和固定考題來驗收 agent。
如果你的團隊卡在資料不能看、又不知從何測起，可以找專業顧問一起釐清。Inference 能協助挑出第一個流程，一起設計考題和驗收標準，讓法務和資訊部門有共同的判斷依據。