Система бенчмаркинга GLM-5.2 должна отвечать на практический вопрос: способен ли кандидат выполнить определённый вид работы при приемлемых эксплуатационных затратах? Публичный балл может сузить круг кандидатов. Однако он не скажет, как модель работает с вашим репозиторием, схемой инструментов, правилами утверждения, политикой повторных попыток или резервным маршрутом. Начните с работы, которая должна по-прежнему успешно выполняться после пилотного проекта.
В этой статье не утверждается, что какая-либо модель доступна, недорога, быстра или надёжна. Проверяйте эти детали в соответствующем официальном источнике в день запуска. Если вы планируете тестировать через OdiRouter, начните с актуального OdiRouter product page, ознакомьтесь с pricing и используйте getting-started documentation для получения информации по настройке.
Начните с решения
Запишите, какое решение должен принять бенчмарк. Он может определять, следует ли поручить задачу программирования одному кандидату, когда запрос нужно перевести на резервный вариант или всё ещё требуется проверка человеком. Без такого решения команды обычно получают таблицу оценок, которая не помогает выбрать вариант реализации.
Определите тип работы до выбора задач. Для сопровождения кода нужны иные доказательства, чем для процесса поддержки или задачи структурированного извлечения данных. Опишите приемлемый результат, входные данные, которые система может использовать, инструменты, которые она может вызывать, максимальное время ответа и момент, когда работу принимает человек.
Все кандидаты должны работать по одинаковым правилам. Зафиксируйте промпт, файлы задач, системные инструкции, определения инструментов, порядок контекста, лимит повторных попыток, тайм-аут и критерии оценки для проверяющих. Если одному кандидату нужен специальный адаптер или иной контракт инструмента, зафиксируйте эту интеграционную работу. Не скрывайте это в итоговой оценке.
Составьте пакет документов на основе реальной работы.
Выбирайте задачи, которые по своему усмотрению соответствуют той работе, которую вы планируете выполнять. Включите типовые случаи, сложные случаи и случаи с высокой вероятностью сбоя. Пакет не обязательно должен быть огромным. Он должен оставаться достаточно стабильным, чтобы последующий запуск можно было сопоставить с предыдущим.
Для написания кода используйте небольшие изменения с тестами, задачу, которая затрагивает несколько файлов, и запрос с явным правилом репозитория. Для использования инструмента необходимо указать допустимый вызов, неоднозначный запрос, который должен инициировать уточнение, и результат, который заставляет модель пересмотреть свой план. Для задач поиска или работы с длинным контекстом поместите обязательное ограничение в начале материала, добавьте позже правдоподобные отвлекающие элементы и проверьте, соблюдает ли итоговый вывод правило.
Ведите запись по каждой задаче:
Поле | Что записывать |
|---|---|
Идентификатор задачи | Постоянное название задачи и ее редакция |
Входные данные | Промпт, фикстуры, порядок контекста и доступные инструменты |
Критерий успеха | Результат теста, рубрика для проверки или проверка структурированного вывода |
Эксплуатационные ограничения | Тайм-аут, лимит повторных попыток и требование одобрения |
Результат | Принят, исправлен, повторён, направлен на резервный вариант или эскалирован |
Ответ не считается успешным лишь потому, что он звучит правдоподобно. Для изменения кода решение принимают тесты и правила ревью. Для вызова инструмента проверяйте имя инструмента, аргументы и результат действия. Для структурированного вывода проверяйте схему и значения, используемые последующей системой.
Измеряйте, что происходит после первого ответа
Первый ответ — это не вся стоимость. Отслеживайте путь к принятому результату: долю завершений, принятие с первой попытки, задержку, повторные попытки, время на исправление человеком, долю использования резервного варианта и общую стоимость принятой работы. Используйте одинаковые единицы измерения для каждого кандидата.
Разделяйте неудавшийся запрос и исправленный запрос. Почти правильный ответ может быть полезен, но время на исправление всё равно влияет на выбор. Фиксируйте, кто выполнил исправление, что было изменено и дошёл бы тот же сбой до клиента или автоматизированной системы.
Датируйте каждую проверку затрат. Не переносите цену токена в постоянно используемую запись бенчмарка. Цены, категории тарификации и правила учёта кэша могут меняться. Когда оценка выполняется через OdiRouter, используйте текущий pricing page, чтобы проверить тестируемую конфигурацию, и сохраните эту проверку вместе с записью.
Тестируйте инструменты, контекст и восстановление
Работа агента — это не только текстовый тест. Используйте инструменты, которые будут доступны в рабочем процессе в продакшене. Пробуйте некорректный ввод, отсутствующее поле, отклонённое действие и результат работы инструмента, который противоречит более раннему плану модели. Полезным результатом является то, запрашивает ли кандидат разъяснения, исправляет ли курс или повторяет неправильный поступок.
Длинный контекст требует отдельного теста. Указанное контекстное окно не доказывает, что важное правило сохраняется в течение длительного времени. Проверьте размеры контекста, которые имеют значение для вашей рабочей нагрузки. Прорабатывайте требования, не сбиваясь с графика, и проверяйте как конечный результат, так и работу инструмента.
Резервный вариант следует разработать до того, как ошибка достигнет производственной среды. Определите, какие сигналы переключают маршрут: недопустимый структурированный вывод, небезопасные аргументы инструмента, тайм-аут, повторные попытки, не пройденная проверка верификации или граница политики. Выполняйте эти сценарии в составе пакета. Команда должна знать, как маршрут даёт сбой, прежде чем об этом придётся узнать пользователям.
Сформулируйте правила маршрутизации, которые можно будет применять позднее
Завершайте запуск правилами, которые другой инженер сможет применить без опоры на воспоминания о совещании. Не объявляйте универсального победителя. Укажите, какая нагрузка поступает в каждую линию, какие доказательства ей нужны, когда она переходит на резервный вариант и кто отвечает за журнал оценки.
Например, правило может гласить, что кандидат обрабатывает определённый пакет задач по сопровождению кода только после прохождения тестов на фикстурах и при соблюдении согласованного лимита повторных попыток. Другое правило может требовать проверки аргументов до принятия запроса, интенсивно использующего инструменты. Это операционные правила, а не маркетинговые выводы.
Храните вместе редакцию промпта, фикстуры, идентификаторы модели и провайдера, конфигурацию, дату, справочные сведения о ценах, разрешённые необработанные результаты, заметки рецензента и правило маршрутизации. Повторно запускайте пакет, когда один из этих входных параметров меняется настолько, что это может изменить решение.
Проверьте OdiRouter перед пилотным запуском
Методика бенчмаркинга должна оставаться отделённой от маркетинговых материалов провайдера. Когда вы будете готовы к пилотному запуску OdiRouter, проверьте актуальные product entry point, сопоставьте предполагаемую конфигурацию с текущими pricing и следуйте OdiRouter documentation. Это даёт команде датированную запись о том, что именно она тестировала, и при этом сохраняет изменяемые сведения о продукте вне методики бенчмаркинга.