Как честно сравнить LLM на своём коде: эксперимент с тремя моделями Claude

Когда выходит новая модель, анонс отвечает на вопрос «насколько она лучше на бенчмарках» — и не отвечает на единственный вопрос, который меня интересует: что она изменит в моей работе. Я провёл контролируемый эксперимент: три модели Claude — Fable 5, Opus 4.8 и Sonnet 4.6 — получили дословно одинаковое задание на аудит кодовой базы этого блога, каждая в изолированной копии репозитория, с заранее согласованной рубрикой оценки. В статье — сама методика, которую можно повторить на любом проекте, результаты, и отдельно — как эксперимент дважды сломался и чему это научило.

Почему бенчмарки не отвечают на мой вопрос

У публичных бенчмарков две проблемы, и обе фундаментальные. Первая — загрязнение данных: тестовые примеры просачиваются в обучающие выборки, и модель частично «вспоминает» ответы вместо того, чтобы решать задачу. Это не маргинальное подозрение, а предмет целого направления исследований: обзор Xu и соавторов (2024) систематизирует исследования загрязнения бенчмарков, а обзор EMNLP 2025 фиксирует ответ индустрии — переход от статических тестов к динамически генерируемым.

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

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

Дизайн эксперимента: один промпт, три изолированных мира

Задание для всех трёх моделей было дословно одинаковым — различались только имя ветки и папка результатов. Четыре фазы: аудит двуязычной системы статей блога с доказательством каждой находки в виде файл:строка с цитатой кода; выбор решений для трёх главных находок с описанием компромиссов; реализация одного фикса с самопроверкой; заметка о результатах на русском и английском. Полный цикл инженерной работы, а не изолированный «вопрос-ответ» — такой подход рекомендует и Anthropic: оценивать агентов на задачах из реального продукта, по рубрике, согласованной до запуска.

Три правила сделали сравнение честным:

Изоляция. Каждая модель работала в отдельном git worktree — собственной копии рабочего каталога со своей веткой. Модели физически не могли увидеть результаты друг друга или помешать друг другу.

Защита от галлюцинаций — в самом промпте. Ключевая строка задания: «выдуманная находка (несуществующий код, неверная строка) хуже, чем отсутствие находки». Без этого стимула модель, которую просят найти проблемы, склонна их «находить» в любом случае. С ним — каждая находка обязана пережить ручную проверку.

Исключение подсказок из зачёта. В репозитории лежит CLAUDE.md, где описаны известные грабли проекта — например, относительные пути к ассетам, ломающиеся на URL с языковым префиксом. Все три модели читают этот файл, поэтому такие находки «бесплатные»: они засчитываются за аккуратность, но не за глубину.

Рубрика: оценивать только то, что можно проверить руками

До запуска я зафиксировал шесть осей по пять баллов: точность аудита (ручная проверка выборки находок по файл:строка), глубина (подтверждённые находки, которых нет в подсказках), качество рассуждения о компромиссах, код и реальность самопроверки, качество русского и английского текста, дисциплина (ноль вопросов человеку, ни одного нарушения ограничений). Принцип тот же, что и у хорошего код-ревью: чем меньше ось опирается на вкус и чем больше — на проверяемый факт, тем больше ей можно доверять.

Как всё сломалось в первый раз

Первый запуск я сделал неправильно — и это оказалось самой переносимой частью эксперимента. Я открыл три интерактивные сессии параллельно в одной и той же папке репозитория. Через несколько минут в рабочем дереве лежали незакоммиченные правки, которые невозможно было атрибутировать: общий checkout означает, что когда одна сессия делает git checkout -b, ветка переключается у всех трёх, а их правки и коммиты перемешиваются. Одна из сессий вдобавок сделала git stash и смела в него всё подряд — включая мои собственные файлы, к эксперименту не относившиеся.

“Параллельные AI-агенты в одной папке — это не параллельный эксперимент. Это один большой конфликт с тремя авторами.”

– вывод, который стоил мне перезапуска

Результаты двух сессий пришлось признать непригодными: даже если бы они доработали до конца, я не смог бы честно сказать, чьи правки оцениваю. Второй запуск — уже в изолированных worktree — упёрся в лимиты тарифа: два агента погибли на старте, а третий завис, продолжая выглядеть «работающим» в интерфейсе. Диагноз поставила файловая система, а не индикатор статуса: за двадцать минут в его рабочей копии не появилось ни одного файла. Это второй переносимый урок: живость агента проверяется по изменениям на диске. После перезапуска все три модели прошли полный цикл в равных условиях.

Результаты: где модели одинаковы и где различаются

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

Дальше начинаются различия:

Качественные различия информативнее баллов. Opus 4.8 — единственный, кто не заметил сломанный заголовок Content-Type в sitemap (его нашли двое других) и оставил его в собственном фиксе; а в его русский текст протекло английское слово — «и even путь к картинке». Sonnet 4.6 сделала корректный фикс, но её самопроверка была декларативной: линтер вместо запуска. Fable 5 выделилась именно на самопроверке: обнаружила, что php на моей машине — это обёртка над docker-контейнером, смонтированным на основной каталог, перестроила все проверки через одноразовые контейнеры и прогнала свой фикс интеграционно на временной базе. Разница между «я сделал» и «я доказал, что сделал» — это и есть самая дифференцирующая ось для агентских задач.

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

Судья из числа участников

Оценку по рубрике проводила Fable 5 — та же модель, что участвовала в сравнении. Это методическая дыра, и о ней надо говорить прямо: LLM-судьи систематически завышают оценки собственным текстам, причём склонность тем сильнее, чем лучше модель узнаёт свои тексты — это показано в работе Panickssery и соавторов на NeurIPS 2024. Смягчить смещение можно двумя способами, и я использовал оба: во-первых, максимально сместить рубрику от вкусовых осей к проверяемым фактам — точность строк, полнота фикса, протёкшее иноязычное слово не зависят от симпатий судьи; во-вторых, явно задекларировать конфликт и отдать спорные оси на перекрёстную проверку другой модели или человеку. Субъективные оси моего итога — качество текста, качество рассуждения — стоит читать с этой поправкой.

Ограничения честности

Один прогон на модель — это n=1: различия в один-два балла ничего не значат, доверять стоит только качественным разрывам — пропущенному багу, глубине самопроверки. Эксперимент измеряет три модели на одной задаче в одном домене; «Fable 5 лучше вообще» из него не следует. И стоит помнить про цену: топ-модель потратила в 1,6 раза больше токенов и почти вдвое больше времени, чем самый экономный участник, а её токен по прайсу ещё и дороже сам по себе — для регулярных задач это весомый аргумент в пользу моделей попроще.

Что я забираю себе

Методика свелась к короткому чек-листу, который работает для любого проекта и любых моделей:

• Тестовое задание — полный цикл реальной работы на своём коде, а не синтетическая задачка.
• Один промпт для всех, изоляция через отдельные worktree, результаты — в отдельные ветки.
• В промпте — явная цена галлюцинации: выдуманная находка хуже отсутствия находки.
• Подсказки, доступные всем (документация, заметки в репозитории), исключаются из зачёта глубины.
• Рубрика фиксируется до запуска и опирается на проверяемые факты, а не на впечатление.
• Выборку находок проверять руками; совпадение топ-находок у независимых моделей — сигнал их реальности.
• Судья-участник — задекларированный конфликт: спорные оси отдавать на перекрёстную оценку.
• Живость агента проверять по диску, а не по индикатору в интерфейсе.

Бонус, который не входил в план: эксперимент окупился сам. Три независимых аудита нашли в блоге реальные проблемы — от sitemap без английских страниц до мёртвых запросов в контроллере — и два готовых фикса уже лежат в ветках, дожидаясь переноса в прод. Сравнение моделей на своём коде, в отличие от чтения бенчмарков, оставляет после себя не только мнение.

Источники и ориентиры

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — систематизация проблемы загрязнения бенчмарков; главный аргумент в пользу тестов на собственном коде.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — как индустрия уходит от статических тестов к динамическим; мой эксперимент — частный случай динамического теста.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — практика оценки агентов: задачи из реального продукта, проверяемые рубрики, различие траектории и результата.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — почему модель-судья завышает оценки себе и что с этим делать.
• Run parallel sessions with worktrees (Claude Code Docs) — штатный механизм изоляции параллельных агентских сессий, без которого первый запуск эксперимента и развалился.