Лид: Подготовка данных, классификация обращений, поиск повторяющихся причин и ручная проверка аналитических выводов.
Языковые модели помогают разбить тысячи обращений на темы, найти повторяющиеся причины жалоб и подготовить черновик отчёта. Результат требует проверки: модель может объединить разные ситуации под одним заголовком или пропустить редкую, но важную причину. Ниже — рабочий процесс от подготовки данных до отчёта с таблицами проверки и чек-листом для контроля выводов.
Подготовка данных для классификации
Языковая модель работает с текстом. Перед анализом необходимо собрать обращения в единый формат и удалить персональные данные, которые не влияют на суть проблемы.
Состав исходных данных
Минимальный набор полей для классификации:
- уникальный идентификатор обращения;
- текст обращения или последовательность сообщений клиента;
- дата и время создания;
- канал обращения (чат, форма, почта);
- статус обращения (открыто, закрыто, в работе).
Дополнительные поля — категория, присвоенная оператором, продукт или услуга, тип клиента — помогут проверить качество автоматической классификации, сопоставив результат модели с оценкой человека.
Удаление персональных данных
Перед отправкой данных в языковую модель замените имена, телефоны, адреса электронной почты, номера карт и документов на метки [ИМЯ], [ТЕЛЕФОН], [EMAIL], [НОМЕР]. Это снижает риск утечки чувствительной информации и не влияет на определение темы обращения. OWASP относит утечку данных к основным рискам приложений на основе больших языковых моделей (проверено 2026-10-03).
Экспорт и формат
Сохраните данные в CSV или JSON. CSV подходит для простой структуры: одна строка — одно обращение. JSON удобнее, если обращение содержит несколько сообщений или вложенные поля. Убедитесь, что файл сохранён в UTF-8, чтобы кириллица отображалась корректно.
Выбор модели и способа классификации
Классификация обращений может выполняться по заранее заданному списку категорий или путём автоматического поиска тем в данных. Выбор зависит от задачи и объёма данных.
| Подход | Когда использовать | Преимущества | Ограничения |
|---|---|---|---|
| Классификация по списку | Есть справочник категорий; нужна совместимость с CRM | Понятные категории; результат можно сопоставить с ручной разметкой | Модель не предложит новую категорию, если её нет в списке |
| Извлечение тем | Список категорий неполон или устарел; ищете новые проблемы | Модель найдёт повторяющиеся темы без заготовки | Названия тем требуют ручного редактирования; сложно сравнивать с прошлыми периодами |
Для первого анализа подходит извлечение тем: модель группирует обращения и предлагает описание каждой группы. После проверки можно составить список категорий и в следующий раз применить классификацию по списку.
Формирование промпта для классификации
Промпт должен описывать задачу, формат входных данных и ожидаемый результат. Чем точнее инструкция, тем меньше потребуется правок.
Пример промпта для извлечения тем
Ты аналитик обращений клиентов. Перед тобой список обращений в службу поддержки.
Твоя задача:
1. Прочитать каждое обращение.
2. Определить основную причину или тему.
3. Сгруппировать обращения с похожими причинами.
4. Для каждой группы дать короткое название темы и краткое описание.
Формат ответа:
Тема: [название]
Описание: [1–2 предложения]
Обращения: [идентификаторы через запятую]
Обращения:
ID: 1001
Текст: Не могу войти в личный кабинет, пишет «неверный пароль».
ID: 1002
Текст: Забыл пароль, кнопка восстановления не работает.
ID: 1003
Текст: Заказ пришёл с браком, хочу вернуть деньги.
Пример промпта для классификации по списку
Ты классификатор обращений. Для каждого обращения выбери одну категорию из списка:
- Вход и авторизация
- Оплата и счета
- Доставка и логистика
- Возврат и брак
- Технические неполадки
- Прочее
Формат ответа:
ID: [идентификатор]
Категория: [название категории]
Обращения:
ID: 1001
Текст: Не могу войти в личный кабинет, пишет «неверный пароль».
Указание формата ответа упрощает парсинг результата скриптом и снижает вероятность получения свободного текста вместо структурированных данных.
Запуск классификации и обработка результата
Если обращений больше нескольких десятков, разбейте файл на пакеты по 20–50 записей. Это позволит уложиться в контекстное окно модели и упростит поиск ошибок.
Отправка данных
Используйте API языковой модели: OpenAI Chat Completions, Anthropic Claude, YandexGPT или локальную модель через Ollama. Передайте промпт в роли «system» или в начале сообщения «user», затем добавьте пакет обращений. Сохраните ответ в отдельный файл с указанием номера пакета.
Парсинг ответа
Если модель вернула текст в указанном формате, извлеките категории или темы регулярным выражением или простым парсером. Если формат нарушен — например, модель добавила пояснение перед списком, — скорректируйте промпт, указав «Не добавляй пояснения, начинай сразу с Темы или ID».
Объединение результатов
Соберите все пакеты в единый CSV-файл. Добавьте столбец «Категория» или «Тема» рядом с идентификатором обращения. Проверьте, что каждое обращение получило одну категорию. Если модель предложила несколько вариантов, выберите первый или попросите модель явно выбрать один.
Проверка выборки классификации
Автоматическая классификация может содержать ошибки: модель объединяет разные проблемы под одним заголовком или присваивает обращению категорию по ключевому слову, не разобравшись в контексте. Проверка выборки помогает оценить точность и скорректировать промпт или список категорий.
Размер выборки
Для набора до 1000 обращений проверьте 5–10 % случайных записей из каждой категории. Для большего объёма достаточно 50–100 обращений на категорию. Если категория содержит менее 10 обращений, проверьте все.
Метод проверки
Откройте исходный текст обращения и сравните с присвоенной категорией. Зафиксируйте результат в таблице:
| ID обращения | Присвоенная категория | Корректно (да/нет) | Правильная категория | Комментарий |
|---|---|---|---|---|
| 1001 | Вход и авторизация | Да | — | — |
| 1003 | Доставка и логистика | Нет | Возврат и брак | Модель сфокусировалась на слове «пришёл» |
Посчитайте долю корректных присвоений. Если точность ниже 80 %, уточните промпт: добавьте примеры разметки, укажите ключевые признаки каждой категории или разделите сложную категорию на две.
Поиск повторяющихся причин
После классификации найдите конкретные причины внутри каждой категории. Например, категория «Вход и авторизация» может содержать обращения о забытом пароле, ошибке сервера, блокировке аккаунта и проблемах с двухфакторной аутентификацией.
Промпт для извлечения причин
Ты аналитик причин проблем. Перед тобой обращения из категории «Вход и авторизация».
Твоя задача:
1. Прочитать каждое обращение.
2. Определить конкретную причину проблемы.
3. Сгруппировать обращения с одинаковой причиной.
4. Указать количество обращений в каждой группе.
Формат ответа:
Причина: [описание]
Количество: [число]
Примеры ID: [первые 3 идентификатора]
Обращения:
ID: 1001
Текст: Не могу войти в личный кабинет, пишет «неверный пароль».
ID: 1002
Текст: Забыл пароль, кнопка восстановления не работает.
Проверка причин
Модель может назвать причиной описание действия клиента («Клиент не может войти») вместо технической или процессной проблемы («Ссылка для восстановления пароля не приходит на почту»). Проверьте 5–10 обращений из каждой группы причин и переформулируйте названия, чтобы они указывали на устранимую проблему.
Формирование отчёта
Отчёт должен содержать распределение обращений по категориям, список повторяющихся причин и примеры текстов для каждой причины. Это позволит команде поддержки или продукта сразу понять масштаб проблемы и приоритеты.
Структура отчёта
- Общее количество обращений и период анализа.
- Распределение по категориям: таблица с названием категории, количеством обращений и долей от общего числа.
- Топ-5 причин в каждой категории: название причины, количество обращений, примеры ID для выборочной проверки.
- Редкие причины: обращения, которые не вошли в крупные группы, но могут указывать на новые проблемы.
- Рекомендации: черновик действий на основе данных, требует обсуждения с командой.
Пример таблицы распределения
| Категория | Количество обращений | Доля, % |
|---|---|---|
| Вход и авторизация | 340 | 34 |
| Оплата и счета | 220 | 22 |
| Доставка и логистика | 180 | 18 |
| Возврат и брак | 150 | 15 |
| Технические неполадки | 80 | 8 |
| Прочее | 30 | 3 |
Автоматическая генерация черновика отчёта
Передайте языковой модели сводную таблицу категорий и список причин. Попросите составить текст отчёта в формате Markdown или HTML. Укажите, что отчёт предназначен для команды продукта, и модель не должна предлагать решения, которые требуют знания архитектуры системы или бизнес-процессов.
Условный пример: анализ обращений интернет-магазина
Представим интернет-магазин, который получает около 1000 обращений в месяц через форму обратной связи, чат и электронную почту. Команда поддержки вручную размечает обращения, но список категорий не обновлялся два года, и часть обращений попадает в «Прочее».
Шаг 1: Подготовка данных
Выгрузили обращения за последний месяц в CSV. Удалили имена, телефоны и адреса электронной почты регулярными выражениями. Оставили поля: ID, дата, канал, текст обращения, категория оператора.
Шаг 2: Извлечение тем
Разбили файл на 20 пакетов по 50 обращений. Отправили каждый пакет в API с промптом для извлечения тем. Модель вернула 12 тем, включая «Проблемы с промокодом», «Отмена заказа», «Неверный адрес доставки».
Шаг 3: Проверка выборки
Проверили 10 случайных обращений из каждой темы. Обнаружили, что «Проблемы с промокодом» включает как технические ошибки («промокод не применяется»), так и вопросы о сроке действия. Разделили тему на две: «Промокод не работает» и «Вопросы о промокодах».
Шаг 4: Поиск причин
Для темы «Промокод не работает» попросили модель извлечь причины. Получили: истёк срок действия, минимальная сумма заказа не достигнута, промокод не применяется к товарам со скидкой, техническая ошибка. Проверили примеры — всё корректно.
Шаг 5: Отчёт
Сформировали таблицу распределения тем и список топ-3 причин для каждой темы. Обнаружили, что 15 % обращений связаны с промокодами, из них половина — технические ошибки. Передали данные команде разработки для проверки логики применения скидок.
Этот пример показывает рабочий процесс, но не является реальным кейсом и не содержит измеренных результатов.
Типичные ошибки классификации
Модель может неправильно интерпретировать текст обращения или объединить разные проблемы. Знание частых ошибок помогает настроить промпт и проверку.
Фокус на ключевых словах
Модель присваивает категорию «Доставка», если в тексте встречается слово «доставка», даже если клиент жалуется на качество товара, который был доставлен. Решение: добавьте в промпт инструкцию «Определи основную причину обращения, игнорируя упоминания о доставке или оплате, если они не являются проблемой».
Объединение разных причин
Модель называет причиной «Не могу войти в аккаунт», объединяя обращения о забытом пароле, технических ошибках и блокировке. Решение: попросите модель выделять конкретную причину, а не общее описание действия клиента.
Игнорирование контекста
Если обращение содержит несколько сообщений, модель может классифицировать только последнее. Решение: объедините все сообщения клиента в одно поле или явно укажите в промпте «Учитывай всю переписку».
Изобретение категорий
При классификации по списку модель иногда предлагает категорию, которой нет в перечне. Решение: завершите список категорий фразой «Если ни одна категория не подходит, выбери "Прочее"» и настройте параметр температуры на низкое значение (0.0–0.3).
Управление рисками и безопасность
Использование языковых моделей для анализа обращений создаёт риски утечки данных, неконтролируемых расходов и зависимости от качества выводов модели. NIST AI Risk Management Framework связывает управление рисками ИИ с целями организации и допустимым уровнем риска (проверено 2026-10-03).
Защита персональных данных
Удаляйте или маскируйте персональные данные перед отправкой в модель. Если используете API стороннего провайдера, уточните условия обработки данных: некоторые провайдеры используют запросы для дообучения моделей, если не отключена соответствующая опция.
Ограничение расходов
Установите лимит на количество токенов или запросов в день. Проверяйте стоимость обработки одного обращения перед запуском полного анализа. Для моделей с оплатой за токены считайте примерное количество токенов: один русский текст на 100 слов занимает около 150–200 токенов.
Контроль галлюцинаций
Модель может выдумать причину, если в данных нет явного объяснения проблемы. Всегда проверяйте выборку результатов и сверяйте выводы отчёта с исходными текстами обращений. Не публикуйте отчёт без ручной проверки.
Аудит промптов
Сохраняйте версии промптов и результаты классификации. Это позволит повторить анализ с теми же условиями и сравнить результаты при изменении промпта или модели.
Чек-лист подготовки и проверки
Используйте этот список перед запуском классификации и перед публикацией отчёта.
Перед анализом
- Данные выгружены в CSV или JSON с уникальным идентификатором каждого обращения.
- Персональные данные удалены или заменены метками.
- Промпт содержит описание задачи, формат входных данных и ожидаемый формат ответа.
- Выбран размер пакета, умещающийся в контекстное окно модели.
- Установлен лимит на количество запросов или токенов.
После классификации
- Каждое обращение получило одну категорию или тему.
- Проверена выборка: не менее 5–10 % случайных записей из каждой категории.
- Точность классификации составляет не менее 80 %. Если ниже — промпт скорректирован и анализ повторён.
- Названия тем и причин переформулированы для ясности и указывают на устранимую проблему.
- Отчёт содержит ссылки на примеры обращений для выборочной проверки.
- Рекомендации в отчёте являются черновиком и требуют обсуждения с командой.
Частые вопросы
Можно ли полностью автоматизировать анализ обращений?
Автоматизировать можно классификацию и группировку, но проверка выборки и формулировка выводов требуют участия человека. Модель не знает контекста бизнес-процессов и может предложить нереалистичные или неприоритетные решения.
Какую модель выбрать для классификации на русском языке?
Для русскоязычных текстов подходят GPT-4, GPT-4 Turbo, Claude 3, YandexGPT Pro, GigaChat Pro. Локальные модели Saiga, Vikhr и ruGPT-3.5 справляются с классификацией по списку, но менее точны при извлечении тем. Проверьте качество на тестовой выборке перед запуском полного анализа.
Как часто обновлять список категорий?
Запускайте извлечение тем раз в квартал, чтобы обнаружить новые повторяющиеся проблемы. Если модель предлагает тему, которой нет в текущем списке, и проверка подтверждает её актуальность, добавьте категорию и используйте классификацию по обновлённому списку в следующий раз.
Что делать, если модель возвращает ответ не в указанном формате?
Уточните промпт: добавьте фразу «Не добавляй пояснения, начинай сразу с указанного формата» или «Верни только структурированный ответ без вводных слов». Если модель продолжает нарушать формат, используйте режим JSON (если доступен) или парсите ответ регулярным выражением, извлекая нужные поля.
Как оценить стоимость анализа?
Посчитайте среднее количество токенов на одно обращение, умножьте на общее количество обращений и на цену за 1000 токенов. Добавьте токены промпта. Например, 1000 обращений по 100 слов (≈150 токенов) + промпт 200 токенов на пакет из 50 обращений = (150 × 1000 + 200 × 20) / 1000 = 154 тысячи токенов. Уточните актуальную цену у провайдера.
Можно ли использовать результат модели для автоматической маршрутизации обращений?
Да, если точность классификации на проверенной выборке превышает 90 % и ошибочная маршрутизация не создаёт критических проблем. Настройте отправку в специалиста на основе присвоенной категории, но сохраните возможность ручного переназначения. Регулярно проверяйте выборку автоматически маршрутизированных обращений.
Практический вывод
Языковые модели ускоряют классификацию обращений и помогают обнаружить повторяющиеся причины проблем. Процесс требует подготовки данных с удалением персональных сведений, проверки выборки результатов и ручного контроля выводов отчёта. Промпт должен задавать формат ответа, чтобы упростить парсинг. Проверка 5–10 % случайных записей из каждой категории покажет реальную точность и укажет на ошибки объединения или игнорирования контекста. Отчёт с распределением тем и списком причин служит основой для обсуждения приоритетов, но не заменяет анализ команды продукта или поддержки. Регулярное извлечение тем помогает обновлять список категорий и замечать новые проблемы до того, как они станут массовыми.