Синтетические наборы тестов, которые могут создавать команды продукта и операций

Проблема с тестированием ИИ «на глаз»

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

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

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

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

Тогда обсуждение буксует. Команда спорит о вкусе вместо результатов. Кто‑то заботится о скорости, кто‑то — о тоне, кто‑то — о политике. Без общих примеров никто не может показать, улучшил ли последний промпт, смена модели или правка воркфлоу ситуацию.

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

Как выглядит полезный кейс

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

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

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

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

У большинства хороших кейсов пять частей:

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

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

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

Именно это делает наборы полезными. Каждый кейс остаётся маленьким, привязанным к реальности и простым для одинаковой оценки людьми.

Сбор исходного материала без кода

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

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

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

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

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

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

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

Соберите первый набор в шесть шагов

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

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

Во‑вторых, соберите 20–30 недавних примеров. Используйте скриншоты, письма, чаты, формы или короткие заметки. Реальная работа важнее придуманных промптов, потому что в ней есть детали, на которых системы спотыкаются.

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

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

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

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

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

Оценивание результатов так, чтобы люди соглашались

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

Короткая рубрика работает лучше. Держите каждое правило конкретным и легко проверяемым за минуту.

Используйте короткую рубрику

Для многих кейсов достаточно четырёх проверок:

• Факты: использовал ли ответ правильные детали из кейса?
• Действие: выполнил ли он запрошенную задачу — например, составил ответ, классифицировал проблему или предложил следующий шаг?
• Тон: звучало ли это уместно для клиента и ситуации?
• Полнота: охватил ли ответ всю просьбу, не пропустив нужную часть?

Используйте простой скоринг. «Пройдено/не пройдено» работает для рутинной работы. При необходимости используйте 0, 1 и 2: 0 — промах, 1 — частично правильно, 2 — явно правильно.

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

Разделяйте чистые кейсы и «грязные»

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

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

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

Записывайте одну короткую заметку каждый раз, когда кейс проваливается. Десяти слов достаточно: «неверный статус заказа», «пропущен второй вопрос», «тон слишком холодный» или «выдуманная политика возврата».

Эти заметки так же важны, как и оценка. Через 20–30 кейсов паттерны проявляются быстро. Продукт и операции тогда могут исправить промпт, воркфлоу или исходный материал вместо догадок.

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

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

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

Небольшой стартовый набор

Держите первый набор достаточно простым, чтобы его можно было просмотреть за один присест. Например:

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

Для каждого кейса просите модель подготовить следующий ответ или предложить следующее действие. Не просите всё сразу. «Составьте следующий ответ службы поддержки» — понятно. «Выберите следующее действие согласно политике» — тоже понятно. Если просить ответ, действие, тон, эскалацию и теги в одном промпте, оценка быстро станет запутанной.

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

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

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

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

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

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

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

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

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

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

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

Несколько привычек предотвращают большинство ошибок:

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

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

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

Короткое ревью перед прогоном экономит часы неправильной оценки. Хорошие наборы на этом этапе обычно выглядят немного скучными — это нормально. Ясность важнее остроумия.

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

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

Очистите входы до того, как кто‑то начнёт их оценивать. Удалите имена, адреса электронной почты, номера аккаунтов и всё, что указывает на реального человека или компанию. Замените их простыми метками вроде Customer A или Order 1234, чтобы кейс оставался реалистичным, не раскрывая приватные данные.

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

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

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

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

Что делать после первого прогона

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

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

Простой ритм работает хорошо:

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

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

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

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

Если команде нужна помощь в формировании процесса оценки, выборе метрик или превращении сырых кейсов в надёжные — Oleg Sotnikov at oleg.is занимается этим как fractional CTO и советник стартапам. Внешний взгляд полезен, когда команда слишком близко к проблеме и постоянно меняет слишком много параметров одновременно.