Золотой набор запросов: как держать его в рабочем виде

Почему набор быстро стареет

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

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

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

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

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

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

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

Какие запросы должны в нем жить

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

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

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

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

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

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

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

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

Откуда брать новые сценарии

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

Самый честный источник - продовые логи. Но брать их можно только после маскировки персональных данных. Команда обычно раз в неделю выгружает свежую выборку, убирает дубли и отмечает запросы, где модель ошиблась, ответила не в том формате или ушла в лишние детали. Если у вас уже есть маскирование PII и аудит по каждому запросу, собирать такие примеры заметно проще.

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

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

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

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

Как обновлять набор после каждого изменения

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

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

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

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

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

Дальше запускайте весь набор минимум на двух вариантах: на текущей модели и на кандидатной. Сравнивайте не только общий балл, но и конкретные падения по новым кейсам. Это особенно полезно, когда вы меняете провайдера или маршрут модели. Если команда работает через единый OpenAI-совместимый эндпоинт, такой прогон проще встроить в обычный пайплайн. Например, в RU LLM можно сменить base_url на api.rullm.com и продолжать использовать те же SDK, код и промпты, а потом сравнивать прогоны разных моделей в одном контуре.

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

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

Как хранить версии и причины правок

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

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

Этого достаточно, чтобы через полгода быстро ответить на два вопроса: почему кейс попал в набор и почему он до сих пор там. Если команда работает в среде с аудит-трейлами и строгими требованиями к изменениям, например в проектах с 152-ФЗ, такой подход быстро становится нормой.

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

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

Хорошо работает привязка к релизам. Если после релиза 2.8 в продукте появился новый маршрут ответа, рядом с кейсом должен стоять тег этого релиза. Если тест добавили после инцидента в поддержке, так и пишите. Потом проще понять, какие изменения реально улучшили оценку промптов, а какие просто раздули тестовый набор для LLM.

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

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

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

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

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

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

Например, в набор можно добавить такие запросы:

• "Потерял карту, можно срочно перевыпустить сегодня?"
• "Если поменяла фамилию, какие документы нужны?"
• "Сколько ждать новую карту и где ее забрать?"
• "Можно оформить перевыпуск не через приложение, а по звонку?"

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

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

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

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

Где команды ломают набор

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

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

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

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

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

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

Короткий список проверок

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

Перед релизом полезно пройтись по пяти вопросам. Они занимают мало времени и хорошо отсекают мусор.

• У каждого кейса есть живая причина. Если никто уже не помнит, зачем запрос попал в набор, его стоит пересмотреть.
• Ожидаемый результат понятен с первого чтения. Если кейс нельзя проверить по короткому правилу, команда начнет трактовать результат по-разному.
• В наборе нет дублей и пустых вариаций. Пять почти одинаковых запросов с разными именами клиента только засоряют активный контур.
• Теги помогают быстро собрать нужный срез: функция, риск, язык, тип пользователя, регуляторный сценарий.
• Активный набор команда гоняет перед каждым релизом, а не "когда будет время".

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

Для команд с чувствительными данными стоит добавить еще один фильтр: видно ли по тегам и описанию, где сценарий связан с персональными данными, маскированием и аудитом. Это особенно полезно в средах с требованиями 152-ФЗ, где ошибка в одном "редком" запросе потом стоит намного дороже, чем лишние 10 минут на чистку набора.

Что сделать на следующей неделе

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

Выберите кейсы из разных типов работы: простой запрос, пограничный случай, частая ошибка, дорогой по токенам сценарий, ответ с риском для бизнеса. Такой набор уже даст заметный сигнал перед релизом. Лучше 40 проверок, которые команда запускает каждую неделю, чем 400, которые никто не открывает.

План на ближайшие дни может быть таким:

• выбрать 30-50 активных кейсов из логов, саппорта и недавних багов
• для каждого кейса записать ожидаемый результат в 1-2 коротких пунктах
• добавить теги: продуктовая функция, риск, язык, длина ответа
• назначить еженедельный слот на 30 минут для разбора новых и спорных кейсов
• перед каждым релизом прогонять набор хотя бы на двух-трех моделях

Еженедельный ритуал лучше держать коротким. За 30 минут можно удалить мертвые кейсы, добавить 3-5 новых и быстро обсудить, где ответы начали "плыть". Если встреча длится час и больше, люди начнут ее пропускать.

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

Если вы сравниваете модели через один OpenAI-совместимый контур, такие прогоны проще автоматизировать и повторять. Для российских команд это особенно удобно в средах, где важны data residency, аудит и работа внутри РФ. В этом сценарии RU LLM может быть практичным вариантом: сервис дает единый эндпоинт, поддерживает биллинг и хранение данных внутри России, так что тестовый контур проще держать ближе к продакшену.

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