Анализ текста нейросетью: отзывы, темы и тональность

Анализ текста нейросетью — короткий ответ

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

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

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

Для чего аналитику читать отзывы пачками

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

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

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

Сначала определите категории, потом открывайте модель

В демонстрации четыре первичные темы: delivery — перевозка, время и передача заказа; payment — списание, чек и возврат денег; quality — свойства и дефекты товара; support — общение с оператором и решение обращения. Это не «естественные» классы, которые модель обязана угадать: это договор аналитика с командой.

Для тональности используем positive, negative, neutral, mixed. Позитив — явная похвала; негатив — явная жалоба; нейтральный текст сообщает факт без оценки; смешанный содержит заметную положительную и отрицательную оценки. Пример «курьер был вежлив, но приехал поздно» относится к доставке и смешанному тону. Фраза «курьер передал заказ в 18:00» нейтральна: в ней нет оценки времени.

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

Темы: delivery — время и передача заказа; payment — списание и чек; quality — свойства товара; support — ответ оператора.
Тон: positive — явная похвала; negative — явная жалоба; neutral — факт без оценки; mixed — обе оценки.
Если классы не подходят, верни other / uncertain. Не выводи догадки как факт.

Контрольная выборка: 64 условных отзыва

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

Файл gold.csv сохранён в исследовательской папке сайта. Там есть идентификатор, текст, тема и тон. Например, «Карта списала сумму дважды, теперь жду возврата» — payment / negative; «Оператор был вежлив, но проблему не решил» — support / mixed. Здесь метку выбирал автор набора, а не нейросеть. Это значит, что эталон прозрачен, но сам нуждается в проверке другим разметчиком перед использованием как настоящего бенчмарка.

В рабочем проекте соберите 60–100 реальных, обезличенных отзывов случайным образом из нужного периода. Не выбирайте только простые примеры. Добавьте длинные, ироничные, смешанные и неоднозначные записи: именно на них схема классов покажет слабые места.

Как размечать вручную, чтобы эталон не обманывал

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

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

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

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

Модели проще отвечать сопоставимо, когда формат фиксирован. Передавайте ID, текст и определения классов. Попросите вернуть только JSON с допустимыми метками; краткое доказательство можно взять как фрагмент исходного текста, чтобы проверить, что ярлык не взят из воздуха. Не просите «подробно объяснить эмоции клиента» — это стимулирует домысливание.

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

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

Разметь отзыв ID=<id>: <текст>.
Темы: delivery, payment, quality, support, other — определения: <словарь>.
Тон: positive, negative, neutral, mixed — определения: <словарь>.
Верни JSON: {"id": <id>, "topic": "...", "sentiment": "...", "evidence": "дословный короткий фрагмент"}.
Если невозможно выбрать метку, верни other или uncertain. Не добавляй неупомянутые факты.

Как сравнить модель с ручной разметкой

После получения предсказаний сохраните отдельный CSV с id, topic, sentiment. Соедините его с gold.csv по ID с проверкой уникальности. Если ID отсутствует или повторяется, остановитесь до подсчёта качества: иначе вы сравниваете не те объекты.

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

Скрипт ниже воспроизводит проверку для темы; тот же вызов нужен для тональности. Он не содержит заранее придуманных ответов модели. Пока файла предсказаний нет, метрик качества тоже нет. На странице можно показать процедуру, но нельзя писать «модель достигла 90%» без реального запуска и сохранённых сырых ответов.

import pandas as pd
gold = pd.read_csv('gold.csv')
pred = pd.read_csv('predictions.csv')  # результат реального прогона
assert gold['id'].is_unique and pred['id'].is_unique
joined = gold.merge(pred, on='id', suffixes=('_gold', '_pred'), validate='one_to_one')
assert len(joined) == len(gold) == len(pred)
for field in ('topic', 'sentiment'):
    print(field, (joined[f'{field}_gold'] == joined[f'{field}_pred']).mean())
    print(pd.crosstab(joined[f'{field}_gold'], joined[f'{field}_pred'], dropna=False))

Что показывает матрица ошибок, а чего не показывает

Матрица помогает увидеть конкретные подмены классов. Если payment часто превращается в delivery, посмотрите тексты, где оплата связана с получением заказа. Возможно, определения пересекаются; возможно, модель цепляется за слово «доставка». Исправление промпта без анализа примеров часто не решает проблему.

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

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

Уточнять определения после ошибок, а не после красивой цифры

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

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

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

Извлечение сущностей: отдельная задача

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

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

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

Суммаризация обращений: краткость с опорой на ID

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

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

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

Четыре ошибки в проекте разметки

Первая — назвать классификацией свободное резюме модели. Без фиксированных меток результаты нельзя сравнивать между неделями; команда увидит изменение формулировок как изменение продукта.

Вторая — считать тональность по одному слову. «Товар хороший, но доставка сорвалась» даёт смешанную оценку. Бинарная метка прячет проблему доставки.

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

Четвёртая — забыть пропущенные ID. Если модель вернула ответ для 60 из 64 строк, доля совпадений на 60 может выглядеть высокой, а четыре самые сложные строки исчезнут. Проверяйте полноту до метрик.

Пятая — публиковать доли синтетического набора как мнение клиентов. Наш файл специально сбалансирован; на нём нельзя оценить реальные частоты проблем.

Приватность и передача отзывов

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

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

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

Чек-лист запуска

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

Для отчёта показывайте период, источник, объём и ограничения выборки. Если использовали синтетику — так и назовите. Если модель не запускалась — не рисуйте график точности. Проверка качества начинается с честного описания того, какие данные были и чего ещё нет.

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

Частые вопросы

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

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

Что лучше: общая тональность или темы? Они отвечают на разные вопросы. Тема показывает, о чём отзыв; тональность — какую оценку даёт автор. Для смешанных сообщений полезна оценка по аспектам.

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

Куда перейти после пилота

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

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