企业官网建设流程全解析

做 AI 应用开发的同学可能都有过这种体验：大模型在对话里回答问题特别笃定，语气自信，甚至会把错误信息叙述得有理有据。可一旦把它放到医疗辅助、金融风控、企业知识库问答这类真实业务场景里，这种“盲目的自信”就会变成隐患。最近 DeepMind 副总裁公开讨论了 AI 不确定性推理这个话题，又把“模型如何知道自己不知道”推到了技术圈的讨论中心。

这篇文章不打算只做观点解读，而是把话题拆成一条可学习、可落地的技术脉络：先从概念入手讲清楚什么是不确定性推理，再补充概率与熵的基础知识，然后给出语言模型和 AI Agent 项目里常见的实现思路，最后用一个带决策层的问答系统案例，演示如何把“不确定性”变成产品能力。

适合以下读者阅读：

• 正在用大模型做业务系统，却不知道如何判断模型输出可不可信的开发者。
• 想入门 AI Agent、RAG 应用，但对置信度、熵、校准等概念比较陌生的同学。
• 需要把 AI 能力接入生产环境，同时又担心幻觉、误判、失控的工程师。

读完你会掌握：不确定性推理要解决什么问题、有哪些可操作的实现手段、如何在项目里设计一套“不确定就转人工/触发检索”的兜底机制，以及工程落地时需要注意的坑。

1. 从 DeepMind 的讨论说起：为什么不确定性突然成了焦点

1.1 一个被忽略的问题：模型不知道自己不知道

传统软件系统的行为是确定的：条件成立就走这个分支，条件不成立就走另一个分支。开发者在写代码时，可以精确预判系统在什么输入下会给出什么输出。

大模型不一样。它本质上是基于海量文本训练的概率模型，生成每个 token 时都在做概率采样。它给出的答案只是“在当前参数和上下文下，概率上比较合理的延续”，并不代表事实判断。更关键的是，模型在训练过程中没有学过“如何表达自己的无知”，它只知道根据分布生成文本。

于是出现了一个典型的工程矛盾：模型并不知道自己给出的答案是否正确，但用户和业务系统默认它是正确的。一旦模型把幻觉内容以高置信度的方式输出，系统的可靠性就会大打折扣。

DeepMind 团队讨论不确定性推理，本质上是在回应这个问题：如果模型能对自身的判断给出一个可靠的不确定性估计，应用层就可以用它做风险控制。

1.2 不确定性推理不是让 AI“变笨”

有人在第一次接触这个概念时，会误以为不确定性推理就是让模型多回答“我不知道”。这是一种比较片面的理解。

让模型说“我不知道”，只是不确定性推理的一种外在表现。更核心的工作是：让系统能够量化自己的认知边界，并在不确信时改变行为。比如：

• 如果模型对答案的置信度低于阈值，就触发知识库检索。
• 如果多次推理结果互相矛盾，就转给人工处理。
• 如果分类概率分布比较平坦，就输出多个候选结果供用户选择。
• 如果 Agent 对当前工具调用结果没有把握，就放弃执行高风险动作。

换句话说，不确定性推理解决的不是“模型会不会错”，而是“系统在模型可能出错时，如何提前感知并做出安全反应”。

1.3 哪些场景最需要不确定性推理

从工程角度看，以下几类场景对不确定性推理的需求最迫切：

这些场景的共性是：错误成本高，且不能通过简单增加数据彻底消除错误。系统要做的是在错误发生之前，对“不确定性”建立感知和应对机制。

2. 先厘清概念：偶然不确定性 vs 认知不确定性

2.1 两种不确定性的定义

在机器学习里，不确定性一般被分为两类：

偶然不确定性（Aleatoric Uncertainty）

指数据本身固有的随机性。比如抛硬币的结果、传感器噪声、用户行为的随机波动。这类不确定性不会因为收集更多数据而消失，只能通过概率模型去刻画它。

认知不确定性（Epistemic Uncertainty）

指模型因为知识不足而产生的认知盲区。比如模型没见过某种数据分布、训练语料过时、上下文信息太少。这类不确定性可以通过增加数据、扩充知识、改进模型来降低。

这两种区分的价值在于：当系统判断出不确定性主要来自认知层面时，可以通过检索知识、访问数据库、询问用户来补救；如果不确定性主要来自数据本身的随机性，那再多的知识补充也无法消除，系统应该谨慎决策而不是盲目追问。

2.2 用天气预报理解两类不确定性

以天气预报为例：

• 假设我们拥有非常完整的气象数据和精细的模型，仍然无法百分之百确定明天是否下雨，因为大气系统本身存在随机扰动。这是偶然不确定性。
• 如果模型只在热带地区的数据上训练过，现在要预测寒带城市的天气，那么模型对“降雪概率”的判断会非常不靠谱。这是认知不确定性。

理解这个区别后，在 AI 应用设计时就会有一个清晰的思路：先判断模型的不确定来自哪里，再决定用哪种策略去应对。

2.3 和大模型落地有什么关系

大模型场景下的不确定性来源很多，可以按下面这个思路归类：

• 训练语料覆盖不足：模型对某些小众领域、新知识、特定格式的输入了解不够，回答容易失真。这属于认知不确定性。
• 上下文信息缺失：用户只给了一个模糊的问题，没有提供足够条件，模型只能在多个可能答案里猜。这既是认知不确定性，也带有偶然性。
• 生成过程的随机性：采样温度较高时，同一个问题可能得到不同的回答。这是生成机制带来的随机性，本质上更接近偶然不确定性。

当我们说“要为大模型系统增加不确定性推理”时，其实是希望系统能把上面这些来源的信号综合起来，输出一个可供上层决策使用的置信度。

3. 数学基础：概率、熵与模型校准

3.1 从贝叶斯公式理解不确定性更新

贝叶斯公式是不确定性推理最基础的工具：

P(A|B) = P(B|A) * P(A) / P(B)

它的含义是：在看到新证据 B 之前，我们对 A 有一个先验概率 P(A)；看到 B 之后，通过似然 P(B|A) 更新为后验概率 P(A|B)。

这个思路在 AI 系统里非常实用。例如一个 Agent 接到用户问题后，可以先根据历史数据给出一个初始答案分布，再通过检索到的知识库片段更新答案分布。如果新证据和先验答案一致，置信度上升；如果矛盾，置信度下降。

很多生产系统在做“检索增强生成”时，实际上就在做类似的更新：先用检索结果降低模型对未知知识的认知不确定性，再让生成模型基于更充分的上下文作答。

3.2 用熵度量“有多不确定”

有了概率分布之后，需要用一个标量来量化不确定程度。最常用的指标是信息熵：

H(p) = -Σ p(x) · log p(x)

熵越大，说明概率分布越平缓，系统对答案越不确定；熵越小，说明概率集中在某个类别或某个答案上，系统越确定。

分类场景中最直接的例子：

• 概率分布是 [0.98, 0.01, 0.01]，熵很小，模型基本确认答案属于第一类。
• 概率分布是 [0.34, 0.33, 0.33]，熵很大，模型完全无法区分三类，这时直接输出最高概率的类别就很危险。

下面这段代码演示了如何计算 softmax 概率、熵和最大概率。这是做不确定性判断时最基础的工具。

# uncertainty_basics.py import numpy as np def softmax(logits: np.ndarray) -> np.ndarray: # 减去最大值做数值稳定处理，避免 exp 溢出 max_logit = np.max(logits) exp_logits = np.exp(logits - max_logit) return exp_logits / np.sum(exp_logits) def distribution_entropy(probs: np.ndarray) -> float: # 计算概率分布的熵，概率夹紧到极小值防止 log(0) probs = np.clip(probs, 1e-12, 1.0) return -float(np.sum(probs * np.log(probs))) # 模拟模型输出的 logits logits = np.array([2.0, 1.0, 0.1]) probs = softmax(logits) print("softmax 概率:", np.round(probs, 4)) print("分布熵:", round(distribution_entropy(probs), 4)) print("最大类概率:", round(np.max(probs), 4))

运行结果：

softmax 概率: [0.659 0.243 0.098] 分布熵: 0.8159 最大类概率: 0.659

如果把 logits 改成 [0.0, 0.0, 0.0]，三个类别的概率会非常接近，熵也会显著变大。这时候就不建议直接把最高概率的类别作为最终答案。

3.3 校准：置信度 70% 的时候，正确率是否接近 70%

熵和最大概率可以衡量“模型自己觉得有多确定”，但这里还有一个重要问题：模型的自信程度和真实正确率是否匹配？

这就涉及到校准（Calibration）。校准良好的系统应该满足：当模型预测置信度为 0.7 时，这类样本的真实正确率也接近 70%。如果模型对所有样本都给出 0.99 的置信度，但真实正确率只有 70%，那就是典型的过度自信。

常用的评估指标是期望校准误差（ECE）。计算思路是：把置信度分成多个区间，统计每个区间内模型平均置信度与真实准确率的差值，再按样本数量加权平均。

# calibration_demo.py import numpy as np def expected_calibration_error(confidences, correct, n_bins=10): """ confidences: 模型对每个样本给出的置信度 correct: 每个样本是否预测正确，用 0/1 表示 """ bins = np.linspace(0.0, 1.0, n_bins + 1) ece = 0.0 total = len(confidences) for i in range(n_bins): in_bin = (confidences > bins[i]) & (confidences <= bins[i + 1]) if np.sum(in_bin) == 0: continue bin_conf = np.mean(confidences[in_bin]) bin_acc = np.mean(correct[in_bin]) # 该区间样本数 / 总样本数 * |置信度 - 准确率| ece += np.sum(in_bin) * abs(bin_conf - bin_acc) / total return ece # 模拟数据：模型整体偏乐观 confidences = np.array([0.95, 0.92, 0.88, 0.75, 0.70, 0.60, 0.55, 0.45, 0.40, 0.30]) correct = np.array([1, 1, 0, 1, 0, 1, 0, 1, 0, 0]) print("ECE:", round(expected_calibration_error(confidences, correct), 4))

ECE 越低，说明模型的置信度越可信。实际项目中，我们可以用验证集持续监控这个指标，当 ECE 明显偏高时，就要考虑对模型做温度缩放，或者在决策层引入更保守的策略。

3.4 为什么工程上要同时关注“概率”和“校准”

只看 logits 或概率是不够的。一个没有经过校准的模型，哪怕 softmax 输出 0.95，真实准确率也可能只有 60%。只看“熵”也不够，因为熵描述的是模型内部的不确定性，并不等于事实层面的可靠性。

正确做法是把两个层面同时纳入系统：

• 概率层面：用熵、最大概率、多次采样一致性作为实时不确定信号。
• 校准层面：用 ECE 等指标在离线阶段评估模型置信度是否可靠，并据此设置合理阈值。

4. 语言模型和 AI Agent 里的不确定性推理思路

4.1 读取模型输出的概率信息

在实际项目中，获取不确定性信号的第一个入口是模型自身的概率输出。

如果是分类任务，可以直接读取每个类别的概率，或者读取最后一个分类层的 logits，再通过 softmax 得到分布。这是成本最低的方式。

如果是生成任务，情况会复杂一些。生成文本时会为每个 token 产生一个概率分布，但我们最终关心的是整段答案的可信度。比较简单的办法是取所有 token 概率的平均值或几何平均值，但这样只能反映“生成过程是否顺畅”，不能完全反映“答案是否符合事实”。

一个常见误区是：把文本生成过程中的高概率当成答案正确。实际上，模型可以非常流畅、非常自信地生成一段完全错误的内容。因此生产系统不能只依赖 token 概率。

4.2 多次采样与语义熵

对于开放生成任务，更稳妥的思路是多次采样。

让模型在较高 temperature 下对同一个问题生成 N 个回答，然后度量这些回答之间的语义一致性。如果 N 个回答在语义上高度一致，说明模型对答案相对确定；如果回答之间分歧很大，说明模型并没有形成稳定判断。

这里需要注意，不能直接比较文本是否完全相同，而应该做语义相似度比较。可以用编辑距离、BLEU、向量余弦相似度等方法。下面用一个简化版本的示例来演示核心思路。

# semantic_entropy_demo.py from difflib import SequenceMatcher import numpy as np responses = [ "今天上海会下雨，建议带伞。", "今天上海有降雨，最好带伞。", "今天上海不会下雨，不用带伞。" ] def similarity(a: str, b: str) -> float: # 简化用字符序列相似度，实际项目中可用 embedding 余弦相似度 return SequenceMatcher(None, a, b).ratio() def pairwise_similarity(responses): n = len(responses) matrix = np.zeros((n, n)) for i in range(n): for j in range(n): matrix[i][j] = similarity(responses[i], responses[j]) return matrix sim_matrix = pairwise_similarity(responses) print("回答两两相似度矩阵:") print(np.round(sim_matrix, 2)) print("平均相似度:", round(float(sim_matrix.mean()), 2))

运行结果：

回答两两相似度矩阵: [[1. 0.68 0.24] [0.68 1. 0.2 ] [0.24 0.2 1. ]] 平均相似度: 0.53

平均相似度只有 0.53，提示模型对这个问题没有形成一致答案，系统应该触发兜底策略。如果三次回答都非常相似，平均相似度接近 1.0，系统就可以相对放心地直接返回。

实际生产中，通常会使用 embedding 模型计算向量余弦相似度，比字符相似度更稳健。这里用 SequenceMatcher 只是为了演示流程，不依赖外部模型。

4.3 让模型显式给出置信度

另一种实现思路是修改 Prompt，让模型在回答内容之外，额外输出一个 0 到 1 的置信度。例如：

请回答下面的问题。回答结束后，另起一行输出你对答案的置信度，范围 0 到 1，只输出数字。 问题：上海明天会下雨吗？

这种方式的优点是简单直接，缺点是模型口头报出的置信度往往校准得很差。在温度较高时，让它输出 0.9，它可能依然给出错误答案。所以，Prompt 自报置信度更适合作为辅助信号，不能作为唯一的决策依据。

如果想更可靠，可以把自报置信度和多次采样结果结合起来：如果模型自报置信度低，或者多次采样结果不一致，只要有一个信号异常，系统就进入降级处理。

4.4 Agent 策略：不确定就调用工具

在 AI Agent 场景里，不确定性推理不只是用来判断“要不要拒绝回答”，还可以驱动 Agent 的行为。

一个比较常用的策略是“不确定性驱动的工具调用”：

• Agent 收到用户指令。
• 先在大模型内部生成一个初步方案。
• 如果方案对应的置信度偏低，Agent 不直接执行，而是先检索知识库、查询数据库、调用搜索接口。
• 工具结果返回后，根据新证据更新置信度，再决定是否继续执行。

举个例子，用户让 Agent“把上周的订单汇总发到邮箱”。Agent 如果能明确找到上周订单数据，置信度较高，可以直接执行；如果它对时间范围、订单状态、收件人邮箱存在多种理解，就应该先向用户确认，而不是贸然发邮件。

这种机制本质上把不确定性推理变成了系统的“安全阀”：宁可多问一次，也不在模糊状态下执行高风险操作。

5. 实战：给 QA 系统加上“不确定性决策层”

5.1 场景与目标

假设有一个企业知识库问答系统，用户会问关于订单、物流、售后等问题。系统内部使用一个大模型生成答案。

目前的痛点是：模型遇到知识库没覆盖的问题时，会编造一个看似合理的回答。现在我们要增加一个“不确定性决策层”，让系统在不确定时自动选择：

1. 直接回答。
2. 多次采样后给出多数答案。
3. 转人工或触发知识库检索。

目标不是让模型永不犯错，而是让错误发生在可控范围内。

5.2 决策流程设计

决策流程可以设计成下面几步：

第一步，模型对问题生成初始答案，同时得到一组 logits。

第二步，根据 logits 计算熵。如果熵低于阈值，说明模型对答案比较确定，直接返回。

第三步，如果熵高于阈值，模型进入多次采样模式。设置较高 temperature，生成多个答案。

第四步，计算多次采样答案之间的语义一致性。如果一致性较高，则选择出现频率最高的答案；如果一致性很低，则转人工或触发检索。

这里把熵作为第一道门槛，把多次采样一致性作为第二道门槛。两道门槛都通过，才认为答案可靠。

5.3 完整代码实现

下面这段代码是完整可运行的最小示例。为了不依赖具体大模型 API，我用随机函数模拟模型输出，核心决策逻辑可以直接迁移到真实项目。

# uncertain_qa_demo.py import numpy as np from collections import Counter def softmax(logits: np.ndarray) -> np.ndarray: max_logit = np.max(logits) exp_logits = np.exp(logits - max_logit) return exp_logits / np.sum(exp_logits) def distribution_entropy(probs: np.ndarray) -> float: probs = np.clip(probs, 1e-12, 1.0) return -float(np.sum(probs * np.log(probs))) def simulate_model_answer(question: str, seed: int = 0): """ 模拟模型返回答案和 logits。 真实项目中，这里替换成 LLM API 调用即可。 """ rng = np.random.default_rng(seed) answers = [ "订单会在 24 小时内发货。", "订单预计明天发出。", "我无法确定订单状态，请联系人工客服。" ] logits = rng.normal(size=len(answers)) probs = softmax(logits) idx = int(np.argmax(probs)) return answers[idx], probs def run_decision(question: str, entropy_threshold: float = 1.0, max_samples: int = 5): """ 带不确定性决策层的问答流程 """ # 第一轮：直接生成答案，计算熵 answer, probs = simulate_model_answer(question, seed=0) ent = distribution_entropy(probs) if ent < entropy_threshold: return { "answer": answer, "strategy": "直接回答", "entropy": round(ent, 4), "samples": None } # 低置信度时多次采样 sample_answers = [] for i in range(max_samples): ans, _ = simulate_model_answer(question, seed=i) sample_answers.append(ans) counter = Counter(sample_answers) most_common_ans, most_common_cnt = counter.most_common(1)[0] # 如果多数答案占比超过 60%，认为是稳定答案 if most_common_cnt / max_samples >= 0.6: final_answer = most_common_ans strategy = "多次采样后回答" else: final_answer = "需要转人工，或触发知识库检索" strategy = "转人工/检索" return { "answer": final_answer, "strategy": strategy, "entropy": round(ent, 4), "samples": sample_answers } # 运行示例 result = run_decision("我的订单什么时候发货？") print("最终回答:", result["answer"]) print("使用策略:", result["strategy"]) print("第一轮熵值:", result["entropy"]) if result["samples"]: print("多次采样结果:") for s in result["samples"]: print(" -", s)

5.4 运行结果与分析

由于使用了随机数模拟，每次运行结果会略有不同。但决策逻辑是稳定的：

• 如果第一轮熵比较低，系统直接回答，延迟最低。
• 如果熵较高，系统自动进入多次采样模式。
• 多次采样后如果答案一致，返回多数答案；如果答案分散，转人工或触发知识库检索。

这个流程最大的好处是：把“模型是否可信”的判断从用户侧转移到了系统侧。用户可能无法分辨模型答案的真假，但系统可以通过概率和一致性信号提前识别高风险输出。

5.5 如何迁移到真实 LLM 项目

把这个示例迁移到真实项目时，需要做几处关键替换：

第一，simulate_model_answer函数替换成真实模型调用。对于 OpenAI 兼容接口，可以传入 temperature 参数实现不同采样；对于开源模型，可以直接修改采样参数。

第二，logits 不一定总是能拿到。如果接口不提供 logits，可以用多次采样的平均置信度来代替第一轮熵判断。

第三，文本相似度建议使用 embedding 模型计算余弦相似度，而不是字符相似度。字符相似度对中文同义表达不敏感，意思是相近但写法不同的句子可能被误判为不一致。

第四，阈值需要根据实际数据调参。可以用一批历史问题做验证，统计不同阈值下的转人工率、误判率和延迟，选择业务上可接受的平衡点。

6. 常见误区与排查清单

6.1 常见误区

不确定性推理听起来简单，实际落地时容易踩坑。这里整理几个常见误区。

第一个误区是把“模型说不知道”等同于“系统处理了不确定性”。很多模型在 Prompt 引导下会说“我不确定”，但这只是表面行为，系统并没有量化不确定性。如果后续决策仍然依赖最高概率答案，那“我不知道”只是一句空话。

第二个误区是只看熵不看校准。熵低只能说明模型内部概率分布集中，不代表概率值可靠。就像学生考试时信心满满，但成绩未必好。需要同时关注离线校准指标。

第三个误区是多次采样时 temperature 设置不合理。temperature 太低，多次采样结果基本一致，失去排查意义；temperature 太高，回答会变得混乱，无法稳定判断。通常用 0.7 到 1.0 作为多次采样的起点比较合适，具体要看模型和场景。

第四个误区是忽视延迟。多次采样会把推理成本放大 N 倍。如果不做分级策略，所有请求都走多次采样，系统的服务能力会明显下降。更合理的做法是先用低成本信号判断，只有低置信度样本才进入多次采样流程。

6.2 常见问题排查表

7. 工程落地建议：把不确定性变成产品能力

7.1 把校准指标加入评估体系

在模型评估阶段，除了准确率、BLEU、ROUGE 等常规指标，建议增加校准相关指标。比如计算测试集上的 ECE、绘制置信度-准确率曲线。

如果团队在评估模型时只比较“谁的回答更准”，很容易选出一个表面分数高但过度自信的模型。校准指标能帮团队识别出那些“犯错时不自知”的模型，这类模型在真实业务中风险其实更高。

7.2 阈值、日志与人工回流

不确定性决策层的阈值不应该拍脑袋定，建议按照下面的方式管理：

• 在测试集上模拟不同阈值下的转人工率、错误率、直答率。
• 根据业务可接受的风险水平选择阈值。
• 上线后记录每条请求的熵、采样一致性、决策策略、最终用户反馈。
• 定期用线上日志评估阈值是否需要调整。

同时要建立人工回流闭环。转人工的样本不能只停留在客服系统里，应该定期分析：哪些问题是模型频繁不确定的？是不是知识库缺少对应内容？据此反向优化知识库和 Prompt。

7.3 成本与延迟控制

多次采样会显著增加推理成本。一个可行的优化思路是级联决策：

• 先用低温度单次生成，计算快速信号，比如熵。
• 只有低置信度样本才进入多次采样流程。
• 只有多次采样仍然不一致的样本才转人工或触发更强力的检索。

这种“瀑布式”策略能在保证安全性的同时，把平均延迟和成本控制在可接受范围内。

7.4 安全边界：置信度不等于真实风险概率

最后必须强调一个原则：模型输出的置信度只是模型内部的统计信号，业务上不能把它当成真实世界的概率来使用。

在医疗、金融、法律等高风险场景，模型置信度不能作为唯一决策依据。比如金融系统不能因为模型给出了 95% 的违约概率就直接拒绝贷款，还需要把模型输出交给业务规则引擎，结合其他因子综合判断。

不确定性推理的价值在于辅助决策，而不是替代业务风控。它让系统知道“什么时候应该放慢速度、寻求更多信息”，这正是可靠 AI 应用的重要能力。

8. 总结与下一步学习建议

本文围绕 AI 不确定性推理这个主题，建立了从概念到落地的一套知识框架。你可以把关键点浓缩成下面几句话：

• 不确定性分为偶然而知与认知两大类，应对策略完全不同。
• 熵用来量化模型对答案的确定程度，校准用来衡量置信度是否可信。
• 生成式场景下，多次采样与语义一致性比单次 token 概率更可靠。
• 工程落地时，不确定性决策层就是系统的安全阀：低置信度时检索、转人工、放弃执行。
• 不确定阈值需要结合成本和风险，在测试集上反复验证。

如果接下来想深入研究，可以按这条路继续走：

• 第一优先级，在现有项目里增加“熵 + 多次采样一致性”两个信号，记录线上日志，观察模型在什么场景下最不确定。
• 第二优先级，用验证集计算 ECE，尝试最简单的温度缩放校准方法。
• 第三优先级，阅读贝叶斯深度学习和概率模型相关材料，理解 Dropout 不确定性、深度集成等学术方向的思路。
• 第四优先级，如果团队在做 AI Agent，可以把不确定性驱动工具调用的策略落到一个具体流程上，先跑通一个小范围实验。

实际项目里，不需要一开始就搭建一套复杂的不确定性推理引擎。从最简单的“熵阈值 + 转人工”开始，把信号收集起来，再逐步优化阈值和决策策略，效果往往比直接套用复杂模型更快。希望你也能在自己的 AI 系统里，给不确定性留一个位置。