实时配置校验：自动捕获陈旧度量数据的系统

我运营一个经过验证的推理端点。我们销售的是检查：我们在提供结果之前验证结果，并在我们无法验证时主动说明。

本月我们交付的每个声明缺陷都有相同的形式。一个数字被诚实地测量，它下面的配置改变了，但数字仍然留在页面上。我们的基准行是在几周前已经停用的模型层上测量的。没有东西被捏造。所有东西都是陈旧的。

所以我构建了一个无法变陈旧的页面。它从实时网关配置生成，页面上的每个徽章都是派生的而非写死的。如果一个测量的配置前提不再与运行中的系统匹配，页面就会删除该数字并说明原因。

它上线了。一小时内它抓住了我发布的两个数字，这些数字是我们自己的账本明确保留的。

对于系统中的每条路径，它陈述四个事项：

"好"在该路径上意味着什么，以及是否有真正的预言机检查过它。工具调用针对 schema 进行检查。代码在沙箱中针对你的测试运行。自由文本什么都没有检查，因为没有东西可以运行。

测量值，以及 n、间隔和日期。

该测量是否仍然描述运行中的系统，根据实时配置自动评分。

它是否通过了对抗性审查，如果没有，这将出现在页面上数字旁边。

第三项就是重点。一个数字和一个配置是两个悄悄漂离的事实，再多的谨慎也解决不了这个问题。一个同时读取两者的生成器无法对差距撒谎。

我把我们的工具调用和陷阱集合结果放在上面。两者都是好数字。两者都在我们的内部声明账本中标记为未清除外部引用，需要对抗性验证。

我写了一个整个目的就是只发布通过我们检查的东西的页面，但我没有运行该检查。

第一个修复是针对那个特定短语的黑名单。也是错的。我们的账本至少以六种措辞保留行，黑名单会漏掉第七种。对于公开声明，网关必须故障关闭：只有当账本行存在且不携带保留标记时，数字才发布。过度保留会导致页面上的数字丢失。未充分保留会导致更正。

故障关闭立即抓住了两个更微妙的问题。两个图形根本没有账本行，因为我从内部交接而不是真实层源了它们。其中一个是 30/40 的结果。我们的账本也包含一个 30/40，来自完全不同运行中的不同模型。相同的数字，不同的测量。这正是未标注数字会引发的混淆。

然后审阅者拒绝了我的草稿

剩余的声明需要真正的对抗性审查，所以我委托一个并指示它反驳而不是同意。它回复不要发布，有三个具体缺陷：

我写道我们的一致性网关接受错误答案"大约四分之一到三分之一的时候"。那个范围是两个样本量不足的子组（25 中的 6 个和 15 中的 5 个），其置信区间几乎完全重叠。它读起来像一个稳定的操作特征。数据支持一个合并二项式：40 中的 11 个，27.5%，威尔逊 95% 区间 16.1 到 42.8。

我引述"代码上 1.7 到 3.5%"。它具有测量区间的形式。审阅者说证据不在我的简报中，这通常意味着我的简报不充分。所以我检查而不是接受。这个数字在我们的账本中出现三次，没有 n、没有区间也没有日期。这个差距是真实的。

我写"算术上接近零"。这是我们在读者从我们自己发表的文章文本中捕捉到之后公开撤回的声明的残留。不存在干净的替代品，所以这个短语根本无法出现。

我接受了全部三个。我拒绝了一个指令：它想让我名命一个内部阈值，这是配方而不是结果。它不知道这一点是因为我没有就我们的披露政策对它进行简报。同样的失败，另一个方向。

无法失败的绿色检查

在扩展我们的声明网关以覆盖更多表面时，我做了一件我在它被写出来时就应该做的事：我注入了它存在的目的所要捕捉的缺陷。

七个注入。五个错误的百分比，一个删除的成本倍数，一个撤回的复合声明。它没有对任何一个触发。它的容差覆盖了它检查的大部分范围，所以几乎任何数字都是"支持的"。它已经连续几周每天早上打印 OK。

它没有撒谎。它自己的输出说"值被检查，不是声明"，它源代码中的注释也说一样的话。缺陷是在一个层级外：状态板上的一条绿线被读作保护，没人重新阅读警告。

一个你从未看过失败的守卫不是守卫。它是一个习惯。

转移的规则

你的仓库中的更正不是公众中的更正。我们的实时网站仍在提供撤回的数字，而每个内部工具都报告扫描已完成，因为每个内部工具都 grep 仓库。通过获取公共 URL 来验证公开声明。

你的测量工具是一个工具，所以首先验证它。我们的成本脚本汇总了三个成本列中的一个。它报告了一美分，而真实情况是 $1.73，它正是我们账本的成本行引用的确切脚本。

可读性过滤器可能吃掉一个错误。我通过 grep -v 的远程脚本来隐藏一个弃用警告。一个数据库认证失败以零状态码退出，这变成了 STATUS: Success，然后成为两个生产盒子上的全军 OK。这个谎言在每一跳处变得更加权威。

占位符是声明。我们的仪表板在实时数据到达之前呈现了"$1,284 本月节省"为静态 HTML。一个全新的零使用量账户会被展示一个捏造的节省。我在向公众开放注册时发现了它，比陌生人会看到它早了一步。

发布你更弱的路径。我们的陷阱集合在主路径上是 200 的 200。在故障转移下是 30 的 40，每个漏失都是相同的判决：它调用一个工具，而它应该拒绝。两个数字都在页面上。第二个是更有用的一个。

这个页面现在在 tirtha.ai/capabilities 上线。七条路径，每条路由的检查内容，它测量的内容，以及每个数字的审查状态。

要尝试它而不是阅读它，tirtha.ai/verify 对我们的 API 实时运行，无需密钥也无需注册。三个预填充的对抗性案例，你可以看它拒绝一个调用而不是捏造一个。

要在你自己的工作负载上运行它：去 tirtha.ai，点击 Get an API key，用 Google 登录，然后开始。我们在测试阶段期间免费。无需卡、无需邮件、无需销售电话。你每个月获得 100 个请求，它停止而不是让你惊讶。

如果你在那个页面上找到一个不能生存的声明，我想听到它。这不是修辞。上一次有人这样做时，他们在读我们自己发表的文本，而他们是对的。