LLM про корректность, не про производительность

пока что

Недавние исследования (раз, два) подсвечивают "особенность" современных LLM:

«... модели хорошо чинят баги и закрывают задачи, но это умение не переносится на оптимизацию производительности. Современные LLM заточены под корректный код, а не под быстрый.»

Причина не в том, что модели "не могут" в перформанс, а в том, как их обучают и оценивают.

Основные бенчмарки (HumanEval, MBPP, SWE-bench) делают упор на корректность генерируемого кода (pass@k). Метрики эффективности (eff@k) существуют, но пока не стали стандартом.

То есть "перформанс" сейчас не входит в KPI моделей.

———

Первая работа проверяла, насколько модели способны ускорять код: найти узкое место, внести фикс, попутно ничего не сломав.

За 1.0× брали результат человека-эксперта по кодовой базе:

Top-Expert          1.000×
GPT-5               0.150×  
Claude 4.1 Opus     0.098×
Qwen3 Coder Plus    0.064×
Claude 3.7 Sonnet   0.047×
Claude 4.5 Sonnet   0.041×
GLM-4.6             0.026×
GPT-5 Mini          0.019×
Kimi K2-0905        0.008×
Gemini 2.5 Flash    0.008×
DeepSeek V3.1       0.007×
Gemini 2.5 Pro      0.007×

Таким образом, лучшая модель (GPT-5) достигла лишь 15% от ускорения, которое показал человек-эксперт.

А в среднем модели показывали результаты на уровне погрешности.

———

Во второй работе проверяли, можно ли снизить регрессию производительности промптингом. Сравнивали два подхода:

1) few-shot: даём примеры эффективного кода
2) chain-of-thought: просим рассуждать пошагово

За 100% взят уровень регрессий без промпта. Если меньше, то промпт помог, если больше, то навредил. (скрин в комментах)

few-shot почти всегда уводит регрессии ниже 100%, а результаты chain-of-thought неоднозначны: где-то помогает, а где-то делает только хуже.

Как нетрудно догадаться, когда LLM дают примеры эффективного кода (мы же так и делаем, верно?🙂), результат стабильно лучше, чем когда мы просто просим её "хорошо подумать".

———

Среди основных слабостей LLM отмечают:

1) неверно идентифицируют узкое место
2) бросают на полпути, найдя любое ускорение
3) используют костыли вместо системных решений
4) подгоняют решение под тесты, периодически ломая корректность

———

В любом случае, на сегодня "человек с perf'ом" в руках остается важнейшим звеном в вопросах производительности.

А с растущим объёмом генерируемого кода эта роль только усиливается.

———

Хотя вопросы появляются:

1) 15% от "экспертного" уровня это много или мало? И сколько покажет обычный, пусть и опытный, разработчик?
2) Как скоро эффективность кода станет для LLM полноценным KPI?