Мы выбирали модель для AI-наставника по программированию. Сначала дорогая нейросеть проиграла дешёвой. Через неделю победитель сам уступил другому кандидату.
В конце июля мы выбирали нейросеть для AI-наставника в редакторе кода Koddo. На первый взгляд задача простая: взять самую умную модель, подключить её к чату и получить лучшие ответы.
Для учебного продукта этот подход не работает.
Наставник должен найти ошибку в чужом коде, объяснить её понятным языком и оставить ученику следующий шаг. Если модель сразу напишет готовое решение, она справится как программист, но провалится как преподаватель.
За неделю мы провели два теста. В первом восемь моделей дали 48 ответов. Во втором шесть моделей прошли 96 проверок. Сначала дорогая модель проиграла более дешёвой, затем победитель первого теста уступил другому кандидату.
Эта история показывает, почему место в общем рейтинге и цена запроса мало говорят о качестве конкретного AI-продукта.
Что значит «лучшая модель» для наставника
Обычный ассистент получает вопрос и старается дать максимально полный ответ. У учебного наставника задача сложнее.
Мы оценивали четыре свойства:
- правильно ли модель нашла причину ошибки;
- помогла ли разобраться, а не просто выдала ответ;
- насколько естественно она пишет по-русски;
- можно ли сократить ответ без потери пользы.
Кроме содержания были продуктовые ограничения. Ответ должен появляться быстро, укладываться в ограниченный объём и не стоить дороже списываемого с пользователя кредита.
Есть и ещё одна граница: модель не должна дописывать решение за ученика. Например, если она видит такую заготовку:
def normalize(text):
passХороший наставник объяснит назначение функции и подскажет, с чего начать. Плохой для учебного сценария, хотя технически сильный, сразу вставит готовое тело функции.
«Лучшей» становится не модель с самым высоким общим интеллектом, а модель, которая точнее выполняет конкретную роль.
Первый тест: дешёвая модель обошла дорогую
В первом бенчмарке мы сравнили восемь моделей на шести реалистичных диалогах. Ответы обезличили, чтобы название поставщика и репутация модели не влияли на оценку.
Лучшие результаты выглядели так:
- Qwen3 Max — 4,75 балла;
- Qwen Plus — 4,62 балла;
- Claude Sonnet 5 — 4,46 балла.
Самый высокий балл получила Qwen3 Max. Но в потоковых ответах она не сообщала точное количество использованных токенов. Пришлось бы оценивать расход по длине текста, а для русского языка такая оценка занижала бы стоимость примерно вдвое.
Поэтому мы выбрали Qwen Plus. Она немного уступила лидеру по ответам, зато позволяла точно учитывать расходы.
Sonnet 5 оказалась дороже и в нашем сценарии набрала меньше баллов. На одном и том же проверочном вопросе вызов Sonnet стоил 1,345 ₽, а Qwen Plus — 0,185 ₽. При этом Qwen последовательно разобрала три дефекта в коде и закончила предложением дать подсказку, не выдавая решение.
Была и техническая проблема. В нашей конфигурации через используемый шлюз Sonnet иногда тратила весь лимит ответа на внутренние рассуждения. Пользователь ждал, но в конце получал пустое сообщение.
Важно: это не означает, что Qwen Plus сильнее Sonnet 5 вообще. Результат относится к нашему промпту, шлюзу, ограничениям длины и шести учебным диалогам. Для другой задачи победитель мог быть другим.
28 июля мы перевели AI-наставника на Qwen Plus.
Ошибка из продакшена изменила результат
Через несколько дней пользователь сообщил о неправильном объяснении поведения Python. Ошибка касалась метода strip().
Аргумент strip(chars) выглядит как строка, которую нужно удалить с краёв. На самом деле Python воспринимает его как набор отдельных символов. Например:
print('cabba'.strip('ab'))
# cСправа последовательно удаляются все a и b, пока не встретится символ вне набора. Метод не ищет точную подстроку ab. Такое поведение описано в официальной документации Python.
Qwen Plus объяснила этот нюанс неправильно. Причём ответ выглядел убедительно: хороший русский язык, спокойный тон, понятная структура. Стилевая оценка не помогла заметить фактическую ошибку.
Мы поняли, что первый тест слишком хорошо измерял форму ответа и недостаточно строго проверял знание языка программирования.
Второй тест: 96 ответов с проверяемой истиной
Новый бенчмарк включал 16 ходов на каждую из шести моделей. Внутри были вопросы о 12 нюансах семантики Python, раунд с возражением пользователя и четыре проверки на утечку готового решения.
Факты проверяли запуском кода, а не впечатлением от текста. Если модель утверждала, что round(2.5) вернёт определённое значение, мы запускали Python и сравнивали результат.
Qwen Plus набрала 1,75 из 2 по фактической точности. Ошибка с strip() повторилась.
GPT-5.4 Mini получила 2,00 из 2. Она не изменила правильный ответ после возражения пользователя, отвечала в полтора раза быстрее и в среднем использовала вдвое меньше токенов.
Кроме того, это была единственная модель из шести, которая объяснила заготовку с pass, не продиктовав ученику готовую строку решения.
Стоимость одного хода выросла примерно с 0,06 до 0,16 ₽. Для операции ценой в один кредит эта разница не влияла на экономику продукта.
4 августа мы заменили Qwen Plus на GPT-5.4 Mini в роли основного наставника.
Почему два бенчмарка выбрали разных победителей
Модели не успели радикально измениться за неделю. Изменился вопрос, который мы задавали тесту.
Первый бенчмарк спрашивал: «Какой ответ выглядит наиболее полезным для ученика?» Он хорошо измерял стиль, диагностику и отказ от спойлеров.
Второй спрашивал: «Какая модель правильно знает Python, выдерживает давление пользователя и при этом остаётся наставником?» У него была проверяемая истина, поэтому уверенный, но ошибочный ответ больше не мог спрятаться за хорошей формой.
Бенчмарк не отвечает на вопрос «какая модель лучшая». Он отвечает на вопрос, который вы в него заложили.
OpenAI в рекомендациях по оценке моделей тоже подчёркивает: измеряемая способность зависит не только от модели, но и от среды, инструментов и тестового стенда. Поэтому выводы бенчмарка должны соответствовать тому, что он действительно проверял.
Иногда тест модели находит ошибку не в модели
Все 96 ответов второго бенчмарка мы дополнительно пропустили через защиту от готовых решений. Она должна скрывать фрагменты, где наставник фактически пишет код за ученика.
Проверка неожиданно нашла две ошибки уже в нашей системе.
В первом случае минус внутри строки strip('-') принимался за математическую операцию. Полезное объяснение ошибочно выглядело как готовое вычисление и скрывалось.
Во втором случае система считала любое имя из кода принадлежащим задаче. Из-за этого рассказ о стандартной функции round() мог восприниматься как передача части решения.
До исправления защита скрывала 25 нормальных фрагментов вне специальных проверок на утечку. После исправления осталось 18. Все реальные случаи передачи готового решения продолжили блокироваться.
Так бенчмарк моделей нашёл дефект в окружающем коде. Пользователь взаимодействует не с нейросетью отдельно, а со всей системой: промптом, контекстом, ограничениями, фильтрами и интерфейсом.
Цена и скорость тоже входят в качество
Представим две модели. Первая отвечает чуть точнее, но работает десять секунд и иногда возвращает пустое сообщение. Вторая отвечает за три секунды и стабильно показывает результат.
В лабораторной таблице первая может оказаться выше. В редакторе кода пользователь выберет вторую, потому что он ждёт подсказку прямо во время работы.
То же самое со стоимостью. Если дорогая модель улучшает один ответ из ста, нет смысла отправлять к ней остальные 99 запросов.
Исследователи RouteLLM проверяли похожий подход: обычные запросы направлялись к дешёвой модели, а сложные — к более сильной. На части тестов такая маршрутизация снизила расходы более чем вдвое без ухудшения качества.
Для продукта это может выглядеть ещё проще. Обычный запрос обрабатывает быстрая модель, а после неудачного ответа пользователь нажимает «Разобрать глубже» и явно соглашается на более дорогой вызов.
Так сильная модель используется там, где её дополнительная способность влияет на результат, а не включается на каждое «почему здесь IndexError?».
Как выбирать модель для своего продукта
Название модели и место в публичном рейтинге годятся для первого списка кандидатов. Окончательный выбор требует собственного теста.
- Возьмите реальные запросы. Добавьте неприятные случаи из поддержки, а не только аккуратные демонстрационные примеры.
- Определите недопустимые ошибки. Заранее зафиксируйте, что считается правильным ответом и какой провал блокирует запуск.
- Проверяйте код кодом. Числа, поведение языка и формат данных лучше подтверждать выполнением программы, а не мнением другого AI-судьи.
- Сравнивайте вслепую. Вместе с качеством записывайте задержку, токены, стоимость и долю пустых сообщений.
- Возвращайте сбои в тест. Каждый новый производственный дефект должен становиться постоянной проверкой.
Именно один пользовательский вопрос о strip() заставил нас пересобрать проверку и сменить модель.
Победитель такого бенчмарка тоже не становится лучшим навсегда. Он остаётся подходящим, пока не появятся новые задачи, модели или данные.
Посмотреть, как результаты этого бенчмарка применяются в AI-наставнике, можно в Koddo.
А вы бы доверили выбор нейросети общему рейтингу или сначала проверили её на 30 самых сложных запросах своих пользователей?
Источники
- Внутренние бенчмарки Koddo от 28 июля и 4 августа 2026 года: 8 моделей × 6 ходов и 6 моделей × 16 ходов.
- Документация Python по
str.strip(). - OpenAI: подход к достоверной оценке моделей.
- RouteLLM: Learning to Route LLMs with Preference Data.
- Первая публикация статьи на vc.ru.