Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Дані для ML-моделей в NLP, recommendation і CV — пошук, підготовка і трансформація

Усі статті, обговорення, новини про AI — в одному місці. Підписуйтеся на DOU | AI!

Привіт! Я Віталій Шевчук — data scientist в українській компанії LOOQME. Останні 7 років я працюю з big data, з них 5 — саме в AI та ML.

Мені подобається витягувати з даних «extra value for the client» та будувати високоякісні автоматизовані системи на основі штучного інтелекту — з нуля до готового рішення, що інтегроване з системою. Я адепт інтерактивного навчання як в житті, так і в роботі.

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

  1. TSA (target sentiment analysis) NLP — комерція
  2. Personalized recommendations — комерція
  3. CV (Emotion expression detection on low-resource machines) — Pet-проєкт

Трішки загальної теорії

Почнемо з того, що декілька відсотків точності в новій моделі не завжди призводять до покращення KPI. KPI (key performance indicators) — це якісні показники, основна ціль яких — показати бізнесу прогрес компанії (наприклад, підвищення прибутків, зростання кількості користувачів і т.д.). Якщо це невелике покращення моделі й спричиняє покращення цільового показника, то нелінійно і, можливо, із затримкою (залежно від бізнес-моделі).

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

DeepLearning.AI — slide, source paper — [D. Sculley et. al. NIPS 2015: Hidden Technical Debt in Machine Learning Systems

У цій статті ми будемо розглядати Data collection (збір даних), Feature engineering (створення факторів) й частину Data verification (перевірка даних).
З власного досвіду можу сказати, що основна помилка багатьох спеціалістів по роботі з даними — це виділяти найбільше часу на тренування моделі й підбір гіперпараметрів, у результаті чого замало часу відводиться підготовці даних.

У часи зародження штучного інтелекту був дефіцит даних. Це призвело до створення спеціальних механізмів у алгоритмах, що дозволили б надати хороший результат з обмеженою кількістю даних. Тобто раніше для покращення якості результуючої системи основний акцент було поставлено на моделювання. Ця парадигма має назву Model Centric AI. У наш час даних стало набагато більше, чому сприяло створення й розвиток нових соціальних мереж та перетворення даних в електронний варіант.

З іншого боку, процес покращення моделювання досягає плато, при якому покращення відбувається при збільшенні кількості тренувальних даних чи збільшенні потужностей обладнання (GPU, CPU, TPU). Все більше фахівців починають переходити до Data Centric AI — парадигми, де центральну роль відіграють дані. Цю теорію також підтверджує висловлювання Едрю Ина, засновника Coursera й Deep learning AI:

Джерело: read.deeplearning.ai

Розробляючи системи, пов’язані зі штучним інтелектом, ми використовували саме цю парадигму. З нашого досвіду, саме підготовці даних, збору нових й покращенню якості існуючих потрібно приділяти найбільшу увагу, адже data science системи працюють за GIGO (garbage in → garbage out) принципом.

Ще одним важливим концептом є data drift. Data drift — це явище, коли тренувальні й тестові дані не відповідають даним, з якими модель стикається в продакшені. Важливо відслідковувати data drift й знати, як його уникати, адже його наслідком є погана продуктивність моделі. Про реальні кейси data drift й засобів його уникнення з досвіду можна прочитати далі.
Перейдемо до практики.

TSA (target sentiment analysis)

SA VS TSA VS ABSA

Наша компанія працює з моніторингом медіа й однією з ключових систем є оцінка тональності (opinion mining). Певно, що більшість чули про оцінку тональності (Sentiment analysis), проте тут є різні види задачі:

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

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

Зробимо «ліричний відступ» і згадаємо, звідки можна дістати дані:

  1. Відкриті датасети (для української мови я таких не знайшов (саме для TSA), проте є невелика кількість датасетів для англійської). Гарний варіант для початку, проте варто звернути увагу на розподіл даних в порівнянні з очікуваним розподілом в продакшені та на ліцензію використання даних.
  2. Наприклад, якщо відкритий датасет має всі приклади з соціальних мереж, а в компанії ви плануєте розмічати пресу або радіо, — це не найкращий підхід.
  3. Власне дані компанії з розміткою. Найкращий випадок з наявних.
  4. Підхід з перекладом.
3.1. Можна за допомогою моделі для перекладу перекласти з англійської на українську і застосувати в тренуванні (якість гірша, проте як baseline — непогано).
3.2. Є готові рішення для багатьох мов (на момент написання статті — без підтримки української та російської), а саме: AWS, IBM, Google NLP API (по 5000 безкоштовних оцінок в місяць).
Тобто ідея наступна: маємо англійські тексти, розмічуємо їх за допомогою Cloud API → перекладаємо, маємо непоганий датасет + він оновлюється по 15 000 оцінок на місяць.
3.3. Так само, як і в 3.2, тільки знайти якусь іншу модель.

Тут якість перекладу відіграє ключову роль. Наприклад, BLEU score < 20 буде неприпустимою, а від 20+ можна вже подумати над застосуванням (BLEU score interpretation).

Через особливості збереження даних у нас такого датасету не було. Точніше він був, але не в тому форматі та з рядом помилок, який потрібен для тренування. Наприклад, в системі дані могли зберігатися так:

Хороший приклад:
«Компанія Х — гарно працює, *похвала компанії*».
Ціль: Компанія Х, тональність: позитив.

Ідеальний приклад:
«Компанія Х — гарно працює, а от Компанія Y — точно гірше».
Ціль: Компанія Х, тональність: позитив.
Ціль: Компанія Y, тональність: негатив.

Поганий приклад:
«Компанія Х — лідер продажів, *узагальнений текст*. Компанія Х також має вплив на ринок і *узагальнений текст*. Але не всі відгуки про Компанію Х позитивні, *узагальнений текст*. До того ж підписуйтеся на телеграм-канал Компанії Х».
Ціль: Компанія Х, тональність: позитив.

Оскільки неможливо однозначно сказати, яке із чотирьох входжень тексту про Компанію Х позитивне, ці дані для тренування використовувати не можна.

Після аналізу розмічених даних за останніх два роки виявилося, що критеріям «хороших» даних відповідає всього 10% від усіх текстів. Наступний крок — це балансування даних, а саме цих 10%. Розподіл по тональності виглядає приблизно так: позитив — 10%, негатив — 5%, нейтрал — 85%.

Ще було би непогано зробити балансування по типу текстів (інтернет, соціальні мережі, преса, блоги, радіо, телебачення), але про це поговоримо пізніше. У результаті нам вдалося зібрати початковий датасет у розмірі по 30 000 прикладів на клас.

Трансформація «сирого» тексту

Будемо вважати, що для першої ітерації цього достатньо та перейдемо до процесу підготовки даних перед тим, як тренувати модель. Трансформації, які ми використовували, наведено на цьому рисунку:

Звісно, сюди можна додати ще визначення частини мови (POS tagging), лематизацію, чистку стоп-слів, обробку емоджі, чистку цифр. Тут варто бути обережними: існує безліч компаній, які мають числа в назві. Наприклад, компанія «95», «777» і подібні.

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

Ембедінги та тренування

Тренуємо моделі? Ні, ми пропустили ще один важливий пункт: ембедінги, або точніше — репрезентація тексту. На вибір є 2 варіанти: transfer learning чи тренувати ембедінги самостійно. Хоча й на вибір є доволі багато різних готових моделей (той самий BERT), але практика показала, що тренувати власні ембедінги набагато краще. Ціна питання — 2-3% точності (певно причина в різних розподілах).

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

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

Нижче наведено результати тренувань перших моделей (зараз усе виглядає значно краще):

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

Після ембедінгів і тренувань загортаємо результати в API і оголошуємо, що все готово. Готово, щоб констатувати факт, що ми зробили близько 20% необхідної роботи. А найцікавіше тільки починається :)

Зазвичай тут варто поставити бізнесу наступні питання:

  • Ця модель вирішила дану задачу?
  • Наскільки добре ця модель вирішила поставлену задачу?

Мається на увазі не точність, а саме відгуки клієнтів (які можуть бути доволі специфічними). Якщо відповідь «так», то можна було б і закінчити розповідь, але...

Вирішуємо проблему з data drift та corner cases

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

  • Мова з часом змінюється і модель стає застарілою, тобто можна спостерігати data drift.
  • Інколи виникають ситуації, при яких модель за наявних даних поводить себе некоректно.

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

Якщо це значення високе — очікувати на якісні результати не дуже обнадійливо.

Ще один з показників — «нормальний» розподіл за класами. Якщо мережа раптом почала називати все «негативом» — щось точно пішло не так.

На даному зображенні все гаразд:

Бачимо більше нейтральних документів, що логічно (відповідає розподілу в оригінальному тренувальному файлі).

Тепер, коли ми зафіксували модель, варто подумати, як ще ми можемо залучити дані. Аби вирішити описані вище проблеми ми застосували наступні методи:

  1. Direct labeling — це, грубо кажучи, правка помилок моделі, один з найцінніших видів циклу зворотного зв’язку для моделі, бо ми дотреновуємо модель на її ж виправлених помилках (нову розмітку робить або клієнт, або спеціальні люди).
  2. Manual labeling (with cross labeling) — найдорожчий і найдовший вид отримання нових якісних даних, але необхідний для розуміння критичних проблем: human level of performance (у перших ітераціях три людини сходилися в 66% випадків, тому очікувати від моделі правильних рішень у 95% всіх випадків, м’яко кажучи, нераціонально) + формування golden standard датасету (для валідації кожної наступної версії моделі — тестова вибірка). Також із цього високоякісного датасету частину найскладніших даних можна і варто застосовувати у validation.
  3. Active learning — активне навчання. Чудово працює з пунктом 2. Ідея полягає в тому, що активне навчання використовують замість генерації просто великої кількості тренувальних даних. Адже це насправді призводить тільки до вирішення проблеми зі старим словником, але не дає моделі сильного приросту варіативності в рідкісних прикладах. Тому ми обробили новий датасет (а також уже розмічений) й аналізували ймовірності відношення до певних класів. Наприклад, якщо модель на 90% впевнена, що це позитив — найімовірніше так і є. Проте якщо ми знаємо, що це позитив, а модель впевнена у цьому на 30% — постає питання, чому так сталось. Тоді звужуємо пошуки до прикладів текстів з низькими ймовірностями і даємо їх на розмітку.

Існує ще безліч додаткових методів, таких як генерація текстів, semi-supervised learning та інші. Щодо доцільності застосування потрібно відштовхуватися від особливостей проєкту. З мого досвіду описані вищі пункти призводять до поступового покращення моделі та запобігають деградації вагів і data drift.

Працюємо з даними далі: що під капотом у цієї Tesla

У поєднанні з попередніми методами ми також робили глибокий аналіз помилок за допомогою EAI (Explainable AI) та case study. Основна задача error analysis — сформувати кластери помилок і взяти в розробку той або ті, які займають найбільше відсотків.

Оскільки ми використовували нестандартну архітектуру для TSA (є різниця зі звичайною класифікацією текстів), то з незначними змінами під бібліотеку LIME ми зробили аналіз помилок. Це має такий вигляд:

Коли фокус на ключове слово «компанія а»:

Коли фокус на ключове слово «компанію б»:

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

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

Бонусні кейси про роботу над помилками — data slices validation

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

  • за типом джерел даних

  • за довжиною текстів

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

Підсумок

За декілька ітерацій моделей і даних ми суттєво покращили якість рішення і покриття різноманітних випадків вхідних даних, вирішили проблему з data drift. Усе завдяки методам, що описані вище. Загалом приблизно 25 % часу пішло саме на роботу з моделями та 75 % — з даними. Як бачимо, робота з даними в цьому випадку дає краще розуміння, куди варто рухатися і як покращувати результати.

P.S. Під час роботи ми знайшли набагато більше інсайтів, ніж вмістили в статтю, але наведені вище методи вважаємо надзвичайно ефективними :)

👍ПодобаєтьсяСподобалось27
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дійсно, ґрунтовна стаття, дякую. Може кому стануть у нагоді:
— github.com/...​ainian-Sentiment-Analysis
— github.com/...​ienko/Ukrainian-Stopwords

Дякую, справді крута стаття!.
Вітайлій, скажіть, які PET проекти могли б порадити новачку у data science? Мрію побудувати кар’єру у МL. На вашу думка, звідки краще брати датасет, та якого типу проекти вказати у резюме.

1. Виберіть собі напрям, NLP, CV, time series, analytics
2. Датасети найкращи скрепети самому з сайтів

Тобто вручну скрепити данні з сайтів?
Розмислював з приводу результатів на Кагл, що їх можна вказувати у резюме. Але знаю що деякі компанії не розглядають їх як повноцінні проекти і досвід...

Результати на кагл варто вказувати якщо вони в топі.

гм..
окей, дуже дякую за пораду!

Наприклад:
1. NLP порівняльний аналіз Корану та Біблії, яка релігійна книга більш «Миролюбива», чи наприклад скільки дійових осіб там і там. зробити повноцінний EDA + просто знайти багато інсайтів.
2. NLP Парси всі вакансії в LinkedIN чи Glassdoor + зроби дашборд який показує цінність певних скілів в часі і що стає популярним.

візьми пару курсів по Coursera ML — там приклади на різних проектах, можливо щось сподобається і спробуєш зробити схоже але сам.

зроби все сам з 0 до готового рішення і опиши це в резюме.

Підписатись на коментарі