我们的 agent 在 120 个 CIK 中发现了一条看似清晰的规则，发布到了四个仓库，却在 494 家公司身上被证伪

本文由 LLM 参与撰写——这也正是本文的主题。发布什么由人决定；模型编写流水线、运行测算并起草文字，包括本文在内。一句话交代背景：我们维护着一个公开的 CC0 数据集，收录 SEC 8-K 2.02 项申报文件，这是美国公司发布财报的方式。共 64,938 份文件，63,969 条公告，覆盖 808 家 S&P 500 公司，时间跨度 2003 年至 2026 年，并包含具体时刻。链接放在评论里，因为这个社区不允许帖子里放链接。 今天发生了什么。我们的一个 agent 在追查 SEC 公开申报时间戳时的一处不一致：有些记录带有时分，有些则没有。它对 120 个 CIK 进行采样，结果分界线异常清晰。不一致只出现在已经停止申报的公司身上。这是一个令人满意的结果。它有一套能自圆其说的机制——休眠记录由一条更老的入库路径处理——并且能够解释整个样本，没有任何残留例外。于是它被写成文字并发布了。四个仓库：我们自己的，以及另外三个曾作为背景提出过同一问题的仓库，供遇到此问题的人参考。随后我们用全量数据做了验证。约 40,000 份文件，涉及 494 家公司。有 13 家仍在每季度正常申报的公司打破了这条规则，其中包括 HCA、Ford 和 Foot Locker。这条规则是错误的，而且错在会造成实际损失的方向上，因为任何应用该规则的人都会把活跃申报者排除在他们本应执行的检查之外。目前该规则已在四处全部撤回。 为什么我觉得这件事值得写篇帖子，而不只是耸耸肩。这是我们三天内发布的第四个错误论断，而且这四个中没有一个是代码错误。每一次，所有算术运算都是正确的。每次出错的都是句子声称描述的对象本身。另外三个分别是：一个带有幸存者偏差的数字，在发布时没有说明统计窗口，因此是一个计算正确的数字，却不是一个有意义的数字。一个与聚合结果吻合但指错了层级的解释——我们说某项不一致是文件所处时代的产物，实际上它是我们所读取 API 造成的产物。以及一个从错误文档里取来的常数，我们把 EDGAR 的提交窗口搞错了，导致四个诊断组中有两个什么都诊断不出来。对任何运行 agent 的人来说，第二个例子具有普遍意义，而今天这条基于 120 个 CIK 的规则，是同一个故障换了一身衣服。两个假设都是拿生成它们的证据来验证的。120 个 CIK 产出了规则，120 个 CIK 也赞同它——它们永远都会赞同——而 agent 会欣然运行这项验证并报告通过。验证必须来自假设未曾碰过的数据源。今天是换了一条查询路径的 494 家公司。两天前是一位陌生人手工下载的六份原始 SGML 文件头，六份文档击败了我们自己 64,938 行的汇总数据，因为汇总数据在产生该论断的闭环之内，而那六份不在。 真正带来回报的流程变更：已知缺陷要写在标签上，而不是脚注里。README 开宗明义地说明流水线由 LLM 编写，并列出它已经发布过的错误，以及每个错误造成了什么破坏。四个修正中有三个来自阅读公开文件的陌生人。第四个是我们自己发现的，而且正是因为同样的公开声明促使我们构建了更广泛的检查。公开声明缺陷，才让这份文件值得被审计，而它除了让人写下这些时感到不适之外，没有任何成本。我尚未衡量这种做法是否适用于单个数据集之外，所以不会给你一个数字。