LLM evaluation metrics: A comprehensive guide for large language models

Why do we need LLM evaluation metrics?

Compare models and prompts: Determine which model (or model version) performs better on a given task.
Track improvements: See if fine-tuning or prompt tweaks actually improved results over time.
Ensure quality and safety: Catch issues like factual errors, incoherence, or toxic content before they reach end-users.
Meet requirements: Verify the model meets business or user-defined criteria (e.g. a support chatbot must solve customer queries correctly and respectfully).

Categories of LLM evaluation metrics

Automatic Metrics: Quantitative scores computed by algorithms or models. These require no human in the loop and often compare the LLM output against a reference or use an intrinsic measure. Examples: perplexity, BLEU/ROUGE scores, BERTScore, MAUVE, exact match accuracy.
Human-Aligned Metrics: Qualitative judgments reflecting human preferences or values. These include clarity, coherence, helpfulness, harmlessness, etc., and are often obtained via human raters or learned proxies (like another LLM “judge”). Examples: toxicity level, factuality/faithfulness, helpfulness ratings.

Generative task metrics: For open-ended text generation (e.g. stories, dialogs) or tasks like summarization and translation. These often use reference-based metrics (compare output to a reference text) or distribution-based metrics (assess output quality by comparing to human language distribution).
Classification/decision task metrics: For tasks where the LLM produces a specific answer or class (e.g. multiple-choice Q&A, code correctness, tool usage). These can use metrics like accuracy, precision/recall, F1, or domain-specific success rates (e.g. test pass rates for code).

Automatic evaluation metrics for LLMs

Perplexity – how well does the model predict text?

from transformers import AutoModelForCausaLLM, AutoTokenizer
import torch

model = AutoModelForCausaLLM.from_pretrained("gpt2")
tokenizer = AutoTokenizer.from_pretrained("gpt2")
text = "Hello, how are you?"
enc = tokenizer(text, return_tensors="pt")
with torch.no_grad():
    # Compute negative log-likelihood loss
    loss = model(**enc, labels=enc["input_ids"]).loss
    perplexity = torch.exp(loss)
print(f"Perplexity: {perplexity.item():.2f}")


N-gram overlap metrics (bleu, rouge, etc.) – how much does output match a reference text?

BLEU (Bilingual Evaluation Understudy): Originally developed for machine translation, BLEU evaluates how many n-grams in the generated text appear in the reference text. It computes a precision score for n=1 up to 4 (typically) and combines them (with a brevity penalty to discourage outputs that are too short). A higher BLEU means closer word overlap with the reference. BLEU works best when there’s a relatively fixed phrasing expected (e.g. translations). However, it can be overly strict – e.g., using a synonym or paraphrase will lower BLEU even if the meaning is preserved.
ROUGE (Recall-Oriented Understudy for Gisting Evaluation): Commonly used for summarization tasks, ROUGE measures recall of n-grams – essentially, what percentage of the reference’s n-grams appear in the output. ROUGE-N is for n-gram overlap, and ROUGE-L measures longest common subsequence overlap. High ROUGE means the model’s summary covered a lot of the reference summary’s content. Like BLEU, it’s superficial – it doesn’t account for meaning, just exact overlaps. Still, ROUGE is a decent proxy for content coverage in summarization and is easy to calculate.
METEOR: A metric that goes beyond exact n-grams by including stemming and synonym matching. METEOR calculates precision and recall of unigram matches, but unlike BLEU, it tries to align words and can use a thesaurus (like WordNet) to count synonyms as matches. It often correlates better with human judgments than BLEU on some tasks, thanks to considering synonyms and partial credit for matches. It outputs a score (0-1) like BLEU/ROUGE.
Exact Match & F1 (for QA): In tasks like extractive QA or closed-book QA, a simple but effective metric is Exact Match – does the model output exactly the correct answer string – and F1 score – which accounts for partial overlaps (treating the answer and output as bag-of-words sets). These are essentially overlap metrics at the answer level. For example, if the question’s true answer is “George Washington” and the model says “Washington”, that’s a partial match (F1 < 1.0, Exact Match = 0). These metrics are popular in question-answering benchmarks.

Embedding-based semantic similarity (bertscore & beyond) – do the output and reference mean the same thing?

BERTScore: This metric computes similarity by embedding both the candidate output and the reference text using a model like BERT (or Roberta, etc.) and then matching tokens in one to tokens in the other. Instead of exact word matches, it uses cosine similarity between embedding vectors of words. For each word in the candidate, BERTScore finds the most similar word in the reference (and vice versa) to compute a precision and recall, then a combined F1 score. The idea is that if the output conveys the same meaning as the reference, the embeddings (which capture context and semantics) will be similar even if the exact words differ. For example, “The cat sits on the mat” vs “A feline rests upon a rug” might have low BLEU, but a high BERTScore because “cat” is close to “feline” in embedding space, “mat” to “rug”, etc. A perfect semantic match would score 1.0.

!pip install bert_score   # install the bert-score library

from bert_score import score

candidates = ["The cat sits on the mat"]
references = ["A feline rests upon a rug"]
P, R, F1 = score(candidates, references, lang="en", verbose=True)
print(f"BERTScore F1: {F1[0]:.4f}")


Generative quality metrics (mauve and others) – how close is the output distribution to human-like?

MAUVE: MAUVE is a metric designed to measure the gap between the distribution of machine-generated text and human text. It effectively compares two sets of text samples – one from the model, one from human-written data – and computes a divergence score (it uses a fancy method with clustering in an embedding space and computing KL divergences). The MAUVE score (ranging 0 to 1) indicates how well the model’s distribution approximates human-like language: higher MAUVE = more human-like generation. Unlike BLEU which needs one reference per output, MAUVE looks at overall distributions. It’s particularly useful for open-ended tasks like long-form text generation, dialogues, or anywhere you can sample many outputs and want to evaluate them collectively.

Task-specific automatic metrics (accuracy, etc.) – did the model get the correct answer or complete the task?

Accuracy / Error Rate: If the LLM is used for classification or to pick one of a few options (e.g. multiple-choice questions, next action in an agent, picking a tool), we can measure accuracy (% of outputs that are exactly correct). For example, if using an LLM to take a standardized test (like MMLU or another benchmark), the accuracy on those questions is a clear metric of performance.
Precision/Recall/F1: If the task involves identifying items or producing lists (like extracting names from text, or multi-label classification), precision and recall can be computed comparing the set of items output vs the ground truth set.
Exact Match (EM): Often used in QA evaluations (e.g., SQuAD dataset), it’s a strict measure: does the model’s answer exactly match the ground truth answer string (after normalization)? It’s a harsher criterion than accuracy in multiple-choice because any deviation or wording difference counts as 0.
Code correctness metrics: For code generation tasks, automatic evaluation often uses execution-based metrics. A common one is pass@k – the percentage of problems for which at least one of the model’s k generated solutions passes all unit tests (i.e., is a correct program). For instance, Codex might be evaluated on pass@1 or pass@10 on a suite of coding challenges. This is effectively an accuracy measure but allowing multiple tries. Similarly, if the code can be executed, you might measure runtime errors vs. successful runs.
Tool use success: In agent scenarios, if an LLM is supposed to call tools (APIs, calculators), you can define metrics like Tool Success Rate (did the model call the correct tool and get the right result?). The Confident AI guide, for example, defines Tool Correctness as whether the agent used tools appropriately. This often reduces to an accuracy measure on a set of scenarios.

Human-aligned metrics: quality, safety, and beyond

Coherence, fluency, and relevance – does the output make sense and flow well?

Coherence: A coherent response is logically consistent and well-structured. It should stay on topic and not contradict itself. Coherence can be assessed by humans by reading the output for logical flow. Automatic proxies include checking if the output stays relevant to the prompt (no random tangents) and whether it follows a sensible narrative or reasoning. W&B Weave, for instance, includes a ContextRelevance scorer which can function as a guardrail to ensure the output is on-topic with the input or provided context. For multi-turn chats, coherence also means maintaining context from prior turns.
Fluency: This refers to the grammar, syntax, and style – basically, does the text read like good, natural writing in the target language? A fluent response has no obvious grammatical errors or awkward phrasing and follows normal usage. Fluency is often high for modern LLMs (they’re quite good at local language modeling), but it can degrade if the model is stressed or if it’s producing something it’s less sure about. There are automated grammar checkers (like LanguageTool or GPT-based checkers) that can rate fluency, but human reading is the gold standard.
Relevance: Especially for tasks like Q&A or dialogue, we ask: Did the model actually address the user’s query or the task prompt? A response can be perfectly fluent and coherent yet completely irrelevant or evasive. Ensuring relevance means the model’s answer stays on the topic asked and provides information that’s useful for the prompt. In RAG systems, this ties to using provided context (is the answer grounded in the retrieved documents?). Metrics like answer relevancy, such as W&B's ContextRelevance scorer, are often implemented via LLM-as-a-judge or heuristics to see if the question’s keywords or intent appear in the answer.

Factuality and faithfulness – is the content correct and grounded in truth?

Factuality: Measures whether the statements the model makes are factually correct in the real world. For instance, if asked “Who is the President of France in 2023?” a factually correct answer is “Emmanuel Macron.” An answer like “Jean Dupont” would be factually incorrect. Factuality is hard to assess automatically because it requires a knowledge source or ground truth. Techniques include checking the output against a knowledge base or Wikipedia (for factual QA), or using a separate fact-checking model. Datasets like TruthfulQA also attempt to quantify how often a model gives true vs. false answers for tricky questions.
Faithfulness: Often discussed in context of summarization or RAG, faithfulness means the model’s output does not introduce unsupported information and sticks to the provided source content. For example, a summary is faithful if everything in it is derived from the original document (no made-up facts), even if the original document might not be universally true. In RAG, an answer is faithful if it is grounded in the retrieved documents and doesn’t inject outside hallucinated info. Essentially, it’s a measure of not hallucinating relative to source. An unfaithful output would be one that contains details not present in the input source.

String match checks: In RAG, a simple metric is Precision@k of source citation – e.g., check if the answer contains sentences or facts that can be found in the top-k retrieved documents. If not, likely a hallucination. Some use an overlap score between answer and sources to gauge groundedness.
Question generation + QA (Q^2): One clever metric for faithfulness (for summaries) is to generate questions from the summary and see if the original text can answer them. If the original text can’t provide the answer given in the summary, the summary probably hallucinated that detail. This approach, called Q^2, yields a score of consistency.
Fact-check models: There are classifiers fine-tuned to detect factual inconsistencies. For instance, FactCC was a model for checking if a summary is consistent with an article. Similarly, one can prompt GPT-4: “Is the following statement correct? ...” to use it as a fact-checker (with caution). W&B Weave also offers scorers that can act as guardrails for Hallucination and Faithfulness, providing automated checks against provided context or known facts.
Human eval: Ultimately, human experts sometimes need to verify facts. This is common in domains like medical or legal, where every statement might need verification.

Toxicity and harmlessness – does the model avoid harmful or offensive content?

Helpfulness and user satisfaction – is the model effectively addressing user needs?

Use-case-specific metrics and best practices

Summarization metrics

ROUGE scores: As mentioned, ROUGE is the de facto standard for summarization evaluation. A high ROUGE means the summary has high overlap with a reference summary, which usually implies it covered similar content. It’s good for measuring coverage of important points.
BERTScore / Embedding similarity: To allow for more paraphrasing, many works report BERTScore for summaries, as it captures similarity in meaning even if phrasing differs.
Faithfulness checks: Summaries are notorious for potential hallucinations (adding details not in source). So evaluating faithfulness is critical. One might use a model like FactCC, or an LLM judge that compares the summary to the source and rates factual consistency. Alternatively, the Q^2 approach (question generation) can be automated to some extent. Automated tools like W&B's Hallucination scorer can also be applied here.
Compression & coverage metrics: Some works look at how much of the source was retained or compressed. For example, the ratio of summary length to source length (a basic metric, but too high compression might miss info, too low might just copy). Coverage can mean did the summary include all the key facts (which you might define via a set of reference facts).
Coherence & readability: A summary should read well as a standalone text. While usually high-level metrics don’t explicitly capture this, human eval often includes a score for coherence/fluency of the summary.

Retrieval-Augmented Generation (rag) metrics

Retrieval relevance (Recall@k / Precision@k): How good are the retrieved documents? If the system is asked a question answerable by some document in the corpus, did the retriever find that doc in its top-k results? This is often measured by Recall@k (did the relevant doc appear in top-k). If you have labeled data with which documents contain the answer, you can compute this objectively. If not, you might sample and manually judge if the retrievals look on-topic.
Context relevance (to the query): Low context relevance indicates the retrieval might have missed the mark (which usually will lead to a bad answer). Tools like W&B Weave provide ContextRelevance scorers that can automate this check during evaluation.
Context completeness: Another RAG-specific idea is completeness – whether the retrieved info covers everything needed. Even if each retrieved doc is somewhat relevant, maybe a key piece was missing. If you have a multi-part question and your documents only answered part, the answer might end up incomplete.
Answer faithfulness to context: Given the docs, did the LLM actually use them correctly? A good metric is to check if the answer’s facts appear in the context. If the answer has a sentence that can’t be found in any provided doc, that’s a sign of hallucination. One can automatically highlight which parts of the answer are supported by the context (there are NLP methods for this, or simply overlap and heuristic matching of names/dates). Hallucination rate in RAG can be measured by human labeling on a sample: e.g., “out of 100 questions, 5 answers contained info not present in the retrieval results” => 5% hallucination rate. Automated Faithfulness or Hallucination scorers, like those in W&B Weave, are specifically designed for this RAG evaluation task, checking if the answer is grounded in the provided documents.
End-to-end accuracy: If your RAG system is used for QA, ultimately you care if the answer was correct. Sometimes retrieval could fail but the model guesses correctly anyway (rare, but possible if it had training data answer). Or retrieval might succeed but the model still misstates the answer. So it’s worth also evaluating the final answer in the same way you’d evaluate a non-RAG model for that task (accuracy, ROUGE if it’s long answer, etc.). If a correct answer is defined, measure exact match or F1 of the answer itself. This gives the bottom-line performance.

Chatbot and dialogue metrics

Conversation Success / Task completion: If the chatbot has a specific purpose (booking a ticket, troubleshooting an issue), you can measure task completion rate – did the chat end in a successful outcome? This often requires defining success criteria for a conversation (maybe the user says “thanks, that answers my question”). Wizard-of-Oz style evaluation can be done where testers interact and then note if their goal was met.
Turn-level quality: Similar to coherence/helpfulness at the single response level, but extended to dialogue. Did each answer follow from the last user prompt appropriately? Metrics like Next Utterance Relevance (potentially using a ContextRelevance scorer) can be calculated via an embedding similarity between the response and the conversation context to ensure the bot’s reply is on-topic. Also, length & verbosity can be a metric: does the bot ramble or keep it concise? Depending on preference, there might be an optimal range.
Engagement: Does the user remain engaged? For example, average number of turns in a session could be a proxy – if users consistently only say 1 thing and leave, maybe the bot’s responses aren’t engaging. This is a bit product-oriented, but if you have user data it’s a valuable signal.
Safety in dialogue: All the safety metrics (toxicity, PII detection etc.) apply here, but in dialogue we also worry about things like the bot revealing private info or getting manipulated by user messages (prompt injections). So you might run specific red-team test conversations to evaluate how the model responds to adversarial or sensitive prompts using automated scorers like W&B's Toxicity checker. For evaluation, you can script some known dangerous prompts and see if the model complies or refuses appropriately. Then report e.g., “Model refused X% of unsafe requests” (higher is better, to a point).
Persona & Consistency: If your chatbot has a persona or style, you might subjectively evaluate if it’s consistent. For instance, does it maintain the same tone? There’s a metric in research called Consistent Persona where they check if the bot doesn’t contradict earlier stated facts about itself across a conversation.
Human evaluation via chat comparison: Often the most comprehensive evaluation for chatbots is to have humans chat with different bots (or different versions) and blindly rate their experience or choose which chat they preferred. This was done in many chatbot competitions. You could simulate this with LLM judges as well (have GPT-4 simulate a user and then evaluate, though simulating a user is tricky).

Code generation metrics

Functional Correctness (Pass@k): As mentioned, the primary metric is whether the generated code is correct (does it compile? does it pass all tests for the problem?). Because LLMs can generate multiple attempts, pass@k measures the probability that at least one of k samples is correct. For instance, pass@1 is just accuracy of the first attempt; pass@5 might allow the model to generate 5 solutions and see if any solve it. This is especially useful when generation has some nondeterminism.
Error Rate: If code is generated in an interactive setting (like an assistant writing code), you might measure how many errors the user had to fix or how often the model had to retry. A low error rate means the model usually gets it right first time. Some evaluations measure the edit distance between model output and the corrected solution.
Code Quality & Style: Beyond just working, is the code clean and well-structured? This is subjective, but you can use linters or formatters as a crude metric. For example, running a PEP8 linter on Python code to see if it follows style guidelines. Or measuring complexity (does the model produce an overly complex solution? maybe count number of lines or cyclomatic complexity).
Commenting & Docstrings: If part of the task is to generate documentation, you could measure comment density or completeness of docstrings. Some evaluations require the model to produce an explanation with code, which then you might evaluate using text metrics (like is the explanation accurate, etc.).
Security/safety of code: If generating code for real systems, one might also evaluate if the code has obvious vulnerabilities. There’s research on using static analysis tools on AI-generated code to catch issues.

When to use what: choosing the right metrics

For informative tasks (QA, assistants): combine accuracy/factuality metrics with helpfulness metrics. E.g., measure correctness of answers and have users rate helpfulness. Also include a safety metric like automated Toxicity or PII detection to ensure no harmful outputs.
For creative tasks (story generation, open dialog): focus on quality metrics like coherence, fluency, and use a distribution metric (MAUVE) or human preference to see which model is more engaging. Safety still, of course, if public-facing.
For transformation tasks (translation, summarization): use reference-based metrics (BLEU/ROUGE/BERTScore) for a quick check, but augment with human eval for nuance like adequacy and fluency. Ensure to check faithfulness for summarization, potentially using automated Faithfulness scorers.
For code: prioritize functional tests, then perhaps track edit distance to solution as a secondary. If multiple outputs are allowed, use pass@k.
For RAG systems: evaluate the pipeline: retrieval quality (maybe as separate metrics) and final answer quality (accuracy/factuality/faithfulness using metrics like W&B's Faithfulness scorer). If performance is lacking, these metrics can tell you if the bottleneck is retrieval or the generation step.
Across all: always keep an eye on safety metrics (toxicity, bias, PII). Even if it’s not the main goal, you don’t want to deploy a model that scores poorly on these. They can be included as “guardrail metrics” (like those offered by W&B Weave) that must be above a threshold to consider the model deployable.

Strengths and weaknesses of different metrics

Perplexity: Strengths: Direct measure of language model fit; easy to compute for causal LMs; good for model development (lower PPL generally = better model). Weaknesses: Doesn’t ensure outputs are correct or relevant; not interpretable to non-ML stakeholders; not applicable to all model types.
BLEU/ROUGE: Strengths: Easy to understand (n-gram overlap); quick to compute; good for detecting major content alignment with references; established in literature (baseline for many tasks). Weaknesses: Poor at capturing meaning; penalize legitimate variation; can be gamed by lengthy outputs; low correlation with human quality on free-form tasks.
BERTScore/Embedding metrics: Strengths: Capture semantic similarity; more tolerant to phrasing differences; better correlation with human judgments on many tasks. Weaknesses: Depend on a specific pre-trained model (may not work equally on all domains/languages); harder to explain; moderate computation cost.
MAUVE / distribution metrics: Strengths: Evaluate general text quality without references; good for creative/open-ended text; correlates with overall human-likeness. Weaknesses: Need many samples; doesn’t pinpoint errors in individual outputs; if the domain requires factuality, MAUVE alone won’t catch factual errors.
Accuracy/Exact Match: Strengths: Clear-cut correctness measure; easily understood; directly reflects task success; no fancy computation needed. Weaknesses: Only works when a single correct answer or classification is defined; too strict for nuanced answers; doesn’t capture partial credit unless you also use F1 or similar.
Factuality/Faithfulness (auto eval): Strengths: Targets one of the most important failure modes (hallucination); if you have a knowledge source, can automatically catch blatant errors; improves trust in model outputs. Weaknesses: Hard to automate fully; risk of false alarms or misses; often requires human verification or very good reference data. Automated tools like W&B's Hallucination scorer help but aren't perfect.
Toxicity/Bias/PII metrics: Strengths: Essential for safety; can automatically scan lots of outputs for red flags using tools like W&B's Toxicity and PII scorers; helps maintain ethical standards. Weaknesses: Classifiers can be imperfect (possible bias in the detector itself); might need continual updates; only catch surface-level issues.
Helpfulness/Human preference: Strengths: Ultimately reflects what users care about; broad and can capture things automated metrics miss; when used in RLHF, leads to big leaps in user satisfaction. Weaknesses: Expensive (requires human ratings) or approximate (LLM judges aren’t perfect); can be inconsistent if not carefully calibrated; may conflict with other metrics (a model might be very helpful but occasionally hallucinate – which do you prioritize?).

Aligning metrics with human judgment: challenges

Low correlation in open-ended tasks: As research has noted, traditional metrics (BLEU, ROUGE) have relatively low correlation with human judgments, especially for creative tasks. This means a model that humans rate highly might not score highest on these metrics, and vice versa. It’s crucial to validate that your chosen metrics do correlate with human preferences for your task. If not, you might need to incorporate human eval in the loop.
Reference bias: Metrics that use reference answers assume the reference is the gold standard. But sometimes human references can be sub-optimal or one of many possible good answers. Humans might judge an LLM response better than the original reference (!), but the metric would penalize it for deviating from the reference. This has been observed in tasks like summarization, where an LLM might phrase something more clearly than the reference – a human would prefer the LLM output, but ROUGE would prefer the reference.
Human variance: Human evaluators themselves can disagree. What one person finds “helpful”, another might find “condescending”, for example. This makes it hard to get a single ground truth. The best practice is to have multiple ratings and average them, and ensure evaluators are well-trained on the criteria. Even then, there’s noise. Metrics like rank correlation (Spearman’s) are used to measure how well an automatic metric matches the ranking that humans would produce for a set of outputs. A metric might have, say, 0.5 correlation – which is decent but far from perfect alignment.
Evolving definitions: What is considered toxic or harmful can change, and companies may tighten guidelines over time. So a model that passes today’s safety metric might fail tomorrow’s stricter evaluation. Also, user expectations rise – an “acceptable” level of factual error a year ago might be unacceptable after users have seen a more advanced model that rarely makes such mistakes.
Complex multi-dimensional quality: A single scalar metric can’t capture the full multi-dimensional nature of “good” conversation or text. For instance, a dialogue response might be perfectly accurate (factuality=100%) but very terse (low helpfulness). Humans weigh these aspects depending on context. Automatic metric frameworks are being developed where you combine multiple scores (maybe a weighted sum or a vector of metrics). Some academic works attempt to learn a model that predicts a “human score” from various features (including those metrics). That’s essentially what GPT-4 as a judge is doing implicitly – using its knowledge to weigh different factors.
LLM as evaluator bias: Using LLMs to evaluate other LLMs (LLM-as-a-judge or “GPT-4 based grading”) is promising and has shown high agreement with humans in some studies. But it can introduce biases: for example, an LLM judge might favor outputs that mimic its own style. There’s a known concern that LLM judges might give higher scores to text that looks AI-generated vs. truly human responses (one paper noted GPT-4 preferred GPT-4’s outputs in some cases, a form of model bias). Thus, while LLM grading is useful, it’s good to mix in real human checks to calibrate it.

How to address these challenges?

Conclusion and best practices

Mix objective and subjective metrics: Use automatic scores for speed and scale, but include human-aligned evaluations for quality and safety aspects that are hard to quantify. For example, track perplexity or accuracy alongside user ratings and automated safety flags like Toxicity.
Leverage task-specific metrics: Tailor your evaluation to what success means for your application. If it’s code, run the code. If it’s a dialog, measure goal completion or user satisfaction. If it's RAG, use Faithfulness scorers. Generic scores are a starting point, but custom metrics capture what really matters for your use case.
Set up guardrails: Define threshold criteria for safety and quality using specific evaluators. For instance, “No more than X% of outputs can be flagged toxic by the Toxicity scorer” or “At least Y ROUGE on key summaries”. Tools like W&B Weave Guardrails can automate the application of these scorers (like Toxicity, PII, Hallucination) during evaluation, flagging problematic outputs and preventing the deployment of models that score outside acceptable bounds.
Use evaluation frameworks: Tools like W&B Evaluation help run evaluations reproducibly. They allow you to log each model’s outputs on a fixed test set, compute all your metrics (including scores from Guardrails), and compare results side by side. This makes A/B testing between model versions much easier – you can see that “Model B improved factuality by +10% but had slightly lower helpfulness by -5%, with safety unchanged, for example.”
Don’t over-optimize one number: Be wary of chasing a single metric too hard. Maintain a balanced scorecard. It’s often useful to have a table of metrics for each model (see Table 2 for an illustration) so you can make an informed decision beyond “this one number went up”. For instance:

Continuously update evaluations: As you encounter new failure modes (e.g., a specific kind of hallucination or user complaint), incorporate that into your test suite or metrics (perhaps by creating a custom scorer). Evaluation is an ongoing process, not a one-time checklist. The field of LLMs is evolving, and so are evaluation techniques – stay updated with the latest research on metrics and consider adopting new ones that might suit your needs (for example, new LLM-based evaluators or adversarial testing methods).

Resources

LLM Evaluations: Metrics, Frameworks, and Best Practices
AI Guardrails
Hugging Face Transformers Documentation
BERTScore
MAUVE: Measuring the Gap Between Neural Text and Human Text
BLEU: A Method for Automatic Evaluation of Machine Translation
ROUGE: A Package for Automatic Evaluation of Summaries
METEOR: An Automatic Metric for MT Evaluation with Improved Correlation with Human Judgments
Self-BLEU: Measuring Diversity in Text Generation
TruthfulQA: Measuring How Models Behave in the Face of Adversarial Questions
FactCC: A Neural Approach for Factual Consistency Checking
OpenAI Moderation API –
Perspective API
Codex: Evaluating Code Generation by Large Language Models
Learning to Summarize with Human Feedback