I Showed Cloudflare's Clef an Image of a Document (in English) and Had It Find Errors in the OCR Results

Hello, I'm Keima.

For OCR processing of documents on AWS, one approach is to host an OCR model on Amazon SageMaker to extract text, then use a downstream LLM to structure keys and values while making use of the character recognition confidence scores.
However, hosting a model on SageMaker around the clock tends to get expensive, and because multiple services are combined, the architecture also tends to become heavy.

Recently, the character recognition accuracy of VLMs themselves has improved, so a setup where a VLM alone handles everything through extraction has become practical.
However, the confidence scores an LLM outputs tend to be self-reported, and it can give high scores even to misread values, so they are a weak basis for judgment that cannot be fully trusted.
On the other hand, calling yet another LLM just for verification would add further cost.

Clef, released on Cloudflare Workers AI on October 1, 2026, is a decision model that supports image input and returns probabilities directly in response to questions.
Because it runs lightweight and at low cost, I thought it might be suitable for independently checking extraction results.

So in this article, I pass a document image and its extraction results to Clef, have it judge "Is this value exactly as in the image?", and test whether it can find errors in OCR results.

1. Test conditions

First, I had Claude Haiku 4.5 extract fields from English quotes, invoices, and receipts (3 documents, 91 fields in total), trying to detect naturally occurring errors.
However, Haiku turned out to be better than expected and extracted every field correctly, so for this test I intentionally injected 3 patterns of errors (12 each, 36 in total).

The breakdown of the injected errors is as follows.

• Digit change (12): change just one digit of an amount or date ($1,150.00 → $1,160.00, 09/18/2026 → 09/19/2026, etc.)

• Change to a similar character (12): replace with a character easily confused in OCR (0 → O, 1 → l, m → rn, etc.)

• Replacement with a different value (12): replace with another word that is not unnatural in context (SAMPLE MART → FRESH MARKET, Service → Hardware, etc.)

The judgment and verification conditions are as follows.

• Judgment method: pass one document image and the extraction results, and for each field ask with noul (a question that returns the probability of yes) "Is this value exactly as printed in the image?" A probability below 0.5 is judged as an "error"

• Models: clef (27B) and clef-flash (9B)

{
  "model": "clef",
  "images": ["data:image/png;base64,..."],
  // state: premise for the judgment (an OCR system read the invoice image and extracted keys and values)
  "state": {
    "task": "An OCR system read the attached invoice image ...",
    "extracted": { "invoice_no": "INV-2026-0042" }
  },
  "questions": {
    "field.invoice_no": {
      "type": "noul", // a yes/no question. Returns the probability of yes
      // instructions: judgment instructions (Does the extracted invoice_no value match the string printed in the document image exactly, character for character?)
      "instructions": "Is the extracted value of \"invoice_no\" (\"INV-2026-0042\") exactly what is printed in the document image, character for character?"
    }
  }
}

The invoice used in the test

2. Results

2.1 Could it find the errors?

Clef returns, for each field, the "probability that the value matches the image."
Fields with a probability below 0.5 were judged as "errors," and I counted the results from the following two perspectives.

• Error detection: Of the 36 injected errors, the number correctly judged as "errors"

• Correct values judged as errors: The number of values that were actually correct but were judged as "errors" (false positives).

clef detected all of the injected errors and had 0 false positives.
On the other hand, clef-flash had 3 false positives, where fields that should have been correct were wrongly judged as "errors (probability below 0.5)." The fields involved were as follows, and all of them were amount-related fields such as the total amount.

• The quote's Total was falsely flagged in each of two trials, so the count is 3 in total, but the fields themselves are the two kinds above.

The match probabilities for all 36 injected errors are as follows.
These values represent "the probability that the extracted value is correct according to the image," so the lower the number, the more strongly the model suspects that it "does not match the image (is an error)."

2.2 How the probabilities separate

To see where the threshold should be set, I summarized the spread of the "probability that the value matches the image" assigned to the error fields (36) and the correct fields (237).
The bottom 5% and top 5% are the values at the 5% and 95% positions from the bottom when the probabilities are sorted from lowest to highest.

For the correct fields, both models gave high probabilities with medians in the 0.9s (clef: 0.914, clef-flash: 0.940).
Looking at the bottom 5%, clef was at 0.769 and clef-flash at 0.645, so some fields came out somewhat low.

The results when changing the threshold are as follows.

At every threshold, both models caught all 36 injected errors.
The difference was in the number of false positives: the higher the threshold, the more correct values get sent to human review.
With clef, there were 0 false positives at 0.5 to 0.6, but at 0.8 about 10% of the correct values (23) would be sent to human review.
clef-flash had 3 false positives even at 0.5, and at 0.8 it reaches about 20% (50), so clef is better suited if you want to keep the review effort down.
However, since the error data is only 36 cases, for actual operation I recommend collecting similar statistics on the documents you handle and deciding the threshold from them.

2.3 Time and cost

The requests to Clef were made once per document.
In each request, I sent one image together with the questions for all fields of that document (21 to 38 questions).

Times are measured values when calling the REST API from within Japan, and costs are converted at 150 yen per dollar.
Extraction by Haiku takes about 10 to 13 seconds per document, so adding this check barely changes the overall processing time.

3. Summary

As far as I tested with three English documents, clef, given the images, detected all the injected errors and had no false positives.
However, the errors this time were injected artificially, so I have not confirmed performance against the kinds of misreadings Haiku itself makes.

If you incorporate this into a document extraction check, rather than having the VLM self-report the correctness of its own extraction results, an effective setup is to pass the results together with the image to a lightweight decision model like Clef and have it double-check.

References

• Models: clef | Cloudflare Workers AI docs

• Changelog: Introducing Clef: Cloudflare's first open-source decision models, now on Workers AI | Cloudflare Docs