Отзывы помогают понять, о чём люди пишут в конкретном наборе отзывов. Они не рассказывают автоматически, что думают все клиенты: авторы самоотобрались, площадка могла показывать лишь часть сообщений, а молчаливые покупатели в выборке не видны. Сначала зафиксируй, что именно считаешь одним отзывом; затем проси ИИ предложить темы и вручную проверь каждую метку.
Определи границы набора
Запиши источник, дату выгрузки, выбранный период и критерий включения. Единица анализа здесь — один опубликованный отзыв, а не один клиент: человек может оставить несколько отзывов, и это не всегда известно. Знаменатель для простого подсчёта — число отзывов, попавших в этот конкретный набор. Если выборка небольшая, проверь все строки, а не только случайные.
Удаляй имя автора, номер заказа и детали, по которым человека можно узнать. Не загружай частный отзыв в стороннюю модель без разрешённого процесса; модель может работать на фрагментах, которые ты вправе передать. Для анализа пользовательских наблюдений полезно разделять дословно замеченное и интерпретацию, группировать близкое, а затем формулировать выводы и действия; так устроена и качественная процедура GOV.UK (анализ исследовательской сессии). Это не превращает отзывы в репрезентативный опрос.
Пример: пять вымышленных отзывов
Все строки ниже синтетические и предназначены только для демонстрации:
| ID | Текст учебного отзыва |
|---|---|
| R1 | «Отчёт открылся на телефоне, но таблицу пришлось искать внизу» |
| R2 | «Понравилась доставка, коробка пришла целой» |
| R3 | «Не понял, где поменять адрес после оформления» |
| R4 | «Поддержка ответила на вопрос о размере» |
| R5 | «Доставка пришла позже указанного дня» |
Попроси модель предложить небольшой кодбук, но требуй точную опору в строке:
Это обезличенный набор отзывов. Одна строка — один опубликованный отзыв.
Предложи не более пяти описательных кодов. Для каждой строки верни ID, основной код,
дословный фрагмент-основание и отметку «неясно», если текст не позволяет назначить код.
Не делай выводов о причинах, которых автор не назвал. Не придумывай цитаты.
Не экстраполируй на всех покупателей и не выдавай количество этих отзывов за частоту
проблем среди клиентов. Верни также проект кодбука с определениями и примером включения.
Источник и период набора: [..]
Критерий включения: [..]
Строки: [ID, текст после проверки на личные данные]
Гипотетический кодбук и проверка руками
Модель может предложить код поиск элемента интерфейса для R1, положительная доставка для R2, изменение заказа для R3, полезность поддержки для R4 и срок доставки для R5. Это пример возможного чернового вывода, не результат реального запуска. Редактор читает исходный набор и подтверждает или меняет все пять меток; например, R1 говорит, что таблица оказалась внизу, но не обязательно, что интерфейс плохой в целом.
Для настоящего набора посчитай число отзывов с каждой меткой только после проверки. Можно указать: «В выгрузке из N отзывов за период T код встретился в n сообщениях». Не говори «n клиентов» без дедупликации авторов и не называй проценты мнением всех покупателей. Если одному отзыву разрешено несколько кодов, числа кодов не обязаны складываться в число отзывов.
От темы к следующему действию
Сначала отдели наблюдение («в отзыве человек не нашёл таблицу») от вывода («всем трудно пользоваться мобильной версией»). Для сильного вывода потребуются дополнительные данные: проверка интерфейса, обращения в поддержку или отдельное исследование. Для редакционного действия хватит конкретного подтверждённого вопроса: например, сделать инструкцию «где открыть таблицу с телефона», а затем проверить её на интерфейсе.
Сохраняй версию кодбука и причины спорных решений. В следующий раз сравнивай одинаково собранные наборы и описывай их ограничения. Открытые отзывы полезны как источник формулировок и отдельных сигналов, но их знаменатель всегда ограничен выбранной выгрузкой.
Если по проверенным отзывам возникли темы для справки, сравни их с обращениями поддержки, не смешивая источники и единицы анализа. Перед передачей текста модели сверь правила работы с данными.