How Implicit Relationship Chains Solve Cold‑Start Problems at NetEase Cloud Music
This article details NetEase Cloud Music's technical approach to building implicit user relationship chains—using SimHash, Item2Vec, and MetaPath2Vec embeddings, large‑scale vector search, and a unified service architecture—to address cold‑start challenges across multiple business scenarios.
Project Background
NetEase Cloud Music expands from its core music service into live streaming, podcasts, and other content, all of which face two cold‑start problems: delivering content to new or inactive users and exposing new or niche content to users. Existing solutions rely on cross‑domain preferences, but the team sought a method that is effective, low‑cost to develop, and broadly applicable.
After evaluating several techniques—including cross‑domain recommendation, user segmentation, meta‑learning, and relationship‑chain propagation—the team identified implicit relationship chains as a promising generic foundation, noting that many internet products (e.g., WeChat Channels, Pinduoduo) also use similar ideas.
Because Cloud Music lacks explicit friend connections, the solution builds implicit links from users' heterogeneous behavior across music, live, and podcast domains, anonymizing data for privacy.
Project Challenges
1. Data scale – Massive, multi‑scenario interaction logs required selective sampling. The team kept only core, desensitized behavior data and performed cleaning, filtering, and size reduction to obtain a high‑quality dataset.
2. Modeling – No explicit labels or clear optimization targets, and the interaction graph is heterogeneous (users, songs, live streams, podcasts) with multiple edge types (click, play, like, etc.).
3. Evaluation – Traditional ranking metrics (AUC) are unsuitable. The team combined qualitative analyses (case studies, Jaccard similarity, visual embedding inspection) with quantitative methods (online experiments, offline AUC/loss, recall/precision of u2u, u2i recommendations).
4. Service delivery – The system must support billion‑scale user vectors with millisecond‑level similarity search. The team evaluated Faiss, Milvus, Proxima and ultimately built an in‑house engine called Nsearch for high‑throughput, low‑latency vector retrieval.
Technical Evolution
The solution progressed through five research stages, illustrated below:
Stage 1 – SimHash : Treat each user's behavior sequence as a document, extract keywords, hash them, weight the bits, and aggregate into a 64‑bit fingerprint. Similarity is measured by Hamming distance (< 3 considered similar). To search efficiently among ~1 billion fingerprints, the 64‑bit strings are split into four 16‑bit blocks and indexed in key‑value stores; candidates are retrieved via block equality and then filtered by Hamming distance, reducing comparisons from 10⁹ to ≤ 65 536.
Stage 2 – Item2Vec : Inspired by Word2Vec, items become “words” and user interaction sequences become “sentences”. The team applied constrained negative sampling to improve representation of long‑tail items and derived user vectors via mean‑pooling of interacted item embeddings. High‑dimensional vector engines (Nsearch, Faiss) enable fast similarity lookup.
Stage 3 – MetaPath2Vec : Extends Item2Vec to heterogeneous graphs (users, songs, artists). Meta‑paths (e.g., User‑Song‑User) guide random walks, and a heterogeneous Skip‑Gram model maximizes co‑occurrence probability between a node and its typed neighbors, producing embeddings for all node types.
Service Deployment
The architecture consists of three layers:
Algorithm layer – trains SimHash, Item2Vec, and MetaPath2Vec models to produce user and content embeddings.
Vector engine layer – imports embeddings into Nsearch for high‑performance similarity indexing.
Service layer – built on the proprietary rtrs framework, providing unified APIs, dynamic publishing, multi‑level caching, and asynchronous processing for downstream business services.
This stack supports various recall modes (u2u, u2i, i2i) and can be customized per business scenario.
Project Outcomes
Implicit relationship chains now serve 13 applications across 9 Cloud Music services (music, podcasts, feeds, etc.). Notable results include a 9.4% increase in average connection time for the “listen together with strangers” feature. The service handles peak QPS > 5 000 with an average latency of ~10 ms.
Conclusion & Outlook
While the infrastructure has proven valuable, challenges remain: model interpretability for recommendation explanations, deeper exploitation of data value (KOL discovery, community detection), enhancing generalization with richer side information, and improving robustness against popularity bias. Future work will explore graph‑database‑assisted modeling and contrastive learning to address these gaps.
References
Charikar, M. S. (2002). Similarity estimation techniques from rounding algorithms. Proceedings of the 34th ACM Symposium on Theory of Computing .
Singh, G., Manku, J., Jain, A., & Sarma, A. (2007). Detecting near‑duplicates for web crawling. WWW ’07 .
Barkan, O., & Koenigstein, N. (2016). Item2vec: Neural item embedding for collaborative filtering. IEEE MLSP .
Dong, Y., Chawla, N. V., & Swami, A. (2017). MetaPath2vec: Scalable representation learning for heterogeneous networks. KDD ’17 .
Kipf, T. N., & Welling, M. (2017). Semi‑Supervised Classification with Graph Convolutional Networks. ICLR .
He, X., Deng, K., Wang, X., Li, Y., Zhang, Y., & Wang, M. (2020). LightGCN: Simplifying and Powering Graph Convolution Network for Recommendation.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
