Журнал · Rit.work

LangSelect выбирает язык кода по расходу токенов

LangSelect показывает, как выбирать язык до запуска LLM, учитывать неудачные попытки и соотносить расход токенов с долей решений, прошедших тесты.

Rit.work
Студия разработки
17 сентября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Язык, на котором LLM пишет решение, можно выбирать как переменную стоимости, если задача допускает несколько языков и проверяется одинаковыми тестами. Хотя препринт Son Ha Xuan, Phat T. Tran-Truong, Xuan-Bach Le и Nghia Duong-Trung не проходил рецензирование и содержит собственные замеры авторов, базовая эвристика сократила расход токенов на 50,3% при 92,9% решений, прошедших тесты после резервной попытки. Для таких систем язык больше не обязательно фиксировать в конфигурации: его можно выбирать перед каждой генерацией.

Почему один язык обходится дешевле другого

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

Но выбрать самый короткий язык недостаточно. Если первая реализация не проходит модульные тесты, приходится генерировать ещё одну, поэтому неудачная короткая попытка может стоить дороже одной успешной длинной. LangSelect выбирает язык до генерации, проверяет результат и при неудаче запускает резервный вариант.

Работа оценивает расход через прокси-показатель тестового контура: он считает токены самой реализации, обвязки и точки входа. Это позволяет сопоставлять языки в одинаковой среде, но результат выражает расход токенов, а не денежную стоимость всего запуска.

Проверка охватывает MultiLang-Bench — корпус из 3000 задач с проверенными решениями на 8 языках — и отдельный реальный запуск GPT-5 на 450 отложенных задачах. Поскольку материал основан на абстракте, а не на полном тексте, из него нельзя восстановить правила доменной эвристики, обучение модуля выбора и точный расчёт прокси-показателя.

Повтор готовых решений не заменяет реальную генерацию

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

Затем GPT-5 генерировал код заново. В расход попадала каждая попытка, включая решения, которые не прошли тесты, и последующие резервные генерации. Именно этот режим ближе к рабочему контуру, где ошибка расходует токены, даже если пользователь в итоге получает корректный код.

Базовая доменная эвристика, настроенная на обучающей части корпуса, уменьшила прокси-расход токенов на 50,3% и довела долю успешных задач после резервной попытки до 92,9%. Модуль выбора на CodeBERT и метаданных получил максимальную долю успешных решений — 93,8%, но увеличил расход токенов на 3,7%. Выигрыш в корректности составил 0,9 процентного пункта, однако направление изменения стоимости оказалось противоположным.

Поэтому у LangSelect нет одного победившего режима. Простая эвристика лучше выглядит при приоритете экономии, а обучаемый модуль — при приоритете прохождения тестов. Работа описывает это как границу между стоимостью и корректностью: перед запуском команда выбирает подходящую точку, а не максимизирует одну метрику в отрыве от другой.

Когда выбор языка стоит вынести в отдельный модуль

Работа меняет архитектурный план для систем, где результатом служит поведение программы, а не исходный код на заранее заданном языке. Должны выполняться два условия: несколько языков допустимы как итог и один набор тестов способен проверить каждый вариант. Если язык закреплён контрактом продукта или средой исполнения, исходная предпосылка LangSelect не выполняется.

В подходящих системах выбор языка имеет смысл отделить от генератора. Маршрутизатор получает описание задачи и доступные метаданные, выбирает первый язык, а проверяющий контур решает, нужен ли резервный запуск. Это позволяет менять правила маршрутизации без замены самой LLM.

При оценке такого контура недостаточно сравнивать длину только успешных ответов. В метрику должны попадать неудачные генерации, обвязка и резервные попытки: иначе повтор готовых решений покажет потенциал, который система не реализует при реальном запуске. Одновременно нужно отслеживать долю задач, прошедших тесты после всей цепочки попыток.

Результаты также не дают основания сразу заменять эвристику обучаемым селектором. CodeBERT повысил долю успешных решений лишь немного и одновременно увеличил расход токенов, тогда как доменная эвристика заметно его сократила. Практический следующий шаг — сравнить фиксированный язык, простые правила и обучаемый выбор на собственных задачах, считая всю цепочку генераций.

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

Ко всем материалам
Понравилось? Обсудим вашу задачу