Skip to main content
LLM judge evaluators use a secondary model to assess output quality. multivon-eval uses QAG scoring (Question-Answer Generation) — generating binary yes/no questions about the output instead of asking for a numeric 1-10 rating. Why QAG? Binary questions are easier for LLMs to get right, fully auditable (you see which questions passed), and cheaper (shorter prompts).

Configuration

JudgeConfig

The judge model is fully decoupled from your pipeline model. Configure it once globally, override per-evaluator, or fall back to environment variables.
Resolution order (highest to lowest):
  1. Per-evaluator judge= kwarg
  2. configure() global
  3. JUDGE_PROVIDER / JUDGE_MODEL environment variables
  4. Built-in default: anthropic / claude-haiku-4-5
Changed in 0.16.0: temperature, max_tokens, timeout, and reliability_sample now default to None, meaning “inherit from the global config” — they resolve to the same effective defaults as before. The old merge compared overrides against the default values, so an explicit JudgeConfig(temperature=0.0) was silently ignored whenever a nonzero global was configured. Explicit values — including 0.0 — now always win.
The model under test and the judge model can be different providers.

Local and self-hosted models

Any OpenAI-compatible server works as a judge — Ollama, LM Studio, vLLM, llama.cpp, or a self-hosted endpoint:
base_url is also read from the OPENAI_BASE_URL environment variable, so no code changes are needed to switch between cloud and local judges in CI.

Calibrated thresholds

Faithfulness, Hallucination, and Relevance automatically apply the optimal threshold for the configured judge model, derived from benchmarks against human-labeled datasets. You don’t need to tune this manually. Pass threshold= explicitly to override:
To inspect the full calibration table:

UNKNOWN verdicts

New in 0.16.0. QAG scoring asks the judge binary yes/no questions — but judges hedge, and a hedge is not a verdict. The parser now has three outcomes per question:
  • A reply starting with “yes”/“no”, or containing exactly one unambiguous verdict word, parses as before — the calibrated thresholds above were fit under these semantics, and they are unchanged.
  • A reply with no unambiguous verdict is UNKNOWN: excluded from the score denominator entirely and disclosed in the result reason, e.g. 1 of 3 question(s) UNKNOWN — excluded from score denominator. An UNKNOWN never counts for or against the model.
  • If every verdict for a case is unparseable, the evaluator raises JudgeUnavailable and the case gets JUDGE_ERROR status — excluded from pass_rate, counted in report.errors.
One honest sentence about the past: before 0.16.0 the parser fell back to “does ‘yes’ appear in the first 50 characters”, so a judge replying “I cannot say yes or no with certainty” was scored as YES. That yes-bias is gone; the previously mis-scored tail is now UNKNOWN.

Error budget: max_error_rate

New in 0.16.0. pass_rate excludes errored cases by design — a judge outage is not a quality regression. The blind spot: 90 judge errors plus 10 passes is a 100% pass rate, and a fail_threshold gate would wave it through. max_error_rate closes it:
Available on suite.run, run_async, and run_on_cases. With max_error_rate unset, a fail_threshold gate still warns loudly on stderr when the error rate reaches 10% — the same threshold view --dir flags. report.error_rate exposes the number directly (denominator is total, not evaluated — this is exactly the metric pass_rate cannot see, so read the two together).

Faithfulness

Checks that the output is grounded in the provided context — no invented facts. When to use: RAG pipelines, document Q&A, or any task where the model must answer strictly from a provided source.
Requires context on the EvalCase.

Hallucination

Checks that the output doesn’t introduce claims not supported by context. When to use: Complement to Faithfulness — Faithfulness checks what’s present in the answer; Hallucination checks what shouldn’t be there.
Requires context.

Relevance

Checks that the output actually addresses the input question. When to use: Catch evasive, off-topic, or boilerplate responses that technically answer but don’t address what was asked.
No context required.

Coherence

Checks that the output is clear, well-structured, and logically sound. When to use: Long-form generation (articles, reports, explanations) where logical flow and clarity matter.

Toxicity

Checks that the output is safe, non-harmful, and appropriate. When to use: User-facing products, content moderation pipelines, or any deployment where harmful output is unacceptable. Score 1.0 = not toxic; 0.0 = toxic.

Bias

Checks that the output is free of demographic, political, or cultural bias. When to use: HR tools, news summarizers, recommendation systems, or any application where systematic favoritism is a risk. Score 1.0 = no bias detected; 0.0 = significant bias.

Summarization

Checks that a summary captures the key points of the source faithfully, without adding or omitting critical information. When to use: Summarization pipelines — news, legal documents, meeting transcripts.
Requires context (the source document).

AnswerAccuracy

Checks factual correctness of the output against expected_output. Uses judge comparison rather than string matching, so paraphrasing is handled correctly. When to use: Knowledge QA, fact retrieval, or any task with a known correct answer where the phrasing may vary.

ContextPrecision

For RAG systems: checks that retrieved context chunks are actually relevant to the question. High precision = low noise in retrieval. When to use: Evaluating the retrieval stage of a RAG pipeline independently from generation.
Accepts context as either a string or a list of strings (chunks). Evaluates up to 8 chunks.

ContextRecall

For RAG systems: checks that the retrieved context contains everything needed to derive the expected answer. When to use: Diagnosing retrieval gaps — cases where the model gave a wrong answer because the right chunk wasn’t retrieved.
Requires both context and expected_output.

CustomRubric

Define your own yes/no criteria. Each criterion is a (question, expected_answer) tuple. Score = fraction of criteria where the judge’s answer matches expected_answer. When to use: Domain-specific quality checks that don’t map to the built-in evaluators — support tone, legal disclaimers, brand voice.

GEval

Holistic numeric scoring for qualities that don’t decompose well into yes/no questions (creativity, tone, polish). The judge returns a 0.0–1.0 score directly with reasoning. When to use: Subjective qualities like writing style, creativity, or polish where binary questions don’t capture the nuance. Use sparingly — less auditable than QAG evaluators.
GEval is the only evaluator that uses a numeric score directly from the judge rather than QAG aggregation.

CheckEvaluator

The fastest way to add a quality check. You write a plain-English criterion; CheckEvaluator auto-generates specific yes/no questions from it and scores with QAG. No need to pick an evaluator class or write questions manually.
Questions are generated once at the start of suite.run() (eager warmup), so no case pays the generation cost and failures surface before the eval loop starts.

Escape hatch: pin questions for CI

Generated questions vary per run and per model. For reproducible CI runs, pin them explicitly:
When questions= is set, no LLM call is made during prepare().

Inspect generated questions

Discrete scores for N questions

With the default num_questions=3, the only possible scores are 0.0, 0.33, 0.67, and 1.0. The default threshold of 0.7 therefore requires 3/3 questions to pass. Lower the threshold or use num_questions=5 if you want more granularity.

Fallback behavior

If question generation fails after two attempts, CheckEvaluator issues a warnings.warn and falls back to using the criterion itself as a single yes/no question. The EvalResult reason will include a [⚠ question generation failed — using fallback] tag. Check ev._used_fallback programmatically.