Что получится в конце
На выходе нужен не пересказ отзывов, а рабочая таблица: одна строка на отзыв, единые категории, подтверждающая цитата и измеримые показатели. Из неё собираются топ проблем, различия сегментов, динамика по неделям и backlog улучшений.
Гайд подходит для отзывов с маркетплейса, анкет NPS, обращений поддержки и комментариев в приложении.
Шаг 1. Сформулируйте один бизнес-вопрос
Выберите решение, которое должно измениться после анализа: что исправить в продукте, почему падает рейтинг, какие возражения мешают покупке или где ломается доставка. Запишите период и сегмент.
Плохая цель — «узнать мнение клиентов». Хорошая — «найти три причины оценок 1–3 за последние 60 дней и оценить их долю».
Шаг 2. Соберите исходную таблицу
Минимальные столбцы: review_id, дата, текст, оценка, продукт, канал и сегмент. ID нужен для проверки и повторного запуска. Не объединяйте несколько отзывов в одну ячейку.
Удалите служебные ответы компании и точные дубли, но сохраните число повторов. Телефоны, email, номера заказов и другие персональные данные удалите до передачи внешней модели.
Шаг 3. Создайте кодировочную схему
Начните с 30–50 разных отзывов и вручную выделите 8–15 тем: цена, качество, доставка, интерфейс, поддержка. Для каждой темы напишите определение и два примера.
Разрешите несколько тем в одном отзыве и категорию «другое». Не заставляйте модель выбирать близкую метку, если доказательств нет.
Шаг 4. Зафиксируйте формат результата
Попросите возвращать JSON или таблицу с полями: ID, themes, sentiment, severity, request_type, evidence_quote и confidence. Значения перечислите заранее. Цитата должна дословно подтверждать метку.
Никаких имён клиентов и придуманных причин. Если текст неоднозначен, модель ставит needs_review=true.
Шаг 5. Проведите пилот на 50 строках
Не запускайте сразу весь массив. Сравните разметку модели со своей: где смешиваются цена и ценность, где сарказм ошибочно считается позитивом, где отзыв содержит две независимые проблемы.
Уточните определения и примеры, затем повторите те же 50 строк. Менять схему после полной обработки дорого и разрушает сопоставимость.
Шаг 6. Обрабатывайте пакетами
Разделите данные на небольшие партии, сохраняя один system prompt, версию схемы и параметры модели. Записывайте номер batch и статус. При сбое перезапускайте только незавершённые ID.
Не просите модель помнить предыдущие партии. Справочник категорий передаётся заново, а итоговые числа вычисляются после объединения результатов.
Готовый промпт для разметки
Используйте роль аналитика, определения категорий и строгий контракт результата. Главная инструкция: анализировать только данный текст и возвращать доказательство.
Пример: «Для каждого review_id выбери до трёх тем из справочника, оцени sentiment и severity, приведи короткую точную цитату. Не делай вывод, которого нет в отзыве. Неоднозначное пометь needs_review».
Шаг 7. Проверьте качество
Вручную проверьте случайные 10% строк, все low-confidence случаи и все отзывы с высокой серьёзностью. Посчитайте согласие по каждой теме, а не одно среднее число.
Если модель систематически путает две категории, исправьте их определения или объедините. Оценку качества сохраняйте рядом с версией prompt.
Шаг 8. Посчитайте показатели
Формулами или скриптом посчитайте число и долю отзывов по темам, среднюю оценку, долю негатива и изменение к прошлому периоду. Один отзыв с тремя темами входит в каждую тему, поэтому доли тем могут суммарно превышать 100%.
Не поручайте LLM считать сотни строк из контекста: классификацию делает модель, агрегацию — детерминированный инструмент.
Шаг 9. Расставьте приоритеты
Для каждой проблемы оцените частоту, серьёзность, затронутый сегмент, влияние на выручку и сложность исправления. Редкая потеря оплаты может быть важнее сотни пожеланий изменить цвет кнопки.
К каждой рекомендации приложите число отзывов, период и 2–3 репрезентативные цитаты. Так команда видит основание, а не мнение нейросети.
Шаг 10. Сделайте анализ повторяемым
Сохраняйте сырой snapshot, очищенный набор, prompt, taxonomy version, model version и размеченный результат. Новый период прогоняйте по той же схеме, а изменения категорий оформляйте как новую версию.
Автоматический еженедельный отчёт показывает новые темы и резкие скачки; человек подтверждает продуктовые выводы.
Типичные ошибки
- Просить «проанализировать всё» без бизнес-вопроса.
- Загружать персональные данные без необходимости.
- Придумывать категории до просмотра реальных отзывов.
- Считать один отзыв только одной темой.
- Верить sentiment без проверки сарказма и контекста.
- Просить модель одновременно размечать и считать.
- Публиковать вывод без цитат и размера выборки.
- Сравнивать периоды с разными taxonomy и prompt.