查询成功、图表漂亮、报告完整，都不能单独证明答案可信。Agent 可能选错数据源、套错指标口径、执行了正确 SQL 却读到不完整数据，最后再把相关性写成因果解释。
一个总准确率会把这些错误压成同一个数字，也会掩盖高风险失败。更有效的做法是沿分析链逐层验证，并让失败回到真正需要修复的位置。
下层错误会污染上层。来源不对时，评价报告文笔没有意义；发生越权时，再高的平均准确率也不能抵消安全问题。
五层验证，各自回答不同问题
| 层级 | 验证问题 | 失败后回到哪里 |
|---|---|---|
| 来源层 | 资产、版本、权限、数据水位和覆盖是否正确 | 接入与上下文路由 |
| 语义层 | 指标、实体、粒度、时间、Join 与过滤是否符合业务定义 | 语义计划或澄清 |
| 执行层 | 查询/代码能否安全运行，结果是否完整且符合契约 | 工具参数、代码或运行环境 |
| 分析层 | 比较基线、统计方法、推断和不确定性是否成立 | 分析计划或补充证据 |
| 交付层 | 结论是否有引用，图表是否误导，接收者是否有权使用 | 报告、制品或审批流程 |
每层都应产生结构化结果：pass、fail、unknown 或 needs_human，并附证据。未知不能自动当作通过；同一个模型对自己的答案说“看起来正确”，也不是独立验证。
一道题需要多种正确性
以“哪个渠道导致本月转化下降”为例：
- 任务正确性：是否回答了“贡献变化”，而不是只列出最低转化率渠道。
- 数据正确性：是否覆盖本月全部渠道，水位是否完整。
- 语义正确性：转化率分子分母和新客定义是否一致。
- 程序正确性：SQL 是否避免重复 Join，查询结果是否被截断。
- 分析正确性：渠道结构变化是否造成聚合偏差，是否误写因果。
- 交付正确性：结论、证据、限制和建议是否对应，接收人是否有权限。
只用 exact match 比较 SQL，会把等价查询判错，也会把能运行但业务错误的查询判对。评测应执行查询、检查语义绑定和结果性质，再由规则或人判断分析结论。
建立一套来自真实工作的任务集
通用基准能比较研究系统，但企业上线仍需要自己的任务集。样本应来自实际问法、历史工单、分析报告和失败日志，并按业务域、难度、风险和数据形态分层。
每题至少记录：用户身份、目标、允许资产、禁止资产、语义版本、数据快照、期望产物、可接受变体、必须拒绝的行为和评分规则。开放分析不必只有一个标准答案，但应有事实不变量、必须覆盖的假设和不可越过的推断边界。
困难样本不能只靠“更长问题”制造。真正有价值的是同名表、歧义指标、权限差异、数据延迟、空集与零、工具超时、冲突证据和无法回答的问题。
指标要与失败成本对应
一组更实用的指标包括：
- 资产选择与覆盖：Hit@K、Recall@K、跨源完整集合覆盖率。
- 语义绑定：正确指标/实体/版本比例，歧义时的澄清或拒答质量。
- 执行可靠性：可执行率、结果契约通过率、超时与资源超限、重复副作用。
- 答案支持率：关键事实声明中有可访问证据支持的比例。
- 校准：系统表达的置信度是否与真实正确率一致，未知时是否收敛。
- 安全阻断：未授权请求误放行率，必须独立报告并设为上线门禁。
- 成本与延迟：端到端 p50/p95、模型与工具调用、扫描量和人工复核时间。
不要把这些指标简单平均成一个“综合分”。越权、错误写入和没有证据的高置信结论，成本远高于格式不完美；权重应由场景风险决定。
离线评测、影子运行和线上监控各做什么
离线回归用于固定快照上比较模型、提示词、语义版本和工具变更。每次发布都跑核心集和近期故障集，保存执行轨迹与差异。
影子运行让 Agent 处理真实请求但不向用户或生产系统提交结果，用来发现目录、权限、成本和长尾问题。它比离线集更接近环境，同时保持较低风险。
线上监控关注任务完成、人工修改、拒答、升级、工具故障、权限阻断、延迟和成本。用户点赞不是正确性标签；人工修改也要区分文风调整、口径修正和事实错误。
线上确认的错误进入回归集，但要去除敏感数据、绑定版本并记录失效条件。评测集本身也会漂移，需要负责人和更新流程。
评判器也要被评测
LLM-as-a-judge 适合检查结构、覆盖和开放式表达，却可能偏爱更长、更自信或与自身风格相近的回答。使用前应让多名领域专家标注一组校准样本，测量一致性，并为高风险结论保留人工复核。
确定性问题优先用确定性验证器：SQL 解析与执行、Schema 检查、数值容差、不变量、权限策略和引用可访问性。模型评判器负责难以形式化的部分，而不是替代所有测试。
可观测性要能重建一次任务
一次任务轨迹应连接：请求与身份、上下文候选、语义计划、计划版本、工具参数摘要、执行 ID、验证结果、最终制品和人工修改。日志中避免保存凭证与不必要的敏感全文。
有了关联轨迹，团队才能回答“错在选表、口径、SQL、推断还是表达”，而不是只看到最终差评。错误分类应直接映射负责人和修复层级。
一套最低可行评测流程
- 选 50–100 个真实高频任务，加入至少 20% 的拒答、越权和故障样本。
- 为每题标注来源、语义、不变量、允许变体和错误成本。
- 固定数据快照，先建立人工或现有系统基线。
- 分层评分并保存轨迹，不只比较最终文字。
- 在影子环境验证权限、成本和恢复行为。
- 设定上线阻断项与回退条件；发布后持续把确认错误加入回归。
可信不是一句“模型置信度 95%”，而是每一层都有可检查证据，任何未知都不会被语言润色成确定答案。评测的最终目的也不是拿到高分，而是知道系统在哪些任务上可以接手责任，在哪些边界必须停下来。