最近在梳理小模型Small Language Model落地场景时我越来越意识到一个被很多人忽略的问题模型对自己的回答到底有多确定大模型在被追问时经常会在回复里出现“我不确定”“我觉得这个答案可能是……”这类表达这种用自然语言描述自信程度的方式学术界称为 Verbalized Uncertainty语言化不确定性。但同样的现象放到小模型身上情况就复杂得多——小模型既可能答错又可能非常自信。这篇论文《Provable Limits and Certified Deferral for Verbalized Uncertainty in Small Language Models》正是围绕这个矛盾展开的它同时讨论了“可证明的局限”和“有保证的延迟决策”两条路径。本文适合正在做小模型应用落地、LLM Agent 链路、或者研究模型可信度与决策机制的开发者阅读。读完你会理解什么是 Verbalized Uncertainty以及它为什么不是简单的“让模型说一句不确定”。为什么小模型在这条路上会碰到理论层面都无法绕开的限制。Certified Deferral认证式延迟决策如何作为一种兜底手段把模型不擅长的样本交给人类或更强的模型。如何在工程上设计一个可运行的不确定性判断与延迟决策流程。1. 背景与核心概念1.1 为什么关注小模型的不确定性在实际业务中小模型的使用频率远比想象中高。很多团队为了控制推理成本、降低响应延迟会把问答、意图识别、文本分类、信息抽取等任务从 GPT-4 这类大模型迁移到 7B、3B 甚至更小的模型上。迁移之后出现一个很典型的现象模型在常见样本上表现不错但一旦遇到训练分布之外的输入小模型不会像人一样说“这题我没见过”而是会给出一个看起来完全正常、实际错误的答案。这种“错误地自信”在线上系统中很危险。比如一个智能客服模型在无法确定用户意图的时候如果硬给出一个高置信度的答案用户可能因此被误导在金融或医疗辅助场景中这种风险更是不被接受的。所以我们真正需要的不是让模型“永远正确”而是让模型在自己不确定的时候能主动暴露不确定性并触发一个人工兜底或模型升级策略。1.2 Verbalized Uncertainty 是什么Verbalized Uncertainty 从字面上理解就是模型把“自身的不确定性”用自然语言表达出来。举个例子输入东京是哪个国家的首都 模型输出我不太确定但根据常识东京是日本的首都。这里的“我不太确定”就是语言化的不确定性表达。相比传统的 Softmax 概率、logit 置信度等数值型不确定性Verbalized Uncertainty 有几个很明显的优点不需要修改模型结构直接通过 Prompt 让模型说“确定”或“不确定”。人类可以直接读懂模型对自己的判断而不需要去分析概率分布。在多轮对话或 Agent 链路中自然语言的不确定性可以很方便地被下游模块处理。但问题也随之而来模型说“我不确定”真的代表它不确定吗如果训练数据里经常出现“我不确定但答案是……”模型可能只是学会了这种句式而不是真正拥有了自我认知。对这一点论文给出的结论比较严肃——小模型在这件事上存在可证明的界限。1.3 Certified Deferral 是什么面对“模型不确定”的情况最直接的工程方案是延迟决策Deferral也就是让模型这样响应这个问题超出了我的能力范围我将转给人工客服处理。但延迟决策本身也有质量问题。如果模型过度触发延迟所有请求都转人工那还不如不用模型如果触发得太少错误又会漏到用户侧。Certified Deferral 的“Certified”强调不是拍脑袋决定而是通过某种可验证的机制保证当模型决定延迟时系统整体风险是可控的、可证明的。换句话说论文不是在问“模型能不能表达不确定性”而是在问“模型能不能在理论上保证什么时候该表达、表达之后如何兜底”。这两者结合才是一个完整的可信决策系统。1.4 三个概念的边界概念核心问题输出形态侧重点Uncertainty Quantification模型对答案有多确信概率、logit、方差数值化度量Verbalized Uncertainty模型能否用语言描述确信度自然语言“确定/不确定”表达形式Certified Deferral不确定时如何安全兜底转交人工或更强模型决策与保证2. 相关技术脉络与基础2.1 大模型不确定性表达的常见方案关于模型不确定性学术界和工业界已经积累了不少方案主要分成三大类。第一类是基于概率的方法。分类模型输出 Softmax 概率回归模型输出方差无论是 MC Dropout、深度集成还是贝叶斯神经网络本质上都是想获得一个经过校准的不确定性估计值。第二类是基于采样的方法。对同一个 Prompt 做多次采样观察答案的一致性。如果多次采样结果高度一致就认为模型对答案比较确定如果不一致则说明模型处于“摇摆”状态。这个方法在 LLM 上很常用因为不需要改模型结构代价是多次推理带来的计算开销。第三类就是本文讨论的 Verbalized Uncertainty。它让模型直接在生成文本里夹带不确定性描述再通过启发式规则或额外分类器去解析。OpenAI 等团队的很多实际系统里已经能看到这种影子比如 ChatGPT 遇到知识盲区时会说“我无法确认这一点”。在大模型身上这三类方法都取得了不错的效果。原因是参数量足够大之后模型学习到的模式足够丰富有能力在内部表征“这个答案是否常见、是否可靠”。但小模型由于容量限制很难学到类似的自我评估能力。2.2 小模型为什么难做到“自知之明”小模型的参数量从 1B 到 13B 不等虽然听起来不小但在预训练数据覆盖度和指令跟随能力上和大模型有明显差距。要让模型准确表达“我是否知道”本质上是要模型对自己拥有一个“元认知”层面的判断。问题在于语言模型训练的核心目标是预测下一个 token而不是判断自己是否知道下一个 token。模型可以学会“当上下文出现某类模式时我倾向于输出什么”但很难学会“我当前内部状态是否可信”。对于小模型来说这个问题更加严重。一是因为参数量不足难以拟合复杂的校准函数二是因为小模型的训练数据往往更聚焦在某几个下游任务上没见过足够多的“反面样本”模型从来没有机会学习“什么时候应该承认自己不知道”。这些观察并不只是工程经验层面的猜测。论文的“Provable Limits”部分正是从理论角度论证了在某些条件下小模型的 Verbalized Uncertainty 一定会失效。这个结论非常重要它告诉我们不要盲目相信模型说出来的“我很确定”。2.3 ReAct 与不确定性表达的结合和论文相关的另一个热词是 ReAct即 “Synergizing Reasoning and Acting in Language Models”。ReAct 的核心思想是让模型在推理时交替进行“思考Reasoning”和“行动Acting”比如说在回答之前先调用搜索工具、查数据库然后根据工具返回结果再生成答案。ReAct 和 Verbalized Uncertainty 可以天然结合。在 ReAct 链路中模型如果对一个推理步骤没有把握可以在文本里明确写出我对这一步的搜索结果不太确定需要再验证一次。然后触发一个工具调用而不是直接生成最终答案。这种“推理中出现怀疑 → 采取行动 → 再评估”的模式和 Certified Deferral 的思路非常一致。区别在于ReAct 中的行动可能只是查资料而 Deferral 则是把决策权交给人类或更强的模型。3. 论文核心思路拆解3.1 Verbalized Uncertainty 的实现方式在实际操作中让模型表达不确定性有几种常见实现方式第一种是 Prompt 诱导法。在系统提示词里明确要求模型回答时附带置信度描述例如请回答下面的问题。在回答之前先明确写出你的自信程度确定、比较确定、不确定。第二种是选项强制法。让模型在输出中先输出一个置信度标签再进行回答格式要求 第一行CONFIDENCE: high/medium/low 第二行ANSWER: ...第三种是双模型对比法。让两个不同的模型或同一模型的两次采样分别作答如果答案不一致则认为不确定性较高。这种方法虽然也是“数值型”思想但模型输出的仍然是自然语言。论文讨论的“可证明局限”主要针对前面两种依赖模型自我表达的方法。原因在于模型在生成“CONFIDENCE: high”这样的标记时并没有经过严格的概率校准训练。它只是在模仿训练分布中的某种文本模式而不是在输出一个真实反映内部状态的信号。3.2 “可证明局限”到底证明什么这是整篇论文最值得关注的部分。所谓可证明局限不是说“小模型效果不好”而是说在理论上可以构造出场景让小模型的 Verbalized Uncertainty 无法满足期望。一个容易理解的类比是假设你要让一个只见过猫和狗的模型判断“面前这是不是一只老虎”。模型在训练时根本没见过老虎那么无论你怎么诱导它说出“我不确定”它都没有足够的内部证据来判断“自己是否认识老虎”。在这种情况下模型可能输出“我不确定”也可能输出“我确定这是狗”这两种输出都不具备任何真实可信度。论文的论证方式更形式化一些。它通过构建两个在训练数据上等价、但在测试分布上完全不同的模型证明基于有限训练数据的小模型无法区分这两种情况。因此任何声称“模型语言化不确定性可靠”的结论在小模型场景下都需要打一个问号。对工程实践的启示是不要只依赖模型自己说“我不确定”就认为它不可靠也不要在它说“我确定”时完全信任。更稳妥的做法是引入外部校验信号比如多次采样一致性、语义相似度、交叉验证。3.3 Certified Deferral 的决策机制既然小模型的 Verbalized Uncertainty 存在局限那怎么办论文给出的解法是 Certified Deferral。它试图从决策层去弥补表达能力层的不足。Certified Deferral 的基本流程可以拆成四步模型针对输入给出候选回答和不确定性信号。系统根据不确定性信号和阈值判断是该直接输出答案还是触发延迟。如果触发延迟将样本转给人类专家或一个更强的大模型。对延迟决策本身进行监控和审计确保延迟策略达到了预期的安全边界。这里的关键词是“Certified”意思是延迟策略必须可验证。比如系统可以设定一个约束在部署集上模型直接输出的错误比例不得超过 1%。如果模型发现某个样本的低置信度阈值会破坏这个约束就必须触发延迟。这实际上把问题从“模型是否确定”转换成了“系统如何决策”。这种设计非常符合工程直觉。我们不需要模型完美地知道“自己知道什么”只需要系统在面对不确定输入时有可靠的后备路径。3.4 关键设计参数在实现 Certified Deferral 时有四个参数需要重点考虑。参数含义影响置信度阈值低于该值则触发延迟阈值越高延迟率越高系统越保守延迟率上限系统中最多允许多少请求被延迟控制人工成本和响应体验风险预算直接答错允许占多大比例决定安全边界评估集分布用来验证延迟策略的数据分布决定认证结论是否可靠这四个参数互相牵制实际项目中需要结合业务容忍度反复调优。4. 完整案例一个可运行的延迟决策示例下面用一个可运行的概念案例演示如何构建一个带有不确定性判断和延迟决策的完整流程。这里使用模拟模型输出来展示逻辑实际接入模型时只需要替换get_model_response这一个函数。整体代码可以直接复制运行不需要额外安装依赖。4.1 场景设计假设我们要做一个“客服问答小模型”系统输入是用户问题输出是答案。如果模型不确定就转人工。我们的目标是尽量让模型回答问题同时保证低置信度样本不直接外发给用户。为了演示我们定义三种置信度等级等级模型输出标记置信度数值决策HIGHhigh0.9直接输出MEDIUMmedium0.6直接输出但记录日志LOWlow0.2触发延迟转人工4.2 Prompt 设计示例如果使用真实的语言模型Prompt 可以这样设计你是一个智能客服助手。请回答用户问题。 回答格式要求 第一行CONFIDENCE: high/medium/low 第二行ANSWER: 你的答案 如果对问题完全没有把握请将第二行设置为: ANSWER: 需要转人工处理 用户问题{user_question}这里要求模型先输出置信度标记再输出答案。虽然我们前面讨论过这种自我表达存在局限但它仍然是最简单、成本最低的启动方案。4.3 Python 代码实现# -*- coding: utf-8 -*- # 文件路径deferral_demo.py def get_model_response(user_question: str) - dict: 模拟模型返回结果。 实际项目中这里替换为真实的模型调用即可例如 response llm.chat(prompt) 返回建议使用规范化字典方便下游处理 {confidence: high/medium/low, answer: 回答内容} # 这里用关键词规则模拟一个小模型仅用于演示流程 if 退款 in user_question: return {confidence: high, answer: 退款需要联系客服并提供订单号。} elif 发票 in user_question: return {confidence: medium, answer: 发票一般在确认收货后开具。} else: return {confidence: low, answer: 这个问题我不太确定建议转人工。} def parse_confidence(confidence: str) - float: 将模型输出的置信度等级映射为数值。 这个映射可以根据实际业务灵活调整。 mapping { high: 0.9, medium: 0.6, low: 0.2 } return mapping.get(confidence.lower(), 0.0) def decide(confidence_value: float, threshold: float 0.5) - str: 决策函数 - 置信度低于阈值返回 defer表示转人工或转大模型。 - 置信度不低于阈值返回 direct表示直接回复用户。 if confidence_value threshold: return defer return direct def handle_user_question(user_question: str, threshold: float 0.5) - dict: 完整处理流程 1. 获取模型回答 2. 解析置信度 3. 根据阈值决定直接回答还是延迟 response get_model_response(user_question) confidence_value parse_confidence(response[confidence]) decision decide(confidence_value, threshold) result { user_question: user_question, model_confidence: response[confidence], confidence_value: confidence_value, answer: response[answer], decision: decision } return result if __name__ __main__: test_questions [ 请问退款流程是什么, 可以帮我查一下发票吗, 如何用 Python 实现递归神经网络, ] for question in test_questions: result handle_user_question(question) print(问题:, result[user_question]) print(模型置信度:, result[model_confidence], f({result[confidence_value]})) print(模型回答:, result[answer]) print(决策:, 直接回答 if result[decision] direct else 延迟转人工) print(- * 60)4.4 运行结果与解读运行上述代码会得到类似下面的输出问题: 请问退款流程是什么 模型置信度: high (0.9) 模型回答: 退款需要联系客服并提供订单号。 决策: 直接回答 ------------------------------------------------------------ 问题: 可以帮我查一下发票吗 模型置信度: medium (0.6) 模型回答: 发票一般在确认收货后开具。 决策: 直接回答 ------------------------------------------------------------ 问题: 如何用 Python 实现递归神经网络 模型置信度: low (0.2) 模型回答: 这个问题我不太确定建议转人工。 决策: 延迟转人工 ------------------------------------------------------------这个例子虽然简单但它已经把核心流程跑通了模型输出 → 置信度解析 → 阈值判断 → 决策输出。真实项目中get_model_response换成实际模型调用decide函数里可以加入更复杂的规则比如结合延迟率上限做动态阈值调整。4.5 评估思路校准与覆盖率只把流程跑通还不够我们需要评估延迟策略的效果。两个最常用的指标是校准误差Calibration Error模型的置信度是否和真实准确率一致。比如模型说 high 的样本准确率是否真的接近 90%。覆盖率Coverage所有样本中有多少比例由模型直接回答多少比例被延迟。一个最简单的评估方法是按置信度等级分桶统计每个桶内的准确率和平均置信度。下面给出一段示例代码# -*- coding: utf-8 -*- # 文件路径evaluate_calibration.py def evaluate_calibration(samples: list) - dict: samples 是一个列表每个元素是字典 { confidence: high/medium/low, is_correct: True/False } 返回每个置信度桶的样本数、准确率。 buckets {high: [], medium: [], low: []} for item in samples: conf item[confidence].lower() if conf in buckets: buckets[conf].append(item[is_correct]) result {} for conf, labels in buckets.items(): if labels: accuracy sum(labels) / len(labels) else: accuracy None result[conf] { 样本数: len(labels), 准确率: accuracy } return result if __name__ __main__: # 模拟一批评估样本 demo_samples [ {confidence: high, is_correct: True}, {confidence: high, is_correct: True}, {confidence: high, is_correct: False}, {confidence: medium, is_correct: True}, {confidence: medium, is_correct: False}, {confidence: low, is_correct: False}, {confidence: low, is_correct: False}, ] print(evaluate_calibration(demo_samples))运行结果会显示类似{high: {样本数: 3, 准确率: 0.6666666666666666}, medium: {样本数: 2, 准确率: 0.5}, low: {样本数: 2, 准确率: 0.0}}如果发现 high 桶的准确率只有 0.66远低于预期的 0.9说明模型的 Verbalized Uncertainty 校准很差。这时候就需要调整阈值、改进 Prompt或者直接引入采样一致性作为新的不确定性信号。5. 常见问题与排查思路在实际落地中围绕 Verbalized Uncertainty 和 Deferral 的坑非常多。下面整理了几类高频问题。问题现象常见原因解决思路模型对不同问题都说 “high”模型没有真正校准只是学会了输出格式引入采样一致性多次采样比较答案使用指令数据微调模型频繁触发转人工延迟率过高置信度阈值设置太严降低阈值或对延迟样本做二次确认后再决策延迟转人工后人工反馈问题简单模型对简单问题也表现不确定检查 Prompt 是否让模型过度保守增加 few-shot 示例置信度与真实准确率严重不一致训练分布和线上分布偏离大重新构建评估集统计分桶准确率必要时做温度缩放下游系统无法处理“转人工”文本对模型输出缺少后处理用结构化输出替代自由文本建议模型输出 JSON 或固定标记延迟策略上线后效果无法量化缺少决策日志在延迟决策节点记录 confidence、threshold、final_action这里重点说一下采样一致性的做法。既然不能完全相信模型说出来的置信度我们可以让模型对同一个问题回答多次然后判断答案的语义一致性# -*- coding: utf-8 -*- # 文件路径consistency_check.py from collections import Counter def check_consistency(answers: list) - float: 输入多次模型回答的答案列表返回最常见答案的出现比例。 比例越高说明模型对答案越稳定。 if not answers: return 0.0 counter Counter(answers) most_common counter.most_common(1)[0][1] return most_common / len(answers) if __name__ __main__: # 模拟同一个问题采样三次的结果 sample_1 [退款需要联系客服, 退款需要联系客服, 退款需要联系客服] sample_2 [是日本, 不确定, 应该是日本] print(sample_1 一致性比例:, check_consistency(sample_1)) print(sample_2 一致性比例:, check_consistency(sample_2))实际项目中一致性比例可以作为新的置信度特征和模型说出的 Verbalized Confidence 一起输入决策函数。这样即使模型表达不准确系统层面仍然有兜底依据。6. 工程实践与最佳实践6.1 什么任务适合用延迟机制不是所有任务都需要引入 Deferral。建议优先在以下场景中使用决策错误代价较高的场景比如医疗建议、金融答疑、法律咨询。模型经常遇到分布外输入的开放域问答。多轮对话中用户问题语义不稳定难以提前枚举。对于简单分类、规则明确的抽取任务即使模型说“不确定”只要准确率满足业务要求直接输出效率更高。6.2 不确定性信号的可靠性评估无论采用哪种不确定性信号上线前都应该做一次系统评估。推荐流程如下构建一个覆盖线上分布的测试集包含典型样本和困难样本。记录每个样本的模型置信度、采样一致性、最终答案。按置信度分桶计算准确率和覆盖率。调节阈值画出“覆盖率-准确率权衡曲线”。选择满足业务风险预算的阈值组合。这里的关键是测试集分布要尽量接近线上真实分布。如果只拿训练集里的简单样本评估得到的阈值往往过于乐观。6.3 生产环境部署建议在真实系统中建议至少做到以下几点。第一决策日志必须完整。每一次延迟都要记录原始问题、模型回答、置信度、阈值、触发原因、最终处理人。这样后续可以复盘也可以用来持续调优阈值。第二阈值不要写死。可以把阈值做成配置项支持按业务线、按时间段、按问题类型动态调整。比如活动大促期间客服压力大可以适当放宽阈值让模型多承担一些平时则收紧阈值保证安全。第三人工兜底流程要闭环。延迟给人工后人工的处理结果需要回流到系统形成新的标注数据。这些数据既可以用来微调小模型也可以用来优化延迟决策策略。第四警惕过度自信。即便在人工评估中模型的准确率很高也不要完全信任模型文本中的 “high”。建议至少保留一个基于采样一致性或外部规则校验的额外防线。尤其是在小模型上把“模型自己说确定”当作“系统确定”是风险最高的一种设计。7. 总结与后续学习方向这篇文章从一个论文标题出发梳理了 Verbalized Uncertainty、Provable Limits、Certified Deferral 三个核心概念并用一个可运行的 Python 案例演示了“模型输出置信度 → 解析 → 阈值决策 → 延迟兜底”的完整链路。核心收获可以归纳为三点小模型的语言化不确定性表达存在理论和工程双重限制不能作为唯一判断依据。更稳健的做法是把不确定性信号与延迟决策机制结合让系统在风险不可控时主动把样本交给人或更强的模型。延迟策略上线前一定要构建贴近线上分布的评估集并用分桶准确率、覆盖率等指标验证阈值。如果继续深入可以从三个方向展开学习。一是研究如何提高小模型的不确定性校准能力比如指令微调时加入“我不知道”类样本二是阅读 ReAct 类 Agent 框架把不确定性判断嵌入到推理和工具调用链路中三是学习在线评估系统为延迟决策加上实时监控和自动回退机制。建议你动手做一个小实验选一个你自己实际使用的分类或问答模型在 Prompt 里加上置信度输出要求然后用十到二十个困难样本测试它的 Verbalized Uncertainty 是否可信。这个实验成本很低但会让你对“模型说自己知道”这件事有一个更直观的判断。