如何為你的 AI 管道設計人在迴路工作流程

大多數 HITL 指導停留在原則上：保持人類在迴路中。本文關於實施——建立在生產環境中有效（而非只是在設計審查中）的 HITL 系統所需做出的具體決定。

框架有七個步驟。它們是順序的，因為每個步驟的輸出成為下一個步驟的輸入。你可以跳過步驟，但當某些事情出問題時你會重新建立它們。

第 1 步：風險評估——2x2 矩陣

在設計任何 HITL 流程之前，你需要知道哪些決策需要它以及需要多大強度。在兩個軸上映射你的 AI 的決策：

後果嚴重性（低 → 災難性）：當 AI 出錯時會發生什麼？錯誤的產品推薦浪費用戶的注意力。錯誤的藥物劑量建議使患者處於風險中。嚴重性是關於傷害的程度，而非其概率。

決策可逆性（容易可逆 → 不可逆）：錯誤能否事後糾正？錯誤路由的支援工單很容易糾正。提交的帶有幻覺引用的法庭簡報則不然。

對決策所在位置要誠實。團隊通常通過考慮典型情況而非最壞的合理情況來低估後果嚴重性。評估第 95 百分位結果，而非中位數。

這個矩陣告訴你哪些決策需要 HITL 以及大致什麼強度——但不是如何實施。那是接下來的內容。

第 2 步：定義干預點

人類可以在三個地方與 AI 決策相交：

行動之前（阻塞）：AI 提出建議；人類批准或拒絕；只有在批准後才執行操作。最高可靠性，最高延遲，最高人工成本。高後果不可逆決策必需。

行動期間（監控）：AI 行動；人類實時觀察並可以停止或修改。僅在行動有持續時間（流程、生成的文件、工作流程）允許有意義干預時有效。對於即時決策無效。

行動之後（稽核）：AI 行動；系統記錄；人類按定義的時間表審查日誌，可在時間窗口內撤銷決策。適合中後果可逆決策。撤銷的時間窗口必須明確指定——「有人會審查日誌」不是一個設計。

對於大多數企業 AI 系統，不同的決策類型需要不同的干預點。信用 AI 可能對超過 10 萬美元的拒絕使用行動前 HITL，對低置信度閾值以下的自動批准使用行動後稽核。精確定義這個是大多數團隊跳過的設計工作。

第 3 步：設計審查介面

審查介面是 HITL 成功或失敗的地方。設計不良的介面產生與完全沒有 HITL 相同的結果：審查員對輸出進行橡皮圖章批准，沒有有意義的參與。

審查員做出獨立決定必須看到的內容：

AI 的輸出：建議、分類或生成的內容——清晰呈現，而非深埋。

AI 的推理：模型如何達到這個輸出？輸入的哪些特徵驅動了它？對於產生結構化推理的微調模型，這是明確的。對於通用模型，提示進行思維鏈推理是必要的。沒有可見推理的輸出無法被有效質疑。

置信度或不確定性信號：模型對這個輸出的置信度是多少？置信度分數、不確定性範圍或明確的對沖語言是審查員校準需要多仔細審查的必要輸入。高置信度輸出和 51% 置信度輸出需要不同的審查努力程度。

備選輸出：對於分類任務，顯示第二和第三最可能的類別及其概率。對於生成任務，如果模型產生了備選草稿或措辭，顯示它們。這打破了錨定效應——只看到 AI 首選輸出的審查員傾向於孤立地評估它。

溯源：AI 使用了什麼資料？對於基於 RAG 的系統，檢索了什麼文件？對於微調模型，哪個訓練領域最相關？關於 AI 信息來源的上下文幫助審查員識別模型何時可能在其可靠範圍之外進行外推。

還有一個要求：介面必須使記錄審查員的推理變得容易，而不只是他們的決定。「批准」告訴你一個人點擊了一個按鈕。「批准——與借款人三年收入歷史一致，LTV 在政策範圍內」告訴你一個人做出了判斷。這個差異對稽核追蹤品質和檢測自動化偏差都很重要。

第 4 步：設置升級閾值

並非每個決策都需要同等程度的人類注意。升級閾值允許你根據 AI 置信度和決策特徵將決策路由到正確的審查級別。

簡單的閾值結構：

• 置信度 ≥ 0.92：自動批准，帶稽核日誌。以第 5 步中定義的抽樣率進行人工抽查。
• 0.75 ≤ 置信度 < 0.92：路由到標準審查員。標準審查介面，24 小時 SLA。
• 置信度低於 0.75：路由到資深審查員。帶額外上下文的擴展審查介面，4 小時 SLA。
• 置信度低於 0.60，且屬於高後果類別：需要雙重簽核。不允許單一審查員批准。

這些數字是說明性的。你的閾值應根據模型實際的置信度-準確性關係進行校準。一個在正確時報告 0.90 置信度但只有 70% 的時候是正確的模型是未校準的——設置為該模型名義置信度分數的閾值會將太多錯誤路由到自動批准。

根據經驗校準閾值，而非憑直覺。運行保留集，測量每個置信度十分位數的實際準確率，並根據每個審查層可接受的準確率級別設置閾值。

第 5 步：防止自動化偏差

自動化偏差——過度依賴 AI 建議的傾向——是 HITL 系統隨時間退化的主要機制。三種對策在實踐中有效：

對自動批准決策的隨機抽查：即使在最高置信度層，也隨機抽取 2-5% 進行人工審查。這為你提供關於自動批准閾值是否仍然校準的持續資料，並讓審查員保持與 AI 在其分布的置信端實際做什麼的接觸。

校準練習：定期向審查員呈現已知基準事實的歷史決策——AI 做對和做錯的案例混合——而不透露 AI 的建議。這測量審查員的獨立判斷如何追蹤實際結果，並識別可能過度依賴 AI 輸出的審查員。

審查員問責記錄：每個審查員的決策歷史必須被追蹤和審查。如果一個審查員在通過其隊列的所有事物中批准 99.5%，要麼 AI 幾乎完美，要麼審查員在橡皮圖章批准。兩者都值得調查。

不要告訴審查員抽查的情況。如果他們知道哪些審查正在被監控，他們會在那些上表現不同。隨機監控的價值在於每次審查都可能被監控。

第 6 步：建立稽核追蹤

稽核追蹤不是可有可無的。它同時是你的合規證據、檢測 HITL 退化的機制，以及調查特定事件的工具。

每個 HITL 事件必須記錄：

• 時間戳（精確到秒）
• 審查員身份（不是共享登入——個人帳戶）
• 呈現給審查員的 AI 輸出（不是摘要——實際輸出）
• AI 的置信度分數和顯示的任何其他信號
• 審查員的決定
• 審查員記錄的推理（自由文字，必填——不是可選的）
• 案例是自動批准、標準審查、升級審查還是抽查
• 審查花費的時間（這是參與品質的代理指標）

稽核追蹤必須是不可變的。審查員不應能夠事後編輯他們的記錄決定。決定了什麼以及何時決定的記錄對監管審查和事件調查都必須是可靠的。

將其存儲在你的法律和合規團隊可以訪問和匯出的系統中。存在於工程部門以外的人無法查詢的開發者資料庫中的 HITL 日誌在操作上沒有用。

第 7 步：測量 HITL 有效性

HITL 是一個系統。系統需要指標。如果不測量有效性，你無法區分有效的 HITL 和看起來有效的 HITL。

重要的指標：

• 按置信度層的覆蓋率：在每個置信度級別，多少百分比的人類審查員正在覆蓋 AI 建議？在低置信度層非常低的覆蓋率表明審查員可能沒有有意義地參與。
• 決策時間：審查員每次審查花多長時間？對複雜決策少於 5 秒的審查值得調查。
• 下游結果跟踪：在可行的情況下，將 AI 建議並人工批准的決策結果與純人工決策進行比較。這是你測量 AI 是否真的有幫助的方法。
• 抽查錯誤率：在抽查中審查的自動批准決策中，有多少百分比是錯誤的？這是告訴你閾值是否校準的指標。
• 審查員在校準練習中的準確率：你的審查員做出好的獨立判斷嗎？他們追蹤實際結果嗎？獨立準確率差的審查員不是有效的保障。

每月審查這些指標。為每個設置觸發流程審查的閾值——例如，如果抽查錯誤率超過 5%，自動批准閾值需要重新校準。

常見失敗模式

太多低信號警報：警報疲勞是 HITL 最常見的死亡原因。調整你的路由閾值，使到達人工審查的案例值得人工審查。將明顯的案例——高置信度、低後果——路由到自動批准。

埋藏關鍵信息的審查 UI：如果審查員必須瀏覽三個屏幕才能看到 AI 的推理，他們不會這樣做。在單個視圖上顯示他們需要的一切。

對橡皮圖章批准沒有後果：如果審查員知道他們的個人決定沒有被追蹤，稽核日誌從未被檢查，HITL 就退化為表面文章。問責制是執行機制。

不捕獲推理的稽核日誌：只捕獲「批准/拒絕」的日誌告訴你人類是否參與了什麼都沒有。要求每次審查都有記錄的推理。

沒有重新訓練迴路：HITL 也是資料收集機制。人工覆蓋決策，尤其是對高置信度輸出的，是模型改進的黃金標準訓練信號。如果覆蓋資料沒有回流到模型開發流程，你就浪費了系統一半的價值。

Ertas Data Suite：為 HITL 整合管道而建

Ertas Data Suite 中的標注和標注工作流程圍繞與生產 HITL 相同的原則設計。領域專家直接在工具中標注資料。每個操作——標注、糾正、審查、批准——都記錄了操作員身份和時間戳。稽核追蹤內建在資料準備流程中，而非事後從系統日誌中組裝。

對於建立在生產中需要 HITL 的 AI 系統的組織，訓練資料準備應該實踐同樣的規範：在資料階段有文件記錄、歸屬、可稽核的人類監督。你用來訓練模型的管道是你將應用於部署模型的治理標準的預覽。

請參閱什麼是人在迴路 AI？ 了解基礎框架，以及當 AI 系統在沒有你的情況下運行時 了解使 HITL 必要的生產失敗模式。

預約與 Ertas 的探索通話 →

HITL 不是單一功能。它是跨越風險評估、流程架構、介面設計、測量和持續改進的系統設計。建立正確的團隊不是一次建立它——他們維護它。將其視為複選框的團隊建立一次，然後看著它退化。