Как оценивать LLM для кодинга без слепой веры в бенчмарки: практическое оружие

Публичные бенчмарки лгут. А вы им верите

Открываете очередную сравнительную таблицу. DeepSeek-Coder-V2-Lite на HumanEval — 78%. Llama 3.1 Coder — 69%. Берете модель с лучшим результатом, запускаете на своем проекте — и получаете код, который выглядит так, будто его писал стажер после трех энергетиков. Знакомо?

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

Зачем вообще оценивать самому?

Три причины, каждая из которых бьет по бюджету или по нервной системе:

• Контекст — это все. Модель, которая блестяще решает алгоритмические задачки, может сломаться при попытке понять архитектуру вашего монолита на Django. Вам нужна модель, которая умеет читать ваш код, а не учебник.
• Публичные тесты оптимизированы. Команды, разрабатывающие модели, знают о существовании HumanEval, Aider Polyglot и других бенчмарков. Есть подозрение (сильное подозрение), что они натаскивают свои модели именно на эти датасеты. Вы получаете чемпиона по сдаче экзаменов, а не инженера.
• Стоимость и латентность имеют значение. 7B модель может работать на вашем ноутбуке в реальном времени. 70B — уже требует серьезного железа или облака. Если разница в качестве для ваших задач составляет 5%, а разница в скорости и цене — 300%, выбор очевиден. Но только если вы знаете эту разницу в качестве.

Наш путь — бросить таблицы и начать тестировать модели так, как будто мы нанимаем их на работу. С собеседованием.

Инструменты для реалистичной оценки

Забудьте про абстрактные скрипты. Мы будем использовать инструменты, которые уже есть в вашем арсенале или должны там быть.

1 Aider — ваш главный союзник

Aider — это не просто инструмент для pair programming с ИИ. Это идеальный полигон для тестирования. Почему? Потому что он работает в контексте реальной кодовой базы. Модель видит не чистый лист, а ваши файлы, ваши импорты, ваши стили.

Установите Aider, если еще нет:

pip install aider-chat

Теперь запустите его с разными моделями. Для локальных моделей через Ollama это выглядит так:

# Тестируем Codestral
MODEL=codestral:latest aider

# Тестируем DeepSeek Coder
MODEL=deepseek-coder:latest aider

# Тестируем Llama Coder
MODEL=llama3.2-coder:latest aider

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

2 Создаем свой «датасет» из реальных задач

Не нужно изобретать 100 задач. Возьмите 5-10, но таких, с которыми вы сталкиваетесь каждый день.

Ваша задача — не оценить, решила ли модель задачу. Ваша задача — оценить, как она ее решила.

3 Система оценки: субъективная, но последовательная

Заведите таблицу (хоть в Google Sheets, хоть в Markdown). Для каждой модели и каждой задачи выставляйте баллы по критериям. Не усложняйте. 1-3 балла по каждому пункту.

• Скорость ответа: 1 (медленно) — 3 (мгновенно)
• Качество кода (стиль, чистота): 1 (спагетти-код) — 3 (идеально под стиль проекта)
• Понимание контекста: 1 (игнорирует существующий код) — 3 (идеально интегрируется)
• Правильность решения: 1 (не работает) — 3 (работает без доработок)
• Объяснения (если просите): 1 (бессвязно) — 3 (четко и по делу)

Самое важное — вести записи. Через неделю вы забудете, почему поставили Codestral 2 балла за стиль, а Llama — 3. Пишите короткие комментарии: «добавил лишние пустые строки», «использовал устаревший метод .append()».

Автоматизация — там, где она нужна

Субъективная оценка — это основа. Но некоторые вещи можно и нужно автоматизировать.

Напишите простой скрипт, который будет проверять, что сгенерированный код:

# Пример проверки для Python
import ast
import subprocess

def validate_generated_code(filepath):
    """Проверяет, что код синтаксически корректен и проходит линтер."""
    try:
        with open(filepath, 'r') as f:
            ast.parse(f.read())  # Проверка синтаксиса
        
        # Запуск black в режиме проверки (если используете)
        result = subprocess.run(
            ['black', '--check', '--quiet', filepath],
            capture_output=True
        )
        if result.returncode == 0:
            return "✅ Синтаксис и стиль в порядке"
        else:
            return "⚠️  Стиль не соответствует black"
            
    except SyntaxError as e:
        return f"❌ Синтаксическая ошибка: {e}"

# Аналогично можно добавить mypy для типов, pytest для запуска тестов и т.д.

Такой скрипт не скажет, хороший ли это код. Но он отфильтрует откровенный брак — синтаксические ошибки, грубые нарушения стиля. Это экономит время.

Типичные ошибки при самостоятельной оценке

Я видел, как люди делают эти ошибки. Вы не должны их повторять.

1. Тестирование на слишком простых задачах. Если ваша задача решается одним промптом в ChatGPT — вы не тестируете модель, а тестируете свое умение формулировать простые запросы. Берите сложные, многокомпонентные задачи.
2. Использование разных промптов для разных моделей. Это фатально. Если для Codestral вы пишете «напиши функцию», а для DeepSeek — «создай, пожалуйста, функцию, которая бы...», вы сравниваете не модели, а свои промпты. Используйте идентичные формулировки. Сохраните их в файл.
3. Игнорирование контекста предыдущих сообщений. В реальной работе вы общаетесь с моделью в диалоге. Тестируйте и это: задайте уточняющий вопрос, попросите переписать часть кода, исправить ошибку. Некоторые модели отлично стартуют, но полностью теряют нить после третьего сообщения.
4. Оценка только по конечному результату. Процесс тоже важен. Модель, которая предлагает три варианта решения с плюсами и минусами, может быть полезнее модели, которая сразу выдает работающий, но хрупкий код.

Помните историю про провал промпт-инжиниринга? Там как раз пытались автоматизировать сложную задачу, не поняв ограничений модели. Не попадайте в ту же ловушку при оценке.

Что делать с результатами?

Вы протестировали 3-5 моделей на своем наборе задач. У вас есть таблица с баллами и комментариями. Что дальше?

Не ищите абсолютного победителя. Ищите лучшую модель для конкретных сценариев.

• Модель А блестяще справляется с рефакторингом Python, но путается в JavaScript. Отлично, используйте ее для бэкенд-задач.
• Модель B медленная, но ее код почти никогда не требует правок. Подойдет для code review или написания критичного кода, где важна точность, а не скорость.
• Модель C маленькая и быстрая, идеально работает с шаблонными задачами (генерация CRUD, простые тесты). Запускайте ее локально на слабом железе для рутинных задач.

Именно так вы и приходите к осознанному выбору, о котором говорилось в гиде по лучшим opensource LLM. Но теперь этот выбор основан на ваших данных, а не на чужих цифрах.

Следующий уровень: заставляем модели спорить

Если вы уже определили 2-3 сильные модели, попробуйте запустить их одновременно. Инструменты вроде Owlex MCP-сервера позволяют получить ответы от нескольких моделей параллельно.

Это не просто для развлечения. Когда вы видите три разных подхода к одной задаче, вы:

• Лучше понимаете саму задачу.
• Видите альтернативные решения, которые не пришли бы в голову.
• Можете выбрать лучшее из предложенного или скомбинировать подходы.

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

А если после всех тестов вы все еще не можете выбрать — возможно, проблема не в моделях. Может, стоит вернуться к основам и почитать, почему LLM вообще не понимают, чего вы хотите. Но это уже совсем другая история.