让故障 Agent 的置信度有据可查

AI 说自己有 95% 的把握，依据是什么？DejaVu 团队给故障处理 Agent 加了一层约束：引用必须来自检索到的历史事故，置信度必须受成功修复记录限制，不能任由模型报数。

这套方案值得看的是工程细节：怎样清理虚构引用、怎样限制分数，以及测试如何抓住一个放行 100% 的漏洞。不过，规则算出的 98%，是否真能代表成功概率，还得单独讨论。

先让证据能核对，再讨论有多大把握

DejaVu 是一个利用历史故障经验辅助排障的 AI Agent。团队把过去的事故存入 Vectorize 的开源 Agent 记忆系统 Hindsight；新错误出现时，先召回最相似的事故，再让运行在 Groq 上的 GPT-OSS 120B 仅围绕这些记录推理。

这里的「记忆」可以理解为可检索的历史事故档案。模型给建议时，需要列出用了哪些事故，工程师才能回头检查依据。

但模型输出的引用并不天然可靠。它可能引用没有召回的事故，把编号写成 12 或 #12，也可能重复引用同一条记录。团队先用代码清理证据：

def clean_evidence(evidence, recalled_ids):
    cleaned, seen = [], set()
    for e in evidence or []:
        raw = str(e.get("incident_id", "")).strip().lstrip("#")
        if not raw.isdigit():
            continue
        iid = int(raw)
        if iid in recalled_ids and iid not in seen:   # must come from memory, once
            seen.add(iid)
            cleaned.append({**e, "incident_id": iid})
    return cleaned

关键是 iid in recalled_ids and iid not in seen：只有本次召回集合里的事故才能保留，同一事故只能算一次。模型虚构的编号会被丢弃，重复引用也不能增加证据数量。

能追溯到真实记录，是证据成立的第一步。

但这一步只验证了「记录确实被召回」，还没有证明它与当前故障足够相关。这个边界会影响后面的分数解释。

98% 是怎样算出来的，又能说明什么

清理引用后，系统统计其中有多少事故的修复确实成功，再限制模型分数：

proven = sum(1 for c in cited if c["fix_successful"])
if proven >= 3:
    conf = min(98, max(model, 88 + 2 * proven))
elif proven == 2:
    conf = min(max(model, 75), 89)
elif proven == 1:
    conf = min(max(model, 55), 74)
else:
    conf = min(model, 30)

要看的是 proven 对应的分支：没有成功记录，最高只能给 30%；有 1 条，限制在 55%—74%；有 2 条，限制在 75%—89%。达到 3 条后，按 88 + 2 * proven 设置下限，最终封顶 98%。

模型自己的判断仍参与计算，但只能在规则允许的范围内活动。例如，5 条成功记录对应的下限是 98% 封顶前的 98？并不是，88 + 2 * 5 恰好等于 98，因此此时分数会被固定为 98%。

分数下面还会展示文字依据，例如「5 条匹配的历史事故中，5 条都通过这种方式修复」。工程师可以打开事故卡片，查看服务、错误和处理耗时。

原文给了两个场景。支付服务在部署后出现 KeyError: 'amount'，系统召回 5 条相同缓存问题的事故，修复全部成功，最终给出 98%。另一个是从未见过的新问题：检索仍会返回最接近的记录，但没有可证明的成功修复，分数就保持在 30% 或以下。

这里有个容易误读的地方：检索返回了相似记录，不等于已经找到适用的解决方案。

界面在无成功证据时显示「记忆中没有匹配事故」，表达了谨慎态度；不过，严格来说，「没有匹配记录」与「有相似记录但缺少成功修复证据」是两种情况，原文没有充分区分。

真正有用的测试，是让模型故意乱来

团队使用 pytest 编写自动化测试，并模拟 Hindsight，让测试约一秒就能跑完。部分测试由运行在 Band 桌面应用中的 AI 编程 Agent 编写，整套测试目前有 56 项。

其中一项输入很直接：模型声称有 100% 把握，同时给出 5 条成功匹配。旧公式放行了 100%，团队因此补上 98% 的硬上限。

后续测试还覆盖了文本形式的编号、重复引用、损坏的 JSON，以及把修复步骤返回为一整段字符串等情况。

这部分经验很适合日常 AI 应用开发：测试不能只检查模型按要求返回内容时是否正常，还要检查它违反格式、重复证据、夸大结论时，程序能否守住规则。原文没有展开全部容错实现，因此不能仅凭测试数量判断覆盖是否充分。

我的判断

我认同把引用校验和分数约束放进程序。相比只在提示词里要求「诚实回答」，这些规则更容易检查，也能通过测试防止回归。

但作者展示的是一套经验评分规则，还不是经过统计验证的概率校准。原文没有提供真实事故上的分组准确率，也没有给出与模型直接报分的对照数据，不能据此认定「98% 的建议有 98% 会成功」。

它还依赖历史数据的质量：fix_successful 如何标注，不同事故是否相互独立，过去成功的修复是否适用于当前环境，原文都没说清。公式主要看成功数量，也没有直接体现失败记录的比例。

因此，我会把这个分数理解为受证据约束的参考指标。它比毫无依据的自信更方便审查，但用于凌晨生产故障决策时，仍需要核对当前环境和具体操作。

能拿来做什么

• 给前端或 Node 服务做历史故障助手时，可以要求模型返回事故编号，再用本次召回集合验证引用并去重，让每条建议都有可打开的依据。
• 如果产品需要展示置信度，可以同时展示成功记录数量和原始事故，并说明分数采用规则计算，避免让用户把它直接当成成功概率。
• 为 AI 输出处理补上边界测试，优先覆盖虚构编号、重复引用、损坏 JSON、步骤类型错误，以及模型声称 100% 确定等情况。
• 对没有成功修复证据的新问题，让系统明确提示证据不足，引导工程师继续调查，而不是把最接近的历史记录当作现成答案。