LLMs, GenAI, RAG, agents, evaluation · insight-0562
Check everything verifiable with code before reaching for an LLM judge
- Evidence type
- practitioner heuristic
- Difficulty
- easy
- Roles
- Applied AI, ML engineer
- Industries
- aviation
Summary: situation, action, reason, boundary
Situation
An eval pipeline sends every output to an LLM judge, including checks such as valid JSON, word limits and whether the booking reference matches the input.
Action
Split criteria into verifiable (schema validity, exact match, numeric tolerance, length, required keywords, unit tests) and judgment-based; implement the first group in code and reserve the judge for the rest.
Reason
Instruction-following benchmarks built on automatically verifiable instructions avoid both human cost and judge bias for those criteria.
Boundary
Any LLM eval suite.
Symptom or risk
Objective failures are scored inconsistently, judge costs grow, and judge bias contaminates criteria that never needed judgment.
Exceptions
Criteria such as tone, helpfulness and faithfulness of paraphrase still need human or model judgment.
Trade-offs
Writing checks takes engineering time, repaid on every run.
Pitfalls
Asking a judge whether a number is correct when the correct number is known.
Lessons and concepts
Claims and their sources
Zhou et al. built IFEval around automatically verifiable instructions, such as word counts and keyword frequency, to avoid the cost of human evaluation and the bias of LLM judges.