model-compare.md

Исходные данные

Что именно тестировал:

• Один реальный diff: ~7000 строк, 29 файлов.
• Домейн: улучшения Memory Layer (несколько фаз, много асинхронщины, concurrency и инфраструктурного кода).
• 18 заранее известных багов, размеченных руками:
  • CRIT/HIGH/MED/LOW;
  • от банальных “перепутали поле в JSON” до гонок на dict, resource leak и N+1 запросов.
• 17 моделей:
  • OpenAI: GPT‑5.2 (2 прогона), GPT‑5‑mini, GPT‑4.1‑nano, O4‑mini.
  • Google: Gemini 3 Flash (r1/r2), Gemini 3 Pro, Gemini 2.5 Pro.
  • Anthropic: Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5.
  • Остальные: DeepSeek V3‑2, DeepSeek V3‑2 Speciale, Qwen3, Qwen‑Max, GLM‑4.5, Grok‑3, Grok‑4 и др.
• Для каждой модели:
  • прогонял один и тот же diff;
  • собирал JSON с findings;
  • каждую находку проверял руками: “реальный баг/мимо/стилистика/фантазия”.

Важный момент: это один большой стресс‑тест, а не универсальный бенчмарк всех LLM на свете. Но он достаточно злой: много асинхронщины, concurrency, сложной логики и инфраструктуры.

Краткий итог (если лениво читать всё)

• GPT‑5.2 — лучший баланс “находит баги / не сходит с ума / стоит адекватно”.
• Gemini 3 Flash — примерно такое же покрытие багов, но гораздо дешевле и быстрее; особенно хорош на перформанс‑ и инфраструктурных штуках.
• Claude Opus 4.5 — премиум по качеству и аккуратности, но дороже GPT‑5.2 при похожем recall.
• Gemini 2.5 Pro — лучший “бюджетный рабочий конь”: аккуратные findings, высокая precision, смешная цена.
• DeepSeek V3‑2 / GLM‑4.5 — нишевые “охотники за редкими багами”: мало известных багов, но иногда попадание в то, что остальные пропускают.
• Часть моделей (O4‑mini, Qwen‑Max, Grok‑3/4, GPT‑4.1‑nano, DS Speciale) не годятся как единственный gatekeeper: спокойно говорят APPROVE при наличии критических дефектов.

Ниже — детали.

Какие баги лежали в эталоне

Примеры референс‑багов (упрощённо, без кода):

• fact_tier вместо tier (CRIT) Неверное поле в JSON/модели: логика опирается на tier, а в одном месте используют fact_tier. Типичный “легко заметить по внимательному diff‑у”, но многие модели промахнулись.

• verified_by вместо evidence_verified_by (CRIT) Аналогично: критичный сдвиг в семантике, который ломает downstream‑логику.

• UTC не импортирован → NameError (CRIT) Классический runtime‑краш: в коде используют UTC, но нужный импорт отсутствует.

• Мутация dict без lock (HIGH) Многопоточный/асинхронный код меняет общий dict без синхронизации: типичный race.

• Итерация по dict в shutdown (HIGH) В момент завершения сервиса идёт перебор той же структуры, которую другие ветки могут менять.

• task.cancel() без await (HIGH) Грязный async‑паттерн: задачи отменяются, но не дожидаются корректного завершения, что ведёт к висящим таскам и странным эффектам.

• Resource leak в __main__.py (HIGH) Не закрывается ресурс (соединение/клиент/файл) на hot‑path’е.

• UUID semantic search broken (HIGH) Логика поиска по UUID/semantic‑индексу сломана (ошибки в запросе/нормализации).

• tiktoken import crash (HIGH) При определённых условиях модуль падает сразу при импорте.

• N+1 Search Queries (HIGH) Классика: для списка из N сущностей вызывается отдельный запрос, вместо батча.

• Double __aexit__ call (HIGH) Контекстный менеджер вызывают некорректно, что приводит к повторному __aexit__ и странному поведению.

• Missing CLI auth headers (MED) CLI делает вызовы к API без обязательных заголовков авторизации.

• И несколько LOW‑багов вокруг:

  • хрупкой вставки контекста;
  • неэффективного legacy‑кода;
  • дропа коротких токенов и т.д.

Все 18 багов были проверены в реальном коде: это не synthetic “придуманные антипаттерны”.

Как модели себя показали по этим багам

GPT‑семейство

GPT‑5.2 (два прогона)

• Нашёл больше всего багов среди всех моделей:
  • в одном срезе — 8/18 багов;
  • в “ключевом” наборе из 7 багов — до 71% recall.
• Очень высокая precision:
  • примерно 93% на основных срезах;
  • единичные FP вроде жалобы на “отсутствующий import”, который на самом деле есть.
• Хорошо ловит:
  • критические ошибки в полях (fact_tier, verified_by);
  • проблемы с импортами (UTC);
  • часть concurrency‑багов (dict mutation/iteration race);
  • resource leak’и.
• По времени не самый быстрый, но вменяемый.
• По цене дешевле Opus и многих “премиум”‑вариантов.

Итого: если нужен один основной LLM для ревью продового кода — GPT‑5.2 выглядит наиболее здраво.

GPT‑5‑mini

• Находит заметное число багов, но при этом:
  • стоит сопоставимо с GPT‑5.2 (в этом тесте даже дороже),
  • при этом особо не выигрывает в качестве.
• В отчёте вывод простой: “не оправдывает цену” по сравнению с GPT‑5.2.

GPT‑4.1‑nano

• Очень дорогой прогон, низкий recall.
• Итогом получил жирное “НЕ РЕКОМЕНДУЕТСЯ” в роли code review‑модели.

O4‑mini

• Критика жёсткая: модель дала APPROVE при наличии критических багов.
• Нашла считанные проблемы, пропустила много важного.
• Как “помощник по дизайну” ещё ок, но как gatekeeper — нет.

Gemini‑семейство

Gemini 3 Flash (r1/r2)

• r1:
  • нашёл 8/18 багов, без ложных срабатываний;
  • дешёвый (порядка $0.06);
  • быстрый (в районе полутора минут).
• r2:
  • чуть меньше багов, одно FP, ещё дешевле (ещё агрессивнее по цене/токенам).
• Очень хорошо чувствует:
  • перформанс (N+1);
  • инфраструктурные вещи (CLI auth headers, double __aexit__);
  • некоторые тонкие места вроде дропа коротких токенов.
• Внутренний вывод отчёта:
  • “лучшее соотношение цена/скорость среди Gemini”,
  • отлично работает в паре с 2.5 Pro.

Gemini 3 Pro

• После фикса параметров (max_tokens) нашли ещё два новых бага:
  • сломанный UUID search,
  • tiktoken import crash.
• Всего багов меньше, чем у Flash и GPT‑5.2, но:
  • 100% precision;
  • есть важные уникальные находки.
• Существенно дороже Flash и 2.5 Pro.

Gemini 2.5 Pro

• Очень аккуратное поведение:
  • 100% precision;
  • разумный recall;
  • смешная стоимость (десятые доли цента).
• В доке он фигурирует как:
  • “лучший budget‑вариант”;
  • модель, которую имеет смысл использовать как основной ревью‑движок в Gemini‑стеке, если нужен стабильный результат без шума.

Claude‑семейство

Claude Opus 4.5

• Высокое качество:
  • 0 FP;
  • recall в диапазоне 57–71% по разным срезам.
• Очень аккуратные объяснения и хороший вкус к архитектуре.
• Главный минус — цена: модель заметно дороже GPT‑5.2 при похожем покрытии.
• Итог: “premium качество, но дорогой”. Использовать точечно на критичных кусках кода, а не заливать им всё подряд.

Claude Sonnet 4.5 / Haiku 4.5

• В разы дешевле Opus, но и заметно хуже по recall.
• Haiku очень быстрый, но в этом тесте не победитель по багам.
• Haiku умудрился дать 1 FP.
• Вывод: Sonnet/Haiku — не замена Opus как code review‑движка, скорее “лайтовые” варианты.

Остальные модели

DeepSeek V3‑2

• В целом мало найденных известных багов.
• Но:
  • нашёл уникальный баг с task.cancel() без await, который другие игнорировали;
  • неплохо подмечает стилевые и архитектурные проблемы.
• В отчёте его позиционируют как:
  • “хороший баланс цена/качество для некритичного кода”;
  • полезен как второй взгляд в ансамбле, особенно по async/concurrency.

DeepSeek V3‑2 Speciale

• В этом прогоне “сломана”:
  • всего несколько токенов на выходе;
  • 0 findings;
  • дала APPROVE при критических багов.
• Как есть — использовать нельзя.

Qwen3 / Qwen‑Max

• Qwen3:
  • быстрый и дешёвый,
  • но слабый по качеству (минимальное количество реальных багов).
• Qwen‑Max:
  • 100% precision, но 0% recall по известным багам;
  • больше подходит для design review, чем для поиска дефектов.

GLM‑4.5

• Практически 0 recall по известным багам.
• Зато нашёл уникальную race condition, которую остальные не заметили.
• Нишевый “сканер хитрых мест”, но не основной ревьюер.

Grok‑3 / Grok‑4

• Быстрые и дешёвые, но:
  • практически не находят баги;
  • больше рассуждают о дизайне.
• Grok‑4, как и O4‑mini, умудрился дать APPROVE при наличии критических ошибок.

Ансамбли: зачем и какие работают

Вместо “одна модель решит всё” в отчёте пробовали простые ансамбли (2 модели параллельно).

Примеры, которые показали себя лучше всего:

1. GPT‑5.2 + DeepSeek V3‑2

   • GPT‑5.2:
     • основные критические баги;
     • concurrency, ресурсы, поля, импорт.
   • DeepSeek:
     • async‑углы (task.cancel() и компания);
     • стилевые и архитектурные замечания.
   • В сумме покрытие известных багов сильно растёт, цена остаётся вменяемой.

2. Gemini 2.5 Pro + DeepSeek V3‑2

   • Gemini:
     • UTC‑импорт, гонки, leaks, инфраструктура.
   • DeepSeek:
     • дополняет находками по асинхронщине и стилю.
   • Это “бюджетный ансамбль”: не бьёт по кошельку, но заметно расширяет coverage.

В целом вывод простой: две разные модели, запущенные параллельно, дают сильно больше, чем одна, а цена остаётся приемлемой.

Как я бы это использовал в реальной жизни

Если выбирать “прямо сейчас для прод‑репозитория”, после этого эксперимента я бы делал так:

• Основной ревьюер:
  • GPT‑5.2 или Gemini 3 Flash (в зависимости от стека/стоимости).
• Дополнительно для критичных изменений:
  • точечный прогон через Claude Opus (дорого, но очень аккуратно).
• Для максимального покрытия:
  • ансамбль GPT‑5.2 + DeepSeek V3‑2 или
  • ансамбль Gemini 2.5 Pro + DeepSeek V3‑2.
• Модели, которые нашли мало багов или дали APPROVE при CRIT‑ошибках:
  • использовать разве что как “мнение по дизайну”, но не как gatekeeper.

При этом человеческий ревью никуда не девается. LLM удобны как:

• быстрый фильтр очевидных багов;
• автоматизированный “второй взгляд”;
• инструмент для объяснения сложных кусков кода.

Но финальное “merge / не merge” всё равно остаётся за людьми.

Ограничения эксперимента (чтобы не делать неправильных выводов)

• Один diff, пусть и большой: другие языки/стили/фреймворки могут вести себя иначе.
• 18 багов — хороший, но не бесконечный набор.
• Конфигурации моделей (температура, системные подсказки и пр.) тоже влияют на результат.
• Всё это — срез на конкретную дату; модели эволюционируют.

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

• кто вообще умеет находить реальные баги;
• кто склонен к фантазиям;
• кому можно доверить “REQUEST_CHANGES”;
• а кто опасно легко нажимает “APPROVE”.