Оценка на препоръчителни системи: Избор на най-добрата за вашия бизнес

Заедно с безкрайното разрастване на електронната търговия и онлайн медиите през последните години, все повече и повече софтуерни системи за препоръки (SaaS) се предлагат днес. За разлика от преди 5 години, когато използването на RS-та беше привилегия на големите компании, изграждащи собствена собствена RS-компания, харчейки голям бюджет за екип от учени за данни, днешната популярност на решенията на SaaS прави достъпно използването на препоръки дори за малки и средни -размерни компании. Въпрос, с който се сблъскват ОПР на такива компании, когато търсят правилния SaaS RS, е: Кое решение е най-доброто? Ако приемем, че все още нямате RS или не сте доволни от сегашния си RS, кое решение да изберете?

В тази статия ще разгледам два подхода:

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

Офлайн светът = Как академиците го правят?

РС са изследвани от десетилетия в академичните изследвания. Има много научни трудове, които въвеждат различни алгоритми и за да направят алгоритмите съпоставими, те използват академични мерки. Ние наричаме тези мерки офлайн мерките. Не пускате нищо в производство, просто играете с алгоритмите във вашата пясъчна кутия и ги прецизирате според тези мерки. Аз лично съм изследвал тези мерки много, но от днешната ми гледна точка те са по-скоро праисторически. Но дори в средните векове на 2006 г. в известната награда за Netflix, е използвана чисто академична мярка, наречена RMSE (грешка средно коренно ниво).

Само за да обясня накратко как работи, той предполага, че вашите потребители изрично оценяват вашите продукти с брой на звездите (1 = силна неприязън, 5 = силна като) и имате куп такива оценки (записи, в които се казва, че потребителят е оценил артикул X с Y звезди) от миналото. Използва се техника, наречена разделяне на валидността: вземате само подмножество от тези оценки, да речем 80% (наречен влаков комплект), изграждате RS на тях и след това молите РС да предвиди оценките на 20%, които сте скрито (тестът). И така може да се случи, че тестов потребител е оценил някой елемент с 4 звезди, но моделът ви прогнозира 3,5, следователно има грешка 0,5 в тази оценка и точно от там идва RMSE. След това просто изчислявате средната стойност на грешките от целия тестов набор, използвайки формула и получавате краен резултат от 0,71623. Бинго! Ето колко е добър (или по-точно лош) вашият РС. Или можете също да използвате различна формула и да получите MAE (средна абсолютна грешка), която не санкционира огромни грешки (истински 4 звезди, прогнозирана 1 звезда) толкова много, така че може да получите само 0.6134.

Един малък недостатък тук е, че такива данни почти не съществуват в реалния свят или поне има твърде малко от тях.

Потребителите са твърде мързеливи и няма да оценят нищо. Те просто отварят уеб страница и ако им хареса това, което виждат, могат да го купят / консумират; ако е гадно, те тръгват толкова бързо, колкото са дошли. И така имате само така наречените имплицитни оценки във вашия дневник на уеб сървъра или база данни за покупки и не можете да измервате грешката в броя на звездите върху тях, просто защото няма звезди. Имате само +1 = потребителят е гледал детайл или е закупил продукт и обикновено нищо друго. Понякога те се наричат ​​унарните оценки, които знаете от бутона „Харесвам“ на Facebook: рейтингът е или положителен, или непознат (потребителят просто не знае, че съдържанието съществува).

Все още можете да използвате разделителното валидиране на такива данни, дори за ваше собствено сравнение офлайн на препоръчителите на SaaS. Кажете, че вземете, например, своята база данни за покупки, представите история на 80% потребители в RS и след това за всеки тестов потребител изпратите само няколко покупки и помолете РС да предвиди останалото. Може да сте скрили 4 закупени артикула и да поискате от RS за 10 артикула. Можете да получите 0%, 25%, 50%, 75% или 100% точност за този потребител, в зависимост от това колко от скритите 4 са се появили в препоръчителните 10. И тази точност се нарича Recall. Можете да го оцените средно за целия си тестов набор и TADAAA! Резултатът е 31.4159%, това е колко е добър вашият RS.

Сега честно казано, въпреки че Recall е много по-здрав от RMSE, той все още носи много болка. Кажете, че тестов потребител е гледал 20 епизода от същата телевизионна поредица и измервате припомнянето за нея. Така че криете епизоди # 18-20 и молите РС да ги предскаже от №1-17. Това е доста лесна задача, тъй като епизодите са силно свързани, така че можете да си припомните 100%. Сега вашият потребител откри ли нещо ново? Искате ли изобщо да й препоръчате такова съдържание? И какво изобщо носи най-високата стойност на бизнеса за вас? Кажете в онлайн магазина, искате ли да препоръчате алтернативи или аксесоари? Трябва да почувствате, че се качвате на много тънък лед с извикване.

И още една тайна, която ще ви кажа: В някои случаи (не винаги, зависи от вашия бизнес!) Е честна стратегия да препоръчвате само най-популярните в световен мащаб артикули (a.k.a. бестселъри), за да постигнете разумно припомняне. Така че тук идва покритието на каталога. Искате ли потребителите да продължават да откриват ново и ново съдържание, за да останете лоялни? Тогава може да искате да препоръчате колкото се може повече различни артикули. В най-простия случай, за да изчислите покритието на Каталога, просто вземете своите тестови потребители, поискайте препоръка за всеки един от тях и сложете всички препоръчани елементи. Получавате голям набор от различни елементи. Разделете размера на този комплект на общия брой артикули в целия ви каталог и ще получите… 42.125%! Това е частта от артикулите, които вашият RS може да препоръча.

Сега помислете за модел на бестселъри. Може да има доста добро припомняне, но почти нулево покритие (5 константи?). И вземете случаен препоръчател. Има почти нулево изземване и 100% покритие. Може да почувствате, че искате някакъв компромис.

Горното изображение идва от моето (сега много остаряло) оригинално изследване. Можете да видите около 1000 различни модели RS, съставени в самолета Recall-Coverage. Глупав, нали? :) Може да се почувствате замаяни при избора на най-добрия, но се надявам да почувствате, че избирането на някои от горната дясна част („Pareto-optimal front“) може да бъде добър избор.

За да направите оценката си офлайн още по-стабилна, можете да използвате кръстосана проверка (Xval) вместо разделителна валидация. Просто разделете потребителите си на 10 пъти и преминете в цикъл: винаги вземете 9 пъти, за да изградите модела, и използвайте останалите 1 пъти, за да направите валидирането. Сравнете резултатите за тези 10 серии.

Сега може да кажете: Какво ще кажете за моя бизнес? Измерването на извикването и покритието може да е добре, но как са свързани с моите KPI?

И си прав. За да поставим SaaS RS на X-ос и $$$ на Y-оста, трябва да напуснем офлайн света и да влезем в производството!

Онлайн свят: Следвайте примерите за интелигентни CTO

Горепосоченият раздел беше за измерване на качеството на RS, преди той да започне да произвежда, сега е време да поговорим за бизнес KPI.

Докато при офлайн оценката обикновено използваме разделителното валидиране, при онлайн оценяването A / B-тестването (или многовариантното тестване) е най-известният днес подход. Можете да интегрирате няколко различни РС, да разделите потребителите си на групи и да поставите РС в борба. Малко скъпо, защото той изразходва ресурсите ви за развитие, така че можете да използвате прогнозната трудност на интеграцията и бъдещите разходи за персонализиране / корекции като една от вашите мерки, което може априори да намали набора от кандидати.

Сега нека да кажем, че сте готови за интеграцията и сте в състояние да разделите вашите онлайн потребители на A / B-тестови групи. Можете или да използвате собственото си хеширане на техните UID бисквитки, или да използвате някакъв инструмент за това (например VWO, Optimizely или дори GA, въпреки че последната опция е малко болезнена). За да направите експеримента, трябва да определите едно добро място на уебсайта / приложението си, където да тествате препоръките, тъй като сте сигурни, че не искате да направите пълната интеграция на всички кандидат-RS в началото на пилотния етап, нали? Ако имате малък трафик, имайте предвид, че избраното място трябва да е достатъчно видимо, за да събере значителни резултати. В обратния случай, ако имате огромен трафик, можете да изберете консервативна стратегия, например, да освободите само 20% от трафика си за тестване, като запазите себе си и останалите 80% потребители в безопасност, в случай че някои от кандидат-RS бъдете напълно счупени и препоръчайте странни неща.

Да предположим, че всичко е готово. Какво да измерваме? Най-лесните мерки са честотата на кликване (CTR) и процента на реализация (CR) на препоръките.

Показва се набор от N препоръки 20 пъти, от които 3 пъти потребител кликва върху поне един от препоръчаните елементи? Тогава вашият CTR е 15%. Наистина щракването е хубаво, но вероятно доведе потребителя до страница с подробности и може би искате да знаете какво се случи след това. Потребителят наистина намери ли съдържанието за интересно? Гледала ли е цялото видео, слушала ли е цялата песен, прочела цялата статия, отговорила на офертата за работа, поставила продукта в количката и всъщност го поръчала? Това е процентът на конверсия = брой препоръки, които направиха щастлив и вас, и вашия потребител.

Пример: Консулирайте KPI конзолата

CTR и CR могат да ви дадат добра оценка за ефективността на препоръчителя, но трябва да бъдете внимателни и да продължите да мислите за вашия продукт. Може да работите с портал за новини, поставяйки крайните новини на началната страница. Това може да не ви донесе най-високата възможна CTR, но поддържа качеството и усещането, което вие и вие имате към вашата услуга. Сега можете да поставите РС там и може да започне да показва различно съдържание, като например статии в жълта журналистика или забавни статии за „много бързи кучета, които се движат с невероятна скорост на височината“. Това може да увеличи незабавния Ви CTR 5 пъти, но това ще повреди вашето изображение и може да загубите потребителите в дългосрочен план.

Тук идва емпиричната оценка на РС. Просто стартирайте нова сесия с празни бисквитки, симулирайте поведението на потребителя и проверете дали препоръките са правилни. Ако имате QA екип, дайте им работа! Емпиричната оценка е едновременно сложна и лесна. Сложно е, защото не произвежда никакви номера, които бихте могли да представите на таблото с продукти. Но също така е лесно, защото благодарение на човешката си интуиция просто ще разпознаете кои препоръки са добри и кои са лоши. Ако изберете странно работещ препоръчател, вие се поставяте в много бъдещи проблеми, дори ако CTR / CR са високи в момента.

Но разбира се, освен за качеството, трябва да се грижите и за възвръщаемостта на инвестициите (ROI).

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

Едно предупреждение за изчисляване на възвръщаемостта на инвестициите: Много е размито и зависи от голям брой неизвестни: CR ли ще бъде същото на други места в моя уебсайт / приложение? (Прост отговор = не, няма да има, различните места имат различен CTR / CR). Как CR ще се промени, ако поставите препоръките на повече или по-малко привлекателна позиция? (Прост отговор = много). Как CR ще се развива във времето? Ще се научат ли потребителите да използват и да се доверят на препоръката или CR ще намалее?

Това води до крайната, но най-трудната мярка: стойността на живота на клиента (CLV). Търсите ситуацията „печелене-печелене“. Искате вашите потребители да харесат вашата услуга, да се чувстват комфортно, щастливи и готови да се върнат. За ръка с това, вие искате RS да подобри UX, да помогнете на потребителите да намерят интересно съдържание / продукти какво харесват. Как да достигнем висок CLV с помощта на RS?

Е, тук няма прости съвети. Трябва да потърсите приятни препоръки с високо емпирично качество и сравнително положителна възвръщаемост на инвестициите. Според мен приятността на препоръките обикновено съответства на бизнес стойността, ще ви попречи да бъдете изпращани от жалби от вашия QA екип / изпълнителен директор. И ако наблюдавате, че бизнес случаят е положителен, вие сте намерили това, което търсите :)

заключение

Опитах се да обхвана най-важните аспекти на оценката на РС. Може би сте виждали, че това не е лесна задача и има много за обмисляне, но се надявам поне да ви даде някои улики, за да се ориентирате в района. Можете да изпробвате RS офлайн, дори преди да влезете в производство, или да направите производствено A / B тестване с оценка на CTR / CR и ROI. Винаги включвайте някои QA, защото CTR / CR / ROI сам може да е подвеждащ и да не гарантира съвместимост с визията на вашия продукт.

Много е пропуснато само за да се запази текстът окончателно дълго. Освен CTR / CR / ROI / качество на препоръките, трябва бързо да разгледате общите възможности на разглеждания RS. Може да искате да включите препоръки в своите имейл кампании в бъдеще. Ще работи ли? Има ли възможности за завъртане на препоръки, така че даден потребител да не получава същия и същ набор от препоръки във всеки имейл? Можете ли да обслужвате всички ваши бизнес изисквания, можете ли да повлияете на препоръките, да засилите някакъв тип съдържание, да го филтрирате въз основа на различни критерии? Това са теми, които не са обхванати, но може да почувствате, че искате да ги разгледате.

Авторът е съосновател в Рекомби, усъвършенстван механизъм за препоръчване на SaaS.