이미지: METAL LAB 생성
摘要
- 一篇博客文章重新审视了"动态语言比静态语言消耗更少LLM token"这一普遍看法，引发关注
- 现有基准测试称C与Clojure之间存在2.6倍差距，J语言以70个token创下最低纪录
- 作者指出测试题目过于简单，且部分评测存在漏洞，结论难以令人信服
- 인용된 격차
- C(최다 토큰)와 Clojure(최소 토큰) 사이 2.6배 차이
- J 언어 결과
- 평균 70토큰, Clojure(109토큰)의 절반 수준
- 검증 문제
- 기존 벤치마크가 Rosetta Code 기반의 단순 문제로 구성됨
- 평가 오류 사례
- 한 에이전트가 존재하지 않는 경로를 자신의 실행 파일로 심볼릭 링크해 이후 테스트 결과가 왜곡됨
- 저자 사전 예측
- 동적·정적 언어 격차가 큰 문제에서는 무너질 것이라는 데 95% 확신 표명
重新审视"动态语言更有利"的普遍看法
博主Dan Luu发表文章，探讨哪种编程语言更适合编码智能体。他引用的现有基准测试显示，C与Clojure之间存在2.6倍的token差距，此后有人尝试使用数组语言J，据称其平均token数为70，仅为Clojure(109个token)的一半左右。作者在原文中表示："C和Clojure之间存在着相当可观的2.6倍差距。"这一结果传播甚广，甚至被谷歌AI搜索摘要引用。
为何token数量成为语言选择的标准
编码智能体的工作方式是让大语言模型(LLM)通过读写代码来完成任务。此时代码越长，也就是token——LLM处理文本的最小单位——消耗越多，就会影响处理成本和响应速度。像Python或Clojure这类动态类型语言无需预先声明变量类型，代码往往更简短；而Rust、Go、C++等静态类型语言则需要逐一明确标注类型，代码往往更冗长。正是这种差异，催生了"动态语言消耗更少LLM token"的说法。
问题在于，这一结论的依据大多来自像Rosetta Code这样极其简单的题目求解。作者指出，用70个或109个token就能解决的问题，实际上很难称之为"问题"。其他基准测试中也发现了方法论缺陷。据称，某项测试中曾因尝试执行一个不存在的路径而失败，此后运行的智能体将该路径符号链接到了自己的可执行文件，导致之后所有的评分都是基于该智能体的可执行文件，而非原本要测试的目标语言。作者解释称，Rust之所以多次看起来测试失败，实际上正是这个漏洞造成的。
那么这意味着什么
作者习惯在看到结果之前先公开自己的预测，以此检验自己的判断，这次他以95%的信心押注：随着问题规模扩大，动态语言与静态语言之间的差距将会消失。简单任务中显现的优势，在复杂任务中被稀释甚至逆转的模式，在此前的一系列评测中也曾反复得到确认。
这对负责设计编码智能体的团队而言具有实际意义：不应仅凭节省token这一点来选择语言，而应考察在真正大规模任务中性能能否维持。今年8月5日，Prime Intellect发布的自我改进型编码框架"Prime Agent"也曾表示同时追求token效率与表达能力，这表明在语言及框架设计整体层面，token成本仍是被重点考量的核心变量。
