企业官网建设流程全解析

如果你问一名普通用户“AI 最大的问题是什么”，他大概率会说“AI 会一本正经地胡说八道”。但在 DeepMind 这类顶级实验室看来，这个问题有一个更严谨的技术名字：模型缺少对自身不确定性的表征能力。换句话说，模型不只是“回答错了”，更严重的是“它不知道自己在犯错，却表现得非常确信”。

DeepMind 高层在近年的多次公开讨论中反复提到同一个观点：如果大模型要在科学研究、代码生成、智能体调度、甚至医疗辅助这类高风险场景中真正落地，那么“懂得什么时候说自己不知道”可能比“答对更多题”更重要。这不是一种哲学式提醒，而是一个会直接决定系统可靠性的工程问题。

本文会先从概念上拆解“AI 不确定性推理”到底指什么，再结合大模型和 Agent 应用的实际场景，给出可以落地的处理思路。文章中会包含三个可运行的 Python 示例：不确定性校准评估、置信度温度缩放，以及 Agent 场景下的不确定性门控。读完你能得到两样东西：一套判断模型置信度是否可靠的思维框架，和一套可以在自己项目里跑起来的处理方案。

1. 这篇文章真正要解决的问题

先看一个非常典型的失败场景。你搭建了一个基于大模型的客服问答机器人，它在几百条测试问题上回答得都很流畅，几乎每一条都给出了自信满满的答案。上线后却发现，当用户问到知识库中没有覆盖的问题时，它不会回答“不知道”，而是会编造一个听起来合理的答案。这时你才意识到，问题不在提示词，也不在知识库覆盖度，而在模型根本没有“认知到自己不知道”的机制。

这是所有想把大模型从演示推向生产环境的人都会撞上的墙。过去几年，业界解决这个问题的主流手段是叠加 RAG、增加外部工具校验、做人工审核兜底。这些都有效，但它们都是在模型之外“强行纠偏”，而不是让模型在生成答案时就把不确定性考虑进去。

DeepMind 讨论不确定性推理时，强调的是另一层：让模型本身具备一种对“自己是否真的知道”的内部判断能力。说得直白一点，现在的大模型像是一台没有油量表的车，你永远不知道它下一秒会不会熄火；不确定性推理的目标，就是给这台车装上油量表、胎压监测和路线预判系统。

这篇文章适合四类读者：

• 正在把大模型接入真实业务系统的工程师，你更需要关注“置信度门控”和“人工兜底”的设计。
• 做模型评测和效果优化的算法工程师，你需要理解 ECE、温度缩放这些校准指标和手段。
• 研究 Agent、多步推理和工具调用的开发者，你需要重视“不确定性在长链路中会累积放大”的问题。
• 对 AI 技术趋势保持敏感的技术管理者，你可以从本文获得判断“模型是否可用”的工程视角。

2. 基础概念：不确定性、置信度与校准

2.1 不确定性的两种来源

在机器学习里，不确定性通常被分为两类，理解这个分类是后续所有讨论的基础。

第一类是偶然不确定性，英文叫 aleatoric uncertainty。它来自数据本身固有的随机性，比如“明天是否下雨”，无论你收集多少历史数据，都无法完全确定结果。这类不确定性无法通过增加知识来消除，只能尽量精确地估计概率。

第二类是认知不确定性，英文叫 epistemic uncertainty。它来自模型“不知道但误以为自己知道”的部分，比如一个只见过猫和狗的模型，你拿一张老虎的图片给它，它可能会信心满满地说是“猫”。这就是认知不确定性，它的成因是训练数据覆盖不足，或者模型本身的泛化能力不够。

DeepMind 在讨论 AI 不确定性时，重点关注的恰恰是认知不确定性。因为偶然不确定性可以被概率系统合理建模，而认知不确定性是大模型产生幻觉、过度自信、错误推理的主要根源。

2.2 置信度与校准的区别

很多开发者会把“置信度”和“校准”混为一谈，实际是完全不同的两个概念。

置信度是模型对某个预测结果的自信程度。比如分类模型输出“这张图是猫的概率是 0.9”，0.9 就是置信度。校准是衡量“置信度是否等于真实准确率”的指标。如果模型对所有输出 0.9 置信度的预测，真实正确率确实是 90%，那么这个模型就是校准良好的。

举个反例。一个模型在测试集上准确率达到 95%，但当它输出置信度 0.95 时，真实正确率只有 70%。这说明模型过度自信。更可怕的是，在很多大模型上，这类过度自信会集中在模型“编造内容”时，模型对幻觉内容的置信度甚至可能高于对正确答案的置信度。这就是为什么不能直接相信模型给自己打的分数，必须先做校准评估，再做校准修正。

2.3 DeepMind 为什么要强调不确定性

DeepMind 在 AlphaGo 时代就建立了对不确定性量化的使用习惯。AlphaGo 评估棋局时会同时给出胜率区间，而不是只给一个“我觉得能赢”的结论；AlphaFold 预测蛋白质结构时会输出每个残基的置信度分数(pLDDT)，研究者据此判断哪些结构预测是可靠的，哪些只是猜测。到了大模型时代，他们面对的问题更棘手：语言模型的输出是离散的、开放的、没有固定答案空间的，传统分类模型的校准方法不能直接搬过来。

所以 DeepMind 提出的方向更接近“让系统在推理过程中管理不确定性”，而不是仅仅在最终输出概率。这种思路对 Agent 应用尤其重要，因为 Agent 的每一次工具调用、每一步推理都在消费之前的不确定性判断，如果中间某一步过度自信，后续所有步骤都可能建立在错误基础上。

3. 大模型在身边的不确定性：从哪里来，藏在哪里

3.1 训练数据层面的不确定性

模型知道什么、不知道什么，本质上是训练数据决定的。当用户的问题落在训练数据覆盖充分的区域时，模型通常能给出准确回答；落在覆盖稀疏的区域时，模型就只能依靠内部插值猜一个答案。问题在于，用户无法直接看到“当前问题是否落在覆盖区域内”。

这就是为什么“模型会不会说不知道”如此重要。一个理想的模型应该具备这样的能力：输入一个问题，它内部先判断“这个问题我熟悉吗”，如果不熟悉，就明确表达不确定，而不是生硬地编一个答案。

3.2 推理过程层面的不确定性

即便模型“知识上知道”，推理过程也可能出错。尤其是面对数学题、逻辑推导、代码执行这类多步问题，模型每一小步都有出错概率，而整个链路的正确率会快速衰减：如果每一步正确率是 95%，10 步之后整体正确率就只有约 60%。

这里要注意一个反直觉现象：模型在推理过程的中间步骤，往往比最终答案更自信。它可能清楚地知道答案，但中间某一步已经推理错了。这就导致，只对最终答案做不确定性评估是远远不够的，必须对推理的中间状态也做监测。

3.3 Agent 长链路中的不确定性放大

在 Agent 场景中，问题会进一步恶化。一个 Agent 通常要经历“理解用户意图 -> 拆解任务 -> 调用工具 -> 读取结果 -> 生成最终答案”这样的链路。每一步都存在不确定性，而且误差会逐级传递。

比如一个智能客服 Agent，第一步把用户的问题理解偏了，第二步检索到的文档就是错的，第三步基于错文档生成的最终答案就会更离谱。而且每一步模型都有可能是自信的。DeepMind 强调的不确定性推理，在这种链路中对应的落地做法是：每一步都评估置信度，一旦某步置信度低于阈值，就及时切换策略，比如重新提问、换一个工具、直接转人工。

4. 工程实践中的不确定性处理：四个可落地的层级

理解了问题来源，就到了实操环节。我建议把不确定性处理拆成四个层级，从轻到重，企业可以根据自己的场景选。

4.1 第一层：提示词层的显式不确定性表达

最简单的方式，是在提示词里要求模型区分“事实”和“推理”。OpenAI、Anthropic 等多家机构的公开评测都显示，如果要求模型“不确定时直接说不知道，不要编造”，模型的幻觉率会有一定下降。这不算严格意义上的不确定性推理，但对很多业务场景是成本最低的改进。

你是一个严谨的技术助手。请根据以下规则回答用户问题： 1. 如果问题有明确事实依据，直接给出答案。 2. 如果问题存在多种可能解释，请列出所有可能性，并标注每种可能性的依据。 3. 如果问题超出你的知识范围，必须明确回答“我无法确认这一点”，不要尝试猜测。 4. 当你在推理过程中不确定某一步时，请单独说明“这里的判断置信度较低”。

这种写法的本质，是给模型一个“安全出口”。默认情况下，模型会被训练得尽可能迎合用户，倾向于给出完整答案；显式允许它“不确定”，可以减少一部分为了迎合而编造的动机。

4.2 第二层：概率输出层的置信度校准

如果模型本身能输出概率或 logits，就可以用温度缩放等方式做校准。温度缩放是经典的模型校准方法，思路很简单：训练一个温度参数 T，把 logits 除以 T 后再做 softmax，使得输出的概率分布更贴近真实准确率。如果 T 大于 1，则概率分布会被拉平，模型会变得更“谦虚”；如果 T 小于 1，模型会变得更“尖锐”。

不过要注意，大模型常见的 API 接口通常只返回 token 序列，不会暴露完整 logits。这种情况下可以使用替代方案，比如让模型生成多次并统计答案的一致性：同一个问题问 5 次，如果答案几乎一致，说明模型对这个问题较有把握；如果每次答案都不一样，说明模型在猜测。这种“采样一致性”方法不需要访问模型内部，是实际工程中最常用的技巧。

4.3 第三层：机制层的验证与工具辅助

比模型自身判断更可靠的方式，是引入外部验证机制。RAG 可以部分解决知识缺失问题，但它只能保证“引用了文档”，不能保证“文档内容正确”。此时可以增加权威来源比对，比如：

• 让模型回答时必须附上引用来源，再由业务规则校验来源是否存在和匹配。
• 对于数学计算，让模型先生成推理过程，再用一个独立的代码解释器执行关键步骤验证结果。
• 对于代码生成，直接运行生成的代码，用编译器或测试用例的返回结果判断是否正确。

这些机制的共同点是：不再依赖模型“自我感觉”，而是引入确定性工具来验证模型的输出。DeepMind 在很多场景下的做法也是类似的思路，用外部反馈信号来修正模型的不确定判断。

4.4 第四层：决策层的风险门控与人工兜底

这是最重要的一层。即使做了前面所有处理，模型在少数情况下仍然可能出错且自身没有察觉。所以生产系统必须设计一个决策层，在模型输出达到一定风险等级时，自动触发降级策略。比如置信度低于 0.6 时转人工，置信度介于 0.6 到 0.9 时二次校验，置信度高于 0.9 时直接输出。

这套“门控 + 人工兜底”的机制，才是企业可以接受大模型落地的原因。DeepMind 在讨论大模型应用时，反复强调的是“不要无条件信任模型的输出”，这句话落到工程上，就是这样的决策层代码。

5. 完整示例一：用 ECE 评估模型校准度

在动手改进之前，得先知道模型现在的校准情况有多糟。Expected Calibration Error（ECE，期望校准误差）是最常用的校准评估指标，它把模型输出概率分箱，然后对比每个箱子的平均置信度和真实准确率。ECE 越低，说明模型校准越好。

下面的示例使用 numpy 实现一个最小版 ECE 计算函数，不需要任何额外的机器学习库。

# 文件路径：calibration_eval.py import numpy as np def compute_ece(y_true, y_prob, n_bins=10): """ 计算 Expected Calibration Error。 参数: y_true: 真实标签数组，取值为 0 或 1 y_prob: 模型输出的正类概率数组，取值在 [0, 1] n_bins: 分箱数量 返回: ece: 期望校准误差 详细的分箱统计列表 """ bin_boundaries = np.linspace(0.0, 1.0, n_bins + 1) ece = 0.0 bin_stats = [] total_samples = len(y_true) for i in range(n_bins): # 当前分箱内的样本索引 if i == n_bins - 1: mask = (y_prob >= bin_boundaries[i]) & (y_prob <= bin_boundaries[i + 1]) else: mask = (y_prob >= bin_boundaries[i]) & (y_prob < bin_boundaries[i + 1]) bin_count = np.sum(mask) if bin_count == 0: continue # 箱内平均置信度 avg_conf = y_prob[mask].mean() # 箱内真实正例比例，即实际准确率 avg_acc = y_true[mask].mean() # 按样本占比加权 weight = bin_count / total_samples ece += weight * abs(avg_conf - avg_acc) bin_stats.append({ "bin": i, "sample_count": int(bin_count), "avg_confidence": round(float(avg_conf), 4), "avg_accuracy": round(float(avg_acc), 4), "gap": round(float(abs(avg_conf - avg_acc)), 4) }) return ece, bin_stats # 模拟一组数据：真实标签 + 模型预测概率 np.random.seed(42) n = 1000 y_true = np.random.randint(0, 2, size=n) y_prob = np.clip(y_true + np.random.normal(0, 0.25, size=n), 0.01, 0.99) ece, stats = compute_ece(y_true, y_prob) print(f"整体 ECE: {ece:.4f}") print("\n分箱统计:") for s in stats: print(s)

这段代码的核心逻辑是按概率区间分箱。正常来说，如果模型校准良好，那么“预测概率 0.8 的样本”中应该有大约 80% 是正例。如果模型预测 0.8 的样本中只有 60% 是正例，说明模型过度自信，ECE 会相应变大。

运行这个脚本后，你会看到类似这样的输出：

整体 ECE: 0.0334 分箱统计: {'bin': 0, 'sample_count': 0, 'avg_confidence': 0.0, 'avg_accuracy': 0.0, 'gap': 0.0} {'bin': 1, 'sample_count': 4, 'avg_confidence': 0.11, 'avg_accuracy': 0.25, 'gap': 0.14} {'bin': 2, 'sample_count': 12, 'avg_confidence': 0.23, 'avg_accuracy': 0.33, 'gap': 0.10} ...

由于上面的示例数据是人为模拟生成的，实际数值每次运行会略有差异。你要关注的是每个箱子中的 gap 列：gap 越大，说明模型在该区间内的置信度越不靠谱。如果 gap 普遍超过 0.1，就说明模型需要做校准处理。

6. 完整示例二：用温度缩放校准模型置信度

当你通过 ECE 确认模型校准不佳之后，下一步就是做校准。温度缩放是应用最广的方法，它的好处是只需要一个参数，不容易过拟合，而且实现成本很低。

温度缩放的核心思想是：在 softmax 之前把 logits 统一除以一个温度系数 T。T 越大，输出的概率越平滑，模型的最高置信度越低；T 越小，则概率分布越尖锐。训练时用验证集进行优化，目标是找到让交叉熵损失最小的 T。

下面使用 PyTorch 实现温度缩放。

# 文件路径：temperature_scaling.py import torch import torch.nn.functional as F class TemperatureScaler: """ 温度缩放校准器。 用法： 1. 收集验证集上的 logits 和真实标签 2. 调用 fit() 学习最优温度参数 3. 调用 calibrate() 对新的 logits 应用温度缩放 """ def __init__(self, max_iter=100, lr=0.01): self.T = torch.tensor(1.0, requires_grad=True) self.max_iter = max_iter self.lr = lr def fit(self, logits_val, labels_val): """ 在验证集上学习温度参数。 logits_val: shape = [N, num_classes]，模型输出的 logits labels_val: shape = [N]，真实类别索引 """ logits_val = torch.tensor(logits_val, dtype=torch.float32) labels_val = torch.tensor(labels_val, dtype=torch.long) def loss_fn(): # 除以温度后的交叉熵损失 loss = F.cross_entropy(logits_val / self.T, labels_val) return loss optimizer = torch.optim.LBFGS([self.T], lr=self.lr, max_iter=self.max_iter) def closure(): optimizer.zero_grad() loss = loss_fn() loss.backward() return loss optimizer.step(closure) return self.T.item() def calibrate(self, logits): """ 对新的 logits 应用温度缩放，返回概率分布。 """ logits_tensor = torch.tensor(logits, dtype=torch.float32) calibrated_probs = F.softmax(logits_tensor / self.T, dim=-1) return calibrated_probs.numpy() # 模拟一个三分类问题 torch.manual_seed(0) n_val = 500 n_classes = 3 # 随机生成 logits 和标签（仅为演示代码路径） logits_val = torch.randn(n_val, n_classes) labels_val = torch.randint(0, n_classes, (n_val,)) scaler = TemperatureScaler() temperature = scaler.fit(logits_val.numpy(), labels_val.numpy()) print(f"学习到的温度参数 T = {temperature:.4f}") # 对新的 logits 做校准 new_logits = torch.randn(10, n_classes) probs = scaler.calibrate(new_logits.numpy()) print("\n校准后的概率分布（每行之和为 1）:") print(probs)

运行后你可能得到一个大于 1 的温度值，这意味着验证集上的模型原始输出过于尖锐，校准会拉平概率分布。如果 T 接近 1，说明模型本身已经校准较好，不需要大幅调整。

这里要特别提醒：在大模型 API 场景中，你通常拿不到 logits，只能拿到 token 字符串。这时无法直接使用温度缩放，但可以用一个替代策略：让模型生成多次，统计多个答案的 token 级相似度来近似置信度。如果多次生成结果高度一致，就认为置信度较高；如果每次生成差别很大，就认为模型在不确定地猜测。这种方法虽然粗糙，但在没有内部 logits 的情况下是工程上唯一可行的近似方案。

7. 完整示例三：Agent 场景下的不确定性门控

前两个示例是在单次模型预测层面做处理，Agent 场景则需要把不确定性意识嵌入到每一步工具调用和分支决策中。

下面是一个简化版的高风险 Agent 框架。它的思路是：每执行一步，都计算当前置信度，如果置信度低于门限，就停止继续执行，转人工或请求用户澄清。

# 文件路径：agent_uncertainty_gate.py from dataclasses import dataclass from typing import Callable, Optional @dataclass class StepResult: """Agent 中一步执行的结果。""" content: str confidence: float # 当前步骤的置信度，范围 [0, 1] needs_human: bool = False # 是否需要人工介入 metadata: Optional[dict] = None class UncertaintyAwareAgent: """ 带不确定性门控的 Agent。 实际使用时，需要把 llm_call 和 tool_call 替换成 你自己的大模型调用和工具调用实现。 """ def __init__(self, llm_call: Callable[[str, Optional[str]], StepResult], tool_call: Callable[[str], StepResult], confidence_threshold: float = 0.7): self.llm_call = llm_call self.tool_call = tool_call self.confidence_threshold = confidence_threshold def _should_stop(self, step_result: StepResult) -> bool: """ 判断当前步骤是否需要停止： 1. 步骤本身标记需要人工介入 2. 置信度低于阈值 """ if step_result.needs_human: return True if step_result.confidence < self.confidence_threshold: return True return False def run(self, user_question: str) -> StepResult: # 第一步：理解用户意图 intent_result = self.llm_call( f"请拆解用户意图：{user_question}", prompt_type="intent" ) if self._should_stop(intent_result): # 意图不明确时，直接请求用户澄清，而不是硬着头皮执行 return StepResult( content="我不确定您的具体需求，能否再补充一些信息？", confidence=intent_result.confidence, needs_human=True, metadata={"stage": "intent", "reason": "low_confidence"} ) # 第二步：根据意图调用工具 tool_result = self.tool_call(intent_result.content) if self._should_stop(tool_result): # 工具返回结果不可靠时，转人工复核 return StepResult( content="初步判断需要人工协助处理，请稍候。", confidence=tool_result.confidence, needs_human=True, metadata={"stage": "tool", "reason": "tool_low_confidence"} ) # 第三步：生成最终答案 answer_result = self.llm_call( f"基于工具结果回答问题：{tool_result.content}", prompt_type="final_answer" ) if answer_result.confidence < self.confidence_threshold: # 最终答案置信度低时，给出带保留的回答 return StepResult( content="以下信息可能不完全准确，建议人工确认：" + answer_result.content, confidence=answer_result.confidence, needs_human=True, metadata={"stage": "final", "reason": "answer_low_confidence"} ) return answer_result # 演示用法 def fake_llm(prompt: str, prompt_type: str = "intent") -> StepResult: # 这里应该替换成真实的大模型调用 # 示例中直接返回固定值，方便你理解框架设计 if prompt_type == "intent": return StepResult(content="查询天气", confidence=0.95) elif prompt_type == "final_answer": return StepResult(content="杭州明天多云，气温 22-28 度", confidence=0.55) return StepResult(content="", confidence=0.0) def fake_tool(query: str) -> StepResult: # 这里应该替换成真实的工具调用 return StepResult(content="杭州 明天 多云 22-28 度", confidence=0.80) agent = UncertaintyAwareAgent( llm_call=fake_llm, tool_call=fake_tool, confidence_threshold=0.7 ) result = agent.run("杭州明天天气怎么样？") print(f"最终回答：{result.content}") print(f"置信度：{result.confidence:.2f}") print(f"需要人工介入：{result.needs_human}")

在这个示例里，意图识别步骤置信度 0.95，通过了门槛；工具调用步骤置信度 0.80，也通过了；但最终答案置信度只有 0.55，低于 0.7 的门限，于是 Agent 自动给回答加上了保留说明，并标记为需要人工介入。

真实的 Agent 中，llm_call 应该从模型服务获取结果，同时通过多次采样一致性或者模型自带的置信度接口得到置信度。tool_call 则可以结合工具自身的返回状态来设置置信度。这个框架的关键思想是：任何一步的不确定性都不能被忽略，链路中只要有一环置信度过低，整个任务就应该降级处理。

8. 常见问题与排查思路

在实际落地不确定性机制时，开发者会遇到一些典型问题，我来整理成排查清单。

9. 最佳实践与工程建议

9.1 先定义“多低算低”

置信度阈值不能拍脑袋定。不同业务场景对错误容忍度完全不同：垃圾邮件分类器即使把 5% 的正常邮件误判为垃圾，也可以接受；但一个药物剂量推荐系统，1% 的错误都是事故。我的建议是：先统计你当前系统的错误分布，再反推阈值。比如你统计发现模型输出置信度低于 0.6 时，正确率只有 68%，而业务要求是 95%，那阈值至少设在 0.6 以上。

9.2 校准数据要与任务分布一致

很多团队会用通用评测集做校准，再直接部署到业务场景，这是错误做法。校准本质上是在拟合“置信度到准确率”的映射，这个映射依赖数据分布。通用数据上学到的温度参数，换到垂直领域后可能完全失效。正确流程是：收集业务真实流量中的问题样本，人工标注后，用这部分数据重新做校准评估和温度学习。

9.3 给不确定性留足日志

生产环境中一定要记录每一步推理的置信度、采用的策略、是否触发门控。这不仅仅是排查问题的需要，更是后续优化校准模型的数据资产。我见过不少团队上线了不确定性门控，却因为没留日志，出了问题只能猜原因。建议在 Agent 框架中，把 step 的 metadata 字段完整记录到日志系统。

9.4 从轻到重逐步落地

不要一开始就追求复杂的贝叶斯神经网络或完整的概率编程。先用提示词约束，再上采样一致性评估，然后做温度缩放，最后叠加 Agent 门控。这套路径每走一步都能获得明确的收益，而且不会对现有系统产生破坏性改动。如果某一步做完效果已经满足业务要求，就不需要继续往下做复杂度更高的方案。

9.5 不要试图消除不确定性，要管理不确定性

这是 DeepMind 讨论中我认为最有价值的一句话：不确定性是客观存在的，模型不可能变成全知全能。工程系统的目标不是让模型“永远正确”，而是让正确的部分被信任，错误的可能被识别，不确定的地方被降级给人类处理。这句话应该成为所有 AI 产品设计的默认原则。

10. 下一步演进：从指令学习到不确定性原生模型

如果你把本文介绍的方法都落地了，你的系统已经比绝大多数大模型应用更可靠。但我们也必须承认，提示词、温度缩放、Agent 门控都是“事后补救”，真正的改变应该发生在模型训练阶段。

从 DeepMind 的讨论和行业公开研究看，有三个演进方向值得持续跟踪。第一是在后训练阶段加入校准约束，让模型在 RLHF 或偏好优化过程中不仅学习“什么是对的”，也学习“什么时候不确定”。第二是奖励模型层面的不确定性感知，让奖励模型对高风险输出给出更保守的评分。第三是给模型引入更多工具反馈信号，让模型通过实际执行结果来修正自己的置信度，这相当于让模型在推理时像人一样“验证一遍再做判断”。

对普通开发者来说，现在无需等到这些研究方向成熟。你可以从本文的示例代码开始，先用采样一致性加上置信度门控，把自己的 AI 系统做得更可信。当你有了一定数据积累后，再把这套机制持续迭代优化。AI 的不确定性永远存在，但作为工程师，我们至少可以让它在系统中变得可见、可度量、可控制。