Building the Relevance Layer for the AI World
Every product surface that matters is, at its core, a relevance problem. A feed decides what to show you next. A marketplace decides which listings to rank. A search box decides which results actually answer your query. Increasingly, even LLM applications depend on retrieval to ground their answers in the right context.
For most of my career, from the Applied ML group at Meta to leading PyTorchVideo at FAIR, I worked on systems where the model was only as good as the data it could retrieve and rank. That insight is what led to Shaped.
Relevance is infrastructure, not a feature
Teams often treat ranking as something to bolt on later. In practice, it’s the single biggest lever on engagement and conversion. A recommendation system that adapts in real time to user behavior consistently outperforms static heuristics, but building one in-house means owning:
- Feature pipelines that stay fresh as behavior changes
- Embedding and candidate-generation infrastructure
- A ranking layer that can be retrained continuously
- Low-latency serving under production load
That’s a lot of undifferentiated heavy lifting for most teams.
What changes with LLMs
Retrieval-augmented generation made one thing obvious: the quality of an AI product is bounded by the quality of its retrieval. The same relevance machinery that powers recommendations and search is what grounds an LLM in the right facts. The disciplines are converging.
The best AI products won’t be the ones with the biggest models. They’ll be the ones that retrieve the right information at the right moment.
Where we’re headed
At Shaped, we’re building real-time personalization that any team can deploy quickly, across feeds, search, and notifications, and extending it into the retrieval layer that AI applications increasingly depend on.
If you’re working on something in this space, reach out. I’d love to compare notes.