Synthetic Datasets¶

TL;DR

• Use synthetic data to bootstrap before launch and fill rare slices after launch. Treat it as a silver label tier until a human verifies it.
• Force diversity structurally: generate inputs in stages (dimensions → tuples → scenario → query), with two LLM calls (scenario, then query) and realistic user personas.
• Ground generation in your artifacts: use document chunks or knowledge graphs for RAG, JSON schemas for tool calls, and database execution for Text-to-SQL.
• Over-generate by 2× and filter aggressively. Unfiltered synthetic questions are usually too easy, copy exact phrases from chunks, or contain wrong reference answers.

• What you will learn:
  • When synthetic data helps and when it misleads you
  • How to run the dimensions → tuples → scenario → query pipeline
  • Chunk-based and knowledge-graph RAG generation (RAGAS and DeepEval Synthesizer)
  • Back-translation recipes for tool-calling and Text-to-SQL datasets
  • How to generate adversarial guardrail variants with benign twins
  • Automatic quality filters and human spot-check rules
  • How to check a synthetic set against real traffic
• Prerequisites: Dataset Strategy
• Related guides:
  • SME Golden Datasets
  • Production Data Flywheel
  • Threat Model & OWASP

1. When synthetic data helps (and when it doesn't)¶

Default rule: Mark synthetic rows as label_tier: "silver" (Dataset Strategy §2.2). Promote a synthetic row to gold only after a human expert reviews it.

2. A practical generation pipeline¶

flowchart TD
    S["Sources: docs, chunks, DB schema, tool specs, seed examples, prod queries"] --> P["Plan coverage: dimensions, query types, personas, roles"]
    P --> C["Select context: single chunk, related chunk sets, KG paths, tables"]
    C --> G["Generate input + expected output + reference contexts"]
    G --> E["Evolve: harder, multi-context, constrained, edge cases"]
    E --> F["Automatic filters: schema, dedup, answerability, groundedness, round-trip, critic score"]
    F --> H["Human spot-check sample"]
    H -->|"reject rate too high"| P
    H --> V["Versioned silver dataset with provenance"]
    V --> R["Run evals; compare with golden and prod slices"]
    R -->|"gaps or too easy"| P

Two steps matter more than any prompt trick:

1. Plan coverage first: Diversity comes from your tuple plan, not from turning up the LLM temperature.
2. Filter aggressively: Quality comes from rejecting bad generations, not from expecting 100% perfection on the first prompt.

Always record generation metadata on every synthetic row:

{
  "source": "synthetic",
  "label_tier": "silver",
  "generator": {"method": "kg_multi_hop_specific", "model": "<generator-model-id>", "prompt_version": "qa-gen-v4", "seed": 17},
  "tuple": {"intent": "hr_policy", "query_type": "comparative", "persona": "new_hire_verbose", "user_role": "employee"},
  "evolutions": ["multi_context", "constrained"],
  "filters_passed": ["answerability", "groundedness", "dedup", "critic>=0.7"],
  "reviewed_by": null,
  "source_chunks": ["hr-travel-emea#c12", "hr-travel-us#c07"],
  "doc_versions": {"hr-travel-emea": "2026-05-10", "hr-travel-us": "2026-02-01"}
}

3. Dimensions, tuples, scenarios, queries¶

If you prompt an LLM to "write 50 questions about our HR policy," you will get 50 nearly identical, polite, single-fact questions. Break homogeneity by generating inputs in four steps:

1. Define dimensions: intent, query_type, persona, user_role, and language.
2. Sample tuples: Pick specific combinations like ("hr_policy", "comparative", "new_hire_verbose", "employee") (Dataset Strategy §4.2).
3. Generate a concrete scenario first: Ask the LLM to describe a specific situation in 2 sentences.
4. Generate the user query second: Ask the LLM to write the exact chat message that persona would type in that scenario.

Splitting scenario generation and query generation into two calls makes synthetic queries much more realistic:

SCENARIO_PROMPT = """You are helping test an internal enterprise assistant.
Write ONE realistic scenario (2-3 sentences) for this combination:
- intent: {intent}
- query type: {query_type}
- user persona: {persona}
- user role: {user_role}
The scenario must be answerable ONLY from the provided document excerpts (unless query type is 'unanswerable').
Excerpts:
{context}
Return JSON: {{"scenario": "..."}}"""

QUERY_PROMPT = """Given this scenario, write the exact message the user would type into a chat box.
Match the persona's style (length, tone, typos, language). Do not copy phrases from the excerpts verbatim.
Scenario: {scenario}
Persona: {persona}
Return JSON: {{"query": "..."}}"""

Use contrasting personas so your dataset tests more than polite textbook English:

4. QA pairs from chunks or documents (RAG)¶

The fastest way to build a RAG benchmark is to pick a document chunk and ask an LLM to write a question and reference answer from that chunk.

What you get automatically:

• reference_contexts (the source chunk ID), which unlocks Context Recall, Recall@k, Hit Rate@k, and MRR.
• reference_answer and key_facts, which unlock Answer Correctness.

QA_FROM_CHUNK_PROMPT = """You write evaluation questions for an internal company assistant.
Excerpt (doc_id={doc_id}, chunk_id={chunk_id}):
\"\"\"{chunk}\"\"\"

Write ONE question a {persona} employee might realistically ask whose answer is fully contained in the excerpt.
Rules:
- Do NOT reuse distinctive phrases from the excerpt; paraphrase as a real user would.
- The question must make sense WITHOUT seeing the excerpt (no "according to the text").
- Then write a concise reference answer (1-3 sentences) using only the excerpt,
  and list 1-4 atomic key facts.
Return JSON: {{"question": "...", "reference_answer": "...", "key_facts": ["..."]}}"""

How to pick chunks for generation:

To generate multi-hop questions, pair two chunks that are related but not near-duplicates (for example, cosine similarity between 0.55 and 0.85). Then prompt the generator to write a question that needs facts from both chunks. These thresholds depend on the embedding model. Calibrate them: read about 20 pairs at several similarity levels and pick the band where pairs share a topic but say different things.

import numpy as np

def related_chunk_sets(chunks, embed, k=2, sim_lo=0.55, sim_hi=0.85, cross_doc_only=False):
    """For each chunk, yield up to k partners that are related in topic but not near-duplicates.
    `embed` (app-provided) maps a list of texts to an (n, d) array."""
    vecs = np.asarray(embed([c.text for c in chunks]), dtype=float)
    vecs /= np.linalg.norm(vecs, axis=1, keepdims=True)         # cosine = dot product
    sims = vecs @ vecs.T                                          # O(n^2) memory: use an ANN index above ~20k chunks
    np.fill_diagonal(sims, -1.0)
    seen = set()
    for i, a in enumerate(chunks):
        ok = (sims[i] >= sim_lo) & (sims[i] <= sim_hi)
        if cross_doc_only:
            ok &= np.array([c.doc_id != a.doc_id for c in chunks])
        candidates = np.flatnonzero(ok)
        for j in candidates[np.argsort(-sims[i, candidates])][:k]:   # the k most similar partners in the band
            pair = (min(i, j), max(i, j))
            if pair not in seen:
                seen.add(pair)
                yield a, chunks[j], float(sims[i, j])

Pairs from the same document are kept by default, because many multi-hop questions combine two sections of one policy. Set cross_doc_only=True for cross-document questions. Tested with synthetic embeddings: every pair is inside the band, each chunk has at most k partners, and a near-duplicate chunk is never paired.

5. Knowledge-graph-based generation (RAGAS)¶

RAGAS solves multi-hop generation by building a knowledge graph over your chunks first. It links chunks that share entities, keyphrases, or high embedding similarity, then walks paths in the graph to generate questions:

flowchart LR
    D["Documents"] --> SP["Split into nodes: documents and chunks"]
    SP --> EX["Extractors: headlines, keyphrases, entities, summaries, embeddings"]
    EX --> RB["Relationship builders: entity overlap, embedding similarity"]
    RB --> KG["Knowledge graph"]
    KG --> SC["Scenarios: nodes + persona + query style + length"]
    SC --> QS["Query synthesizers"]
    QS --> OUT["Samples: user_input, reference_contexts, reference"]

RAGAS provides built-in synthesizers for different hop counts and specificity levels:

# Illustrative: check current RAGAS API for your installed version
from ragas.testset import TestsetGenerator
from ragas.testset.persona import Persona
from ragas.testset.synthesizers import (
    SingleHopSpecificQuerySynthesizer,
    MultiHopAbstractQuerySynthesizer,
    MultiHopSpecificQuerySynthesizer,
)

personas = [
    Persona(name="New hire", role_description="Recently joined, unfamiliar with internal terms, asks long questions."),
    Persona(name="Finance analyst", role_description="Expert in expense policy, asks terse precise questions."),
]

generator = TestsetGenerator(llm=generator_llm, embedding_model=generator_embeddings, persona_list=personas)
query_distribution = [
    (SingleHopSpecificQuerySynthesizer(llm=generator_llm), 0.5),
    (MultiHopSpecificQuerySynthesizer(llm=generator_llm), 0.25),
    (MultiHopAbstractQuerySynthesizer(llm=generator_llm), 0.25),
]
testset = generator.generate_with_langchain_docs(docs, testset_size=100, query_distribution=query_distribution)
df = testset.to_pandas()   # Columns: user_input, reference_contexts, reference, synthesizer_name

Older RAGAS tutorials (0.1.x). Many blog posts still show the RAGAS 0.1 API. It used evolutions (simple, reasoning, conditioning, multi-context, and conversational) instead of synthesizers: from ragas.testset.evolutions import simple, reasoning, multi_context, then generator.generate_with_langchain_docs(documents, 10, distributions={simple: 0.5, reasoning: 0.1, multi_context: 0.4}). The v0.1.21 docs say this design was inspired by Evol-Instruct. This API does not exist in RAGAS 0.2 and later. Do not mix the two.

Other generators.

Whichever tool you use, apply the filters in §10 to its output.

6. Query evolution and edge-case generation¶

6.1 Evol-Instruct-style evolution¶

First-pass synthetic questions are often too simple. Use query evolution (inspired by WizardLM Evol-Instruct) to rewrite a simple seed question into a harder one:

6.2 DeepEval Synthesizer¶

DeepEval's Synthesizer automates query evolution and quality filtering. To keep evolved questions strictly answerable from your documents, use MULTICONTEXT, CONCRETIZING, CONSTRAINED, and COMPARATIVE evolutions:

# Illustrative: check current DeepEval API
from deepeval.synthesizer import Synthesizer, Evolution
from deepeval.synthesizer.config import EvolutionConfig, FiltrationConfig

synth = Synthesizer(
    evolution_config=EvolutionConfig(
        evolutions={
            Evolution.MULTICONTEXT: 0.25,
            Evolution.CONCRETIZING: 0.25,
            Evolution.CONSTRAINED: 0.25,
            Evolution.COMPARATIVE: 0.25,
        },
        num_evolutions=2,
    ),
    filtration_config=FiltrationConfig(synthetic_input_quality_threshold=0.6),
)
goldens = synth.generate_goldens_from_docs(
    document_paths=["policies/travel_emea.pdf", "policies/travel_us.pdf"],
    include_expected_output=True,
)

6.3 Edge-case and adversarial generation for RAG¶

Generate edge cases on purpose so your benchmark tests how the agent handles messy reality:

def near_miss_unanswerable(question: str, entity: str, corpus_index) -> dict | None:
    """Swap an entity for one not covered in the corpus, then verify via search.
    llm_json, answers_question and corpus_index are app-provided helpers."""
    replacement = llm_json(f"Suggest a plausible alternative to '{entity}' in this question that a company "
                           f"policy might not cover. Question: {question}. Return {{\"alt\": \"...\"}}")["alt"]
    new_q = question.replace(entity, replacement)
    hits = corpus_index.search(new_q, k=10)
    if any(answers_question(new_q, h.text) for h in hits):
        return None  # Corpus actually answers it -> discard
    return {"question": new_q, "answerable": False, "expected_behavior": "abstain",
            "derived_from": question}

7. Synthetic data for tool calling and text-to-SQL¶

Tool calls and SQL queries are machine-checkable. Use back-translation (start from a valid tool call or SQL query, then generate the user question) so your expected labels are valid by construction.

7.1 Tool-calling data¶

flowchart LR
    TS["Tool schemas"] --> AC["Sample a target call: tool + valid args"]
    AC --> NL["LLM writes a user request implying exactly that call"]
    NL --> VAL["Validate: args satisfy schema; request mentions or implies each required arg"]
    VAL --> RT["Round-trip: a different model predicts the call from the request"]
    RT -->|"matches"| KEEP["Keep"]
    RT -->|"differs"| REV["Human review: ambiguous request or bad label"]

1. Sample a valid target call from your JSON Schema (for example, create_ticket(category="hardware", priority="high", summary="Laptop screen flickering")).
2. Back-translate into a user message: Ask an LLM to write a natural user message that implies those exact arguments without using the raw parameter names.
3. Run a round-trip check: Have a second, independent LLM predict the tool call from the generated message. If it predicts the exact same call, keep the row; if it disagrees, send the row to human review.
4. Generate negative tool rows: Drop a required argument from the user prompt to test whether the agent asks a clarifying question instead of hallucinating the missing argument.

7.2 Text-to-SQL data (schema-grounded)¶

Use SQL → Question back-translation to guarantee every gold_sql query executes cleanly:

1. Generate or sample a SQL query over your warehouse schema covering specific SQL features (JOIN, GROUP BY, HAVING, window functions, date filters).
2. Execute the SQL against your frozen test database. Discard any query that errors, returns 0 rows, or returns more than 1,000 rows.
3. Ask an LLM to write the business question that the SQL query answers, using business terms instead of raw column names.
4. Run a round-trip execution check: Have an independent baseline model generate SQL from the question and compare the returned result tables. If the baseline SQL fails, flag the row for review; do not crash the run.

from collections import Counter

SQL_FEATURES = ["single_table_filter", "join_2", "join_3", "group_by_having", "date_range",
                "window_function", "subquery", "top_k", "null_handling"]

def results_match(rows_a, rows_b, order_matters=False, float_tol=1e-6):
    """Compare two result tables by value. Column names are ignored; column order is not. Floats are rounded to float_tol."""
    def norm(row):
        return tuple(round(v / float_tol) * float_tol if isinstance(v, float) else v for v in row)
    a, b = [norm(r) for r in rows_a], [norm(r) for r in rows_b]
    if len(a) != len(b):
        return False
    if order_matters:                                  # set True when gold_sql has ORDER BY
        return all(x == y for x, y in zip(a, b))
    return Counter(a) == Counter(b)                    # multiset: duplicate rows count

def synth_sql_example(schema, db, feature, persona):
    # llm_json, text_to_sql_baseline and db.execute_readonly are app-provided helpers
    sql = llm_json(f"Write a realistic analytics SQL query over this schema using feature '{feature}'. "
                   f"Schema:\n{schema}\nReturn {{\"sql\": \"...\"}}")["sql"]
    try:
        result = db.execute_readonly(sql, timeout_s=10)
    except Exception:
        return None                                   # Invalid SQL -> discard
    if len(result) == 0 or len(result) > 1000:
        return None                                   # Empty or huge results make poor tests
    question = llm_json(f"Write the question a {persona} business user would ask that this SQL answers. "
                        f"Use business terms, not column names.\nSQL:\n{sql}\nReturn {{\"question\": \"...\"}}")["question"]
    try:
        sql2 = text_to_sql_baseline(question, schema)
        ok = results_match(db.execute_readonly(sql2, timeout_s=10), result,
                           order_matters="order by" in sql.lower())
    except Exception:
        ok = False                                    # Baseline SQL failed -> a human decides
    return {"question": question, "gold_sql": sql, "expected_result": [list(r) for r in result],
            "features": [feature], "review_flag": "auto_ok" if ok else "needs_review",
            "db_id": db.snapshot_id}

results_match compares values, not column names, and treats rows as a multiset unless the gold SQL has ORDER BY. Tested with SQLite and a stubbed LLM: matching results, a failing baseline, an invalid gold query, an empty result, row order, float tolerance, and duplicate rows.

8. Synthetic guardrail and red-team test cases¶

Guardrail test sets need hundreds of examples to measure low miss rates. Use the Seed → Mutate → Benign Twin pipeline:

flowchart LR
    SEEDS["Seed attacks by category"] --> MUT["Mutation operators"]
    MUT --> VAR["Attack variants"]
    VAR --> TWIN["Generate benign twins"]
    TWIN --> LAB["Label: block or allow, category, severity"]
    LAB --> SET["Guardrail eval set"]

8.1 Seed → mutate → pair¶

Start with seed attacks across your threat model (Threat Model & OWASP), apply mutation operators (translation, Base64/leetspeak encoding, payload splitting, markdown/JSON wrapping, authority claims), and generate a benign twin for every attack:

Count families, not variants. Mutations of one seed are strongly correlated. If 300 variants come from 10 seeds, the guardrail has seen about 10 independent attacks, not 300. The Rule of Three bound (Dataset Strategy §5.2) uses the number of independent attack families as $n$. Report recall per family and per category, and the false-positive rate on benign twins.

8.2 Tools for automated red-teaming¶

Instead of writing mutation scripts from scratch, use established open-source red-teaming tools:

• promptfoo red teaming: Generates attack plugins (injections, PII leaks, RBAC probes, multi-turn jailbreaks) tailored to your application prompt.
• NVIDIA garak: Automated LLM vulnerability scanner with built-in attack probes.
• Microsoft PyRIT: Python Risk Identification Toolkit for single-turn and multi-turn red teaming.

9. Multi-turn persona simulation¶

Fixed multi-turn scripts break whenever the assistant asks a different follow-up question on turn 2. Solve this with a user simulator LLM that role-plays a persona pursuing a specific goal:

sequenceDiagram
    participant Sim as User simulator LLM
    participant App as Assistant under test
    participant Judge as Evaluator
    Sim->>App: Opening message from scenario and persona
    App-->>Sim: Reply, possibly with tool calls
    loop until goal met, stop signal, or max turns
        Sim->>App: Next message in persona
        App-->>Sim: Reply
    end
    App-->>Judge: Full transcript, tool calls, final state
    Judge-->>Judge: Score goal completion, correctness, retention, policy

Give the user simulator a persona, a goal, and hidden_facts that it reveals only when the assistant asks for them:

SIMULATOR_SYSTEM = """You are role-playing a USER of an internal company assistant. Never act as the assistant.
Persona: {persona}
Your goal: {goal}
Facts you know (reveal only when asked or natural): {hidden_facts}
Behavior:
- Write like the persona (length, tone, typos).
- Don't volunteer all details up front.
- If the assistant asks a question, answer it consistently with your facts.
- When your goal is achieved or clearly impossible, reply exactly: <END>.
"""

10. Quality control¶

Unfiltered synthetic datasets often contain many bad rows: questions that copy the chunk word-for-word, questions that make no sense without the chunk, or wrong reference answers. A common practitioner heuristic is 20–40% bad rows before filtering. This is not a measured constant. It depends on the generator, the prompts, and the domain, so measure your own rate with the spot-check in §10.2. Generate 2× as many rows as you need and filter them automatically.

10.1 Automatic filters¶

import numpy as np

def cosine(u, v) -> float:
    u, v = np.asarray(u, dtype=float), np.asarray(v, dtype=float)
    return float(u @ v / (np.linalg.norm(u) * np.linalg.norm(v)))

def lexical_overlap(question: str, chunk: str) -> float:
    q = question.lower().split()
    c = chunk.lower().split()
    if len(q) < 3:
        return 0.0
    trigrams_q = {tuple(q[i:i+3]) for i in range(len(q) - 2)}
    trigrams_c = {tuple(c[i:i+3]) for i in range(len(c) - 2)}
    return len(trigrams_q & trigrams_c) / max(1, len(trigrams_q))

def near_duplicates(items, embed, threshold=0.9):
    """Greedy dedup in input order. `embed` (app-provided) maps one text to a vector."""
    kept, vecs = [], []
    for it in items:
        v = embed(it["question"])
        if all(cosine(v, u) < threshold for u in vecs):
            kept.append(it); vecs.append(v)
    return kept

10.2 Human spot-check¶

Always inspect a random sample of 30–50 filtered synthetic rows by hand:

1. Count how many rows you reject (unrealistic question, wrong reference answer, or too easy).
2. If your human rejection rate exceeds 15%, fix your generation prompts and filters instead of hand-editing individual rows.
3. Promote a synthetic row to label_tier: "gold" only if a domain expert verifies its reference answer.

10.3 Validate the synthetic set against reality¶

Once you have production traffic, compare your synthetic dataset against real user queries:

• Score gap. If your system scores 95% on synthetic data but 70% on production samples, your synthetic questions are too clean or have too much keyword overlap with your chunks.
• Coverage. Embed real and synthetic queries and cluster them together. List the clusters that have real queries but no synthetic ones. These are topics or phrasings your generator misses.
• Classifier two-sample test (C2ST). Train a classifier to tell real queries from synthetic ones (Lopez-Paz & Oquab, 2017). A cross-validated AUC near 0.5 means the sets are hard to tell apart. An AUC near 1.0 means the synthetic set looks different. Read the queries the classifier is most sure are synthetic to see why.
• Ranking agreement. Score 3–5 system versions on both sets. If the synthetic set ranks them in a different order from the production sample (check with Kendall's $\tau$, Kendall, 1938), do not use it to pick between versions.

import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import cross_val_score

def c2st_auc(real_vecs, synth_vecs, seed=0):
    """Classifier two-sample test on query embeddings.
    AUC near 0.5 = hard to tell apart. AUC near 1.0 = the synthetic set looks different."""
    n = min(len(real_vecs), len(synth_vecs))            # balance the two classes
    rng = np.random.default_rng(seed)
    X = np.vstack([rng.permutation(np.asarray(real_vecs))[:n],
                   rng.permutation(np.asarray(synth_vecs))[:n]])
    y = np.r_[np.zeros(n), np.ones(n)]
    clf = LogisticRegression(max_iter=1000)
    return cross_val_score(clf, X, y, cv=5, scoring="roc_auc").mean()

Tested with random vectors: two samples from the same distribution give AUC ≈ 0.46; shifting one dimension of the synthetic set gives AUC ≈ 0.84. Embedding-based tests can miss differences in tone or length that the embedding model ignores, so also compare simple features such as query length and the share of typos.

11. Risks¶

12. End-to-end pseudo-code¶

# Pseudo-code: every helper except lexical_overlap and near_duplicates (§10.1) is app-provided.
def build_synthetic_rag_set(corpus, plan, budget: int):
    rows = []
    for tup in sample_tuples(plan.dimensions, n=int(budget * 2)):          # Over-generate ~2x
        ctx = select_context(corpus, tup)                                   # Single chunk, related pair, or none
        if tup["query_type"] == "unanswerable":
            row = make_unanswerable(corpus, tup)                            # Near-miss + full-corpus search check
        else:
            scenario = llm_json(SCENARIO_PROMPT.format(**tup, context=ctx.text))["scenario"]
            q = llm_json(QUERY_PROMPT.format(scenario=scenario, persona=tup["persona"]))["query"]
            ref = llm_json(REFERENCE_PROMPT.format(question=q, context=ctx.text))  # Answer + key_facts
            row = {"question": q, **ref, "reference_contexts": ctx.ids, "answerable": True}
        if tup.get("evolve"):
            row = evolve(row, ctx, kinds=["multi_context", "constrained", "concretizing"])
        row["metadata"] = {"tuple": tup, "source": "synthetic", "label_tier": "silver",
                           "doc_versions": ctx.doc_versions, "generator": GEN_INFO}
        rows.append(row)

    # Apply automatic quality filters
    rows = [r for r in rows if passes_schema(r) and is_standalone(r["question"])]
    rows = [r for r in rows if answerability_ok(r, corpus)]
    rows = [r for r in rows if reference_grounded(r)]
    rows = [r for r in rows if lexical_overlap(r["question"], joined_text(r)) < 0.3]
    rows = [r for r in rows if round_trip_ok(r, independent_model)]
    rows = near_duplicates(rows, embed, threshold=0.9)
    rows = rebalance_to_plan(rows, plan, budget)

    # Human spot-check gate
    sample = random_sample(rows, k=min(50, len(rows)))
    report = human_review(sample)
    if report.reject_rate > 0.15:
        raise RuntimeError(f"Fix generation pipeline: {report.top_reasons}")
    return version_and_save(rows, report)

Key takeaways¶

• Synthetic data is a fast silver tier for cold start and rare slices, but it never replaces SME golden data or real production traces.
• Generate diversity via structure (dimensions → tuples → scenario → query), not via sampling temperature.
• Use back-translation for structured tasks: start from a valid tool call or executed SQL query, then generate the user question.
• Over-generate by 2× and filter for standalone wording, answerability, low keyword overlap, deduplication, and round-trip consistency.
• Check the synthetic set against reality with a score gap, cluster coverage, a classifier two-sample test, and ranking agreement.
• Count attack families, not mutations, when you bound a guardrail's miss rate.

Further reading¶

• RAGAS, Testset Generation Concepts
• DeepEval, Golden Synthesizer and Conversation Simulator
• RAGAS 0.1 (legacy), Testset Generation with evolutions
• Giskard, RAGET testset generation
• distilabel and NVIDIA NeMo Data Designer
• Xu et al., WizardLM (Evol-Instruct)
• Lopez-Paz & Oquab, Revisiting Classifier Two-Sample Tests (2017)
• Panickssery et al., LLM Evaluators Recognize and Favor Their Own Generations
• Red teaming tools:
  • promptfoo red team
  • NVIDIA garak
  • Microsoft PyRIT
• Next in this section: Production Data Flywheel