多 Agent 说你「很确定」的时候，可能在瞎编｜一篇新论文给 LLM 系统装了置信度仪表盘
用不止一个 LLM Agent 串起来干活的人，多半遇到过这种场景：每个 Agent 单独看都还行，一组成流水线就开始互相喂错误数据，而且每个节点都自信满满地输出，没有任何信号告诉你哪一环已经不可靠了。
这个问题在精算建模这种高 stakes 场景里尤其致命——模型定价错了、风险评估偏了、监管合规没过，最后追责的时候每个 Agent 都说自己是按流程跑的。根因在于：LLM 天生是概率输出，但多 Agent 系统缺乏一个能在运行时观测不确定性的仪表盘。
一篇刚被 WAISE 2026（国际 AI 安全工程研讨会）接收的论文给出了一个还算务实的方案。作者 Bart Custers 和 Koorosh Aslansefat 来自精算背景——不是那种随便拿个 benchmark 跑跑的论文，他们真在精算工作流里搭了一个多 Agent 系统，然后认真处理了一件事：让系统在运行过程中告诉你它有多不确定。
logprob 不能直接当置信度用
很多人做类似事情时犯的一个错误是：直接把 LLM 返回的 token-level log probability 当成「置信度」来用。这篇论文明确说了这不靠谱——logprob 高不代表任务正确，而且不同长度的输出之间没法直接比。
他们的做法是：先做 length-normalised 处理，再把汇总值通过校准转换成 task-level 的置信度估计，然后喂进一个 Bayesian Network。这个贝叶斯网络的作用是传播不确定性——当一个 Agent 输出可疑时，它的影响会沿着工作流传递到下游判断，而不是每个 Agent 各自为政地给出一个孤立分数。
整套框架的结构很清晰：一个中心 hub 下面挂专门做数据准备、建模、审查、解释的 Agent，每个环节的不确定性都可以被实时追踪。
谁该关心这个
在聊天框里用 LLM 写邮件的人，这东西确实关系不大。但在搭 Agent 做自动化决策——尤其是金融、保险、合规这类需要审计链条的领域——这篇论文的切入点值得关注。
核心不是模型又刷了多少分，而是它找到了一个不依赖额外标注数据、只用 LLM 自带的 log probability 就能做运行时置信度估计的方法。而且它保留了精算 baseline 的准确性——加了这层不确定性监控，没有牺牲业务表现。
局限也很明显：这套验证只在一个精算场景里跑通，通用性还没验证；Bayesian Network 的结构依赖对工作流的先验理解，不是完全数据驱动的。论文里提到的「log probability 校准后进入贝叶斯网络」这个路线，不是唯一路径——未来肯定会有更轻量或者端到端的方案冒出来。
但方向是对的：多 Agent 系统不能只靠「看起来很确定」来运转，它需要在运行过程中给自己打分，而且这个分数得可追溯、可审计。 这篇论文算是往那个方向认真迈了一步。
相关链接：
- 论文页面（arXiv）
- WAISE 2026