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

Почему набор быстро превращается в свалку

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

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

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

Обычно свалка узнается по четырем признакам:

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

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

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

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

Какие кейсы стоит держать в наборе

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

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

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

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

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

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

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

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

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

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

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

Рабочий порядок обычно выглядит так:

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

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

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

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

Как не терять сложные запросы пользователей

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

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

Что помечать у сложного кейса

Каждому такому примеру нужна короткая метка причины. Команде обычно хватает 1-2 слов: длинный контекст, два намерения, двусмысленная ссылка, конфликт инструкций, риск для денег или комплаенса. Без этой пометки кейс быстро превращается в "еще один странный чат", и через месяц никто не вспомнит, зачем он лежит в наборе.

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

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

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

Когда отправлять пример в архив

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

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

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

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

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

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

Так активный набор остается коротким и рабочим, а архив хранит историю решений, а не мусор.

Как оформить кейс так, чтобы его понимала вся команда

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

Часто команда хранит только текст запроса и пометку "прошел" или "не прошел". Этого мало. Один и тот же вопрос может вести себя по-разному в чате поддержки, в мобильном приложении и во внутреннем помощнике для сотрудников. Без контекста спор начинается заново при каждом релизе.

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

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

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

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

Например, у команды банка карточка может выглядеть так: клиент пишет с ошибками и просит "показать последние списания по карте жены"; канал - чат; язык - русский; риск - высокий; промпт версии 12; проверка - ассистент не выдает чужие данные и просит пройти подтверждение личности. Даже новый сотрудник сразу поймет, что именно проверяет этот кейс.

Когда команда ведет такие карточки одинаково, обсуждение становится короче. Люди спорят уже не о формулировках в таблице, а о самом качестве ответа.

Пример: как команда банка обновляет набор после релиза

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

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

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

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

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

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

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

Частые ошибки при поддержке набора

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

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

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

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

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

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

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

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

Быстрая проверка раз в неделю

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

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

Для такого разбора подойдет короткий чеклист:

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

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

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

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

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

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

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

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

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

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

Если вы сравниваете несколько моделей, удобно прогонять один и тот же набор в одинаковых условиях через единый шлюз. Например, в AI Router на airouter.kz команда может заменить base_url на api.airouter.kz и использовать те же SDK, код и промпты без отдельной обвязки под каждого провайдера.

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