Внутри рекомендательной системы VK Видео, которую в компании называют AI VK, появился механизм под названием стримы. О нём в корпоративном блоге рассказал Иван Воробьев, ведущий инженер отдела базового качества рекомендаций. По его словам, изменение не является продуктовой функцией и не должно быть заметно пользователям: его ценность в том, что командам становится проще дорабатывать отдельные составляющие рекомендаций, не затрагивая соседние. Стримы появились из вполне обычной инженерной ситуации, когда один пайплайн решал сразу несколько разных задач и постепенно обрастал нетривиальными взаимосвязями. Автор прямо оговаривает, что продуктовой фичей механизм не назовёшь, — для пользователя изменения не должны быть видны, а выигрыш лежит в плоскости удобства разработки и сопровождения системы.

Схема работы рекомендаций до нововведения была общей для всех этапов. Когда человек открывает ленту, сервис обращается к рекомендеру, и снаружи это выглядит как одна операция: пришёл запрос — вернулся список объектов. Внутри же последовательно проходят сбор данных о пользователе, подбор документов-кандидатов, фильтрация, ранжирование и блендинг. До внедрения стримов кандидаты подбирались сразу для всего объёма задач в запросе, затем проходили через одни и те же фильтры и ранжировались единым образом, а разбиение по меткам и смешивание по квотам происходило только на последнем шаге. Таким образом разделение задач в системе существовало, но было отнесено в самый конец конвейера. Именно эта особенность — общая конфигурация при разных целях — и стала источником накопленных сложностей.

Стримы переносят это разделение на этап, следующий сразу за сбором данных о пользователе. Запрос по-прежнему приходит в рекомендер один, но дальше разбивается на несколько стримов, в рамках каждого из которых документы независимо подбираются, фильтруются и ранжируются. Под капотом часть вычислений переиспользуется между стримами, однако на уровне конфигурации их исполнение можно считать независимым. Финальный блендинг по квотам сохранился, но теперь умеет работать не только по меткам документов, но и по стримам. Среди задач, которые решаются в рамках одного запроса, автор перечисляет подбор по известным интересам, исследование интересов пользователя, исследование новых документов и поддержку авторов, которым нужно помочь найти аудиторию. Четвёртая задача прямо связана с устойчивостью платформы: она должна помогать новым и небольшим авторам находить свою аудиторию, чтобы сервис не замыкался на тех, кто уже набрал охваты.

Наиболее показательной в статье названа пара задач — подбор по известным интересам и изучение нового. Первая опирается на то, в чём система уже уверена, вторая решается ради сбора дополнительных данных для первой: если пользователь лайкнул котика, это не повод показывать ему дальше только котиков, стоит попробовать автомобили, спорт и другие темы и посмотреть на реакцию. Пока обе задачи решались одним пайплайном, настраивать их одновременно было проблематично: подбор кандидатов, фильтры и ранжирование оказывались общими, а цели у задач разными, поэтому каждая настройка становилась компромиссом. Стримы позволяют развести конфигурации и двигать каждую отдельно, оставив замешивание по квотам там же, где оно было, — в самом конце. В терминах самой статьи это классическая для рекомендательных систем пара: система применяет то, что уже знает про пользователя и документы, и параллельно собирает новые данные.

Проблема связности проявлялась на практике тремя способами. Во-первых, конфигурация ветвилась по каждому параметру в отдельности: настройки обрастали условиями вида «в таком-то случае применить фильтр, в другом не применять», и понять, что получается в сумме, становилось всё труднее. Во-вторых, изменения было сложно изолировать, а вклад конкретной механики — оценить, поскольку разные задачи использовали одних и тех же кандидатов, общее ранжирование и общую выдачу. Метки и информация об источнике кандидата помогали отслеживать, откуда появился документ, но один и тот же документ мог попадать в выдачу по разным причинам, что размывало оценку. В-третьих, эксперименты конкурировали за общие слоты: разводить A/B по слоям так, чтобы они не пересекались на пользователях, умели и раньше, но один крупный параметр или флаг мог одновременно менять несколько смысловых частей рекомендера. Сбои обычно удавалось находить по мониторингам, однако проблема одного механизма могла затронуть весь запрос.

Контекст публикации показателен для российской индустрии: тема внутренней инженерной инфраструктуры рекомендаций обсуждается в одном потоке с материалами о Spec-Driven Development для ИИ-агентов и опытом команд, которые внедряют агентов в разработку. Это отражает общий сдвиг интереса от демонстрации возможностей моделей к вопросам эксплуатации, тестируемости и управляемости ИИ-систем. Для VK Видео стримы — это ставка на масштабируемость платформы: подход уже внедрён в рекомендациях сервиса, а затем через внутреннюю платформу сделан доступным другим продуктам компании. Прямых конкурентов в статье не упоминается, но подобные задачи декомпозиции рекомендательных конвейеров так или иначе решают все крупные платформы с лентами и видеосервисами, и появление подробного разбора внутренней архитектуры можно считать сигналом зрелости этого направления в российской практике.

Дальнейшие шаги автор не раскрывает детально: остаётся открытым вопрос, как стримы будут сосуществовать с уже накопленными метками документов и насколько глубоко платформа позволит другим продуктам переиспользовать общие части вычислений. Неясно и то, какие метрики качества и стабильности будут применяться для оценки вклада каждого стрима в итоговую выдачу, а также как именно будет устроено разведение экспериментов между стримами на практике. Тем не менее сам факт публикации подробного разбора говорит о том, что VK рассматривает рекомендательную инфраструктуру как инженерный актив, который можно тиражировать внутри компании, а не как набор локальных настроек одного сервиса.