Стенд вместо чужих бенчмарков: как мы проверяем ИИ-агентов для бизнеса перед сдачей

Стенд вместо чужих бенчмарков: как мы проверяем ИИ-агентов для бизнеса перед сдачей

Стенд вместо чужих бенчмарков: как мы проверяем ИИ-агентов для бизнеса перед сдачей

На созвоне с заказчиком нас спросили простую вещь: «Как вы поймёте, что ваш новый агент лучше старого?» Мы честно замялись. Показали таблицу с публичного лидерборда, где одна модель обходит другую на пару процентов в какой-то задаче про математические задачи для школьников. Директор по цифровизации посмотрел на нас без выражения и сказал: «Ребята, у меня не школа. У меня входящие заявки от поставщиков». В тот же вечер мы начали собирать собственный стенд для проверки ИИ-агентов. С тех пор ни один релиз не уходит клиенту, пока не пройдёт эту проверку.

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

Почему публичные бенчмарки нас ничего не научили

Каждую неделю выходит новая модель. GPT, Claude, Gemini, Llama, Qwen, DeepSeek, Mistral, GigaChat Pro, YandexGPT, T-Lite, Cotype — список не заканчивается. Под каждый релиз идут графики: MMLU выше, HumanEval выше, ещё какой-то арк-челлендж выше. Красиво.

Проблема в том, что наш агент не отвечает на школьные задачи и не пишет функции с нуля в вакууме. Он получает письмо от поставщика, где в теме — номер договора с опечаткой, в теле — просьба «как обычно», а во вложении — счёт в формате, который сканер собрал криво. И его работа — не написать эссе, а понять, к какой поставке это относится, есть ли расхождения с приложением к договору, и надо ли поднимать тревогу.

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

Что мы кладём на стенд

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

Мы разбиваем сценарии на три группы.

Обычные будни. Заявки и письма, которые агент видит десятки раз в день. Здесь мы проверяем не столько «умеет ли», сколько «стабильно ли». Хорошая модель на этих сценариях не должна раз в десять раз давать другой ответ. Разброс — это как раз то, что бесит операторов и рушит доверие к системе.

Тонкие места. Ситуации, где агент раньше ошибался. Приказ, который отменяет предыдущий приказ. Счёт от поставщика, у которого сменились реквизиты. Клиент, который написал в чат из другого аккаунта. Каждая такая история после разбора превращается в отдельный кейс на стенде. Их немного, но именно они показывают, честно ли новая модель понимает задачу или просто хорошо звучит.

Ловушки. Промпт-инъекции, попытки увести агента с темы, письма с заведомо противоречивыми инструкциями во вложении. Тут мы смотрим не на «правильный ответ», а на то, что агент не сделал глупостей: не выдал внутренние данные, не полез выполнять команду из тела письма, не начал переписываться с ботом на той стороне.

Никаких школьных задач. Никаких абстрактных «оцените по шкале». Только те входы, которые агент будет разбирать в понедельник утром у настоящего клиента.

Как это устроено под капотом

Стенд у нас — обычное скучное инженерное хозяйство. PostgreSQL с pgvector, где лежат сценарии, их эталонные результаты и все прогоны. FastAPI, который умеет прогнать выбранный набор сценариев через выбранного агента с выбранной моделью. Небольшой Angular-интерфейс, чтобы менеджер проекта мог сам запустить сравнение и посмотреть, где расхождения.

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

Каждый прогон пишет структурированный лог: что пришло на вход, какие инструменты агент вызвал, что вернулось из них, какой был финальный ответ и сколько всё это стоило. Из этих логов мы потом строим три отчёта.

Проходит или нет. Совпал ли ответ с эталоном по ключевым полям (например, «правильно определил договор» и «правильно посчитал расхождение по сумме»). Здесь мы стараемся не оценивать текст целиком — это ловушка. Оцениваем то, что дальше пойдёт в систему.

Стабильность. Одинаково ли модель отвечает при десятке прогонов одного и того же сценария. Если разброс большой — модель эмоциональная, ей не место в продакшене на этой задаче.

Стоимость и скорость. Сколько токенов ушло, сколько шагов агент сделал, за сколько секунд ответил. Это не бенчмарк, это счёт, который мы потом покажем финдиректору заказчика.

История про «сильную» модель, которая провалилась

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

Международная на общих тестах была на голову выше. На нашем стенде она красиво отвечала на простые сценарии, но на «тонких местах» начала фантазировать: додумывала номера договоров, которых не было в контексте, и красиво объясняла, почему она так решила. Убедительно. Неправильно.

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

Без стенда мы бы, скорее всего, поставили ту, которая выглядит сильнее. Потому что так делают все.

Что видит заказчик

Раньше отчёт о создании ИИ-агента для заказчика выглядел как «мы всё сделали, работает». Теперь у клиента есть панель, где под каждый релиз агента и под каждую версию модели видно: какие сценарии проходят, где просело качество, сколько это стоит в пересчёте на месячную нагрузку.

Это оказалось важнее, чем мы думали. Разговор с заказчиком превратился из «поверьте нам» в «смотрите сами». Когда через квартал вышла новая версия российской модели, мы прогнали её через тот же стенд за полдня и показали, что на его сценариях она чуть лучше и заметно дешевле. Решение о переходе приняли за один созвон.

Что мы поняли, пока это собирали

Разработка ИИ-агентов без стенда — это ремонт машины на слух. Пока едет — вроде хорошо. Что-то стукнуло — начинаем гадать.

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

И ещё одно наблюдение. Когда у команды есть стенд, отношение к релизам моделей меняется. Перестаёшь бегать за каждым громким анонсом. Вышла новая модель — прогнал, посмотрел, принял решение. Скучно, спокойно, по делу. Ровно то, что нужно ИИ-агентам для бизнеса, если они уже стоят между вашими клиентами и вашими деньгами.

Вопрос, который мы теперь задаём сами себе перед каждым большим внедрением: если через полгода выйдет модель в два раза лучше, как мы это поймём? Если ответа нет — работать рано.

Похожие статьи

Обсудить проект← Все статьи