Наборы для оценки ИИ, которые остаются полезными после запуска

Почему эвалы устаревают после запуска

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

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

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

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

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

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

Относитесь к эвалам как к текущим проверкам качества продукта, а не к задаче на запуск. Когда команды регулярно обновляют тесты реальными провалами и текущим поведением, набор остаётся честным.

Что должно стать триггером для обновления

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

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

Язык меняется быстрее, чем думают многие команды. Пользователи сокращают запросы, смешивают сленг с официальными словами, отправляют однострочные сообщения с телефона или пропускают контекст, считая, что ассистент уже всё знает. Поддерживающий бот может нормально обрабатывать «Я хочу отменить подписку», но провалиться на «stop billing me rn» или «charged again why». Эти примеры должны быть в пакете, потому что они отражают то, как люди реально печатают.

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

Лучший источник материалов обычно лежит в системах, которые команда и так проверяет:

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

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

Сортируйте новые провалы, прежде чем писать тесты

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

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

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

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

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

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

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

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

Как поэтапно обновлять пакет эвалов

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

Не сливайте в него всё подряд. Шумный пакет становится медленным, трудночитаемым и легко игнорируемым.

1. Соберите недавние промахи из реальных применений. Посмотрите тикеты поддержки, плохие ответы, помеченные ревьюерами, сломанные автоматизации и логи промптов, которые вызвали путаницу. Если десять пользователей столкнулись с одной и той же ошибкой, сначала рассматривайте это как одну проблему.
2. Очистите кучу перед написанием тестов. Уберите точные дубликаты и объедините случаи, которые отличаются только незначительными словами. Если три промпта все просят возврат разными словами, оставьте пока один базовый случай.
3. Напишите один ожидаемый результат на случай. Делайте его понятным и конкретным. Хорошо: «Ассистент просит номер заказа и не обещает возврат.» Плохо: «Ассистент даёт полезный ответ.»
4. Добавьте несколько естественных вариаций. Измените формулировку, тон, орфографию и уровень детализации. Реальные пользователи не все печатают чисто. Один случай может выглядеть как «Мне вернуть деньги», а другой — «charged twice, fix this please.»
5. Прогоните пакет и уберите слабые случаи. Оставляйте тесты, которые ловят реальную ошибку, проверяют новое правило или выявляют изменение поведения. Удаляйте случаи, которые всегда проходят и ничего не учат.

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

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

Используйте тесты, которые звучат как настоящие люди

Команды часто пишут аккуратные вежливые промпты для первого набора эвалов. Реальные пользователи делают наоборот. Они пропускают контекст, ошибаются в написании имён, просят два дела сразу и меняют мнение в середине сообщения.

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

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

Реалистичный случай может выглядеть так:

• "cant log in after changing email, did my plan reset too?"
• "need invoice for march... maybe april too, same card failed btw"
• "can your app export to csv or only api? i dont code"
• "we added 3 users and now permissions look wrong"

Ни одна из этих строк не красива. В этом смысл.

Неопрятная формулировка помогает ловить ошибки, которые скрывают полированные промпты. Добавляйте опечатки, расплывчатые слова, отсутствующие даты, смешанные намерения и полуформулировки. Если ваш продукт получает трафик от людей, для которых русский не родной, включите и такие стили. Люди редко пишут так, как команда продукта.

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

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

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

Простой пример для ассистента поддержки

Розничный магазин добавляет самовывоз в тот же месяц, когда его AI‑ассистент поддержки уже в продакшне. Чекаут меняется, правила меняются, и вопросы клиентов меняются тоже. Ассистент по‑прежнему опирается на старые ответы про доставку.

Это создаёт распространённый провал. Люди спрашивают про самовывоз, а бот слышит слова о сроках и отвечает про доставку. Клиенты хотят узнать, когда они могут забрать заказ, а ассистент отвечает про сроки доставки.

Формулировки различаются, потому что реальные люди редко повторяют вопрос слово в слово. Один пишет: «Can I grab this today?», другой: «If I order before lunch, when can I pick it up?», третий: «Do you do curbside this afternoon?», а четвёртый смешивает самовывоз и доставку в одном сообщении.

Пара хороших тестовых промптов:

• "Can I pick this up after work today?"
• "What is the pickup window if I order before noon?"
• "Is same-day pickup faster than shipping?"
• "Why does checkout show pickup but chat keeps talking about delivery?"

Ассистент может ответить "Standard shipping takes 3 to 5 business days" или "Express delivery arrives tomorrow." Эти ответы на поверхности выглядят нормально, но они не отвечают на вопрос.

Хорошая команда не считает такие чаты единичными ошибками. Они сохраняют провалившиеся разговоры, убирают приватные данные и превращают их в свежие тестовые случаи. Они также сохраняют ту речь, которую использовали люди, включая короткие формулировки вроде "pick up today", "curbside" и "ready this afternoon."

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

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

Ошибки, которые тратят время впустую

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

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

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

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

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

И не позволяйте одному человеку навсегда обновлять пакет в одиночку. Соло‑правки тянутся к личным вкусам. Быстрая проверка со стороны поддержки, продукта или другого инженера ловит слабые случаи, дубликаты и скрытые предположения.

Самые медленные команды обычно делают ту же ошибку дважды. Они добавляют тесты, не удаляя старые, и пишут ожидаемые ответы, вызывающие споры вместо чёткого да/нет. Тогда каждый релиз превращается в митинг про крайние случаи, которые никто уже не видит.

Добавляйте тесты для недавних провалов, новых политик и повторяющихся паттернов пользователей. Пропускайте остальное. Это держит обслуживание LLM‑эвалов лёгким для частого запуска и строгим настолько, чтобы ловить реальные регрессии.

Быстрая проверка перед каждым релизом

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

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

Используйте эту короткую проверку:

• Добавьте 3–5 случаев из недавних промахов. Выбирайте реальные промпты, которые сломались в продакшне, а не отшлифованные версии, переписанные позже.
• Просмотрите изменения правил за последний месяц. Если команда поменяла политику возврата, логику одобрений, тональность или лимиты безопасности, ожидаемые ответы тоже должны измениться.
• Прочитайте промпты и ответы вслух. Если в продукте теперь говорят «workspace» вместо «project», или пользователи просят «credit» вместо «refund», обновите формулировку, чтобы тесты звучали актуально.
• Проверьте, может ли новый коллега быстро оценить каждый случай. Ожидаемый результат должен быть коротким и конкретным, чтобы новичок мог за несколько секунд понять, пройдено ли тестом.
• Удалите устаревшие и дублирующие случаи. Если два теста ловят одну и ту же проблему, оставьте более понятный. Если кейс покрывает удалённую функциональность, уберите его.

Это работает, потому что держит пакет привязанным к тому продукту, который у вас есть сегодня. Язык быстро меняется. Ассистент поддержки, который месяц назад успешно обрабатывал «cancel my plan», теперь может чаще получать запросы «pause billing» или «switch me to annual». Если ваши тесты не отражают это, показатели могут казаться стабильными, пока пользовательский опыт ухудшается.

Ясность важна не меньше покрытия. Когда ожидаемые результаты похожи на мини‑эссе, люди ставят оценки по‑разному и тратят время на споры. Короткая заметка вроде «должен запросить email аккаунта перед проверкой возврата» обычно достаточно понятна.

Команды часто держат слишком много тестов, потому что удаление кажется рискованным. Чаще всего это не так. Плотные, актуальные наборы эвалов лучше, чем раздутые пакеты с повторами, мёртвыми правилами и языком продукта, которым никто не пользуется.

Что делать дальше

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

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

Храните провалившиеся ответы в одном доступном для команды месте. Это может быть общий документ, борд задач или простая папка с короткими заметками. Формат менее важен, чем скорость. Когда лидер поддержки, PM или инженер видит один и тот же плохой ответ дважды, он должен точно знать, куда его положить.

Эта привычка быстро окупается. Команда, которая сохраняет даже по десять реальных провалов в месяц, построит гораздо лучше пакет, чем команда, которая однажды сочинит пятьдесят промптов и больше их не тронет. Реальные ошибки лучше по текстуре — они показывают, где пользователи непонятны, нетерпеливы, эмоциональны или просто используют продукт непредсказуемо.

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

Если такая поддержка была бы полезна, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как Fractional CTO и консультант по практическим рабочим процессам разработки ИИ. Такой внешний проход часто достаточно, чтобы превратить устаревший пакет эвалов в то, чему команда снова может доверять.