Data for RAG vs Training

"Prepare the data for AI" means two very different things depending on whether the data will be retrieved or learned from. A RAG corpus is evidence the model quotes at answer time; a training set is experience the model absorbs into its weights. Exams love this distinction because the preparation disciplines barely overlap — and applying the wrong one is a classic architecture mistake.

Curating a RAG corpus

A retrieval corpus is judged on trustworthiness per chunk, because whatever is retrieved gets quoted as fact. Curation rules:

• Authoritative sources only — the approved policy library, not the draft folder or an employee's personal notes. One wrong-but-plausible document poisons every answer it reaches.
• Deduplication — near-duplicate documents fill the retrieval window with repetition and crowd out genuinely relevant evidence.
• Versioning — supersede, don't accumulate. When policy v3 lands, v2 must leave the index (or be marked historical), and lineage metadata records which version answered which question.

The payoff: a RAG corpus updates in minutes through the ingestion pipeline, needs no labels, and mistakes are correctable by fixing a document.

Constructing a training set

Fine-tuning data is judged on coverage and balance, not per-document authority. You need labeled examples — input paired with desired output — in the hundreds to thousands. Two disciplines matter most:

• Class balance — if 95% of examples are "approve," the model learns to say "approve." You must oversample rare classes or curate deliberately, or the model inherits the skew.
• Held-out evaluation sets — split off test data before training and never train on it. Without a held-out set you cannot distinguish learning from memorisation, and you cannot prove to a review board that the model works. Leaking test data into training is the cardinal sin.

Training data also inherits stricter governance: PII baked into weights cannot be redacted later, and a wrong training example requires retraining, not a document fix.

Synthetic data and labeling strategies

Synthetic data — examples generated by a model — fills gaps real data can't: rare edge cases, privacy-safe stand-ins for citizen records, or volume when labeled examples are scarce. The risks: it mirrors the generator's biases, drifts from real-world distribution, and models trained mostly on model output degrade. Use it to augment real data and always evaluate on genuinely real held-out examples.

For labeling, the pragmatic enterprise pattern is LLM-assisted labeling with human review: a strong model (say, Claude or Azure OpenAI) drafts labels cheaply, then humans verify — reviewing is far faster than labeling from scratch, and sampling-based QA keeps quality measurable. Humans remain accountable for the labels; the LLM is a productivity tool, not the authority. Exam shorthand: RAG data is curated evidence; training data is balanced, labeled, held-out-tested experience — and never confuse the two pipelines.