Use Synthetic and Teacher Data Carefully

Section 1: The Practical Outcome First

In specialized domains like Site Reliability Engineering, production failure data is severely unbalanced. Common events — such as intermittent HTTP 504 timeouts or routine pod restarts — occur millions of times in production logs. But critical, catastrophic failures — such as an etcd split-brain quorum loss or cross-region BGP route flapping — may occur only once or twice a year.

If you train exclusively on historical logs, your fine-tuned model will never learn to diagnose high-severity edge cases. Using frontier teacher models (such as GPT-4o, Claude 3.5 Sonnet, or Llama 3.1 70B) to generate synthetic variations bridges this data gap.

However, unconstrained synthetic data is toxic. Frontier models hallucinate fictional runbook numbers, invent non-existent configuration flags, and produce repetitive, sterile phrasings that degrade model capability over time.

Look at the filtering pipeline for an evolved synthetic candidate:

[Prompt Evolution Input]
Seed Incident: Postgres primary connection pool exhaustion (cluster-03).
Mutation Strategy: Constraint Deepening (Add network partition & multi-hop dependency).

[Raw Teacher Generation (Unfiltered)]
Candidate Response:
{
  "subsystem": "database",
  "severity": "P1",
  "root_cause_hypothesis": "Connection pool saturated by unindexed batch export during network flap",
  "recommended_runbook": "RB-CUSTOM-MADE-UP-RUNBOOK-99",  <-- HALLUCINATED RUNBOOK!
  "safety_escalation": false,
  "rationale": "Pool at 100% capacity with 4200ms latency spike across cluster-03."
}

[Programmatic Verification Pipeline]
Gate 1 (JSON Schema Syntax): PASS (Valid JSON, all required fields present)
Gate 2 (Entity & Catalog Registry): FAIL!
  -> Runbook "RB-CUSTOM-MADE-UP-RUNBOOK-99" NOT found in approved SRE catalog.
  -> Rejection triggered. Candidate purged from dataset.

[Filtered & Accepted Candidate (After Correction)]
Runbook mapped to verified catalog: "RB-DB-POOL-MITIGATION-02"
Gate 2 (Entity & Catalog Registry): PASS
Gate 3 (Telemetry Grounding): PASS (Rationale links to "4200ms" and "pool" from prompt)
Type-Token Diversity Check: PASS (TTR = 0.800 > 0.50 threshold)
Outcome: Verified training example committed with synthetic provenance metadata.

---

Section 2: Synthetic Generation and Prompt Evolution

Simple prompting (“Generate 100 incident tickets”) yields superficial, repetitive outputs. To create high-value training demonstrations, production pipelines use Evol-Instruct (Xu et al., 2023).

The Evol-Instruct multi-path prompt mutation and multi-tier verification pipeline

Read this diagram as text

A seed incident undergoes evolutionary mutation across three paths: constraint deepening, breadth expansion, and multi-hop reasoning. The resulting candidate completion must pass three programmatic verification gates before being accepted into the training set.

The Three Mutation Paths

1. Constraint Deepening: Take an existing incident prompt and inject realistic production constraints: “Rewrite this Postgres alert such that read replicas are also unresponsive, and connection pooling cannot be restarted without causing an API gateway cascading failure.”
2. In-Breadth Expansion: Create analogous incident scenarios in neighboring technological domains: “Given this Redis connection exhaustion incident, generate a structurally analogous failure in a high-throughput Apache Kafka cluster experiencing partition lag.”
3. Multi-Hop Reasoning: Combine multiple disparate operational symptoms into a single root cause: “Generate an incident where an authentication token expiry storm initially manifests as high compute CPU utilization, masquerading as a backend compute capacity failure.”

---

Section 3: Model Collapse and The Curse of Recursion

The most dangerous pitfall of synthetic data is Model Collapse.

In a landmark Nature study, Shumailov et al. (2024) proved mathematically and empirically that when language models are trained recursively on model-generated data, the learning process enters an irreversible degeneration loop.

Why Collapse Occurs

Let p_0(x) represent the authentic production data distribution. When teacher model M_1 samples synthetic data, it draws from its learned distribution q_1(x).

Because sampling cannot perfectly cover the distribution, low-probability events in the tails of p_0(x) (the rare 1-in-a-million incident edge cases) are sampled with diminishing probability:

Var_{q_n}(X) < Var_{q_{n-1}}(X) < ... < Var_{p_0}(X)

Across successive training generations:

1. Early-Stage Collapse: The model loses the tails of the distribution. It forgets rare failure modes, bizarre network edge cases, and nuanced operational policies.
2. Late-Stage Collapse: The distribution collapses into a point mass. The model outputs repetitive, stereotypical phrases and degenerate sentence fragments.

In production

The Anchoring Heuristic (Recursive vs. One-Off Teacher Generation): Distinguish between recursive multi-generation self-training (where Model n trains on outputs from Model n-1, which Shumailov et al. 2024 proved causes progressive variance loss when real data is discarded) and one-off teacher generation (where a strong frontier or 70B teacher generates candidate examples for a smaller student). Even in one-off teacher generation, ungrounded synthetic data drifts from production telemetry distributions. As a practical engineering heuristic for our SRE pipeline, we anchor the training corpus with 30% to 50%+ authentic human-verified production traces (75.0% in our 8-record Module 2 reference lab) so gradient updates stay grounded in real operational telemetry.

Monitoring Diversity: Type-Token Ratio (TTR)

To catch lexical mode collapse before weights are corrupted, monitor the Type-Token Ratio across equal-length synthetic batches (note that raw TTR decreases naturally as total word count N grows by Heaps’ Law, so compare TTR across fixed token window sizes such as 200-word windows or use MATTR):

TTR = | Vocabulary (Unique Words) | / Total Word Tokens

In fixed 200-word windows of operational notes, TTR typically ranges between 0.65 and 0.85. If a fixed-window synthetic batch drops below an illustrative operational warning threshold of TTR = 0.50, inspect the teacher prompts for repetitive boilerplate clichés.

---

Section 4: Multi-Tier Programmatic Verification Gates

Never trust raw teacher outputs. Every synthetic generation must pass three deterministic software verification gates before entering the training manifest:

Gate 1: Deterministic Schema Validation

The completion must parse to the strict operational Pydantic schema:

• Must be valid JSON without markdown wrapping.
• Must contain all required keys: subsystem, severity, root_cause_hypothesis, recommended_runbook, safety_escalation, and rationale.
• severity must strictly equal "P1" | "P2" | "P3".

Gate 2: Entity & Registry Grounding

Frontier models love to invent plausible-sounding names. If an incident recommends runbook "RB-ETCD-HEAL-QUORUM-99", but your infrastructure runbook repository only contains "RB-ETCD-QUORUM-RECOVER-05", the model has hallucinated.

Gate 2 performs an exact set-membership lookup against verified engineering catalogs:

• recommended_runbook in APPROVED_RUNBOOKS
• subsystem in {"database", "network", "storage", "compute", "auth"}

Any candidate referencing unapproved entities is immediately rejected.

Gate 3: Telemetry Grounding

A model must not guess root causes out of thin air. Gate 3 enforces that the generated rationale must explicitly cite concrete metric terms, latency values, or hostnames present in the prompt. If the prompt discusses a 4200ms latency spike, the rationale cannot claim a memory OOM kill without evidence.

---

Section 5: Legal Governance and Terms of Service

When utilizing commercial frontier models as teacher generators, data governance teams must audit commercial service agreements:

1. The “No Competing Models” Clause

Most commercial API providers include contractual restrictions on using outputs to train competing models. For example, the OpenAI Services Agreement (Section 3.3(e)) and Terms of Use restrict using outputs to “develop models that compete with OpenAI.”

Engineering Interpretation (Requires Legal Review for Your Use Case):

• Whether a downstream domain-specific model is deemed “competing” is a contractual and legal question rather than a purely technical distinction; always obtain legal review before training on commercial API outputs.
• For unrestricted commercial and open-weights workflows, generate synthetic data using permissive open-weights teachers (such as Apache-2.0 Qwen/Qwen2.5-72B-Instruct, or meta-llama/Llama-3.1-70B-Instruct under the Llama 3.1 Community License, which permits using outputs to train derivative models within the 700M MAU limit provided derivative model names begin with “Llama” and preserve attribution).

2. Provenance Metadata Contract

Every accepted synthetic training example must be tagged with complete lineage metadata:

{
  "example_id": "syn-ops-4091",
  "provenance": {
    "is_synthetic": true,
    "seed_incident_id": "INC-2026-9041",
    "teacher_model": "llama-3.1-70b-instruct",
    "mutation_type": "constraint_deepening",
    "verification_gates": {
      "schema_parse": true,
      "entity_registry_match": true,
      "telemetry_grounding": true
    },
    "human_curator_signoff": "curator_ops_712",
    "license_classification": "internal_proprietary"
  }
}

---

Section 6: Worked Code Example & Verifier Walkthrough

The companion script scripts/verify-synthetic-data.py implements the multi-tier verification pipeline, catalog whitelist checking, and Type-Token Ratio diversity scoring.

6.1 Multi-Tier Verification Implementation

def verify_synthetic_completion(
    candidate: SyntheticIncidentCandidate,
) -> Tuple[bool, List[str], Optional[Dict[str, Any]]]:
    rejection_reasons = []

    # Gate 1: JSON Schema Parse Gate
    try:
        data = json.loads(candidate.teacher_completion)
    except json.JSONDecodeError as e:
        rejection_reasons.append(f"Gate 1 Failed: Malformed JSON syntax ({str(e)})")
        return False, rejection_reasons, None

    # Gate 2: Entity & Taxonomy Grounding
    if data["subsystem"] not in VALID_SUBSYSTEMS:
        rejection_reasons.append(f"Gate 2 Failed: Hallucinated subsystem '{data['subsystem']}'")

    if data["recommended_runbook"] not in APPROVED_RUNBOOKS:
        rejection_reasons.append(
            f"Gate 2 Failed: Hallucinated runbook '{data['recommended_runbook']}' not in approved catalog"
        )

    # Gate 3: Telemetry Grounding
    prompt_lower = candidate.prompt_text.lower()
    rationale_lower = data["rationale"].lower()
    keywords = ["latency", "pool", "exhaustion", "cpu", "memory", "packet", "timeout", "cluster", "etcd", "quorum"]
    found_in_prompt = [kw for kw in keywords if kw in prompt_lower]
    found_in_rationale = [kw for kw in found_in_prompt if kw in rationale_lower]

    if not found_in_rationale:
        rejection_reasons.append("Gate 3 Failed: Rationale lacks grounding in prompt telemetry keywords")

    is_accepted = len(rejection_reasons) == 0
    return is_accepted, rejection_reasons, data if is_accepted else None

6.2 Running the Verifier

Run the verifier script to test candidate filtering and diversity scoring:

python3 scripts/verify-synthetic-data.py

Expected output:

=== Running Topic 07: Synthetic Data & Teacher Verification ===
[*] Candidate 1 Valid: True (Reasons: [])
[*] Candidate 2 Valid: False (Reasons: ["Gate 2 Failed: Hallucinated runbook 'RB-CUSTOM-MADE-UP-RUNBOOK-99' not in approved catalog"])
[*] Candidate 3 Valid: False (Reasons: ['Gate 1 Failed: Malformed JSON syntax (...)'])
[*] Synthetic Sample Type-Token Ratio (TTR): 0.800
=== All Topic 07 Verifications Passed Cleanly ===

6.3 Module 2 Exit Lab Walkthrough (labs/track3/02-data-curation/)

To complete the Module 2 Exit Artifact, execute the integrated 8-record reference curation pipeline in labs/track3/02-data-curation/:

python3 labs/track3/02-data-curation/curate_dataset.py

This script combines Lessons 4–7 into a single checkable local pipeline:

1. Scrubs IPv4 addresses, corporate emails, high-entropy secrets, and conversational chatter across 8 incident records (6 human, 2 synthetic = 75.0% human anchor ratio).
2. Validates every completion against the IncidentTriageExample schema, APPROVED_RUNBOOKS, and telemetry keyword grounding rules from scripts/verify-synthetic-data.py.
3. Performs group-aware splitting by cluster_id across all human and synthetic records with 0.0% cluster overlap across Train (5 records), Validation (1 record), and Test (2 records), writing labs/track3/02-data-curation/training_dataset_manifest.json.
4. Emits an integer-ID ChatML loss mask trace to labs/track3/02-data-curation/loss_mask_inspection.json (label = -100 on prompt tokens, token_id = 151645 supervised on <|im_end|>), accompanied by the unsigned audit template labs/track3/02-data-curation/DATA_CURATION_AUDIT.md.

---

Key takeaways

• Synthetic data bridges the gap for rare, high-severity domain edge cases (e.g. split-brain outages) that occur infrequently in historical logs.
• Evol-Instruct expands seed demonstrations across three paths: constraint deepening, breadth expansion, and multi-hop reasoning.
• Model collapse occurs when recursive training on synthetic data causes distribution tail probabilities to evaporate, leading to mode collapse and linguistic degeneration.
• Always anchor synthetic training sets with at least 30-50% authentic human-verified production examples, and monitor Type-Token Ratio (TTR > 0.50).
• Enforce multi-tier programmatic verification gates (schema parsing, entity catalog matching, and telemetry grounding) to reject teacher hallucinations.
• Audit commercial terms of service restrictions (e.g. no competing model development) and maintain immutable provenance metadata for every synthetic example.

Try it yourself

1. 01A team generates 20,000 synthetic incident reports from GPT-4o and trains an 8B model. In testing, the model repeatedly outputs "All systems normal, investigation ongoing" regardless of input. What happened?

   Show a hint

   The dataset lacked anchoring in authentic failure data and suffered model collapse. The generator mode-collapsed into generic uninformative responses.

2. 02Calculate the Type-Token Ratio (TTR) for a synthetic completion containing 160 total words, of which 96 words are unique.

   Show a hint

   TTR = 96 / 160 = 0.60. This is above the 0.50 warning threshold, indicating healthy lexical diversity.

3. 03Explain why a whitelist lookup against an internal runbook repository (Gate 2) is necessary when distilling knowledge from frontier teacher models.

   Show a hint

   Frontier models confidently hallucinate runbook IDs and API commands that do not exist in reality. Grounding filters prevent baking hallucinated procedures into weights.

4. 04Under what conditions does using commercial frontier API outputs violate provider terms of service during model training?

   Show a hint

   Training and distributing an open-weights foundation model intended to compete directly with the frontier provider violates terms like OpenAI Section 2(c)(iii). Internal task-specific routing usually does not.

Interview questions

What is model collapse, and how does it manifest during recursive language model fine-tuning?

Model collapse (Shumailov et al., Nature 2024) is a degenerative process where models trained recursively on synthetic data lose information about the true underlying distribution. Early-stage collapse manifests as a reduction in distribution variance where rare tail events are forgotten. Late-stage collapse causes complete mode collapse where output degenerates into repetitive, low-diversity tokens.

How does Evol-Instruct create higher-quality training demonstrations than naive few-shot generation?

Evol-Instruct applies systematic mutations to seed prompts: deepening constraints (adding complex failure conditions), broadening breadth (transferring failure patterns across technologies), and increasing reasoning hops. This forces the teacher model to generate multi-step diagnostic reasoning rather than generic surface-level summaries.

What programmatic verification checks should be applied to synthetic data before adding it to an SFT corpus?

A three-tier verification harness: (1) Schema validation to ensure syntactically valid JSON matching Pydantic contracts; (2) Entity registry lookup to reject hallucinated runbooks, APIs, or hostnames; and (3) Telemetry grounding to verify that the rationale directly cites metrics, errors, and symptom terms present in the input prompt.

Why must synthetic training datasets maintain an anchoring ratio of authentic human demonstrations?

Purely synthetic datasets drift away from empirical production distributions. Retaining a minimum of 30-50% authentic human-verified demonstrations anchors gradient updates to true production realities, preserving linguistic nuance and preventing synthetic mode collapse.

Related lessons

• Fine-Tuning & Domain-Specific Models · Decide Whether to TrainDiagnose the Gap Before Changing Weights12 min
• Fine-Tuning & Domain-Specific Models · Decide Whether to TrainSelect a Base Model for the Task13 min
• Fine-Tuning & Domain-Specific Models · Decide Whether to TrainSet a Baseline and Success Threshold12 min
• Fine-Tuning & Domain-Specific Models · Make Training Data TrustworthyTurn Real Tasks Into Training Examples14 min
• Fine-Tuning & Domain-Specific Models · Make Training Data TrustworthyFormat Conversations and Mask the Loss13 min
• Fine-Tuning & Domain-Specific Models · Make Training Data TrustworthySplit, Deduplicate, and Audit the Dataset13 min