Self-Evaluation and Reliability Checks

A model can review a draft, look for missing requirements, or say how confident it feels. These checks can be useful, but a polished critique does not prove the answer is right. If the model and reviewer share the same blind spot, asking it to “check again” may only produce a more persuasive version of the same mistake.

In this lesson, you will learn how to ask for a focused critique, what confidence means, and how to choose an independent check when accuracy matters. The examples are illustrative. I have not run them through a live model.

Give the reviewer something to check

“Check your answer” is an open-ended instruction. The model must guess what matters, decide what counts as correct, and decide when it has reviewed enough. A more useful review has three parts:

1. The original task. What was the answer supposed to do?
2. The answer to review. Which draft or response should be checked?
3. A short rubric. What properties must pass, and what should happen if one fails?

For example, suppose the task was to reply to a customer who asks whether a replacement will arrive before Friday. The order record says the replacement has not shipped yet. A vague review request might be “Is this response good?” A more focused one would be:

1Review this reply against the requirements below.
2
3Requirements:
4- It must not promise delivery before Friday because no shipping date is available.
5- It must explain that the replacement has not shipped yet.
6- It must offer a useful next step.
7
8Reply with any unmet requirement and the phrase that caused the problem.
9If all requirements pass, say “Pass.” Do not rewrite the reply.

The specific rubric makes a review more actionable. It also limits scope. A reviewer asked to improve tone, accuracy, length, policy compliance, and empathy all at once may generate a broad opinion without pointing to a testable issue.

Critique and revision are separate decisions

A review can lead to a revision, but it should not automatically replace the answer. Consider an illustrative draft:

Your replacement is on its way and should arrive before Friday. Please contact us if it does not.

The record only says the replacement has not shipped. A focused critique could flag “should arrive before Friday” as an unsupported promise. You can then decide whether to ask the model to revise that sentence, supply a verified delivery estimate, or request human review.

Keeping critique and revision separate has practical benefits. You can inspect whether the critique is valid before applying it. You can keep the original answer if the revision adds a new error. You can also stop if the answer already passes. A model should not be allowed to invent facts to make a reply sound more helpful.

One simple critique prompt could be:

1Compare the answer with the task and requirements.
2List only specific failures. For each one, quote the relevant words and name the requirement it fails.
3Do not rewrite the answer or add facts. If you find none, reply “No specific failure found.”

This wording asks for evidence from the answer. It cannot guarantee a correct critique, but it is easier to inspect than “think carefully and improve this.” If the critique says “unsupported promise,” you can locate the exact promise and compare it with the source record.

The Self-Refine paper studied a loop in which one language model generated an output, provided feedback, and revised it. Its abstract reports improvements over one-step generation across the paper’s tested tasks. That is evidence that feedback loops can help in some settings, not a promise that every self-review will improve every answer. In contrast, the self-correction study found that models struggled to correct reasoning without external feedback, and sometimes performed worse after correction. A useful distinction is whether the review receives new information, such as a rubric, source, test result, or failing example, or simply asks the model to reconsider its own guess.

Confidence is a signal, not a guarantee

When a model says “I’m 90% confident,” it is producing a confidence statement. It is not automatically a measured 90% chance that the answer is correct. Confidence is calibrated when, across many answers assigned a particular confidence level, the observed accuracy is close to that level. For instance, among many answers labeled 80% confident, roughly 80% would need to be correct for that group to be well calibrated.

You cannot tell whether a confidence score is calibrated from one answer. It takes a set of representative questions with known outcomes. Group answers into confidence ranges and compare each range’s average confidence with its actual success rate. If answers labeled 90% are correct only 65% of the time, the confidence is too high for that task and setup.

The primary study Language Models (Mostly) Know What They Know examined model self-evaluation and the ability to predict which answers are correct. Its abstract reports promising results for some formats, while noting challenges calibrating “I know” predictions on new tasks. Another study, Just Ask for Calibration, found that verbal confidence statements from the tested RLHF models could be better calibrated than their conditional probabilities on specific benchmarks. These findings are about evaluated models, datasets, and elicitation methods. They do not make a confidence sentence from an arbitrary model or task a dependable probability.

If you need a confidence estimate for a real workflow, test it on examples similar to the intended use. Decide what happens at each confidence level. A low-confidence result might be routed to a person, while a high-confidence result might still need a deterministic check. If a wrong answer has serious consequences, do not let a self-reported number be the only gate.

A self-check can repeat the original mistake

A self-review is not independent just because it happens in a second message. The same model may rely on the same mistaken assumption, overlook the same missing source, or interpret the rubric in the same way. A fresh call can sometimes catch a problem, but it can also agree with the first answer for the wrong reason.

Think about a summary that says a policy allows a customer to return an item within 30 days. If the policy actually says 14 days, asking the model “Are you sure?” may not expose the error. Asking it to quote the exact supporting sentence from the supplied policy is better, because it must point to evidence. A simple program can also compare the stated number with a field extracted from a trusted policy database. A staff member can resolve ambiguity in the policy itself.

A useful principle is to match the check to the possible failure:

No check is perfect. A code validator only checks the properties it was written to check. A source can be outdated. A human can overlook details. But independent checks are useful because they can bring information or methods the original generation did not have.

Choose the lightest check that answers the question

For a low-stakes personal draft, reading it yourself may be enough. If the request has an exact length or format, a quick script may be enough. If it summarizes a document, ask for specific claims and citations, then compare them against the original. For a consequential decision, an expert may need to review both the source and the answer.

The order can be simple:

1. Write down what “correct” means for this task.
2. Check properties that can be tested exactly with code.
3. Use a focused model critique for qualities that need language judgment.
4. Independently verify factual claims against a source.
5. Send uncertain or consequential cases to a person with the right context.

The same answer can require more than one check. A response might pass a word-count test and still invent a delivery date. A citation may point to the right document but fail to support the sentence. Check the thing that could actually go wrong, not just the thing that is easy to count.

For a broader agent workflow with generator and evaluator roles, stopping rules, and iterative revision, see the AI Agents lesson on self-critique and evaluator-optimizer. This lesson focuses on reading a model’s answer critically; an agent review loop adds orchestration and execution decisions.

Keep a small record of whether checks work

If a check is part of an application, test it on examples where you already know the outcome. Include routine cases and tricky ones: incomplete context, near-miss values, ambiguous wording, and answers that look plausible but are wrong. Compare the critique with the known issues. Does it catch the missing fact? Does it flag a correct answer by mistake? Does it consistently pass confident-sounding errors?

Record the task, model and prompt version, rubric, original answer, critique, independent result, and whether someone accepted or corrected it. Protect private information and follow your data handling rules. This history helps distinguish an evaluator that sounds strict from one that catches real errors.

If the check misses a class of mistakes, improve the evidence or criteria. A reviewer cannot find a source omission if the source was never provided. A rubric cannot check “polite” consistently unless you explain what that means for the task. A number needs a known reference value. More rounds are not the fix when each round sees the same incomplete information.

The next lesson, define success and build test cases, turns these criteria into examples you can use to compare prompts. A check becomes more useful when you can describe what should pass and measure whether it does.

Mistakes beginners make

1. Asking only “Are you sure?” That may repeat the same unsupported answer. Name the criteria and request evidence.
2. Treating a confidence score as a probability without checking it. Measure calibration on representative examples before relying on it.
3. Assuming a second message is an independent reviewer. Independence comes from different evidence, methods, or expertise, not just another turn.
4. Letting a critique rewrite the answer automatically. Inspect the issue first, then decide whether a revision is warranted.
5. Using a model to check something code can check exactly. Use deterministic checks for sums, schemas, required fields, and length limits.
6. Checking only formatting. A valid JSON object can still contain false facts or unsupported claims.
7. Calling a citation verified without opening it. Confirm that the source says what the answer claims.
8. Using confidence to bypass human review in a high-stakes case. Route decisions according to risk and the quality of the available checks.

Recap and try it yourself

A model can critique its own answer, especially when given a clear task and rubric. It may find omissions or improve a draft, but it can share the original answer’s blind spots. Confidence is worth measuring across many examples; a single confident sentence is not a guarantee. Use code for exact checks, sources for factual support, and human judgment for ambiguity or consequential decisions.

Try this with a short, non-sensitive answer you can verify:

1. Write down three requirements the answer must meet.
2. Ask a model for a first draft, then ask it to list specific failures against those requirements without rewriting.
3. Check each claimed failure yourself. Mark it valid, invalid, or uncertain.
4. Ask for a revision only if a valid issue exists. Then re-check the result against the same requirements.
5. Note what the critique caught, missed, or incorrectly flagged.

For a stronger experiment, repeat this on ten examples with known outcomes. Count how often the critique catches a real issue and how often it raises a false alarm. If it does not help, add better evidence, sharpen the rubric, or use a more independent check. The purpose of a review prompt is to make a specific check easier, not to transfer responsibility for correctness to the model.