Training Data: What Is a Negative?
In one line: users tell you what they liked and never what they disliked, so every negative in your training set is one you invented, and how you invent them decides what the model learns.
The problem
A click is a positive. What is a negative?
An item the user did not click is the obvious answer and it is wrong, or at least ambiguous. From the RAG and evaluation chapters: an un-clicked item may have been seen and rejected, or never seen at all. Those are different signals collapsed into the same absence.
And a retriever has a worse version of the problem. It must learn to distinguish good candidates from the entire catalogue, but the log only contains items the current system decided to show — perhaps a hundred out of a million. The other 999,900 have no data whatsoever.
Three ways to construct negatives
In-batch negatives
For each user-item positive pair in a training batch, treat the other items in the batch as negatives for that user. Free — no extra sampling, no extra encoding — and it is the industry default for two-tower training.
Its bias is specific and worth knowing: items appearing in more batches are sampled as negatives more often, and the items appearing most are the popular ones. So in-batch negatives systematically over-penalise popular items, and the model under-ranks them.
Some implementations correct for this with a logit adjustment based on estimated sampling probability. Knowing the bias exists is the interview-relevant part.
A second limitation is that batch size caps the number of negatives, and batch size is bounded by memory — which is why cross-batch approaches that reuse encodings from previous batches exist.
Corpus-sampled negatives
Sample uniformly from the whole catalogue. These are genuinely random items, so they represent the distribution the retriever actually operates over — including the 999,900 nobody has seen.
Their weakness is that they are too easy. A random item is usually so obviously irrelevant that the model learns nothing from separating it. Training converges quickly to a model that is good at rejecting the obviously bad and mediocre at the distinctions that matter.
Mixed negative sampling — combining in-batch with uniformly sampled corpus negatives — is the production answer, and it has shown offline and online gains at large scale. The uniform samples correct in-batch's popularity bias; the in-batch ones keep the negatives relevant.
Hard negatives
Items that are plausible but wrong: same category, similar embedding, retrieved by the current system and not engaged with. These carry the most information, because separating them is the actual task.
They also carry the most risk, and it is worth being precise about why: a hard negative is often just an unlabelled positive. An item the user did not click may be one they would have loved and never noticed. Train on it as a negative and you teach the model to suppress exactly the items it should surface.
| In-batch | Corpus-sampled | Hard | |
|---|---|---|---|
| Cost | Free | Cheap | Requires mining |
| Difficulty | Moderate | Too easy | Highest information |
| Bias | Over-penalises popular items | None — matches the corpus | May be unlabelled positives |
| Role | The default backbone | Corrects popularity bias | Sharpens the decision boundary |
The practical recipe is all three: in-batch as the backbone, a fraction of uniform corpus samples to fix the popularity skew, and a small, carefully-chosen fraction of hard negatives.
Different stages need different negatives
The point that ties this to the cascade, and it is the one most often missed.
The retriever must separate good candidates from the whole catalogue. Its negatives should look like the catalogue — random, easy, plentiful.
The ranker only ever sees candidates that already survived retrieval and pre-ranking. Training it against random catalogue items teaches it a task it never performs.
So the ranker should be trained on logged impressions: items the pipeline actually surfaced, with what happened to them. That gives the right distribution and brings its own problem — those impressions carry position bias, which is the next lesson.
The feedback loop, again
Every negative-sampling choice is made from data the current system produced, which is the loop the foundations module named.
An item the system never shows is never a positive and never a hard negative — it is at best a random corpus sample. It has no chance to prove itself, and the model has no reason to start showing it.
The countermeasures are the ones already established: an exploration budget in candidate generation, and position-debiased training. They are not refinements. Without them the training data narrows every cycle, and the negative-sampling strategy accelerates it.
Key takeaway
Implicit feedback gives positives and never negatives, so every negative is constructed and the construction is a modelling decision. In-batch negatives are free and over-penalise popular items because popular items appear in more batches; corpus samples fix that bias and are too easy to learn much from; hard negatives carry the most information and are often unlabelled positives, so keep them few and prefer evidence of rejection over mere absence. Mix all three. And train each stage on the distribution it actually operates over — a ranker trained against random catalogue items has learned a task it will never perform.
Next: the bias baked into every logged impression.