客服工单路由第一课：用 Nimble 做高并发有界判断，预算直降为 0
客服工单系统是典型的"高并发 + 有界判断"场景：每一张新工单进来，系统都要在几个固定问题上给出答案——这是什么类别的问题？优先级多高？应该转给哪个团队？选项永远就那么几十个，但调用量是每天百万级。过去我们习惯把这类问题丢给通用大模型，让它生成一段 JSON 再解析，结果既慢、又贵、还经常输出非法格式。2026 年 9 月 Bespoke Labs 开源的 Bespoke-Nimble-9B 提供了另一种思路：模型不生成任何文本，只对候选答案打分——一次前向传播输出多个选项的概率分布，端到端延迟落在毫秒级。配合本地化部署，单次判断的 API 成本直接归零。本文以客服工单路由为落地场景，结合仓库源码拆解三件事：为什么这类问题天生适合决策模型、schema 怎么设计、置信度阈值和错误率监控怎么落地。
一、工单路由为什么是决策模型的主场：有界选项 + 高频调用
工单路由本质上不是"写作任务"，而是"判断题"。它有两个鲜明的结构特征：
选项有界。工单分类、优先级、归属部门都是预先定义好的枚举集合。系统需要的不是模型自由发挥，而是在给定集合中选出一个最合适的答案。这恰好是 Bespoke-Nimble-9B 的设计定位——README 开门见山：它是一个面向 "context-grounded choices, booleans, and rubric score levels" 的 LoRA 适配器，评估流程中模型不生成推理、不输出自由文本，直接对允许的答案 token 打分（见 README.md）。
调用高频。每张工单至少要做一次分类判断，峰值期每秒几十上百次。自回归生成模型一次回答要逐个 token 生成，推理时延与输出长度强相关；而 Nimble 的 serving 方式完全不同——官方文档的描述是 "process the context and schema once, then obtain the scores for the tokens we care about"：上下文只 prefill 一次，每个问题只需要模型输出最后一个位置、候选答案对应 token 的 logits。仓库中的 inference.py 把这一点写得很直白：
def candidate_logits(model, inputs): logits = model(input_ids=inputs["input_ids"], attention_mask=inputs["attention_mask"], use_cache=False, logits_to_keep=1).logits[:, -1, :].float() selected = logits.gather(1, inputs["candidate_ids"]) return selected.masked_fill(~inputs["candidate_mask"], -torch.inf)logits_to_keep=1意味着只保留最后一个位置，gather只取出候选 token 对应的 logits——整个解码过程只有一次前向传播，没有生成循环。这就是"快"的来源。
效果如何？官方在 324 个留出样例上的对照给出了直观的量化：Bespoke-Nimble-9B 对参考标签的一致率达90.12%，而未经微调的基础模型 Qwen3.5-9B 只有 66.36%（见 schema_config.json 中注册的bespoke-eval评估）。延迟方面，官方在 H100 上实测中位数约 106ms；社区在 Ollama 0.35 上报告本地运行 Nimble 系列决策模型的典型延迟已压到 91ms、中位数 33ms。对工单路由这类任务而言，这个量级意味着可以在网关层同步完成判断，而不是把每张工单都送进一个几十秒的生成式调用。
"预算直降为 0"并非夸张修辞：模型权重开源（Apache 2.0），LoRA 适配器仅约 165 MiB，base 权重来自 Qwen3.5-9B。本地部署意味着没有按 token 计费的 API 账单，唯一成本是硬件和电力。
二、schema 设计：类型、优先级、归属部门怎么建模
Nimble 的使用接口极其收敛：给定一段 context（工单文本）和一个 schema（问题清单），返回类型化结果和每个候选答案的概率。仓库中的 README.md 给出了最小示例：
from inference import NimbleModel model = NimbleModel("nimble-model") result = model.score( context="The store accepts returns within 30 days. This item was bought 12 days ago.", schema={ "eligible": { "type": "boolean", "description": "Is this item within the store return window?" } }, ) print(result["output"]) print(result["fields"]["eligible"]["probabilities"])schema 的三条铁律
把源码里的校验逻辑（见 extended_schema.py 与 parallel_schema.py 的validate_schema）翻译成工程约束，就三条：
- schema 必须是扁平结构，不支持嵌套字段，每个字段独立判断；
- 字段类型只有两种：
enum（枚举选择，1–255 个字符串选项）和boolean（真/假）；字段必须有非空的description，这是模型理解语义的主要来源； - 选项去重、不能为空，布尔字段必须恰好包含
true/false各一次。
超出限制的 schema 会在调用前被直接拒绝（ValueError），而不是被静默截断——这是刻意设计：宁可报错，也不让模型在一个残缺的契约上瞎猜。
把工单路由翻译成 schema
以一张客服工单为例，路由判断通常包含三个维度：类别（归属哪个业务线）、优先级（紧急程度）、是否需要人工复核。可以建模为：
schema = { "category": { "type": "enum", "choices": ["ACCOUNT", "BILLING", "TECHNICAL", "AFTER_SALES"], "description": "工单所属的业务类别", "choice_descriptions": { "ACCOUNT": "账号登录、权限与资料变更问题", "BILLING": "账单、扣款、发票与退款问题", "TECHNICAL": "产品功能故障与接口报错问题", "AFTER_SALES": "退换货、物流与售后政策问题", }, }, "priority": { "type": "enum", "choices": ["P0", "P1", "P2", "P3"], "description": "基于当前业务影响的紧急程度", "choice_descriptions": { "P0": "核心业务完全不可用或资金安全受影响", "P1": "大部分用户受影响且业务持续受损", "P2": "局部功能受影响，存在临时方案", "P3": "无当前业务影响的可选改进", }, }, "requires_review": { "type": "boolean", "description": "工单是否包含证据不足或需要人工复核的争议内容", }, }两个值得注意的细节：
choice_descriptions不是可选项，而是质量杠杆。系统提示词明确要求 "Use choice descriptions when provided"（见 parallel_schema.py 中的SYSTEM_PROMPT），prompt 构造时会把每个选项的描述拼进 schema（见 extended_schema.py 的prepare_prompts）。在真实路由场景里，"P0" 这种代号对模型毫无意义，必须用描述把业务语义喂进去，模型才知道 P0 和 P1 的边界在哪里。这本质上是在用 prompt 工程给枚举选项补语义，代价为零但收益显著。
评分类字段（rubric）可以直接当"服务质量打分器"用。把整数级别建模为枚举字符串并传入score_fields，推理结果会返回概率加权后的期望分数（expected_score），见 inference.py 的decision_result：
if row.get("kind") == "score": result["prediction"] = int(choices[index]) result["expected_score"] = sum(int(v) * p for v, p in zip(choices, probs.tolist()))对工单系统来说，这个能力可以用来给每条工单打"处理难度分"或"情绪升级风险分"，作为路由的额外信号。
底层：候选答案是一张 255 个 token 的码本
schema 被渲染成 prompt 后，每个选项被映射成一个单 token 编码。仓库的 schema_config.json 和 serving_config.json 里固化了一份 255 个候选编码的码本：从A到Z，再到AA、AB……直到JT，全部是大写单 token（candidate_encoding: "uppercase_single_token_v1"）。prepare_prompts会在真实回答边界上逐一验证每个编码是否恰好是一个普通 token（见 extended_schema.py 的candidate_suffix），保证打分时 gather 到的 token id 与选项严格一一对应。这也是为什么 Nimble 的输出是结构化的——根本没有生成 JSON 这个环节，也就没有解析失败的可能。
一个容易被忽略的事实：训练数据长什么样
路由工程化之前，值得看一眼模型是被什么数据训出来的。schema_config.json 的data_audit记录了最新一版 checkpoint（v3）的训练构成：12,026 行训练数据、8,468 个 group、5,370 个 family，其中choice（枚举选择）8,080 行、noul（布尔判断）2,412 行、score（评分）1,534 行。官方方法论（contrastive data curation）的核心是构造"只改一个事实、答案翻转"的对照样本对——例如"仅 Mira 有权批准退款，授权记录签名人是 Mira → true"，把签名人换成 Noah → false。这套数据设计直接服务于决策场景：让模型学会"哪个证据变化会导致哪个决策翻转"，而不是背诵语料。对做路由的人来说，这意味着你自己的工单标注数据同样应该按这种"对照样本"思路构造，而不是简单堆一堆正例。
三、线上化：置信度阈值与错误率监控怎么定
拿到概率只是第一步，把它用对才是线上化的关键。Nimble 的每个字段都会返回完整概率分布：
# result["fields"]["category"]["probabilities"] # {"account": 0.91, "billing": 0.05, "technical": 0.03, "after_sales": 0.01}于是最自然的做法是设一个阈值，低于阈值转人工、高于阈值自动路由：
def route(ticket_result): probs = ticket_result["fields"]["category"]["probabilities"] best = ticket_result["output"]["category"] if probs[best] < 0.85: return "HUMAN_REVIEW" # 低置信度兜底 return best但这里有一个必须在灰度前就理解透彻的坑：概率不是正确率。
先校准，再谈阈值
概率只保证在所有选项上求和为 1，不保证"模型说有 90% 把握，就真的 90% 对"。官方在原始版本的校准实验里记录过一个非常典型的案例：温度 T=1 时，模型给出答案的平均概率是 0.89，但这些答案的实际正确率只有 73%——期望校准误差（ECE）高达 0.128。他们通过拟合温度 T=2.179 把 ECE 降到 0.066、log loss 从 0.692 降到 0.555，Brier score 从 0.348 降到 0.295（温度拟合方法为softmax(candidate_logits / temperature)，一次完成）。
而当前仓库里这份最新 checkpoint（v3）的默认温度是T=1.0 且未做独立温度拟合——这一点被写进了 temperature_config.json（"temperature": 1.0, "temperature_fitted": false）和 provenance.json，README 也明确警告："do not reuse the older model's 2.179 calibration"。翻译成工程动作就是：
- 不要把旧版本的 2.179 温度拿来直接用；当前版本的概率分布与旧版不是同一套校准体系；
- 阈值必须在自己数据上重测。官方文档反复强调：0.9 的概率不代表在你的数据分布上 90% 正确，任何概率阈值在依赖之前都要用自己的验证集检验；
- 线上概率在温度变化后不可直接横向比较。如果你用阈值判断转人工，升级 checkpoint 或调整温度后，阈值很可能要跟着重新标定。
好在验证手段是现成的：decision_result在带 gold label 时会直接计算correct、nll（负对数似然）和brier（Brier score）（见 inference.py），配合留出集就能量化校准质量，不必另写评估框架。
监控看什么：留出集指标 + 线上指标
官方对 324 个留出样例的评估除了准确率，还给出了一组校准指标：ECE、log loss、Brier score。这套指标体系应该原样搬进你的工单路由监控：
- 留出集 / 灰度集：关注 ECE 与 Brier，它们直接度量"概率与真实正确率之间的差距"，比单纯看准确率更能预警阈值失效；
- 线上：按天统计低置信度占比、转人工率、路由后的工单解决时长/二次转派率。如果某一天低置信度工单占比突然升高，往往意味着出现了训练分布外的新工单形态（新品类、新话术），此时不是调阈值，而是补数据。
兜底选项永远要留
官方对概率的一个硬性提醒是：如果存在"所有选项都不合适"的可能，就加一个表示"无匹配"的选项，并把它当成普通枚举值。在工单路由里这尤其重要——新出现的业务类别如果不在 choices 里，模型被迫在四个旧类别里挑一个，概率再高也是错的。加一个OTHER（或UNCLASSIFIED）选项，等于给系统留了一条显式的失败通道，低置信度 + 无匹配双保险都落到人工队列。
一个架构层面的提醒
Nimble 的每个字段是独立打分的——官方明确说 "one field cannot see the answer to another field"（README.md）。这意味着 schema 里字段之间的一致性需要业务层自己保证：模型可能给某张工单判priority=P0但category=TECHNICAL且requires_review=false，这在语义上也许矛盾，但模型并不知情。所以线上实现要在 schema 之外加一层规则校验，把"字段间一致性"作为监控指标之一，而不是默认模型会自己协调。
小结
把 Bespoke-Nimble-9B 用到工单路由，本质是完成一次思维切换：从"让模型写答案"变成"让模型做选择"。有界选项 + 高频调用 + 结构化输出，恰好让这种切换获得两个直接回报——推理不再随输出长度膨胀，成本随本地化归零。仓库源码已经把 serving 原理（单 token 打分）、契约约束（扁平 schema、255 选项码本）、校准事实（T=1.0 未拟合）全部摊开在明面上，剩下的事情很朴素：schema 认真写描述、数据按对照样本构造、阈值在自己数据上重测、兜底选项和一致性校验始终留着。第一课到此为止，余下的就是把你自己的工单历史数据喂进去，让模型和阈值在你的分布上重新校准。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
