이미지: X — 모델·오픈소스 화면 갈무리
摘要
- Liquid AI公布了2025年底的一项实验结果:让Claude Opus 4.5和Codex(GPT-5.2)开发一个生产级BPE分词器训练器
- 两个智能体都在30分钟内做出了可运行的玩具版训练器,但在真实大规模语料库上全部失败
- 在引入"执行-报错-诊断-修复"循环结构后,成果才得以完成,这一训练器"toktoktok"已作为开源项目发布到GitHub上
- 실험 시기
- 2025년 말
- 투입 에이전트
- Claude Opus 4.5, Codex(GPT-5.2)
- 결과물
- 오픈소스 BPE 토크나이저 트레이너 toktoktok (GitHub 공개)
- 검증용 하드웨어
- AMD EPYC 9755, 128코어 256스레드, 메모리 2TB
- 1차 결과
- 양쪽 모두 30분 내 장난감 트레이너 완성, 자체 테스트 통과
- 실전 실패 지점
- 목표 코퍼스의 약 1% 처리 시점에서 메모리 부족 등 7개 문제 발견
- 해결 방식
- 실행→오류 보고→진단→수정→재실행을 반복하는 루프 구조 도입
30分钟做出的玩具,在实战中崩溃
Liquid AI在其工程博客上公布了2025年底进行的一项实验结果。问题很简单:编程智能体能否在没有人工监督的情况下,独立解决生产级问题。为验证这一点,他们将同样的任务交给了当时公认最强的两款编程模型——Claude Opus 4.5和Codex(GPT-5.2)。
结果两个智能体表现一致。二者都在30分钟内做出了可运行的训练器,通过了自身的单元测试,并用几兆字节规模的数据训练出了玩具版分词器。但当输入真正生产规模的语料库后,两个训练器都没能撑住。
为何偏偏选择分词器训练器
Liquid AI在研究端侧(edge)LLM词表大小对性能的影响时,需要一个能在单机上处理数万亿个token的字节对编码(BPE,一种把常见字符对组合起来构建词表的分词方式)训练器。但现有工具无一满足要求:sentencepiece针对非BPE方式做了优化,速度较慢;Hugging Face的tokenizers库在处理大规模语料库时会出现内存不足；tiktoken则干脆没有训练功能。
Liquid AI选择这个任务作为实验对象有三个理由。第一,这不是把现成系统移植到另一种语言的工作,而是以真正的实际部署为目标的任务。第二,该任务同时需要理解分词器训练的机器学习研究人员,以及能编写内存感知型多线程代码的Rust工程师这两种截然不同的专业能力。Liquid AI表示,他们想验证"智能体能否替代任何一名工程师单独都无法覆盖的专业领域组合"。第三,产出结果必须能原样加载进tiktoken和Hugging Face tokenizers,这一外部验证条件使得智能体没有自行操纵"成功"结果的余地。
将目标与验证分离设计
实验设计者在智能体动手写一行代码之前,先准备好了两样东西。其一是规定目标的AGENTS.md、CLAUDE.md规范文档。这份文档不涉及实现方法,只写明结果与约束条件——例如内存是最大的制约因素,因此必须能稳定处理远超RAM容量的语料库;而运算和输入输出用Rust与多线程处理即可满足需求。
其二是智能体无法触碰的验证装置。智能体被授予了对真实生产训练数据集,以及可处理这些数据的AMD EPYC 9755服务器（128核256线程、内存2TB）的沙盒访问权限。训练出的词表会同时加载进tiktoken和Hugging Face tokenizers中,检验编码-解码往返结果是否一致,以及在多语言、数字、货币符号、制表符、换行符乃至源代码中是否存在问题。
代码都通过了,为何还是崩溃
问题出在规模上。在几兆字节测试数据中没有暴露的缺陷,在真实语料库中却接连爆发。Liquid AI整理出的7个问题如下。
| 发现的问题 | 如何暴露 | 何种手段发现 | 修复耗时 |
|---|---|---|---|
| 文件编码不一致 | 测试中正常,但在语料库中悄然出错 | 真实语料库文件 | 数小时 |
| 缺乏内存感知 | 在目标语料库约1%处出现内存不足 | 全规模运行 | 2~3天 |
| 并行化不足 | 所有核心都在忙碌,但处理吞吐量未达标 | 全规模运行 | 1~2天 |
| 预分词速度下降 | 正则表达式回溯导致处理速度骤降 | 性能分析器 | 数小时 |
| 排序(rank)错误 | 词表可加载,但编码结果与预期不符 | 外部验证工具 | 数小时 |
| 重复合并 | 词表数量不足,后续排序全部错位 | 外部验证工具 | 数小时 |
| 数字编码错误 | 两个库仅在数字上结果不一致 | 外部验证工具 | 一行代码修复 |
引入循环后发生了什么变化
Liquid AI在这一阶段改变了做法。他们引入了这样一种循环结构：智能体用真实数据执行任务,遇到瓶颈时报告症状,自行诊断并修复后再次执行。Liquid AI表示,经过多轮这样的循环,两个智能体逐一解决了上表中列出的问题。最终产出的BPE分词器训练器toktoktok目前已作为开源项目发布在Liquid AI的GitHub账号上。
编辑视角
这项实验有意思的地方在于,它问的不是"智能体代码写得好不好"。Liquid AI想验证的是"能否在没有人工介入的情况下通过生产级验证",而分水岭正在于此。30分钟内做出的玩具训练器因为通过了自身测试,乍看像是成功,但真正的失败只有在扩大规模的那一刻才会暴露出来。这项实验表明,基准测试或演示中常见的许多"成功案例"很可能都还停留在这个"玩具阶段"。
将类似规模的编程智能体任务投入实际业务中会发现,结论往往是相似的走向——初期产出看起来不错,但一旦遇到真实数据规模或边缘情况,隐藏的假设就会崩塌。这次实验中,内存不足恰好在目标语料库仅1%的位置爆发,这一事实便是例证。这种错误是小规模测试永远无法捕捉到的。
从实务角度来看,值得关注的是"将目标与验证分离"这一设计原则。不规定实现方法、只写明结果与约束条件,并用智能体无法触碰的外部库进行验证,这种方式为想把实际业务交给智能体处理的团队提供了可参考的最低限度条件。这意味着,与其让人工代替代码审查,不如先建立起自动化验证本身、并允许反复执行的结构。
预计未来几周内,其他公司也可能出现类似的"基于循环"的智能体评估案例。在前沿模型编程基准测试分数竞争持续的背景下,像这次实验一样区分"玩具版与生产版"的评估方式,有可能成为检验基准测试可信度的新标准。
