Реалізація аналізу тональності тексту (Sentiment Analysis)

Аналіз тональності тексту: де втрачається точність

Зворотний зв'язок надходить із підтримки, відгуків на маркетплейсах, опитувань і листування з менеджерами, і в кожному каналі своя форма оцінювання. Ручна розмітка відгуків не встигає за потоком: поки розмітники розбирають тижневу вибірку, надходить нова.

Частина повідомлень осідає в роботі без мітки, і загальна картина за тональністю збирається з фрагментів.

Точність втрачається ще на вході — коли немає єдиної шкали оцінювання. Один розмітник вважає «нейтрально» лише констатацію факту, інший відносить туди ж стриману скаргу, третій — запитання без емоцій.

Помилки класифікації звернень накопичуються не в моделі, а в мітках: однакові за змістом повідомлення отримують різний знак, і навчання відбувається на суперечливих прикладах.

Далі ефект накопичується: розбір зворотного зв'язку показує зростання негативу там, де його немає, а спірні приклади повторно потрапляють на ручний етап.

Відкриті корпуси на кшталт RuSentiment допомагають лише частково — їхнє розмічання годиться як орієнтир, але не як готова шкала під конкретний продукт, його лексику та сленг клієнтів.

Закривається це дисципліною розмічання й регулярною перевіркою узгодженості, а не зміною моделі. Розбираємо, як це влаштовано і де саме втрачається точність в аналізі тональності тексту.

Що дає налагоджений розбір зворотного зв'язку

Налагоджений розбір зворотного зв'язку змінює не інструмент, а режим роботи з ним: замість вибіркового читання обробляється весь потік.

Частка оброблених звернень піднімається до повного охоплення, а швидкість реакції на сплеск невдоволення вимірюється хвилинами — від появи перших негативних повідомлень до сигналу відповідальному.

Частка ручної обробки падає передбачувано: розмітник підключається лише до спірних випадків — сарказм, змішана оцінка в одному відгуку, галузевий сленг. Решта розбирається автоматично, і черга на ручний розбір скорочується в рази, а не на відсотки.

Моніторинг невдоволення клієнтів будується на порозі частки негативу за каналом і на швидкості зростання цієї частки. Якщо за коротке вікно негатив перевищує звичайний фон, оповіщення надходить власнику напряму — до того, як тема розійшлася публічними майданчиками.

Зведена оцінка за каналами дає порівнянну шкалу: відгуки, листування в підтримці та коментарі приводяться до одного вигляду. Тоді видно, де проблема локальна, а де системна. Зникає й окремий клас пропущених скарг — тих, що не потрапили у вибірку й залишилися без відповіді.

Усі ці показники фіксуються до старту робіт: частка автоматичної обробки, час до сигналу, частка спірних випадків на ручному розборі. За ними ж приймається результат — без суб'єктивного «стало зручніше».

Порівняння підходів до розбору відгуків

Розбір відгуків починається з вибору методу, і універсального переможця тут немає: точність залежить від обсягу тексту, домену та ціни помилки.

Словниковий підхід дає результат першого ж дня, але ламається на іронії, сленгу та конструкціях на кшталт «непогано, але більше не прийду». Навчання на розмічених даних знімає частину цих проблем — і переносить витрати на розмітку корпусу.

Донавчання мовної моделі краще тримає контекст, скорочення та друкарські помилки, але потребує прикладів саме вашого домену й передбачуваної інфраструктури для регулярного перенавчання.

Гібридна схема класифікації закриває крайні випадки: правила відпрацьовують критичні теми та службові формулювання, модель — решту потоку.

Ми обираємо варіант за вашими даними: дивимося, чи є розмічений корпус, як швидко змінюється лексика і що відбувається при помилці — клієнт іде або з'являється зайве звернення в підтримку.

Якщо система розбору вже працює, частіше виграє гібридна схема: правила додаються до поточної моделі, і перезбирати все з нуля не потрібно.

Етапи впровадження розбору зворотного зв'язку

Починаємо не з вибору моделі, а з аудиту того, що вже є: вивантажень звернень, відгуків, історії ручної розмітки. Тут же видно, чи достатньо даних для потрібної кількості класів і де розмітники розходилися між собою.

1. Аудит розмітки. Дивимося обсяг і розподіл даних, частку дублів, узгодженість оцінок між розмітниками. За розходженнями зрозуміло, які формулювання інструкції потрібно переписати до навчання.
2. Схема класів тональності. Фіксуємо набір класів: зазвичай позитив, негатив, нейтраль плюс предметні категорії на кшталт скарги на доставку. Занадто дробову схему не беремо — на рідкісних класах падає точність.
3. Налаштування обробки. Зводимо підготовку тексту, навчання та застосування моделі в один відтворюваний сценарій: очищення, нормалізація, сленг, друкарські помилки, короткі репліки, змішані мови.
4. Перевірка на відкладених прикладах. Метрики рахуємо за кожним класом окремо, а не лише в середньому. Прогоняємо тексти з періоду, який модель не бачила, і розбираємо матрицю помилок: де плутаються сусідні класи.
5. Розбір помилок і донавчання. Часті промахи повертаємо в розмітку й повторюємо цикл, доки приріст на відкладеній вибірці не стане незначущим. Відстежуємо дрейф: зростання частки нейтральних відповідей або нова лексика слугують сигналом до донавчання.
6. Передача рішення команді. Віддаємо інструкцію з розмітки, схему класів, код навчання та застосування, панель з метриками якості й регламент перенавчання. Навчаємо співробітників і залишаємося на зв'язку в період самостійної роботи системи.

Комплект документації та правила розмітки

Модель без документації — чорна скринька: при відході підрядника замовник не може ні розмітити новий корпус, ні пояснити, чому конкретний відгук віднесено до негативу. Тому правила розмітки, схема класів і регламенти передаються як частина рішення, а не додатком до нього.

Нижче — комплект, який залишається всередині вашої команди та дає змогу розвивати аналіз тональності власними силами.

• Правила розмітки — інструкція з межовими випадками (сарказм, подвійне заперечення, змішана тональність), пріоритет міток у разі конфлікту та вимоги до згоди між анотаторами.
• Схема класів — ієрархія міток, пороги впевненості та зв'язка «клас → дія»: де відповідаємо автоматично, де підключаємо оператора, що вважаємо шумом.
• Налаштовані маршрути обробки — які потоки йдуть у реальному часі, які збираються в пакети, куди надходять відповіді з низькою впевненістю і як вони потрапляють у донавчання.
• Регламент контролю якості — частка документів на ручну перевірку, порядок розбору розходжень між перевіряльниками, метрики за кожним класом, строки перегляду розмітки.
• Порядок оновлення моделі — тригери перенавчання (зміна лексики, падіння точності на свіжих даних), склад навчального набору, хто затверджує розгортання.
• Карта інтеграції — формати запиту та відповіді, поведінка при недоступності сервісу, відкат на попередню версію.
• Журнал рішень — які гіпотези перевірялися, чому обрано поточний поріг впевненості й що відхилено.

Документи пишуться під вашу предметну область і ваш потік даних, а не переписуються з загальної інструкції — тому новий розмітник виходить на узгоджену розмітку за лічені дні.

Кейс: як зросла точність на потоці звернень

Початкова точка: потік звернень з кількох каналів розбирався вручну, а автоматика працювала на словниках і правилах.

Правила впевнено ловили явні скарги, але ламалися на запереченнях, іронії та коротких репліках — частка правильно розібраних звернень трималася близько 61%, і черга на розбір зростала швидше, ніж команда встигала її закривати.

Перезібрали процес: розмітили вибірку за каналами й типами звернень, вирівняли спірні приклади між анотаторами, навчили модель на попередньо навчених мовних моделях із Hugging Face і окремо відкалібрували пороги впевненості.

Клас «нейтрально» перестав перетягувати межові випадки, а відповіді з низькою впевненістю надходять на ручну перевірку, а не в загальний звіт.

Що показали метрики до та після

• Частка правильно розібраних звернень: 61% → 92%, на іронії та запереченнях — з 48% до 86%.
• Час реакції на інцидент: з 40 хвилин до 6 — сплеск негативу видно в перші хвилини, а не наступного тижня.
• Ручних перевірок: з ~1800 до 260 на тиждень, час, що вивільнився, пішов на розбір причин, а не наслідків.

По ходу виявилися вузькі місця, яких на словниках просто не було видно. Трансліт і змішування мов усередині одного звернення, складені повідомлення з двома темами одразу, дрейф формулювань після змін у продукті.

Під них додали нормалізацію тексту, розбиття складених звернень на окремі записи й моніторинг дрейфу з перенавчанням за розкладом.

Кожне оновлення моделі проходить тіньовий прогін на історичних даних і може бути відкочено на попередню версію — точність не просідає непомітно. Розбір тональності перестав бути рутиною, яку треба встигати закривати, і став джерелом даних про причини звернень.

Чим відрізняється тональність від тематики звернення?

Тональність і тематика — два незалежні шари розбору одного звернення, і їх постійно плутають. Оцінка ставлення клієнта відповідає на питання «як він це говорить»: позитив, негатив, нейтраль, а для скарг — наскільки різко.

Класифікація за темами відповідає на «про що він пише»: оплата, доставка, якість товару, робота підтримки.

Дані для налаштування в цих завдань різні. Для оцінки ставлення потрібна розмітка емоційного забарвлення з оглядкою на заперечення, іронію, сленг і змішані формулювання — «дякую, що змусили чекати третій раз» формально подяка, по суті різкий негатив.

Для класифікації за темами потрібен рубрикатор: ієрархія від великих груп до підтем, правила для звернень одразу про кілька речей і окремий клас «тему не визначено», інакше модель натягне будь-який текст на найближчу рубрику.

Різняться й способи перевірки. Тональність оцінюють на рідкісному класі: негативу в потоці зазвичай менша частка, тому дивимося точність саме на ньому, а не загальну частку правильних відповідей.

Тематику перевіряють покриттям рубрикатора — скільки звернень упевнено віднесено і як часто модель плутає сусідні теми, наприклад «повернення» й «гарантія».

Практична ціна плутанини — модель, навчена на темах, починає видавати «негатив» на будь-яку згадку проблеми. У підсумку повідомлення про факт без емоцій потрапляє в червону зону, а ввічлива скарга з загрозою піти — ні.

У робочому розборі тема визначає маршрут звернення, а тональність — пріоритет і ознаку ризику відтоку.

Ми налаштовуємо ці завдання роздільно, на своїх вибірках і своїх метриках, а пов'язуємо вже на виході. Тоді збій в одній частині не тягне за собою другу, і кожну можна донавчити без перезбирання всього розбору.

Спірні випадки та обмеження методу

Аналіз тональності впевнено працює там, де оцінка лежить на поверхні тексту, і помітно просідає на живих відгуках. Іронія, сленг, уривки фраз і друкарські помилки зсувають передбачення: репліка «ну дякую, зробили послугу» формально позитивна, а за змістом — претензія.

Нижче — спірні випадки, які найчастіше спливають на прийманні, і те, чим вони закриваються на рівні розмітки, словників і правил постобробки.

Що робити зі змішаними та короткими репліками?

Змішаний відгук розбиваємо на сегменти й оцінюємо поетапно: «доставка швидка, але упаковка роздавлена» дає два класи й нейтральний підсумок із прив'язкою до аспекту — доставки чи якості.

Короткі репліки на кшталт «ок» і «норм» не тягнемо в загальний висновок, а позначаємо як слабоінформативні, інакше вони розмивають розподіл оцінок.

Наскільки система стійка до друкарських помилок і зміни формулювань?

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

Обговоримо задачу й повернемося з оцінкою та планом

Щоб оцінка обсягу робіт спиралася на ваші дані, а не на середні цифри по ринку, нам достатньо пів години розмови й пари прикладів вивантажень. Ми розбираємо задачу по частинах: де текст з'являється, у якому вигляді він доходить до моделі та що вважається правильною відповіддю.

• Джерела та мови: звідки надходять тексти, чи є змішані мови, сленг, трансліт, друкарські помилки.
• Вимоги до даних: обсяг доступної історії, наявність еталонної розмітки та того, хто її підтверджував.
• Класи та їхній баланс: які оцінки потрібні, що робити з нейтральними та двозначними формулюваннями.
• Профіль навантаження: середній і піковий потік, допустима затримка відповіді, чи потрібна обробка пакетами.
• Точки вбудовування: інтерфейс, черга повідомлень, звітність, уже працюючі внутрішні системи.
• Обмеження щодо даних: де їх можна зберігати, що обезличувати, скільки тримати для донавчання.
• Критерії приймання: частка правильних відповідей на відкладеній вибірці та поведінка моделі на рідкісних класах.

У відповідь ви отримуєте план впровадження, а не загальну пропозицію: етапи з результатом кожного, склад робіт і зони відповідальності, схему руху даних і список того, що потрібно від вашої сторони. Якщо розмітки немає — окремим пунктом фіксуємо її підготовку та спосіб контролю якості.

Опишіть задачу в двох-трьох абзацах: домен, приклади текстів, бажана оцінка. Повернемося з планом і уточнювальними питаннями.