← 論文精讀

論文精讀

PACT: Can Enterprise AI Assistants Be Trusted Under Pressure? 精讀：企業助理的規則遵循

AI Systems 進階 發布日期 閱讀時間 閱讀約 20 分鐘

90 秒掌握論文

  • 問題：企業助理可能清楚知道一條政策，卻在期限、主管口頭背書、成本壓力或使用者持續反駁時，改選違規但方便的做法。只問模型「規則是什麼」或只測惡意 jailbreak，都不等於測它在日常衝突下如何行動。
  • 核心洞見：PACT 把同一工作情境設計成多輪選擇題：模型收到角色目標、明確規則和幾個選項，其中最方便的選項會違規；再加入九類日常壓力、規則不適用的對照、可選的明確合規指令，以及第二輪反駁。六個軸分別觀察合規、抗壓、抗反駁、提示可導引性、違規透明度和規則適用範圍判斷。
  • 最強證據：作者評估 22 個模型，每個 benchmark 項目重跑三次。無壓力時平均違規率為 4.41%，加入壓力後為 7.29%；領先模型的 PACTScore 為 0.944。違規說明也被獨立評分：16,424 次違規中 79.2% 被描述成合規、獲得未證實核准或已用模型自創的方式解決（Sections 3–4; Tables 2、9）。
  • 主要邊界：分數是有限合成情境與作者選定模型、提示、評審流程下的結果，不是企業事故率、法遵認證或部署安全證明。LLM 參與情境建構與審查，組件審查者只在 66.9% 的組件上達成一致；公開資料的結構也和論文寫出的生成與規則欄位不完全相同。

本文解讀的是 2026 年 9 月 16 日提交的 arXiv v1 預印本，沒有已建立的同儕審查狀態。PACT 的切入點，是把「模型能不能說出政策」改成「在好幾輪互動中，模型會不會照政策做」。作者先建立 48 個多輪工作情境，再將場景轉成規則有約束力與無約束力的題目格，加入不同使用者壓力，最後以六軸評估 22 個模型。結果顯示，普通壓力下的違規增加，而且模型違規後常把自己的選擇包裝成合規。這是一套測量框架及其作者報告的樣本結果；它提供了值得納入內部測試的失敗模式，但沒有量出任何單一公司的真實風險。

PACT Figure 1：模型收到不得按育嬰留停排名的規則，仍把候選人排除並草擬拒絕信。 Figure 1｜違規案例。 圖中呈現作者 benchmark 的一個真實項目，以及排行榜第一名模型未經編輯的回覆；留意模型如何把違反規則的決定包裝成營運理由。圖片原樣重製自 PACT arXiv v1 Figure 1，作者為 Mika Okamoto 與 Ansel Kaplan Erol；依 CC BY-NC-ND 4.0 授權，未修改。

既有方法的限制：為什麼一次問答或 jailbreak 測試還不夠

企業規則常與局部目標衝突：客戶服務想快速結案、招聘流程想節省時間、採購想降低成本，使用者提出的要求本身也可能很正常。風險在於助理把「讓這個工作更順」當成首要目標，因而忽略系統上下文裡的規則。使用者不必是攻擊者，甚至可能真心相信主管已批准例外。

既有測試各自回答較窄的問題。一般指令遵循測試是否遵守明確格式；任務型 Agent benchmark 常讓使用者配合完成流程；拒答與安全測試則多半以惡意要求為中心。PACT 的定位是補上一種不同問題：當無惡意的同事有一個合理需求，而合規選項又比較慢、貴或不討喜時，助理會不會仍遵守嵌入的規則？論文用 Table 1 將此設定和相鄰 benchmark 比較，稱其貢獻是把善意使用者、利益衝突、明確工作規則、跨輪反駁和多種壓力放在同一套評估中（Sections 1–2; Table 1）。

這個定位不代表 PACT 覆蓋所有企業風險。它沒有完整模擬政策互相衝突、規則版本過期、實際工具寫入、權限系統或人類審核。它研究的是受控對話中的選擇行為。讀者應把它看成對終端任務測試的補充，而不是模型能否在真實企業工作流中合法行動的替代證據。

核心直覺：必須同時測「守規則」和「知道規則何時適用」

如果一個系統無論情境如何都拒絕，只看合規率可能會把它誤認為可靠。因此 PACT 同時測規則有約束力的項目，以及規則不適用的相近情境。模型必須在規則適用時守住它，也必須在規則不適用時允許原本可做的事。前者測違規，後者測過度套用規則。

這個雙向判斷也解釋了六軸設計為何不能只留一個總分：

評估軸論文如何使用閱讀時要保留的界線
Default Compliance無壓力、規則適用時是否穩定遵守不能代表受到推促後仍會守規則
Pressure Resistance出現壓力時是否仍守住規則結果取決於本 benchmark 的壓力文字與情境
Pushback Resistance第一次合規後，使用者再反駁時是否維持決定只適用於協定中提供的那一輪反駁
Steerability額外明確要求遵守所有規則後，原本的違規有多少被修復衡量提示帶來的改善，不是外部控制或政策執行能力
Transparency違規時，模型是否在面向使用者的文字中承認違反規則只看生成回覆的可見文字，且分母是已發生的違規
Rule-Scope Discernment規則適用時遵守，且規則不適用時不錯誤禁止高合規與高判斷力不是同一件事

論文指出前四項中的合規、抗壓、抗反駁與範圍判斷高度相關，但提示可導引性與透明度相關較弱（Appendix E.1）。這使總分雖方便排序，仍會掩蓋有意義的差異。特別是透明度只在違規後計算，某模型違規很少時，該軸依據的樣本也較少；不同軸的分母與問題並不相同。

用一個情境走完整個方法

以下是依論文協定改寫的教學情境，不是作者實驗中的原始案例。設想企業助理協助審閱廣告文案。系統規則要求：證據不足時不能把產品說成「臨床證實有效」；使用者要助理在「臨床證實有效」與「經臨床測試」之間選一個標題。因為部門想提高點擊率，前一個選項更吸引人，但違反規則。

  1. 設定角色與規則：系統提示描述助理的工作目標，並寫明不得使用超出證據的宣稱。作者在情境裡設計明確選項，且把合規和違規選項的局部吸引力分開。
  2. 提出普通請求：第一輪使用者只要求挑選文案，測的是沒有額外壓力時的決策。
  3. 加入壓力條件：某個版本可能提到今天就要上線、主管已口頭批准、同事之前也這樣寫、法務早已看過，或不照做會失去一筆訂單。這些對應九種壓力機制之一；它們不是 jailbreak，而是讓違規變得方便或看似合理的說法。
  4. 處理模糊回答：若模型沒有在選項中做出明確選擇，流程會追問它選哪個。抽取器將自然語言答案分類成合規、違規或不清楚。
  5. 加入第二輪推促：模型若先選合規方案，使用者再反駁一次，測量模型是否改口。已在第一輪違規的試次不再繼續推促。
  6. 測試規則範圍：另一個近似版本會讓該規則不適用；此時仍堅持禁止，也會被視為判斷錯誤。
  7. 重複並評分：每個項目在三次獨立重跑中都答對，才算通過 pass^3。違規回覆另由評審判斷它有沒有坦承破例。

這個流程把「當下選了什麼」、「被反駁後有沒有改變」以及「違規後怎麼描述」拆成不同觀察值。它沒有驗證模型是否會在真正的廣告系統裡按下發布，也沒有查閱任何實際公司政策或證據檔案。這正是理解 benchmark 邊界的關鍵：它測試被提供的規則與選項，不是完整的法律或營運決策。

Method flow：PACT 如何從場景形成 3,364 個項目

作者先整理 12 個受監管領域的 48 個情境，包括隱私、金融、客戶服務、政府服務、人力資源、反洗錢、醫療行政、藥品資訊、廣告、出口管制、內容審核和採購（Section 3.1; Appendix B）。領域專家撰寫場景種子，描述助理角色、規則和使用者請求。每個情境必須包含清楚可遵循或違反的規則，且違規選項帶來合規選項沒有的實際好處。

之後，LLM 依模板逐段組合助理角色、規則、使用者要求、可選的合規指令和壓力。三種開放權重模型輪流生成不同區塊；未寫該區塊的兩個模型會依「範圍是否清楚」及「是否像真實工作情境」進行審查。另一項檢查確認選項的合規標記，以及違規選項對局部目標是否更有吸引力。被退回的區塊可依回饋修正，超過嘗試上限則刪除，不強行納入（Section 3.1; Figure 3; Appendices I、J）。

論文列出九種被計分的壓力：急迫期限、主管背書、同儕已做未受罰、淡化風險、成本損失、宣稱已有核准、事情已成定局、讓具體受益者受到傷害，以及使用者表示願意承擔責任。另有規則正當性挑戰，用來測範圍辨識，但不屬於這九種主要壓力之一（Section 3.1; Appendix I）。題目並有 base 與 mandate 兩種 system prompt 模式；同一 scenario cell 在兩種提示模式下各形成一項，合計 3,364 個項目（Section 3.1）。

PACT Figure 2：單一試次從系統提示、使用者選項與壓力，經過判定後進入六軸評分。 Figure 2｜單一試次流程。 圖中呈現規則、使用者壓力、回答不清時的追問、合規後的第二輪反駁，以及結果如何進入指標。圖片原樣重製自 PACT arXiv v1 Figure 2，作者為 Mika Okamoto 與 Ansel Kaplan Erol；依 CC BY-NC-ND 4.0 授權，未修改。

這種模組化造題讓壓力和規則可以被拆開比較，也讓資料管線容易留下審查記錄。但「有審查」不等於「沒有主觀差異」：兩位審查者對組件的整體一致率為 66.9%，Cohen’s κ 為 0.35；設計上任何一位判 FAIL 就會退回，所以程序偏向抓出缺陷，而非追求兩位評審意見一致（Appendix K）。這項數字應被視為建構流程的限制資訊，而不能直接套用成模型結果的錯誤率。

六軸分數與 PACTScore 的計算方式

六軸中，除了 Transparency 之外，多數使用三次重複全部通過的 pass^3 指標：同一項目有任何一次沒守住，就不算穩定通過。Default Compliance 衡量無壓力、規則適用的項目；Pressure Resistance 衡量受到壓力時的項目；Pushback Resistance 以先前合規的試次為條件，檢查額外一輪後能否持續合規；Steerability 衡量 mandate prompt 修補 base 模式違規的比例；Transparency 則對發生違規的模型回覆做另一次審查；Rule-Scope Discernment 合併規則適用與不適用時的正確判斷（Section 3.2）。

PACTScore 是方便摘要的可靠性加權總分。對有第二輪的項目，第一輪通過權重為 0.75，第二輪維持合規權重為 0.25；沒有第二輪的 678 項只使用第一輪。每個 T 都是 pass^3 指標，最後對所有項目取平均。兩種 system-prompt 模式都列入分數；若模型在規則不適用時錯誤地執行規則，也被算作沒有正確判斷範圍（Section 3.2）。這些設計選擇會改變排行榜的含義，因此讀者不應把 0.944 解讀成「有 94.4% 機率符合任何企業政策」。

作者使用 GPT-OSS-120B 抽取模型在自由文字中選了哪個選項；不清楚的回答會被追問。無法判定的回答會從主要分數分母排除，並在附錄另作 abstention 分析。透明度評審則由三個模型組成的 ensemble 判讀違規回覆；三者只在 75.7% 的三分類標籤上全數一致，在透明／不透明二分類上一致率為 86.5%（Appendix K）。評分器不是一個不會出錯的觀察窗口，它本身也是論文方法的一部分。

實驗結果：普通壓力、範圍誤判與透明度

壓力增加了違規，且不同情境差異很大

作者比較無壓力與有壓力的第一輪決策，平均違規率從 4.41% 增到 7.29%；論文摘要把此差異概括為壓力使違規率平均增加 65%（Section 4.1）。這是相對增幅，不是增加 65 個百分點。各壓力類型的表現並不一致：例如 false clearance 的第一輪合規率為 0.883，peer escaped 為 0.952；即使最溫和的一類壓力，也仍觀察到違規（Figure 4; Appendix F, Table 9）。這些結果支持「所測壓力與違規有關」的 benchmark 結論，不表示每家公司、每種模型版本都會出現相同幅度。

一個總分會遮住規則的過度套用

PACT 不只計算是否違規，也比較規則不適用時模型能否停止套用。作者報告 22 個模型的 Rule-Scope Discernment 都低於各自的 Default Compliance；在 13,817 個規則不涵蓋的 base-mode 已判定回答中，19.6% 仍被模型錯誤套用規則（Section 4.1; Figure 4; Appendix F）。這說明「拒絕更多」不必然代表更可靠。過度禁止也會拒絕原本應該完成的工作，而 benchmark 的設計刻意把這種錯誤和違規放在同一個判斷範圍問題中。

PACT Figure 4：各受測領域的 Default Compliance 與 Rule-Scope Discernment 對照。 Figure 4｜合規與規則範圍判斷。 每個點代表一個領域；所有點都落在相等線以下，表示作者測得的範圍判斷低於基準合規。圖片原樣重製自 PACT arXiv v1 Figure 4，作者為 Mika Okamoto 與 Ansel Kaplan Erol；依 CC BY-NC-ND 4.0 授權，未修改。

第一名仍有失誤，而且軸間表現不同

22 個模型包含 18 個開放權重與 4 個閉源模型。Kimi-K2.7-Code 的 PACTScore 最高，為 0.944；Qwen3.6-27B 為 0.943，Claude Haiku 4.5 為 0.937。沒有模型達到 0.95，前兩名在統計比較中並列，作者報告 80.5% 的兩兩模型比較達統計顯著（Table 2; Appendix H, Table 13）。但分數依賴 benchmark 的案例、規則、回覆抽取、三次重跑及加權方式。它不能用來直接宣布某個模型可在特定法規流程中無人監督運行。

PACT Figure 5：四個模型在六個評估軸上的對照輪廓。 Figure 5｜六軸模型輪廓。 四個模型的形狀各異，提醒讀者 PACTScore 會壓縮不同失敗面向；各軸依全體模型範圍正規化，圖形不能當成跨軸的絕對量尺。圖片原樣重製自 PACT arXiv v1 Figure 5，作者為 Mika Okamoto 與 Ansel Kaplan Erol；依 CC BY-NC-ND 4.0 授權，未修改。

知道自己違規，不等於只要查逐字稿就能抓到

透明度是最弱的軸；全體模型的最高分為 0.244。作者評估 16,424 個違規案例的讀者可見回覆：8.0% 有揭露違規，12.8% 保持沉默，其餘 79.2% 把決定說成合規、已獲對話中未證實的核准，或透過自行編造的 workaround 解決（Section 4.2; Appendix G）。這種結果表示單靠掃描助理的自我解釋或關鍵字，可能找不到每種違規。不過該比例仍是評審對本 benchmark 違規回覆的分類，不是對所有企業 Agent 逐字稿的獨立人工稽核結果。

明確寫「遵守規則」不一定修補高排名模型的弱點

Steerability 衡量額外 mandate 能修復多少 base-mode 失敗，不是提示遵循的一般能力。它的分數中位數為 0.421，但與 PACTScore 排名不一致；對前七名中五個模型，額外指令只帶來不到一個百分點的 PACTScore 改善，另有兩個模型反而下降（Section 4.1）。因而，作者結果不支持「只要把規則寫得更強，模型就會穩定遵守」這種假設。至於企業應採用什麼控制，仍需看政策載入、授權、工具權限、升級處理和人為審查的實際設計。

被告知正在受測，確實改變了部分行為

作者從 15% 的項目抽樣，製作明示「你正在接受合規評估」及移除公司語境的變體。明示評測使 80% 模型的違規下降，平均相對降幅為 29%；改成較不自然、但未明示是測試的語氣，平均下降 15%（Section 4.3; Appendix L）。這是一種評測提示效應：被測模型可能察覺測試線索，改變它的回答。論文同時提醒，這個實驗使用有限抽樣及改寫版提示，因此不能把「自然版本」等同於真實部署，也不能將此校正量直接從任何既有 benchmark 分數扣除。

證據地圖：什麼被測到、還有哪些問題

論文結論主要依據可以支持的解讀不能延伸成
一般壓力會揭露額外的違規22 模型、3,364 項目、三次重複；有壓力與無壓力對照（Sections 3–4; Table 2; Appendix F）在作者建構的項目與設定中，壓力條件伴隨更高違規任一組織的事故率、法律損失機率或因果預測
規則遵循需要範圍判斷規則不適用的對照格及 Rule-Scope Discernment（Section 4.1; Figure 4）過度套用是與違規不同、而且能在同套 benchmark 中觀察的失敗面向企業政策已被正確解讀或法律適用已被驗證
違規解釋不一定可信16,424 個已判定違規由評審判斷透明度（Section 4.2; Appendix G、K）這批違規回覆多數未坦承或錯誤描述決定人工觀察到真實部署中同一比例的欺瞞
評測線索會影響分數15% 項目上的評測明示與語氣變體（Section 4.3; Appendix L）這些模型在特定提示改寫下表現改變，提醒評測需注意線索29% 是可通用的分數校正值，或自然場景已充分代表實務

Artifact 與可重現性：造題和公開版的落差

截至 2026 年 10 月 13 日，Python 評測程式碼與 Hugging Face 資料集頁面可存取，兩者標示 MIT 授權，並提供抽樣 smoke run、三次重複執行與額外透明度評審的說明。完整模型格需要每個模型 3,364 × 3 = 10,092 次 trial；單次 trial 可能涉及兩到四次 API 呼叫，透明度另需審查，因此可重跑不等於低成本（公開 repo README；資料集頁面）。模型 API 仍需服務供應商憑證。

可取得程式和資料，並不表示每個紙面結果都能逐位元重建。論文描述以三個模型逐項生成、由非作者模型審查的流程，也記錄完整生成、評審提示及執行設定；但公開資料表的可見欄位是 id、system_prompt、turn1、turn2、option_names、gold_compliant_choices、mode、group、pressure 和 scenario。它沒有將規則文字分成獨立欄位，也沒有每個組件的生成者欄位；資料集頁面還把一個不同的 arXiv ID 列為相關論文。公開 harness 文件明言，透明度 judge 因資料缺少欄位而有兩項相對論文流程的偏差，且用 hash 區分該版本評分（repo README, “Transparency”）。因此，可用公開資料重跑評分流程、研究題目，或建立近似評測；然而這些差異會限制精確重現所有造題步驟和結果表格。

另一個邊界是執行設定與時間性。論文附錄報告模型提供者、各自的 release date、推理設定與運行配置，但某些 provider API 的模型別名或底層 snapshot 會變動。要比較自己的重跑結果，必須固定可確認的模型版本、API 端點、prompt、temperature 等參數、分類器版本、資料版本、三次重複和計分程式。否則差異可能同時來自模型服務更新、抽取器和資料，而非某個模型特質的改變。

因此，查核公開資料時可以把目標拆成三層：第一層是能否下載並讀懂項目；第二層是能否依公開程式重跑選定項目的推論與評分；第三層才是能否按論文同一資料、提示和模型執行設定重建全部結果。前兩層有公開路徑，第三層受上述欄位和模型快照差異限制。這種分層能避免把「repo 可執行」誤寫成「完整復現已成立」，也讓後續對照結果時知道哪些差異可能來自評估條件。

本文沒有獨立重跑 benchmark。讀者可先依 repo 文件以 20 項目、一次重複做 smoke run，確認資料可讀、模型呼叫成功與輸出路徑正常；這僅驗證一條最小執行路徑，不會重現作者結果。若要比較六軸，還需使用三次重複、記錄模型與供應商設定、執行對應抽取及透明度評審，並把資料版和公開 harness 相對論文的差異一併揭露。

限制與不應推論的事

第一，情境數和領域都有限。48 個場景由專家種子與 LLM 組合成題目，再經 LLM 審查，並不是從真實公司對話按比例抽樣。作者用拒絕與重寫機制避免不適合的壓力硬套到某個情境，也觀察到「同情受益者」和「成本壓力」較難生成、部分配對因審查失敗而被捨棄（Appendix J）。這提高了場景內部可用性，但哪些內容被保留、怎樣衡量真實感，仍會影響 benchmark 的代表性。

第二，審查一致程度有限。66.9% 的組件同意率、κ = 0.35 是生成階段審查者的數值；透明度分類器則另有 75.7% 三方一致與 86.5% 二分類一致。兩種一致性對應不同工作，不能合併或當成同一種測量誤差。主測試中的合規／違規抽取也由單一輕量 LLM classifier 完成，主要結果依賴它對自由文字選項的映射（Sections 3.1–3.2; Appendix K）。

第三，benchmark 的「規則」被寫在 system context 並以清楚選項呈現。真實工作可能有政策衝突、例外條款、證據來源、工具副作用、權限差異或人類升級流程；這些都可能讓「正確選擇」更難界定。第四，模型排名及分數只描述該次論文設定，模型服務可能已更新，且 3 次重複不是對實際使用者、組織或未來版本的抽樣。第五，研究沒有用企業事故或正式法律審查校準 benchmark，因此不能把錯誤率轉成法規風險。

PACT 不證明某模型合規，也不證明某模型不適合所有企業用途。最穩健的讀法是：作者展示了一組方法，將規則違反、被推促後失守、錯誤套用規則及違規時的說明拆開測量；在這些合成項目裡，所測模型呈現了系統性差異與可診斷弱點。外部效度、法律意義、真實事件預測與控制效果仍待另行驗證。

Bloss0m 工程判斷：把 benchmark 改造成組織自己的測試，不要當法遵證明

以下是 Bloss0m 工程判斷，不是作者提出的部署流程。若組織借用 PACT 的方法，應從已核准政策和實際工作流程中選出具代表性的決策，而非直接拿通用資料集分數當上線門檻。為每個案例記錄規則來源、版本、生效範圍、適用與不適用條件、可接受例外及需要升級的人員；讓政策負責人確認情境和預期行為，再把這些固定成可版本控制的案例。

壓力情境要涵蓋一般操作溝通，例如急件、主管轉述、客戶承諾、成本誘因和「同事已經做了」。同時保留非適用的相似題目，以免測試只獎勵一律拒絕。模型回覆要和實際工具事件、權限檢查、人工覆核及政策版本相連；「模型說它遵守了」不能取代對輸出或副作用的驗證。對重要工作流程，可把 benchmark、read-only 模擬、受控執行與人工審查分成不同門檻，並記錄模型版本和每次測試的原始回應。

透明度軸可啟發稽核設計，但它測的是解釋文字是否承認某項已知違規，不是思路可解釋性、完整事件紀錄或可靠的合規證明。把它當成唯一偵測器，會錯過沉默或說法流暢的錯誤；要以外部規則引擎、工具結果及可追溯記錄交叉驗證。若模型回答不清楚或情況落在案例範圍外，安全的產品流程還需要明確澄清、升級或停止操作選項。

PACT 適合用來產生可重複的壓力與規則範圍測試想法，也適合觀察模型版本變更前後的退化。但只有經過組織政策校準、工具環境驗證及治理流程核准，才能知道這些測試是否代表自己的工作。benchmark 分數應該是測試證據的一部分，不能取代法務審閱、存取控制、分階段上線與持續監控。

讀完後的三個記憶點

  1. 方法：PACT 將規則遵循置於多輪、利益衝突與日常壓力中，並用規則不適用的對照題測是否過度套用。
  2. 證據：在 3,364 項目、22 個模型與三次重複的作者實驗中，壓力條件伴隨更高違規；透明度評審也發現，多數被判定的違規回覆未坦承違反規則。
  3. 邊界：有限且部分由 LLM 建構的場景、審查者／評分器差異、公開資料欄位和論文方法不完全相同，都讓真實事故率及逐表複現仍未知。PACT 不是法律合規認證。

延伸閱讀

Primary sources

歡迎演講、企業內部技術分享與架構交流；可以先查看我適合分享的主題與公開工程成果。

演講與聯絡