本章定位

▼①~⑤ 预处理 → 护栏 → 分类 → 实体 → 多意图
← 前五章
▼⑥ 置信度决策路由
← 根据置信度决定：直接处理 / 确认 / 兜底
▼路由到对应业务处理节点

意图分类的结果不是百分之百可靠。置信度决策路由就是根据“程序有多确定”来决定走哪条路——高置信直接处理、中置信先确认、低置信兜底转人工。

一、三级路由策略

主要架构

# confidence>= 高阈值 ──→ 直接路由到业务处理节点
# 低阈值 <= confidence <高阈值 ──→ 确认式交互
#     用户确认 → 执行
#     用户否认 → 提供选项 / 转人工
# confidence <低阈值 ──→ 兜底处理
#     提供选项让用户选
#     引导用户重新描述
#     转人工客服

阈值不是全局统一的

不同意图、不同风险等级应该有不同的阈值：

DEFAULT_THRESHOLDS = {
"high"这方面。...,# 高置信线
再看"low"，... # 低置信线
}
HIGH_RISK_THRESHOLDS = {
"high"这方面，...,"low": ...
}
def get_thresholds -> dict:
"""根据意图的风险等级返回对应的阈值。高风险→ 阈值更严格
普通操作 → 默认阈值"""
intent_config = intent_schema.get.get
risk_level = intent_config.get
if risk_level == "high":
return HIGH_RISK_THRESHOLDS
return DEFAULT_THRESHOLDS

二、高置信路由：直接执行

做什么

程序对分类结果足够自信，直接路由到对应的业务处理节点。

实现

from typing import Literal
from langgraph.graph import END
def route_high_confidence -> str:
"""高置信路由：根据 L1 意图路由到对应的业务处理节点。返回节点名称，"""
l1 = state
route_map = {
再看"售前咨询"，"presale_handler","售后服务": "aftersale_handler","投诉建议": "complaint_handler","账号问题": "account_handler","闲聊": "chitchat_handler",}
target = route_map.get
return target
def pre_route_check -> str:
"""路由前置检查：
槽位齐全 → 进入业务处理
槽位缺失 → 进入追问节点"""
if state.get:
return "route_to_business"
至于else。return "ask_for_missing_slots"
def ask_for_missing_slots_node -> dict:
"""追问缺失槽位"""
return {
'response': state,'awaiting_slot_fill': True,}

三、中置信路由：确认式交互

程序不够确定，先向使用者展示识别结果，请求确认后再处理。其实，

确认话术生成

def generate_confirmation -> dict:
"""生成确认话术。根据意图类型生成不同风格的确认问题。"""
l1 = state
l2 = state
confidence = state
entities = state.get
intent_label = f"{l1} - {l2}"
entity_parts =
if entities.get:
entity_parts.append
if entities.get:
entity_parts.append
entity_text = f"" if entity_parts else ""
confirmation = f"请确认：您是想要「{l2}」{entity_text}吗？"
options = (
f"请回复：
"
f"1. 是的
"
f"2. 不是我想要的是..."
)
return {
'response': f"{confirmation}
{options}",'awaiting_confirmation': True,'pending_intent': {'l1': l1。'l2': l2},}

处理使用者的确认回复

def handle_confirmation_response -> dict:
"""处理使用者对意图确认的回复。"""
user_reply = state.strip
pending = state.get
negative_signals =
positive_signals =
is_denied = any
for s in negative_signals)
is_confirmed = and any(
user_reply == s or user_reply.startswith
for s in positive_signals)
if is_confirmed:
return {
'l1_intent' : pending。'l2_intent' : pending,'confidence' : None,# 使用者确认后提高置信度可自行设定
'awaiting_confirmation' : False,'confirmation_status' : 'confirmed',}
if is_denied:
return {
'awaiting_confirmation' : False,'confirmation_status' : 'denied',# 否认后进入兜底流程…}
# 模糊回复，直接转兜底或
询问…return {
'awaiting_confirmation' : False,'confirmation_status' : 'unclear'。}
MAX_CONFIRMATION_ROUNDS=5
def should_escalate_confirmation->bool:
rounds=state.get
return rounds>=MAX_CONFIRMATION_ROUNDS

使用者痛点嵌入：

• 答非所问导致多轮交流，增加等待时间。
• 当程序无法判断时若没有明确提示会让客户感到迷茫。
• 过多重复提问会降低满意度，特别是在退款等敏感场景。
• 错误地把“不是”误判为肯定。会出现错误操作，损害品牌信誉。
• 缺失槽位时继续执行可能导致订单信息错误，引发投诉。
• 未能及时转人工会导致客户流失与口碑下降。
• KPI 如高置信率、兜底率需实时监控，以防模型质量波动影响体验。
• C级客服负担加重时需要快速切换至人工转接机制。不过，
• 在多语言环境下对话风格和语义解析需细化。以避免误解，
• A/B测试中发现过高阈值导致正面反馈下降，需要动态调节策略。
• PROMPT 调整可提高识别准确率，但需要持续迭代以匹配新业务需求。

从常用方法来看，

• 三级路由高置信直接处理 | 中置信先确认 | 低置信兜底；保证每种情况都有清晰方法；避免无谓等待与卡顿，
• ，高风险操作使用更严格门槛；防止错误触发导致重大损失。
• 槽位联动即使高信心。也必须完整槽位，否则先追问；避免因缺失信息而产生误操作。
• 确认交互自动生成友好话术并支持最大5轮；不过，超限则放弃并转兜底；按理说，减少误判与重复沟通。
• 兜底分级提供选项、引导重述或人工转接，逐步递进确保覆盖率与满意度平衡。
• 阈值调优上线初期保守，高精度目标为80%+；随数据积累每周校准一次实现精准控制。
• 监控告警实时跟踪高/中/低信任比例、人工转接率及成功率；立即报警并回滚配置，