cd /news/large-language-models/benchmarking-gemini-claude-and-opena… · home topics large-language-models article
[ARTICLE · art-96218] src=dev.to ↗ pub= topic=large-language-models verified=true sentiment=· neutral

Benchmarking Gemini, Claude, and OpenAI for Structured Document Extraction

A developer benchmarked Gemini, Claude, and OpenAI models for structured document extraction using LangSmith and LangGraph, finding that Gemini and Claude tied on field accuracy but Gemini achieved more perfect records. The evaluation highlighted that cost-efficient models like Gemini Flash Lite can outperform flagship models on field accuracy, and that no single model dominates across all metrics.

read4 min views1 publishedAug 14, 2026

A few fellow engineers and I were talking about field extraction the other day. They were both saying Gemini's been surprisingly good at pulling structured data off documents, which surprised me, since that's not really the model I'd have reached for first. So we ran an experiment using LangSmith.

I printed ten copies of a form with the usual set of fields, names, dates, IDs, a checkbox, a signature line, and asked my coworker to help me fill them out by hand. I ran OCR on them too, mostly out of curiosity. It was pretty bad, which wasn't unexpected, especially on checkboxes.

I set up a LangGraph graph with one node that does the extraction, and passed in which provider to use as runtime context, so the eval could run the exact same graph once per model:

def _extract(state: ExtractionState, runtime: Runtime[ExtractionContext]) -> dict:
    extractor = EXTRACTORS[runtime.context.provider]
    return {"result": extractor.extract(state["image_path"])}

I hand-labeled ground truth for every form and ran it all through LangSmith so I could score each model against the exact same data.

Scoring took a bit of tuning, mostly because a plain exact string match evaluator will ding a model for writing "Sr" instead of "Sr." or "management" instead of "Management," which isn't actually wrong, it's just formatting. So everything got normalized first (lowercased, trailing punctuation stripped, dates parsed into one format, phone numbers stripped down to digits) and scored three ways: fraction of fields correct for partial credit, whether the whole record was perfect for a stricter all-or-nothing exact match, and field accuracy per dollar.

Model Field accuracy Exact match Perfect records Field accuracy / cost
Claude (opus-5) 0.934 0.364 4/11 31.8
Claude (haiku-4-5) 0.636 0.091 1/11 207.2
Gemini (3.1-pro-preview) 0.934 0.636 7/11 93.1
Gemini (flash-lite-latest) 0.884 0.455 5/11 1084.8
OpenAI (gpt-5.6-sol) 0.860 0.455 5/11 50.6
OpenAI (gpt-5.4-nano) 0.620 0.091 1/11 814.4

Claude and Gemini ended up tied on average field accuracy, but Gemini still got a lot more whole forms completely right, which is a different thing to be measuring than it sounds like at first. The other thing that jumped out was the cheap tiers. Gemini's Flash Lite scored higher on field accuracy than OpenAI's flagship did, while Claude's Haiku and OpenAI's nano both fell off hard.

No single model won across the board, and that's kind of the whole point. Field accuracy, exact match, and cost efficiency measure different things, so a model that dominates one of them can easily be the weakest on another. What's nice about having an eval running is that switching which one you care about is just a matter of changing what you sort by.

A form that's 11 out of 12 fields right still needs someone to go fix that twelfth field, and that costs about the same as fixing a form that's only 6 out of 12 right, since either way a person has to open it back up. That's the case for caring about exact match instead of average field accuracy.

exact match and field accuracy per model with a baseline selected for exact match

Field accuracy gives partial credit for every field that's right, which matters more than exact match when a human is going to check every field anyway. Fewer wrong fields overall beats fewer broken records when the correction happens field by field instead of record by record.

exact match and field accuracy per model with a baseline selected for field accuracy

Cost efficiency matters most at volume, since a cheaper model that's a little less accurate can still get more forms extracted correctly per dollar than a pricier one that's only a little better.

exact match, field accuracy, and accuracy per dollar with a baseline selected for accuracy per dollar

So Chris and Mike were right, though the answer splits three ways. Gemini Pro won exact match and tied Claude Opus on field accuracy, and Gemini Flash Lite won on cost. Flash Lite is the one I didn't see coming, since it beat OpenAI's flagship on field accuracy too, at a tiny fraction of the price.

Benchmarking LLMs for Structured Data Extraction GitHub Repo

── more in #large-language-models 4 stories · sorted by recency
── more on @gemini 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/benchmarking-gemini-…] indexed:0 read:4min 2026-08-14 ·