Како работиме на квалитетот и брзината на избор на препораки

Моето име е Павел Пархоменко, јас сум развивач на ML. Во оваа статија, би сакал да зборувам за структурата на услугата Yandex.Zen и да споделам технички подобрувања, чија имплементација овозможи да се зголеми квалитетот на препораките. Од овој пост ќе научите како да ги пронајдете најрелевантните за корисникот меѓу милиони документи за само неколку милисекунди; како да се направи континуирано разложување на голема матрица (која се состои од милиони колони и десетици милиони редови), така што новите документи ќе го добијат својот вектор за десетици минути; како повторно да се искористи распаѓањето на матрицата корисник-напис за да се добие добра векторска репрезентација за видео.

Нашата база на податоци за препораки содржи милиони документи од различни формати: текстуални написи создадени на нашата платформа и преземени од надворешни страници, видеа, наративи и кратки објави. Развојот на таква услуга е поврзан со голем број технички предизвици. Еве некои од нив:

• Поделете ги компјутерските задачи: правете ги сите тешки операции офлајн и во реално време само извршувајте брза примена на моделите за да бидете одговорни за 100-200 ms.
• Брзо земете ги предвид дејствата на корисникот. За да го направите ова, неопходно е сите настани веднаш да бидат доставени до препорачувачот и да влијаат на резултатите од моделите.
• Направете го доводот така што за новите корисници брзо се прилагодува на нивното однесување. Луѓето кои штотуку се приклучија на системот треба да чувствуваат дека нивните повратни информации влијаат на препораките.
• Брзо разберете кому да препорачате нова статија.
• Брзо реагирајте на постојаното појавување на нови содржини. Секој ден се објавуваат десетици илјади написи, а многу од нив имаат ограничен животен век (да речеме, вести). Тоа е она што ги разликува од филмови, музика и други долговечни и скапи содржини за создавање.
• Пренеси знаење од една област на домен во друга. Ако системот за препораки има обучени модели за текстуални написи и додадеме видео на него, можеме повторно да ги користиме постоечките модели за да се рангира новиот тип на содржина подобро.

Ќе ви кажам како ги решивме овие проблеми.

Избор на кандидати

Како да се намали бројот на документи што се разгледуваат за илјадници пати за неколку милисекунди, без практично никакво влошување на квалитетот на рангирањето?

Да претпоставиме дека обучивме многу ML модели, генериравме карактеристики врз основа на нив и обучивме друг модел кој ги рангира документите за корисникот. Сè би било добро, но не можете само да ги земете и броите сите знаци за сите документи во реално време, ако има милиони од овие документи, а препораките треба да се направат за 100-200 ms. Задачата е да се избере одредено подмножество од милиони, кое ќе биде рангирано за корисникот. Оваа фаза обично се нарекува избор на кандидат. Постојат неколку барања за тоа. Прво, изборот мора да се случи многу брзо, за да остане што е можно повеќе време за самиот пласман. Второ, со значително намалување на бројот на документи за рангирање, мора да ги зачуваме документите релевантни за корисникот што е можно поцелосно.

Нашиот принцип на избор на кандидат еволуираше и во моментот стигнавме до шема во повеќе фази:

Прво, сите документи се поделени во групи, а најпопуларните документи се земени од секоја група. Групите можат да бидат сајтови, теми, кластери. За секој корисник, врз основа на неговата историја, се избираат најблиските групи и од нив се земаат најдобрите документи. Исто така, го користиме индексот kNN за да избереме документи кои се најблиску до корисникот во реално време. Постојат неколку методи за конструирање на индекс на kNN; нашите функционираа најдобро ХНСВ (Хиерархиски пловени графикони на мал свет). Ова е хиерархиски модел кој ви овозможува да ги пронајдете N најблиските вектори за корисник од базата на податоци од милиони за неколку милисекунди. Прво ја индексираме целата наша база на документи офлајн. Бидејќи пребарувањето во индексот работи доста брзо, ако има неколку силни вградувања, можете да креирате неколку индекси (еден индекс за секое вградување) и да пристапите до секој од нив во реално време.

Сè уште имаме десетици илјади документи за секој корисник. Сè уште е многу за да се избројат сите карактеристики, така што во оваа фаза користиме лесно рангирање - лесен тежок модел за рангирање со помалку карактеристики. Задачата е да се предвиди кои документи ќе ги има тешкиот модел на врвот. Во тешкиот модел, односно во последната фаза од рангирањето ќе се користат документи со највисок предиктор. Овој пристап ви овозможува да ја намалите базата на податоци на документи што се сметаат за корисникот од милиони на илјадници во десетици милисекунди.

ALS чекор во траење

Како да ги земете предвид повратните информации од корисниците веднаш по кликнување?

Важен фактор во препораките е времето на одговор на повратните информации од корисниците. Ова е особено важно за новите корисници: кога некое лице штотуку почнува да го користи системот за препораки, тој добива неперсонализиран извор на документи од различни теми. Веднаш штом ќе го направи првиот клик, треба веднаш да го земете предвид ова и да се прилагодите на неговите интереси. Ако ги пресметате сите фактори офлајн, брзата реакција на системот ќе стане невозможна поради доцнењето. Значи, неопходно е да се обработат корисничките дејства во реално време. За овие цели, го користиме чекорот ALS при извршување за да изградиме векторска репрезентација на корисникот.

Да претпоставиме дека имаме векторска претстава за сите документи. На пример, можеме да изградиме вградувања офлајн врз основа на текстот на статијата користејќи ELMo, BERT или други модели за машинско учење. Како можеме да добиеме векторска претстава на корисници во истиот простор врз основа на нивните интеракции во системот?

Општ принцип на формирање и разградување на матрицата корисник-документДозволете ни да имаме m корисници и n документи. За некои корисници, нивната врска со одредени документи е позната. Тогаш оваа информација може да се претстави како m x n матрица: редовите одговараат на корисниците, а колоните одговараат на документите. Бидејќи лицето не ги видело повеќето документи, повеќето матрични ќелии ќе останат празни, додека други ќе бидат пополнети. За секој настан (како, не ми се допаѓа, клик) е дадена одредена вредност во матрицата - но ајде да разгледаме поедноставен модел во кој допаѓањето одговара на 1, а недопаѓањето одговара на -1.

Ајде да ја разложиме матрицата на два: P (m x d) и Q (d x n), каде што d е димензијата на векторската претстава (обично мал број). Тогаш секој објект ќе одговара на d-димензионален вектор (за корисник - ред во матрицата P, за документ - колона во матрицата Q). Овие вектори ќе бидат вградување на соодветните објекти. За да предвидите дали на корисникот ќе му се допадне документ, можете едноставно да ги помножите нивните вградувања.

Еден од можните начини за разложување на матрицата е ALS (Alternating Least Squares). Ќе ја оптимизираме следнава функција за загуба:

Тука rui е интеракцијата на корисникот u со документот i, qi е векторот на документот i, pu е векторот на корисникот u.

Тогаш оптималниот кориснички вектор од гледна точка на средната квадратна грешка (за фиксни вектори на документи) се наоѓа аналитички со решавање на соодветната линеарна регресија.

Ова се нарекува „чекор ALS“. А самиот алгоритам ALS е дека наизменично поправаме една од матриците (корисници и статии) и ја ажурираме другата, наоѓајќи го оптималното решение.

За среќа, наоѓањето на векторската репрезентација на корисникот е прилично брза операција што може да се направи при извршување користејќи векторски инструкции. Овој трик ви овозможува веднаш да ги земете предвид повратните информации од корисниците при рангирањето. Истото вградување може да се користи во индексот kNN за да се подобри изборот на кандидати.

Дистрибуирано заедничко филтрирање

Како да се направи инкрементална дистрибуирана матрица факторизација и брзо да се најдат векторски претстави на нови статии?

Содржината не е единствениот извор на сигнали за препораки. Друг важен извор се информациите за соработка. Добрите карактеристики за рангирање традиционално може да се добијат од распаѓањето на матрицата кориснички документ. Но, кога се обидувавме да направиме такво распаѓање, наидовме на проблеми:

1. Имаме милиони документи и десетици милиони корисници. Матрицата не се вклопува целосно на една машина, а распаѓањето ќе трае многу долго.
2. Поголемиот дел од содржината во системот има краток животен век: документите остануваат релевантни само неколку часа. Затоа, неопходно е да се конструира нивното векторско претставување што е можно побрзо.
3. Ако изградите распаѓање веднаш по објавувањето на документот, доволен број корисници нема да имаат време да го проценат. Затоа, неговата векторска репрезентација најверојатно нема да биде многу добра.
4. Ако некој корисник сака или не сака, нема да можеме веднаш да го земеме предвид ова при распаѓањето.

За да ги решиме овие проблеми, имплементиравме дистрибуирано распаѓање на матрицата корисник-документ со чести инкрементални ажурирања. Како точно функционира?

Да претпоставиме дека имаме кластер од N машини (N е во стотици) и сакаме да направиме дистрибуирано разложување на матрица на нив што не се вклопува на една машина. Прашањето е како да се изврши ова разложување за, од една страна, да има доволно податоци за секоја машина, а од друга, пресметките да бидат независни?

Ќе го користиме алгоритмот за распаѓање ALS опишан погоре. Ајде да погледнеме како да се изврши еден ALS чекор на дистрибуиран начин - останатите чекори ќе бидат слични. Да речеме дека имаме фиксна матрица на документи и сакаме да изградиме матрица на корисници. За да го направите ова, ќе го поделиме на N делови по линии, секој дел ќе содржи приближно ист број линии. На секоја машина ќе испратиме непразни ќелии од соодветните редови, како и матрицата на вградување документи (целосно). Бидејќи нејзината големина не е многу голема, а матрицата на кориснички документи е обично многу ретка, овие податоци ќе се вклопат на обична машина.

Овој трик може да се повторува во неколку епохи додека моделот не се конвергира, менувајќи ја фиксната матрица една по една. Но, дури и тогаш, распаѓањето на матрицата може да потрае неколку часа. И ова не го решава проблемот што треба брзо да примате вградувања на нови документи и да ги ажурирате вградувањата на оние за кои имаше малку информации при градењето на моделот.

Ни помогна воведувањето на брзи постепено ажурирања на моделот. Да речеме дека имаме моментално обучен модел. Од нејзината обука, имаше нови написи со кои нашите корисници комуницираа, како и написи кои имаа мала интеракција за време на обуката. За брзо да ги добиеме вградувањата на таквите написи, ги користиме корисничките вградувања добиени за време на првата голема обука на моделот и правиме еден чекор ALS за да ја пресметаме матрицата на документите со фиксна корисничка матрица. Ова ви овозможува да примате вградувања доста брзо - во рок од неколку минути по објавувањето на документот - и често да ги ажурирате вградувањата на неодамнешните документи.

За да дадеме препораки веднаш да ги земеме предвид човечките дејства, за време на извршувањето не користиме вградувања на корисници добиени офлајн. Наместо тоа, правиме чекор ALS и го добиваме вистинскиот кориснички вектор.

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

Како да ги искористите повратните информации од корисниците за текстуални написи за да изградите векторска претстава на видео?

Првично, препорачувавме само текстуални статии, така што многу од нашите алгоритми се прилагодени на овој тип на содржина. Но, при додавање на други видови содржини, се соочивме со потребата да ги прилагодиме моделите. Како го решивме овој проблем користејќи видео пример? Една опција е да се преквалификуваат сите модели од нула. Но, ова трае долго, а некои од алгоритмите бараат големината на примерокот за обука, кој сè уште не е достапен во потребната количина за нов тип на содржина во првите моменти од неговиот живот на услугата.

Отидовме на другата страна и повторно ги искористивме текстуалните модели за видеото. Истиот ALS трик ни помогна да создадеме векторски претстави на видеа. Направивме векторско претставување на корисници врз основа на текстуални написи и направивме чекор ALS користејќи информации за преглед на видео. Така лесно добивме векторска претстава на видеото. И за време на извршувањето, ние едноставно ја пресметуваме близината помеѓу векторот на корисникот добиен од текстуални написи и векторот за видео.

Заклучок

Развивањето на јадрото на системот за препораки во реално време вклучува многу предизвици. Треба брзо да ги обработувате податоците и да примените ML методи за ефективно да ги користите овие податоци; изградба на комплексни дистрибуирани системи способни за обработка на кориснички сигнали и нови единици на содржина во минимално време; и многу други задачи.

Во сегашниот систем, чиј дизајн го опишав, квалитетот на препораките за корисникот расте заедно со неговата активност и должината на престојот на услугата. Но, се разбира, тука лежи главната тешкотија: тешко е системот веднаш да ги разбере интересите на личноста која има мала интеракција со содржината. Подобрувањето на препораките за новите корисници е нашата клучна цел. Ќе продолжиме да ги оптимизираме алгоритмите, така што содржината што е релевантна за некоја личност побрзо ќе влезе во неговата храна, а неважните содржини да не се прикажуваат.

Извор: www.habr.com