Case study · AI Engineering · Forward Deployed · Data Engineering
LLM Extraction with Evals: Know When to Trust the Output
Extracts invoice fields with Claude or Gemini, keeps the exact text behind every value, scores each field and sends doubtful documents to a person.
The problem
Getting JSON out of an LLM is easy. Knowing whether to trust it is the hard part: a model can return a clean, valid value that is simply wrong, like the customer's tax ID instead of the seller's. Average accuracy hides which documents are wrong.
Constraints
- Every value must point to the exact text it came from, so a person can check it in seconds
- Claude and Gemini behind one interface and one prompt, so scores compare models, not wording
- Tests and CI must run with no API key and no cost
Architecture and decisions
Click a box to see why it was chosen.
Why · Claude
messages.parse() with a Pydantic schema: the SDK returns a validated object. Refusals, truncated output and API errors become an empty result, logged with the document ID, so one failure never stops a run.
Results
- generated invoices in 4 layouts, each with traps
- 60
- generated invoices in 4 layouts, each with traps
- baseline: fields right vs documents fully right
- 86% vs 25%
- baseline: fields right vs documents fully right
- of baseline auto-accepted documents fully right: what the eval exists to catch
- 33%
- of baseline auto-accepted documents fully right: what the eval exists to catch
- tests; Claude and Gemini code tested with fake clients
- 29
- tests; Claude and Gemini code tested with fake clients
What I would do next
- 01Commit Claude and Gemini runs and compare them with the baseline
- 02Use the evidence to highlight each value in a review screen
- 03Add scanned PDFs so the eval also covers OCR noise