Why “correct answer, wrong source” is a real problem
In retrieval-augmented generation (RAG), it’s possible for an LLM to produce an answer that is factually correct while citing the wrong document. This is more than a cosmetic issue. If your system is used for support, compliance, analytics, or public-facing content, a mismatched citation breaks verifiability, reduces trust, and makes debugging nearly impossible. It also hides retrieval regressions: the model “looks fine” until someone checks the evidence.
Synthetic Q&A loop testing is a practical way to detect this failure mode at scale. The idea is simple: generate (or curate) questions with known ground-truth sources, run them through your full RAG pipeline, then score both answer correctness and citation correctness. When these diverge, you’ve found a retrieval-path problem, not necessarily a generation problem.
What synthetic Q&A loop testing looks like in practice
A synthetic loop has four stages that run continuously (nightly, per deploy, or per index update):
1) Build a controlled evaluation set
You need question–evidence pairs where the “right” source is known. The most reliable approach is to create the dataset from your own corpus: pick a passage, generate a question that can be answered only from that passage, and store the passage identifier as the expected citation. If multiple passages legitimately support the answer, store an allowed set rather than a single ID.
Keep the set diverse: short factual queries, multi-hop questions, ambiguous terms, and “near-duplicate” topics where the wrong doc looks tempting. This is where synthetic data shines: you can deliberately create difficult contrasts, like two docs that both mention a product feature but only one specifies the constraint that matters.
2) Run the exact production retrieval path
Evaluation should use the same embedding model, chunking rules, query rewriting, hybrid retrieval (if any), reranker, filters, and caching behavior you use in production. If you test a simplified pipeline, you won’t catch the mismatches that come from real query transforms or routing logic.
3) Score answer quality and citation quality separately
Most teams only measure whether the answer “looks right.” For this problem, you need two independent scores:
- Answer correctness: Does the response match the ground truth?
- Citation correctness: Do the cited chunks actually contain the supporting claim?
When the answer is correct but citation is wrong, you’ve likely got leakage (the model knows the fact) or a retrieval/reranking bug where the right evidence was available but not cited, or not retrieved at all.
4) Feed failures back into retrieval, not just prompting
The most common anti-pattern is trying to “prompt away” citation problems. If the model is producing good answers with bad evidence, the retrieval layer needs attention: chunking, canonical IDs, query rewriting, reranking features, filtering rules, or how citations are selected from the context window.
How to detect wrong-source citations reliably
There are three practical checks that work well together:
Claim-to-evidence alignment
Break the answer into atomic claims, then verify each claim is supported by at least one cited chunk. This can be automated with an LLM-as-judge, but you’ll get better stability if you also store “supporting spans” (small snippets) alongside each chunk so the evaluator can match text more deterministically.
Citation coverage
Even if the citation is from the right document, it may not support the specific claim (e.g., citing an intro paragraph). Track a coverage metric: how many claims are supported by the cited spans. Low coverage often indicates chunk boundaries are wrong or that your citation selection is using similarity to the question rather than support for the answer.
Source exclusivity tests
For a subset of tests, design questions where only one document can answer correctly. If the system answers correctly while citing another document, you have a strong signal of memorization, training-data leakage, or a reranker bias toward popular documents.
Root causes and how to fix the retrieval path
Chunking and fingerprint drift
If chunk IDs are unstable (because chunk boundaries shift when content changes), your evaluation will falsely flag citations as wrong, or worse, allow incorrect citations to pass. Use stable document IDs and content fingerprints, and store offsets/spans inside the original document. If you syndicate content or have multiple near-identical versions, consider content fingerprinting so citations remain verifiable across mirrors. The pattern is similar to what’s described in content fingerprinting for LLMs without losing citability.
Query rewriting that changes intent
Rewriters can improve recall but may broaden or shift the query. In synthetic tests, log the rewritten query and compare it with the original. If wrong citations spike after rewriting, constrain rewrites with guardrails: preserve named entities, product identifiers, and time bounds; block expansions that add unrelated synonyms; and keep the original query as a parallel retrieval path (ensemble retrieval).
Reranker optimizing relevance over attribution
Many rerankers are trained to pick “the most relevant” chunks, not “the most directly evidential” chunks. Add features and training signals for evidence: lexical overlap with the expected answer span, presence of numeric constraints, or proximity of the claim terms. In evaluation, separate “retrieved correct evidence” from “cited correct evidence” so you can see whether reranking is losing the good chunk or whether citation selection is ignoring it.
Citation selection bug: citing top-k rather than used-k
A common engineering mistake is to cite the top retrieved chunks, even if the model actually used another part of the context window to form the answer. Fix this by enforcing used evidence citations: require the model to point to specific chunk IDs and, ideally, offsets/spans, then validate them post-hoc. If the model can’t point to supporting spans, treat it as unsupported and either regenerate or return “not enough evidence.”
Making the loop continuous with observability and governance
Synthetic Q&A testing becomes far more valuable when it runs like a monitoring system: you track citation precision over time, segment by domain, and alert on regressions after index rebuilds, embedding upgrades, reranker changes, or content updates.
This is also where an AEO/GEO-focused agent can help. lunem fits naturally into this workflow because it’s designed to monitor how content is interpreted and surfaced across LLM experiences, and to turn visibility problems into concrete, fixable signals. Pair that with a testing harness and you can move from anecdotal “the bot cited something weird” to repeatable evidence about where the retrieval path broke.
If your RAG pipeline is a DAG of steps (rewrite → retrieve → rerank → assemble context → answer → cite), treat each step like it has an SLO. Instrumenting per-step latency and quality makes it easier to pinpoint whether citation failures correlate with a particular node, which is the same operational mindset described in enforcing per-step SLOs in DAG workflows.
