Обробка даних реальних користувачів для створення рекомендаційної системи. Мій досвід виправлення помилок

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

Привіт! Мене звати Володимир Ковенко і я data scientist й ML engineer в компаніях LOOQME та Vimmi. Маю 3 роки комерційного досвіду в AI/ML. Також пишу наукові статті за сферами своєї роботи.

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

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

Рекомендаційні системи є доволі важливим компонентом відеостримінгових платформ. Як зазначено у статті Нейла Ханта за 2015 рік, системи рекомендацій та персоналізацій зберігають компанії Netflix приблизно $1 мільярд на рік. Щоб така система працювала коректно, великі масиви вхідних даних повинні бути правильно очищені й оброблені.

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

Упередження щодо популярного контенту й петля зворотного зв’язку

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

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

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

Щоб краще зрозуміти ситуацію, розберемо наступну схему. Вона зображує спрощений потік користувацьких даних:

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

Під час першої ітерації роботи над рекомендаційною системою я зіштовхнувся з проблемою. У 2019 році вийшов останній сезон популярного серіалу від HBO «Гра престолів». Дуже велика кількість користувачів почала його дивитися. Алгоритмом, що був використаний для тренування, був GRU4REC.
Вхідними даними до алгоритму були послідовності ідентифікаторів контенту (кожен користувач — одна послідовність), а вихідними — останній фільм, що був переглянутий користувачем. Важливим є те, що послідовності ніяк не оброблялися, крім перетворення з текстових ідентифікаторів у цифри. Оскільки заходів для стабілізації ситуації з точки зору даних не було вжито, під час тесту системи було виявлено, що вона перенавчилася й рекомендувала майже всім лише «Гру престолів».
Випускати таку систему користувачам було б катастрофічною помилкою, адже зображений у серіалі контент має рейтинг 18+, а остання серія серіалу не один раз рекомендувалася після дитячого фільму про «Тома й Джері».

Міскліки користувачів й аналіз неявних вподобань

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

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

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

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

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

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

Незбалансованість даних відносно певних категорій

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

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

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

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

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

Проблема холодного старту

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

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

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

Data drift

Data drift є дуже важливою проблемою у рекомендаційному домені. Як вже було зазначено, data drift є зміною продакшн даних із тих, на яких оригінально відбувалося тренування й тестування моделі. У домені рекомендацій data drift можна віднести до оновлення каталогу (видалення фільмів чи додавання нових), появи нових шаблонів поведінки користувачів й нових метаданих.

Іншою проблемою є сезонність. Наприклад, фільм «Один вдома» зазвичай дивляться взимку, і складно знайти користувачів, які переглядали б його влітку. З мого досвіду, проблема data drift найбільше виражалася саме в оновленні каталогу.

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

Для вирішення зазначених проблем можуть бути використані такі етапи обробки даних:

✅ Фільтрація переглянутого контенту на рівні користувачів, типу контенту й типу девайсу відносно часу перегляду.

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

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

✅ Агрегація даних за користувачами.

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

✅ Фільтрація даних за кількістю переглянутого контенту.

Послідовності, що складалися з замалої чи завеликої кількості фільмів — було відфільтровано. Нижня межа щодо фільтрації залежала від параметрів рекомендаційних метрик, mean average precision at k (map@k), coverage at k (coverage@k), й була не меншою, ніж k у зазначених метриках. Більше про рекомендаційні метрики можна дізнатися за цим посиланням.

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

✅ Нарізання послідовностей переглянутого контенту для збільшення кількості даних.

Послідовності були нарізані наступним чином:
нехай мінімальна довжина результуючих послідовностей — 3, а максимальна — 4;
результуюча послідовність — [1,2,3,4,5,6], тоді отримуємо наступні послідовності:

1. X — [1, 2, 3, 4], y — 4
2. X — [1, 2, 3, 4, 5], y — 6

Мінімальна довжина, знову ж таки, залежала від параметрів метрик. Цей етап обробки допоміг частково вирішити проблему упередження щодо популярного контенту й створити більший датасет для тренування.

✅ Падинг послідовностей з найпопулярнішим фільмом/серіалом.

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

Приклад використання падингу:
послідовність перегляду користувача — [1,2,3], максимальна довжина послідовності — 5;
після паддингу: [0, 0, 1, 2, 3], де 0 — ідентифікатор найпопулярнішої одиниці каталогу.

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

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

✅ Збереження розподілу послідовностей відносно категорій на рівні тренувальних й валідаційних батчів.

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

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

✅ Використання ваг для балансування контенту відносно жанрів.

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

✅ Циклічна обробка даних й тренування моделі.

Хоча тема тренування моделі не є головною у цій статті, важливо зазначити те, як вирішити проблему data drift. Я вирішив цю проблему, використовуючи циклічну обробку даних й тренування моделі. Зазвичай цикл обирався відносно частоти зміни каталогу. Під час цього процесу дані оброблялися, використовуючи вже зазначені етапи, й модель перетреновувалася на них. Це дозволило нівелювати проблему data drift.

Підсумок

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

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