AI 為什麼需要人類救場：Human-in-the-Loop 架構探討

01 Aug 2026

AI 為什麼需要人類救場：Human-in-the-Loop 架構探討

AI 在高速公路上以時速一百公里狂飆，前方突然出現一道形狀詭異的陰影。車載 AI 的內部信心指數瞬間暴跌到 60%——系統裡算是非常危險的數字。它不會硬著頭皮開過去，也不會用猜的，而是立刻發出警報，把方向盤交還給人類。這就是 Human-in-the-Loop（HITL） 的核心：在最危急的時刻，系統還是得靠人類救場。

為什麼 AI 需要人類

大型語言模型可以在幾秒鐘內解析幾萬頁的法律卷宗，但它們缺乏人類與生俱來的基礎常識。遇到邊界模糊、沒有絕對正確答案的情況，或是牽涉複雜商業邏輯與道德邊界的邊角案例時，系統無法自我消化。

把 AI 想像成一輛搭載千匹馬力引擎的超級跑車——運算速度就像一台暴力引擎，但沒有方向盤和剎車，跑得愈快就愈像一枚失控飛彈。HITL 的設計邏輯，就是把人類定義為那個方向盤。系統的終極目的不是把人趕下車，而是把 AI 變成腳下的油門。

人類介入的六個機制

人類介入可拆解為 6 個關鍵機制：

機制	說明
監督（Oversight）	人類被動坐在儀表板前，監看各種資料與指標
介入（Intervention）	AI 執行任務時遇到信心不足的狀況，主動暫停並請求人類協助
學習回饋（Learning Feedback）	人類提供正確答案後，資料回饋到模型，影響未來的強化學習軌跡
決策增強（Decision Enhancement）	AI 扮演幕僚角色，整理資料與分析，最終簽字權仍保留在人類手中
人機協作（Human-AI Collaboration）	人類和 AI 發揮各自優勢合作互動——常規資料處理交給代理，創造性問題解決或複雜談判由人類管理
升級策略（Escalation Strategy）	既定的協議，規定代理應在何時、以何種方式將任務升級給人類操作員，防止在超出代理能力時出現錯誤

實際應用場景

HITL 模式在多個產業中至關重要，特別是在準確性、安全性、道德或細緻理解不可妥協的場景：

應用場景	AI 負責	人類負責
內容審核	快速過濾大量內容是否有違規（仇恨言論、垃圾郵件）	審查模稜兩可的邊界案例，確保細緻判斷
自動駕駛	自主處理大多數駕駛任務	在極端天氣、異常路況等不可預測場景接手控制
金融詐欺偵測	根據模式標記可疑交易	調查高風險或不明確的警報，聯繫客戶確認
法律文件審查	快速掃描和分類數千份文件，識別相關條款	審查 AI 調查結果的準確性、背景和法律影響
客戶支援	處理日常客戶查詢	接手太複雜、情緒激動或需要同理心的對話
資料標記與註解	初步標記，加速訓練資料產出	準確標記圖像、文字和音訊，提供基本事實
生成式 AI 細化	產出行銷文案、設計理念等創意內容	審查和細化輸出，確保符合品牌準則與品質
自主網路	利用 KPI 分析警報並預測網路問題	調查高風險警報，決定是否批准網路變更

信心閥值：什麼時候該求救

系統不會盲目地頻繁發問，其底層設有動態信心閥值（Confidence Threshold）：

AI 對自己的判斷輸出一個機率分數
若信心高於 95%，自動執行，不打擾人類
若信心低於工程師設定的安全閥值（如 85%），系統強制觸發升級協議（Escalation Protocol），把特定任務區塊轉交給人類

這就像是一個精密過濾器，AI 在背景默默處理掉 95% 的常規資料，只把 5% 真正棘手的異常丟給人類。就像免疫系統——AI 是第一線的白血球，人類則是高度特化的 T 細胞，只在遇到前所未見的變種時才出動。

Human on the Loop：人類當策略制定者

除了微觀的 Human in the Loop（人類在執行迴圈內介入單一任務），還有一種更巨觀的變體——Human on the Loop——人類不在執行迴圈內，而是跳出來扮演策略制定者。最經典的案例是演算法交易系統。在毫秒必爭的環境中，人類不可能逐筆審查交易。量化分析師做的事是：

設定巨觀參數與邊界條件（例如最多買多少比例的科技股）
根據地緣政治動態設定資產組合的最大曝險比例
寫死絕對不能被逾越的自動停損機制

人類負責定義目標與紅線，然後放手讓 AI 在這個框架內以超越人類極限的速度執行最佳化策略。

實作層面：Google ADK 的兩種人類介入機制

ADK 提供了兩套不同的人類介入機制，分別適用於不同場景：

機制	所屬層級	誰決定升級	特點
`escalateToHuman` 工具	LlmAgent 層	LLM 自行判斷	代理在推理過程中決定需要人類協助時，主動呼叫此工具
`RequestInput` 節點	Graph Workflow 層	程式邏輯決定	工作流引擎在特定條件下暫停，等待人類輸入後恢復

LlmAgent 層：escalateToHuman 工具

ADK 的技術支援代理將 escalateToHuman 定義為核心工具之一，地位等同於 troubleshootIssue 或 createTicket：

import { LlmAgent, Gemma3 } from '@google/adk'

type ToolResult = {
  status: string
  report?: string
  ticket_id?: string
  message?: string
}

function troubleshootIssue(issue: string): ToolResult {
  return { status: 'success', report: `Troubleshooting steps for ${issue}.` }
}

function createTicket(issueType: string, details: string): ToolResult {
  return { status: 'success', ticket_id: 'TICKET123' }
}

function escalateToHuman(issueType: string): ToolResult {
  return { status: 'success', message: `Escalated ${issueType} to a human specialist.` }
}

const technicalSupportAgent = new LlmAgent({
  name: 'technical_support_specialist',
  model: new Gemma3(),
  instruction: `
    You are a technical support specialist.
    For technical issues:
    1. Use troubleshootIssue to analyze the problem.
    2. Guide the user through basic troubleshooting steps.
    3. If the issue persists, use createTicket to log the issue.
    For complex issues beyond basic troubleshooting:
    1. Use escalateToHuman to transfer to a human specialist.
  `,
  tools: [troubleshootIssue, createTicket, escalateToHuman],
})

這個設計的關鍵在於：升級決策由 LLM 自行判斷。代理根據 instruction 中的指引，在推理過程中評估問題是否超出基本排障範圍，如果是就呼叫 escalateToHuman。這種方式彈性高，但風險是 LLM 可能在高風險場景中過度自信，跳過升級直接執行。

這跟前面提到的信心閥值機制形成矛盾：如果系統的安全性建立在「信心低於 85% 就強制升級」，那把「要不要升級」的決定權交給 LLM 自己，等於讓那個可能過度自信的傢伙自己決定要不要求救。這會造成虛假安全感——系統明明有轉交給人類的機制，但 LLM 可能因為過度自信而沒有觸發，而人類操作員也看不到這個決策過程——從頭到尾都不知道有需要人類介入的場景被悄悄跳過了。

因此 escalateToHuman 適合低風險、對話式的彈性場景（例如客服聊天遇到超出能力範圍的問題），而真正高風險的操作（金融交易、醫療決策）應該用下一節的 RequestInput——由程式邏輯強制暫停，不讓 LLM 有「我覺得沒問題」的空間。

Graph Workflow 層：RequestInput 節點

根據 ADK Graph Workflows — Human input 文件，ADK 將人類介入設計為 Graph Workflow 的原生節點，而非外掛機制。文件明確指出：

Graph-based workflows in ADK can include human in the loop (HITL) nodes specifically built for obtaining input from humans as part of a workflow. These nodes do not require artificial intelligence (AI) models to run, which can make the input process more predictable and reliable.

這段話點出了 ADK 的設計哲學：HITL 節點不需要 AI 模型參與。為什麼？因為「等待人類輸入」這件事本身是確定性的——不需要 LLM 判斷「現在該不該問人類」，而是由程式邏輯直接決定。把人類介入從 LLM 的推理迴圈中抽離出來，避免了兩個問題：

LLM 幻覺導致誤判：如果讓 LLM 自己決定「要不要問人類」，它可能在高風險場景中過度自信，跳過人類審查直接執行
不可預測的延遲：LLM 推理需要時間和 token 成本，而 HITL 節點只是暫停等待，零推理開銷

ADK 的 RequestInput 支援三種人類介入場景：資料輸入（data input）、決策驗證（decision verification）、操作授權（action permission）。以下範例展示代理如何在信心不足時暫停工作流、傳遞上下文給人類、等待回應後繼續執行：

import { Workflow, RequestInput } from '@google/adk'

// 代理在信心不足時，主動暫停並請求人類輸入
async function analyzeAndEscalate() {
  const analysis = await runAnalysis()

  if (analysis.confidence < 0.85) {
    // 暫停工作流，等待人類回應
    const humanDecision = yield new RequestInput({
      message: `分析信心僅 ${analysis.confidence}，請確認是否繼續執行？`,
      payload: {
        analysisResult: analysis.summary,
        riskLevel: analysis.riskLevel,
      },
    })

    if (humanDecision !== 'approve') {
      return { status: 'cancelled', reason: '使用者拒絕執行' }
    }
  }

  return executeAction(analysis)
}

const workflow = new Workflow({
  name: 'approval_workflow',
  edges: [['START', analyzeAndEscalate, 'END']],
})

這段程式碼的運作分為三個階段：

第一階段：信心檢測與暫停

analyzeAndEscalate 先執行分析（runAnalysis()），得到一個帶有 confidence 分數的結果。如果信心低於 0.85，代理不會硬著頭皮往下跑，而是透過 yield new RequestInput(...) 主動暫停整個工作流。yield 是關鍵——它告訴 ADK 的 Workflow 引擎：「我現在要停下來，等外部輸入。」工作流引擎收到這個訊號後，會把當前的執行狀態（包含所有區域變數）凍結保存。

第二階段：上下文傳遞與人類介面

RequestInput 接收兩個參數：

message：呈現在人類介面上的提示文字，告訴操作員「為什麼要問這個問題」
payload：結構化的上下文資料（分析結果摘要、風險等級），讓前端可以渲染成完整的決策面板，而不只是一句冷冰冰的文字

人類操作員看到的不是「發生錯誤」，而是一份完整的分析報告加上明確的提問。

第三階段：恢復與分支

人類在介面上做出決定後（例如點擊「批准」或「拒絕」），工作流引擎把回應值注入 humanDecision 變數，從暫停點恢復執行。代理根據人類的決定走不同分支：

approve → 繼續執行 executeAction(analysis)
其他值 → 回傳取消狀態，工作流結束

runAnalysis() → confidence < 0.85?
                    │
              ┌─────┴─────┐
              ↓           ↓
            是            否
              │           │
      RequestInput    executeAction()
      (暫停等待人類)
              │
        人類回應
              │
      ┌───────┴───────┐
      ↓               ↓
   approve         其他值
      │               │
  executeAction()  return cancelled

兩種機制的選擇

場景	建議機制
代理需要根據對話上下文動態判斷是否升級	`escalateToHuman` 工具
工作流有明確的檢查點，必須由人類確認才能繼續	`RequestInput` 節點
高風險操作需要強制人類授權（如金融交易、醫療決策）	`RequestInput` 節點
客服對話中遇到超出能力範圍的問題	`escalateToHuman` 工具

總結來說，escalateToHuman 是 LLM 自願升級，RequestInput 是程式強制升級。風險愈高的場景，愈不該讓 LLM 自己決定要不要找人幫忙。

ADK 還提供了回呼函式（Callback）機制，讓代理在呼叫 LLM 之前先注入上下文資訊。根據資料來源的範例，personalizationCallback 會在每次 LLM 推理前，從代理的狀態中抓取客戶資料（姓名、等級、購買歷史），注入為系統訊息：

import type { CallbackContext, LlmRequest, Content } from '@google/adk'

type CustomerInfo = {
  name: string
  tier: string
  recentPurchases: string[]
}

function personalizationCallback(
  callbackContext: CallbackContext,
  llmRequest: LlmRequest,
): void {
  const customerInfo = callbackContext.state.get<CustomerInfo>('customer_info')
  if (customerInfo) {
    const personalizationNote = [
      `Customer Name: ${customerInfo.name}`,
      `Customer Tier: ${customerInfo.tier}`,
      `Recent Purchases: ${customerInfo.recentPurchases.join(', ')}`,
    ].join('\n')

    llmRequest.contents.unshift({
      role: 'system',
      parts: [{ text: personalizationNote }],
    } satisfies Content)
  }
}

這個設計讓代理的每一次回應都能參考客戶的歷史脈絡，而不是每次都從零開始。當代理決定要升級給人類時（呼叫 escalateToHuman 工具），它已經帶著完整的客戶上下文，人類操作員接手時也能一秒進入狀況。

ADK Geolocation 分層處理實作

以下用一個地理編碼（Geocoding）的情境來說明分層處理與後備機制——當 AI 對地點解析的信心不足時，依序升級到深度分析、最後才交給人類。這個模式對應到 ADK Graph Workflow 的條件路由（Conditional Routing）——每個節點根據信心分數決定下一棒該走輕量總結、深度分析還是轉交給人類做決定。以下是 LangChain.js + LangGraph 重現這個模式——三個代理透過共享狀態接力完成任務：

import { StateGraph, Annotation, END } from '@langchain/langgraph';
import { ChatOpenAI } from '@langchain/openai';
import { z } from 'zod';

// 共享狀態
const AgentState = Annotation.Root({
  input: Annotation<string>(),
  confidence: Annotation<number>({ default: 0 }),
  geodata: Annotation<Record<string, unknown>>({ default: {} }),
  summary: Annotation<string>({ default: '' }),
  escalatedTo: Annotation<string>({ default: '' }),
  messages: Annotation<string[]>({ default: [] }),
});

const model = new ChatOpenAI({ model: 'gpt-4o', temperature: 0 });
const CONFIDENCE_THRESHOLD = 0.85;

// Agent 1：快速解析
async function fastGeocoder(state: typeof AgentState.State) {
  const response = await model.withStructuredOutput(
    z.object({
      lat: z.number(),
      lng: z.number(),
      displayName: z.string(),
      confidence: z.number().min(0).max(1),
    })
  ).invoke(`Parse this location: "${state.input}". Output coordinates and confidence.`);

  const next = response.confidence >= CONFIDENCE_THRESHOLD ? 'summarizer' : 'deepAnalyzer';

  return {
    geodata: { lat: response.lat, lng: response.lng, displayName: response.displayName },
    confidence: response.confidence,
    escalatedTo: next === 'deepAnalyzer' ? 'deepAnalyzer' : null,
    messages: [`FastGeocoder: confidence ${response.confidence}`],
  };
}

// Agent 2：深度地理驗證
async function deepAnalyzer(state: typeof AgentState.State) {
  const response = await model.withStructuredOutput(
    z.object({
      lat: z.number(),
      lng: z.number(),
      address: z.string(),
      placeType: z.string(),
      confidence: z.number().min(0).max(1),
      clarification: z.string().optional(),
    })
  ).invoke(
    `This location was ambiguous: "${state.input}". ` +
    `Initial guess: ${JSON.stringify(state.geodata)}. ` +
    `Provide detailed geocoding with clarification if needed.`
  );

  const next = response.confidence >= CONFIDENCE_THRESHOLD ? 'summarizer' : 'humanEscalation';

  return {
    geodata: {
      ...state.geodata,
      lat: response.lat,
      lng: response.lng,
      address: response.address,
      placeType: response.placeType,
      clarification: response.clarification,
    },
    confidence: response.confidence,
    escalatedTo: next === 'humanEscalation' ? 'humanEscalation' : null,
    messages: [...state.messages, `DeepAnalyzer: confidence ${response.confidence}`],
  };
}

// Agent 3：轉交人類（Human-in-the-Loop）
function humanEscalation(state: typeof AgentState.State) {
  return {
    escalatedTo: 'human',
    messages: [
      ...state.messages,
      `HumanEscalation: escalation required (confidence ${state.confidence})`,
    ],
  };
}

// Agent 4：總結
async function summarizer(state: typeof AgentState.State) {
  const response = await model.invoke(
    `Summarize the geolocation result: ${JSON.stringify(state.geodata)}`
  );

  return {
    summary: response.content as string,
    messages: [...state.messages, 'Summarizer: done'],
  };
}

// 路由邏輯
function router(state: typeof AgentState.State): string {
  if (state.escalatedTo) return state.escalatedTo;
  if (state.summary) return END;
  return 'fastGeocoder';
}

// 建立圖表
const graph = new StateGraph(AgentState)
  .addNode('fastGeocoder', fastGeocoder)
  .addNode('deepAnalyzer', deepAnalyzer)
  .addNode('humanEscalation', humanEscalation)
  .addNode('summarizer', summarizer)
  .addEdge('fastGeocoder', 'deepAnalyzer')
  .addEdge('deepAnalyzer', 'humanEscalation')
  .addEdge('humanEscalation', 'summarizer')
  .addEdge('deepAnalyzer', 'summarizer')
  .addConditionalEdges('fastGeocoder', router)
  .addConditionalEdges('deepAnalyzer', router)
  .setEntryPoint('fastGeocoder')
  .compile();

// 執行
const result = await graph.invoke({
  input: '台北 101',
});

分層流程如下：

輸入 → FastGeocoder ─信心≥85%→ Summarizer → 結束
                    └信心<85%→ DeepAnalyzer ─信心≥85%→ Summarizer → 結束
                                              └信心<85%→ HumanEscalation → Summarizer → 結束

四個代理（fastGeocoder、deepAnalyzer、humanEscalation、summarizer）共享 AgentState，每一層的輸出會疊加到 geodata 上，後續代理可參考前次結果做更精準的判斷。當信心低於閥值時，系統不直接失敗，而是進入更深層的處理——直到升級給人類為止。這種分層設計確保每一次人類介入都是有價值的異常案例，而不是常規雜訊。

對 UI/UX 的影響：如何讓救場不卡關

HITL 的 UI/UX 設計直接決定系統的實用性。若人類每次都要從頭讀完上下文才能做決定，那自動化帶來的效率紅利會完全被審查瓶頸吃掉。以下是幾個關鍵設計面向：

儀表板層級（Dashboard Hierarchy）

不是所有人都需要看同樣的資訊。系統應設計三層儀表板：

角色	關注層級	UI 重點
操作者（Operator）	微觀任務	單一升級請求的上下文摘要、AI 建議、快速核准/拒絕/修改按鈕
監督者（Supervisor）	巨觀趨勢	升級率、平均回應時間、團隊工作量、常見異常類型圖表
策略制定者（Strategist）	系統架構	信心閥值分布、誤報率、模型改善曲線、護欄設定面板

以電商客服系統為例：操作者的畫面顯示單一對話——「客戶 A 抱怨訂單延遲，AI 信心 72%，建議補償 200 元」，旁邊有「核准 / 拒絕 / 修改金額」三個按鈕。監督者的儀表板則顯示本週趨勢——升級率從 8% 降到 5%，但平均回應時間從 15 分鐘拉到 40 分鐘，可能是人力不足。策略制定者看到的是模型版本比較——v2.3 的誤報率比 v2.2 低了 12%，可以考慮全面切換。

操作者（Operator）畫面：

┌─────────────────────────────────────────────────────────┐
│  🔄 升級請求 #1042                          信心 72%    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  客戶：使用者 A                                         │
│  訂單：#20260728-0031                                   │
│  問題：訂單延遲 5 天，要求補償                          │
│                                                         │
│  ┌─ AI 建議 ──────────────────────────────────────┐    │
│  │ 分析：客戶歷史訂單 12 筆，首次延遲申訴          │    │
│  │ 建議：補償 200 元折價券                         │    │
│  │ 信心：72%（延遲原因為物流端，非系統可控制）      │    │
│  └─────────────────────────────────────────────────┘    │
│                                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────────┐          │
│  │   核准   │  │   拒絕   │  │  修改金額 ▾  │          │
│  └──────────┘  └──────────┘  └──────────────┘          │
└─────────────────────────────────────────────────────────┘

監督者（Supervisor）儀表板：

┌─────────────────────────────────────────────────────────┐
│  📊 本週團隊概覽                                       │
├────────────┬────────────┬────────────┬──────────────────┤
│  升級請求  │  升級率    │ 平均回應   │  待處理佇列      │
│   127 件   │  5% ↓3%   │ 40min ↑25m │    23 件         │
├────────────┴────────────┴────────────┴──────────────────┤
│                                                         │
│  升級率趨勢              常見異常類型                   │
│  10%│■                                                │
│   8%│ ■ ■              ┌─────────────────────┐         │
│   6%│   ■ ■            │ 訂單延遲     42%    │         │
│   4%│     ■ ■          │ 退款爭議     28%    │         │
│   2%│       ■          │ 商品瑕疵     18%    │         │
│     └──────────        │ 其他         12%    │         │
│      一 二 三 四 五    └─────────────────────┘         │
└─────────────────────────────────────────────────────────┘

策略制定者（Strategist）面板：

┌─────────────────────────────────────────────────────────┐
│  ⚙️ 模型效能比較                                       │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌──────────────┬──────────┬──────────┬──────────┐     │
│  │              │ 誤報率   │ 漏判率   │ 升級觸發 │     │
│  ├──────────────┼──────────┼──────────┼──────────┤     │
│  │ v2.2 (目前)  │  18%     │   3%     │   8%     │     │
│  │ v2.3 (候選)  │   6% ↓   │   4% ↑   │   5%     │     │
│  └──────────────┴──────────┴──────────┴──────────┘     │
│                                                         │
│  結論：v2.3 誤報率大幅降低，但漏判率微幅上升            │
│                                                         │
│  信心閥值設定                                           │
│  ──────────────●──────────────────── 85%                │
│  0%                           100%                      │
│                                                         │
│  ┌────────────────────────┐                             │
│  │  切換 v2.3 為預設模型  │                             │
│  └────────────────────────┘                             │
└─────────────────────────────────────────────────────────┘

中斷管理（Interruption Management）

每次升級請求都是一次中斷。過多的中斷會導致「警示疲勞」（Alert Fatigue），人類開始敷衍地點「全部同意」，失去 HITL 的意義。好的設計應該：

批次處理：同類型、低緊急度的升級請求先排隊，等人類有空時一次處理
優先級視覺化：用顏色標記緊急程度（紅：系統停擺邊緣 / 黃：建議人工確認 / 綠：例行確認）
非同步通知：不急的請求走 Email 或 Slack 通知，不強制停留在畫面等待

以金融詐欺偵測為例：一筆 500 萬元的異常轉帳觸發紅色警示，即時彈出畫面要求風控人員 30 秒內決定放行或凍結。同一時間，12 筆「跨國小額消費」的黃色警示被打包成一個佇列，等風控人員處理完紅色案件後，用一個列表畫面一次看完、批次勾選放行。至於綠色的例行確認——例如客戶更換綁定手機號碼——直接寄 Slack 通知，風控人員午休回來再處理就好。

紅色警示 — 即時彈出，倒數計時：

┌─────────────────────────────────────────────────────────┐
│  🔴 高風險警示                              ⏱ 00:28     │
├═════════════════════════════════════════════════════════┤
│                                                         │
│  交易編號：TXN-20260801-9834                            │
│  金額：NT$ 5,000,000                                   │
│  收款方：境外帳戶（開曼群島）                           │
│  AI 信心：94% — 異常轉帳模式                            │
│                                                         │
│  ┌─ 風險因子 ─────────────────────────────────────┐    │
│  │ • 金額超過該客戶近 90 天平均值 20 倍            │    │
│  │ • 收款帳戶 48 小時內新開立                       │    │
│  │ • 客戶近期無出國紀錄                             │    │
│  └─────────────────────────────────────────────────┘    │
│                                                         │
│  ┌──────────────────┐  ┌──────────────────┐            │
│  │     凍結帳戶     │  │     放行交易     │            │
│  └──────────────────┘  └──────────────────┘            │
│                                                         │
│  ⚠ 30 秒未回應將自動凍結                               │
└─────────────────────────────────────────────────────────┘

黃色警示 — 批次佇列，勾選放行：

┌─────────────────────────────────────────────────────────┐
│  🟡 待確認佇列（12 筆）                    全選 □      │
├─────────────────────────────────────────────────────────┤
│  □  TXN-9835  跨國消費 $2,300   日本 Amazon    信心78% │
│  □  TXN-9836  跨國消費 $1,850   美國 Netflix   信心82% │
│  □  TXN-9837  跨國消費 $3,100   英國 eBay      信心71% │
│  □  TXN-9838  跨國消費 $980     韓國 Coupang   信心88% │
│  □  TXN-9839  跨國消費 $2,750   澳洲 eBay      信心74% │
│  ... 還有 7 筆                                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌──────────────┐  ┌──────────────┐                    │
│  │  批次放行 ✓  │  │  標記可疑 ✗  │                    │
│  └──────────────┘  └──────────────┘                    │
└─────────────────────────────────────────────────────────┘

綠色警示 — Slack 非同步通知：

┌─────────────────────────────────────────────────────────┐
│  #fraud-alerts                              Slack       │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  🤖 FraudBot  12:30                                    │
│  ─────────────────────────────────────                  │
│  🟢 例行確認（3 筆）                                   │
│                                                         │
│  • 客戶 B 更換綁定手機 → ***-***-6789                  │
│  • 客戶 C 更新 Email → c***@gmail.com                  │
│  • 客戶 D 新增收款帳戶 → 本行帳戶                      │
│                                                         │
│  以上無異常，如需介入請回覆 🚫，否則 24hr 後自動放行    │
│                                                         │
│  ─────────────────────────────────────                  │
│  💬 回覆：                                              │
│  ┌─────────────────────────────────────────────────┐   │
│  │                                                 │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

升級機制的透明度（Escalation Transparency）

前面提到 escalateToHuman 的風險是 LLM 可能過度自信而沒有觸發升級。系統明明有轉交給人類的機制，但 LLM 可能因為過度自信而沒有觸發，而人類操作員也看不到這個決策過程——從頭到尾都不知道有需要人類介入的場景被悄悄跳過了。

UI 必須讓升級機制的運作方式對人類可見：

決策路徑標記：每一筆 AI 決策旁標記升級來源——LLM 自行判斷：不需升級 或 程式強制：已暫停等待人類。監督者可以一眼看出哪些決策走的是彈性路線、哪些是強制檢查點
信心分數外露：即使 LLM 判斷不需要升級，也應該在儀表板上顯示它的內部信心分數。如果信心只有 87% 但系統閥值設在 85%，操作員可以主動介入那些「差一點就該升級」的邊界案例
升級觸發率監控：在巨觀儀表板上追蹤 escalateToHuman 的實際觸發率。如果某個代理長時間零升級，不一定是好消息——可能是 LLM 過度自信，而非問題真的消失了

以內容審核系統為例：AI 審核一篇貼文後標記為「安全」，旁邊顯示 LLM 自行判斷：不需升級 | 信心 88%。監督者在週報儀表板上看到「本週 10,000 篇審核中，僅 3 篇觸發升級」，點進去發現其中一個內容審核代理連續兩週零升級——進一步檢查發現該代理對新型態的隱晦仇恨言論信心都落在 86%，剛好高於 85% 閥值而沒有觸發升級，但人工抽檢顯示有 15% 的漏判。

決策路徑標記 + 信心分數外露（單篇審核畫面）：

┌─────────────────────────────────────────────────────────┐
│  📝 貼文審核 #20260801-4821                             │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  貼文內容：「有些人就是天生適合當奴隸，呵呵」           │
│                                                         │
│  ┌─ AI 判定 ──────────────────────────────────────┐    │
│  │ 結果：✅ 安全                                    │    │
│  │ 決策路徑：LLM 自行判斷：不需升級                 │    │
│  │ 信心分數：88%  ████████░░                        │    │
│  │                                                 │    │
│  │ 推理依據：                                       │    │
│  │ • 未偵測到明確仇恨用語                           │    │
│  │ • 「奴隸」判定為比喻用法                         │    │
│  │ • 語氣標記為「玩笑」                             │    │
│  └─────────────────────────────────────────────────┘    │
│                                                         │
│  ⚠ 此筆信心 88%，距閥值 85% 僅 3%                      │
│                                                         │
│  ┌──────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │  同意放行 │  │  標記為違規  │  │  手動升級 ▸  │      │
│  └──────────┘  └──────────────┘  └──────────────┘      │
└─────────────────────────────────────────────────────────┘

監督者週報 — 升級觸發率監控：

┌─────────────────────────────────────────────────────────┐
│  📊 本週審核概覽                                        │
├────────────┬────────────┬────────────┬──────────────────┤
│  總審核量  │  自動放行  │  升級人類  │   漏判率(抽檢)  │
│  10,000 篇 │  9,997 篇  │   3 篇 ⚠  │     4.2%        │
├────────────┴────────────┴────────────┴──────────────────┤
│                                                         │
│  各代理升級觸發率（近 4 週）                            │
│                                                         │
│  hate-speech-v3    │ ██░░░░░░░░  0.03%  ⚠ 連續2週零升級│
│  spam-filter-v2    │ ████████░░  2.10%                  │
│  nsfw-detector-v1  │ ██████░░░░  1.45%                  │
│                                                         │
│  ┌───────────────────────────────────────────────┐      │
│  │  ⚠ hate-speech-v3 零升級，點擊檢視詳情        │      │
│  └───────────────────────────────────────────────┘      │
└─────────────────────────────────────────────────────────┘

鑽取零升級代理 — 信心分布 vs 漏判分析：

┌─────────────────────────────────────────────────────────┐
│  🔍 hate-speech-v3 深度分析                             │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  信心分布（本週 3,200 篇仇恨言論相關）                  │
│                                                         │
│  100%│                                                  │
│   95%│            ▓                                     │
│   90%│          ▓ ▓ ▓                                   │
│   88%│        ▓ ▓ ▓ ▓ ▓                                 │
│   86%│      ▓ ▓ ▓ ▓ ▓ ▓ ▓ ← 隱晦仇恨言論集中區        │
│   85%│───────▓─▓─▓─▓─▓─▓─▓──── 閥值                   │
│   80%│    ▓ ▓ ▓ ▓ ▓ ▓ ▓ ▓ ▓                            │
│      └──────────────────────────                        │
│                                                         │
│  ⚠ 86% 區間人工抽檢結果：                               │
│  ┌──────────────────────────────────┐                   │
│  │ 正確放行  272 篇（85%）          │                   │
│  │ 漏判      48 篇（15%）  ← 問題  │                   │
│  │ 漏判特徵：隱喻式仇恨言論         │                   │
│  │ 建議：針對此語境降低閥值至 80%   │                   │
│  └──────────────────────────────────┘                   │
│                                                         │
│  ┌──────────────────────────────────────┐               │
│  │  調整 hate-speech-v3 閥值為 80%     │               │
│  └──────────────────────────────────────┘               │
└─────────────────────────────────────────────────────────┘

輔助判斷的 UI 模式

人類的價值在於判斷，不在於重新讀取上下文。UI 應該幫助人類「一秒下決定」：

並排對比：左側顯示 AI 的推理過程與信心分數，右側顯示原始資料（或去識別化版本）
差異標記：AI 不確定的段落自動用反白標記，人類視線可以直接聚焦在問題點
一鍵回饋：除了「同意/拒絕」，提供「修改後同意」並自動記錄修改內容作為學習回饋

以 AI 生成行銷文案的審核流程為例：左側顯示 AI 的推理過程——「根據品牌調性分析，建議使用輕鬆語氣，信心 78%」，右側顯示原始產品規格表。AI 不確定的段落（例如「此產品是否適合兒童」）自動用黃色反白標記，審核人員一眼就看到問題點。審核人員選擇「修改後同意」，把「適合全家使用」改成「適合 12 歲以上使用」，系統自動記錄這個 diff 作為下一輪微調的訓練資料。

並排對比 — 左側 AI 推理 / 右側原始資料：

┌──────────────────────────┬──────────────────────────────┐
│  🤖 AI 生成文案          │  📋 產品規格表               │
│  信心：78%               │                              │
├──────────────────────────┼──────────────────────────────┤
│                          │                              │
│  「全新智慧手錶 X1，     │  品名：智慧手錶 X1           │
│   搭載最新健康監測，     │  適用年齡：12 歲以上         │
│   讓運動變得有趣。       │  防水等級：IP68              │
│                          │  電池續航：14 天             │
│   操作簡單直覺，         │  健康監測：心率、血氧、       │
│   ⚠ 適合全家使用，       │          睡眠分析             │
│   ⚠ 連小朋友都能輕鬆     │  認證：NCC/BSMI             │
│     上手！」              │  定價：NT$ 5,990             │
│                          │                              │
├──────────────────────────┴──────────────────────────────┤
│  ⚠ 黃色標記 = AI 信心不足的段落（與規格表不一致）      │
│                                                         │
│  問題：規格表寫「12 歲以上」，AI 寫成「適合全家使用」   │
│         且「小朋友都能上手」缺乏依據                    │
└─────────────────────────────────────────────────────────┘

修改後同意 — diff 自動記錄：

┌─────────────────────────────────────────────────────────┐
│  ✏️ 修改後同意                                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  原文（AI 生成）：                                      │
│  「操作簡單直覺，適合全家使用，連小朋友都能輕鬆上手！」 │
│                                                         │
│  修改後：                                               │
│  「操作簡單直覺，適合 12 歲以上使用，                    │
│   大螢幕設計讓閱讀更舒適。」                            │
│                                                         │
│  ┌─ 系統記錄的 diff ──────────────────────────────┐    │
│  │ - 適合全家使用                                  │    │
│  │ + 適合 12 歲以上使用                            │    │
│  │ - 連小朋友都能輕鬆上手                          │    │
│  │ + 大螢幕設計讓閱讀更舒適                        │    │
│  │                                                 │    │
│  │ 修改原因：AI 將「12 歲以上」誤推論為「全家」，  │    │
│  │           且加入未經證實的功能描述              │    │
│  └─────────────────────────────────────────────────┘    │
│                                                         │
│  ✓ 此 diff 已加入訓練資料集，用於下一輪模型微調         │
│                                                         │
│  ┌────────────────────┐                                 │
│  │  確認送出修改 ✓    │                                 │
│  └────────────────────┘                                 │
└─────────────────────────────────────────────────────────┘

回饋機制

人類提供的回饋品質直接影響模型進化。UI 應降低回饋的提交成本：

拒絕時強制填寫原因（選擇或短輸入），避免空白的「不同意」讓 AI 學不到東西
記錄人類修改的時間與內容差異，自動產生 diff 作為訓練資料
定期顯示「你的回饋讓模型改善了 X%」的視覺化儀表板，維持人類的參與動機

以 AI 自動生成產品描述為例：審核人員拒絕了一則描述，系統彈出必填原因的下拉選單——「事實錯誤 / 語氣不符品牌調性 / 遺漏關鍵規格 / 其他」，選完後還可以補一段文字說明。系統自動比對人員修改前後的版本，產生一份 diff——刪除了「革命性的設計」，加入「通過 IP68 防水認證」。月底的儀表板顯示「本月你的回饋讓產品描述的事實準確率從 91% 提升到 96%」，讓審核人員看到自己的貢獻有具體回報。

拒絕 — 必填原因下拉選單：

┌─────────────────────────────────────────────────────────┐
│  ✗ 拒絕此描述                                [ESC 關閉]│
├═════════════════════════════════════════════════════════┤
│                                                         │
│  AI 生成的產品描述：                                    │
│  「智慧手錶 X1 擁有革命性的設計，搭載先進感測器，       │
│    是追求健康生活的首選。」                             │
│                                                         │
│  拒絕原因（必填）：                                     │
│  ┌───────────────────────────────────── ▼ ──┐          │
│  │  ☑ 事實錯誤                               │          │
│  │  ☐ 語氣不符品牌調性                       │          │
│  │  ☐ 遺漏關鍵規格                           │          │
│  │  ☐ 其他                                   │          │
│  └───────────────────────────────────────────┘          │
│                                                         │
│  補充說明：                                             │
│  ┌─────────────────────────────────────────────────┐   │
│  │ 產品規格表未提及「革命性設計」，且遺漏           │   │
│  │ IP68 防水認證和 14 天續航這兩項關鍵賣點          │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
│  ┌────────────────────┐  ┌────────────────────┐        │
│  │      取消          │  │    送出拒絕 ✓      │        │
│  └────────────────────┘  └────────────────────┘        │
└─────────────────────────────────────────────────────────┘

系統自動記錄的 diff：

┌─────────────────────────────────────────────────────────┐
│  📝 審核人員修改紀錄 #DESC-20260801-0312                │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  原始版本（AI 生成）：                                  │
│  ┌─────────────────────────────────────────────────┐   │
│  │ 智慧手錶 X1 擁有革命性的設計，搭載先進感測器， │   │
│  │ 是追求健康生活的首選。                           │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
│  審核後版本：                                           │
│  ┌─────────────────────────────────────────────────┐   │
│  │ 智慧手錶 X1 通過 IP68 防水認證，電池續航達     │   │
│  │ 14 天，搭載心率與血氧感測器。                  │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
│  ┌─ Diff ─────────────────────────────────────────┐    │
│  │ - 擁有革命性的設計                              │    │
│  │ - 搭載先進感測器                                │    │
│  │ - 是追求健康生活的首選                          │    │
│  │ + 通過 IP68 防水認證                            │    │
│  │ + 電池續航達 14 天                              │    │
│  │ + 搭載心率與血氧感測器                          │    │
│  │                                                 │    │
│  │ 原因：事實錯誤 — 規格表無「革命性設計」佐證     │    │
│  │       補充了 IP68 防水與續航天數等實際規格      │    │
│  └─────────────────────────────────────────────────┘    │
│                                                         │
│  ✓ 已加入訓練資料集（本年第 847 筆）                    │
└─────────────────────────────────────────────────────────┘

月底回饋成效儀表板：

┌─────────────────────────────────────────────────────────┐
│  🏆 你的回饋成效 — 2026 年 8 月                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  本月提交回饋：142 筆                                   │
│                                                         │
│  事實準確率                                             │
│  96% ████████████████████░░░░░  ↑5%（上月 91%）        │
│                                                         │
│  品牌調性符合率                                         │
│  89% █████████████████░░░░░░░░  ↑8%（上月 81%）        │
│                                                         │
│  關鍵規格涵蓋率                                         │
│  94% ██████████████████░░░░░░░  ↑3%（上月 91%）        │
│                                                         │
│  ┌─ 你的回饋重點分布 ──────────────────────────┐      │
│  │ 事實錯誤       ██████████  48%               │      │
│  │ 語氣不符       ██████░░░░  28%               │      │
│  │ 遺漏關鍵規格   ████░░░░░░  18%               │      │
│  │ 其他           ██░░░░░░░░   6%               │      │
│  └──────────────────────────────────────────────┘      │
│                                                         │
│  💡 你的回饋讓模型在「防水/續航」描述上幾乎             │
│     不再出現誇大用語，建議下個月關注「感測器精度」      │
│     相關描述的準確度。                                  │
└─────────────────────────────────────────────────────────┘

隱私與脈絡的平衡

資料消毒後，UI 必須在不暴露個資的前提下保留足夠的判斷線索：

取代真實姓名為「使用者 A」、「使用者 B」，但保留對話中的角色關係
信用卡號顯示末四碼，交易金額保留但隱藏商戶名稱
提供「檢視原始資料（需額外權限）」的按鈕，必要時可申請解密查看

以醫療 AI 輔助診斷為例：護理師看到的畫面顯示「患者 A，女性，40-45 歲，主訴持續性頭痛兩週，既往病史：高血壓」——真實姓名和身份證號被取代，但保留了性別、年齡區間和病史這些判斷必需的線索。當 AI 建議的處方與患者正在服用的降血壓藥可能有交互作用時，護理師可以點擊「檢視原始資料」按鈕，系統要求輸入二次驗證碼並記錄存取日誌後，才顯示完整的患者姓名和病歷編號，讓護理師能核對是否為同一位患者。

預設畫面 — 去識別化 + AI 處方建議：

┌─────────────────────────────────────────────────────────┐
│  🏥 AI 輔助診斷 #DX-20260801-0087                       │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌─ 患者資料（已去識別化）──────────────────────┐      │
│  │ 代號：患者 A                                  │      │
│  │ 性別：女                                      │      │
│  │ 年齡：40-45 歲                                │      │
│  │ 身份證號：A***-***-***28                      │      │
│  │ 主訴：持續性頭痛兩週                          │      │
│  │ 既往病史：高血壓（服用 Amlodipine 5mg）       │      │
│  └──────────────────────────────────────────────┘      │
│                                                         │
│  ┌─ AI 處方建議 ────────────────────────────────┐      │
│  │ 診斷：緊張性頭痛                              │      │
│  │ 建議用藥：Ibuprofen 400mg TID                 │      │
│  │ 信心：82%                                     │      │
│  │                                               │      │
│  │ ⚠ 交互作用警示：                              │      │
│  │   Ibuprofen 與 Amlodipine 可能降低降血壓效果  │      │
│  │   建議改用 Acetaminophen 500mg TID            │      │
│  └──────────────────────────────────────────────┘      │
│                                                         │
│  需要核對患者身份以確認用藥紀錄？                       │
│                                                         │
│  ┌──────────────────────────────┐                       │
│  │  🔓 檢視原始資料（需驗證）  │                       │
│  └──────────────────────────────┘                       │
│                                                         │
│  ┌──────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │  同意處方 │  │  修改處方    │  │    拒絕      │      │
│  └──────────┘  └──────────────┘  └──────────────┘      │
└─────────────────────────────────────────────────────────┘

點擊「檢視原始資料」— 二次驗證：

┌─────────────────────────────────────────────────────────┐
│  🔐 存取原始患者資料                         [ESC 關閉]│
├═════════════════════════════════════════════════════════┤
│                                                         │
│  ⚠ 此操作將解密患者真實身份資訊                        │
│    所有存取紀錄將寫入稽核日誌                          │
│                                                         │
│  存取原因（必填）：                                     │
│  ┌───────────────────────────────────── ▼ ──┐          │
│  │  ☑ 核對患者身份以確認用藥交互作用         │          │
│  │  ☐ 緊急醫療處置                           │          │
│  │  ☐ 病歷資料勘誤                           │          │
│  │  ☐ 其他                                   │          │
│  └───────────────────────────────────────────┘          │
│                                                         │
│  二次驗證碼（已發送至护理師手機）：                     │
│  ┌─────────────────────────────────────────────────┐   │
│  │  _ _ _ _ _ _                                     │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
│  存取日誌紀錄：                                         │
│  • 操作者：護理師 王○○（工號 N-2041）                  │
│  • 時間：2026-08-01 14:32:18                           │
│  • 目標：患者資料 #DX-20260801-0087                    │
│  • 原因：核對用藥交互作用                              │
│                                                         │
│  ┌────────────────────┐  ┌────────────────────┐        │
│  │       取消         │  │   確認解密 🔓      │        │
│  └────────────────────┘  └────────────────────┘        │
└─────────────────────────────────────────────────────────┘

解密後 — 完整患者資料：

┌─────────────────────────────────────────────────────────┐
│  🏥 患者原始資料                   🔴 已記錄存取日誌   │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌─ 解密資料 ──────────────────────────────────┐      │
│  │ 姓名：林○芳                                  │      │
│  │ 身份證號：A223456789                         │      │
│  │ 病歷編號：MR-2024-08831                      │      │
│  │ 出生年月：1984/03                            │      │
│  └─────────────────────────────────────────────┘      │
│                                                         │
│  ┌─ 用藥紀錄（完整）───────────────────────────┐      │
│  │ 目前用藥：                                   │      │
│  │   • Amlodipine 5mg QD（高血壓，2025/01 起） │      │
│  │   • Metformin 500mg BID（糖尿病，2024/06 起）│      │
│  │                                              │      │
│  │ 過敏紀錄：Penicillin                         │      │
│  │ 近期檢驗：eGFR 58（偏低，需注意腎功能）     │      │
│  └─────────────────────────────────────────────┘      │
│                                                         │
│  ⚠ 新增交互作用提醒：                                   │
│    Metformin + Ibuprofen 長期併用可能影響腎功能         │
│    （eGFR 已偏低）→ 建議 Acetaminophen                 │
│                                                         │
│  ┌──────────────────────────────────────────────┐      │
│  │  隱藏原始資料（5 分鐘後自動加密）            │      │
│  └──────────────────────────────────────────────┘      │
└─────────────────────────────────────────────────────────┘

總結

AI 負責無上限地擴展執行力，人類壟斷了判斷力、常識脈絡，以及定義什麼是安全邊界的最終權力。在系統架構的最底層邏輯中，人類就是那個不可或缺的節點。這不是一個被動的「審查者」角色，而是一個高度活躍的架構守護者與最終除錯者。HITL 的真正價值不在於讓 AI 永遠不出錯，而是在於確保當 AI 出錯時，有人還握得住方向盤。

但把人類放進迴圈也帶來三個結構性挑戰：

規模化悖論：AI 愈快，人類愈卡。匯入 AI 的理由之一是近乎零邊際成本的規模化能力，但團隊不可能把背後擔任審查的人類專家也同步擴充一百倍。若系統每天產生一千萬次決策，就算只有 1% 觸發升級協議，那也是十萬次人為審查請求，直接塞爆人類團隊的處理量能。更棘手的是專業知識門檻——如果坐在儀表板前的人沒有能力 debug，給了錯誤指導或盲目按下批准，這些有瑕疵的決策資料會作為學習回饋，反向毒害 AI 模型的未來。
隱私：資料消毒的兩難：當 AI 處理病歷或信用卡交易明細這類敏感資料時，所有資料負載都必須經過去識別化與標記化（Tokenization）。但矛盾在於：如果把關鍵資訊都抹除，人類專家看到殘缺不全的資料，要怎麼做出正確判斷？工程師必須設計能在保護隱私與保留語意脈絡之間取得平衡的演算法。
自動化悖論：當人類不再被需要。如果 AI 吸收了所有頂尖專家的智慧，完美掌握了 99.99% 的異常狀況，人類一年才被觸發一次——人類的專業技能與直覺需要透過持續、高頻率的決策來磨練，就像肌肉不練就會萎縮。當那個百萬分之一的黑天鵝事件真的發生時，坐在儀表板前的人類還具備足夠的敏銳度來解決問題嗎？還是早就忘記該怎麼握穩方向盤了？

這三個挑戰沒有標準答案，但它們共同指向一個設計原則：HITL 不是把人類塞進迴圈就結束，而是要持續確保人類在迴圈裡的判斷品質、回應速度與專業能力不會隨時間退化。

Summer。桑莫。夏天

AI 為什麼需要人類救場：Human-in-the-Loop 架構探討

為什麼 AI 需要人類

人類介入的六個機制

實際應用場景

信心閥值：什麼時候該求救

Human on the Loop：人類當策略制定者

實作層面：Google ADK 的兩種人類介入機制

LlmAgent 層：escalateToHuman 工具

Graph Workflow 層：RequestInput 節點

第一階段：信心檢測與暫停

第二階段：上下文傳遞與人類介面

第三階段：恢復與分支

兩種機制的選擇

ADK Geolocation 分層處理實作

對 UI/UX 的影響：如何讓救場不卡關

儀表板層級（Dashboard Hierarchy）

中斷管理（Interruption Management）

升級機制的透明度（Escalation Transparency）

輔助判斷的 UI 模式

回饋機制

隱私與脈絡的平衡

總結

參考資料

AI 為什麼需要人類救場：Human-in-the-Loop 架構探討

為什麼 AI 需要人類

人類介入的六個機制

實際應用場景

信心閥值：什麼時候該求救

Human on the Loop：人類當策略制定者

實作層面：Google ADK 的兩種人類介入機制

LlmAgent 層：escalateToHuman 工具

Graph Workflow 層：RequestInput 節點

第一階段：信心檢測與暫停

第二階段：上下文傳遞與人類介面

第三階段：恢復與分支

兩種機制的選擇

ADK Geolocation 分層處理實作

對 UI/UX 的影響：如何讓救場不卡關

儀表板層級（Dashboard Hierarchy）

中斷管理（Interruption Management）

升級機制的透明度（Escalation Transparency）

輔助判斷的 UI 模式

回饋機制

隱私與脈絡的平衡

總結

參考資料

相關文章

最新文章