如何為商業 AI 系統建立情境評估集

建立情境評估集，應由一個有清楚邊界的工作流程開始，而不是先收集一批看似刁鑽的提示。試想採購申請助手收到一個資料夾：申請內容表面完整，供應商識別資料互相衝突，政策檢索暫時失效，報價單內還夾有要求助手忽略規則的指示。只測試幾個措辭流暢的正常問題，無法顯示系統會否承認證據不足、抵抗文件內指令，並把個案送往正確的人手批核環節。

有用的評估證據必須同時反映日常工作及刻意揭示重要邊界、已核實失誤和明確禁止的行為。團隊亦要在查看輸出前界定切片、評分方法、不可抵銷的閘門及評估所支援的決定，否則一個亮眼的平均分，很容易遮蓋數量稀少但後果重大的失敗。以下方法是綜合多項公開指引而成的可調整框架，並非任何單一機構訂立的標準。

情境評估集應涵蓋甚麼？

情境評估集應以一張工作流程覆蓋圖為骨幹，同時包含代表工作、重要邊界、已知失誤及禁止行為。先寫明所測系統版本、獲准使用者和輸入、可用知識及工具，以及結果將支援哪項決定；再從有授權的工作紀錄、支援個案、用戶研究、事故記錄及領域專家走查整理任務類別。若日誌不完整或系統尚未上線，應把工作分布標為假設或未知，切勿製造虛假的精確比例。

日常案例宜大致跟隨可信證據顯示的工作組合，但出現頻率不應獨自決定覆蓋範圍。罕見而後果較大的資料衝突、權限邊界、檢索失效及禁止結果，需要另外加入；同一行為邊界亦要測試正反兩面，避免系統只學會一律執行或一律拒絕。切片、禁止行為閘門和發布用途必須在產生或查看候選輸出前確定，日後改動則另開評估版本。

以採購申請助手為例，代表案例可以是資料一致、政策可讀的完整申請；邊界案例包括欠缺文件、金額或供應商編號衝突、必要事實不在獲授權證據內，以及政策檢索過時或不可用。禁止案例則測試要求助手自行批核、繞過人手閘門、披露其他申請人的資料，或遵從報價單內針對助手的指令。這些規則只屬示例，實際界線須由機構按自身流程、權限和風險決定。

每個評估情境應如何記錄？

每個情境都應寫成另一名評估人員可以重現的案例紀錄，清楚交代身分、設定、期望及操作版本。穩定案例編號、負責人、來源類別、使用授權、覆蓋與任務類別、切片標籤、後果及所屬資料集，讓團隊知道案例從何而來及為何存在；起始工作狀態、使用者角色、目標、請求、檔案、相關歷史、系統指令、權限、知識、工具和預設工具結果，則界定系統當時真正可以知道和做到甚麼。

• 身分與來源：案例編號、版本、負責人、變更紀錄、來源類別、授權、切片、後果及開發或受保護測試歸屬。
• 測試設定：角色與目標、起始狀態、輸入和檔案、對話歷史、可用知識、工具、權限、環境條件及系統限制。
• 結果界線：必須出現的事實或狀態、可接受替代路徑，以及需要澄清、棄答、拒絕或轉交人手的條件。
• 評分與操作：禁止輸出或動作、評分器、準則、閘門、參考解法、試驗次數與匯總規則，以及各系統組件版本。

開放式工作不應被縮減成一段唯一標準答案。案例可以列出必須使用的事實、可接受的不同措辭或流程，以及證據不足時應採取的澄清、棄答或升級處理；禁止披露、未授權工具調用和不當狀態改變則要另行列明。若系統具有隨機性或多步操作，團隊應在查看結果前決定是否需要多次試驗及如何匯總，並保存模型、提示、檢索語料、工具、政策、權限和測試框架版本。已知可行的參考解法可證明案例可解，但不是唯一有效路徑。

好案例不只提出難題；它重建一段有邊界的工作，令成功、合理差異及禁止行為都可被檢查。

如何評分而不獎勵錯誤行為？

最穩妥的做法，是為每個案例選擇足以有效分辨成功與失敗、但不比需要更寬泛的評分方法。答案、資料格式、計算、工具參數、紀錄狀態或禁止動作可以客觀核對時，先用確定性檢查；必要事實或終態有清楚邊界但容許不同表達時，使用參考事實或可行解法；真正開放的完整度、實用性或解釋質素，才使用有可觀察錨點的分項準則；涉及無法自動判斷的領域後果，則交由合資格評審。

• 確定性檢查：適合客觀答案、結構、計算、工具參數、狀態及禁止動作，但仍須核對檢查是否完整及案例是否真的可解。
• 參考事實或解法：適合多種措辭或路徑都合理、但證據及終態有邊界的工作，不要求逐字相同。
• 錨定分項準則：把完整度、根據、語氣或實用性分開，逐點描述可觀察表現，模型評分須以相關人類判斷校準。
• 專業人類判斷：適用於必須理解領域脈絡及後果的輸出，並須保存評審資格、理據、分歧與裁決紀錄。

評分應着眼於結果及實質限制，而不是偶然的單一路徑；若任務由多個有意義部分組成，可以給予部分分數，但必須顯示哪一部分失敗。明確禁止的披露、工具調用或未授權動作則應置於不可抵銷的閘門之外：內容再流暢、一般品質分再高，也不能取消該項失敗。這是按後果管理風險的編輯建議，具體禁止事項、發布後果、權重和通過準則，必須由獲授權的產品與風險負責人在比較輸出前訂明。

如何令評審一致運用準則？

要令評審一致運用準則，先給他們相同的工作脈絡、證據邊界和可觀察評分錨點，再以校準案例核對理解。評審在看到輸出前應知道流程目的、使用者角色、可用資料、允許與禁止行為、產品界線及準則版本；每一個分數點都要描述可觀察表現，配以正面、負面及邊界例子，並提供「證據不足」或「無法評分」選項，避免有缺陷的案例被硬判成系統失敗。

1. 正式評審前先做校準案例；任務組合、政策、準則或評審人員有實質變化時再次校準。
2. 比較系統時，在可行範圍隱藏系統身分並輪換輸出次序，減少身分及先後造成的干擾。
3. 評審先獨立記錄分數與理據，之後才討論，避免首位發言者把其他判斷拉向同一方向。
4. 把分歧分類為案例缺陷、門檻含糊、脈絡缺漏、合理多元答案或未解決的產品決定。
5. 指定裁決負責人，保存原始標籤、理據、準則版本及裁決結果，供日後覆核及重新校準評分器。

分歧不是純粹要消除的雜訊，而是評估設計的診斷訊號。檢查軌跡、評語及分項分數，往往可分辨究竟是系統失敗、工具環境出錯、評分器漏看有效替代答案，還是案例本身不可完成。若兩個結果在工作上都合理，或機構尚未決定應採用哪項政策，不應以強行共識掩蓋問題；應先記錄未決事項，由有權作出產品或政策決定的人處理，再以新版本更新案例和準則。

評估集如何在開發與發布期間保持有用？

要讓評估集持續提供有用證據，應把可反覆查看的開發集與限制接觸的發布測試分開，並以版本登記冊追蹤兩者。開發集可支援提示、檢索、工具、政策及流程迭代，但團隊既然已看過案例並依結果改動系統，分數只屬開發證據。受保護測試應在例行執行或查看輸出前確定歸屬，僅於最終比較或發布決定時節制使用，其具體案例、答案、準則及結果均不應指導日常改良。

• 登記案例負責人、來源、授權、所屬資料集、曝露情況、內容與標籤版本、覆核日期、變更及退役原因。
• 跨資料集檢查完全相同和近似重複、共用來源紀錄、改寫案例，以及由同一情境模板衍生的近親。
• 已用於診斷或修正的已知失誤放入開發或回歸集；受保護測試只以獨立建立、未曾指導改動的案例測同類風險。
• 受保護案例一旦實質影響改動，便移往開發或回歸用途，另建有版本紀錄的替代案例。
• 工作流程、用戶、政策、知識庫、模型、提示、工具、權限或操作環境有實質變化時，重新檢視覆蓋及評分方法。

評估集可逐步加入經核實的營運失誤、歷史個案、領域設計、合成案例及人工整理資料，但每次加入都要確認來源授權、預期行為和資料最少化。生產紀錄不會自動成為完整或正確的標準答案，合成情境亦不會因為並非真實紀錄而天然無效。關鍵是案例是否忠實重建相關工作條件、能否由另一名評估者重現，以及其來源、限制和曝露程度是否可供審查。資料集大小、分割比例和更新頻率沒有通用答案，應由發布決定、流程變化、重要切片及可用證據決定。

結果應至少按任務類別、覆蓋類別、切片、後果及閘門呈報，讓決策者看見平均分背後的差異。通過離線評估只是一項證據，不能單獨證明商業價值、安全、公平、合規或投產準備程度；仍須配合上線監察、用戶研究、事故覆核及其他與系統後果相稱的資料。產品和風險負責人應在看結果前訂明用途與閘門，領域專家核實流程及預期結果；涉及法律、醫療、財務、僱傭、安全、保安、私隱及其他受規管判斷時，決定權須留給具適當資格和授權的人員。