W
AI-Wiki
CONCEPT

基于置信度与风险的HITL动态路由

定义

基于置信度与风险的HITL动态路由，是指在 HITL Agent 系统处理用户请求时，不是只看一次大模型输出是否“像是对的”，也不是默认全交给 AI 或全交给人工，而是先通过一组评估与预检机制，对请求的可自动化程度和潜在业务后果做联合判断，再把请求动态送入不同处理路径。

这里的“动态”有两层含义：一是每个请求都按当前信号单独判断；二是路由阈值和规则会随着人工反馈、规则注入、模型迭代与知识沉淀持续调整。

其核心不是单一的“模型置信度阈值”，而是至少同时结合以下几类信号：

  • 模型置信度
  • 风险评分
  • 合规性检查
  • 上下文一致性

因此，它本质上是一种风险加权的入口控制机制，而不是简单的分类器后处理逻辑。

在本文档中的语境

在本文语境中，这一机制位于“用户请求”进入系统后的首个关键分流点，处在智能路由网关与 AI能力评估层 之间，决定请求后续进入：

  • 全自动执行
  • 人工审核
  • 混合模式

它不是孤立模块，而是企业级 HITL 架构中的入口编排原语：

  • 向前承接智能路由网关对请求的接入与预处理。
  • 向中间连接 AI能力评估层 对能力、风险和一致性的综合打分。
  • 向后把任务派发到 AI 执行引擎或 人工干预决策中心。
  • 再通过 HITL Agent双反馈闭环 把人工决策沉淀为规则、训练数据和知识资产。

因此，它决定的不只是“谁来处理”，还影响：

  • 自动化率
  • 人工介入率
  • 合规风险暴露
  • 审核成本
  • 响应时延
  • 后续反馈闭环的效率

关键判断原则

不是只看模型置信度

本文明确强调，路由判断不能单看模型置信度。即使一个回答表面上置信度很高，只要业务风险高、合规预检不过、或上下文一致性异常，仍然不应直接进入全自动通道。

这意味着在生产系统里，以下情况都可能导致“高置信度但不能自动放行”：

  • 任务属于金融、医疗等高合规场景，单次错误代价极高。
  • 输入涉及监管约束，需要先做合规性预检。
  • 当前请求与历史上下文、用户状态、业务流程状态不一致。
  • 模型虽然给出高分答案，但不确定性量化显示分布不稳定。

反过来，低风险、上下文清晰、合规预检通过的请求，即便不是最高置信度，也可以进入混合模式，而不必一律转人工。

风险加权而非单点输出信任

高合规行业必须采用风险加权路由，而不能只靠大模型单次输出，原因主要有三点：

  1. 单次输出只反映模型当前生成的表面确定性，不等于业务后果可接受。
  2. 高风险场景的错误成本是非线性的，少量误判也可能引发监管、法律或生命安全问题。
  3. 合规要求往往需要可审计、可追踪、可解释，不能把最终责任压在一次黑盒生成上。

因此，在医疗、金融等场景中，路由层更像“风险闸门”，而不是“置信度大于某值就自动执行”的简单开关。

关键组成

AI能力评估层的关键组成

本文把动态路由建立在 AI能力评估层 之上，该层至少包含以下关键组成：

1. 置信度计算模块

这是最直接的自动化判断信号，用于评估模型对当前任务输出结果的把握程度。文中明确指出，该模块并不是裸置信度分数，而是集成了更丰富的评估能力。

2. 不确定性量化

不确定性量化用于识别“模型看起来很肯定，但其实不稳定”的情况。它补足了普通置信度分数的缺陷，使系统能区分：

  • 真正高把握的输出
  • 只是在某种提示结构下看起来高分的输出

这一步是路由从“表面信心”升级到“稳健性评估”的关键。

3. SHAP 值解释

文中提到置信度计算模块集成 SHAP 值解释。其作用不是直接替代决策，而是增强可解释性，帮助系统或人工理解：

  • 哪些输入特征推动了当前判断
  • 为什么系统给出高或低置信度
  • 哪些因素造成风险升高或判定不稳定

在企业环境中，这一能力尤其有利于审计、复盘和人工复核。

4. 风险预测模型

风险预测模型负责把“答案对不对”之外的业务后果显式建模。文中给出的典型增强方式是：在金融场景中加入合规性预检。

也就是说，风险模型不仅预测一般错误风险，还要吸收：

  • 业务风险权重
  • 合规触发条件
  • 监管敏感字段
  • 异常交易或异常决策模式

5. 上下文一致性检测器

上下文一致性检测器用于判断当前输入、历史状态与处理中任务是否相互一致。它的作用是拦截这样的问题：

  • 当前请求与前序会话状态冲突
  • 用户身份、业务阶段或任务上下文切换后仍沿用旧结论
  • 多轮决策中的关键信息发生漂移

对 Agent 系统来说，这一步很重要，因为很多错误并非来自“不会答”，而是来自“上下文接错了”。

多路分流模式

本文明确支持三种分流模式，而不是只有 AI/人工二选一。

1. 全自动

当系统判断任务置信度高、风险低、合规通过且上下文一致时，请求可以直接进入 AI 执行引擎，输出结果再集成到业务系统。

这一模式追求最高效率，适合：

  • 标准化程度高的任务
  • 历史样本充分的任务
  • 低风险、低争议的任务

2. 人工审核

当置信度不足、风险偏高、合规预检有问题，或上下文出现异常时，请求直接转入人工工作流，由 人工干预决策中心 派发给人工工作台处理。

本文还给出分级任务派发系统，支持 L1-L3 专家支持，说明“人工审核”并不是一个单层队列，而是可按复杂度和风险继续分层。

3. 混合模式

混合模式是本文特别强调的中间态，即不是完全自动，也不是完全人工接管，而是人机协同执行。

它适合：

  • 模型已有一定把握，但尚不足以无监督放行
  • 风险可控，但需要人工确认关键节点
  • 需要 AI 先给建议、人工再裁决的任务

在这个模式里，AI 通常负责：

  • 预分析
  • 证据整理
  • 建议标签与决策依据生成
  • 任务优先级辅助判断

人工则负责最终确认、修正和异常处置。

文中伪代码与阈值

文中给出了一段明确的置信度路由伪代码，其核心阈值如下：

  • confidence > 0.9 且 risk_score < 0.3：走 AI 执行路径
  • 0.7 < confidence <= 0.9：走混合模式
  • 其他情况：转人工工单

可整理为：

def route_request(input_data):
confidence = uncertainty_model.predict(input_data)
risk_score = compliance_checker.evaluate(input_data)

if confidence > 0.9 and risk_score < 0.3:
return ai_engine.execute(input_data)
elif 0.7 < confidence <= 0.9:
return hybrid_executor.run(input_data)  # 人机协同模式
else:
return human_workflow.create_ticket(
input_data,
priority=risk_score*10
)

这里有几个值得注意的工程细节：