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.

Last reviewed Sep 11, 202629 questions
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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

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.

Open full page & share →

mediumHow do you evaluate the context-awareness of an LLM?

To evaluate the context-awareness of an LLM, you can use several methods. One approach is to create datasets that include prompts with varying levels of contextual complexity. Then, analyze the model's ability to maintain coherence across multi-turn dialogues or respond accurately based on hidden contextual clues. Metrics such as user satisfaction ratings and the consistency of responses over turns can also provide insights. Additionally, involving human evaluators to assess the relevance and appropriateness of responses in context can enhance understanding.

Open full page & share →

hardHow can fairness be measured in LLM evaluations?

Fairness in LLM evaluations can be measured by analyzing model outputs across different demographic groups, using techniques such as disparity metrics. These metrics assess whether certain groups receive preferential treatment or biased outcomes. Fairness tests can also include adversarial probing, where specific inputs known to elicit biased responses are used. Additionally, employing fairness-aware evaluation metrics, such as equal opportunity or disparate impact measures, helps quantify potential biases in outputs. Involving diverse human evaluators can also highlight fairness issues inherent in the system.

Open full page & share →

mediumHow do you evaluate LLM performance over time?

Evaluating LLM performance over time involves tracking metrics such as accuracy, relevance, and user satisfaction across different versions of the model. It is important to establish a baseline during initial deployment and then implement a continuous monitoring system to assess the model's outputs regularly. Techniques like A/B testing can be employed to compare different versions or configurations, while user feedback can highlight shifts in performance perception. Statistical methods like time series analysis can help identify trends, and data collection should include various contexts to ensure a comprehensive understanding of performance evolution.

Open full page & share →

mediumWhat is inter-rater reliability, and why is it important in LLM evaluation?

Inter-rater reliability (IRR) measures the degree of agreement among different evaluators assessing the same outputs from an LLM. It is crucial in LLM evaluation because stakeholder interpretation can vary, affecting perceived output quality. High IRR indicates that evaluators share similar judgments, suggesting the evaluation process is reliable and valid. This minimizes bias and enhances the credibility of evaluation results. To compute IRR, statistical methods like Cohen's Kappa or Fleiss' Kappa can be used, especially when assessing subjective outputs where human judgment is involved.

Open full page & share →

mediumWhat specific NLP tasks can be effectively evaluated using LLMs, and what metrics are most appropriate for each?

LLMs can effectively evaluate various NLP tasks such as text classification, summarization, question answering, and machine translation. For text classification, accuracy and F1-score are most appropriate metrics. In summarization, ROUGE scores are commonly used to evaluate the overlap between generated summaries and reference summaries. For question answering, metrics like Exact Match (EM) and F1 score are vital for assessing correctness. In machine translation, BLEU score and METEOR provide insights into translation quality by measuring n-gram overlap. Utilizing the right metrics ensures a comprehensive evaluation across different tasks.

Open full page & share →

mediumHow can user feedback be incorporated into the LLM evaluation process?

User feedback can be incorporated into the LLM evaluation process through systematic collection and analysis of user interactions and satisfaction. This can be achieved by deploying feedback forms, conducting user surveys, and analyzing user behavior analytics on the platform. User feedback can provide qualitative insights on output relevance, coherence, and usability, which standard metrics may not capture. Additionally, this feedback can inform model tuning and improve training datasets by identifying common issues or preferences. Incorporating this iterative feedback loop can enhance the overall user experience and lead to more aligned LLM outputs.

Open full page & share →

mediumWhat considerations should be taken into account when sourcing data for LLM evaluation?

When sourcing data for LLM evaluation, it's important to consider several factors, including: 1. **Quality**: The data should be accurate, relevant, and representative of the use case. 2. **Diversity**: Include varied types of examples to cover different contexts, domains, and linguistic variations. 3. **Size**: A sufficiently large dataset is needed for statistical significance, especially in performance measurement. 4. **Annotations**: If applicable, ensure that the data is well-annotated for tasks like classification or sentiment analysis. 5. **Bias**: Data should be examined for potential biases that could affect evaluation fairness and reliability. 6. **Privacy**: Comply with data privacy regulations to protect sensitive information.

Open full page & share →

hardHow can the reliability of human annotations be ensured in LLM evaluations?

To ensure the reliability of human annotations in LLM evaluations, consider the following strategies: 1. **Training**: Provide thorough training for annotators to ensure they understand the task and the criteria for quality assessment. 2. **Clear Guidelines**: Establish clear and unambiguous guidelines to reduce subjectivity in annotations. 3. **Pilot Studies**: Conduct pilot studies to identify potential issues in the annotation process before full-scale evaluation. 4. **Consensus Scoring**: Use multiple annotators to score each output, and take the average or majority vote to mitigate individual biases. 5. **Inter-Annotator Agreement**: Measure inter-annotator reliability, such as using Cohen's Kappa, to evaluate consistency among different annotators. 6. **Feedback Loop**: Incorporate a feedback mechanism for annotators to discuss ambiguous cases and improve the guideline clarity.

Open full page & share →

mediumHow does the diversity of training data impact the evaluation of LLMs?

The diversity of training data is crucial for the evaluation of LLMs as it affects their ability to generalize across different contexts and domains. A more diverse dataset helps LLMs understand a wider range of concepts, language structures, and cultural nuances, which can lead to improved performance on varied evaluation metrics. If the training data is not sufficiently diverse, the model may perform well on familiar inputs but struggle with edge cases or novel situations. Thus, when evaluating LLMs, it's important to consider how well the training data represents the intended application domain to ensure reliability and accuracy in their outputs.

Open full page & share →

mediumHow do you balance speed and accuracy in LLM evaluations?

Balancing speed and accuracy in LLM evaluations involves a strategic approach where both quantitative metrics and qualitative assessments are taken into consideration. Evaluators may employ automated metrics that provide quick feedback on model performance, such as BLEU or ROUGE, alongside more time-consuming human evaluations that yield richer insights. Furthermore, employing sampling techniques can optimize evaluation speed without compromising accuracy by focusing on a representative subset of outputs. Ultimately, a hybrid evaluation strategy that combines automated methods for preliminary assessments with human review for critical insights can help strike this balance effectively.

Open full page & share →

mediumHow can you mitigate bias in LLM evaluation results?

Mitigating bias in LLM evaluation results involves several strategies. First, diversifying validation datasets by including varied demographic, cultural, and contextual factors can provide a more balanced assessment. Second, employing multiple evaluators can help reduce personal biases, as aggregating their feedback may yield a more accurate picture. Third, using fairness metrics and tools, such as equality of opportunity and disparate impact analysis, can help assess and quantify bias systematically. Finally, iterative testing and retraining of the model based on evaluation outcomes can further decrease bias over time.

Open full page & share →

mediumHow do you conduct LLM evaluations in real-world applications?

Conducting LLM evaluations in real-world applications involves a combination of strategy and execution. First, define clear objectives based on the application's purpose, including target metrics for accuracy, efficiency, and user satisfaction. Implement a mixed-method approach by combining qualitative assessments (e.g., user interviews or surveys) with quantitative metrics (e.g., precision, recall). Involve end-users in the evaluation process to gather their feedback, which helps ensure that the model meets practical needs. Finally, set up a continuous evaluation loop, allowing for ongoing monitoring and adjustments based on user interactions and feedback.

Open full page & share →