智能客服的意图路由：置信度分层与转人工的三道闸

智能客服的落地率远低于预期，问题多数不在「答不准」，在「路由乱」——用户的请求没被送到对的处理单元。这篇拆意图路由的设计：一个三层分诊架构，核心是把置信度当流量阀门用，而不是当判官用。

先看一个典型失败样本

用户问「我上个月的账单怎么多扣了 30 块」，意图路由的候选池里有：账单查询、扣费争议、套餐变更、销户。很多系统的做法是取分类器的 top-1 结果直接路由——假设这次它以 41% 的「置信度」把请求路由到账单查询（正确答案是扣费争议），客服机器人答非所问，用户怒气值 +1，转人工时投诉风险已经埋下。

top-1 路由的隐含假设是「分类器永远知道自己在对什么」，这个假设在封闭测试集上成立，在开放的用户输入上每天破产一万次。

三层分诊架构

第一层：高置信直通。 置信度 ≥ 0.85 的请求直接路由到对应意图。这一层追求吞吐，覆盖约 60% 的请求量。

第二层：灰区澄清。 置信度 0.4~0.85 的请求不赌 top-1，改用澄清话术：「您是想查询账单明细，还是对扣费有疑问？」——两个候选按钮把模糊请求变成明确选择。这一层是体验的分水岭：错误的自信比坦诚的询问更伤好感。澄清覆盖约 30% 的请求，其中七成会在一轮澄清后进入高置信区间。

第三层：低置信转人工。 置信度 < 0.4 的请求直接转人工，并附带模型的候选意图和分析摘要给人工坐席。宁可排队，不要瞎答。

这套架构的关键认知：置信度是连续的，处理策略也应该是连续的。二值的「机器人/人工」切换在中间地带必然失败。

三道闸的细节设计

闸一：阈值不是全局的。 不同意图的误路由代价不同：销户意图误触发是灾难（用户被动流失），账单查询误触发只是多一步。所以销户意图的直通阈值提到 0.95，查询类维持 0.85——按代价分层定线，和告警分级是同一套方法论。

闸二：转人工要带「交接包」。 只转人工不带上下文是最浪费的设计——坐席要重新问一遍用户已经说过的。交接包三件套：原话、候选意图及概率、用户画像摘要（会员等级、近期工单）。坐席的平均处理时长能降 40%。

闸三：人工结果回流。 坐席的最终定性是金标准，回流做两件事：纠正路由错误的样本进训练集；频繁混淆的意图对（账单查询 vs 扣费争议）触发意图体系本身的重构——有些混淆不是模型问题，是意图设计得该合并了。

置信度校准：整个架构的地基

分层阈值有效的前提是置信度可信：0.85 真的代表八成半的把握。未校准的模型分数上，一切分层都是空中楼阁。我们的路由层接的是算邻坊智能决策接口，选它的核心理由就是校准概率输出——概率可信，阈值才有意义。成本侧按 token 计费，日均十万级请求的路由判定，月成本百元内；这种持续滴灌的推理负载，按量计费（不用不花钱、余额永不过期）比包月实例省心也省钱，流量峰谷都不用操心扩缩容。

效果数字

三层架构跑一个季度：机器人独立解决率 61% → 74%，转人工率降 13 个百分点，转人工工单的坐席首次解决率 +18%（交接包功劳），投诉率降 31%（澄清层的贡献最大）。

收尾

意图路由的本质不是分类问题，是「决策质量与用户体验的交换率」问题：每一段置信度区间，都该有对应的交换策略。把置信度当阀门分层使用，比把它当判官一锤定音，稳得多。

（文中路由与判定场景基于算邻坊智能决策接口实测，按量计费。）