Оцінка систем рекомендацій: вибір найкращого для вашого бізнесу

Разом з нескінченним розширенням електронної комерції та Інтернет-ЗМІ в останні роки з'являється все більше і більше Рекомендаційних систем (РС) SaaS. На відміну від 5 років тому, коли використання РС було привілеєм великих компаній, які будували власну власну службу в РС, витрачаючи величезний бюджет на команду науковців даних, сьогоднішня популярність рішень SaaS робить доступним використання рекомендацій навіть для малого та середнього бізнесу -розмірні компанії. Питання, з яким стикаються ОГС таких компаній при пошуку потрібного SaaS RS, таке: яке рішення є найкращим? Якщо припустити, що ви все ще не маєте РС, або вас не влаштовує нинішня RS, яке рішення вам вибрати?

У цій статті я розповім про два підходи:

  • Офлайн-оцінка в академічному світі (плюс премія Netflix), пошук помилок з низьким прогнозуванням (RMSE / MAE) та високим покриттям відкликання / каталогу. TLDR; просто знайте, що ці заходи існують, і ви, мабуть, не хочете їх використовувати. Але я все ж даю короткий підсумок їх у випадку, якщо вас цікавить.
  • Оцінювання в Інтернеті в діловому світі, пошук високих цінностей для життя клієнтів (CLV), проходження A / B-тестування, CTR, CR, ROI та QA. Ви повинні прочитати цей розділ, якщо ви серйозно розглядаєте рекомендації щодо розширення вашого бізнесу.

Офлайн світ = Як це роблять вчені?

РС досліджуються десятиліттями в академічних дослідженнях. Існує багато науково-дослідних робіт, що представляють різні алгоритми, і щоб зробити алгоритми порівнянними, вони використовують академічні заходи. Ми називаємо ці заходи офлайн-заходами. Ви нічого не вкладаєте у виробництво, ви просто граєте з алгоритмами у вашій пісочниці та точно налаштовуєте їх відповідно до цих заходів. Я особисто багато досліджував ці заходи, але з моєї сьогоднішньої точки зору вони є доволі доісторичними. Але навіть у середні віки 2006 р. У знаменитій премії Netflix застосовувався суто академічний захід під назвою RMSE (середньоквадратична помилка).

Щоб коротко пояснити, як це працює, він передбачає, що ваші користувачі чітко оцінюють вашу продукцію за кількістю зірок (1 = сильна неприязнь, 5 = сильна, як), і у вас є купа таких рейтингів (записи, що говорять про те, що користувач оцінив предмет X з зірками Y) з минулого. Використовується методика, яка називається роздільною валідацією: ви берете лише підмножину цих оцінок, скажімо 80% (називається набір поїздів), будуєте на них РС, а потім просите РС передбачити рейтинги на 20%, які ви приховано (тестовий набір). І тому може статися, що тестовий користувач оцінив якийсь предмет із 4-ма зірками, але ваша модель прогнозує 3,5, отже, в ньому є помилка 0,5, і саме звідси походить RMSE. Тоді ви просто обчислюєте середнє значення помилок з усього тестового набору за допомогою формули і отримуєте кінцевий результат 0,71623. БІНГО! Ось наскільки хороший (а точніше поганий) ваш RS. Або ви також можете використовувати іншу формулу і отримати MAE (середня абсолютна помилка), яка не карає величезних помилок (справжні 4 зірки, передбачувана 1 зірка) настільки багато, тож ви можете отримати лише 0,6134.

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

Користувачі ліниві, і вони нічого не оцінюють. Вони просто відкривають веб-сторінку, і якщо їм подобається те, що вони бачать, вони можуть придбати / споживати її; якщо це смокче, вони виїжджають так само швидко, як прийшли. Отже, у вашому журналі веб-сервера чи базі даних про покупки у вас є лише так звані неявні рейтинги, і ви не можете виміряти похибку кількості зірок на них просто тому, що немає зірок. У вас лише +1 = користувач переглянув деталі або придбав товар, і, як правило, нічого іншого. Іноді їх називають одинарними рейтингами, які ви знаєте за допомогою кнопки "Like" у Facebook: рейтинг - або позитивний, або невідомий (користувач просто не знає, що існує вміст).

Ви все ще можете використовувати роздільну валідацію таких даних, навіть для власного порівняння в режимі офлайн SaaS. Скажімо, ви приймаєте, наприклад, свою базу даних покупок, подаєте історію 80% користувачів в РС, а потім для кожного тестового користувача подаєте лише кілька покупок і просите РС передбачити решту. Можливо, ви заховали 4 придбані речі та попросили РС про 10 предметів. Ви можете отримати 0%, 25%, 50%, 75% або 100% точності для цього користувача, залежно від того, скільки прихованих 4 з'явилося у рекомендованому 10. І ця точність називається Відкликання. Ви можете оцінювати його протягом усього тестового набору та TADAAA! У вас результат 31,4159%, це добре, наскільки ваш RS.

Якщо чесно, то, хоча Recall набагато розумніший за RMSE, він все ще приносить багато болю. Скажіть, користувач-тест переглянув 20 серій із цього ж телесеріалу, і ви вимірюєте відкликання на ній. Тож ви ховаєте епізоди №18–20 і просите РС передбачити їх від №1–17. Це досить легке завдання, оскільки епізоди сильно пов'язані, тому ви отримуєте відкликання на 100%. Тепер ваш користувач виявив щось нове? Ви хочете взагалі рекомендувати їй такий зміст? І що вам найбільше приносить найвищу цінність для бізнесу? Скажіть в інтернет-магазині, чи бажаєте порекомендувати альтернативи чи аксесуари? Ви повинні відчувати, що потрапляєте на дуже тонкий лід із відкликанням.

І ще один секрет, який я вам скажу: у деяких випадках (не завжди, це залежить від вашого бізнесу!), Це справедлива стратегія рекомендувати лише найбільш популярні товари в світі (a.k.a. бестселери), щоб досягти розумного відкликання. Отож, тут виходить покриття Каталогу. Чи бажаєте ви, щоб користувачі постійно відкривали для себе новий і новий вміст, щоб залишатися лояльними? Тоді ви можете порекомендувати якомога більше різних предметів. У найпростішому випадку, щоб обчислити покриття Каталогу, просто візьміть своїх тестових користувачів, попросіть рекомендації для кожного з них і складіть всі рекомендовані елементи разом. Ви отримуєте великий набір різних предметів. Розділіть розмір цього набору на загальну кількість предметів у вашому каталозі, і ви отримаєте… 42,125%! Ось та частина предметів, яку ваш RS може будь-коли порекомендувати.

Тепер розглянемо модель бестселера. Він може мати досить гарне нагадування, але майже нульове покриття (5 констант?). І візьміть довільну рекомендацію. Він має майже нульовий відкликання та 100% покриття. Ви можете відчути, що вам подобається якийсь компроміс.

Наведене вище зображення походить від мого (зараз дуже застарілого) оригінального дослідження. Ви можете побачити близько 1000 різних моделей RS, намальованих у площині Recall-Coverage. Гекі, чи не так? :) Ви можете запаморочитись, вибираючи найкращий, але, сподіваюся, ви відчуваєте, що вибір обрати верхній правий край ("Парето-оптимальний фронт") може бути хорошим вибором.

Щоб зробити вашу офлайн-оцінку ще більш надійною, ви можете використовувати перехресну перевірку (Xval) замість роздільної валідації. Просто розділіть своїх користувачів на 10 разів і перейдіть в цикл: завжди візьміть 9 складок, щоб скласти модель, а решту 1 разів скористайтеся для перевірки. Середні результати за ці 10 циклів.

Тепер ви можете сказати: А як щодо мого бізнесу? Вимірювання відкликання та покриття може бути добре, але як вони пов’язані з моїми KPI?

І ти маєш рацію. Щоб поставити SaaS RS на вісь X і $$$ на вісь Y, ми повинні покинути офлайн-світ і піти у виробництво!

Інтернет-світ: наслідуйте приклади розумних CTO

У вищенаведеному розділі йшлося про вимірювання якості РС до того, як він вийде на виробництво, тепер саме час поговорити про бізнес-показники KPI.

Хоча в офлайн-оцінці ми зазвичай використовуємо роздільну валідацію, в онлайн-оцінці A / B-тестування (або багатоваріантне тестування) є найбільш відомим сьогодні підходом. Ви можете інтегрувати декілька різних РС, розділити користувачів на групи і ввести в боротьбу РС. Трохи затратна, оскільки вона споживає ваші ресурси розвитку, тому ви можете використовувати передбачувані труднощі інтеграції та майбутні витрати на коригування / коригування як один із ваших заходів, що може апріорі скоротити набір кандидатів.

Тепер скажемо, що ви готові до інтеграції та можете розділити своїх користувачів онлайн на групи A / B-тестування. Ви можете або використовувати власний хеш-файл їхніх файлів cookie UID, або використовувати якийсь інструмент для цього (наприклад, VWO, Optimizely або навіть GA, хоча останній варіант трохи болісний). Щоб зробити експеримент, вам слід визначити одне добре місце на своєму веб-сайті / програмі, де перевірити рекомендації, оскільки ви впевнені, що не хочете здійснювати повну інтеграцію всіх кандидатів на початку пілотного етапу, правда? Якщо у вас мало трафіку, пам’ятайте, що вибране місце повинно бути достатньо видимим для отримання значних результатів. У протилежному випадку, якщо у вас величезний трафік, ви можете обрати консервативну стратегію, наприклад, звільнити лише 20% вашого трафіку для тестування, зберігаючи себе та решту 80% користувачів у безпеці у випадку, якщо хтось із кандидатів з РС бути повністю зламаним і рекомендувати дивні речі.

Припустимо, вся справа працює. Що міряти? Найпростішими заходами є рейтинг рекомендацій (CTR) і коефіцієнт конверсії (CR).

Відображено набір N рекомендацій 20 разів, з яких 3 рази користувач натискав хоча б на один із рекомендованих елементів? Тоді ваш CTR становить 15%. Дійсно, клацання приємне, але воно, ймовірно, призвело користувача до сторінки деталей, і ви, можливо, захочете дізнатися, що сталося далі. Чи користувач дійсно вважав вміст цікавим? Чи переглянула вона ціле відео, прослухала всю пісню, прочитала всю статтю, відповіла на пропозицію роботи, поставила товар у кошик і фактично замовила його? Це коефіцієнт конверсії = кількість рекомендацій, які радували і вас, і вашого користувача.

Приклад: консоль KPI рекомбі

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

Тут наводиться емпірична оцінка РС. Просто почніть новий сеанс із порожніх файлів cookie, моделюйте поведінку користувача та перевірте, чи є рекомендації здоровими. Якщо у вас є команда з забезпечення якості, прийміть їх на роботу! Емпіричне оцінювання одночасно є складним та простим. Це складно, оскільки він не дає жодних цифр, які ви могли б представити на дошці продуктів. Але це також просто, тому що, завдяки своїй людській інтуїції, ви просто визнаєте, які рекомендації є хорошими, а які - поганими. Якщо ви виберете дивно працюючий рекомендатор, ви створюєте багато проблем у майбутньому, навіть якщо CTR / CR зараз високий.

Але звичайно, окрім якості, вам слід подбати про повернення інвестицій (ROI).

Простіше кажучи, ви могли визначити, що складка № 1 тестування A / B призводить до збільшення швидкості конверсії на X% у порівнянні з краткою № 0 (ваше поточне рішення), що ваша маржа становила $ Y для середнього успішно рекомендованого товару, і що для цього потрібні запити рекомендацій Z. Зробіть математику, спроектуйте витрати / доходи на випадок, якщо ви поставите дану RS на 100% вашого трафіку, інтегруючи також в інші розділи вашого веб-сайту / програми.

Одне попередження щодо розрахунку рентабельності інвестицій: Це дуже нечітко і залежить від великої кількості невідомих: Чи буде КР однаковим в інших місцях мого веб-сайту / програми? (Проста відповідь = ні, не буде, різні місця мають різний CTR / CR). Як зміниться CR, якщо поставити рекомендації на більш-менш привабливе становище? (Проста відповідь = багато). Як ЧР буде розвиватися в часі? Чи зможуть користувачі навчитися використовувати та довіряти рекомендаціям, чи знизиться CR?

Це призводить до остаточної, але найскладнішої міри: ціна життя клієнта (CLV). Ви шукаєте безпрограшну ситуацію. Ви хочете, щоб ваші користувачі подобалися вашим послугам, відчували себе комфортно, щасливо та готові повернутися. Одночасно з цим, ви хочете, щоб RS покращив UX, допомагав користувачам знаходити цікавий вміст / продукти, що їм подобається. Як досягти високого CLV за допомогою RS?

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

Висновок

Я намагався висвітлити найважливіші аспекти оцінювання рівнів. Можливо, ви бачили, що це непросте завдання, і є багато чого розглянути, але я сподіваюся, принаймні, дав вам декілька підказок, щоб знайти свій шлях у цьому районі. Ви можете протестувати RS в автономному режимі навіть перед початком виробництва або робити тестування A / B виробництва з оцінкою CTR / CR та ROI. Завжди включайте якісь питання якості, оскільки лише CTR / CR / ROI може вводити в оману і не гарантувати сумісність із баченням вашого продукту.

Багато чого було опущено лише для того, щоб зберегти текст остаточно довгим. Окрім CTR / CR / ROI / якості рекомендацій, ви повинні швидко ознайомитись із загальними можливостями розглянутих РС. Можливо, у майбутньому ви захочете включити рекомендації у свої електронні кампанії. Чи буде це працювати? Чи є у нього можливість повороту рекомендацій, щоб певний користувач не отримував той самий набір рекомендацій у кожному електронному листі? Чи можете ви обслуговувати всі свої бізнес-вимоги, чи можете ви впливати на рекомендації, збільшити якийсь тип контенту, відфільтрувати його за різними критеріями? Ці теми не висвітлюються, але ви можете відчути, що хочете їх також розглянути.

Автор є співзасновником у рекомбі, вдосконаленому механізмі рекомендацій SaaS.