Key takeaways
Traditional batch processing builds a reliable recommendation baseline but fails to capture real-time shifts as user behavior changes and new content is continuously published.
Modern recommendation engines translate content properties and historical user interactions into mathematical embedding vectors to calculate context and intent.
Deploying inference at the edge allows systems to instantly refine baseline recommendations using immediate session behavior and real-time context.
Minimizing operational latency is critical because even a technically accurate recommendation loses its value if it arrives too late to match immediate user intent.
Recently, NVIDIA CEO Jensen Huang argued that even in an AI-assisted world, original thought and personal taste retain real value. Taste, in this context, is the ability to recognize quality, distinguish signal from noise, and choose the right output from many choices. Can that ability one day be reduced to algorithms?
While philosophers have been debating that possibility for two decades, recommendation systems have been trying to figure out the answer.
Today, machines can pick up on the preferences of users, as well as the characteristics of available content . With that information, a recommendation engine will guess, in real time, what a user wants next based on what it knows about them and what’s available.
For a news app, streaming platform, retailer, or social feed, this is not a one-time task. The catalog keeps changing, user behavior shifts from one session to the next, and the system has only a brief window to make a relevant choice.
That means recommendation quality depends on how quickly systems can incorporate new information and make decisions at scale.
The recommendation problem
Imagine that we run a news app. Every day, thousands of new articles arrive. Millions of readers log in, each with different interests, reading habits, and reasons for showing up.
The challenge: Narrow all that content down to a small set of articles, videos, or products that are most likely to matter to each person. (For simplicity in this blog post, we’ll use “article” and “content” synonymously.)
In recommendation-system language, that means finding the top-K — the most relevant articles for a given user — whether it needs to provide 50 in a feed or 20 on a search result page.
Formally:
Finding the Top-K articles means selecting the most relevant recommendations for a given user
The formula looks simple on paper. The hard part is estimating relevance well enough to make that choice quickly, across a huge volume of content and behavior that keeps changing.
That’s the problem that a recommendation system is built to solve.
Giving content a taste profile
Before a recommendation system can learn what a user likes, it needs a way to understand the characteristics of each piece of content. For example, consider a news article about AI, economics, Taiwan, and data centers. To a reader, those topics are context clues about the type of story they’re going to read. To a machine, however, the article needs to be translated into something it can compare against other articles.
Modern semantic encoders make this possible by translating content into vectors, or lists of numbers that represent its characteristics. That representation is called an embedding: a vector that captures patterns in an article’s meaning, topics, relationships to other content, and latent characteristics that keywords alone may not reveal.
That news article might be represented as an embedding like this:
An article can be represented as a vector that captures its content characteristics
Behind the scenes, those numbers give the system a consistent way to compare one piece of content with another. Articles with similar subjects, themes, or language tend to appear closer together in the shared vector space.
Visually, the process looks like this:
Article A -----> [Embedding Vector]
Article B -----> [Embedding Vector]
Article C -----> [Embedding Vector]Modeling user taste
Learning article vectors is relatively straightforward. A semantic encoder can read an article and map its characteristics into an embedding.
But how do we learn user taste?
A user’s taste can also be represented as a vector
We can’t feed a human being into an encoder. A person’s interests show up through behavior over time: what they click on, read, skip, share, save, or come back to later.
To complicate matters further, those signals are incomplete and can change quickly. Someone who has spent the past week reading about AI and data centers, for instance, may be focused on breaking news today.
As a result, the system has to infer taste from behavior.
We are what we read
There’s a saying in nutrition science: We are what we eat.
Recommendation systems use a similar principle: Users are what they read. A user's taste can be estimated from their historical interactions with content.
Some examples include:
Clicked articles
Articles read completely
Time spent reading
Articles shared
Articles bookmarked
Topics or formats returned to over time
Not every signal carries the same meaning. A quick click may show curiosity. Reading an article to the end, saving it for later, or sharing it may point to stronger interest. Recency matters, too. Even if a user has followed one topic for months, they may be more interested in something new that happened this morning.
One way to formulate a user’s taste profile is:
User taste can be estimated by weighting the articles with which a user has had interaction
Here, each article a user interacts with contributes to their overall taste vector. The engagement weight reflects how meaningful that interaction was.
Over time, the system builds a dynamic representation of what the user is likely to care about, based on both longer-term interests and more recent behavior.
How recommendation systems match users to content
At this point, the system has both a vector for the user and for each article. And because both live in the same vector space, the system can compare them.
One common way to score that match is with a dot product.
A dot product can score how closely a user’s taste vector matches an article vector
The score shows how well a user’s taste matches a given article. Many recommendation systems first normalize the vectors, which puts them on the same scale. The dot product can then show how closely the two vectors point in the same direction, similar to cosine similarity.
Building a baseline recommendation set
Many recommendation systems use batch processing to build an initial set of assessments.
At set intervals, often overnight, the system processes the previous day’s activity. It looks at what users clicked, read, shared, or saved; updates their taste profiles; and identifies the articles most likely to be relevant to each person.
A typical daily workflow looks like this:
Yesterday's Logs
↓
Feature Generation
↓
Taste Vector Computation
↓
Top-K Generation
↓
Recommendation CacheThis approach gives the system a reliable baseline. It can process a large volume of user behavior and content data at once, then store a set of likely recommendations in a cache so they’re ready when a user opens the app.
For many use cases, this is a practical place to start. The system has a recent picture of each user’s interests, a set of ranked articles, and a fast way to return recommendations.
The challenge? “Recent” can become outdated quickly.
Why batch recommendations go stale
Today's world doesn’t wait 24 hours. Two things — user taste and content space — change continuously.
A user may spend the morning reading about AI, GPUs, and data centers, but then rapidly shift topics if a major news story breaks. Their longer-term interests still matter, but their current session might tell the system something new.
The content catalog changes just as quickly. New articles and videos are constantly being published, sometimes just minutes or seconds before a user arrives. That type of content doesn’t exist in yesterday’s batch computation, so the system can’t recommend it if the cache hasn’t caught up.
It’s scenarios like these in which batch processing starts to fail in a world where freshness matters. When user behavior changes and new content enters the queue, the vector space itself is moving. It needs a way to respond without waiting for the next overnight job.
Using edge inference for real-time content recommendations
The daily batch still has a job to do. It gives the system a first-order estimate: a baseline set of top-K recommendations based on historical behavior and the latest full refresh.
Edge inference can then refine that baseline with signals the batch job missed. A news app or website may already know what the user read today, what they clicked on during the current session, and what content was published after the batch cutoff.
With newer content encoded and indexed for faster lookup, the system can compare an updated user taste vector against a more current set of candidates and return top-K edge recommendations that better reflect what is happening now.
In practice, this creates a two-step recommendation flow:
The batch system generates a reliable starting point.
The edge layer refines the result using more current user and content signals.
Akamai EdgeWorkers can help run the last adjustment closer to the user, while Akamai Object Storage can hold supporting files that the recommendation workflow needs, such as content metadata, index snapshots, or other recommendation data. That gives the application a way to update recommendations with current behavior, newly available content, and real-time context before sending the response back.
Processing data closer to users reduces network round-trip times and ensures that recommendations remain fast and relevant.
Why recommendation quality depends on latency
A recommendation is only useful if it arrives at the right moment, and that’s why the edge matters. When the final decision-making step happens closer to the user, the application doesn’t have to send every request back to a centralized cloud region before deciding what to show. It can adjust the baseline set to be closer to the moment the response is created.
For recommendation systems, that can mean:
Lower latency
More recent recommendations
Stronger regional relevance
Less unnecessary backhaul
More real-time adaptation
As recommendation workloads scale, teams also have to think about where data moves and where real-time decisions happen. Keeping more of that work closer to users can reduce unnecessary return trips to centralized cloud regions while helping applications respond faster.
A technically accurate recommendation can still feel stale if it arrives too late, ignores new content, or misses current intent.
For modern recommendation systems, the question is how quickly the system can turn its understanding of taste into a relevant response.
At that point, recommendation quality becomes an infrastructure question. The system is no longer just asking, “What does this user usually like?” Instead, it’s asking, “What is most relevant right now, and how quickly can we return it?”
Turning taste into real-time relevance
Recommendation systems have spent decades trying to answer a surprisingly human question: What do you like? Vectors, embeddings, and real-time inference give machines a way to model that question mathematically, but the goal is still familiar. The better the system can understand taste, update that understanding, and act on it in the moment, the more relevant the experience becomes.
Lab exercise
To see these ideas in practice, explore Akamai’s open source AI-curated feed template. It uses recommendation-system concepts to generate a personalized newsletter based on content signals and user preferences.
Tags
