This prompt is designed for evaluation pipeline architects who need a calibrated, repeatable metric for factual accuracy. The primary job-to-be-done is automated, scalable scoring of a generated answer against a known ground-truth reference. It is ideal for offline evaluation suites, CI/CD pipelines for prompt regression testing, and periodic quality monitoring dashboards. Use it when you are benchmarking RAG outputs, fine-tuned model responses, or any system where factual fidelity to a single, reliable answer is the primary quality signal. The prompt instructs an LLM to act as a judge, comparing the candidate answer to the reference and producing a score on a defined scale, along with a justification.
Prompt
LLM Judge Prompt for Factual Accuracy Evaluation

When to Use This Prompt
Understand the ideal job-to-be-done, required context, and clear boundaries for deploying an LLM judge to score factual accuracy.
This judge is not a hallucination detector for unverified claims. It assumes a trustworthy reference answer already exists. Do not use it when you lack a ground-truth, when you need to verify claims against raw source documents (use a claim-by-claim verification prompt instead), or when the acceptable answer space is broad and subjective. The judge is also unsuitable for real-time, user-facing guardrails due to latency and cost; it belongs in asynchronous evaluation workflows. For high-stakes domains like healthcare or finance, the judge's output should be treated as a signal for human review, not an autonomous pass/fail decision. Ensure your evaluation harness logs the judge's full reasoning alongside the score to enable calibration audits.
Before implementing, define your accuracy scale and partial-credit rules clearly within the prompt's rubric. The judge must handle partially correct answers, extraneous information, and subtle factual contradictions consistently. Pair this prompt with a regression test suite of scored examples to monitor judge drift over time. If you observe inconsistent scoring, calibrate the judge by providing few-shot examples of scored answer pairs. The next section provides the copy-ready prompt template you can adapt for your specific evaluation task.
Use Case Fit
Where the LLM Judge Prompt for Factual Accuracy Evaluation works well and where it breaks down. Use these cards to decide if this prompt fits your evaluation pipeline before you invest in calibration.
Good Fit: Regression Testing Against Golden Answers
Use when: you have a curated dataset of questions with verified ground-truth answers and want to catch factual regressions after prompt or model changes. Guardrail: run the judge prompt on a fixed golden set before every release; gate deployment on score thresholds that match your risk tolerance.
Good Fit: Calibrated Scoring with Defined Rubrics
Use when: you need a repeatable accuracy metric on a defined scale (e.g., 1-5) with clear criteria for partial correctness. Guardrail: include rubric anchors with examples in the judge prompt; validate inter-rater agreement between the LLM judge and human evaluators on a sample before trusting the metric.
Bad Fit: Open-Ended Subjective Quality Assessment
Avoid when: you need to evaluate style, tone, helpfulness, or creativity rather than factual alignment with a reference. Guardrail: use a separate judge prompt tuned for subjective dimensions; do not repurpose a factual accuracy judge for tasks it was not calibrated for.
Bad Fit: No Ground-Truth Reference Available
Avoid when: you lack verified reference answers and expect the judge to assess factual accuracy from source documents alone. Guardrail: this prompt compares answer to reference, not answer to evidence; use a source-grounded verification prompt instead when only documents are available.
Required Inputs: Answer, Reference, and Scoring Rubric
Risk: missing or ambiguous inputs produce unreliable scores. Guardrail: validate that the generated answer and ground-truth reference are both non-empty and semantically complete before invoking the judge; include the scoring scale and partial-credit rules explicitly in the prompt body.
Operational Risk: Judge Drift Over Time
Risk: the judge model's scoring behavior can shift after model updates, making historical scores incomparable. Guardrail: pin the judge model version; recalibrate against a human-annotated sample after any judge model change; log judge model version alongside every score for traceability.
Copy-Ready Prompt Template
A calibrated, repeatable LLM judge prompt that scores the factual accuracy of a generated answer against a ground-truth reference on a 0–5 scale with structured claim-by-claim analysis.
This prompt template is designed to be used as an automated evaluation step in a RAG or content-generation pipeline. It instructs the model to act as a factuality judge, decomposing a generated answer into discrete claims, comparing each against a reference answer, and assigning a holistic accuracy score. The structured JSON output makes it straightforward to integrate into CI/CD eval harnesses, regression test suites, or production monitoring dashboards. Use this when you have a reliable ground-truth reference and need a repeatable metric for factual fidelity—not for open-ended quality assessment or style evaluation.
textAct as an expert factuality judge. Your task is to evaluate the factual accuracy of a [GENERATED_ANSWER] against a [REFERENCE_ANSWER] for the given [USER_QUESTION]. Scoring Rubric (0-5 scale): - 5 (Completely Accurate): All factual claims match the reference. No omissions, no contradictions, no added incorrect facts. - 4 (Mostly Accurate): Minor omissions or imprecise language, but all core facts are correct and no false claims are present. - 3 (Partially Accurate): Contains a mix of correct and incorrect claims, or a significant omission of a core fact. - 2 (Mostly Inaccurate): More incorrect than correct claims, or the answer fundamentally misunderstands the question. - 1 (Completely Inaccurate): Almost all factual claims are wrong or contradicted by the reference. - 0 (Not Evaluable): The generated answer is empty, entirely off-topic, or a refusal to answer. Instructions: 1. First, extract the key factual claims from the [GENERATED_ANSWER]. 2. Compare each claim to the [REFERENCE_ANSWER]. Note if the claim is supported, contradicted, or absent from the reference. 3. Identify any extraneous information in the generated answer that is not present in the reference. Do not penalize for this unless it introduces factual errors. 4. Assign a score based on the rubric above. 5. Provide a brief justification for the score, citing specific claims. [USER_QUESTION]: {{USER_QUESTION}} [REFERENCE_ANSWER]: {{REFERENCE_ANSWER}} [GENERATED_ANSWER]: {{GENERATED_ANSWER}} Return your evaluation in the following JSON format: { "score": <integer 0-5>, "justification": "<string explaining the score>", "claims_analysis": [ { "claim": "<extracted claim from generated answer>", "verdict": "supported | contradicted | absent_in_reference | extraneous_but_harmless", "reference_evidence": "<relevant excerpt from reference answer or 'N/A'>" } ] }
To adapt this template, replace the {{USER_QUESTION}}, {{REFERENCE_ANSWER}}, and {{GENERATED_ANSWER}} placeholders with your actual data at runtime. The rubric is intentionally strict to produce calibrated scores; if your use case tolerates minor imprecision, adjust the score-4 description or collapse the scale. The claims_analysis array is the most valuable part of the output for debugging—use it to trace exactly which claims caused a score drop. For high-stakes domains such as healthcare or finance, always pair this automated judge with periodic human spot-checks and never treat the score as a sole release gate without human review of low-scoring samples.
Prompt Variables
Required inputs for the LLM Judge prompt to perform a reliable factual accuracy evaluation. Each placeholder must be populated before the prompt is sent. Validation notes describe how to programmatically check the input before execution.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[GROUND_TRUTH_ANSWER] | The verified, correct answer against which the generated answer is compared. | The capital of France is Paris. It has been the capital since the 10th century. | Must be a non-empty string. Check length > 0. If ground truth is unknown or unavailable, this prompt is not applicable; use a source-grounded verification prompt instead. |
[GENERATED_ANSWER] | The AI-generated answer that needs to be evaluated for factual accuracy. | Paris is the capital of France and was established as the capital in the year 987. | Must be a non-empty string. Check length > 0. If the generated answer is empty, the evaluation should return a score of 0 with a reason of 'no answer provided'. |
[EVALUATION_CRITERIA] | A structured description of the scoring scale, definitions for each score level, and rules for handling partial correctness and extraneous information. | Score 1: Completely incorrect. Score 2: Partially correct with major errors. Score 3: Mostly correct with minor omissions. Score 4: Fully correct. Score 5: Fully correct and complete. | Must be a non-empty string. Validate that it contains a numeric scale definition. If criteria are missing, the judge may apply inconsistent standards. Consider storing this as a reusable template variable. |
[FOCUS_AREAS] | Specific factual dimensions the judge should prioritize, such as dates, names, quantities, or causal relationships. | dates, numerical quantities, proper nouns | Optional. If provided, must be a comma-separated string or null. If null, the judge evaluates all factual content equally. Validate format if not null. |
[ALLOWED_TOLERANCE] | Instructions for how to handle near-matches, paraphrases, and semantically equivalent statements that differ in wording. | Treat 'approximately 1000 years ago' as equivalent to 'since the 10th century' for date ranges. | Optional. If provided, must be a non-empty string. If null, the judge applies strict literal matching. Document the tolerance policy in your eval run metadata for reproducibility. |
[OUTPUT_FORMAT] | The exact schema the judge must return, including field names, types, and descriptions. | JSON object with fields: score (integer 1-5), justification (string), errors_found (array of strings), missing_facts (array of strings) | Must be a valid JSON Schema string or a structured description. Parse and validate the schema before sending. If the output format is invalid, the downstream parser will fail. Include a retry instruction in the harness if the judge output does not conform. |
[FEW_SHOT_EXAMPLES] | Calibrated examples of generated answers, ground truth answers, and the expected evaluation output to anchor the judge's scoring behavior. | Example 1: Generated='Paris is the capital of France.' GroundTruth='The capital of France is Paris.' Output: {score: 5, ...} | Optional but strongly recommended for score calibration. If provided, must be an array of objects with generated_answer, ground_truth_answer, and expected_output fields. Validate the array structure. If null, the prompt should still function but may exhibit score drift across runs. |
Implementation Harness Notes
Wire this judge prompt into an automated evaluation pipeline with structured parsing, retry logic, and threshold gating.
This judge prompt is designed to be called programmatically, not used as a one-off chat interaction. Integrate it into your evaluation harness by calling the model API directly with response_format set to json_object if your provider supports structured output modes. If not, enforce JSON output with a robust parser and implement a retry loop that catches parsing errors, resubmitting the request with the malformed output and a correction instruction appended. The goal is a reliable, machine-readable score and justification that can feed into automated decision-making, not a human-readable summary.
Log the raw score, justification, and the full claims_analysis array to your experiment tracker or evaluation database on every run. This structured artifact is essential for debugging score regressions later—without it, you cannot trace why a particular answer received a low score. For CI/CD integration, set a minimum score threshold (e.g., 4 out of 5) and configure your pipeline to block a deployment if the average score across your eval dataset falls below that threshold. Run this judge across a representative sample of your evaluation dataset, not just a few hand-picked examples, to avoid overfitting your threshold to easy cases. If the judge model is weaker than the generation model you are evaluating, expect noisy scores; calibrate the judge's behavior by running it against a set of human-annotated samples first and adjusting your threshold or rubric language based on observed discrepancies.
Avoid using this judge as the sole gate for high-stakes factual accuracy decisions. Pair it with human review for a subset of outputs, especially when the judge's confidence is borderline or when the generation model operates in a domain where factual errors carry significant risk. Store the complete claims_analysis payload alongside each evaluated answer to enable retrospective analysis, judge model upgrades, and threshold recalibration as your system evolves.
Expected Output Contract
The structured JSON object the judge prompt must return. Validate each field before accepting the score.
| Field or Element | Type or Format | Required | Validation Rule |
|---|---|---|---|
factual_accuracy_score | integer (1-5) | Must be an integer between 1 and 5 inclusive. Reject if float, string, or out of range. | |
score_rationale | string | Must be non-empty and contain at least one explicit reference to a specific claim in [GENERATED_ANSWER]. | |
claim_verifications | array of objects | Array must not be empty. Each element must conform to the claim_verification schema. | |
claim_verifications[].claim | string | Must be an exact text span extracted from [GENERATED_ANSWER]. Reject if claim text is not found verbatim in the answer. | |
claim_verifications[].verdict | string (enum) | Must be one of: 'fully_supported', 'partially_supported', 'contradicted', 'unsupported'. Reject any other value. | |
claim_verifications[].evidence_reference | string or null | If verdict is 'fully_supported' or 'partially_supported', must contain a direct quote or specific passage reference from [GROUND_TRUTH]. If 'unsupported' or 'contradicted', must be null. | |
claim_verifications[].explanation | string | Must explain the reasoning linking the claim, evidence, and verdict. Reject if empty or purely generic. | |
overall_assessment | string | Must summarize the distribution of verdicts and justify the final factual_accuracy_score. Reject if length is less than 20 characters. |
Common Failure Modes
What breaks first when using an LLM judge for factual accuracy and how to guard against it.
Judge Hallucinates the Verdict
What to watch: The evaluator model fabricates a score or justification that does not match the provided reference text. This often occurs when the reference is long, complex, or contains conflicting information. Guardrail: Force the judge to quote the exact ground-truth span before assigning a score. Implement a secondary string-match check to ensure the quoted evidence actually exists in the reference.
Position Bias Skews the Score
What to watch: The judge consistently prefers the first answer presented in a pairwise comparison, or inflates scores for answers placed early in the context window. Guardrail: Randomize the order of the generated answer and the ground-truth reference in the prompt. Run multiple passes with swapped positions and flag the result if the score variance exceeds a defined threshold.
Stylistic Preference Masks Factual Errors
What to watch: The judge rewards fluent, authoritative, or well-formatted prose while ignoring factual inaccuracies. A confident-sounding hallucination often scores higher than a hedged, accurate statement. Guardrail: Explicitly instruct the judge to ignore tone, grammar, and style. Use a strict rubric that separates "factual accuracy" from "presentation quality" and requires a distinct score for each.
Partial Correctness Causes Binary Failure
What to watch: The judge assigns a failing score to an answer that is 90% correct because it contains a single minor error, or passes a mostly fabricated answer because it contains one true fact. Guardrail: Replace binary pass/fail logic with a multi-point ordinal scale (e.g., 1-5). Define clear anchors for each level, such as
Extraneous Information Penalty Leakage
What to watch: The judge penalizes the answer for including true, relevant information that simply wasn't present in the ground-truth reference, treating it as a hallucination. Guardrail: Distinguish between "unsupported" and "contradicted" in the prompt. Instruct the judge that extra information not found in the reference should be flagged as "Unsupported" but not treated as a factual error unless it directly contradicts the reference.
Self-Consistency Drift in the Evaluator
What to watch: The same judge prompt returns different scores for the same input pair when run multiple times, especially at high temperatures or with complex rubrics. Guardrail: Set the evaluator model temperature to 0.0 for deterministic outputs. If variance persists, implement a majority-vote ensemble across 3-5 judge runs and log the distribution to detect unstable evaluations.
Evaluation Rubric
Calibrated criteria for an LLM judge to score factual accuracy of a [GENERATED_ANSWER] against a [GROUND_TRUTH_REFERENCE]. Use this rubric to configure automated eval pipelines, set pass/fail thresholds, and diagnose specific failure patterns before shipping.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Core Factual Alignment | All key entities, dates, quantities, and named concepts in [GENERATED_ANSWER] match [GROUND_TRUTH_REFERENCE] exactly or with semantically equivalent paraphrasing. | A named entity is replaced with a different entity, a date is off by more than one unit, or a quantity is materially incorrect. | Parse both texts for named entities and numeric values. Perform exact and fuzzy string matching. Flag any mismatch where the edit distance exceeds a defined threshold. |
Absence of Fabricated Details | No claim in [GENERATED_ANSWER] introduces a specific fact not present in [GROUND_TRUTH_REFERENCE]. | The answer adds a specific name, number, event, or causal claim absent from the reference. Vague stylistic additions are ignored. | Decompose [GENERATED_ANSWER] into atomic claims. For each claim, run a semantic entailment check against [GROUND_TRUTH_REFERENCE]. Flag any claim with entailment score below 0.9. |
Handling of Partial Correctness | If [GENERATED_ANSWER] is partially correct, the score reflects the proportion of correct claims. Extraneous true facts from outside the reference are treated as neutral, not penalized. | A single critical error in a multi-claim answer causes a zero score. The judge penalizes correct supplementary information that was not requested. | Compute precision as (correct claims / total claims in answer). Use a human-annotated calibration set of 50 partial-correctness examples to validate the judge's scoring distribution. |
Omission Severity | Missing non-critical details (e.g., an adjective) does not reduce the score. Missing a core entity or event reduces the score proportionally. | The judge penalizes an answer for omitting a detail that was present in the reference but not strictly required by the question. | Create a dependency map of required facts from [GROUND_TRUTH_REFERENCE]. Score recall as (required facts present in answer / total required facts). Validate against a golden set of acceptable omission examples. |
Contradiction Detection | No statement in [GENERATED_ANSWER] logically contradicts [GROUND_TRUTH_REFERENCE]. | The answer states the opposite of a reference fact (e.g., 'increased' vs 'decreased') or asserts a mutually exclusive condition. | Use a dedicated contradiction detection prompt as a secondary judge. Feed the contradicting statement and reference passage. Require a binary verdict with a confidence score above 0.95 to trigger a failure. |
Extraneous Information Handling | The judge ignores information in [GENERATED_ANSWER] that is true but outside the scope of [GROUND_TRUTH_REFERENCE]. It does not penalize harmless additions. | The judge deducts points for any statement not explicitly found in the reference, even if factually true. | Classify each claim as 'in-reference', 'out-of-reference-true', or 'out-of-reference-false'. Only the last category triggers a penalty. Validate this behavior with 20 examples containing known true extraneous facts. |
Numerical Precision Tolerance | Numerical values within a configurable tolerance (default ±5%) of the reference value are considered correct. | The judge requires exact string match for numbers, failing answers that round or approximate correctly. | Extract all numerical values from both texts. Apply a relative error calculation. Flag only pairs where |answer_value - reference_value| / |reference_value| > tolerance. Confirm tolerance with domain experts. |
Score Calibration | The judge's 1-5 score correlates with human expert ratings at Spearman's ρ ≥ 0.8 on a held-out calibration set. | The judge exhibits score inflation, giving high scores to partially incorrect answers, or score deflation, penalizing stylistic differences. | Run the judge against a calibration set of 100 answer-reference pairs with three independent human expert ratings. Calculate Spearman's rank correlation. Recalibrate the rubric or prompt instructions if correlation falls below 0.8. |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt
Add a strict output schema with supported_claims, unsupported_claims, contradicted_claims, and an overall_score. Include calibration examples for each score level. Add a confidence field and require evidence spans for every verdict.
codeYou are a factual accuracy evaluator. Compare [GENERATED_ANSWER] to [GROUND_TRUTH_REFERENCE]. For each claim in the answer, classify it as: supported, unsupported, or contradicted. Provide the exact text span from the reference that supports or contradicts each claim. Return JSON matching [OUTPUT_SCHEMA]. Calibration examples: - Score 5: All claims match reference exactly, no extraneous claims - Score 3: Core claims supported, minor details missing or added - Score 1: Core claims contradicted or fabricated
Watch for
- Silent format drift when the model returns extra fields or omits required ones
- Missing human review for high-stakes domains
- Claim extraction failures when the answer uses implicit or inferred statements

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us