In DeepEval, how do LLMTestCase context and retrieval_context differ?

## Two fields, two different questions `LLMTestCase` carries both `context` and `retrieval_context`, both are lists of strings, and nothing in the type signature stops you from putting the same value in both. The difference is entirely semantic, and it maps onto two genuinely different evaluation questions. **`context` — what is true.** This is the ground-truth background a human attaches to the test case: the paragraph from the policy document that actually answers the question, the facts about the account, the source of truth. It exists independently of your application. If you swapped out your retriever tomorrow, `context` would not change. **`retrieval_context` — what your system saw.** This is the output of your retrieval step for this input on this run: the chunks a vector search returned, in the order it returned them, including the irrelevant ones. It is a *record of system behaviour*. If you change your embedding model, chunk size or top-k, `retrieval_context` changes with it. ## Which metric reads which - `HallucinationMetric` → `context`. It asks whether the output contradicts what is known to be true. - `FaithfulnessMetric` → `retrieval_context`. It asks whether the output's claims are supported by what was actually fetched. - `ContextualPrecisionMetric`, `ContextualRecallMetric`, `ContextualRelevancyMetric` → `retrieval_context`. These grade the retrieval step itself. So `context` supports a question about the *model*, and `retrieval_context` supports questions about the *pipeline*. That is the cleanest one-line version of the distinction, and it is what an interviewer is listening for. ## Why swapping them silently corrupts a suite Suppose you populate `context` from your live retriever because it was the convenient variable to hand. `HallucinationMetric` now grades the model against its own retrieved chunks — which is roughly what faithfulness already does. Your hallucination score stops being able to detect the case that matters most: a retriever that returns confident, wrong text, which the model then faithfully repeats. The output contradicts reality but agrees perfectly with what was retrieved, so it scores clean. You have built a metric that cannot fail on your worst failure mode. The reverse mistake is milder but still wrong. Populating `retrieval_context` from a curated gold passage makes faithfulness and the contextual metrics grade a retrieval step that never ran. Contextual relevancy will look excellent — of course the hand-picked passage is relevant — and you will ship a retriever nobody measured. Both failures share a signature: the scores are stable, high and useless. Nothing errors, because both fields are just lists of strings. ## How to keep them straight in practice The rule of thumb that survives contact with a real codebase: **the field you can only fill by hand is `context`; the field you can only fill by running your app is `retrieval_context`.** If your test-case builder is filling both from the same variable, one of them is wrong. This also explains the asymmetry in where cases come from. Cases reconstructed from production traces naturally carry `retrieval_context` — the trace recorded it — but never `context`, because nobody wrote the ground truth for a live query. Curated cases carry `context` because a human authored them, and gain `retrieval_context` only when you replay them through the application. A mature suite ends up with cases in both shapes and simply runs different metric sets over each. ## A related trap Because `HallucinationMetric` is the only stock metric using `context`, teams sometimes drop `context` entirely and conclude they have no way to catch factual errors. The honest answer is that without ground truth you cannot check facts against reality with a stock metric — you can only check grounding against retrieved text with faithfulness. Recognising that limit, rather than pretending faithfulness covers it, is the senior-sounding version of this answer. ## What is out of scope here What "faithfulness" means as a measurement concept, and whether entailment-based grounding checks are trustworthy, is evaluation theory that lives outside the tool. The DeepEval-specific content is exactly this: two similarly named list-of-string fields, a fixed mapping from metric to field, and no runtime protection against putting the wrong data in either.