Компанія з 3000 відгуками на місяць та 800 коментарями NPS на рік має насправді одну проблему: не брак даних, а брак часу, щоб їх прочитати. Аналітику потрібен тиждень, щоб виявити змістовний патерн за один квартал. Поки звіт потрапить на нараду керівництва, дані матимуть чотири тижні затримки. За цей час клієнти, які писали про конкретний біль, вже давно вирішили, чи залишатися.
Добре спроектована система аналізу настроїв перетворює цей тижневий процес на безперервний потік сигналів. Нижче описано, як така система працює, де закінчуються її компетенції та де починається рішення людини.
Поза позитивний/негативний: аналіз за аспектами та намір#
Мітка «негативний» на відгуку не каже нічого корисного. «Негативний, стосується терміну доставки, з наміром відмовитися» — це операційний сигнал.
Аналіз за аспектами (aspect-based sentiment analysis, ABSA) розділяє текст на конкретні виміри: продукт, ціна, обслуговування, доставка, інтерфейс. Одне речення може мати позитивний настрій щодо продукту та негативний щодо доставки одночасно. Модель, яка зводить це до однієї мітки, втрачає половину інформації.
Намір доповнює картину. Клієнт, який пише «розглядаю відмову від підписки після цієї події», має інші пріоритети обслуговування, ніж клієнт, який пише «доставка запізнилася, але продукт чудовий». Першого варто передати на утримання того ж дня. Другому достатньо подякувати.
Терміновість — третій вимір. Відгук на публічному порталі від клієнта з річним контрактом і «Скандал, немає доступу 48 годин» вимагає іншого часу реакції, ніж анонімний коментар про естетику упаковки. Модель може виводити терміновість з комбінації: тону, сигнальних слів, історії клієнта в CRM та каналу (публічний відгук має вищий пріоритет для іміджу, ніж приватний тікет).
Звідки походить текст і як його зібрати#
Дані для аналізу настроїв походять з кількох джерел, які відрізняються структурою та вимогами до обробки.
Відгуки та оцінки продуктів: структуровані (зірочки + текст), обсяг змінний, часто анонімні. Зірочка — слабкий сигнал. Відгук з оцінкою 3/5 може бути гіркотою або ентузіазмом. Текстовий зміст має цінність, числова оцінка — лише як контекст.
Коментарі NPS: короткі, часто лаконічні, написані під впливом моменту. Складніші для класифікації за аспектами, добрі для виявлення загальних трендів настрою та патернів після кампаній.
Тікети підтримки: найбагатші контекстом. Клієнт описує конкретну проблему, надає дати та продукти. Водночас найдорожчі для обробки, оскільки часто містять персональні дані (ім’я, номер замовлення, e-mail), які потребують маскування перед аналізом.
Згадки в соціальних мережах: неструктуровані, скорочені, повні сленгу та абревіатур. Потребують окремого препроцесингу та окремої моделі, каліброваної під platform-specific language.
Збір даних з різних джерел — це завдання ETL, а не ШІ. Модель аналізу настроїв отримує чистий текст після нормалізації.
Архітектура системи: від тексту до структурованого сигналу#
Шаблон, який ми використовуємо в Cashcrown при проєктуванні таких систем, складається з чотирьох кроків.
Крок 1: препроцесинг та маскування PII. Текст очищається від персональних даних перед передачею до моделі висновування. Номер замовлення, ім’я, адреса електронної пошти замінюються токенами-замінниками. Це не опція для тікетів та форм. Це вимога GDPR.
Крок 2: багатовимірна класифікація. Модель (або промпт LLM з few-shot examples) повертає structured output з полями: aspect (доставка/продукт/ціна/обслуговування/інтерфейс), sentiment_per_aspect (позитивний/негативний/змішаний), intent (інформація/скарга/відмова/прохання про допомогу/похвала), urgency (висока/стандартна/низька), keywords. Валідація схеми усуває порожні або галюциновані поля. Якщо модель повертає urgency: null або confidence score нижче порогу, запис потрапляє до черги ручної перевірки.
Крок 3: агрегація та виявлення трендів. Структуровані записи потрапляють до аналітичної бази. Агрегація за тижнями та аспектами показує, коли відбулося погіршення в конкретному вимірі. Зростання частки intent: відмова на 8 процентних пунктів протягом двох тижнів — це операційний сигнал, який випереджає дані про відтік на кілька тижнів.
Крок 4: маршрутизація та human-oversight. Записи з urgency: висока або intent: відмова автоматично потрапляють до черги консультанта з готовим брифом (аспект, цитата, історія клієнта з CRM). Консультант приймає рішення. Модель не контактує з клієнтом самостійно. Це правило жорстке і не має винятків.
Таблиця: що модель класифікує і де закінчується автоматизація#
| Вимір | Що встановлює модель | Де вирішує людина |
|---|---|---|
| Продуктовий аспект | Доставка, ціна, обслуговування, інтерфейс, продукт | Новий аспект, відсутній у тренувальних даних |
| Настрій за аспектом | Позитивний, негативний, змішаний | Іронія, сарказм, специфічний галузевий сленг |
| Намір | Скарга, відмова, похвала, прохання про допомогу | Неоднозначний намір або юридичний (формальна рекламація) |
| Терміновість | Висока, стандартна, низька | Кожна справа з терміновість: висока перед контактом з клієнтом |
| Тренд | Зростання/зниження частки виміру у часовому вікні | Інтерпретація та рішення, що робити з трендом |
Обмеження, про які не можна замовчувати#
Кожна система аналізу настроїв має структурні слабкості. Ігнорування їх призводить до довіри даним, яким довіряти не слід.
Сарказм та іронія. «Чудове обслуговування, тільки замовлення загубилося тричі» — це речення позитивне з лексичної точки зору та негативне за наміром. Мовні моделі справляються з саркастичними реченнями значно гірше, ніж з буквальними. У польському тексті, де іронія зустрічається частіше, ніж в англійському тренувальному корпусі, помилкова класифікація таких випадків є повторюваним патерном, а не випадковою помилкою.
Змішаний настрій в одному реченні. Текст «доставка експрес, але якість продукту розчарувала» містить два протилежні сигнали. Одновимірний класифікатор вибере один або усередить і втратить обидва. Аналіз за аспектами зменшує цю проблему, але не усуває її повністю при коротких, багатопоточних реченнях.
Галузевий та регіональний сленг. Модель, натренована на відгуках споживачів, буде слабшою на думках із промислового, медичного або юридичного секторів, де ті самі слова мають інші коннотації. Дотренування на 200-500 прикладах із власної домени зазвичай покращує результати на кілька процентних пунктів recall, але вимагає підготовки позначеного набору.
Польська мова: специфічні виклики. Флексія та безособові речення рідкісні в англійській, але типові в польській. Базова модель, натренована переважно на англійському корпусі, допускає систематичні помилки там, де підмет домислюється з закінчення дієслова. Багатомовні моделі (наприклад, BGE-M3, mT5) справляються краще, але тести на власних даних є обов’язковими перед промисловим впровадженням.
Одинична мітка вводить в оману. Звітність «75% позитивних відгуків» без розбивки за аспектами та намірами — це спрощення, яке може приховувати критичну проблему. Продукт із 75% позитивних відгуків загалом і 40% негативних відгуків щодо доставки має логістичну проблему, а не іміджеву. Сукупна мітка цього не покаже.
Валідація: як перевірити, що модель не бреше#
Перш ніж результати аналізу настроїв потраплять до звіту для керівництва або до операційного тригера, вони мають бути валідовані на вибірці, позначеній людиною.
Стандартний підхід: випадковий вибір 200-400 записів з кожного каналу, ручне позначення 2-3 людьми незалежно, порівняння з класифікацією моделі. Метрики: precision, recall та F1 за виміром (аспект, намір, терміновість), а не лише глобальна accuracy. Для терміновості recall важливіший за precision: пропуск термінової справи коштує дорожче, ніж хибний тривожний сигнал.
Цю валідацію проводимо перед впровадженням і повторюємо кожні 6-8 тижнів або після суттєвої зміни в продуктовому міксі чи каналах. Дрейф розподілу вхідних даних — реальний ризик: модель, калібрована на відгуках рік тому, може не знати нового продукту або нового патерну скарг.
Observability системи — це як мінімум: розподіл класів за тиждень (якщо частка одного класу зростає швидше, ніж підказує бізнес-інтуїція, це сигнал для перевірки), escalation rate до ручної перевірки, і тижневий звіт розбіжностей між класифікацією моделі та рішеннями консультантів. Останній — найцінніший сигнал для рекалібрування.
Детальніше про проєктування петель якості для агентів ШІ пишемо в статті про автоматизацію обслуговування клієнтів. Шаблон валідації golden set для систем RAG та класифікаційних розглядаємо також у класифікації та маршрутизації звернень.
FAQ#
Чи може ШІ аналізувати настрій у польській мові так само добре, як в англійській?#
Не на тому ж рівні при готовій, незміненій англійській моделі. Польські відгуки мають іншу флексію, довші підрядні речення та частішу іронію, ніж англійський тренувальний корпус більшості моделей. Багатомовні моделі (mT5, XLM-RoBERTa) дають значно кращу відправну точку, ніж англійські моделі. Дотренування на 300-500 власних прикладах з польським текстом зазвичай підвищує recall на 10-20 процентних пунктів порівняно з готовою моделлю без адаптації.
Який мінімальний обсяг даних потрібен, щоб аналіз мав сенс?#
Мінімальний поріг залежить від того, чи шукаєте ви сигнали трендів, чи операційні рішення. Для виявлення тижневих трендів достатньо 100-200 записів на тиждень з одного каналу. Для операційної маршрутизації (який запис потрапляє до консультанта) потрібно щонайменше 500-1000 позначених прикладів на клас, щоб модель була достатньо впевненою. Нижче цих порогів результати є орієнтовними, а не операційними.
Що робити з відгуками, що містять персональні дані клієнтів?#
Перед передачею до моделі висновування необхідно замаскувати або видалити персональні дані: ім’я, e-mail, номер замовлення, номер телефону. У системах, що обробляють персональні дані у великих обсягах, потрібна DPIA перед промисловим впровадженням. Якщо відгуки містять медичні або фінансові дані, рівень захисту вищий, і сам хостинг моделі є рекомендованим рішенням. Деталі цього шару описуємо в статті про ШІ для модерації контенту, де маскування PII є стандартним кроком pipeline.
Чи може система аналізу настроїв автоматично відповідати на негативні відгуки?#
Не рекомендуємо цього шаблону. Аналіз настроїв — це сигнал для людини, а не тригер автоматичної комунікації. Автовідповідь на негативний публічний відгук, згенерована моделлю без перевірки консультанта, є ризиком для іміджу, а при формальних скаргах (рекламації, права споживачів) може порушувати інформаційний обов’язок. Правильний шаблон: модель класифікує та направляє до черги, консультант відповідає. При дуже великому обсязі можна розглянути автовідповідь із підтвердженням отримання звернення, але не змістовну відповідь. Детальніше про цю межу в статті про обробку рекламацій.
Як представити результати аналізу настроїв керівництву, щоб вони були корисними?#
Уникайте звіту з однією цифрою (наприклад, «80% позитивних»). Натомість: графік трендів настрою за аспектами в часі, топ-5 ключових фраз за класом намірів у певному тижні, та зведення кількості записів з urgency: висока, переданих консультантам versus вирішених. Цей формат показує, що змінюється і що потребує дій, замість підтвердження стану, який керівництво вже знає з інтуїції. Шаблон побудови таких операційних звітів розглядаємо в контексті ШІ для маркетингових команд.