LLM Evaluation And Hallucination Detection

What's being tested

These questions test whether you can turn vague LLM quality into measurable, reproducible evaluation metrics, then build an improvement loop that operates safely in production. You must distinguish unsupported claims from stylistic variation, retrieval failures, and legitimate uncertainty, using both automated evaluators and human-labeled data. Microsoft cares because enterprise applications need dependable answers, traceable regressions, and monitoring that remains useful as prompts, models, retrieval indexes, and user traffic change.

Core knowledge

• Groundedness measures whether an answer is supported by supplied evidence, while factuality measures truth against the external world; a response can be factually correct yet ungrounded if the provided context does not support it.

• Build a versioned evaluation set containing representative queries, retrieved contexts, expected answers, abstention cases, adversarial prompts, and metadata such as domain, language, difficulty, model, prompt, and retrieval configuration.

• Use multiple metrics: citation correctness, context recall, answer relevance, groundedness, refusal quality, latency, token cost, and safety. Aggregate metrics can hide severe failures, so report slices such as tenant, language, document type, and query intent.

• For a response split into claims $c_1,\ldots,c_n$, a simple unsupported-claim rate is
  $\text{HallucinationRate}=\frac{\sum_i \mathbf{1}[\text{claim }c_i\text{ lacks support}]}{n}.$
  Weighting claims by importance is better than treating every sentence equally.

• A practical groundedness scorer splits output into atomic sentences or claims, retrieves relevant context passages, and classifies each claim as supported, contradicted, or unverifiable; sentence splitting and coreference resolution are important edge cases.

• LLM-as-a-judge scales semantic evaluation but inherits position bias, verbosity bias, model-specific blind spots, and prompt sensitivity. Calibrate it against human labels, use explicit rubrics and structured outputs, and periodically estimate agreement such as Cohen’s $\kappa$.

• Prefer pairwise comparison for prompt or model changes when absolute scoring is noisy: randomize candidate order, include ties, blind the evaluator, and bootstrap confidence intervals over query-level outcomes rather than treating each claim as independent.

• Maintain evaluation versioning: pin model versions, system prompts, retrieval settings, datasets, judge prompts, and scoring code. Otherwise, a metric change cannot be attributed to the candidate model or deployment change.

• Separate offline evaluation from production monitoring. Offline suites enable controlled regression testing; online signals include user feedback, citation clicks, correction rates, abstention rates, sampled human audits, judge scores, latency, and token consumption.

• Monitor drift across query distributions, retrieved-document distributions, embedding similarity, answer lengths, language, and failure categories. A stable average score can conceal degradation in a newly popular tenant or a low-volume safety-critical slice.

• Design the improvement loop as: collect failures, label or adjudicate them, classify root cause, modify one component, rerun the fixed regression suite, and canary the change. Root causes may be retrieval recall, chunking, prompt instructions, tool failure, model behavior, or evaluator error.

• Use risk-weighted thresholds rather than one universal gate. A minor style regression may be acceptable for a low-risk assistant, while unsupported legal, medical, financial, or administrative claims should trigger abstention, escalation, or release blocking.

Worked example: Design an Evaluation and Improvement Loop for a Production LLM Application

For “Design an Evaluation and Improvement Loop for a Production LLM Application,” I would first clarify the application’s task, grounding sources, risk tolerance, traffic, supported languages, latency budget, and whether answers must cite evidence. I would state an assumption that this is a retrieval-augmented enterprise assistant whose responses must be attributable to approved documents. I would organize the answer around four pillars: a versioned offline dataset, a layered evaluator, production monitoring with slice analysis, and a controlled deployment/improvement loop. The offline set would combine historical queries, expert-authored cases, adversarial examples, abstention cases, and sampled production traffic with human labels for groundedness, relevance, completeness, and safety. The evaluator would combine deterministic checks, retrieval diagnostics, calibrated judge models, and periodic human audits rather than relying on a single LLM score. I would explicitly trade off judge coverage and cost against human-label precision, using human review to calibrate and audit the automated evaluator. Deployment would use shadow or canary traffic, regression gates, rollback criteria, and model/prompt/retrieval version identifiers for every result. I would close by saying that, with more time, I would define an error taxonomy and test whether each intervention improves high-risk slices without merely optimizing the judge.

A second angle

For “Measure LLM Quality and Detect Hallucinations, Then Implement an Evaluation Component,” the emphasis shifts from platform lifecycle design to implementing a transparent groundedness measurement component. I would clarify whether “hallucination” means unsupported-by-context, contradicted-by-context, or globally false, because those require different labels and evidence sources. A robust implementation would extract claims, compare each claim with supplied context, return per-sentence labels and evidence spans, and aggregate with both macro and risk-weighted scores. I would call out that naive string overlap misses paraphrases and can mark a correct synthesis as unsupported, so semantic entailment or a calibrated judge is useful but must be audited. I would test empty context, multi-sentence claims, negation, pronouns, conflicting passages, and answers that appropriately abstain.

Common pitfalls

Analytical mistake: Treating an LLM judge score as ground truth is tempting, especially when it correlates with a few manually reviewed examples. A stronger answer discusses calibration against human labels, inter-rater disagreement, confidence intervals, and judge drift, while retaining deterministic and human checks for high-risk cases.

Pitfall: “The answer contains the same words as the context, so it is grounded.” Lexical overlap does not establish entailment and can miss contradictions or unsupported conclusions.

Communication mistake: Jumping directly into a specific model, vector database, or prompt template before defining quality and risk makes the design sound implementation-led. Start with the contract—what counts as a correct, supported, useful, and safely abstaining answer—then select components that measure it.

Depth mistake: Proposing only an offline benchmark misses production distribution shift and feedback loops. Explain canaries, slice-level monitoring, rollback, dataset refresh, evaluator recalibration, and root-cause attribution across retrieval, generation, tools, and data.

Connections

An interviewer may pivot to retrieval evaluation such as recall@k and nDCG, human annotation design, or experiment analysis for comparing prompts and models. They may also ask about data and concept drift, safety classifiers, abstention policies, model serving latency, and offline/online feature or configuration parity.

Further reading

• RAGAS: Automated Evaluation of Retrieval Augmented Generation — Introduces automated dimensions for faithfulness, answer relevance, and context relevance.

• FAVA: Fine-grained Atomic Verification for Factuality Evaluation — Shows why decomposing answers into atomic claims improves factuality analysis.

• TruthfulQA: Measuring How Models Mimic Human Falsehoods — A useful benchmark for understanding truthfulness failures beyond simple retrieval grounding.