30 августа 2026 года JetBrains опубликовала анализ методологии оценки больших языковых моделей, используемых внутри агента программирования Junie, призвав отказаться от зависимости только от одного показателя — «коэффициента решения» (resolve rate). Компания считает, что важно знать, прошёл ли агент тесты задачи, но это само по себе не показывает, как он достиг результата, сколько это стоило и был ли программный патч ограниченным и пригодным для сопровождения.
Идея основана на сравнении, проведённом JetBrains между Claude Opus 4.7 и Gemini 3.5 Flash на собственном бенчмарке. Обе модели решили одинаковое число задач, однако Opus в среднем потребовалось 184 шага, а стоимость выполнения составила 2,79 доллара, тогда как Gemini потребовалось 271 шаг и 1,24 доллара. Идентичный итоговый результат не отразил заметных различий в траектории выполнения или эффективности использования инструментов.
Что скрывает коэффициент решения?
Junie работает в контексте issue и программного репозитория, позволяя модели просматривать файлы, искать символы, изменять код, выполнять команды и запускать тесты. Эти действия формируют «траекторию выполнения», которую можно отслеживать, не утверждая, что она раскрывает внутреннее мышление модели. По этой траектории можно понять, определил ли агент место проблемы до внесения изменений, повторял ли поисковые операции, проверял ли свои предположения или завершил задачу без проверки итогового патча.
Поэтому JetBrains предлагает конвейер, объединяющий четыре направления оценки: функциональный результат, эффективность выполнения, качество патча и качество процесса. Конкретные измерения включают результаты тестов, время выполнения, число токенов, вызовов модели и инструментов, стоимость, количество изменённых файлов и символов, изменение сложности, повторные операции чтения файлов, повторное выполнение команд, результаты которых не изменились, а также циклы сбоев инструментов.
От результата к траектории его достижения
JetBrains проверила методологию на четырёх бенчмарках, включавших 523 задачи, при сравнении Claude Opus 4.7 и Gemini 3.5 Flash. Opus решил 267 задач, или 51,1%, тогда как Gemini решил 254 задачи, или 48,6%. Результаты совпали в 430 задачах: обе модели успешно справились с 214 задачами и обе провалили 216 задач. Фактическое различие проявилось лишь в 93 задачах, поэтому поведенческие различия важнее сырого разрыва в таблице рейтинга.
В примере с одной задачей, которую успешно решили обе модели, обе начали с открытия связанного файла на 15-м шаге, установили первопричину и провели всестороннюю проверку. Однако Opus использовал более целенаправленный поиск и начал выполнение после 13 шагов, завершив задачу за 53 шага с шестью переходами между исследованием, выполнением и проверкой. Gemini же шире исследовал крупный модуль, выполнил первую проверку, пригодную для выполнения, на 30-м шаге и не внёс первое изменение в производственный код до 88-го шага; затем ему потребовалось 192 шага и 34 перехода между этапами.
Обе модели прошли тесты и изменили те же файл и символы, что и эталонный патч. Однако Opus не затронул другие файлы, тогда как патч Gemini распространился ещё на четыре файла; процесс оценки описал его как широкий, с заметным повторением и некоторыми галлюцинациями. JetBrains подчёркивает, что этот пример носит иллюстративный характер и не является самостоятельным статистическим результатом.
Неудача — это не единичное состояние
Анализ 216 задач, на которых обе модели потерпели неудачу, показал, что более чем в 85% случаев, согласно оценке, первопричина была определена полностью или частично. В одном случае оба агента поняли, что превышение текстом ограничения на число символов вызвало ошибку, но предложили обрезать текст вместо того, чтобы разделить его на корректные части. В другом случае они исправили параметр загрузки в одном пути, но упустили ту же проблему в сопутствующем пути.
На практике эти случаи отличаются от ситуации, когда агент не может найти ответственный компонент. Причиной могут быть неполная реализация, изменение неправильного слоя, несоблюдение точного контракта задачи или остановка до проверки. Поэтому траектория выполнения может помочь определить, где требуется вмешательство: улучшить навигацию по репозиторию, скорректировать формулировку задачи, усилить завершение изменений или принудительно добавить финальный этап проверки.
Поведенческие профили вместо единого рейтинга
JetBrains пришла к выводу, что Claude Opus 4.7 чаще определял причину, лежащую в основе неоднозначных дефектов, и решил 53 задачи, с которыми не справился Gemini. Однако в 123 его запусках не было ни одной проверки, пригодной для выполнения, включая 68 задач, признанных решёнными. Компания считает, что такое поведение может оставлять необнаруженные риски, связанные с регрессиями или крайними случаями.
В свою очередь, Gemini 3.5 Flash чаще запускал проверку, пригодную для выполнения, и использовал её результат для улучшения решения, когда ожидаемое поведение было ясным, а ответственный компонент — относительно определённым. Однако у него наблюдались проблемы со схождением к решению и опорой на репозиторий: он повторял эквивалентные поисковые операции или команды, тратил много шагов на структуру сборки и чаще полагался на недокументированные интерфейсы, зависимости, пути или настройки тестирования. 195 его запусков, то есть 37,3%, были классифицированы как содержащие умеренные или сильные галлюцинации, по сравнению со 130 у Opus. Кроме того, 80 его запусков, или 15,3%, демонстрировали значительное или сильное повторение, против 6,5% у Opus.
Что это означает на практике?
В более широком сравнении, включавшем GPT-5.5, Claude Opus 4.7, Gemini 3.5 Flash и Qwen 3.6 27B FP8 на 522 общих задачах, GPT-5.5 показала самый высокий коэффициент решения — 51,5% — и была единственной моделью, запускавшей проверку, пригодную для выполнения, каждый раз. Opus лидировал по показателям качества патча, тогда как Qwen 3.6 27B FP8 решил 38,9% задач при стоимости выполнения, равной 3% стоимости GPT-5.5.
Эти цифры показывают, что выбор модели зависит от того, где сосредоточены затраты и риски. Модель, сильная в диагностике, может подойти для незнакомого репозитория или неоднозначного дефекта, тогда как модель, более дисциплинированная в проверке, окажется лучше, когда доступны тесты и обратная связь. Низкозатратная модель может стать практичным вариантом, если цена неудачной попытки ограниченна, даже при более низком коэффициенте решения. Однако это не означает, что модель демонстрирует одинаковое поведение в любой среде.
JetBrains предупреждает, что поведенческие профили нельзя напрямую распространять на сами модели, поскольку результаты зависели от конкретной архитектуры Junie. Кроме того, оценки, основанные на больших языковых моделях-судьях, не являются «эталонной истиной» и в значительной степени зависят от одного золотого патча, хотя корректные решения могут использовать другие файлы или архитектурные слои. Поэтому коэффициент решения остаётся необходимой основой, но его ценность возрастает, когда он сопровождается свидетельствами об эффективности, качестве изменений и рабочем процессе, а не сводится к единому общему рейтингу.