我测试了我的确定性AI金融验证引擎。核心部分通过了66/66，但实时LLM管道仅通过了19/66。

Reddit r/ArtificialInteligence 新闻
ai-verification benchmarking financial-ai llm-evaluation deterministic-systems structured-outputs

摘要

这篇文章报告了对确定性AI金融验证引擎的基准测试结果，显示在结构化声明上表现完美（66/66），但当使用LLM生成的声明时表现不佳（19/66），表明LLM与形式系统之间存在翻译差距。

我一直在构建一个用于AI生成金融声明的确定性验证引擎。基本思想很简单：LLM可以生成金融答案，但LLM本身不应被允许决定其答案已“验证”。相反：LLM生成声明 ↓ 结构化声明 ↓ 证据绑定 ↓ 兼容性检查 ↓ 冲突检测 ↓ 确定性计算 ↓ 版本化规则 ↓ 验证通过 / 矛盾 / 阻塞 / 等等。我最近以两种模式运行了66个案例的基准测试。1. 基于固定装置的声明输入 当确定性引擎接收预期的结构化声明时：66/66案例通过。2. LIVE_CLAIM模式 然后我使用Azure OpenAI的GPT-5.1生成进入相同验证管道的声明。结果：19/66案例通过。失败细分：31个管道执行失败 18个声明绑定失败 2个矛盾检测失败 同时，几个验证维度得分完美：证据图完整性：25/25 确定性计算：25/25 规则应用：25/25 缺失证据检测：25/25 可重复性：25/25 可审计性：25/25 所以有趣的结果不是简单的“基准测试失败”。它似乎显示了两个问题之间的分离：问题1：确定性验证引擎能否正确评估一个正确结构化的声明？在这个基准测试中：66/66。问题2：LLM能否可靠地将其输出转换为确定性验证系统所需的确切结构化声明？在这个基准测试中：显然还不行。大多数失败发生在声明绑定和管道执行之前或期间，而不是确定性计算或规则应用。我的下一步是添加更细粒度的诊断并比较：预期固定装置声明 vs 原始LLM输出 vs 标准化声明 vs 验证器输入 我特别感兴趣的是来自以下领域人员的反馈：LLM结构化输出 代理可靠性 确定性验证 形式方法 金融系统 评估基准 你会将此视为验证架构正在工作但LLM到形式系统的翻译层需要改进的证据，还是你看到基准测试设计存在更根本的问题？如果人们感兴趣，我很乐意分享更多关于基准测试方法论和失败分类的细节。https://preview.redd.it/dp5cw84zepkh1.png?width=1536&format=png&auto=webp&s=fca0805351d62f461c404f3e0def1a625e7922d7
查看原文

相似文章

Gate AI：LLM安全基准评估方法与结果

arXiv cs.LG

本文提出了一种针对LLM安全检测器的评估方法，旨在解决诸如按数据集调阈值、未公开操作点等系统性缺陷。该框架在16个基准上进行交叉验证，选取单一全局操作点，并包含多项泛化能力诊断指标。