Т-Банк: ML System Design

Clarify the business objective first: retention, loyalty and time spent, not ad revenue. Then define engagement metrics plus guardrails for quality, safety, fatigue and downstream banking experience.

Start from product intent. If the feed is not monetized by ads, the recommender should support retention, app engagement, loyalty and cross-product trust rather than pure click maximization. This changes the metric set.

Primary metrics can include sessions with feed, dwell time, return rate, meaningful interactions, likes, comments, shares, follows and bookmarks. But each engagement metric is gameable. Use guardrails such as hide/report rate, low-quality content rate, repeated-topic fatigue, notification churn, creator concentration, latency and impact on core banking journeys.

Define the decision surface too: ranking posts in a feed for about millions of users, hundreds of thousands of historical posts and a steady inflow of new posts. That scope determines freshness, cold-start and serving constraints.

Start with interaction history, user profile features and post content features: category, text embeddings, image embeddings and simple statistics. Combine collaborative and content baselines before training a heavier ranker.

Represent posts with both structured and unstructured features: topic/category, author, age, language, text length, text embedding, image embedding, moderation/safety flags and early engagement statistics that are available at serving time.

Represent users with recent interaction history, long-term topic preferences, followed authors, profile or segment features that are allowed for this product, and aggregated embeddings of posts they engaged with. For a bank app, treat sensitive features carefully and avoid using them without a clear policy and fairness review.

A practical baseline is a hybrid candidate generator such as LightFM or ALS with content features, plus popularity/freshness fallback. Then add a ranker that combines candidate score, user-post affinity, freshness, author features and engagement signals. The baseline should be simple enough to debug and strong enough to collect better logs.

Use impression logs, define weighted engagement or multiple heads, sample negatives from shown-but-not-engaged posts, and choose pointwise, pairwise or listwise loss based on maturity and labels.

The dataset should start from exposures: posts that were actually eligible and shown. Labels can be binary click/engagement, weighted engagement, dwell-time regression, or multiple targets for click, like, comment, share and hide. A single weighted target is simple; multi-task heads preserve differences between signals.

Negatives should usually include shown-but-not-clicked or skipped posts, because random unseen posts make the task too easy and distort ranking. You can add hard negatives from the same topic or similar embeddings to improve discrimination.

Pointwise losses are easiest to start with: binary cross-entropy for engagement probability or regression losses for weighted score. Pairwise/listwise losses better match ranking but require careful construction and are harder to debug. For social feeds, also monitor calibration by segment and exposure/popularity bias.

Use ANN over normalized post embeddings for scalable retrieval, cluster users only when personalization cost is too high, and introduce domain-specific encoders after a baseline proves where generic embeddings fail.

Vector search is useful when the item tower produces embeddings and the catalog is too large for brute-force scoring. Store text/image post embeddings in an ANN index such as HNSW, FAISS or a vector database, then measure recall@K, p95 latency, memory, update cost and downstream ranker quality. The similarity metric must match training: cosine for normalized embeddings, dot product if trained that way.

User clustering can reduce serving cost, but it trades personalization for efficiency. If you recommend at cluster level, define how the cluster vector or prototype user is built, how often clusters update, and how much quality drops for heterogeneous clusters. Often it is safer to use clusters for fallback pools or cache warmup, not as the only personalization mechanism.

Domain-specific text/image encoders should be introduced after observing errors: travel photos, restaurant posts and finance/investment posts may need different features. Start with pretrained embeddings plus lightweight adaptation, then consider separate encoders or expert routing by topic. Keep diversity and exploration metrics because stronger embeddings can still create narrow feedback loops.

Choose seed posts from the user history, retrieve similar posts per seed or per topic bucket, deduplicate and cap candidates, then send them to the ranker with user-context features.

Item-to-item retrieval needs user seeds. Pick recent or high-quality positive interactions from the user history: liked posts, long-dwell reads, follows or saved posts. To avoid one-topic collapse, bucket seeds by category or recency and cap how many seeds each bucket contributes.

For each seed, query a text/image embedding index or collaborative item-to-item model, then merge candidates. Deduplicate, remove already seen posts, apply freshness/safety/eligibility filters, and keep enough candidates for the ranker. The ranker then scores each candidate with the current user, post and context features.

This generator is strong for warm users and fresh content with good embeddings. It needs fallbacks for cold users, new topics and sparse histories: popularity, editorial/freshness pools, user-to-user by profile and exploration.

For new posts, use content embeddings, metadata and exploration buckets. For new users, use onboarding/profile/context, popularity by segment and controlled exploration until enough interaction history exists.

New posts have no interaction history, so represent them through content: text embedding, image embedding, topic/category, author, language, freshness and safety signals. Route them through freshness and exploration pools so the system can collect initial feedback without flooding users.

New users need fallbacks before history exists. Use onboarding interests if available, coarse profile/context segments that are allowed for the product, geo/time/device context, global or segment popularity, and user-to-user similarity from non-sensitive profile features. Then quickly update a short-term profile from early positive and negative interactions.

Cold start should be measured. Track coverage for new posts, time to first impressions, new-user engagement, hide/report rate and diversity. Keep exploration bounded so it learns without damaging user trust.

Use scheduled retraining plus monitoring triggers: data freshness, distribution drift, offline quality, online KPIs and model health. Different components can have different refresh cadences.

A feed recommender should not be trained once and left alone. User interests, post inventory, creators and product behavior drift constantly. The basic setup is a recurring training DAG that rebuilds features, trains models, validates metrics, publishes artifacts and keeps rollback versions.

Retraining cadence depends on component freshness. Popularity and freshness features may update hourly. Candidate indexes and embeddings may update daily. Heavier rankers may retrain weekly or when enough new data accumulates. Cold-start handling may require frequent incremental updates.

Monitor both ML and product signals: data freshness, row counts, feature distribution drift, missing values, offline recall/NDCG, online CTR/dwell/retention, hide/report rate, candidate coverage, latency and segment regressions. Metric-triggered retraining can help, but scheduled retraining is easier to reason about; combine both with validation gates.

Encode user/context and post text-image content into a shared space, train positives from engaged impressions against random, exposed and hard negatives, and optimize contrastive, triplet or sampled-softmax losses.

A two-tower recommender has a user tower and an item tower. The item tower can combine text and image encoders in a CLIP-like representation; the user tower can aggregate history, profile/context features and recent interactions. At serving time, user embeddings retrieve item embeddings via dot product or cosine similarity.

Positive pairs should come from meaningful interactions such as clicks with dwell, likes, saves, comments or follows. Negatives can include random items, shown-but-not-engaged impressions and hard negatives from the same topic or close embedding neighborhood. Hard negatives are useful because they force the model to distinguish plausible alternatives.

Loss choices include contrastive InfoNCE/sampled softmax, triplet loss, pairwise ranking losses or multi-task objectives that also predict engagement. If the same item encoder feeds both retrieval and ranking, make sure the training objective matches both uses or split the towers when objectives conflict.

Use ALS as a simple collaborative baseline when you have enough interactions. It is fast and interpretable, but weak for cold users/posts and content-only personalization.

ALS is a useful early baseline when the feed already has exposure and engagement logs. Convert views, clicks, likes, comments and saves into an implicit-feedback confidence matrix, factorize users and posts, and retrieve high dot-product posts for each user.

It is attractive because it is simple, scalable and debuggable. It can also provide one candidate generator alongside content and popularity generators.

Its limitations matter in social feeds: new posts and new users arrive constantly, semantic content is ignored unless you use a hybrid variant, and popularity/exposure bias can dominate. Regular retraining is needed because the interaction matrix changes as interests and inventory drift.