Оценка моделей на своих данных для задач продукта

Почему чужие бенчмарки не отражают ваш продукт

Публичный бенчмарк показывает, как модель решает чужую задачу в чистых условиях. Продукт так не работает. Пользователь пишет с ошибками, вставляет кусок переписки, просит ответить в одном абзаце и ждет не "умный" текст, а полезный результат в нужной форме.

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

Разница особенно заметна там, где запросы не похожи на учебные примеры. В поддержке клиент может прислать номер заказа, скриншот и злое сообщение в одном чате. В бенчмарке обычно есть короткий вопрос и один "правильный" ответ. Это уже другая работа.

Ошибки тоже стоят по-разному. Если чат-бот магазина ответил сухо, это неприятно, но терпимо. Если модель неверно пересказала пункт договора, условия кредита или медицинскую инструкцию, цена ошибки совсем другая. Поэтому смотреть только на средний балл нельзя. Задачи нужно делить по риску и проверять каждую группу отдельно.

Команды чаще всего недооценивают четыре вещи: язык запроса и смешение языков, тон ответа, допустимую длину и формат, без которого результат нельзя использовать дальше.

Даже если вы можете быстро переключать модели через один API, это само по себе не делает сравнение честным. Честным его делает только ваш набор задач и ваши правила оценки.

Поэтому оценка моделей на своих данных начинается не с таблицы лидеров, а с договоренности внутри команды. Что считать хорошим ответом? Что модель обязана сделать всегда, а что допустимо пропустить? Где нужен точный факт, а где хватит краткого и вежливого ответа?

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

Какие задачи брать из продукта

Придумывать задачи с нуля почти всегда плохая идея. Нужны реальные следы работы продукта: логи диалогов, тикеты поддержки, письма, заявки из форм, внутренние запросы сотрудников. Если модель потом будет отвечать клиентам банка, помогать оператору в телекоме или разбирать обращения в ритейле, проверять ее нужно на таких же случаях, а не на удобных демо-примерах.

Сначала соберите сырой массив за понятный период, например за последний месяц или квартал. Потом удалите персональные данные до разметки: имена, телефоны, адреса, номера договоров, ИИН и любые фрагменты, по которым можно узнать человека. Это нужно не только для безопасности. Когда разметчик видит лишние детали, он часто начинает оценивать "по истории клиента", а не по качеству ответа модели.

После этого разложите примеры по типу работы. Обычно хватает четырех групп:

• поиск факта в базе знаний или документе
• короткая суммаризация длинного текста
• классификация обращения или намерения
• генерация ответа, письма или внутренней заметки

Такой разбор быстро показывает перекосы. Во многих командах 70% выборки случайно состоит из простых FAQ просто потому, что их больше всего в логах. В итоге модель хорошо проходит легкие случаи, но сыпется там, где продукт теряет деньги или время сотрудников.

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

Сложные случаи лучше вынести в отдельный набор и не смешивать с общей массой. В нем могут быть противоречивые инструкции, неаккуратные формулировки, длинные цепочки сообщений, устаревшие шаблоны и ситуации, где даже человек отвечает не сразу. Такой набор удобен для стресс-теста перед запуском и для повторной проверки после смены модели.

Если вы сравниваете несколько моделей через один шлюз, набор задач должен быть одинаковым для всех. Иначе сравнение теряет смысл. Хорошая выборка похожа на реальную очередь работы: в ней есть рутина, пограничные случаи и несколько неприятных примеров, на которых сразу видно, можно ли пускать модель в продукт.

Как собрать датасет для проверки

Для оценки моделей на своих данных нужен набор запросов из реальной работы продукта. Берите не удобные демо-примеры, а то, с чем команда сталкивается каждый день: шумные формулировки, неполные данные, длинные переписки, жесткие требования к формату ответа.

Сначала выберите 5-10 сценариев, которые дают основную нагрузку. Обычно это запросы, где ошибка дорого обходится по времени, деньгам или риску для пользователя. Если продукт работает в банке, телекоме или госсекторе, не пропускайте случаи с маскированием PII, обязательной меткой AI-контента или строгой структурой ответа.

В сам набор стоит включить частые запросы, редкие случаи с заметной ценой ошибки, сообщения с опечатками и обрывками контекста, запросы на двух языках и длинные диалоги, где модель должна удерживать детали. Для каждого сценария соберите хотя бы 30 примеров. Если получится довести до 70-100, сравнение будет меньше зависеть от случайных удач модели.

Источник не так важен, как честность выборки. Подойдут реальные обращения, логи, письма, чаты или формы, если команда очистила данные по внутренним правилам.

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

Отдельно проверьте дубли. Если в датасете десять почти одинаковых вопросов вроде "Где мой заказ?", модель может выглядеть лучше, чем есть на самом деле. Оставляйте смысловые повторы только там, где меняется контекст, ограничение или ожидаемое действие.

Как зафиксировать версию

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

Как подготовить эталоны и правила ответа

Слабый эталон портит даже аккуратную оценку. Если интерфейс ждет короткий ответ в две строки, не пишите эталон как длинное идеальное эссе. Если ваш API принимает JSON с полями answer, risk_label и next_step, эталон должен повторять ту же форму. Иначе вы начнете мерить не качество ответа, а сходство с чужим шаблоном.

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

Хорошее правило звучит просто и проверяемо. Обычно достаточно зафиксировать:

• обязательные поля и их порядок, если это важно для клиента
• факты, которые нельзя придумывать или менять
• допустимую длину ответа
• случаи, когда модель должна задать уточняющий вопрос
• случаи, когда модель должна отказаться от ответа

Спорные задачи лучше не сводить к одному "идеальному" эталону. Полезнее описать границы приемлемого ответа и явные признаки провала. Тогда проверяющие оценивают задачу продукта, а не стиль конкретного автора.

Какие критерии считать

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

Если ответ можно проверить однозначно, считайте точность. Это подходит для извлечения полей, классификации заявок, выбора статуса заказа, поиска правильного тарифа по правилам. В таких задачах работают простые метрики: доля верных ответов, доля верно заполненных полей, доля ответов без пропусков.

С открытыми ответами одна цифра почти всегда врет. Для них лучше ввести короткую шкалу и оценивать ответ по нескольким осям:

• полнота
• фактическая точность
• формат, включая тон и длину
• безопасность
• полезность

Такую проверку удобно делать на шкале 0-1 или 0-2. Чем проще рубрика, тем меньше споров. Если проверяющие часто расходятся в оценке, усложнять таблицу не нужно. Лучше переписать правило.

Отдельно считайте цену, задержку и длину ответа. Это не второстепенные числа. Две модели могут дать почти одинаковое качество, но одна отвечает за 2 секунды и тратит вдвое меньше токенов. Для продакшена это часто важнее разницы в пару баллов.

Опасные ошибки стоит выносить в отдельную метрику. Средний балл может выглядеть нормально даже тогда, когда модель в 3% случаев придумывает условия возврата, путает медицинские ограничения или отправляет клиента не туда. Долю критических промахов лучше смотреть первой.

Полезно различать и типы ошибок. Один промах раздражает пользователя, другой создает риск для бизнеса. Длинный ответ в поддержке неприятен. Неверный ответ про лимит перевода уже опасен.

Сравнивайте модели по каждому сценарию, а не сводите все к одной цифре. Сделайте отдельные строки для возврата товара, смены тарифа, проверки статуса, жалобы и эскалации к оператору. Тогда видно, где модель сильна, а где ее нельзя выпускать.

Если вы прогоняете тесты через единый шлюз, удобно собирать рядом и качество, и операционные метрики: цену по провайдеру, задержку, длину ответа, долю ошибок по сценарию. Но даже без такой системы правило простое: смотреть на модель глазами продукта, а не глазами чужого бенчмарка.

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

Хороший пример для проверки - поддержка интернет-магазина. Там много повторяющихся обращений, и ошибка быстро становится заметной. Если модель путает сроки возврата или обещает то, чего нет в правилах, это сразу бьет по деньгам и доверию.

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

Для первого прогона обычно хватает 30-50 примеров. В набор стоит включить вопросы о возврате товара после получения, сообщения о задержке доставки, просьбы проверить статус заказа, спорные случаи с попыткой обойти правило, короткие и длинные обращения с ошибками и разговорным стилем.

К каждому примеру добавьте внутреннее правило компании, на которое должен опираться ответ. Например: возврат возможен в течение 14 дней, если товар не использовали; по предзаказу сроки могут меняться; по статусу заказа нельзя обещать доставку сегодня, если в системе нет такого статуса. Тогда вы проверяете не гладкость текста, а попадание в реальную политику.

Один и тот же запрос можно дать нескольким моделям: "Я жду заказ уже 9 дней, мне никто не отвечает, хочу возврат и компенсацию". Хороший ответ короткий, спокойный и точный. Он ссылается на правило возврата, не придумывает компенсацию и не обещает срок, которого нет в системе. Плохой ответ звучит уверенно, но добавляет вымышленные исключения вроде "обычно мы возвращаем деньги за 3 дня", если такого правила нет.

Что считать хорошим ответом

Смотрите на четыре вещи: верную ссылку на правило компании, отсутствие выдуманных сроков и исключений, спокойный тон без канцелярита и формат в 2-4 коротких предложениях вместо длинного письма. На практике часто выигрывает не самая сильная модель в общем рейтинге, а та, что реже фантазирует на конфликтных обращениях. Для поддержки это важнее особенно красивого стиля.

Где команды чаще ошибаются

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

Для команд из Казахстана и Центральной Азии есть еще одна частая проблема: смешение языков без разметки. В одном потоке легко встретить русский, казахский и английский, а иногда и сообщение, где все три языка есть сразу. Если такие примеры лежат в одной куче без меток, выводы получаются кривыми. Вы не поймете, модель слабо отвечает в целом или ломается только на казахских запросах, код-свитчинге и коротких англоязычных вставках.

Еще один промах связан с метриками. Команда смотрит на средний балл и радуется разнице в пару десятых. Но среднее часто прячет дорогие сбои. Если модель в 95 случаях из 100 отвечает нормально, а в оставшихся 5 путает сумму, статус заявки или правило эскалации, для бизнеса это уже серьезная проблема. Такие ошибки нужно искать отдельно: по срезам, по типам задач и по самым рискованным сценариям.

Сравнение ломается и тогда, когда команда меняет промпт по ходу теста. На старте одна инструкция, через день ее переписали, потом добавили пару примеров, потом попросили отвечать короче. После этого уже нельзя честно сказать, какая модель лучше. Вы сравниваете сразу несколько переменных. Сначала заморозьте промпт, формат ответа, температуру и правила постобработки. Только потом гоняйте набор.

Часто эталон тоже уводит тест в сторону. Эксперт пишет "идеальный" ответ под свой вкус: длиннее, строже, литературнее. Но продукту обычно нужен не красивый текст, а правильное действие. Если оператору нужен короткий ответ с точным решением, не стоит штрафовать модель за то, что она не пишет абзац объяснений.

Хороший тест выглядит чуть скучнее, чем хочется. В нем есть грязные примеры, языковые метки, замороженные условия запуска и отдельный просмотр тяжелых провалов. Зато потом результаты меньше удивляют после релиза.

Быстрая проверка перед сравнением

Сравнение моделей ломается уже на старте, если набор тестов собран наспех. Возьмите реальные сценарии из продукта и сразу пометьте долю каждого. Если у вас 50% запросов - это короткие вопросы в поддержку, 30% - поиск по базе знаний, а 20% - сложные обращения с несколькими условиями, тестовый набор должен повторять эту картину.

Дальше проверьте, что для каждого примера у вас есть понятная граница между хорошим и плохим ответом. Не всегда нужен идеальный эталон в одно предложение. Часто хватает короткого правила: ответил по сути, не придумал факты, сохранил нужный тон, честно попросил уточнение, если данных не хватает. Рядом полезно записать и явный провал: ушел в общие слова, пропустил ограничение, дал опасный совет.

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

Для быстрой сверки хватает одной таблицы. В ней обычно есть сценарий и его доля в продукте, сам пример и краткое правило оценки, один и тот же промпт и формат ввода для всех моделей, цена запуска, средняя задержка, итоговая оценка и короткий комментарий ревьюера.

Одинаковый промпт обязателен. Если одна модель получает другой системный текст, другой формат полей или больше контекста, вы сравниваете не модели, а настройку теста. Когда команда использует один OpenAI-совместимый шлюз, удержать одинаковый запрос проще: меняется только модель. Для таких задач AI Router выглядит практичным вариантом для команд в Казахстане: можно переключать провайдеров через единый эндпоинт и не менять SDK, код и промпты.

Собирайте цену, задержку и качество в одной таблице с первого дня. Иначе качество живет в одном файле, цена в другом, и спор тянется бесконечно. Даже 30-50 примеров уже показывают, какая модель держит основную нагрузку, какая лучше проходит редкие случаи и где экономия на токенах съедается задержкой.

Что делать после первых тестов

После первого прогона не держите в списке все модели. Если модель регулярно путает факты, ломает формат ответа или уходит в лишние рассуждения, уберите ее сразу. Обычно после такого отсева остаются 2-4 финалиста, и их уже имеет смысл проверять вручную.

Ручная проверка почти всегда меняет картину. В таблице две модели могут выглядеть одинаково, но в живых примерах разница быстро видна: одна срывается на длинных диалогах, другая держит стиль ответа, но иногда выдумывает детали. Для продукта такие сбои важнее красивого среднего балла.

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

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

Если вы сравниваете много провайдеров, лишняя ручная работа быстро съедает время команды. В таком случае удобно гонять одинаковые запросы через один OpenAI-совместимый эндпоинт. Для команд, которым важны хранение данных внутри Казахстана, аудит-логи, маскирование PII и единый контур доступа к разным моделям, airouter.kz может упростить именно процесс оценки, а не только сам запуск в продакшен.

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