小模型在这两年的热度回升不是偶然。大模型 API 的成本、延迟和数据合规压力让很多团队重新把目光投向能在本地跑、能私有化部署、能针对单一业务场景精调的小型语言模型Small Language ModelsSLM。但有一个问题被严重低估小模型不只是能力弱一点的大模型它在不确定性表达上有本质短板。说得更直接一点大模型不懂装懂后果可能只是用户体验差小模型不懂装懂在生产系统里可能直接造成业务事故。这篇论文的核心就是围绕小模型如何表达不确定性展开的。标题直译过来是小型语言模型中语言化不确定性的可证明极限与认证延迟。只看标题可能觉得这是纯理论工作但它真正触及的是每一个想把小模型部署到生产环境的团队都会遇到的现实问题模型不确定时应该怎么办是让它说我不知道还是让系统自动把问题交给更强的模型这篇文章我想把这个论文问题讲透并且给出一个可以落地的工程思路。1. 小模型落地时最容易被忽视的短板过去两年很多团队在做小模型选型时主要盯着两个指标准确率和参数量。准确率决定能不能用参数量决定推理成本。在这个二元框架下模型只分两种够用和不够用。但真实的生产系统远比 benchmark 复杂。一个面向客服、法律咨询、医疗导诊、金融问答的系统模型每天会面对大量训练分布之外的输入。这时候最可怕的不是模型答错而是模型完全不知道自己在答错。大模型在这个问题上已经有了一些缓解手段。比如通过大规模指令微调模型可以学会输出我不确定、需要进一步核实这类话术。但小模型参数有限训练数据有限这种能力极不稳定。更麻烦的是小模型经常出现一种局部自信的状态对 A 问题能正确表达不确定对结构相似的 B 问题却给出一个流畅但完全错误的答案。论文标题里的 Verbalized Uncertainty指的就是模型用自然语言直接表达自身置信度的能力。比如模型说我对这个问题没有把握就是一种语言化的不确定性表达。但论文的第二个关键词 Provable Limits可证明极限说明了一个更扎心的结论小模型在这件事情上存在天花板不是靠调 prompt 或加微调数据就能绕过去的。换句话说你不能把拒绝回答的安全责任全部押在模型自己身上。2. 语言化不确定性概念、动机与真正的坑2.1 什么叫语言化不确定性在传统机器学习里模型表达不确定性靠的是概率。分类问题看 softmax 输出的置信度回归问题看方差序列生成问题看解码时的熵。这些方法统称为概率不确定性。语言化不确定性则完全不同。它不是通过数值概率表达而是通过模型生成的 token 序列直接表达。例如我不确定这个问题的答案。根据现有资料这个结论可能不成立。建议咨询专业人士后再做决定。这类输出就是模型在用语言表达不确定性。2.2 为什么小模型更需要研究这个一句话因为没有别的可靠信号可用。在真实部署中拿小模型的 softmax 概率做置信度会遇到几个问题第一模型经过量化、剪枝或蒸馏后概率分布已经失真softmax 分数和真实正确率之间往往没有稳定的映射关系。第二生成式模型的解码概率并不代表知识正确性。一个模型可能对所有候选答案都有低置信度但其中一个答案恰好是对的此时低熵并不能帮助判断。第三很多小模型以 API 或封装服务的形式暴露调用方根本拿不到内部 logits只能拿到纯文本输出。在这种情况下语言化不确定性就成了唯一可用的信号。模型若能在文本中说我不确定下游系统就能根据这句话决定是否触发人工处理或模型升级。2.3 表面可行实则脆弱不少团队的做法是在训练数据里加一批不确定表达样本让模型学习在不知道答案时输出固定话术。这行不行能跑通 demo但很难达到生产级效果。原因有两层。第一层语言化不确定性是模型自己说出来的本质是一种自指判断。小模型没有足够能力建模我自己的知识边界这是参数规模、训练数据和优化目标共同决定的。第二层模型学到的往往是表面的语言模式而不是真实的不确定性。举个例子你训练模型看了很多我不确定正确拒绝的样本它会倾向于过度拒绝如果你训练样本里拒绝样本太少它又恢复成不懂装懂。很难找到一个稳定的平衡点。论文标题里的 Provable Limits正是从这个角度切入的——它试图从理论上证明语言化不确定性与真实校准之间存在一个无法通过训练无限缩小的间隙。3. 可证明极限为什么教会模型说不知道有天花板3.1 极限是个数学问题不是工程问题论文标题里的可证明三个字很关键。它不是在说目前效果不好可能以后会变好而是说即便在理想条件下也存在结构性约束。从理论角度看语言化不确定性本质上要求模型完成一个双重任务既要生成正确答案又要同时监控自己生成正确答案的能力边界。对小模型来说参数容量有限训练信号有限两个任务必然竞争有限的模型容量。无论怎么优化权重模型的自我认知都不可能完全等同于其真实能力边界。这有点像让一个实习生同时做业务和做自我评估。业务做得好不好还能通过结果检验自我评估准不准则需要更高的元认知能力。实习生的经验边界决定了他对自己判断准确性的评估上限。小模型也是同理。3.2 极限不是做不到而是不能全信这里要特别澄清一个容易误解的点可证明极限并不等于语言化不确定性完全没有用。它想说的是你不可能依赖语言化不确定性作为唯一的安全保障并期望它在所有情况下都严格可靠。更准确的理解是语言化不确定性是一个有用的信号但不是一个完整的决策机制。它解决的是模型是否能主动表达不确定的问题而不是系统能否处理模型不确定的问题。3.3 对工程实践的直接启示这意味着什么意味着在设计小模型应用时要把模型自我报告和系统级决策分开。模型说我不知道是一个信号但不是最终决策。最终决策应该由一个可验证、可回滚、可审计的机制来完成。这就是论文标题中第三个关键词 Certified Deferral认证延迟出现的原因。4. Certified Deferral从自我报告到可验证交接4.1 什么是延迟决策延迟决策Deferral这个概念在传统机器学习里就有。当分类器对自己的预测置信度不足时可以选择把样本交给人类专家而不是强行给出错误分类。在论文语境下延迟的对象不一定是人类专家也可以是能力更强的大模型。延迟决策解决的本质问题是模型不确定时如何不阻塞业务同时保证准确性。4.2 认证二字的分量Certified 这个词和 Provable Limits 一样带有理论色彩。它的意思是延迟策略不是拍脑袋定的而是可以用形式化方法验证的。普通的拒绝机制是这样的模型觉得不自信就抛给外部系统。这套流程没问题但有个隐患——你怎么知道模型觉得不自信的判断是可靠的呢这正是论文第一部分说的极限问题。认证延迟的思路则不同。它要求延迟条件本身是可验证的当模型满足某个条件时可以证明延迟后的系统性能不差于不延迟的基线。也就是说延迟不是一种补救措施而是一种被形式化验证过的策略保证。4.3 与传统拒绝机制的三点区别维度传统拒绝机制认证延迟机制触发依据模型自我报告或阈值设定可验证的延迟条件与形式化保证安全边界依赖模型诚实度存在系统性风险理论上不依赖模型诚实度依赖策略验证工程落地改阈值就能上线但风险不可控需要先验证条件但上线后更可预期这不是说每个项目都要做形式化验证。对大部分工程团队来说真正重要的是理解认证延迟的设计哲学不确定性信号只是触发条件系统的安全性要靠机制保证而不是靠模型自觉。5. 从论文到工程如何在真实系统中落地认证延迟论文讨论的是理论极限和认证条件但落到工程项目里我们完全可以把这套思想翻译成一套可实施的系统方案。我建议的落地路径分三步走。5.1 第一步为小模型增加不确定性信号输出如果模型支持定制输出可以要求模型在回答末尾附加一个不确定性标记同时从文本中解析语言化不确定性。这里提供一个轻量级的文本解析器# 文件路径uncertainty_parser.py import re from typing import Dict, List UNCERTAINTY_PATTERNS: Dict[str, List[str]] { high: [我不确定, 无法确认, 没有把握, 不太清楚, 不确定], medium: [可能, 也许, 大概, 不一定, 无法完全确定], flag: [需要人工处理, 建议咨询专家, 请进一步核实, 需要查证], } def parse_verbalized_uncertainty(text: str) - float: 从模型输出文本中解析语言化不确定性分数。 返回值范围0.0非常确定到 1.0非常不确定。 score 0.0 for kw in UNCERTAINTY_PATTERNS[flag]: if kw in text: score max(score, 1.0) for kw in UNCERTAINTY_PATTERNS[high]: if kw in text: score max(score, 0.8) for kw in UNCERTAINTY_PATTERNS[medium]: if kw in text: score max(score, 0.4) return score真实项目中这个解析器可以替换成一个训练过的轻量分类模型效果更好。但核心逻辑是一样的不依赖单一关键词而是综合多个表达信号。5.2 第二步设计可配置的延迟策略延迟策略要用配置驱动方便不同业务线调整。用一个 YAML 文件集中管理# 文件路径deferral_config.yaml deferral: enabled: true # 语言化不确定性触发阈值 verbalized_threshold: 0.6 # 对应答成功率的要求 min_acceptance_rate: 0.85 # 延迟后的落点可以是更强的大模型也可以是人工审核平台 fallback: type: llm_agent # 可选llm_agent / human_review endpoint: http://127.0.0.1:9001/v1/chat timeout_seconds: 8 max_tokens: 1024 # 审计开关 audit: save_deferral_events: true save_raw_responses: true log_level: info5.3 第三步实现延迟决策主逻辑延迟决策的核心不是简单比较阈值而是形成一个有约束的决策策略。下面是一个最小示例# 文件路径agent_deferral.py import yaml from dataclasses import dataclass from uncertainty_parser import parse_verbalized_uncertainty dataclass class SLMResponse: text: str uncertainty_score: float deferred: bool False fallback_text: str def load_config(path: str deferral_config.yaml) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def decide_with_deferral( query: str, slm_predict_fn, llm_predict_fn, config: dict, ) - SLMResponse: 小模型先回答系统判断是否需要延迟必要时交给更强模型。 # 1. 小模型生成回答 raw_response slm_predict_fn(query) # 2. 解析语言化不确定性 uncertainty_score parse_verbalized_uncertainty(raw_response) # 3. 判断是否触发延迟 threshold config[deferral][verbalized_threshold] if uncertainty_score threshold: # 4. 调用更强模型 fallback_text llm_predict_fn(query) return SLMResponse( textraw_response, uncertainty_scoreuncertainty_score, deferredTrue, fallback_textfallback_text, ) return SLMResponse(textraw_response, uncertainty_scoreuncertainty_score) if __name__ __main__: cfg load_config() # 这里用模拟函数演示实际项目替换成真实模型调用。 def fake_slm(q: str) - str: return 这个问题我不太确定可能需要人工确认。 def fake_llm(q: str) - str: return 根据常见情况建议优先检查配置文件的权限字段。 result decide_with_deferral(如何提升服务安全性, fake_slm, fake_llm, cfg) print(原始回答, result.text) print(不确定性分数, result.uncertainty_score) print(是否延迟, result.deferred) print(延迟后回答, result.fallback_text)这段代码已经能说明认证延迟的完整流程小模型先答系统解析不确定性信号达到阈值就延迟到更强的模型。整个链路都是可配置、可审计的。6. 运行验证如何衡量延迟机制是否有价值有人可能会问我加了延迟机制怎么知道它真的有用这就要回到工程指标。6.1 核心评估指标建议从四个维度评估端到端准确率加了延迟机制后整体回答准确率是否提升延迟率多少比例的请求被转交给更强模型平均延迟延迟机制引入后平均响应时间增加多少成本增幅大模型调用带来的额外成本是否在可接受范围内这四个指标必须一起看。只看准确率你不知道成本失控只看延迟率你不知道准确率有没有实质提升。6.2 一个快速评估脚本# 文件路径evaluate_deferral.py from typing import Callable, List, Tuple def evaluate_policy( queries: List[str], labels: List[str], policy_fn: Callable[[str], Tuple[str, bool]], ) - None: total len(queries) deferred 0 correct 0 for q, label in zip(queries, labels): answer, is_deferred policy_fn(q) if is_deferred: deferred 1 if answer.strip() label.strip(): correct 1 print(f样本总数{total}) print(f准确率{correct / total:.2%}) print(f延迟率{deferred / total:.2%}) print(f延迟请求中准确率贡献需要对比无延迟基线计算)运行方式python evaluate_deferral.py6.3 判断成功的标准一个健康的延迟机制应该满足延迟率不高但准确率提升明显延迟决策的事件能完整记录和回放延迟条件可以进行灰度调整不会引发雪崩式调用如果出现延迟率 60%准确率只提升了 2 个百分点的情况说明延迟阈值设置不合理或者语言化不确定性信号本身区分度不够。这时候应该回到数据层检查模型是否真的学会了表达不确定性。7. 常见误区与工程排错问题现象可能原因排查方式解决方案模型从来不触发延迟语言化不确定性阈值设置过高或模型输出中缺乏不确定性表达随机抽样 200 条模型输出人工检查调低阈值或增加模型不确定性表达训练样本延迟率过高成本失控阈值过低模型过度拒绝查看延迟事件日志统计延迟率趋势逐步上调阈值先小流量灰度验证延迟后准确率反而下降大模型对业务上下文不了解或提示词未携带必要信息检查传递给大模型的上下文完整度把业务背景、用户原问题、小模型回答一起传给大模型不确定性分数总是很低模型被训练成无条件自信输出中缺少不确定表达查看 20 条错误样本观察模型是否仍在自信回答用包含不确定性表达的新数据进行指令微调频控或超时导致服务不稳定延迟机制引入外部调用依赖增加检查上游接口 P99 延迟和超时配置增加熔断和超时兜底必要时降级为小模型直答这里特别提醒不要把延迟机制当成万能保险。延迟机制的可靠性取决于小模型输出的不确定性信号质量。如果模型本身没有学会表达不确定你再好的延迟策略也拿不到触发信号。8. 最佳实践小模型可靠部署的几条建议8.1 把不确定性当作一等公民看待做小模型项目时不要只关注准确率指标。建议在评测集里专门增加一组分布外问题测试集检查模型在面对知识范围之外的问题时是会诚实表达不确定还是强行编造答案。8.2 不要用 prompt 解决不确定性问题如果你想不清楚就说我不确定——这种 prompt 在小模型上基本无效。小模型不是不听话而是没有足够能力在生成的同时完成自我监控。更好的做法是在训练和微调阶段注入不确定性表达并在推理阶段用系统机制兜底。8.3 延迟机制必须有审计日志任何生产环境的小模型服务都建议记录三类日志原始模型输出不确定性解析分数是否触发延迟以及延迟后的最终输出有了审计日志你才能复盘每一次安全事件也才能持续优化延迟阈值。没有日志的延迟机制等于没有安全机制。8.4 小流量灰度逐步调整阈值不要上线第一天就追求最优配置。建议从高阈值起步比如 0.8观察一两周。如果误答率高但延迟率极低再逐步下调。每次调整都需要重新评估四个核心指标。8.5 注意成本边界和降级方案延迟机制引入了对大模型的依赖。一旦大模型服务不可用你必须有一个明确的降级策略是直接返回小模型答案还是返回提示信息给用户。这个降级方案要提前设计好否则故障时你会非常被动。9. 这篇论文留给我们的三个判断回头再看论文标题三个关键词实际上回答了一个系统性问题。第一语言化不确定性Verbalized Uncertainty告诉我们小模型的自我报告是一个可用但不可全信的信号要把它当作触发条件而不是决策依据。第二可证明极限Provable Limits提醒我们不要指望靠增加训练数据或调 prompt 就让小模型变成完美的不确定性表达者。这种追求在理论上有边界在工程上是低效投入。第三认证延迟Certified Deferral给出了出路模型不确定时把决策交给可验证的外部机制。对大多数团队而言这意味着在小模型服务外面包一层调度器让它在模型不确定时无缝切换到更强模型或人工审核。小模型的落地拼的从来不只是模型能力更是系统工程能力。谁能把不确定性管好谁才能真正把 SLM 安全地用起来。如果你正在做小模型部署我的建议很简单不要只盯着准确率,先把模型不知道怎么办这个问题设计好。这是这篇论文最值得带到生产环境的结论。 小模型不确定性表达与认证延迟：理论极限到工程落地
小模型在这两年的热度回升不是偶然。大模型 API 的成本、延迟和数据合规压力让很多团队重新把目光投向能在本地跑、能私有化部署、能针对单一业务场景精调的小型语言模型Small Language ModelsSLM。但有一个问题被严重低估小模型不只是能力弱一点的大模型它在不确定性表达上有本质短板。说得更直接一点大模型不懂装懂后果可能只是用户体验差小模型不懂装懂在生产系统里可能直接造成业务事故。这篇论文的核心就是围绕小模型如何表达不确定性展开的。标题直译过来是小型语言模型中语言化不确定性的可证明极限与认证延迟。只看标题可能觉得这是纯理论工作但它真正触及的是每一个想把小模型部署到生产环境的团队都会遇到的现实问题模型不确定时应该怎么办是让它说我不知道还是让系统自动把问题交给更强的模型这篇文章我想把这个论文问题讲透并且给出一个可以落地的工程思路。1. 小模型落地时最容易被忽视的短板过去两年很多团队在做小模型选型时主要盯着两个指标准确率和参数量。准确率决定能不能用参数量决定推理成本。在这个二元框架下模型只分两种够用和不够用。但真实的生产系统远比 benchmark 复杂。一个面向客服、法律咨询、医疗导诊、金融问答的系统模型每天会面对大量训练分布之外的输入。这时候最可怕的不是模型答错而是模型完全不知道自己在答错。大模型在这个问题上已经有了一些缓解手段。比如通过大规模指令微调模型可以学会输出我不确定、需要进一步核实这类话术。但小模型参数有限训练数据有限这种能力极不稳定。更麻烦的是小模型经常出现一种局部自信的状态对 A 问题能正确表达不确定对结构相似的 B 问题却给出一个流畅但完全错误的答案。论文标题里的 Verbalized Uncertainty指的就是模型用自然语言直接表达自身置信度的能力。比如模型说我对这个问题没有把握就是一种语言化的不确定性表达。但论文的第二个关键词 Provable Limits可证明极限说明了一个更扎心的结论小模型在这件事情上存在天花板不是靠调 prompt 或加微调数据就能绕过去的。换句话说你不能把拒绝回答的安全责任全部押在模型自己身上。2. 语言化不确定性概念、动机与真正的坑2.1 什么叫语言化不确定性在传统机器学习里模型表达不确定性靠的是概率。分类问题看 softmax 输出的置信度回归问题看方差序列生成问题看解码时的熵。这些方法统称为概率不确定性。语言化不确定性则完全不同。它不是通过数值概率表达而是通过模型生成的 token 序列直接表达。例如我不确定这个问题的答案。根据现有资料这个结论可能不成立。建议咨询专业人士后再做决定。这类输出就是模型在用语言表达不确定性。2.2 为什么小模型更需要研究这个一句话因为没有别的可靠信号可用。在真实部署中拿小模型的 softmax 概率做置信度会遇到几个问题第一模型经过量化、剪枝或蒸馏后概率分布已经失真softmax 分数和真实正确率之间往往没有稳定的映射关系。第二生成式模型的解码概率并不代表知识正确性。一个模型可能对所有候选答案都有低置信度但其中一个答案恰好是对的此时低熵并不能帮助判断。第三很多小模型以 API 或封装服务的形式暴露调用方根本拿不到内部 logits只能拿到纯文本输出。在这种情况下语言化不确定性就成了唯一可用的信号。模型若能在文本中说我不确定下游系统就能根据这句话决定是否触发人工处理或模型升级。2.3 表面可行实则脆弱不少团队的做法是在训练数据里加一批不确定表达样本让模型学习在不知道答案时输出固定话术。这行不行能跑通 demo但很难达到生产级效果。原因有两层。第一层语言化不确定性是模型自己说出来的本质是一种自指判断。小模型没有足够能力建模我自己的知识边界这是参数规模、训练数据和优化目标共同决定的。第二层模型学到的往往是表面的语言模式而不是真实的不确定性。举个例子你训练模型看了很多我不确定正确拒绝的样本它会倾向于过度拒绝如果你训练样本里拒绝样本太少它又恢复成不懂装懂。很难找到一个稳定的平衡点。论文标题里的 Provable Limits正是从这个角度切入的——它试图从理论上证明语言化不确定性与真实校准之间存在一个无法通过训练无限缩小的间隙。3. 可证明极限为什么教会模型说不知道有天花板3.1 极限是个数学问题不是工程问题论文标题里的可证明三个字很关键。它不是在说目前效果不好可能以后会变好而是说即便在理想条件下也存在结构性约束。从理论角度看语言化不确定性本质上要求模型完成一个双重任务既要生成正确答案又要同时监控自己生成正确答案的能力边界。对小模型来说参数容量有限训练信号有限两个任务必然竞争有限的模型容量。无论怎么优化权重模型的自我认知都不可能完全等同于其真实能力边界。这有点像让一个实习生同时做业务和做自我评估。业务做得好不好还能通过结果检验自我评估准不准则需要更高的元认知能力。实习生的经验边界决定了他对自己判断准确性的评估上限。小模型也是同理。3.2 极限不是做不到而是不能全信这里要特别澄清一个容易误解的点可证明极限并不等于语言化不确定性完全没有用。它想说的是你不可能依赖语言化不确定性作为唯一的安全保障并期望它在所有情况下都严格可靠。更准确的理解是语言化不确定性是一个有用的信号但不是一个完整的决策机制。它解决的是模型是否能主动表达不确定的问题而不是系统能否处理模型不确定的问题。3.3 对工程实践的直接启示这意味着什么意味着在设计小模型应用时要把模型自我报告和系统级决策分开。模型说我不知道是一个信号但不是最终决策。最终决策应该由一个可验证、可回滚、可审计的机制来完成。这就是论文标题中第三个关键词 Certified Deferral认证延迟出现的原因。4. Certified Deferral从自我报告到可验证交接4.1 什么是延迟决策延迟决策Deferral这个概念在传统机器学习里就有。当分类器对自己的预测置信度不足时可以选择把样本交给人类专家而不是强行给出错误分类。在论文语境下延迟的对象不一定是人类专家也可以是能力更强的大模型。延迟决策解决的本质问题是模型不确定时如何不阻塞业务同时保证准确性。4.2 认证二字的分量Certified 这个词和 Provable Limits 一样带有理论色彩。它的意思是延迟策略不是拍脑袋定的而是可以用形式化方法验证的。普通的拒绝机制是这样的模型觉得不自信就抛给外部系统。这套流程没问题但有个隐患——你怎么知道模型觉得不自信的判断是可靠的呢这正是论文第一部分说的极限问题。认证延迟的思路则不同。它要求延迟条件本身是可验证的当模型满足某个条件时可以证明延迟后的系统性能不差于不延迟的基线。也就是说延迟不是一种补救措施而是一种被形式化验证过的策略保证。4.3 与传统拒绝机制的三点区别维度传统拒绝机制认证延迟机制触发依据模型自我报告或阈值设定可验证的延迟条件与形式化保证安全边界依赖模型诚实度存在系统性风险理论上不依赖模型诚实度依赖策略验证工程落地改阈值就能上线但风险不可控需要先验证条件但上线后更可预期这不是说每个项目都要做形式化验证。对大部分工程团队来说真正重要的是理解认证延迟的设计哲学不确定性信号只是触发条件系统的安全性要靠机制保证而不是靠模型自觉。5. 从论文到工程如何在真实系统中落地认证延迟论文讨论的是理论极限和认证条件但落到工程项目里我们完全可以把这套思想翻译成一套可实施的系统方案。我建议的落地路径分三步走。5.1 第一步为小模型增加不确定性信号输出如果模型支持定制输出可以要求模型在回答末尾附加一个不确定性标记同时从文本中解析语言化不确定性。这里提供一个轻量级的文本解析器# 文件路径uncertainty_parser.py import re from typing import Dict, List UNCERTAINTY_PATTERNS: Dict[str, List[str]] { high: [我不确定, 无法确认, 没有把握, 不太清楚, 不确定], medium: [可能, 也许, 大概, 不一定, 无法完全确定], flag: [需要人工处理, 建议咨询专家, 请进一步核实, 需要查证], } def parse_verbalized_uncertainty(text: str) - float: 从模型输出文本中解析语言化不确定性分数。 返回值范围0.0非常确定到 1.0非常不确定。 score 0.0 for kw in UNCERTAINTY_PATTERNS[flag]: if kw in text: score max(score, 1.0) for kw in UNCERTAINTY_PATTERNS[high]: if kw in text: score max(score, 0.8) for kw in UNCERTAINTY_PATTERNS[medium]: if kw in text: score max(score, 0.4) return score真实项目中这个解析器可以替换成一个训练过的轻量分类模型效果更好。但核心逻辑是一样的不依赖单一关键词而是综合多个表达信号。5.2 第二步设计可配置的延迟策略延迟策略要用配置驱动方便不同业务线调整。用一个 YAML 文件集中管理# 文件路径deferral_config.yaml deferral: enabled: true # 语言化不确定性触发阈值 verbalized_threshold: 0.6 # 对应答成功率的要求 min_acceptance_rate: 0.85 # 延迟后的落点可以是更强的大模型也可以是人工审核平台 fallback: type: llm_agent # 可选llm_agent / human_review endpoint: http://127.0.0.1:9001/v1/chat timeout_seconds: 8 max_tokens: 1024 # 审计开关 audit: save_deferral_events: true save_raw_responses: true log_level: info5.3 第三步实现延迟决策主逻辑延迟决策的核心不是简单比较阈值而是形成一个有约束的决策策略。下面是一个最小示例# 文件路径agent_deferral.py import yaml from dataclasses import dataclass from uncertainty_parser import parse_verbalized_uncertainty dataclass class SLMResponse: text: str uncertainty_score: float deferred: bool False fallback_text: str def load_config(path: str deferral_config.yaml) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def decide_with_deferral( query: str, slm_predict_fn, llm_predict_fn, config: dict, ) - SLMResponse: 小模型先回答系统判断是否需要延迟必要时交给更强模型。 # 1. 小模型生成回答 raw_response slm_predict_fn(query) # 2. 解析语言化不确定性 uncertainty_score parse_verbalized_uncertainty(raw_response) # 3. 判断是否触发延迟 threshold config[deferral][verbalized_threshold] if uncertainty_score threshold: # 4. 调用更强模型 fallback_text llm_predict_fn(query) return SLMResponse( textraw_response, uncertainty_scoreuncertainty_score, deferredTrue, fallback_textfallback_text, ) return SLMResponse(textraw_response, uncertainty_scoreuncertainty_score) if __name__ __main__: cfg load_config() # 这里用模拟函数演示实际项目替换成真实模型调用。 def fake_slm(q: str) - str: return 这个问题我不太确定可能需要人工确认。 def fake_llm(q: str) - str: return 根据常见情况建议优先检查配置文件的权限字段。 result decide_with_deferral(如何提升服务安全性, fake_slm, fake_llm, cfg) print(原始回答, result.text) print(不确定性分数, result.uncertainty_score) print(是否延迟, result.deferred) print(延迟后回答, result.fallback_text)这段代码已经能说明认证延迟的完整流程小模型先答系统解析不确定性信号达到阈值就延迟到更强的模型。整个链路都是可配置、可审计的。6. 运行验证如何衡量延迟机制是否有价值有人可能会问我加了延迟机制怎么知道它真的有用这就要回到工程指标。6.1 核心评估指标建议从四个维度评估端到端准确率加了延迟机制后整体回答准确率是否提升延迟率多少比例的请求被转交给更强模型平均延迟延迟机制引入后平均响应时间增加多少成本增幅大模型调用带来的额外成本是否在可接受范围内这四个指标必须一起看。只看准确率你不知道成本失控只看延迟率你不知道准确率有没有实质提升。6.2 一个快速评估脚本# 文件路径evaluate_deferral.py from typing import Callable, List, Tuple def evaluate_policy( queries: List[str], labels: List[str], policy_fn: Callable[[str], Tuple[str, bool]], ) - None: total len(queries) deferred 0 correct 0 for q, label in zip(queries, labels): answer, is_deferred policy_fn(q) if is_deferred: deferred 1 if answer.strip() label.strip(): correct 1 print(f样本总数{total}) print(f准确率{correct / total:.2%}) print(f延迟率{deferred / total:.2%}) print(f延迟请求中准确率贡献需要对比无延迟基线计算)运行方式python evaluate_deferral.py6.3 判断成功的标准一个健康的延迟机制应该满足延迟率不高但准确率提升明显延迟决策的事件能完整记录和回放延迟条件可以进行灰度调整不会引发雪崩式调用如果出现延迟率 60%准确率只提升了 2 个百分点的情况说明延迟阈值设置不合理或者语言化不确定性信号本身区分度不够。这时候应该回到数据层检查模型是否真的学会了表达不确定性。7. 常见误区与工程排错问题现象可能原因排查方式解决方案模型从来不触发延迟语言化不确定性阈值设置过高或模型输出中缺乏不确定性表达随机抽样 200 条模型输出人工检查调低阈值或增加模型不确定性表达训练样本延迟率过高成本失控阈值过低模型过度拒绝查看延迟事件日志统计延迟率趋势逐步上调阈值先小流量灰度验证延迟后准确率反而下降大模型对业务上下文不了解或提示词未携带必要信息检查传递给大模型的上下文完整度把业务背景、用户原问题、小模型回答一起传给大模型不确定性分数总是很低模型被训练成无条件自信输出中缺少不确定表达查看 20 条错误样本观察模型是否仍在自信回答用包含不确定性表达的新数据进行指令微调频控或超时导致服务不稳定延迟机制引入外部调用依赖增加检查上游接口 P99 延迟和超时配置增加熔断和超时兜底必要时降级为小模型直答这里特别提醒不要把延迟机制当成万能保险。延迟机制的可靠性取决于小模型输出的不确定性信号质量。如果模型本身没有学会表达不确定你再好的延迟策略也拿不到触发信号。8. 最佳实践小模型可靠部署的几条建议8.1 把不确定性当作一等公民看待做小模型项目时不要只关注准确率指标。建议在评测集里专门增加一组分布外问题测试集检查模型在面对知识范围之外的问题时是会诚实表达不确定还是强行编造答案。8.2 不要用 prompt 解决不确定性问题如果你想不清楚就说我不确定——这种 prompt 在小模型上基本无效。小模型不是不听话而是没有足够能力在生成的同时完成自我监控。更好的做法是在训练和微调阶段注入不确定性表达并在推理阶段用系统机制兜底。8.3 延迟机制必须有审计日志任何生产环境的小模型服务都建议记录三类日志原始模型输出不确定性解析分数是否触发延迟以及延迟后的最终输出有了审计日志你才能复盘每一次安全事件也才能持续优化延迟阈值。没有日志的延迟机制等于没有安全机制。8.4 小流量灰度逐步调整阈值不要上线第一天就追求最优配置。建议从高阈值起步比如 0.8观察一两周。如果误答率高但延迟率极低再逐步下调。每次调整都需要重新评估四个核心指标。8.5 注意成本边界和降级方案延迟机制引入了对大模型的依赖。一旦大模型服务不可用你必须有一个明确的降级策略是直接返回小模型答案还是返回提示信息给用户。这个降级方案要提前设计好否则故障时你会非常被动。9. 这篇论文留给我们的三个判断回头再看论文标题三个关键词实际上回答了一个系统性问题。第一语言化不确定性Verbalized Uncertainty告诉我们小模型的自我报告是一个可用但不可全信的信号要把它当作触发条件而不是决策依据。第二可证明极限Provable Limits提醒我们不要指望靠增加训练数据或调 prompt 就让小模型变成完美的不确定性表达者。这种追求在理论上有边界在工程上是低效投入。第三认证延迟Certified Deferral给出了出路模型不确定时把决策交给可验证的外部机制。对大多数团队而言这意味着在小模型服务外面包一层调度器让它在模型不确定时无缝切换到更强模型或人工审核。小模型的落地拼的从来不只是模型能力更是系统工程能力。谁能把不确定性管好谁才能真正把 SLM 安全地用起来。如果你正在做小模型部署我的建议很简单不要只盯着准确率,先把模型不知道怎么办这个问题设计好。这是这篇论文最值得带到生产环境的结论。