LLM Evaluation & Testing: Interview Questions
How to prove an AI system actually works — the evaluation and testing questions that separate engineers who ship reliable LLM apps from those who ship demos. Covers metrics, LLM-as-a-judge, hallucination detection, red teaming, benchmarks, and regression testing.
easyWhy is evaluating LLM applications harder than testing traditional software?
Traditional software is deterministic — the same input gives the same output, so a test asserts an exact expected value. LLMs are probabilistic and open-ended: the same prompt can yield different wordings that are all correct, or subtly wrong ones that look fine. There's often no single 'right' answer to assert against, quality is partly subjective (is this summary good?), and the model can regress on things you never tested when you change a prompt or model version. So you can't rely on exact-match unit tests alone. You need evaluation on representative datasets using a mix of automated metrics, model-graded scoring, and human review — and you re-run it continuously, because behaviour drifts.
mediumHow do you evaluate LLM outputs, and what metrics do you use?
Match the method to the task. For tasks with a reference answer (translation, extraction), use overlap or similarity metrics (exact match, F1, BLEU/ROUGE, embedding similarity). For open-ended generation, reference metrics break down, so use LLM-as-a-judge scoring against a rubric, or human rating. For RAG, measure retrieval quality (are the right chunks fetched?) and faithfulness (is the answer grounded in them?) separately. Task-specific checks matter too: does the JSON parse, is the code runnable, are required facts present. Always evaluate on a fixed, representative dataset so results are comparable over time, report the metric distribution not just an average, and pair automated scores with periodic human spot-checks to catch what metrics miss.
mediumExplain BLEU, ROUGE, and BERTScore. When would you use each?
All three compare generated text to a reference, but differently. BLEU measures n-gram precision — how much of the output appears in the reference — and was built for machine translation; it rewards exact word overlap. ROUGE measures n-gram recall — how much of the reference is captured — and is standard for summarisation. Both are cheap and reproducible but purely lexical: they punish valid paraphrases that use different words and can't judge meaning. BERTScore instead compares contextual embeddings of the two texts, so it credits semantic similarity even when the wording differs, at higher compute cost. Use BLEU/ROUGE for quick, comparable scoring where wording is constrained; BERTScore when paraphrase matters. For open-ended, subjective quality, none is sufficient — reach for LLM-as-a-judge or humans.
mediumWhat is LLM-as-a-judge evaluation, and what are its limitations?
LLM-as-a-judge uses a strong model to score or compare outputs against a rubric — rating a response 1–5 for helpfulness, or picking which of two answers is better. It scales far better than human review and handles open-ended quality that lexical metrics can't. But it has real limitations: judges show biases (favouring longer answers, the first option presented, or their own model family's style), can be inconsistent run to run, and may confidently mis-grade on domains they're weak in. Mitigate with a clear rubric, few-shot examples, randomising option order, using pairwise comparison rather than absolute scores, and calibrating the judge against a human-labelled sample. Treat it as a strong, cheap signal to validate against humans — not ground truth on its own.
hardWhat is G-Eval, and how does it use LLMs for evaluation?
G-Eval is a framework for more reliable LLM-as-a-judge scoring. Instead of just asking a model to output a number, it first has the model generate the evaluation steps (a chain-of-thought reasoning process from the criteria), then scores against those steps. It also produces a finer, probability-weighted score by considering the distribution over rating tokens rather than a single sampled number, which reduces the coarse, clumpy scores you get from naive prompting. The result correlates better with human judgement than plain prompting on tasks like summarisation quality. It still inherits the general limits of model-based evaluation — judge bias and domain blind spots — so you calibrate it against human labels rather than trusting it blindly.
mediumHow do you detect and measure hallucinations in LLM outputs?
Hallucination is output that's fluent but unsupported or false. To measure it, define it against a source: in RAG, check faithfulness — is every claim grounded in the retrieved context? You can score this with an LLM-judge (or NLI model) that flags claims not entailed by the sources. Where a reference or knowledge base exists, verify facts against it. Other signals: self-consistency (sample several answers; wide disagreement suggests the model is guessing), and asking the model to cite sources you can automatically check. Report a hallucination rate on a labelled evaluation set and track it over time. Reduce it with grounding, lower temperature, and an explicit 'say you don't know' instruction — but you can't drive it to zero, so keep human verification for high-stakes facts.
mediumWhat is red teaming, and how do you red team an LLM application?
Red teaming is deliberately adversarial testing — you attack your own system before users or bad actors do. For an LLM app, probe for prompt injection (inputs that override your instructions), jailbreaks (bypassing safety rules), leakage of the system prompt or other users' data, harmful or biased outputs, and tool misuse (tricking an agent into dangerous actions). Combine manual creative attacks with automated adversarial prompt generation, and cover edge cases across languages and encodings. Track which attacks succeed, fix with input filtering, output guardrails, least-privilege tool permissions, and prompt hardening, then re-test. For multimodal systems, remember text-only tests miss attacks hidden in images or audio. Red teaming is ongoing, not a one-time pre-launch checkbox.
mediumWhat are benchmarks like MMLU, HumanEval, and GSM8K, and how should you interpret them?
These are standardised test sets for comparing base models. MMLU covers broad multiple-choice knowledge across many subjects; HumanEval measures code generation by running the code against unit tests; GSM8K tests grade-school math word problems (reasoning). They're useful for rough capability comparison, but interpret them cautiously: benchmark contamination (test questions leaking into training data) inflates scores, a high average hides weakness on your specific domain, and these academic tasks rarely match your production workload. A model topping MMLU may still be worse for your RAG chatbot. Use public benchmarks to shortlist candidates, then run your own task-specific evaluation on data that reflects real usage — that's what actually predicts how the model performs for you.
hardHow do you evaluate a RAG system end-to-end?
Evaluate the two stages separately, then the whole. Retrieval: on a labelled set of questions with known relevant documents, measure recall and precision (did the right chunks get fetched, and how many irrelevant ones came along?) using metrics like hit rate and MRR/NDCG. Generation given context: measure faithfulness (is the answer grounded in the retrieved chunks, no hallucination?) and answer relevance (does it actually address the question?), typically via LLM-as-a-judge. End-to-end: correctness against reference answers where they exist, plus human spot-checks. This separation is the key insight — a wrong final answer could be a retrieval miss (fix chunking/embeddings/re-ranking) or a generation failure (fix the prompt), and only stage-wise metrics tell you which.
mediumWhat is the difference between offline and online evaluation for AI systems?
Offline evaluation runs before deployment on a fixed dataset — you score model or prompt versions against golden examples in CI to catch regressions and compare candidates. It's fast, reproducible, and gates releases, but it only measures what your dataset covers and can't capture real user behaviour. Online evaluation happens in production on live traffic: A/B tests, user signals (thumbs up/down, edits, task completion, retention), and sampling real outputs for human or automated review. It reflects reality but is slower, noisier, and riskier. You need both — offline to ship with confidence and prevent obvious regressions, online to learn what actually works for users and to catch drift the offline set never anticipated.
easyWhat is the role of golden datasets in AI evaluation?
A golden dataset is a curated, trusted set of inputs paired with known-good expected outputs (or acceptance criteria) that represents your real use cases and important edge cases. It's the fixed yardstick you evaluate every prompt and model change against, so results are comparable over time and a regression is immediately visible. Good practice: keep it representative (mirror real query distribution), include hard and adversarial cases, version it, and grow it whenever a production bug reveals a gap the set missed. Keep it out of any training or few-shot data to avoid contaminating the measurement. A small, high-quality golden set that you actually run in CI beats a huge, stale one nobody trusts.
mediumWhat is evaluation-driven development for AI applications?
It's applying test-driven discipline to AI: define how you'll measure success before and while you build, not after. You start by writing an evaluation set and metrics that encode what 'good' means for the task, then iterate on prompts, retrieval, and models with that eval as the feedback loop — every change is scored, so you keep what improves the number and revert what doesn't. It turns prompt engineering from vibes-based tweaking into measurable progress, catches regressions when you upgrade a model, and gives you evidence to ship. In practice: build a golden dataset early, wire evals into CI, watch the metric distribution as you develop, and expand the set as you discover failure cases. The eval becomes the spec.
hardHow do you evaluate the quality of AI agents?
Agents are harder than single LLM calls because they take multi-step trajectories with tool use, so evaluate both the outcome and the path. Outcome: did it complete the task correctly? Define task-success criteria on a set of representative goals and score end-state, ideally in a sandboxed environment you can check programmatically. Trajectory: was the reasoning sound, did it call the right tools with valid arguments, avoid unnecessary or unsafe steps, and recover from errors? Also track efficiency — step count, tokens, latency, cost — since a correct-but-wasteful agent is a problem. Observability is essential: log every step, tool call, and decision so failures are debuggable. Combine automated task-success checks with human or LLM-judge review of trajectories, and red team for unsafe tool actions.
mediumWhat are some popular evaluation frameworks for LLMs, and how do they differ from one another?
Popular evaluation frameworks for LLMs include Hugging Face's 'Evaluate', AllenNLP's 'Evaluation Toolkit', and the 'OpenAI API Evaluation Framework'. These frameworks differ in their design and focus: Hugging Face's 'Evaluate' emphasizes ease of use with a vast range of metrics applicable to various tasks, while AllenNLP's toolkit is more geared towards detailed NLP evaluations with a strong emphasis on interpretability. The OpenAI API framework, on the other hand, provides a structured way to evaluate models deployed via the API, focusing on real-world utility and scalability. Each offers unique features catering to different aspects of LLM evaluation.
hardWhat ethical considerations should be taken into account when evaluating LLMs?
When evaluating LLMs, several ethical considerations must be taken into account, including bias, fairness, transparency, and accountability. Evaluators should assess whether the LLM produces outputs that could reinforce societal biases or stereotypes, requiring thorough testing across diverse demographic groups. Additionally, it is crucial to ensure models are interpretable, making their decision-making processes transparent to users and stakeholders. Evaluators should also consider the potential impacts of the LLM's outputs on individuals and communities, ensuring that the evaluation process holds the model accountable for harmful or misleading results. Lastly, maintaining user privacy and data security during evaluation is essential to protect sensitive information.
mediumWhat role does human evaluation play in assessing LLM outputs?
Human evaluation is crucial for assessing LLM outputs because it provides qualitative insights that automated metrics may overlook. Evaluators can assess aspects such as relevance, coherence, and nuance, which are difficult to quantify. This form of evaluation helps identify unexpected issues such as biases, inappropriate content, and contextual misunderstandings, enabling better alignment with human expectations. It can be done through surveys, blind tests, or comparative assessments against other outputs.
hardHow can you evaluate the robustness of an LLM in handling adversarial inputs?
Evaluating the robustness of an LLM involves testing it against adversarial inputs designed to mislead or confuse the model. This can include altering input phrasing, introducing noise, or using out-of-distribution data. Methods include creating a set of adversarial examples and measuring performance degradation, as well as employing techniques like stress testing or perturbation analysis. Results can reveal vulnerabilities and guide further training or fine-tuning to enhance model resilience against such challenges.
No questions match your filter.