人们越来越多地要求AI模型设计、部署、保障和恢复生产级基础设施,而不仅仅是通过单位测试的写作功能。
这种转变改变了一种培训环境。
检查输出"看起来正确"已经不够了.
你需要一个金色的参考解决方案,一个决定性的验证套件, 以及一组故意被破坏的变体, 精确地探究一个模型的推理在失败后会崩溃的地方。
在过去几个月里,我一直在这个问题的另一边工作—— 对照结构化标题评估代理编码输出, 设计程序验证检查, 以及写一些作者没有考虑过的边缘案例。
在此之前,我花了7年时间来建造和调试这些环境用来模拟的系统:多租户SaaS平台,具有行级安全,AWS基础设施服务于高流量电子商务,数据管道处理数以万计的并行请求。
这篇文章是关于这两件事的交会地点——实际需要什么来构建一个可以复制,公平评价,难以游戏的基础设施RL环境.
一个金色的解决方案 与其模糊的预算一样好 在建立任何评价环境方面的第一个错误是,未对情况作出充分说明,对解决办法作了过分说明。
如果任务上说"部署一个容错的队列消费者",而不下定交付语义,重试政策,以及"容错"在操作上的含义,你最终会得到一个金色的解决方案,这个解决方案在几个人之间只是一个有效的解释——你会因为一个从未真正做出过的决定而惩罚一个模型.
这是与为编码评价写出标题相同的纪律:每个模棱两可的名词都是未来的争议.
在实践中,这意味着在写出单一一行基础设施代码之前,界定: 范围中的确切失败模式( 节点丢失、 网络分区、 消息重复、 时钟 skew) 无论执行与否,必须持有的变动因素(一经交货,一经交货,便捷性保障,RTO/RPO目标) 算作"被恢复"的东西——不仅仅是"服务上来了",而这种状态是一致的定断主义验证手段,就是针对非定断主义的设计 分配的系统本质上是非定断主义的——这正是它们很难评价的原因.
一个通过重新运行相同序列的API调用和diffing输出而起作用的验证套件,一旦涉及复试,超时,或者最终的一致性,就会产生片面,不公平的结果.
最近写了一套安全测试套件, 以验证排级安保政策, 而不是嘲讽, 对照真实的,可支配的实际依赖性实例进行测试——真实的排队,真实的Postgres,真实的IAM政策引擎,而不是模拟捕捉到在结构上嘲弄的虫类:你假设的合同不符合你的行为.
我有一个由根引起的生产错误(一个小的依赖性版本会悄悄地折叠出TypeScript类型到...,一个OAuth标志性再现的边缘案例,它只在真实的API率限制下复制),一个被嘲笑的测试套件会直通过去.
同样的原则适用于基础设施层,每起故障的利害关系较高。
缺陷变体需要失败的原因 故意被打碎的变体的重心不仅仅是"模型是否注意到什么是错的"——这是"模型正确诊断为什么".
一个配置错误的 IAM 策略的变体,恰好也存在网络配置错误,会教一个模型在错误的信号上进行模式匹配.
建造这些水井意味着将每个缺陷作为单一的孤立假设: 每个变体一个断层.
抵制将破损的再试政策和规定不足的自动升级组合并为一个情景的"效率".
你会