Skip to Content
AI 能力AI Verify

AI Verify

AI Verify（AI 验证器，AI Verifier）解决一个信任问题：AI 的「结论」凭什么可信？ 普通 AI 问答可能过度自信、可能编造引用；Verify 在 LLM 之上加了一层服务侧强制校验—— 每条结论必须出示可追溯的证据、承认盲区，置信度会被规则校正，疑似编造的引用会被拦下重做。 校验通不过，就不出结论。

产品定义：docs/02-product/34-ai-verifier.md · 核验实现：services/copilot/src/verify

三个触发入口

入口用法
Console /verify 页输入要核验的内容，点「开始核验」
MCP 工具在 Claude / Cursor 里让 AI 调 verify.run 或 verify.run_session（接入见 MCP Server）
CLIargus-dev verify "下单流程是否符合预期" 或 argus-dev verify --trace abc123（见 Argus Dev）

三个入口走同一条核验链路，结论口径一致。

结论长什么样：Evidence Schema

每次核验（run）产出一份强约束的证据报告：

字段含义
verdict判定结果：pass / fail / uncertain
confidence三态置信度：high（80% 以上）/ medium（50-80%）/ low（50% 以下）
conclusion一句话结论
evidence证据数组（不能为空），每条含 type（code/doc/trace/log）、ref（可追溯引用）、content（引述内容）、supports（支持 pass/fail/neutral）
reasoning_steps推理步骤
limitations盲区 / 假设（至少 1 条，强制 AI 承认自己的局限）

示例（fail 判定）：

{
  "verdict": "fail",
  "confidence": "high",
  "conclusion": "下单流程触发了非预期的 stripe.refund 调用，与文档不符",
  "evidence": [
    {
      "type": "trace",
      "ref": "5f3a...:span_id=b2c4",
      "content": "span name=stripe.refund, status=OK, duration=820ms",
      "supports": "fail"
    }
  ],
  "reasoning_steps": ["文档明确下单后无 refund", "trace 显示 stripe.refund 被调用"],
  "limitations": ["本次只验证 1 条 trace，未覆盖其他金额场景"]
}

服务侧强校：AI 说了不算

LLM 的自评置信度只是「上报值」，服务侧会用规则校正为有效置信度：

  • 证据不足封顶：证据少于 3 条时，置信度强制不超过 medium；
  • 自相矛盾降级：证据的 supports 同时出现 pass 与 fail 时，强制降为 low；
  • 引用存在性校验：每条证据的 ref（如 trace_id、日志 event_id）都会到真实后端查证—— LLM 编造的引用会被拒绝并要求重做；
  • 不合格即拒绝：报告不符合 schema 时服务侧重试，重试后仍不过则返回 422 「无法产出可信结论」，绝不硬给一个凑数的答案。

Console 中若发生降级，会同时展示「AI 自评 high，服务侧降级为 medium」及降级原因。

红线：无论 verdict 是什么、置信度多高，核验结论永不自动触发任何写操作——不回滚、 不改配置、不动线上。结论给人看，动作由人做。

Console /verify 页

页面标题「AI Verify · 结论可信核验」。使用流程：

  1. 顶部选择项目；
  2. 输入要核验的内容（如「verify 这次下单流程是否符合预期」），点开始核验；
  3. 「本次结果」区展示判定 / 置信度徽标、结论、降级原因（如有）、证据列表、推理步骤、 盲区 / 假设；
  4. 对历史核验可标记采纳 / 拒绝（附原因）——这是人对 AI 的裁决，被采纳 / 拒绝的核验还会 作为后续核验的正 / 负例参考；
  5. 复盘看板汇总「AI 准不准」：总体采纳率，以及按置信度、按判定分桶的采纳率 （检验置信度是否校准）。

MCP 工具

在任何接入了 Argus MCP 的 AI 客户端里可用（需部署 copilot 服务）：

verify.run — 核验一个论断

参数说明
query（必填）要核验什么，如 verify the checkout flow behaves as expected
evidence_context（可选）预先收集的证据上下文（trace / 日志 / 代码片段），用于锚定核验

返回带证据链的 verdict；若返回 ok:false，表示模型无法产出可通过校验的结论——此时应呈现 失败原因，而不是让 AI 猜一个。

verify.run_session — 核验一条或多条 trace

参数说明
trace_id / trace_ids（二选一）要核验的 trace（单条或多条合并为一个会话）
expectation（可选）自由文本预期，如「下单应无错误完成」；缺省做一般健康检查
doc_refs（可选）参照文档（路径 / URL），核验时与 trace 对照
code_scope（可选）代码范围限定（include / exclude glob）

它会自动拉取 trace 的全部 span、汇总为证据再核验——适合改完代码后确认请求链路行为符合预期。 典型配合：先用 trace.search 找到刚才操作产生的 trace_id，再 verify.run_session 判定。

CLI 触发

用 Argus Dev 的 verify 子命令在终端直接核验（需可达 copilot 服务， 经 ARGUS_COPILOT_ENDPOINT / ARGUS_INTERNAL_SECRET 配置）：

argus-dev verify "我刚才的下单流程是否符合预期"
argus-dev verify --trace 5f3a1b2c...

规划中

  • content 一致性校验：当前只校验引用「存在」，尚未比对引述内容与真实内容是否一致 （防「真引用假摘要」）；
  • verify.assert_rules（确定性 DSL 断言，零 LLM 成本、可进 CI）与 verify.diff_with_docs（与指定文档对照）；
  • 代码 / 文档引用的真实源接入：code ref 校验待 GitHub 仓库读取集成（EE），doc ref 待 文档库数据源；
  • 告警自动核验的完整防护：按告警指纹去重已有初步实现，窗口上限、沉默期对齐等仍在补齐；
  • 人工复核状态机：在采纳 / 拒绝之上的「待人工确认 / 已被推翻 / 存疑」完整呈现。

常见问题

Q：Verify 和直接问 Copilot 有什么区别？

Copilot 的回答是「分析」，Verify 的输出是「经过强校验的判定」：证据非空、引用查证、置信度 被规则校正、不合格拒绝出结论。要拿去做决策依据（该不该回滚、修复是否生效）时用 Verify。

Q：为什么返回 422「无法产出可信结论」？

模型多次尝试后仍给不出通过校验的报告——常见原因是相关数据太少（trace / 日志不足以支撑证据）。 这是特性而不是故障：拒绝出结论好过编一个。补充数据或缩小核验范围后重试。

Q：verdict 是 fail 就一定有 bug 吗？

不一定。fail 是「AI 的判断」而不是事实，看置信度与证据后由人裁决；在页面上标记采纳 / 拒绝， 既留下复盘记录，也帮助后续核验更准。

Q：怎么验证一次修复真的生效了？

两种确定性更强的做法：崩溃类用 MCP 工具 crash.recurrence（纯数据判断签名是否复发， 不经 LLM）；链路行为类用 verify.run_session 对修复后的新 trace 核验。

Q：核验计费吗？

核验消耗 AI 调用额度；一次核验后台可能发生多次子工具与 LLM 调用，对你合并计量。 详见配额与计费。

Platform CopilotArgus Dev（开发期采集）