What counts as a dataset?

Four dataset roles in a real product

Most AI products juggle more than one kind of data at once:

• Training data: Examples used to update model weights (fine-tuning, preference tuning, distillation).
• Retrieval corpus: Documents indexed for RAG. The model does not memorize them as weights, but they define what it is allowed to cite.
• Eval / golden sets: Held-out cases with known-good answers or rubrics. Used to decide whether a release is safe.
• Production logs: Live traffic. Not a dataset until someone filters, labels, and versions it for the next training round.

Calling everything "the dataset" blurs ownership. A support bot might have 8k fine-tune examples, 40k indexed help articles, 200 golden eval cases, and millions of raw chat logs. Only the first three are ready to use. The logs are raw material.

Raw material vs ready examples

Support tickets, call transcripts, PDFs, and database exports are not training data yet. They are sources. Turning them into examples means deciding what the input is, what the target output is, what to exclude, and what metadata to keep.

For LLM fine-tuning, a ready example usually has a stable shape: messages with roles, or prompt/completion pairs in JSONL. For classification, it might be text plus a label. For preference tuning, chosen and rejected completions tied to the same prompt. For RAG, chunked passages with source IDs and access controls.

Schema matters early. If one row stores the user question in input and another in messages[1].content, your pipeline will break silently or produce uneven training signal.

Collection strategies

Where examples come from shapes what the model can do:

• Human-written: Highest control, highest cost. Good for policy-heavy tasks and refusal behavior.
• Logged and filtered: Cheapest at scale if you already have traffic. Needs PII scrubbing and quality filters.
• Expert or vendor labeling: Domain specialists or annotation vendors turn raw cases into labels. Cost is often $0.50–$5+ per example depending on task complexity and review rounds.
• Active learning: Ship a model, log failures and low-confidence cases, label those first. Puts budget where the model is weakest.
• Stratified sampling: Deliberately oversample rare intents (fraud escalation, medical edge cases) instead of hoping random sampling catches them.

Scraping public web text is a different beast. Consent, terms of use, robots.txt, and PII at collection time all matter. A corpus that is legally or ethically risky is not cheaper because it was free to download.

Training data is not product data

Product data is what users actually send at runtime: messy, partial, sometimes adversarial. Training data is what you chose to show the model during adaptation. They should overlap in shape, not necessarily in content.

If training examples always include a polished system prompt and clean JSON, but production users paste walls of unstructured text, the model will look worse live than offline evals suggest. If eval cases are written by engineers and production users spell differently, slice metrics will lie.

Golden sets should be representative of product risk, not of what was easy to label. That often means pulling real (consented, redacted) failures into eval, not only writing synthetic happy paths.

Quick check