这次我们来看一个偏研究向、但对实际部署非常有价值的话题Small Language Models小型语言模型中的 Verbalized Uncertainty口头化不确定性以及论文《Provable Limits and Certified Deferral for Verbalized Uncertainty in Small Language Models》提出的“Certified Deferral认证推迟”思路。它解决的问题非常直接小模型在回答问题时经常会“嘴上”说一句“我觉得我有 90% 的把握”但这种口头表达出来的置信度通常是不太可靠的。模型可能嘴上说 90%实际只有 60%。这篇论文的核心贡献是从理论上说明这种不可靠存在边界并给出一种“模型不行就把任务推迟给更强的模型或人工”的可信机制。本文不会只停留在论文解读层面我会把它拆成几个工程上可以落地的技术决策点并给出一套基于小型语言模型的最小验证流程如何让模型输出口头化不确定性、如何评估校准效果、如何用阈值判断是否推迟、如何封装成 API 服务并做批量验证。适合正在做 SLM 落地、RAG Agent、智能客服、知识库问答、内容审核辅助以及任何需要“模型答不出来时能主动放弃”的可靠性系统的同学。如果你只关心推理速度、显存占用、批量任务和接口调用这篇也能帮你把“不确定性机制”接入到现有服务里。1. 核心能力速览先给一张速览表快速判断这篇论文和后续验证流程值不值得继续看。能力项说明项目类型学术论文 / 方法论不是开箱即用工具核心问题小模型口头化不确定性不可靠如何证明并兜底核心方法可证明限制 认证推迟Certified Deferral关键概念Small Language Models、Verbalized Uncertainty、Certified Deferral、校准、选择性预测硬件门槛没有严格特殊要求验证流程可在单张消费级 GPU 或 CPU 上完成显存占用取决于所选小模型尺寸和批次大小需按实际环境测试支持平台论文本身不限平台工程验证可用 Python Transformers 完成启动方式论文无启动器验证流程可用命令行脚本启动是否支持 API论文不是服务但可将验证流程封装为 FastAPI 接口是否支持批量任务可以通过批量评估脚本完成校准和推迟策略验证适合场景SLM 问答、RAG 置信度兜底、客服辅助、知识库问答、模型拒答策略注意因为输入材料中只给了论文标题和相关热词没有提供论文正文、官方代码仓库或作者实验数据所以下文中的复现流程是“一个符合当前研究共识的最小验证框架”不是论文官方代码的复刻。实际使用前需要对照论文原文检查细节。2. 口头化不确定性是什么为什么小模型不可靠2.1 从“口头化”三个字理解问题Verbalized Uncertainty直译是“口头化不确定性”。它指的是模型通过自然语言输出直接表达自己对答案的确定程度。例如“我确定答案是巴黎。”“我觉得北京是正确答案但不太确定。”“这个问题我不太知道。”“正确答案是巴黎置信度 0.87。”这些表达本质上都是模型在“说”它的不确定性。对于大模型这种“口头化”可能有一定参考价值因为大模型接触过大量指令微调和人类反馈数据能够学会在回答中嵌入概率词。但对于小型语言模型情况要复杂得多。2.2 口头置信度不等于真实概率在概率论里一个预测系统如果宣称 80% 置信度那么长期来看它回答正确的频率应当接近 80%。这就叫校准。但语言模型天然不是为输出概率而训练的。它训练目标是最大化下一个 token 的生成概率这是自回归建模目标。模型在解码时最终输出文本中的“0.87”这个 token 序列并不保证和模型内部真实概率分布一致。也就是说模型可能输出“我认为正确率是 90%”但实际正确率只有 60%。模型可能输出“我不确定”但实际答题准确率又很高。不同 prompt 模板对输出的置信度数值影响很大。这和模型的内部隐藏状态概率有关但更核心的问题是口头化不确定性本身就是一段生成文本它可以被“编造”出来也可以被 prompt 引导并不存在天然一致性的保证。2.3 小模型的容量限制让问题更严重大模型容量大训练数据多在指令微调后更容易模仿出合理的置信度表达。小模型参数少、能力弱在指令跟随、自省、数值输出上都存在短板。对比维度大模型小模型指令跟随能力强能按格式输出置信度弱容易输出无关文本自省能力相对可靠容易“胡诌”置信度置信度数值稳定性相对稳定对 prompt 非常敏感校准质量不一定好但通常优于小模型通常偏差明显实际部署成本高需要大显存低CPU 也能跑这不是说小模型完全不能用而是说如果你准备让小模型在线上直接输出“我的置信度是 X”必须先验证 X 和真实正确率之间是否存在可靠关系。2.4 “可证明的限制”意味着什么论文标题里的“Provable Limits”说明作者不是简单做实验发现“小模型口头不确定性不准”而是试图从理论层面证明在某些条件下小模型无法精确表达自己的不确定性或者通过口头化方式表达不确定性存在不可逾越的误差边界。“可证明”这三个字在工程上的价值是不要盲目相信模型自己报出来的置信度。如果理论上就存在误差极限那么单纯让模型“说真话”是无法根本解决问题的。系统设计上必须有一个外部兜底机制这就是 Certified Deferral 出现的背景。3. 认证推迟从“模型自评”到“规则兜底”3.1 什么是推迟“推迟”在机器学习里并不是新概念。传统选择性预测中模型可以选择对某些样本“不回答”而是交给人工处理或者交给另一个更强大的模型处理。这里的核心问题不是“能不能推迟”而是“什么时候推迟”以及“推迟了之后系统性能能不能被保证”。如果模型自己说“我不确定”系统就推迟那么模型要是“过于自信”怎么办如果模型每次都说“我不确定”系统就变成完全不敢回答产品体验也会崩。所以推迟不能完全交给模型自觉而要用外部规则和统计方法来控制。3.2 认证推迟的基本流程一个典型的认证推迟流程包含以下步骤模型生成答案同时输出一个口头化不确定性值 u。系统根据 u 或其它特征计算一个推迟分数 s。设定阈值 tau。如果 s tau正常输出答案。如果 s tau则不输出答案而是转人工或更强模型。这里的“认证”在于我们可以通过验证集在给定的风险约束下找到一个保证性能边界的阈值。比如我们希望系统对外回答的问题错误率不超过 5%。那么我们需要选择 tau使所有通过门槛的问题集合上的整体错误率在统计意义上不超过 5%。这种保证可以用校准后的风险估计、二项式置信区间、保序回归等方法实现。3.3 和直接拒答的区别一般模型“拒答”是模型自己决定不回答典型做法是训练时加入拒绝样本例如“我不知道”。缺点是训练成本高。小模型很难学明白什么时候该拒答。拒绝率不可控。无法给客户提供可解释的风险承诺。认证推迟则把决策从“模型内部”移到“系统外部”用验证集和统计方法控制失败风险。这样即使模型本身不会说“我不知道”系统也能在它置信度不足时强制转人工。3.4 与不确定性的关系口头化不确定性在这里不是被直接信任的最终结论而是作为推迟决策的一个输入信号。哪怕这个信号有偏差只要它包含关于模型正确性的一定信息量我们就能通过阈值和统计校准把它转化为一个可控的推迟策略。这正好契合论文标题里的“Certified Deferral”思想不要求模型自我评估百分之百准确而是设计一个系统让不可靠的自评最终也能被安全地纳入决策。4. 从论文到工程什么时候用得上4.1 适合使用该机制的场景智能客服模型不确定时转人工避免给用户错误承诺。知识库问答低置信度时返回“我帮你转给专业人员”。RAG 问答检索结果和生成答案不一致时不硬答。医疗、金融辅助涉及风险提示时必须有人工复核兜底。边缘设备部署只能跑 1B 以下小模型但又希望保留可靠性控制。这些场景的共同特点是回答错误的代价较高不能接受模型“错了也不自知”。4.2 不适合的场景对延迟敏感、没有人工兜底能力的服务。答案本身就是生成式内容没有明确对错标准的任务例如开放式闲聊、创意写作。模型能力严重低于任务难度几乎所有样本都需要推迟这时候应该先换模型或微调而不是靠推迟兜底。4.3 工程边界认证推迟不是万能药。它不能把一个小模型变成一个小失误率的大模型。它只能帮你识别“哪些回答值得放出去哪些还是转人工更安全”。如果模型本来 80% 的题都不会做那么阈值无论怎么调要么回答准确率极低要么推迟率极高。这时候应该先提升模型能力或者接入更大模型。5. 本地复现与验证环境准备这部分给出一个通用验证环境不绑定论文官方仓库。这里假设你会用 Python 和 Hugging Face Transformers通过加载一个小型语言模型完成“口头不确定性 校准评估 推迟策略”的验证。5.1 环境清单操作系统Windows / Linux / macOS 均可。Python建议 3.10 或以上。包管理工具pip 或 conda。深度学习框架PyTorch。模型库Transformers、datasets。科学计算numpy、scikit-learn、matplotlib。接口演示fastapi、uvicorn。GPU 驱动和 CUDA如果有 N 卡建议装好 CUDA 工具包没有也能纯 CPU 跑只是慢一些。5.2 创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install torch transformers datasets scikit-learn matplotlib fastapi uvicorn scipy如果使用 N 卡且有 CUDA需要按官方说明安装对应版本的 PyTorch。这个命令只是基础模板实际版本号建议到 PyTorch 官网生成。5.3 选择一个小型语言模型这里选择模型不需要太纠结建议选 1B 到 3B 参数范围内的开源模型。例如 Qwen2.5-1.5B、Qwen2.5-3B、Llama-3.2-1B、Phi-3-mini 等。每种指令微调模型对“输出置信度数字”的 prompt 模板要求不同需要你自己测试。建议先用一个非常小的模型跑通流程再换业务实际使用的模型。5.4 准备验证数据集你可以用公开的问答数据集也可以从自己的业务日志里采样一批真实问题。关键要求是每个问题必须有标准答案方便判断模型输出正确与否。如果条件允许准备 500 到 1000 条样本用于校准评估。太少的话置信区间会非常大阈值选择也不可信。6. 最小实验提取口头化不确定性并评估校准下面是一套最小实验流程目的是验证“模型口头报出的置信度”和“真实准确率”之间是否一致。6.1 实验设计输入一个问题。模型输出一个答案和一个置信度数值。后处理判断答案是否正确。聚合统计不同置信度区间下的实际正确率绘制校准曲线。6.2 让模型输出口头化置信度一个简单做法是在 prompt 中要求模型同时输出答案和 0 到 1 之间的置信度。代码示例如下from transformers import pipeline generator pipeline( text-generation, modelQwen/Qwen2.5-1.5B-Instruct, device_mapauto, ) def ask_with_confidence(question: str, answer: str): prompt ( fQuestion: {question}\n fProposed answer: {answer}\n Is this proposed answer correct? First output Yes or No, then output the probability (0-1) that the answer is correct. Format: Yes|0.87 or No|0.35\n ) outputs generator( prompt, max_new_tokens16, do_sampleFalse, ) return outputs[0][generated_text]注意不同模型对 prompt 的格式要求不同。实际使用时要针对模型指令模板做调整。6.3 解析置信度数值模型输出文本后需要解析出数字。这一步要健壮一点因为小模型很可能输出“Yes 0.87”或“0.87”等不同格式。import re def parse_confidence(text: str) - float | None: # 查找形如 0.5、0.80、1.0、0 的浮点数 matches re.findall(r\b([01](?:\.\d{1,3})?|0\.\d)\b, text) if not matches: return None # 取最后一个出现的数字通常是置信度 value float(matches[-1]) if 0.0 value 1.0: return value return None解析失败时可以直接将该样本标记为“无法给出置信度”这在后续推迟策略里可以当作低置信度处理。6.4 评估校准质量这里使用 ECEExpected Calibration Error来量化校准误差。ECE 计算方式是根据置信度分桶比较每个桶内的平均置信度和实际正确率然后加权求和。import numpy as np def compute_ece(confidences, correctness, num_bins10): bins np.linspace(0, 1, num_bins 1) ece 0.0 for i in range(num_bins): low, high bins[i], bins[i 1] # 选取该桶内的样本 mask (confidences low) (confidences high) if mask.sum() 0: continue avg_conf confidences[mask].mean() avg_acc correctness[mask].mean() weight mask.sum() / len(confidences) ece weight * abs(avg_conf - avg_acc) return ece这个指标越大说明模型口头置信度和真实准确率差距越大。你在项目里可以设定一个阈值例如 ECE 超过 0.2就认为口头化不确定性不可用必须上推迟机制。6.5 预期结果与判断标准如果模型校准良好那么置信度 0.8 的样本整体正确率应该接近 0.8。如果模型校准很差可能出现以下情况置信度普遍偏高0.9 的样本实际正确率只有 0.6。置信度集中在 0.5 附近没有区分度。同一模型在不同 prompt 下输出差异极大。如果出现这些问题说明“模型自评”不能单独作为风险控制手段应该考虑论文提到的 Certified Deferral 思路。7. 实现认证推迟阈值选择与风险保证在真实系统中我们需要一个可解释的规则来决定“模型是否可以对外回答”。下面给出一个实现示例。7.1 推迟策略设计假设我们已经收集了一批测试样本每条样本有confidence模型口头输出的置信度。correct模型答案是否正确1 或 0。我们选择阈值 tau只有当 confidence tau 时模型才对外输出答案。否则转人工或强模型。这样对外输出样本集合的风险就是对外回答的错误样本数 / 对外回答的总样本数我们希望控制这个错误率不超过某个业务风险值例如 5%。7.2 使用二项式置信上界做认证为了保证有限的验证集规模下阈值依然可靠可以使用二项分布置信上界来估计“真实错误率”的上界。from scipy.stats import beta def risk_upper_bound(n_defer_errors, n_deferred, alpha0.1): 计算 1 - alpha 置信水平下错误率的置信上界。 使用 Clopper-Pearson 方法也就是 Beta 分布分位数。 if n_deferred 0: return 1.0 # Beta 分布分位数对应二项分布置信上界 return beta.ppf(1 - alpha, n_defer_errors 1, n_deferred - n_defer_errors 1) def find_threshold(confidences, correctness, max_risk0.05, alpha0.1): 遍历阈值找到满足认证风险要求的最大推迟阈值。 返回合格的阈值列表。 candidates np.sort(np.unique(confidences)) qualified [] for tau in candidates: mask confidences tau if mask.sum() 0: continue error_rate 1 - correctness[mask].mean() upper_bound risk_upper_bound( n_defer_errorsint((1 - correctness[mask]).sum()), n_deferredmask.sum(), alphaalpha, ) if upper_bound max_risk: qualified.append((tau, error_rate, upper_bound, mask.sum())) return qualified这段代码的意义是即使模型口头置信度不可靠只要它包含一定信息量我们仍然可以在有限验证集上找出一个阈值使得“对外回答”的错误率在统计意义上被控制住。7.3 调优指标推迟率阈值越高对外回答的准确率越有保证但推迟率也会升高。如果推迟率太高大量问题都转人工产品体验会变差。工程上需要综合看两个指标对外回答错误率上界 业务阈值。推迟率尽量低。一个合理的做法是在不同阈值下分别计算“错误率上界”和“推迟率”画一条曲线然后在满足风险约束的前提下选择推迟率最低的阈值。8. 接口 API 与批量任务验证完校准和阈值后可以将“口头不确定性 推迟决策”封装成 API 服务方便接入业务系统。8.1 基于 FastAPI 的接口示例from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class Query(BaseModel): question: str answer: str class Response(BaseModel): answer: str confidence: float deferred: bool THRESHOLD 0.7 app.post(/predict, response_modelResponse) def predict(query: Query): confidence extract_confidence(query.question, query.answer) if confidence is None: confidence 0.0 deferred confidence THRESHOLD return Response( answerquery.answer, confidenceconfidence, deferreddeferred, )extract_confidence就是前面写的模型推理 解析函数。对于更复杂的场景还可以把推迟决策放到一个独立服务中方便更新阈值。8.2 启动 API 服务uvicorn app:app --host 0.0.0.0 --port 8000启动后可以用 curl 测试curl -X POST http://127.0.0.1:8000/predict \ -H Content-Type: application/json \ -d {question: 中国的首都是哪里, answer: 北京}返回结果中会包含deferred: true/false。业务系统拿到deferredfalse后可以直接把答案返回给用户拿到deferredtrue后转人工或走更高级模型。8.3 批量任务与评估脚本实际使用中往往需要离线批量评估一批样本验证阈值是否满足风险要求。def batch_evaluate(questions, answers, correct_flags, threshold): results [] for q, a, c in zip(questions, answers, correct_flags): conf extract_confidence(q, a) if conf is None: conf 0.0 deferred conf threshold results.append({ question: q, answer: a, confidence: conf, correct: c, deferred: deferred, }) # 统计对外回答的错误率 answered [r for r in results if not r[deferred]] if answered: error_rate sum(1 for r in answered if not r[correct]) / len(answered) else: error_rate None defer_rate sum(r[deferred] for r in results) / len(results) return error_rate, defer_rate, results批量脚本的价值是可以快速验证阈值改动对整体效果的影响。每次模型升级或数据分布变化后都应该重跑一遍。9. 资源占用与性能观察9.1 显存和内存怎么看小模型通常在普通消费级显卡上就能跑。但具体占多少显存取决于模型参数量、输入长度、批次大小和是否量化。建议在测试时单独开一个终端用以下命令观察显存watch -n 1 nvidia-smi在 CPU 上跑时主要观察内存watch -n 1 free -h不要在推理过程中频繁打印日志否则会干扰性能判断。9.2 影响性能的关键因素输入长度越长占用的显存和内存越高。批量越大推理速度越快但显存占用也越高。max_new_tokens越大单次请求耗时越长。如果同时运行多个并发请求需要做好队列或限制并发数。9.3 降低资源占用的方法使用 4bit 或 8bit 量化加载模型。使用batch_size控制批大小。对输入做截断避免超长上下文。使用 vLLM 或 TGI 等推理框架加速小模型推理但会增加部署复杂度。需要说明的是这些建议是通用工程实践不来自论文本身。实际显存数字必须按照你选的模型和机器实测。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型不输出置信度数字prompt 格式不合适或模型指令跟随能力弱打印完整生成文本人工检查输出格式调整 prompt增加示例或改用结构化指令模板置信度总是 0.9 以上模型过度自信训练数据里缺少低置信度表达统计置信度分布查看校准曲线不要直接信任口头置信度改用认证推迟置信度集中在 0.5模型没有真正学会估计不确定性观察不同难度样本的置信度差异需要微调或更换模型校准曲线非常差模型内部概率和口头输出不一致计算 ECE 和可靠性图使用外部校准方法例如温度缩放、保序回归推迟率过高阈值设置太高或模型能力不足查看不同阈值下的推迟率和错误率减小阈值或先提升模型能力API 调用超时模型推理时间过长或并发过高查看日志和 CPU/GPU 占用增加超时时间限制并发使用异步处理显存不足模型加载方式不当或批次过大检查 nvidia-smi降低批大小使用量化加载或换更小模型批量任务卡住没有异常处理单条样本解析失败导致任务中断查看日志中卡住的样本增加 try-except超时跳过设置最大重试次数11. 最佳实践与使用建议11.1 不要在线上直接信任口头置信度就算模型在验证集上校准表现不错也不代表线上一定可靠。训练数据分布、用户提问方式、业务场景变化都会让校准漂移。生产环境应持续采样监控定期重跑校准评估。11.2 把推迟决策做成独立模块建议把“答案生成”和“推迟决策”拆成两个模块。模型只负责生成答案和置信度信号推迟决策由独立服务根据阈值和业务规则完成。这样做的优点是调整阈值不需要重启模型服务。不同业务线可以配置不同风险阈值。模型升级后风险控制逻辑可以保持不变。11.3 保留完整审计日志对于医疗、金融、法律等高风险场景每次模型对外回答都应该记录输入问题。模型答案。口头化不确定性值。是否触发推迟。阈值版本。模型版本。最终是否有人工复核。这些日志不仅能用来复盘错误还能在争议时提供依据。11.4 合规与隐私提醒如果你把真实用户问题传到本地或远程模型做验证要注意最小化数据采集避免留存不必要的个人信息。涉及人脸、声音、身份证件、医疗记录等敏感信息时必须事先完成隐私评估和授权确认。模型输出可能包含有害或错误内容不能直接作为最终决策结果对外发布。12. 总结与下一步这篇论文最有价值的点不是告诉我们“小模型不确定性能做得多好”而是提醒我们口头化不确定性在小模型上存在可证明的可靠性边界不能直接拿来当风险控制依据。工程上最值得做的第一步是先用一个真实业务场景的样本集让 SLM 输出答案和置信度计算 ECE、画校准曲线。如果你发现模型自评和真实正确率差得很远那就坚决引入认证推迟机制让系统在阈值之外强制转人工而不是让模型自己“凭感觉”决定要不要回答。最容易踩的坑有两个一是把“模型说出的置信度”当成了“真实概率”直接做硬阈值拦截二是阈值调太高导致大量问题被推迟业务体验崩掉。正确的做法是把口头化不确定性当作一个弱信号通过验证集找到满足风险约束的最低推迟率阈值。后续可以继续扩展的方向包括用更强的外部校准方法降低口头置信度偏差把推迟阈值做成动态配置按业务线差异化控制接入更强模型作为“救援模型”实现模型间的自动路由。这里的工程落地点比论文本身更通用建议先收藏后面做小模型可靠性设计时直接参照这套验证流程。 小型语言模型口头化不确定性：认证推迟机制与工程落地指南
这次我们来看一个偏研究向、但对实际部署非常有价值的话题Small Language Models小型语言模型中的 Verbalized Uncertainty口头化不确定性以及论文《Provable Limits and Certified Deferral for Verbalized Uncertainty in Small Language Models》提出的“Certified Deferral认证推迟”思路。它解决的问题非常直接小模型在回答问题时经常会“嘴上”说一句“我觉得我有 90% 的把握”但这种口头表达出来的置信度通常是不太可靠的。模型可能嘴上说 90%实际只有 60%。这篇论文的核心贡献是从理论上说明这种不可靠存在边界并给出一种“模型不行就把任务推迟给更强的模型或人工”的可信机制。本文不会只停留在论文解读层面我会把它拆成几个工程上可以落地的技术决策点并给出一套基于小型语言模型的最小验证流程如何让模型输出口头化不确定性、如何评估校准效果、如何用阈值判断是否推迟、如何封装成 API 服务并做批量验证。适合正在做 SLM 落地、RAG Agent、智能客服、知识库问答、内容审核辅助以及任何需要“模型答不出来时能主动放弃”的可靠性系统的同学。如果你只关心推理速度、显存占用、批量任务和接口调用这篇也能帮你把“不确定性机制”接入到现有服务里。1. 核心能力速览先给一张速览表快速判断这篇论文和后续验证流程值不值得继续看。能力项说明项目类型学术论文 / 方法论不是开箱即用工具核心问题小模型口头化不确定性不可靠如何证明并兜底核心方法可证明限制 认证推迟Certified Deferral关键概念Small Language Models、Verbalized Uncertainty、Certified Deferral、校准、选择性预测硬件门槛没有严格特殊要求验证流程可在单张消费级 GPU 或 CPU 上完成显存占用取决于所选小模型尺寸和批次大小需按实际环境测试支持平台论文本身不限平台工程验证可用 Python Transformers 完成启动方式论文无启动器验证流程可用命令行脚本启动是否支持 API论文不是服务但可将验证流程封装为 FastAPI 接口是否支持批量任务可以通过批量评估脚本完成校准和推迟策略验证适合场景SLM 问答、RAG 置信度兜底、客服辅助、知识库问答、模型拒答策略注意因为输入材料中只给了论文标题和相关热词没有提供论文正文、官方代码仓库或作者实验数据所以下文中的复现流程是“一个符合当前研究共识的最小验证框架”不是论文官方代码的复刻。实际使用前需要对照论文原文检查细节。2. 口头化不确定性是什么为什么小模型不可靠2.1 从“口头化”三个字理解问题Verbalized Uncertainty直译是“口头化不确定性”。它指的是模型通过自然语言输出直接表达自己对答案的确定程度。例如“我确定答案是巴黎。”“我觉得北京是正确答案但不太确定。”“这个问题我不太知道。”“正确答案是巴黎置信度 0.87。”这些表达本质上都是模型在“说”它的不确定性。对于大模型这种“口头化”可能有一定参考价值因为大模型接触过大量指令微调和人类反馈数据能够学会在回答中嵌入概率词。但对于小型语言模型情况要复杂得多。2.2 口头置信度不等于真实概率在概率论里一个预测系统如果宣称 80% 置信度那么长期来看它回答正确的频率应当接近 80%。这就叫校准。但语言模型天然不是为输出概率而训练的。它训练目标是最大化下一个 token 的生成概率这是自回归建模目标。模型在解码时最终输出文本中的“0.87”这个 token 序列并不保证和模型内部真实概率分布一致。也就是说模型可能输出“我认为正确率是 90%”但实际正确率只有 60%。模型可能输出“我不确定”但实际答题准确率又很高。不同 prompt 模板对输出的置信度数值影响很大。这和模型的内部隐藏状态概率有关但更核心的问题是口头化不确定性本身就是一段生成文本它可以被“编造”出来也可以被 prompt 引导并不存在天然一致性的保证。2.3 小模型的容量限制让问题更严重大模型容量大训练数据多在指令微调后更容易模仿出合理的置信度表达。小模型参数少、能力弱在指令跟随、自省、数值输出上都存在短板。对比维度大模型小模型指令跟随能力强能按格式输出置信度弱容易输出无关文本自省能力相对可靠容易“胡诌”置信度置信度数值稳定性相对稳定对 prompt 非常敏感校准质量不一定好但通常优于小模型通常偏差明显实际部署成本高需要大显存低CPU 也能跑这不是说小模型完全不能用而是说如果你准备让小模型在线上直接输出“我的置信度是 X”必须先验证 X 和真实正确率之间是否存在可靠关系。2.4 “可证明的限制”意味着什么论文标题里的“Provable Limits”说明作者不是简单做实验发现“小模型口头不确定性不准”而是试图从理论层面证明在某些条件下小模型无法精确表达自己的不确定性或者通过口头化方式表达不确定性存在不可逾越的误差边界。“可证明”这三个字在工程上的价值是不要盲目相信模型自己报出来的置信度。如果理论上就存在误差极限那么单纯让模型“说真话”是无法根本解决问题的。系统设计上必须有一个外部兜底机制这就是 Certified Deferral 出现的背景。3. 认证推迟从“模型自评”到“规则兜底”3.1 什么是推迟“推迟”在机器学习里并不是新概念。传统选择性预测中模型可以选择对某些样本“不回答”而是交给人工处理或者交给另一个更强大的模型处理。这里的核心问题不是“能不能推迟”而是“什么时候推迟”以及“推迟了之后系统性能能不能被保证”。如果模型自己说“我不确定”系统就推迟那么模型要是“过于自信”怎么办如果模型每次都说“我不确定”系统就变成完全不敢回答产品体验也会崩。所以推迟不能完全交给模型自觉而要用外部规则和统计方法来控制。3.2 认证推迟的基本流程一个典型的认证推迟流程包含以下步骤模型生成答案同时输出一个口头化不确定性值 u。系统根据 u 或其它特征计算一个推迟分数 s。设定阈值 tau。如果 s tau正常输出答案。如果 s tau则不输出答案而是转人工或更强模型。这里的“认证”在于我们可以通过验证集在给定的风险约束下找到一个保证性能边界的阈值。比如我们希望系统对外回答的问题错误率不超过 5%。那么我们需要选择 tau使所有通过门槛的问题集合上的整体错误率在统计意义上不超过 5%。这种保证可以用校准后的风险估计、二项式置信区间、保序回归等方法实现。3.3 和直接拒答的区别一般模型“拒答”是模型自己决定不回答典型做法是训练时加入拒绝样本例如“我不知道”。缺点是训练成本高。小模型很难学明白什么时候该拒答。拒绝率不可控。无法给客户提供可解释的风险承诺。认证推迟则把决策从“模型内部”移到“系统外部”用验证集和统计方法控制失败风险。这样即使模型本身不会说“我不知道”系统也能在它置信度不足时强制转人工。3.4 与不确定性的关系口头化不确定性在这里不是被直接信任的最终结论而是作为推迟决策的一个输入信号。哪怕这个信号有偏差只要它包含关于模型正确性的一定信息量我们就能通过阈值和统计校准把它转化为一个可控的推迟策略。这正好契合论文标题里的“Certified Deferral”思想不要求模型自我评估百分之百准确而是设计一个系统让不可靠的自评最终也能被安全地纳入决策。4. 从论文到工程什么时候用得上4.1 适合使用该机制的场景智能客服模型不确定时转人工避免给用户错误承诺。知识库问答低置信度时返回“我帮你转给专业人员”。RAG 问答检索结果和生成答案不一致时不硬答。医疗、金融辅助涉及风险提示时必须有人工复核兜底。边缘设备部署只能跑 1B 以下小模型但又希望保留可靠性控制。这些场景的共同特点是回答错误的代价较高不能接受模型“错了也不自知”。4.2 不适合的场景对延迟敏感、没有人工兜底能力的服务。答案本身就是生成式内容没有明确对错标准的任务例如开放式闲聊、创意写作。模型能力严重低于任务难度几乎所有样本都需要推迟这时候应该先换模型或微调而不是靠推迟兜底。4.3 工程边界认证推迟不是万能药。它不能把一个小模型变成一个小失误率的大模型。它只能帮你识别“哪些回答值得放出去哪些还是转人工更安全”。如果模型本来 80% 的题都不会做那么阈值无论怎么调要么回答准确率极低要么推迟率极高。这时候应该先提升模型能力或者接入更大模型。5. 本地复现与验证环境准备这部分给出一个通用验证环境不绑定论文官方仓库。这里假设你会用 Python 和 Hugging Face Transformers通过加载一个小型语言模型完成“口头不确定性 校准评估 推迟策略”的验证。5.1 环境清单操作系统Windows / Linux / macOS 均可。Python建议 3.10 或以上。包管理工具pip 或 conda。深度学习框架PyTorch。模型库Transformers、datasets。科学计算numpy、scikit-learn、matplotlib。接口演示fastapi、uvicorn。GPU 驱动和 CUDA如果有 N 卡建议装好 CUDA 工具包没有也能纯 CPU 跑只是慢一些。5.2 创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install torch transformers datasets scikit-learn matplotlib fastapi uvicorn scipy如果使用 N 卡且有 CUDA需要按官方说明安装对应版本的 PyTorch。这个命令只是基础模板实际版本号建议到 PyTorch 官网生成。5.3 选择一个小型语言模型这里选择模型不需要太纠结建议选 1B 到 3B 参数范围内的开源模型。例如 Qwen2.5-1.5B、Qwen2.5-3B、Llama-3.2-1B、Phi-3-mini 等。每种指令微调模型对“输出置信度数字”的 prompt 模板要求不同需要你自己测试。建议先用一个非常小的模型跑通流程再换业务实际使用的模型。5.4 准备验证数据集你可以用公开的问答数据集也可以从自己的业务日志里采样一批真实问题。关键要求是每个问题必须有标准答案方便判断模型输出正确与否。如果条件允许准备 500 到 1000 条样本用于校准评估。太少的话置信区间会非常大阈值选择也不可信。6. 最小实验提取口头化不确定性并评估校准下面是一套最小实验流程目的是验证“模型口头报出的置信度”和“真实准确率”之间是否一致。6.1 实验设计输入一个问题。模型输出一个答案和一个置信度数值。后处理判断答案是否正确。聚合统计不同置信度区间下的实际正确率绘制校准曲线。6.2 让模型输出口头化置信度一个简单做法是在 prompt 中要求模型同时输出答案和 0 到 1 之间的置信度。代码示例如下from transformers import pipeline generator pipeline( text-generation, modelQwen/Qwen2.5-1.5B-Instruct, device_mapauto, ) def ask_with_confidence(question: str, answer: str): prompt ( fQuestion: {question}\n fProposed answer: {answer}\n Is this proposed answer correct? First output Yes or No, then output the probability (0-1) that the answer is correct. Format: Yes|0.87 or No|0.35\n ) outputs generator( prompt, max_new_tokens16, do_sampleFalse, ) return outputs[0][generated_text]注意不同模型对 prompt 的格式要求不同。实际使用时要针对模型指令模板做调整。6.3 解析置信度数值模型输出文本后需要解析出数字。这一步要健壮一点因为小模型很可能输出“Yes 0.87”或“0.87”等不同格式。import re def parse_confidence(text: str) - float | None: # 查找形如 0.5、0.80、1.0、0 的浮点数 matches re.findall(r\b([01](?:\.\d{1,3})?|0\.\d)\b, text) if not matches: return None # 取最后一个出现的数字通常是置信度 value float(matches[-1]) if 0.0 value 1.0: return value return None解析失败时可以直接将该样本标记为“无法给出置信度”这在后续推迟策略里可以当作低置信度处理。6.4 评估校准质量这里使用 ECEExpected Calibration Error来量化校准误差。ECE 计算方式是根据置信度分桶比较每个桶内的平均置信度和实际正确率然后加权求和。import numpy as np def compute_ece(confidences, correctness, num_bins10): bins np.linspace(0, 1, num_bins 1) ece 0.0 for i in range(num_bins): low, high bins[i], bins[i 1] # 选取该桶内的样本 mask (confidences low) (confidences high) if mask.sum() 0: continue avg_conf confidences[mask].mean() avg_acc correctness[mask].mean() weight mask.sum() / len(confidences) ece weight * abs(avg_conf - avg_acc) return ece这个指标越大说明模型口头置信度和真实准确率差距越大。你在项目里可以设定一个阈值例如 ECE 超过 0.2就认为口头化不确定性不可用必须上推迟机制。6.5 预期结果与判断标准如果模型校准良好那么置信度 0.8 的样本整体正确率应该接近 0.8。如果模型校准很差可能出现以下情况置信度普遍偏高0.9 的样本实际正确率只有 0.6。置信度集中在 0.5 附近没有区分度。同一模型在不同 prompt 下输出差异极大。如果出现这些问题说明“模型自评”不能单独作为风险控制手段应该考虑论文提到的 Certified Deferral 思路。7. 实现认证推迟阈值选择与风险保证在真实系统中我们需要一个可解释的规则来决定“模型是否可以对外回答”。下面给出一个实现示例。7.1 推迟策略设计假设我们已经收集了一批测试样本每条样本有confidence模型口头输出的置信度。correct模型答案是否正确1 或 0。我们选择阈值 tau只有当 confidence tau 时模型才对外输出答案。否则转人工或强模型。这样对外输出样本集合的风险就是对外回答的错误样本数 / 对外回答的总样本数我们希望控制这个错误率不超过某个业务风险值例如 5%。7.2 使用二项式置信上界做认证为了保证有限的验证集规模下阈值依然可靠可以使用二项分布置信上界来估计“真实错误率”的上界。from scipy.stats import beta def risk_upper_bound(n_defer_errors, n_deferred, alpha0.1): 计算 1 - alpha 置信水平下错误率的置信上界。 使用 Clopper-Pearson 方法也就是 Beta 分布分位数。 if n_deferred 0: return 1.0 # Beta 分布分位数对应二项分布置信上界 return beta.ppf(1 - alpha, n_defer_errors 1, n_deferred - n_defer_errors 1) def find_threshold(confidences, correctness, max_risk0.05, alpha0.1): 遍历阈值找到满足认证风险要求的最大推迟阈值。 返回合格的阈值列表。 candidates np.sort(np.unique(confidences)) qualified [] for tau in candidates: mask confidences tau if mask.sum() 0: continue error_rate 1 - correctness[mask].mean() upper_bound risk_upper_bound( n_defer_errorsint((1 - correctness[mask]).sum()), n_deferredmask.sum(), alphaalpha, ) if upper_bound max_risk: qualified.append((tau, error_rate, upper_bound, mask.sum())) return qualified这段代码的意义是即使模型口头置信度不可靠只要它包含一定信息量我们仍然可以在有限验证集上找出一个阈值使得“对外回答”的错误率在统计意义上被控制住。7.3 调优指标推迟率阈值越高对外回答的准确率越有保证但推迟率也会升高。如果推迟率太高大量问题都转人工产品体验会变差。工程上需要综合看两个指标对外回答错误率上界 业务阈值。推迟率尽量低。一个合理的做法是在不同阈值下分别计算“错误率上界”和“推迟率”画一条曲线然后在满足风险约束的前提下选择推迟率最低的阈值。8. 接口 API 与批量任务验证完校准和阈值后可以将“口头不确定性 推迟决策”封装成 API 服务方便接入业务系统。8.1 基于 FastAPI 的接口示例from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class Query(BaseModel): question: str answer: str class Response(BaseModel): answer: str confidence: float deferred: bool THRESHOLD 0.7 app.post(/predict, response_modelResponse) def predict(query: Query): confidence extract_confidence(query.question, query.answer) if confidence is None: confidence 0.0 deferred confidence THRESHOLD return Response( answerquery.answer, confidenceconfidence, deferreddeferred, )extract_confidence就是前面写的模型推理 解析函数。对于更复杂的场景还可以把推迟决策放到一个独立服务中方便更新阈值。8.2 启动 API 服务uvicorn app:app --host 0.0.0.0 --port 8000启动后可以用 curl 测试curl -X POST http://127.0.0.1:8000/predict \ -H Content-Type: application/json \ -d {question: 中国的首都是哪里, answer: 北京}返回结果中会包含deferred: true/false。业务系统拿到deferredfalse后可以直接把答案返回给用户拿到deferredtrue后转人工或走更高级模型。8.3 批量任务与评估脚本实际使用中往往需要离线批量评估一批样本验证阈值是否满足风险要求。def batch_evaluate(questions, answers, correct_flags, threshold): results [] for q, a, c in zip(questions, answers, correct_flags): conf extract_confidence(q, a) if conf is None: conf 0.0 deferred conf threshold results.append({ question: q, answer: a, confidence: conf, correct: c, deferred: deferred, }) # 统计对外回答的错误率 answered [r for r in results if not r[deferred]] if answered: error_rate sum(1 for r in answered if not r[correct]) / len(answered) else: error_rate None defer_rate sum(r[deferred] for r in results) / len(results) return error_rate, defer_rate, results批量脚本的价值是可以快速验证阈值改动对整体效果的影响。每次模型升级或数据分布变化后都应该重跑一遍。9. 资源占用与性能观察9.1 显存和内存怎么看小模型通常在普通消费级显卡上就能跑。但具体占多少显存取决于模型参数量、输入长度、批次大小和是否量化。建议在测试时单独开一个终端用以下命令观察显存watch -n 1 nvidia-smi在 CPU 上跑时主要观察内存watch -n 1 free -h不要在推理过程中频繁打印日志否则会干扰性能判断。9.2 影响性能的关键因素输入长度越长占用的显存和内存越高。批量越大推理速度越快但显存占用也越高。max_new_tokens越大单次请求耗时越长。如果同时运行多个并发请求需要做好队列或限制并发数。9.3 降低资源占用的方法使用 4bit 或 8bit 量化加载模型。使用batch_size控制批大小。对输入做截断避免超长上下文。使用 vLLM 或 TGI 等推理框架加速小模型推理但会增加部署复杂度。需要说明的是这些建议是通用工程实践不来自论文本身。实际显存数字必须按照你选的模型和机器实测。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型不输出置信度数字prompt 格式不合适或模型指令跟随能力弱打印完整生成文本人工检查输出格式调整 prompt增加示例或改用结构化指令模板置信度总是 0.9 以上模型过度自信训练数据里缺少低置信度表达统计置信度分布查看校准曲线不要直接信任口头置信度改用认证推迟置信度集中在 0.5模型没有真正学会估计不确定性观察不同难度样本的置信度差异需要微调或更换模型校准曲线非常差模型内部概率和口头输出不一致计算 ECE 和可靠性图使用外部校准方法例如温度缩放、保序回归推迟率过高阈值设置太高或模型能力不足查看不同阈值下的推迟率和错误率减小阈值或先提升模型能力API 调用超时模型推理时间过长或并发过高查看日志和 CPU/GPU 占用增加超时时间限制并发使用异步处理显存不足模型加载方式不当或批次过大检查 nvidia-smi降低批大小使用量化加载或换更小模型批量任务卡住没有异常处理单条样本解析失败导致任务中断查看日志中卡住的样本增加 try-except超时跳过设置最大重试次数11. 最佳实践与使用建议11.1 不要在线上直接信任口头置信度就算模型在验证集上校准表现不错也不代表线上一定可靠。训练数据分布、用户提问方式、业务场景变化都会让校准漂移。生产环境应持续采样监控定期重跑校准评估。11.2 把推迟决策做成独立模块建议把“答案生成”和“推迟决策”拆成两个模块。模型只负责生成答案和置信度信号推迟决策由独立服务根据阈值和业务规则完成。这样做的优点是调整阈值不需要重启模型服务。不同业务线可以配置不同风险阈值。模型升级后风险控制逻辑可以保持不变。11.3 保留完整审计日志对于医疗、金融、法律等高风险场景每次模型对外回答都应该记录输入问题。模型答案。口头化不确定性值。是否触发推迟。阈值版本。模型版本。最终是否有人工复核。这些日志不仅能用来复盘错误还能在争议时提供依据。11.4 合规与隐私提醒如果你把真实用户问题传到本地或远程模型做验证要注意最小化数据采集避免留存不必要的个人信息。涉及人脸、声音、身份证件、医疗记录等敏感信息时必须事先完成隐私评估和授权确认。模型输出可能包含有害或错误内容不能直接作为最终决策结果对外发布。12. 总结与下一步这篇论文最有价值的点不是告诉我们“小模型不确定性能做得多好”而是提醒我们口头化不确定性在小模型上存在可证明的可靠性边界不能直接拿来当风险控制依据。工程上最值得做的第一步是先用一个真实业务场景的样本集让 SLM 输出答案和置信度计算 ECE、画校准曲线。如果你发现模型自评和真实正确率差得很远那就坚决引入认证推迟机制让系统在阈值之外强制转人工而不是让模型自己“凭感觉”决定要不要回答。最容易踩的坑有两个一是把“模型说出的置信度”当成了“真实概率”直接做硬阈值拦截二是阈值调太高导致大量问题被推迟业务体验崩掉。正确的做法是把口头化不确定性当作一个弱信号通过验证集找到满足风险约束的最低推迟率阈值。后续可以继续扩展的方向包括用更强的外部校准方法降低口头置信度偏差把推迟阈值做成动态配置按业务线差异化控制接入更强模型作为“救援模型”实现模型间的自动路由。这里的工程落地点比论文本身更通用建议先收藏后面做小模型可靠性设计时直接参照这套验证流程。