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

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

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

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

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

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

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

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

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

Какие тикеты брать в набор

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

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

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

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

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

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

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

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

Как обезличить данные и сохранить смысл

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

Правило простое: заменяйте личные данные понятными метками одного типа. Если в диалоге есть телефон, он везде должен стать [PHONE], а не в одном месте [TEL], в другом [NUMBER]. Имя клиента лучше заменить на [NAME_1], номер заказа на [ORDER_1], адрес на [ADDRESS_1]. Тогда текст остается читаемым, а модель видит структуру реального обращения, а не кашу из случайных звездочек.

Сохраняйте связь между одинаковыми сущностями внутри одного диалога. Если клиент Анна упоминается три раза, везде должна стоять одна и та же метка [NAME_1]. То же самое с заказом, магазином, врачом, курьером или филиалом. Иначе пропадает логика разговора. Модель уже не понимает, что речь все время идет об одном и том же заказе, и пример становится беднее, чем был.

Не удаляйте все подряд. Даты, суммы, сроки доставки, статусы заявки и названия тарифов часто влияют на ответ сильнее, чем имя клиента. Если оператор объясняет, почему возврат невозможен после 14 дней, дата нужна. Если спор идет из-за списания на 12 500 тенге, сумму тоже надо оставить. Иначе вы защищаете данные, но ломаете саму задачу.

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

Небольшой пример: "Меня зовут Айдос, заказ 548921, курьер не приехал 12 мая" лучше превратить в "Меня зовут [NAME_1], заказ [ORDER_1], курьер не приехал 12 мая". Личные данные убраны, но причина жалобы осталась ясной.

После маскирования просмотрите вручную 20-30 диалогов, причем целиком, а не по одному предложению. Так быстро всплывают две частые ошибки: утекшие личные данные и слишком агрессивная чистка, когда из текста исчезает смысл. Если вы работаете в компании, где есть требования по хранению данных внутри страны и маскированию PII, такая ручная проверка нужна не для галочки, а для нормального рабочего набора. Для команд в Казахстане это особенно актуально.

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

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

Сначала дайте каждому обращению короткий ярлык намерения клиента. Не нужна сложная таксономия на 40 пунктов. На старте хватает 8-12 меток: "статус заказа", "возврат", "смена адреса", "жалоба", "сбой оплаты", "доступ к аккаунту". Если оператор тратит 15 секунд, чтобы выбрать метку, схема уже перегружена.

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

Что хранить в разметке

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

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

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

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

Пошагово: первый набор за 10 дней

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

Дни 1-3

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

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

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

Дни 4-10

Дальше прогоните анонимизацию. Имена, телефоны, e-mail, адреса, номера заказов, ИИН и реквизиты карты надо заменить на понятные метки вроде [ИМЯ] или [НОМЕР_ЗАКАЗА]. Смысл должен остаться: модель должна понимать, что клиент ждет возврат по конкретному заказу, а не видеть пустой обезличенный текст.

Автоматика ускоряет работу, но без ручной проверки она подводит. Просмотрите хотя бы 10-15% диалогов глазами. Чаще всего маскирование пропускает данные в свободной форме: "мой номер начинается на 8701", "доставка была на Абая 12", "я писал с почты жены".

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

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

Пример набора для интернет-магазина

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Откройте обезличенные диалоги и проверьте опорные детали. Даты, суммы, сроки доставки и номера заказов должны остаться читаемыми и правдоподобными, иначе задача теряет смысл. С анонимизацией ошибаются не реже: команда маскирует все подряд и случайно убивает контекст. "Заказ 18452 от 03.11 на 12 990 тг" нельзя превращать в "[номер] [дата] [сумма]" без формы и связей. Для оценки модели на данных поддержки важны не сами персональные данные, а структура фактов.

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

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

Что делать дальше с этим набором

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

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

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

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

Если вы сравниваете много моделей, удобнее прогонять их через один OpenAI-совместимый эндпоинт. В этом сценарии AI Router может быть удобной прослойкой: команда меняет base_url на api.airouter.kz и продолжает использовать те же SDK, код и промпты без переделки. Это упрощает сравнение на одном и том же наборе.

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

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