Аспектний аналіз тональності відгуків (ABSA) за допомогою LLM

Аспектний аналіз тональності: що приховує середній бал

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

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

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

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

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

Зворотний зв'язок щодо продукту надходить із затримкою в тижні — на момент звіту привід уже розійшовся по відгуках і оглядах, а виправляти доводиться за охололими слідами.

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

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

Що змінюється після впровадження: ефект у метриках

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

Швидкість обробки потоку відгуків

Раніше потік розбирався вибірково: аналітик встигав пройти частину корпусу, решта чекала в черзі.

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

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

Що перестає губитися під час ручного розмічання

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

• Рідкісні та непрямо сформульовані аспекти фіксуються нарівні з масовими — клас пропусків зникає.
• У кожного аспекту з'являється історія: видно, у який момент оцінка пішла вниз, а не лише підсумкове падіння.

Підходи до розбору відгуків: порівняння режимів роботи

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

Усі три видають аспектну тональність вигляду «доставка швидка, пакування зім'яте», але по-різному тримають сленг, друкарські помилки й відгуки зі змішаною оцінкою.

Коли вистачає правил і словників

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

Де потрібні великі мовні моделі

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

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

На практиці режими комбінують: словники й класифікатор закривають масові однотипні випадки, модель — рідкісні аспекти та вільний текст.

Як ми впроваджуємо: етапи від аудиту даних до передачі

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

Аудит даних і схема аспектів

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

2. Схема аспектів і підтем. Будуємо дерево: аспект верхнього рівня (доставка, якість товару, підтримка) і підтеми всередині. Схему узгоджуємо з вами, щоб кожна гілка відповідала на управлінське питання.

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

4. Перевірка якості розмічання. На сліпій вибірці звіряємо відповіді моделі з розмічанням людей у Label Studio і рахуємо розходження за аспектами та класами тональності. Правила уточнюємо до стійкої згоди — інакше автоматизація ламається на першому релізі.

Викочування та перевірка на живому потоці

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

• Калібрування порогів. На живому потоці підбираємо межу впевненості та відводимо спірні випадки на ручне доопрацювання. Частка автоматично розібраних відгуків зростає, а помилок на рідкісних аспектах стає менше.

• Передача та навчання команди. Віддаємо конфігурації, документацію за схемою аспектів і регламент донавчання, проводимо навчання — правки ви вносите своїми силами.

Що замовник отримує на руки: конфігурації та регламенти

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

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

Документація та схеми

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

Регламенти експлуатації

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

Кейс: як прибрали сліпу зону у відгуках про доставку

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

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

Що було до і що стало після

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

Після модель розмічає кожен відгук за п'ятьма аспектами — кур'єр, пакування, температура, склад замовлення, застосунок — і окремо оцінює тональність кожного. Частка розібраних відгуків зросла з 12% до 96%.

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

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

Спірні розмічання — близько 5% — ідуть на ручну перевірку, тому за аспектом видно не «настрій», а конкретну причину: у частини ресторанів змінили пакування, і частка негативу за цим аспектом повернулася до попереднього рівня за три тижні.

Як рахувати тональність, якщо відгуки кількома мовами?

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

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

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

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

Технічні сумніви: точність, розмічання, донавчання

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

Що робити без історичного розмічання?

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

Як ловиться дрейф якості на нових категоріях?

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

Що з короткими відгуками та друкарськими помилками?

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

Обговоримо задачу: надішлемо оцінку та план робіт

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

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

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

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