AlgoTune: Can Language Models Speed Up General-Purpose Numerical Programs? (блог) Интересный бенчмарк, появившийся совсем недавно. Авторы взяли несколько популярных Python-репозиториев, заплатили 21 эксперту, чтобы те нашли функции/методы, отвечающие определённым критериям — всего 155 штук. Эти же эксперты написали data generator и verifier: первое генерирует аргументы для вызова функции, а второе проверяет результат. Затем на эти функции натравили LLM-агентов с просьбой переписать их так, чтобы они проходили все проверки корректности, но при этом работали быстрее. Каждый раз, когда LLM вносила изменение, его прогоняли несколько раз, замеряли время и отдавали модели как обратную связь. Оценка агента — гармоническое среднее ускорения на всех задачах (x1.2 означает ускорение на 20% по отношению к имеющемуся коду). Каждый агент имел бюджет в $1, и информация о балансе передавалась в промпт — чтобы LLM могла планировать сама, когда выгоднее рисковать и пробовать новые подходы, а когда стоит немного шлифануть уже готовое решение. Ну и получается, что этот бенчмарк штрафует дорогие модели: они могут сделать меньше попыток, а значит получат меньше обратной связи и, скорее всего, их решение будет похуже. Так и вышло: в топе o4-mini, DeepSeek R1 (из-за дешевизны API) и GPT-5. Они дали x1.65-x1.7. Совсем свежая gpt-oss-120b обошла Claude Opus 4/4.1 — но не потому что она суперумная, а потому что копеечная, и смогла сделать больше попыток. К примеру, вот в этой задаче oss-агент сделал 121 действие, а Opus — 8. И то и то по доллару, но просто за счёт количества попыток gpt-oss чуть-чуть опередила Opus 4 (но не 4.1). Прикольно, что такие ускорения — в некоторых случаях более чем в 5-7 и даже 10 раз — всё ещё можно найти для методов в популярных библиотеках вроде NumPy, SciPy, NetworkX. Хотя казалось бы эти столпы Data Science должны быть уоптимизированы в нуль. Вот бы кто-нибудь автоматизировал этого агента для прогона по большому количеству репозиториев на разном языке, и как бы весь софт в мире враз стал быстрее 😏 === На всякий случай напишу: никаких прорывных супер алгоритмов модели не придумали. В основном оптимизации были поверхностными. Но неэффективностей в существующем коде достаточно, чтобы даже это приносило плоды.