AI VK published an article by engineer Ivan Vorobyov on Habr regarding the "stream" mechanism in VK Video recommendations: a unified pipeline splits into several independent pipelines for specific tasks immediately after user data collection, and their results are recombined into a single feed via blending. For the viewer, the feed appears unchanged externally, but internally each task operates within its own contour with its own configuration and release process.
What happened
The AI VK blog published an article on Habr titled "How we in AI VK split recommendations into streams," authored by Ivan Vorobyov, a lead engineer in the basic quality department of VK Video recommendations. The article describes the internal "stream" mechanism: the classic recommendation pipeline ("data collection → candidate selection → filtering → ranking → blending") splits into several independent pipelines immediately after user data collection. Each stream handles its own task: selection based on known interests (exploit), exploration of user interests (explore), exploration of new documents, and author support. Streams are assembled from shared "building block" components—candidate selection, filtering, and feature calculation methods—while each has its own configuration and separate release process. At the output, results are combined via blending based on quotas and tags into a single feed, so nothing changes for the VK Video viewer.
Context
The key detail of the scheme is the splitting point: contours receive their own settings and release cycles immediately after the common data collection stage, rather than being reduced to quotas in the final output. Previously, in a monolithic pipeline, settings accumulated conditions for each option, and experiments competed for common slots. The authors clarify that the total volume of configuration did not decrease with the split—its structure changed, and the "independence" of streams is achieved through computation reuse: common "blocks" are not recreated between requests and streams, and features are calculated once per request. In other words, decomposition pays off only together with such optimizations. The pattern itself—splitting a multitask system into isolated contours with a common component bus and blending at the output—is known in the recommendation industry, and the value of the publication lies in the specific splitting scheme and implementation details, not in a new methodology. Within VK, the mechanism has been moved to the Discovery platform and is already scaling to other products.
Why this matters for the industry
For teams building recommendation systems, the material provides a practical template for architecture design reviews: distribute tasks to isolated contours immediately after the common entry point, maintain local configuration instead of global condition branching, write metrics and logs with stream tags, and plan feature computation reuse in advance. In such a scheme, experiments stop competing for common slots, and isolation of a specific mechanic's contribution via stream-tagged metrics makes ablation checks cleaner as expected. The replication of the mechanism through the Discovery platform signals that pipeline decomposition is becoming a platform standard for VK, not a one-time refactoring. However, the publication does not offer a ready-made product or API for external systems—it is a description of internal mechanics applicable as a design guideline.
Why this matters for users
There are no noticeable changes for VK Video viewers: streams are glued together by blending into a familiar feed, and the user experience remains the same. The publication gives readers a rare "under the hood" breakdown of recommendations from a major platform: it shows how selection based on known interests, exploration of new documents, and author support coexist, why the failure of one stream does not crash the others, and how resources are saved through computation reuse. For those who design systems where one pipeline solves many tasks, the breakdown serves as a diagnostic: if configuration branches with conditions for each setting and experiments share common slots, it is worth considering splitting into streams.
What is currently unknown / limitations
The available material contains no offline metrics, A/B numbers, or latency and cost indicators that would measurably confirm the benefit of the split. The authors' claim that overhead is reduced to approximately zero remains an engineering estimate rather than a measurement result. This is a description of VK's internal mechanics: without code, specific metrics, and documentation, the scheme cannot be reproduced one-to-one, and the commercial effect outside of VK has not yet been demonstrated.
Sources
Author
Look at AI, editorial team