LLM-evaluaties

Relevant dimensions can include factual accuracy, instruction following, retrieval use, robustness, cost, and response time. A single preference score rarely captures all of them.

Key takeaways

• Evaluate the full application configuration.
• Validate grading methods themselves.
• Include abstention and adversarial cases.

Evaluate the system users actually receive. A model with retrieval, tools, and a particular prompt may behave differently from the same model tested alone. Preserve these settings with the evaluation record, including limits on tool calls and retries. Combine deterministic checks with judgments that require interpretation. Exact matching works for some extracted fields or executable tests, while a summary may need a rubric for evidence and omissions. Write the rubric so different reviewers can apply it consistently, and examine disagreements. A model can assist with grading, but its judgment is another measurement process with possible biases. Check it against independently reviewed examples, vary answer order where appropriate, and inspect whether it rewards verbosity or style more than correctness. Do not treat one model approving another as independent proof. Include unanswerable questions, conflicting sources, long-context cases, and malicious instructions in retrieved material when these are relevant. Report results by task and error severity. Retain failed examples as regression cases while refreshing held-out material so the evaluation does not become a memorized target.

1. Give a model an invented policy stating only that refunds are available within 14 days.
2. Ask whether shipping is refunded. A confident answer is unsupported because the policy does not say.
3. Score an answer that identifies the missing information more highly than an invented policy, even if the invention sounds more helpful.

This constructed case evaluates evidence handling rather than fluency.