Кратко
Все мы уже слышали это: ваша ИИ-система — будь то агент, обвязка или слой маршрутизации — ровно настолько хороша, насколько хороша оценка, лежащая в ее основе.
Мы также слышали: публичные бенчмарки плохо отражают реальный трафик разработчиков. С точки зрения того, что они запрашивают, как они это формулируют, сложности задач и того, как развиваются сессии.
Мы воочию увидели это расхождение, когда проанализировали внутренний трафик наших разработчиков. Результаты бросили вызов нашим предположениям о задачах агентного программирования, и мы использовали эти уроки для создания надежного бенчмарка, который сохраняет качество при решении реальных задач программирования в нашем интеллектуальном шлюзе. В этой статье рассказывается о проделанном пути.
Реальное распределение работы разработчиков
К счастью, чтобы понять разрыв между публичными бенчмарками и реальным использованием, у нас есть преимущество в виде живых данных от нашей внутренней команды разработчиков. Чтобы разобраться в этом трафике, мы разработали внутренний классификатор задач программирования и пропустили через него семинедельный трафик реальных разработчиков.
То, что мы увидели при анализе полученного распределения задач, полностью опровергло нашу интуицию относительно привычек агентного программирования:
РИСУНОК 1. Категории верхнего уровня были получены из данных, а подкатегории — внутри каждой категории. Всего 15 категорий, 84 подкатегории и 4211 обращений.
Если посмотреть на задачи, измеряемые стандартным бенчмарком, таким как SWE-bench, может показаться, что разработчики используют агентов в основном для чистой генерации кода и исправления багов с чистого листа. Но наш классификатор выявил совершенно иную реальность.
Уроки семинедельного трафика реальных разработчиков
Разработчики используют агентов как партнеров по размышлениям, а не просто как генераторы кода. В нашем трафике лишь около 11% обращений реальных разработчиков связаны с просьбой написать код. В подавляющем большинстве случаев разработчики задают уточняющие вопросы, вставляют контекст, проводят анализ или запрашивают код-ревью. Самое распространенное сообщение, которое мы видим, — это уточняющий вопрос.
Интерактивные рабочие процессы против одноразовых задач. Данные показывают, что взаимодействие разработчика и агента носит крайне диалоговый характер. Разработчики не просто сбрасывают в чат проблему с GitHub на 1000 слов и уходят. Они пишут короткие сообщения по 80 символов прямо в ходе сессии. Они занимаются пошаговой отладкой, вставляют логи консоли и итеративно дорабатывают вывод агента.
Где расходятся трафик реальных разработчиков и публичные бенчмарки
Тип задачи
Мы прогнали несколько публичных бенчмарков (включая SWE-bench, HumanEval и Spider) через тот же классификатор, чтобы сопоставить их. Несоответствие с нашими внутренними данными оказалось разительным. Почти все эти публичные бенчмарки сосредоточены на написании кода с нуля или исправлении бага для прохождения тестов.
РИСУНОК 2. Те же категории применимы к реальному использованию и к 23 бенчмаркам. Цифра в ячейке отражает % сообщений набора данных. Подтверждения, перенаправления, команды git и вставленный контекст составляют около 40% обращений реальных пользователей, но при этом отсутствуют ни в одном бенчмарке кодинга.Несмотря на то, что подтверждения, перенаправления, команды git и вставленный контекст составляют около 40% обращений реальных разработчиков, эти интерактивные свойства и поведение обмена контекстом почти не встречаются в публичных бенчмарках кодинга.
Сложность задач
Помимо отсутствия реальных типов задач программирования, публичные бенчмарки также не могут точно отразить сложность задач. Стандартные наборы для оценки часто проверяют глубокие архитектурные знания внутренних компонентов кодовой базы. Но в реальном мире? Разработчик с гораздо большей вероятностью задаст быстрый и практичный вопрос вроде: «Почему я не вижу свои изменения в git status?».
Поскольку бенчмарки чрезмерно концентрируются на этих высокосложных многофайловых архитектурных проблемах, они создают искаженное представление о том, что модели действительно должны делать и что они могут. Это может искусственно выставить меньшие или более дешевые модели неспособными справляться с повседневным трафиком. Вы можете увидеть это в приведенном ниже сравнении среднего количества обращений в задачах из реальных сессий разработчиков и передовой модели, протестированной на нашем бенчмарке:
РИСУНОК 3. Среднее количество обращений по категориям задач в сравнении между реальными сессиями разработчиков и данными, полученными при запуске Claude Opus 5.5 на нашем бенчмарке.
Контекст задачи
Мы обнаружили еще одно серьезное различие между трафиком реального мира и публичных бенчмарков: контекст. Типичная задача бенчмарка представлена в виде хорошо написанного тикета GitHub на 1000 символов для чистой ревизии кода.
Но сообщения реальных разработчиков полны хаоса. Имея в среднем около 80 символов, они поступают прямо посреди активной сессии, накладываясь на обширную историю разговора, вывод инструментов и полузавершенные изменения в файлах. Более 60% наших внутренних сессий содержат более одной отдельной задачи. Если вы оцениваете агента исключительно по тому, как он справляется с одним четко очерченным промптом с чистого старта, вы игнорируете реальность переключения контекста в середине сессии.
Создание бенчмарка реального мира
Определение цели
Доказать расхождение между публичными бенчмарками и трафиком реальных разработчиков было самой легкой частью. Теперь нам нужно было создать новый бенчмарк, который устранил бы этот разрыв.
Идеальная оценка просто использовала бы реальные рабочие процессы наших собственных разработчиков. Но создание естественного распределения задач порождает немедленную борьбу между тремя конкурирующими свойствами: извлечение из реальной работы, богатство контекста и способность к автоматической оценке.
Сессии реальных разработчиков отвечают первым двум критериям, но их практически невозможно оценить автоматически. Не существует заранее написанного набора тестов или критериев для разработчика, который спрашивает: «Почему у меня обрывается соединение с базой данных на строке 42?». Намерение целиком находится в голове разработчика, из-за чего трудно измерить, преуспел ли агент, без проверки человеком. С другой стороны, публичные бенчмарки отлично запускаются и легко оцениваются автоматически, но, как мы видели ранее, они оторваны от контекста реального мира.
Наша цель состояла в том, чтобы преодолеть этот компромисс: объединить автоматическую оцениваемость задач публичных бенчмарков с хаотичной реальностью реального трафика. Мы создали новый бенчмарк, руководствуясь четырьмя принципами:
1. Позволить реальному трафику задавать квоты. Вместо случайной выборки публичных задач мы использовали идеи нашего внутреннего классификатора для установки квот. Если 40% нашего реального трафика состояло из уточняющих вопросов и анализа кодовой базы, то 40% нашего бенчмарка должны были тестировать именно это.
2. Смешать публичные задачи с внутренним кодом. Публичные задачи не могут охватить ваши внутренние библиотеки, пользовательские среды или корпоративные соглашения. Чтобы сделать бенчмарк реалистичным, мы отобрали из наших собственных внутренних репозиториев задачи, которые уже были решены и объединены (смерджены). Мы убедились, что эти внутренние задачи могут оцениваться нашими собственными наборами тестов, а затем добавили их в пул наряду с публичными задачами. Этот процесс выглядит примерно так:
РИСУНОК 4. Извлечение данных из GitHub и публичных бенчмарков для создания комплексного бенчмарка, охватывающего ожидаемые привычки программирования в реальном мире.
Синтез на основе трасс включает в себя анализ логов взаимодействия с реальными пользователями и записей сессий для воссоздания реалистичных задач разработчиков и многошаговых сценариев.
3. Пишите как разработчик. Отчет об ошибке на 1000 слов с идеальным форматированием не проверяет способность агента понимать короткие, 80-символьные, часто неоднозначные сообщения, которые на самом деле пишут наши разработчики. Мы изменили оболочку, но оставили базовую кодовую среду и автоматические тесты абсолютно идентичными.
4. Начинайте с середины. Наконец, поскольку разработчики редко просят написать код с нуля, оценка в конечном итоге должна учитывать историю. Мы создали внутреннюю инфраструктуру повтора, которая позволяет нам восстановить реальную сессию разработчика на любом этапе ее прохождения, со всем накопленным контекстом и измененными файлами. Симулируя следующий шаг разработчика из середины запутанной сессии, мы получаем наиболее точное представление о том, как агент действительно поведёт себя в реальных условиях.
Тщательно отбирая задачи, соответствующие нашему реальному набору категорий, переписывая промпты так, чтобы они звучали как слова живых разработчиков, и интегрируя собственную кодовую базу, мы создали бенчмарк из 613 задач, отражающий реальность.
Затем мы подвергли наш бенчмарк суровому испытанию: измерению качества трафика, проходящего через наш интеллектуальный Gateway.
Выдерживает ли он проверку? Стресс-тестирование нашего бенчмарка для реального программирования
Чтобы проверить, насколько хорошо наш бенчмарк отражает естественное распределение реальных задач по программированию по сравнению с публичными бенчмарками, мы хотели посмотреть, как популярная передовая модель ведет себя на реальных пользовательских сессиях по сравнению с каждым из этих двух бенчмарков. Для этого теста мы обратились к маршрутизатору на базе передовой модели в нашем интеллектуальном Gateway, который располагается между нашими разработчиками и базовыми моделями и был обучен для работы с трафиком агентского кодинга. Каждый раз, когда разработчик отправляет сообщение, маршрутизатор Gateway оценивает сложность задачи, чтобы за доли секунды принять решение: требует ли этот запрос нашей самой дорогой, высокопроизводительной премиальной модели, или с ним отлично справится более дешевая и быстрая модель?
Этот маршрутизатор можно настроить на перенаправление ожидаемого процента трафика на премиальную модель, что позволяет нам находить баланс между стоимостью и качеством. Мы рассудили, что пойдем по верному пути и создали действительно репрезентативный бенчмарк, если характер распределения запросов через Gateway будет одинаковым как для реальных пользовательских сессий, так и для нашего бенчмарка.
Мы измеряем этот характер с помощью порога премиальной маршрутизации: процента задач, которые Gateway отправляет на премиальную модель. Мы установили целевой показатель на уровне 25% и сравнили корреляцию процента маршрутизации для живого трафика разработчиков и различных бенчмарков:
Тест № 1: Сравнение живого трафика нашего Gateway с публичным бенчмарком (зеленая линия). Развернутый на реальном входящем трафике, Gateway неверно оценил его и в итоге направил почти 50% запросов на премиальную модель, превысив целевой бюджет на 23 пункта.
Тест № 2: Сравнение живого трафика нашего Gateway с нашим бенчмарком. Продемонстрировав поразительную корреляцию с нашими данными по естественному кодингу, Gateway отклонился от целевого бюджета всего на 0,5 пункта. Это доказывает, что мы не только совпали с распределением задач в наших реальных пользовательских сессиях, но и что Gateway также успешно направлял сложные задачи на премиальную модель с той же частотой в обоих случаях.
РИСУНОК 5. Порог маршрутизатора Gateway был настроен на его собственных данных для отправки целевой доли задач на премиальную модель (ось X), а затем без изменений применен к 1905 реальным сообщениям разработчиков из нашего Gateway (ось Y).
Поскольку работа маршрутизатора наконец оценивалась на распределении, соответствующем реальным привычкам написания кода, это не просто сэкономило деньги; это доказало его способность правильно определять, когда стоит положиться на более дешевую модель для решения простого вопроса по git, а когда привлечь тяжелую артиллерию для сложного запроса на добавление функционала.
Что это значит для вашей команды
В конечном счете, создаете ли вы маршрутизатор, настраиваете промпт или выбираете модель для своей организации, ваши результаты будут ровно настолько точными, насколько точна ваша оценка. Если вы хотите узнать, как агент по кодингу покажет себя в полевых условиях, именно там его и нужно оценивать.
Вот основные выводы для любой команды, оценивающей агентов по кодингу:
- Измеряйте свой трафик перед тем, как выбрать бенчмарк. Если 90% запросов вашей команды — это вопросы по кодовой базе и разбор багов, тестирование агентов на бенчмарке, состоящем исключительно из задач по генерации кода, заведет вас в тупик.
- Соответствуйте по набору задач, сложности и языку. Простого переписывания промптов или изменения весов задач недостаточно для переноса результатов в реальную жизнь. Их необходимо комбинировать и, в идеале, дополнять задачами, извлеченными из ваших собственных закрытых кодовых баз.
- Оценивайте сессии целиком, а не отдельные задачи. Поскольку разработчики работают в диалоговом режиме, переключение моделей внутри сессии стоит реальных денег и токенов контекста. Только оценка на уровне сессии позволяет увидеть эту истинную стоимость.
- Тестируйте решения, а не просто баллы. Оценка в бенчмарке не имеет значения в вакууме. Оценка заслуживает доверия только тогда, когда выбранная модель, политика маршрутизации или установленный для нее бюджетный порог действительно подтверждают свою эффективность на реальном живом трафике.
