这次我们来看一个不是工具、也不是模型但和每个用 AI 做事的工程团队都强相关的话题DeepMind 副总裁谈 AI 不确定性推理。名字听起来偏研究拆开以后全是工程问题——模型什么时候会编答案能不能说出“我不知道”置信度数值能不能信被知识边界卡住时应该走哪条降险路径。这类观点分享很容易被读成“AI 应该更有自知之明”但真正落地时我们需要把它变成三件事第一把不确定性量化出来不能只靠模型凭感觉说“我不确定”第二让模型的置信度和真实正确率尽量一致也就是校准第三在低置信度场景下自动切换策略比如查资料、调计算器、交给人工。下面我会把这三个方向展开成可操作的测试和工程流程。本文不会只复述访谈观点而是整理出一套可以直接拿去用的评估思路怎么设计评测集怎么批量跑模型并记录答案和置信度怎么计算多次采样一致性怎么通过工具调用降低幻觉风险最后给出常见的排查清单。阅读本文不需要特殊硬件如果你已经有模型 API 或本地推理环境就能直接开始。1. 核心能力速览先把“AI 不确定性推理”当作一个系统能力来拆而不是一个模型参数。下面这张表列出工程落地时需要关注的能力维度能力维度说明不确定性识别模型能否区分“有把握”和“不确定”是否会在薄弱知识上给出高置信度答案置信度输出是否提供 logprobs、数值置信度或文本置信度表达能否用于程序判断校准质量置信度 0.9 的答案真实正确率是否接近 90%而不是偏高或偏低降险策略低置信度时自动执行拒绝回答、求助、检索、计算或人工复核工具验证通过搜索引擎、代码执行、计算器、数据库等外部工具验证答案批量评测能否用脚本批量跑评测集记录答案、置信度、延迟和失败次数可观测性日志中是否保留 prompt、输出、置信度、采样参数、触发策略便于复盘适用角色算法工程师、后端开发、AI 应用产品经理、QA 测试、数据合规人员这些能力不是单个模型能天然提供的。当前主流做法是用模型输出概率或多次采样来估计不确定性再用外部工具或人工核验来把不可信答案拦截在业务逻辑之外。具体能拿到多少信息取决于你用的是封闭 API 还是本地开源模型也取决于模型是否暴露 token 概率、logprobs 等字段需要按实际环境评估不能只看宣传。2. 适用场景与使用边界不确定性推理在工程上有用的场景共同点是“答案错了会有成本”。比如客服场景中AI 必须知道哪些售后退款政策是自己的知识盲区不能猜文档问答场景中模型对扫描件或混合排版内容理解不深时应明确低置信度并转人工内容审核辅助场景中风险判断不能直接下结论而是要输出“疑似”以及置信度交给审核员复核数据提取场景中识别结果不一致时应该标记为失败而不是硬给一个结果。也有明显不合适的场景。医疗诊断、法律结论、金融投资决策、司法量刑这类高风险应用即便模型给出了置信度 0.99也不能把最终决策权交给模型。不确定性推理可以暴露风险但不能消除风险。工程团队必须把“模型建议”和“业务决策”分开在流程上设置人工确认。另外如果任务本身就是开放创作、文案润色、灵感生成则不需要高精度置信度也不适合用拒绝回答策略打断创作过程。使用边界还包括数据合规。评测集如果包含用户真实对话、个人隐私、未授权商业数据需要在授权范围内使用。涉及人脸、声音、肖像和版权素材的任务要确认授权链条。公开发布 AI 生成结果时也要符合平台规则和法律要求。工程上除了功能正确性之外数据来源和输出用途都要留痕。3. 工程视角下的不确定性推理三个关键点不确定性和置信度是不同概念。不确定性描述模型对答案的把握程度可以是模型内部概率也可以是从多次生成结果计算出来的一致性置信度是模型对外输出的一个数值或文本表达。工程上不能只看模型自己说“我很有把握”更常见的是用以下三种方式做交叉验证。第一种是内部概率。某些接口会返回 token 级别的 logprobs把所有 token 概率累加或取平均能得到一个粗略置信度。缺点是很多模型会出现过度自信尤其在幻觉样本上概率反而偏高。第二种是多次采样一致性。同一问题在 temperature 大于 0 时采样多次如果答案不一致说明模型不稳定不确定性高。第三种是外部验证。用代码执行、搜索、数据库查询或规则校验去核对答案能直接消解不确定性而不是只评估不确定性。这三个关键点对应到落地动作内部概率用来做快速筛查多次采样一致性用来做稳健性评估外部验证用来做最终兜底。企业级系统通常不能只依赖其中一个。只靠概率会漏掉过度自信的幻觉只靠多次采样会增加成本和延迟只靠外部验证则会受限于工具覆盖面。正确的做法是把三者组合成一条分级处理管线。4. 环境准备与前置条件本文不针对某个具体开源项目所以环境给的是通用检查清单。请根据你自己使用的模型和接口平台做调整。模型访问方式远程 API 或本地部署推理服务只要能通过 HTTP 或 SDK 调用即可。Python 环境建议准备一个独立虚拟环境Python 版本以你使用的推理 SDK 要求为准常见 3.10 及以上。依赖库requests、openai如果用 OpenAI 兼容接口、pandas 或 csv 模块、json用于批量跑评测和记录结果。评测集准备 CSV 或 JSON 格式的问题列表包含题号、类型、问题、标准答案或参考答案必要时附带检索知识库内容。存储空间评测结果、日志、模型输出文件需要独立目录磁盘空间按评测集大小和输出长度估算。计算资源如果用本地模型需要足够的 GPU 显存和内存具体以模型权重显存需求为准如果调用远程 API对本地资源要求较低。网络与端口本地服务需要确认端口未被占用批量任务建议配置超时和重试机制。准备环境时先建目录结构把评测脚本、评测集、输出结果分开。这样后面批量跑任务、复盘失败样例都不用翻日志。# 通用目录结构按实际项目替换路径 mkdir -p ai-uncertainty-eval/{configs,datasets,outputs,logs}5. 搭建不确定性推理评测流程评测集质量直接决定评测结论是否可信。如果全是教科书常见题模型正确率高但不代表不确定性推理能力强如果全是极端偏题参考也不好定。建议按五类问题混合设计。常规题模型应该答对且高置信度用于验证基线能力。边界知识题模型可能只见过一部分同类问题用于考察是否误报高置信度。矛盾前提题问题本身存在逻辑矛盾或信息缺失好的模型应该指出问题而不是硬答。易混事实题相似数字、相似人名、相似时间用于考察细节区分能力。需要计算或查证题例如“某个模型在发布报告中报告了哪些关键参数”要求模型先检索再回答。有了评测集之后用脚本批量调用模型并把每次返回的答案、置信度、温度、采样次数、耗时记录下来。下面给一个通用模板实际接口字段和访问地址需要按你的模型服务调整。import json import time import requests # 以远程 API 为例实际地址、密钥和请求字段需要按服务商文档替换 MODEL_URL https://your-model-endpoint.example.com/v1/chat/completions API_KEY your-api-key def call_model(prompt: str, temperature: float 0.7) - dict: 调用模型返回答案文本、置信度、耗时。 headers {Authorization: fBearer {API_KEY}} payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: temperature, max_tokens: 512, } start time.time() resp requests.post(MODEL_URL, headersheaders, jsonpayload, timeout60) elapsed time.time() - start data resp.json() answer data[choices][0][message][content] # 如果接口提供了 token 概率或置信度字段在这里读取 confidence None return {answer: answer, confidence: confidence, elapsed: elapsed} def run_eval(dataset_path: str, output_path: str) - None: with open(dataset_path, r, encodingutf-8) as f: questions json.load(f) results [] for item in questions: prompt item[question] result call_model(prompt, temperature0.7) results.append({ id: item[id], type: item[type], question: prompt, answer: result[answer], elapsed: result[elapsed], }) with open(output_path, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: run_eval(datasets/eval_set.json, outputs/results.json)上面代码只是框架。真实运行时需要处理返回状态码异常、网络超时、限流、API key 失效。第一轮可以采用小评测集、每条问题只生成一次先跑通流程再放大规模。对评测结果逐条看能发现很多表面上看不见的问题比如同一题换一种说法模型就露怯或者模型对明显错误的事实依然给出高置信度。6. 置信度校准与多次采样单个回答的置信度不可靠工程上更稳妥的方式是多次采样。把同一个问题用 temperature 大于 0 的参数生成多次然后看答案是否一致。如果多次结果一致模型对这个问题的稳定性高如果同一问题生成出多个不同答案显然不该相信任何一条单独输出。下面给出一个最简单的多次采样一致性计算示例。import collections import json def compute_consistency(responses: list[str]) - dict: 根据多次采样结果计算一致性。 counts collections.Counter(responses) total len(responses) top_answer, top_count counts.most_common(1)[0] # 归一化文本后的一致性比例 consistency top_count / total return { top_answer: top_answer, top_count: top_count, total: total, consistency: consistency, distinct_answers: len(counts), } if __name__ __main__: samples json.load(open(outputs/samples.json, encodingutf-8)) for item in samples: result compute_consistency(item[responses]) print(item[id], result)一致性不是绝对标准。有些问题本来就有多个正确答案例如“列出三种常见激活函数”模型每次列出的不完全一样并不代表错误。所以评测集要区分“唯一答案题”和“开放答案题”。对唯一答案题一致性越低风险越高对开放答案题一致性低不一定有风险但仍需要检查语义重复和内容覆盖度。校准环节要观察的是“置信度 0.8 的题目实际答对比例是不是 80%”。做法是把评测结果按置信度分桶例如 0.0-0.1、0.1-0.2……0.9-1.0然后统计每个桶的真实正确率。如果高置信度桶的正确率明显低于置信度说明模型过度自信需要调低阈值或增加验证步骤如果低置信度桶的正确率也很高说明模型对自身能力判断偏低可能影响用户体验。整体校准结果可以用预期校准误差 ECE 这类指标衡量但面向业务汇报时分桶表比单一指标更容易被人理解。7. 降险策略从直接回答到验证后再回答评估完不确定性之后真正要落地的是一套降险策略。核心思路是根据置信度和风险等级决定走哪条路径。低风险问题可以直接回答中等置信度问题先检索再回答低置信度问题拒绝回答或转人工高风险问题无论如何都要外部验证。典型决策流程可以写成下面的伪代码def answer_with_risk_control(question: str, risk_level: str) - str: rough_confidence get_model_confidence(question) if risk_level high: # 高风险场景先检索、再生成、再人工审核 evidence retrieve(question) draft generate_with_evidence(question, evidence) return send_to_human_review(draft) if rough_confidence 0.3: return 我无法确认这个问题的答案建议查阅原始资料或咨询专业人员。 if rough_confidence 0.7: evidence retrieve(question) if evidence: return generate_with_evidence(question, evidence) return 当前资料不足以回答请稍后再试或补充信息。 return generate_direct_answer(question)这个流程是概念示例具体的函数需要接入你的知识库、搜索服务和业务审核系统。值得注意的一点是降险策略不是越多越好也不是拒绝回答越频繁越好。工程上要结合产品体验设定阈值过度拒绝会让用户觉得产品没用过度自信又会让错误答案流向用户。阈值需要根据业务风险承受能力反复调。这里还需要考虑“模型调用之外”的验证手段。对计算类问题让模型调用 Python 解释器完成算术而不是直接心算对事实类问题先把问题拆成检索词去知识库里找到原文后再回答对结构化数据问题要求模型输出 JSON 并由程序校验字段类型和取值范围。外部验证能用规则解决的就用规则不要让模型自己判断自己有没有错。8. 接口 API 与批量任务设计从工程落地看不确定性推理能力必须变成可重复、可批量、可监控的流程。建议把评测和管理封装成一个任务系统输入是问题集输出是结果、日志和统计报表。任务系统至少包含三个目录配置目录、输入目录、输出目录所有任务都记录开始时间、结束时间、成功失败状态。{ task_name: uncertainty_eval_round_1, model: your-model-name, temperature: 0.7, num_samples: 5, timeout_seconds: 60, max_retries: 2, risk_level: medium, input_file: datasets/eval_set.json, output_dir: outputs/round_1 }批量任务里最容易出问题的点是超时和限流。远程 API 在并发量大时会有速率限制本地模型在高并发下可能显存溢出或排队时间变长。建议给每次调用设置超时时间超时后重试最多两到三次如果重试仍失败把该任务标记为失败而不是跳过。批量任务最好支持断点续跑已经完成的结果不要重复调用模型节省成本。接口返回后要立即落盘不能只存在内存里避免进程崩溃后丢失全部结果。批量结果的审计日志要记录问题原文、模型答案、置信度数值或 logprobs、采样参数、检索命中的文档、最终是否触发降险策略、是否进入人工复核。有了这些字段才能复盘“哪类问题让模型高置信度出错”以及“降险策略有没有拦截住错误答案”。没有日志的不确定性评估结果基本不可信。9. 资源占用与性能观察不确定性推理不是免费的。多次采样、检索、工具调用都会增加延迟和成本观察性能时要放在真实业务链路里看。下面列出几个观察维度。推理次数同一问题采样 5 次模型推理次数就是原来的 5 倍延迟和成本都随之上升。温度大于 0 会显著影响连续输出降低并发或使用缓存可以缓解。上下文长度加入检索文档后输入 token 变多单次推理的显存占用和耗时都会增加批量任务总时长明显变长。工具调用搜索或代码执行的耗时通常远大于单次模型生成且不稳定网络波动会拉长任务时间。并发与排队本地模型在高并发下显存占用上升远程 API 有速率限制任务系统需要控制并发数。本地模型显存占用要按你使用的模型权重和上下文长度实测不同参数量的模型差异很大。建议先跑最小配置即单条问题、单次采样、无工具调用观察延迟和显存再把采样次数、上下文、工具调用逐步增加记录每一步的耗时变化。如果显存不足可以降低上下文长度、减小 batch、关闭并行推理、使用量化版本或者换远程 API。从成本角度看没必要对所有问题都做多次采样。可以先用单次生成拿到初步答案只有置信度处于中间区间的问题才触发多次采样或检索高置信度直接返回低置信度直接拒绝。这种分层设计能把性能开销集中在真正需要验证的问题上。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型对明显错误的事实给出高置信度模型内部概率过于自信查看该问题多次采样一致性对比真实正确率降低直接回答阈值改为先检索再回答置信度数值与真实正确率明显不一致校准偏移按置信度分桶统计正确率调整温度或对置信度做映射调整多次采样结果各不相同问题语义不够明确或模型不稳定检查题目措辞和开放性拆分问题明确约束或增加检索范围拒绝回答比例过高阈值设得太高统计各区间置信度分布调整阈值增加检索和工具验证API 调用超时或限流并发过大或网络不稳定查看响应状态码和日志降低并发、增加超时和重试、断点续跑批量任务卡住单条调用无超时或进程阻塞查看任务日志和当前进程为每次调用设置超时和最大重试次数检索后答案仍无改善知识库覆盖不足或检索词不对检查命中文档相关性优化检索词或引入更多数据源高风险问题仍直接透出错误结论决策流程未区分风险等级审查问题分级逻辑对高风险任务强制人工复核排查时先看日志再复现单条问题不要直接在批量任务里反复重试。好的做法是把失败样例沉淀成回归集每次修改策略后都跑一遍确保旧问题不复发。这会持续提升系统稳定性。11. 最佳实践与合规建议最后总结几条值得带进团队实践的工程建议。第一先搭小评测集。不要一上来就评测几千条问题先放 50 到 100 条典型问题把脚本和流程跑通再逐步扩展。第二置信度指标要落到业务含义上。告诉业务方“模型置信度 0.9但这个区间正确率只有 0.7”比只说“模型很自信”更有用。第三高风险任务必须留人工复核节点。AI 可以大幅提升效率但不能承担最终责任的转移。数据合规方面评测集如果来自真实用户对话、内部文档或第三方平台要确认是否具备使用和存储授权。涉及人脸、声音、肖像、版权作品和敏感个人信息时必须有合法来源和明确用途。生成内容的对外发布也要符合平台和行业规则。本地部署能把数据留在自己的环境里但模型权重本身也有授权范围不能随意跨场景商用。还要注意不要试图用不确定性推理功能去规避平台规则、绕过安全限制或生成违规内容。模型评估的目的是提升质量和降低风险不是在灰色地带寻找漏洞。如果某个任务在合规层面本身不能做那么无论模型置信度多高、降险策略多完善都不应该上线。12. 总结与下一步DeepMind 副总裁谈 AI 不确定性推理真正值得关注的是把“模型知不知道”变成工程上可评估、可干预、可复盘的系统能力。建议你从三个动作开始准备一份包含边界题和易幻觉题的小评测集跑一次批量脚本记录答案和置信度再算一次分桶校准结果。这套流程跑完你会比只聊“大模型很厉害”的人更清楚系统在哪些地方会犯错、什么情况下需要加检索或转人工。下一步可以从评测系统往下游走把不确定性信号接入业务规则引擎让低置信度回答自动转人工或回流到知识库建设。更长期的方向是用错误样本反向优化提示词、模型选择甚至知识库内容。这个环节没有终点但每多拦下一个高置信度错误系统就离“可信 AI”更近一步。值得收藏备用也值得在下个迭代里真跑一轮。 AI不确定性推理工程实践：置信度校准与降险策略
这次我们来看一个不是工具、也不是模型但和每个用 AI 做事的工程团队都强相关的话题DeepMind 副总裁谈 AI 不确定性推理。名字听起来偏研究拆开以后全是工程问题——模型什么时候会编答案能不能说出“我不知道”置信度数值能不能信被知识边界卡住时应该走哪条降险路径。这类观点分享很容易被读成“AI 应该更有自知之明”但真正落地时我们需要把它变成三件事第一把不确定性量化出来不能只靠模型凭感觉说“我不确定”第二让模型的置信度和真实正确率尽量一致也就是校准第三在低置信度场景下自动切换策略比如查资料、调计算器、交给人工。下面我会把这三个方向展开成可操作的测试和工程流程。本文不会只复述访谈观点而是整理出一套可以直接拿去用的评估思路怎么设计评测集怎么批量跑模型并记录答案和置信度怎么计算多次采样一致性怎么通过工具调用降低幻觉风险最后给出常见的排查清单。阅读本文不需要特殊硬件如果你已经有模型 API 或本地推理环境就能直接开始。1. 核心能力速览先把“AI 不确定性推理”当作一个系统能力来拆而不是一个模型参数。下面这张表列出工程落地时需要关注的能力维度能力维度说明不确定性识别模型能否区分“有把握”和“不确定”是否会在薄弱知识上给出高置信度答案置信度输出是否提供 logprobs、数值置信度或文本置信度表达能否用于程序判断校准质量置信度 0.9 的答案真实正确率是否接近 90%而不是偏高或偏低降险策略低置信度时自动执行拒绝回答、求助、检索、计算或人工复核工具验证通过搜索引擎、代码执行、计算器、数据库等外部工具验证答案批量评测能否用脚本批量跑评测集记录答案、置信度、延迟和失败次数可观测性日志中是否保留 prompt、输出、置信度、采样参数、触发策略便于复盘适用角色算法工程师、后端开发、AI 应用产品经理、QA 测试、数据合规人员这些能力不是单个模型能天然提供的。当前主流做法是用模型输出概率或多次采样来估计不确定性再用外部工具或人工核验来把不可信答案拦截在业务逻辑之外。具体能拿到多少信息取决于你用的是封闭 API 还是本地开源模型也取决于模型是否暴露 token 概率、logprobs 等字段需要按实际环境评估不能只看宣传。2. 适用场景与使用边界不确定性推理在工程上有用的场景共同点是“答案错了会有成本”。比如客服场景中AI 必须知道哪些售后退款政策是自己的知识盲区不能猜文档问答场景中模型对扫描件或混合排版内容理解不深时应明确低置信度并转人工内容审核辅助场景中风险判断不能直接下结论而是要输出“疑似”以及置信度交给审核员复核数据提取场景中识别结果不一致时应该标记为失败而不是硬给一个结果。也有明显不合适的场景。医疗诊断、法律结论、金融投资决策、司法量刑这类高风险应用即便模型给出了置信度 0.99也不能把最终决策权交给模型。不确定性推理可以暴露风险但不能消除风险。工程团队必须把“模型建议”和“业务决策”分开在流程上设置人工确认。另外如果任务本身就是开放创作、文案润色、灵感生成则不需要高精度置信度也不适合用拒绝回答策略打断创作过程。使用边界还包括数据合规。评测集如果包含用户真实对话、个人隐私、未授权商业数据需要在授权范围内使用。涉及人脸、声音、肖像和版权素材的任务要确认授权链条。公开发布 AI 生成结果时也要符合平台规则和法律要求。工程上除了功能正确性之外数据来源和输出用途都要留痕。3. 工程视角下的不确定性推理三个关键点不确定性和置信度是不同概念。不确定性描述模型对答案的把握程度可以是模型内部概率也可以是从多次生成结果计算出来的一致性置信度是模型对外输出的一个数值或文本表达。工程上不能只看模型自己说“我很有把握”更常见的是用以下三种方式做交叉验证。第一种是内部概率。某些接口会返回 token 级别的 logprobs把所有 token 概率累加或取平均能得到一个粗略置信度。缺点是很多模型会出现过度自信尤其在幻觉样本上概率反而偏高。第二种是多次采样一致性。同一问题在 temperature 大于 0 时采样多次如果答案不一致说明模型不稳定不确定性高。第三种是外部验证。用代码执行、搜索、数据库查询或规则校验去核对答案能直接消解不确定性而不是只评估不确定性。这三个关键点对应到落地动作内部概率用来做快速筛查多次采样一致性用来做稳健性评估外部验证用来做最终兜底。企业级系统通常不能只依赖其中一个。只靠概率会漏掉过度自信的幻觉只靠多次采样会增加成本和延迟只靠外部验证则会受限于工具覆盖面。正确的做法是把三者组合成一条分级处理管线。4. 环境准备与前置条件本文不针对某个具体开源项目所以环境给的是通用检查清单。请根据你自己使用的模型和接口平台做调整。模型访问方式远程 API 或本地部署推理服务只要能通过 HTTP 或 SDK 调用即可。Python 环境建议准备一个独立虚拟环境Python 版本以你使用的推理 SDK 要求为准常见 3.10 及以上。依赖库requests、openai如果用 OpenAI 兼容接口、pandas 或 csv 模块、json用于批量跑评测和记录结果。评测集准备 CSV 或 JSON 格式的问题列表包含题号、类型、问题、标准答案或参考答案必要时附带检索知识库内容。存储空间评测结果、日志、模型输出文件需要独立目录磁盘空间按评测集大小和输出长度估算。计算资源如果用本地模型需要足够的 GPU 显存和内存具体以模型权重显存需求为准如果调用远程 API对本地资源要求较低。网络与端口本地服务需要确认端口未被占用批量任务建议配置超时和重试机制。准备环境时先建目录结构把评测脚本、评测集、输出结果分开。这样后面批量跑任务、复盘失败样例都不用翻日志。# 通用目录结构按实际项目替换路径 mkdir -p ai-uncertainty-eval/{configs,datasets,outputs,logs}5. 搭建不确定性推理评测流程评测集质量直接决定评测结论是否可信。如果全是教科书常见题模型正确率高但不代表不确定性推理能力强如果全是极端偏题参考也不好定。建议按五类问题混合设计。常规题模型应该答对且高置信度用于验证基线能力。边界知识题模型可能只见过一部分同类问题用于考察是否误报高置信度。矛盾前提题问题本身存在逻辑矛盾或信息缺失好的模型应该指出问题而不是硬答。易混事实题相似数字、相似人名、相似时间用于考察细节区分能力。需要计算或查证题例如“某个模型在发布报告中报告了哪些关键参数”要求模型先检索再回答。有了评测集之后用脚本批量调用模型并把每次返回的答案、置信度、温度、采样次数、耗时记录下来。下面给一个通用模板实际接口字段和访问地址需要按你的模型服务调整。import json import time import requests # 以远程 API 为例实际地址、密钥和请求字段需要按服务商文档替换 MODEL_URL https://your-model-endpoint.example.com/v1/chat/completions API_KEY your-api-key def call_model(prompt: str, temperature: float 0.7) - dict: 调用模型返回答案文本、置信度、耗时。 headers {Authorization: fBearer {API_KEY}} payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: temperature, max_tokens: 512, } start time.time() resp requests.post(MODEL_URL, headersheaders, jsonpayload, timeout60) elapsed time.time() - start data resp.json() answer data[choices][0][message][content] # 如果接口提供了 token 概率或置信度字段在这里读取 confidence None return {answer: answer, confidence: confidence, elapsed: elapsed} def run_eval(dataset_path: str, output_path: str) - None: with open(dataset_path, r, encodingutf-8) as f: questions json.load(f) results [] for item in questions: prompt item[question] result call_model(prompt, temperature0.7) results.append({ id: item[id], type: item[type], question: prompt, answer: result[answer], elapsed: result[elapsed], }) with open(output_path, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: run_eval(datasets/eval_set.json, outputs/results.json)上面代码只是框架。真实运行时需要处理返回状态码异常、网络超时、限流、API key 失效。第一轮可以采用小评测集、每条问题只生成一次先跑通流程再放大规模。对评测结果逐条看能发现很多表面上看不见的问题比如同一题换一种说法模型就露怯或者模型对明显错误的事实依然给出高置信度。6. 置信度校准与多次采样单个回答的置信度不可靠工程上更稳妥的方式是多次采样。把同一个问题用 temperature 大于 0 的参数生成多次然后看答案是否一致。如果多次结果一致模型对这个问题的稳定性高如果同一问题生成出多个不同答案显然不该相信任何一条单独输出。下面给出一个最简单的多次采样一致性计算示例。import collections import json def compute_consistency(responses: list[str]) - dict: 根据多次采样结果计算一致性。 counts collections.Counter(responses) total len(responses) top_answer, top_count counts.most_common(1)[0] # 归一化文本后的一致性比例 consistency top_count / total return { top_answer: top_answer, top_count: top_count, total: total, consistency: consistency, distinct_answers: len(counts), } if __name__ __main__: samples json.load(open(outputs/samples.json, encodingutf-8)) for item in samples: result compute_consistency(item[responses]) print(item[id], result)一致性不是绝对标准。有些问题本来就有多个正确答案例如“列出三种常见激活函数”模型每次列出的不完全一样并不代表错误。所以评测集要区分“唯一答案题”和“开放答案题”。对唯一答案题一致性越低风险越高对开放答案题一致性低不一定有风险但仍需要检查语义重复和内容覆盖度。校准环节要观察的是“置信度 0.8 的题目实际答对比例是不是 80%”。做法是把评测结果按置信度分桶例如 0.0-0.1、0.1-0.2……0.9-1.0然后统计每个桶的真实正确率。如果高置信度桶的正确率明显低于置信度说明模型过度自信需要调低阈值或增加验证步骤如果低置信度桶的正确率也很高说明模型对自身能力判断偏低可能影响用户体验。整体校准结果可以用预期校准误差 ECE 这类指标衡量但面向业务汇报时分桶表比单一指标更容易被人理解。7. 降险策略从直接回答到验证后再回答评估完不确定性之后真正要落地的是一套降险策略。核心思路是根据置信度和风险等级决定走哪条路径。低风险问题可以直接回答中等置信度问题先检索再回答低置信度问题拒绝回答或转人工高风险问题无论如何都要外部验证。典型决策流程可以写成下面的伪代码def answer_with_risk_control(question: str, risk_level: str) - str: rough_confidence get_model_confidence(question) if risk_level high: # 高风险场景先检索、再生成、再人工审核 evidence retrieve(question) draft generate_with_evidence(question, evidence) return send_to_human_review(draft) if rough_confidence 0.3: return 我无法确认这个问题的答案建议查阅原始资料或咨询专业人员。 if rough_confidence 0.7: evidence retrieve(question) if evidence: return generate_with_evidence(question, evidence) return 当前资料不足以回答请稍后再试或补充信息。 return generate_direct_answer(question)这个流程是概念示例具体的函数需要接入你的知识库、搜索服务和业务审核系统。值得注意的一点是降险策略不是越多越好也不是拒绝回答越频繁越好。工程上要结合产品体验设定阈值过度拒绝会让用户觉得产品没用过度自信又会让错误答案流向用户。阈值需要根据业务风险承受能力反复调。这里还需要考虑“模型调用之外”的验证手段。对计算类问题让模型调用 Python 解释器完成算术而不是直接心算对事实类问题先把问题拆成检索词去知识库里找到原文后再回答对结构化数据问题要求模型输出 JSON 并由程序校验字段类型和取值范围。外部验证能用规则解决的就用规则不要让模型自己判断自己有没有错。8. 接口 API 与批量任务设计从工程落地看不确定性推理能力必须变成可重复、可批量、可监控的流程。建议把评测和管理封装成一个任务系统输入是问题集输出是结果、日志和统计报表。任务系统至少包含三个目录配置目录、输入目录、输出目录所有任务都记录开始时间、结束时间、成功失败状态。{ task_name: uncertainty_eval_round_1, model: your-model-name, temperature: 0.7, num_samples: 5, timeout_seconds: 60, max_retries: 2, risk_level: medium, input_file: datasets/eval_set.json, output_dir: outputs/round_1 }批量任务里最容易出问题的点是超时和限流。远程 API 在并发量大时会有速率限制本地模型在高并发下可能显存溢出或排队时间变长。建议给每次调用设置超时时间超时后重试最多两到三次如果重试仍失败把该任务标记为失败而不是跳过。批量任务最好支持断点续跑已经完成的结果不要重复调用模型节省成本。接口返回后要立即落盘不能只存在内存里避免进程崩溃后丢失全部结果。批量结果的审计日志要记录问题原文、模型答案、置信度数值或 logprobs、采样参数、检索命中的文档、最终是否触发降险策略、是否进入人工复核。有了这些字段才能复盘“哪类问题让模型高置信度出错”以及“降险策略有没有拦截住错误答案”。没有日志的不确定性评估结果基本不可信。9. 资源占用与性能观察不确定性推理不是免费的。多次采样、检索、工具调用都会增加延迟和成本观察性能时要放在真实业务链路里看。下面列出几个观察维度。推理次数同一问题采样 5 次模型推理次数就是原来的 5 倍延迟和成本都随之上升。温度大于 0 会显著影响连续输出降低并发或使用缓存可以缓解。上下文长度加入检索文档后输入 token 变多单次推理的显存占用和耗时都会增加批量任务总时长明显变长。工具调用搜索或代码执行的耗时通常远大于单次模型生成且不稳定网络波动会拉长任务时间。并发与排队本地模型在高并发下显存占用上升远程 API 有速率限制任务系统需要控制并发数。本地模型显存占用要按你使用的模型权重和上下文长度实测不同参数量的模型差异很大。建议先跑最小配置即单条问题、单次采样、无工具调用观察延迟和显存再把采样次数、上下文、工具调用逐步增加记录每一步的耗时变化。如果显存不足可以降低上下文长度、减小 batch、关闭并行推理、使用量化版本或者换远程 API。从成本角度看没必要对所有问题都做多次采样。可以先用单次生成拿到初步答案只有置信度处于中间区间的问题才触发多次采样或检索高置信度直接返回低置信度直接拒绝。这种分层设计能把性能开销集中在真正需要验证的问题上。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型对明显错误的事实给出高置信度模型内部概率过于自信查看该问题多次采样一致性对比真实正确率降低直接回答阈值改为先检索再回答置信度数值与真实正确率明显不一致校准偏移按置信度分桶统计正确率调整温度或对置信度做映射调整多次采样结果各不相同问题语义不够明确或模型不稳定检查题目措辞和开放性拆分问题明确约束或增加检索范围拒绝回答比例过高阈值设得太高统计各区间置信度分布调整阈值增加检索和工具验证API 调用超时或限流并发过大或网络不稳定查看响应状态码和日志降低并发、增加超时和重试、断点续跑批量任务卡住单条调用无超时或进程阻塞查看任务日志和当前进程为每次调用设置超时和最大重试次数检索后答案仍无改善知识库覆盖不足或检索词不对检查命中文档相关性优化检索词或引入更多数据源高风险问题仍直接透出错误结论决策流程未区分风险等级审查问题分级逻辑对高风险任务强制人工复核排查时先看日志再复现单条问题不要直接在批量任务里反复重试。好的做法是把失败样例沉淀成回归集每次修改策略后都跑一遍确保旧问题不复发。这会持续提升系统稳定性。11. 最佳实践与合规建议最后总结几条值得带进团队实践的工程建议。第一先搭小评测集。不要一上来就评测几千条问题先放 50 到 100 条典型问题把脚本和流程跑通再逐步扩展。第二置信度指标要落到业务含义上。告诉业务方“模型置信度 0.9但这个区间正确率只有 0.7”比只说“模型很自信”更有用。第三高风险任务必须留人工复核节点。AI 可以大幅提升效率但不能承担最终责任的转移。数据合规方面评测集如果来自真实用户对话、内部文档或第三方平台要确认是否具备使用和存储授权。涉及人脸、声音、肖像、版权作品和敏感个人信息时必须有合法来源和明确用途。生成内容的对外发布也要符合平台和行业规则。本地部署能把数据留在自己的环境里但模型权重本身也有授权范围不能随意跨场景商用。还要注意不要试图用不确定性推理功能去规避平台规则、绕过安全限制或生成违规内容。模型评估的目的是提升质量和降低风险不是在灰色地带寻找漏洞。如果某个任务在合规层面本身不能做那么无论模型置信度多高、降险策略多完善都不应该上线。12. 总结与下一步DeepMind 副总裁谈 AI 不确定性推理真正值得关注的是把“模型知不知道”变成工程上可评估、可干预、可复盘的系统能力。建议你从三个动作开始准备一份包含边界题和易幻觉题的小评测集跑一次批量脚本记录答案和置信度再算一次分桶校准结果。这套流程跑完你会比只聊“大模型很厉害”的人更清楚系统在哪些地方会犯错、什么情况下需要加检索或转人工。下一步可以从评测系统往下游走把不确定性信号接入业务规则引擎让低置信度回答自动转人工或回流到知识库建设。更长期的方向是用错误样本反向优化提示词、模型选择甚至知识库内容。这个环节没有终点但每多拦下一个高置信度错误系统就离“可信 AI”更近一步。值得收藏备用也值得在下个迭代里真跑一轮。