沒有基準測試時，如何評估 AI 代理——Air Canada 的 Nathanael Weill

加拿大航空（Air Canada）的 AI 工程師 Nathanael Weill 主張：無法評分的代理（agent），就無法改進；當公開基準不存在時，團隊應該自行打造測試集。這場演講大部分時間放在一個既沒有基準、專家又抽不出時間的領域——加拿大航空的供應商合約分析——以及他的團隊為此打造的五種測試生成技術；至於讓他學到這個教訓的早期 RAG 專案，只是背景，不是主軸。

Weill 的經驗來自兩個專案：2024 年在前東家為電信工程師打造的問答助理，以及 2026 年在加拿大航空負責的供應商合約審查代理——他於 2026 年 6 月加入，團隊為營運、企業、商業與忠誠度等部門交付 AI 方案。讀者讀完應該帶走三件事：核心的反轉思維（先產生答案，再讓代理去把它找出來）、在合約場景中實際有效與失效的具體技術，以及他為何刻意避開「以 LLM 當評審」的清楚理由。

無法評分，就無法改進

Weill 的核心論點是他在 2024 年學到、並自稱兩年來一直記著的教訓：「無法評分的代理，就無法讓它變好。」他描述的失效模式不是模型能力不足，而是缺乏量測。他在兩家公司都遇到同樣的條件：任務高度特定、沒有公開基準；能判斷輸出好壞的領域專家又極難借調，因為這些專家都坐在忙碌的業務單位裡（在加拿大航空，是依小時計費的律師）。

代價反映在迭代週期上。在電信專案中，團隊改動代理只需幾分鐘——加一層查詢改寫、加一個推理步驟——但要評分，就得每週和專家開一次會：大螢幕上五個不同的聊天機器人回答同一個問題，由專家挑出偏好。Weill 指出，專家們不見得會有一致意見：「兩個專家進同一個房間，會得出三個意見。」結果預算實際上等於每週只能試一次。

他也不諱言，團隊 2024 年的方案接連擊敗兩個外部、一個內部競爭對手，而他並不完全確定原因。他最好的解釋是：「我很確定另一隊根本沒有測試集。」他們有，而這正是他們能持續迭代的關鍵。

反轉問題：先把答案種進去，再讓代理去找

Weill 歸功的這個技術並非他原創——他說是在既有的 RAG 實作中看到的，之後就一直「黏」在他身上。做法不是先出題再評答案，而是從一個來源頁面出發，讓 LLM 針對該頁面出一個問題（這是很簡單的任務），再跑代理，最後拿代理檢索到的內容和出題所依據的頁面比對。這個比對是程式碼，不是主觀意見，因此可以自動化。

在電信專案的結果是：評測產能從每週一次躍升到每天數十次。準確率在幾週內逐步上升，而且——反直覺地——拿掉複雜度反而有幫助。Weill 說，許多精心堆疊的管線元件並沒有讓方案變好，即使那些技術在別人紙上談兵時行得通；而且每加一個元件，都可能弄壞原本能運作的部分。真正關鍵的是對的嵌入模型（embedding model）、對的切塊方式（chunking），以及對的 BM25 alpha。

他也點出 RAG 的實務捷徑：只要找到對的頁面或檔案，大約九成的機率就能得到正確答案，所以真正值得量測的是檢索。

合約處理有四步，只有一步有現成的測試方法

2026 年的加拿大航空專案，分析的是專家目前得逐條人工審閱的供應商合約：標出不合法規之處，並起草修訂條款。延誤的代價很高，因為合約沒過，供應商就無法交貨；漏掉條款的代價也高，因為日後可能反咬一口。Weill 把代理拆成四個階段。

| 步驟 | 代理做什麼 | 專案開始時可用的測試方法 |
|---|---|---|
| 1. 辨識（Spot） | 將合約各段落分類到不同領域，並偵測缺陷或需要修改之處 | 起初沒有 |
| 2. 檢索（Retrieve） | 找出支援修訂條款的檔案 | 沿用 RAG 實務做法 |
| 3. 撰寫（Write） | 起草修訂條款 | 起初沒有 |
| 4. 分類（Classify） | 判斷是否保留該修訂條款 | 起初沒有 |

因為只有檢索有經過驗證的方法，其餘三個階段的評測方式都得自己發明。Weill 把目標定位在「給靈感」而非「秀成果」：他希望聽眾能把這些技術套用到自己的問題上。

自製測試集的五種方法，以及哪些失敗了

Weill 提出五種技術。其中兩種不如預期，他也直說——這比只談成功案例有用得多。

1. 比對歷來合約版本——放棄。 原本的計畫是拿簽署正本與修訂版本，像比對程式碼一樣做 diff，要求代理重現相同的事實。結果卡在紀錄管理：團隊並未儲存所有合約、只留最新版本、缺乏完整版本歷程，而且合約會歷經談判。根本找不到可用的成對樣本。

2. 從已知規則出發——有效，但覆蓋率有疑慮。 拿一條規則，例如某領域的合約金額上限不得超過一百萬美元，生成一段不違反該規則的條款，再圍繞它組出一份合約，代理應該要能找到規則並標出違規。這方法便宜、可大量產生，但前提是你得知道規則。部分規則來自專家及其檔案，無法保證涵蓋全部規則。團隊最後得到 275 個答案已知的測試。

3. 從已簽署合約中移除條款——最強，也最難。 代理應該回報「少了某個東西」。Weill 說這非常難，因為供應商使用的範本與內容各不相同，要判斷哪份合約該有哪些條款，需要專業判斷。他把這類測試與「應該完全不觸發警示」的既有合約混著用。發現是：他們的代理漏掉了大多數被移除的條款，這使此方法成為非常強的基準。

4. 擾動不該有影響的內容——純程式碼檢查。 改掉供應商名稱或地址、調換條款順序，或把同一份合約重跑一次，警示數量都不應該改變。這些全部用程式碼驗證，不涉及任何 LLM 評審。

5. 用生成的組合填範本——重用專家資產。 專家本來就在使用留有空白欄位的合約範本。團隊不靠人工填寫，而是為每個空白欄位生成一組值陣列，產出大量合約，其中有些組合會違反規則、有些不違反，因此預期的警示是事先已知的。這個迴圈較慢——取得專家回饋大約要四週——但指令碼一旦寫好，評測五分鐘就能跑完。

程式碼能判斷的事，就不要交給 LLM 當評審

Weill 依速度與可靠性排列評分方法：完全比對與程式碼檢查非常快，而一旦踏入「以 LLM 當評審」，事情就變難了。他的警告很具體——評審帶來的雜訊遠大於被評代理本身的雜訊，以至於「解決這個問題，幾乎和解決真正的問題一樣難」。他承認評審框架可以做到任務檢查與事實查核，但說團隊在這個專案上找不到合適的一套。

他也提到其他技術但未細講：對必須依既定順序命中各端點的代理做軌跡檢查（trajectory check）——生成一段故事、跑代理、檢視執行軌跡——以及 text-to-SQL。他一再重申的通則是：如果你知道怎麼挑出答案，就生成輸入，然後想辦法把它找出來。

重新設計代理，讓它可被評測

他坦承的一點頗具份量：有時團隊必須重新設計解法，去遷就「先產生、再尋找」的範式，因而稍微偏離原始設計。理由是原始設計根本無法評測，所以換成一個稍微不同、但可量測的設計，是更划算的取捨。

Weill 也說明專家回饋的去向。真實的專家回饋不會直接拿來補丁代理，而是用來生成更好的測試、更好的提示，以及更好的「如何移除條款」的想法——一次一個迴圈，而這些工作他說用現有工具、靠 AI 就能完成。他也為生成式測試集劃下界線：它不足以決定要不要上線。「這只是起點。它是協助、支援開發者的工具，不是方案的上線與否判準。」

「當你生成這些測試，它不足以判斷產品能不能上線。它只是起點。」

主線與未解之處

這兩個專案合起來是一個論證：2024 年電信專案的勝出，可以用「有測試集、而對手顯然沒有」來解釋；2026 年的合約專案，則是想在一個顯而易見的捷徑——版本 diff、公開基準、專家時間——全都不可得的領域裡，買到同樣的優勢。存活下來的技術，都是把評分變成程式碼的技術；失敗的技術，則都依賴企業根本沒儲存的紀錄，或依賴一個和代理本身一樣不可靠的評審。

有兩處張力值得留意。第一，Weill 自己的說法讓因果推論留有餘地——他說自己不知道團隊為何成功，只知道他「很確定」另一隊沒有測試集。第二，合約專案最強的基準（移除條款）同時也是最難的任務，而團隊的代理漏掉了大多數被移除的條款；這個落差會不會縮小、275 個規則型測試加上範本生成的合約是否足以證明覆蓋率，是這場演講沒有回答的開放問題。Weill 最後邀請所有想擺脫「沒有評測就上線代理」的人提供回饋，並說 24 小時門檻是這個習慣最難的部分。