The thesis, again
Dharma-AI keeps running the same experiment: train a small model on a bounded task, benchmark it against frontier APIs doing that task in general, and measure the gap. In April they released DharmaOCR-LITE, a 3B-parameter OCR specialist that beat every commercial frontier model on Brazilian Portuguese documents. Now they've shipped Field Extractor, a 2-billion-parameter model for structured field extraction from documents—invoices, receipts, IDs, medical forms—and it scores higher than Claude Opus 5, GPT-5.6 Sol, GPT-5.6 Luna, and Gemini 2 Advanced while costing 6 to 147 times less per extraction.
The result is another data point for specialization over scale. Your production system doesn't need the biggest model available. It needs one trained close to your problem.
What field extraction actually is
OCR gives you the full text of a page, line by line, faithful to the original layout. That's perfect when you need the whole document—a contract, a manuscript, a court filing.
But most business workflows don't want the page. They want specific fields: the supplier name, invoice number, due date, and total off a vendor invoice. The patient name, exam type, and date from a medical requisition. Every line item on a receipt, with quantity and price, ready to load into a database.
Run those documents through OCR and you get back everything printed on them, with no indication of which string is which field. Someone still has to write the code that maps each value to the right column before it hits the system.
A frontier LLM can do this mapping today with careful prompting. At API pricing and latency, on a task many businesses run at high volume, that quickly becomes the expensive way to solve a well-defined problem.
Two request modes
Field Extractor handles extraction two ways, depending on what you already know about the document:
Open mode: no schema supplied. The model reads the page, figures out which parts are structured fields from context and layout—not from a hardcoded list of field names—and returns everything it finds as key-value pairs. Use this when you don't know what the document contains.
Schema-directed mode: you specify the exact shape wanted, field by field, with a type for each one (string, number, boolean), under the key names your system already uses. Ask for service_provider and client_company, and those exact keys come back. Ask for a table and it fills it row by row, matching each cell to the right column. Ask for a field that isn't on the document, and it returns null instead of hallucinating.
Either way, what comes back is JSON: fields as keys, values typed as requested, null where the document didn't have what you asked for. When you send a schema, the output follows it exactly—same keys, no extras—so it can go straight into the next system.
Training: LoRA on top of DharmaOCR-LITE v1.1
The base is DharmaOCR-LITE v1.1, a new 2-billion-parameter checkpoint optimized from the version in the original paper and already specialized for OCR through supervised fine-tuning and DPO.
On top of that they trained a LoRA adapter on 43,384 examples covering both request modes, organized into three streams:
- English multi-domain: diverse public web documents spanning many types
- Brazilian domain: real Portuguese documents sourced internally
- Multilingual: smaller coverage of European and Asian languages for broader generalization
All three streams are annotated at the field level. The mix is deliberately multi-domain—receipts, commercial invoices, forms, bank statements, IDs, synthetic documents—rather than optimizing for one narrow filing type.
The benchmark: 1,638 cases across three scenarios
The full benchmark covers 546 documents across three request scenarios, for 1,638 total cases: extracting every field with no schema, a partial schema naming only real fields, and a schema that also includes deliberately nonexistent fields (to test whether the model hallucinates or correctly returns null).
The score is field-level F1—matched by path, including position inside a table—multiplied by Levenshtein similarity on the values that matched, and multiplied by the share of outputs that come back as valid JSON.
They ran the same benchmark against four frontier configurations: Claude Opus 5 with adaptive effort, GPT-5.6 Sol, GPT-5.6 Luna, and Gemini 2 Advanced. All frontier models ran with reasoning set to low.
The results: higher quality, lower cost
Field Extractor scored 0.834. Every frontier model scored lower:
- Claude Opus 5: 0.816 (1.8 points behind)
- GPT-5.6 Sol: 0.779 (5.5 points behind)
- Gemini 2 Advanced: 0.750 (8.4 points behind)
- GPT-5.6 Luna: 0.741 (9.3 points behind)
On cost, the gap is even wider. Dharma's figure is GPU time on a single L40S at $2.24/hour—self-hosted, not billed per token. Frontier costs come from measured average input and output tokens per page (reasoning tokens included) against published list pricing.
The Field Extractor costs roughly 6× less than GPT-5.6 Luna and roughly 147× less than GPT-5.6 Sol per extraction.
This isn't sales pricing. Self-hosted cost depends on hardware, volume, and required latency. But the comparison shows that a sovereign SSLM, deployed on your own infrastructure, is a real alternative to frontier APIs—not just on quality, but on economics.
Generalization: SROIE and FUNSD holdout examples
Two public datasets in the benchmark—SROIE and FUNSD—were not used in training.
On a SROIE receipt, they asked for all 18 printed fields with no phantom fields. Every one came back correct: the multi-line unlabeled billing address captured as a single field, two blank fields (salesperson and ref) correctly returned as null, and every number matching to the cent.
On a FUNSD photocopying variance form—a checklist of twelve boolean fields with one nested group of five sub-options—the model marked exactly the one box that's checked (poor quality original, with a handwritten "faded" note beside it) as true, and the other eleven as false. It also read the handwritten Bates ID correctly and returned null for the two fields left blank.
These aren't cherry-picked wins. They're examples of what generalization looks like when a model is trained close enough to the task that its inductive biases align with the problem structure.
What this means for deployment
The Dharma-AI thesis is holding up across multiple releases now. A 3B OCR model beat frontier APIs on Brazilian Portuguese. A 2B field extraction model beats them on structured extraction, across languages and document types, while costing 6-147× less.
Parameter count sets the ceiling. Training decides how much of it a model reaches on your task. If your production workflow involves extracting fields from documents at volume—invoices, forms, IDs, requisitions—this is evidence that you don't need to pay frontier API rates to get frontier-beating quality.
You need a model trained for the problem.
Try it on your own documents at ocr-portal.prd-us-east-2.dharma-ai.com. More at dharma-ai.com.