AI recommendation engine: Yandex тества Sona в продукция
Yandex представи Sona на 5 октомври 2026 г. като единен генеративен AI recommendation engine, който заменя обичайната многоетапна каскада за препоръки в седемдневен live експеримент при смарт високоговорители. Резултатът е важен, защото подсказва, че големи recommendation системи могат да опростят serving архитектурата, да намалят натоварването по feature pipeline-а и въпреки това да подобрят ангажираността. Според обобщението на MarkTechPost на техническия доклад на Yandex, моделът е заменил над 15 candidate generators, както и pre-ranking и ranking с един transformer в продукция.
Yandex заменя своята каскада за препоръки със Sona
Основното твърдение е необичайно конкретно: Yandex казва, че Sona е заменил над 15 candidate generators, pre-ranking етапа и финалния ranking етап в live A/B тест при смарт високоговорители. Тестът е продължил седем дни и е използвал 15% от произволно избрани потребители във всяко разпределение, което е достатъчно, за да говорим за нещо повече от лабораторен резултат.
Отчетените ръстове също са съществени за вече зряла повърхност. Yandex съобщава за +4.53% Active Users, +6.30% общо време на слушане, +11.42% likes, +17.99% repeat commands и +7.37% deeply engaged users спрямо продукционната контролна група. За екипите, които управляват recommender stack, това е същинската новина: архитектурната промяна не просто е запазила качеството, а е подобрила потребителското поведение в няколко точки от funnel-а.
MarkTechPost перифразира доклада като преход от отделни системи за candidate generation и ranking към един модел, който споделя едно user representation и за двете задачи. Именно този избор прави Sona значим и извън контекста на Yandex Music.
Защо каскадните recommenders достигат таван
Повечето recommendation системи в продукция са се превърнали в каскади по логични причини. Лек candidate generator поддържа retrieval-а бърз, pre-ranker намалява разхода, а по-тежък ranker прави финалния избор. Но всеки етап вижда само част от решението. Щом даден upstream модел филтрира даден елемент, downstream ranker-ът вече няма шанс да го върне.
Това създава два познати enterprise проблема. Първо, системата натрупва feature engineering и model sprawl с времето. Второ, екипите започват да оптимизират локални метрики на всеки етап, вместо крайния резултат за потребителя. Архитектурата на Sona е интересна, защото се опитва да премахне и двата проблема едновременно: без hand-engineered features и с едно споделено representation за generation и ranking.
Тази посока съвпада и с по-широките изследвания в областта на recommendation системите. Работата на Meta по HSTU generative recommenders преформулира препоръките като sequential prediction върху потребителски действия, а статията OneRec на Kuaishou показва, че единен encoder-decoder recommender може да обслужва реален трафик. Приносът на Yandex изглежда е именно твърдението за пълна замяна на каскадата, валидирано в продукционна среда за музика и смарт високоговорители.
Какво се променя в модела и операциите
Архитектурата на Sona е изградена около един encoder за потребителска история, decoder, който генерира candidates, и ranking модул, който оценява тези candidates спрямо същата encoder памет. Вместо да разчита на стотици ръчно създадени features, тя използва полета от логнати събития като track ID, artist ID, duration, likes и played time, заедно с learned Semantic IDs.
Настройката със Semantic ID е един от по-практичните детайли. Според обобщението на доклада всеки трак се превръща в tuple от три дискретни кода, създадени чрез residual K-means след refinement етап, който подравнява аудио и metadata със слушателското поведение. Yandex твърди, че това превъзхожда CLMR baseline-а по Recall@1000, като подобрява резултата от 0.8111 до 0.8524.
Дизайнът за history compression също се откроява. Sona обръща внимание на 8,192 предишни събития, но не изразходва еднакъв compute за цялата последователност. Най-скорошните 2,048 събития получават по-дълбоко self-attention, а по-старите се обработват по-леко. Това е компромис, насочен към продукционна употреба: запазва голяма част от качеството на пълното attention, като същевременно намалява inference разхода приблизително наполовина според доклада.
От оперативна гледна точка teacher-student setup-ът може да е също толкова важен, колкото и дизайнът на модела. Yandex е използвал frozen teacher ranker с 0.6B параметъра по време на обучението, след което го е премахнал при serving. Нови тегла са достигали до serving на всеки 10 минути, със средна end-to-end latency от 45 минути и p99 на 60 минути. Serving-ът е работил върху NVIDIA Triton Inference Server с CUDA graphs, достигайки 41% model FLOPs utilization. Последното число напомня, че архитектурното опростяване има стойност само ако serving пътят е достатъчно дисциплиниран, за да го поддържа.
Как Sona се сравнява с OneRec и HSTU
Sona не е единствената система, която насочва recommendation към генеративни архитектури, но профилът ѝ е различен.
| System | What it changes | Inputs | Online evidence |
|---|---|---|---|
| Sona (Yandex) | Replaces candidate generation, pre-ranking, and ranking with one served model | Logged event fields + Semantic IDs | +4.53% Active Users in a 7-day A/B test |
| OneRec (Kuaishou) | Serves a single encoder-decoder recommender on part of total QPS | Includes engineered user pathways | Reported App Stay Time gains |
| HSTU GR (Meta) | Reframes recommendation architecture around sequential transduction | User action sequences | Reported online uplift across Meta surfaces |
Компромисът е, че тези резултати не са директно съпоставими. Те идват от различни каталози, повърхности, цели и потребителски поведения. Recommendation engine за музика при смарт високоговорители не е същият оперативен проблем като short-video feed или multi-surface social платформа.
Все пак дизайн моделът става все по-ясен. Все повече екипи си задават въпроса дали един AI recommendation engine трябва да остане разделен на няколко retrieval и ranking етапа, или съвременните генеративни архитектури могат да поемат по-голяма част от този stack, без да се губи контрол върху latency и relevance.
Какво да следят enterprise екипите оттук нататък
За екипите в медии, стрийминг и e-commerce практичният извод не е утре да заменят всяка каскада за препоръки. По-скоро е да идентифицират къде фрагментацията между етапите добавя разход, без да добавя достатъчно relevance. Най-подходящите pilot повърхности обикновено са тези с висок обем събития, кратки feedback цикли и измерими engagement резултати.
Вторият извод е архитектурна дисциплина. Премахването на hand-engineered features звучи привлекателно, но прехвърля натиска към quality на данните, sequence design, честота на retraining и serving инфраструктура. Екипите, които обмислят този път, трябва да преценят дали тяхната item taxonomy, user-event logging и latency budget могат да поддържат споделен generator-ranker дизайн.
За компаниите, които оценяват възможни пътища за внедряване, AI e-commerce product recommendations е най-близкият service pattern до тази тема, защото поставя фокус върху production recommendation системи, integration architecture и измерими бизнес резултати, а не само върху новостта на модела.
Следващото, което си струва да се следи, е обхватът. Yandex валидира Sona върху определен дял от трафика и конкретна повърхност, а не във всяка recommendation среда, която компанията управлява. Ако подобни системи продължат да показват ръст през 2026 г., enterprise разговорът ще се измести от това дали да се тестват single-model recommenders към това къде те могат да заменят по-старите stack-ове, без да създават нови оперативни тесни места.
Вторият ключов въпрос е зрелостта на инструментите. Историята около модела е убедителна, но по-трудният въпрос за enterprise екипите е дали процесите за retraining, observability и rollback могат да поддържат темпото, когато един модел поема по-голяма част от натоварването при вземането на решения.
Написано от екипа на Encorp. Свържете се с нас: запазете 30-минутен разговор или ни последвайте в LinkedIn.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn