Machine Learning At Scale

Machine Learning At Scale

The $22K Neural Search Pipeline That Was Silently 7 Days Behind [Edition #6]

Learn how switching to HNSW indexing and quantized vector search can slash inference costs by 61 percent while eliminating a 7 day content lag for 5 million daily users.

Ludovico Bessi's avatar
Ludovico Bessi
Apr 25, 2026
∙ Paid

The System

Briefly.ly is a late-stage Series B newsletter aggregator that recently hit 5M Daily Active Users. They have successfully aggregated over 2,000 premium newsletters and provide a unified feed for discovery.

Their engineering team built a neural retrieval system that powers the personalized Discovery Tab. Here is their setup.

Architecture Overview

When a user opens the Discovery Tab, the frontend sends a request to the Feed Service.

Traffic patterns:

5.2M Daily Active Users

Average: 125 req/sec

Peak: 850 req/sec

The ML Pipeline:

A Two-Tower (Bi-Encoder) model. The User Tower produces a 128-dimension embedding based on user history. The Item Tower embeds newsletter articles. The model is trained once a month on a static 6-month-old snapshot of engagement data (clicks and read-time) in H1.

A team of 4 engineers runs heuristics for the ranking and deduplication layer to patch-fix issues.

Current performance:

End-to-end Latency: 210ms (p99)

Reliability: 99.92% Uptime

Business impact metric: CTR is flat at 3.2% for the last four months.

Costs:

EC2 (Inference + FAISS nodes): $18,400/month

DynamoDB: $4,200/month

Total: $22,600/month

Recent incidents:

OOM on Vector Node: The FAISS index exceeded memory during a weekly Sunday rebuild, causing a 4-hour recommendation outage.

Stale Content Complaints: Users reported seeing “Breaking News” from three days ago at the top of their feed every Monday morning.

The Analysis

Machine Learning At Scale is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Now let me show you what’s actually happening here.

Critical Issue #1: Massive Temporal Training Mismatch

Look at the training data window in the architecture overview. They are training in H2 using a static snapshot from H1.

In the newsletter world, topics shift weekly. A model trained on June data has no concept of the current geopolitical or tech trends. By the time the model “learns” a topic is interesting, that topic is already six months out of date. The embeddings being generated for new articles are being forced into a latent space that only understands the past.

Critical Issue #2: The Sunday Staleness Spike

The architecture specifies the FAISS index is refreshed weekly on Sundays. For a content aggregator, this is architectural malpractice. A newsletter published on Monday morning will not be discoverable via vector search until the following Sunday. This explains the “flat” engagement; you are effectively running a “Yesterday’s News” service for 6 out of 7 days a week.

Critical Issue #3: Self-Reinforcing Feedback Loop

The ML pipeline notes that the model is trained on engagement data “sourced from production logs of this specific system.” Because the retrieval system only surfaces what the weekly FAISS index contains, the only data being logged is for those specific items. The model is being trained to get better at predicting clicks on the limited, stale subset it already knows how to show. It is impossible for the model to learn that users might like fresh content because it never shows them any.

Critical Issue #4: Popularity Bias Masked as Relevance

The architecture mentions “Dot product similarity with no frequency normalization.” In two-tower models, the magnitude of the item embedding often correlates with its frequency in the training set. Because they use a 6-month window of clicks, the “head” content (the most popular newsletters) develops massive vector magnitudes. These “super-nodes” will always have the highest dot product regardless of the user tower’s state, turning a “personalized” system into a simple “most popular” list.

Critical Issue #5: Operational Bloat for Rule-Sets

They have 4 FTEs (Full Time Engineers) just for manual override rule-sets. Because the model fails to surface fresh or relevant content (due to the weekly index and stale training), the team has built a massive “Heuristics Engine” on top of the output to manually boost new content. They are paying for a neural system but actually running a manual curation shop.

WHAT I’D DO INSTEAD

User's avatar

Continue reading this post for free, courtesy of Ludovico Bessi.

Or purchase a paid subscription.
© 2026 Ludovico Bessi · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture