Владелец интернет-магазина бытовой техники в Алматы получил красивый разбор отзывов за неделю: три главные темы, проценты и объяснение, почему задерживается доставка. Маркетолог Акмарал открыла исходные тексты и увидела, что покупатели писали только о самой задержке. Причину модель придумала сама. Отчёт выглядел как поставленный диагноз, хотя доставку никто даже не начинал проверять.
Магазину нужен еженедельный разбор тем из отзывов, и проверенные наблюдения должны доходить до тех, кто за них отвечает. Схема такая: ИИ предлагает группировку и черновик, Акмарал сверяет смысл, обычная формула считает записи, а руководитель нужного направления, доставки или поддержки, решает, что исследовать дальше. Все цифры в уроке условные.
Пилот ИИ в разборе отзывов
Исходные отзывы
Сохранить тексты для сверки смысла
Черновик тем
ИИ предлагает группировку и черновик
Проверенный разбор
Акмарал сверяет смысл, формула считает записи
Решение руководителя направления
Передать наблюдения и выбрать, что исследовать
Покупатели сообщили о задержке. Причину команда ещё не исследовала.
Опишите результат, который можно принять
В отчёте должны быть период, число включённых отзывов, темы, ID отзывов по каждой теме, частоты и короткие наблюдения. Если покупатель не назвал причину жалобы, так и пишите: «Причину нужно выяснить». Догадки о причинах пишите под наблюдением, списком вопросов для проверки.
Акмарал как владелец процесса задаёт границу: это разбор отзывов из одного согласованного источника, и обо всех покупателях он не говорит. Тот, кто написал отзыв, уже отличается от того, кто промолчал. Если тема встречается в половине отзывов, это не значит, что ею недовольна половина клиентов.
Приёмку можно проверить по пунктам. Каждая тема опирается на исходные записи. Цитата передаёт их смысл. Число можно пересчитать по ID. Непроверенная причина не становится фактом. Если нарушен хоть один пункт, гладкий слог ошибку не закроет.
Сначала приведите в порядок вход
Зафиксируйте источник, начало и конец периода, какие записи входят и как удаляются повторы. Если одно и то же сообщение дважды попало в выгрузку, частота не должна удвоиться. Для двух разных сообщений от одного человека правило выберите заранее: вы считаете сообщения, обращения или покупателей? В нашем примере единица счёта - отзыв с постоянным ID.
Оригинальный текст, язык и связь с источником храните в рабочей среде, которую разрешили для этих данных. Модели отдавайте только то, что нужно задаче. Доступ и состав данных согласуйте до запуска: если задача только найти темы, имена, телефоны и детали заказа модели ни к чему.
Длинный отзыв, пустая запись и сообщение сразу о трёх проблемах не должны пропадать молча. Исключили запись - запишите причину и сколько таких было. Иначе новый инструмент покажется точнее старого только потому, что перестал разбирать сложные тексты.
Разделите роли модели, правил и человека
| Шаг | Кто делает | Что проверить |
|---|---|---|
| Отбор и удаление точных повторов | Согласованные правила | Период, источник и число исключений |
| Предложение тем | Модель по инструкции | Связь каждой темы с исходными ID |
| Подсчёт | Формула или скрипт по проверенным ID | Уникальность и знаменатель |
| Приёмка по смыслу | Акмарал | Цитаты, ограничения, нет ли новых фактов |
| Передача наблюдений | Акмарал как владелец разбора | Кому ушло и какой следующий шаг |
Автоматическую загрузку файла можно добавить потом. Сначала покажите, что команда выпускает полезный разбор, который можно проверить. Если категории размыты, передача данных без участия человека их не исправит.
В инструкции разрешите отзыву иметь несколько тем и разрешите ответ «непонятно». Отзыв «Заказ привезли поздно, но сотрудник помог разобраться» - это и срок доставки, и работа поддержки. Метка «негатив» теряет половину смысла. А фраза «поздно, потому что не хватило курьеров» добавляет причину, которой в тексте нет.
Считайте отзывы, а не найденные фразы
В проверенном наборе 20 уникальных отзывов. Доставка упоминается в 12, упаковка в восьми, поддержка в шести. Один отзыв может попасть в несколько тем, но внутри темы его ID считается один раз.
| Тема | Уникальных отзывов с темой | Доля от 20 отзывов |
|---|---|---|
| Доставка | 12 | 60% |
| Упаковка | 8 | 40% |
| Поддержка | 6 | 30% |
В сумме выходит 130%, потому что темы пересекаются. Подгонять её к 100% делением на 26 упоминаний не нужно: получится другой показатель, доля среди упоминаний, и на вопрос «сколько отзывов про доставку» он уже не ответит. Например, R01 может входить и в доставку, и в поддержку, но в общем числе отзывов это одна запись.
Частота темы ничего не говорит о тоне. Поддержку могут и хвалить, и ругать. Если для решения это важно, добавьте правило оценки тона, проверьте его и держите исходную фразу рядом с оценкой. Записать шесть упоминаний поддержки в шесть жалоб, не прочитав их, - ошибка.
Подготовьте набор для оценки
Соберите разные отзывы: короткие и длинные, однозначные и спорные, с несколькими темами и с нехваткой сведений. Если покупатели пишут на русском и казахском, нужен проверяющий, который понимает оба языка. Для спорных случаев заранее запишите, какие ответы допустимы: дословного совпадения с образцом требовать не нужно.
Руководство OpenAI по оценке предлагает опираться на реальные задачи и сверять автоматические оценки с проверкой человеком. Для разбора отзывов это значит: соберите список типичных ошибок и свойств хорошего ответа и сравнивайте по нему новую инструкцию с прежней.
Примеры для настройки и входы для проверки держите раздельно. Если после каждого ответа менять запрос под те же двадцать отзывов, рост качества на них ничего не скажет о следующей неделе. После настройки зафиксируйте версию и прогоните её на новых отзывах. Часть входов повторите: так видно, стабилен ли ответ.
В исходном проверочном наборе 18 из 20 отзывов размечены без ошибок. В двух модель добавила причину жалобы. Получается 90% полностью принятых ответов, и это только про этот набор. Перед тем как собрать итоговую таблицу, Акмарал проверила все 20 записей и исправила обе ошибки. Таблица тем выше - уже результат после этой приёмки.
Посчитайте путь до выпуска
Допустим, ручной разбор за неделю занимает три часа. В новом процессе 30 минут уходит на подготовку входа, десять минут на черновик, час на проверку и двадцать минут на правки. Всего два часа. Замер условный: тот же объём, то же принятое качество, отклонённые попытки учтены.
За четыре выпуска в месяц ручная работа занимает двенадцать часов, новая - восемь. При внутренней ставке 5 000 ₸ за час это 60 000 и 40 000 ₸ времени команды. Ставку мы взяли для расчёта, рыночную цену часа она не описывает.
Сверх времени на выпуски нужен час сопровождения в месяц, ещё 5 000 ₸. На инструмент заложено 10 000 ₸ в месяц, без привязки к тарифу какого-то сервиса. Новый процесс по этой оценке стоит 40 000 + 5 000 + 10 000 = 55 000 ₸. Это на 5 000 ₸ в месяц меньше ручного.
Первая настройка заняла ещё три часа, это 15 000 ₸. Поэтому первый месяц обходится в 70 000 ₸ против ручных 60 000 ₸: он оплачивает настройку, а экономия начинается со второго месяца. Реальные платежи и оценку времени записывайте в разные строки.
Назначьте владельца и путь при сбое
У Акмарал, которая выпускает разбор, должны быть исходные записи, критерии и право остановить отправку. В журнале она хранит версию инструкции, инструмент, время проверки, ошибки и правки. Если качество упадёт, по журналу видно, что поменялось: вход или процесс.
Если файл не пришёл, часть записей потерялась или проверить смысл некому, отчёт не становится готовым только потому, что настал понедельник. Заранее решите, кто сделает разбор вручную, кто предупредит получателя и кто восстановит процесс. Если сбои повторяются, пересмотрите объём и способ работы.
Расширять пилот начинают с новой задачи, которую тоже можно проверить. Отправить черновик редактору и отправить выводы клиентам - разные действия. Для публикации или изменения бюджета нужны свои полномочия и свои условия приёмки, а удачная группировка отзывов их не проверяла.
Задание: что известно после пилота
Возьмите свой еженедельный процесс, который хотите частично или целиком отдать ИИ. Запишите единицу счёта, исходные данные, критерии приёмки, владельца, полное время работы и новые денежные расходы. Отметьте, какой шаг остаётся за человеком и как он проверит результат.
Потом разберите ситуацию магазина. Команда показывает, что 18 из 20 отзывов размечены без ошибок, и предлагает слать следующие отчёты без проверки. Ещё она считает 130% в таблице ошибкой и хочет разделить все темы на 26. Что ей ответить и когда по расчёту окупится первая настройка?
В двух ответах появились причины, которых в отзывах не было, поэтому 90% - не повод убирать проверку. Нужно поправить инструкцию и прогнать её на новых входах. Сумма долей тоже не ошибка: темы пересекаются, и каждая доля отвечает на вопрос, сколько из двадцати отзывов упоминают эту тему. Деление на 26 поменяет смысл показателя. Знаменатель оставьте прежним, а пересечение объясните под таблицей.
По условной оценке повторный процесс дешевле ручного на 5 000 ₸ в месяц. Три месяца такой разницы покроют 15 000 ₸ первой настройки, если объём, качество и трудоёмкость не изменятся. За три месяца оба варианта стоят по 180 000 ₸: ручной 3 × 60 000, новый 15 000 + 3 × 55 000. Сравнялись оценки. Деньгами новый процесс за три месяца дороже на 30 000 ₸: оклады те же, а инструмент оплачен. Убирать проверку Акмарал расчёт не разрешает.
Запись о вашем процессе готова, если коллега может по ней повторить подсчёт и понять, кто принимает выпуск. Нет исходных данных или времени на проверку - значит, качество пока никто не контролирует. Труд и платежи слиты в одну сумму без пояснения - разделите их, прежде чем просить бюджет. Эти дыры закрывают до расширения пилота.