0% completed
Where Training Data Comes From
On This Page
No Labels, No Learning
Human Labeling Is a System, Not a Task
The LLM in the Labeling Loop
Class Imbalance: Training on a 0.2% World
Manufacturing Negatives
Split Hygiene
A Short Word on Privacy
In the Interview
TL;DR
No Labels, No Learning
Supervised predictive designs need a label pipeline that pairs features with target outcomes. Other learning methods may not need explicit labels, but every design still needs evaluation data.
Candidates draw the training box and assume labels simply exist inside it. Interviewers know they do not, and they ask about it directly. Where do the labels come from? How late do they arrive? Who pays for them?
Explain which evidence supports each label. Fraud detection may use investigations and disputes; ranking may use clicks and reviewed relevance judgments; moderation may use policy-based reviews.
Three useful label sources have different costs, delays, and limitations.
1. Natural labels. An observed outcome supplies a target value, with logging and validation still required.
When a delivery completes, its recorded duration can become a label. A chargeback is a reversed card payment following a dispute; it is evidence to investigate, not automatic proof of fraud.
Outcome labels may avoid a separate annotation task, but collection and validation have costs. Delays vary: a delivery outcome may arrive in an hour, while a dispute may take weeks.
Label delay affects which examples are mature enough for training and when quality can be measured. It does not require waiting a full delay interval between training jobs.
2. Behavioral labels. User actions are used in place of judgments: clicks, skips, saves, watch time.
Behavioral labels can arrive quickly, although logging and processing still have costs.
But they are noisy, because a click is not the same thing as satisfaction. They are also biased, because you can only observe them on what the system chose to show. The data measures the current system almost as much as it measures the user.
3. Human annotation. Written guidelines, trained reviewers, and one judgment per item.
It is expensive, at cents to dollars per label. It is also slow, at hours to days.
Human review is useful when the target depends on a policy or judgment, such as relevance or harmful content. Reviewer decisions also need quality checks.
| Source | Cost | Latency | Main weakness |
|---|---|---|---|
| Natural outcomes (delivery time, chargeback) | Collection and validation costs | Minutes to weeks | Delayed or incomplete outcomes |
| Behavior (clicks, skips, saves) | Logging and processing costs | Often seconds | An indirect signal; biased toward what was shown |
| Human annotation (guidelines + reviewers) | Cents to dollars per label | Hours to days | Cost limits coverage; quality needs management |
Human Labeling Is a System, Not a Task
When a design needs annotation, do not say "we'll have humans label it" and move on.
Treat labeling as a subsystem with clear instructions, sampling, versioning, and quality checks.
Guidelines are versioned artifacts. A label means whatever the guideline document says it means, and nothing more.
So the guideline gets a version number, and that version is recorded in the dataset's lineage. Change the definition of "spam" and every metric computed across that boundary is quietly comparing different labels.
Inter-annotator agreement is one quality signal. Ask several reviewers to label the same items and measure agreement. Agreement alone does not establish correctness.
Low agreement may reflect unclear guidelines, difficult examples, missing context, or reviewer training. Investigate disagreement patterns before deciding how to improve the process.
Gold questions audit the reviewers. Seed the queue with items whose correct answers are already known.
Then track each reviewer's accuracy on them, continuously. This catches tiredness and drift without re-reviewing everything.
Cost per label drives sampling. At real prices, you cannot label all of the incoming data.
So you label where a label is worth the most. There are three usual choices.
- Predictions the model is least certain about.
- Cases where reviewers or models disagree.
- Slices where the product is newest.
The cheapest labeling pipeline is one the product already runs for other reasons.
The analyst queue in the fraud design also supplies potential labels. Record review context and uncertainty; an analyst's decision is not always a verified final outcome.
Validate and version those labels before using them in the process from Monitoring, Drift, and Retraining. Explain how review decisions become suitable training examples.
The LLM in the Labeling Loop
Behavioral signals can be biased, and human review can be costly. LLM-assisted labeling is another option to evaluate.
An LLM can propose labels using written guidelines. Compare its accuracy, throughput, privacy requirements, and total cost with other methods before using it at scale.
The production pattern is a hierarchy, not a full replacement of people.
Use the LLM only for eligible data and tasks. Have reviewers check a random sample and selected difficult or disputed cases. Define review capacity and a fallback when the model cannot provide a reliable label.
Evaluate performance against reviewed examples for each important subgroup. Agreement is useful, but reviewers and models may share mistakes.
Here is the difficult part. LLM labels carry the same weaknesses as the LLM that produced them.
Errors can be systematic and concentrated in particular dialects, specialist topics, or adversarial content. More generated labels do not necessarily remove those errors.
That is exactly where moderation and fraud problems live. So the audit slices stay human-labeled. Agreement gets measured again whenever the prompt, the model, or the policy changes.
Class Imbalance: Training on a 0.2% World
For an illustrative dataset, assume 0.2 percent of transactions are fraud: about one positive example for every 499 negative examples. Actual rates depend on the product and labeling process.
A highly imbalanced dataset can waste computation and make plain accuracy misleading. Whether training fails depends on the objective, model, and sampling strategy.
The standard fix is to downsample negatives. Keep every fraud case. Keep only a fraction of the legitimate transactions, say 1 in 10.
With this sampling ratio, the dataset is about ten times smaller and the positive share rises from 0.2 percent to about 2 percent.
Changing the class proportions can change the meaning of the output scores. Check and correct probabilities on data that reflects the serving population.
The scores must be recalibrated before anyone treats them as probabilities. Recalibration means adjusting the scores back to true real-world probabilities. The calibration deep dive in Design Ad Click Prediction covers exactly how.
The alternative is reweighting. Keep all the data, but count each positive example more heavily in the loss function. The loss function is the number the training process tries to make small.
That trades extra compute for skipping the resampling step.
Imbalance also breaks the most obvious metric. A model that predicts "legitimate" for every single transaction is 99.8% accurate, and completely useless.
That is why imbalanced problems are evaluated on precision and recall instead of plain accuracy. Precision asks how many of the flagged cases were really fraud. Recall asks how many of the real fraud cases were flagged. Offline Evaluation: Choosing the Metric treats that choice properly.
Manufacturing Negatives
Retrieval and recommendation logs often have many positive interactions but few reliable negative judgments.
Logs record what a user clicked. Nobody records the millions of items a user would never have clicked.
So to train a two-tower retrieval model, you must manufacture the negatives yourself. The choice of how matters. There are four options, and they are usually combined.
Random negatives. Sample items uniformly from the catalog.
Random items can be easy to distinguish from relevant items, so they may not teach the model to separate closely related candidates.
In-batch negatives. Inside each training batch, every other user's positive item is used as this user's negative.
In-batch negatives reuse items already loaded into the batch and can reduce sampling overhead. They still add computation, and some may be relevant to multiple users.
Popularity-corrected sampling. Popular items appear as in-batch negatives far too often, precisely because they are popular positives elsewhere.
So the sampling is corrected for how often each item appears. Without that correction, the model learns to score popular items lower simply because they are popular.
Hard negatives. These are the close cases. Items that were retrieved but not clicked, or close neighbors of the true positive.
A small number of them sharpens the exact boundary the retriever needs to learn.
A dataset containing only hard negatives can be biased or unstable. Include appropriate easier examples and validate the results.
Some hard negatives are items the user would have liked but did not choose this time. Using too many false negatives can harm training. Test the mixture rather than assuming one ratio always works.
💡 Explain how you sample negatives, account for item popularity, and check for false negatives. In-batch examples and a tested share of hard negatives are useful options, not a universal recipe.
Split Hygiene
How you split data into train, validation, and test decides whether your offline numbers mean anything at all.
Use temporal splits for any problem where time matters, and nearly every production problem does. Train on weeks 1 to 10, validate on week 11, test on week 12.
When evaluating future performance, a random split can train on observations later than the test examples. Use a temporal split for that evaluation goal. Other goals may require user- or entity-based splits.
Within each example, features must also be point-in-time correct. That means computed only from what existed at the prediction moment. Training vs Serving established this.
Then run the leakage checklist. Each item on it produces a model that looks brilliant offline and fails online.
- Features computed after the label moment. An aggregate like "merchant's fraud rate", computed over a window that includes the very transaction being predicted.
- Label-adjacent features. Fields that only get filled in because the outcome already happened. A refund flag or a case-resolution code, included in the feature set.
- Near-duplicates across splits. Duplicate documents or nearly identical examples across splits can inflate results. Whether the same user should appear in both depends on whether you are testing future behavior for known users or generalization to new users.
A Short Word on Privacy
Training data is user data. One deliberate paragraph in an interview covers it well.
Minimize PII at ingestion. PII means personally identifiable information. Use only the data needed for the task, restrict access, and set retention limits. Hashed identifiers can still be linkable and should not automatically be treated as anonymous.
Make deletion propagate. Define how deletion and retention policies apply to raw records, derived datasets, embeddings, and trained models. The exact obligations depend on the context; involve the responsible privacy and legal teams.
Versioned datasets, deletion tracking, and scheduled rebuilds can help. A rebuild schedule alone does not guarantee that every required copy has been removed.
Treat labels as sensitive in their own right. Think of a fraud verdict or a moderation decision attached to a person. For fields like those, "who can see the labels" is an access-control question, not an afterthought.
In the Interview
The 30-second answer (to "where does your training data come from?"): "I would identify outcome labels, behavioral signals, and human judgments, including their costs and delays. I would validate labels, join them with features available at prediction time, and choose a split that matches the evaluation goal. For imbalanced data, I would evaluate sampling and probability calibration. For retrieval, I would test negative-sampling strategies. LLM-assisted labels would be checked against reviewed examples."
Likely follow-ups:
- "Chargebacks take six weeks. How do you train this week?" Train on data old enough for its labels to have arrived, so the training window ends six weeks back. For recent data, use early proxies as provisional labels. Rule hits and analyst-queue decisions arrive in days. And accept that outcome monitoring runs six weeks late. That is why monitoring the score distribution matters when outcome labels arrive late.
- "Your annotators disagree 30% of the time. What do you do?" Treat it as a guideline bug before an annotator bug. Cluster the disagreements, sharpen the guideline with worked examples, re-version it, and measure agreement again. For the cases that are genuinely ambiguous, collect several judgments per item. Then train on the majority or on the distribution. Report agreement alongside the model metric.
- "Why not label everything with the LLM and drop the humans?" Because LLM errors are correlated. It is one model's weaknesses repeated a million times, and it is invisible from inside the system. Human-labeled audit slices are the ground truth that catches it. Disagreement and low-confidence cases still route to people. Agreement gets re-checked on every prompt, model, or policy change.
TL;DR
| Three sources | Outcomes: delayed and need validation. Behavior: fast but indirect. Human annotation: costly and needs quality controls. |
| Labeling ops | Versioned guidelines, inter-annotator agreement, gold-question audits; review queues also produce labels. |
| LLM labeling | LLM labels at scale, humans audit samples and disagreements; blind spots keep audit slices human. |
| Imbalance | Downsample negatives, then recalibrate scores (or reweight); accuracy alone is misleading at 0.2% positive. |
| Negatives | In-batch by default, popularity-corrected, a few hard ones; check hard negatives for bias and false negatives. |
| Hygiene | Temporal splits, point-in-time joins, dedupe across splits; minimize PII and propagate deletions to derived data. |
Reading Progress
0%
On This Page
No Labels, No Learning
Human Labeling Is a System, Not a Task
The LLM in the Labeling Loop
Class Imbalance: Training on a 0.2% World
Manufacturing Negatives
Split Hygiene
A Short Word on Privacy
In the Interview
TL;DR