Free sample lesson · LLM-Native Recommendation Systems

How traditional recommendation systems use feature engineering

Lesson 1 of the Wondering course LLM-Native Recommendation Systems

Recommendations Before Deep Learning

Traditional recommendation systems do not learn raw behavior directly. Engineers translate messy user activity into numbers a model can read.

That translation step is called feature engineering.

Every click, pause, and replay must become a column of values. Humans decide which columns matter.

From raw activity to a ranked list
  • Raw logs: The system records clicks, plays, and pauses as raw user activity.
  • Hand-crafted signals: Engineers decide which numbers to extract from that activity.
  • Feature store: The computed signals are stored so models can read them.
  • Ranking: The model uses those columns to score and order items.

What A Feature Store Is

A feature store is the shared warehouse for these engineered signals.

Each row is usually a user or an item. Each column is one computed signal, refreshed on a schedule.

A feature store row, simplified

Teams read from the same store during training and during live serving, so the model sees consistent numbers in both places.

Hand-Crafted Signals In Practice

The classic examples are simple to describe.

Watch time captures how long a user stays with an item. Genre affinity captures how strongly a user leans toward comedy or documentaries. Time-of-day captures when someone usually watches.

Each one is a human guess about what predicts interest.

Three classic hand-crafted signals
  • Watch time: How long a user stays with an item.
  • Genre affinity: How strongly a user leans toward a genre.
  • Time-of-day: When someone usually watches.
  • Human guess: Each signal is a human guess about what predicts interest.

Signals Are Designed, Not Found

Nothing in the raw logs says "genre affinity". Someone defined it.

That definition includes choices: which window of history counts, how to weight a partial view, what to do with a brand new user.

Those choices live in code that must keep running correctly.

A signal is only as good as the reasoning behind it.

Who decides what counts as interest?

Why Thousands Of Features Hurt

Mature systems do not carry three signals. They carry thousands.

Every one needs a pipeline, a refresh schedule, monitoring, and an owner. When a pipeline silently breaks, the model keeps serving with stale numbers.

The cost is not the math. The cost is the maintenance.

Keeping one feature alive
  • Pipeline runs: A refresh schedule recomputes the signal.
  • Monitoring check: An owner watches whether the values look right.
  • Pipeline healthy?
  • Model serves: The model reads fresh numbers.
  • Stale numbers: The model keeps serving with old values.
  • needs repair

Three Signals Versus Thousands

Scale changes the nature of the problem.

With a handful of signals, one engineer can reason about all of them. With thousands, no single person knows what every column means or whether it still helps.

Ownership spreads thin, and unused features rarely get deleted.

A few features or thousands
  • A handful
  • Thousands

What To Carry Forward

Traditional recommenders depend on human-defined signals stored in a feature store.

Watch time, genre affinity, and time-of-day show how ordinary the individual signals are. The difficulty appears at scale.

Thousands of features mean thousands of pipelines to run, monitor, and own. That operational weight is the real limitation.

The lesson in three levels
  • Operational cost: Thousands of pipelines to run, monitor, and own.
  • Feature store: The shared warehouse holding every computed signal.
  • Hand-crafted signal: One human-defined number such as watch time.

Each level rests on the one below

Check yourself

Traditional recommendation systems usually convert user activity into engineered numeric signals before a model uses it.

  • True
  • False

Answer: True

Correct. Traditional systems do not learn directly from raw behavior; engineers translate activity such as clicks, pauses, and replays into model-readable values through feature engineering.

A user’s viewing duration is represented by _____, a tendency toward comedy is represented by _____, and a usual viewing hour is represented by _____.

Answer: A user’s viewing duration is represented by watch time, a tendency toward comedy is represented by genre affinity, and a usual viewing hour is represented by time-of-day.

Watch time measures how long a user stays with an item, genre affinity measures a user’s preference for a genre, and time-of-day captures when the user usually watches.

Why is “genre affinity” considered a designed signal rather than something directly found in raw logs?

  • An engineer defines how activity is converted into that measure.
  • The model automatically discovers its exact meaning without code.
  • It is a fixed field produced by every user interaction.
  • It records only the title of the most recently watched item.

Answer: An engineer defines how activity is converted into that measure.

Raw logs contain behavior such as clicks or viewing activity, but they do not inherently contain a field named “genre affinity.” Engineers define how to calculate it, including which history counts and how behavior is weighted.

Keep going

This is lesson 1 of 8 in LLM-Native Recommendation Systems. Next up:

  1. What context engineering means in LLM-native systems
  2. Designing compact, high-information prompts
  3. Two-phase training: foundation adaptation vs. task fine-tuning
  4. Balancing ranking, language modeling, and alignment objectives
  5. Data efficiency advantages of foundation models

Start this course free

Wondering turns any topic into short lessons you can read, watch, or listen to, with practice questions and an AI tutor.