Close Menu
    Trending
    Subscribe
    Wednesday, November 11
    AI Tools & Software

    Any Document In, Structured Fields in JSON Out

    adminBy No Comments8 Mins Read
    Any Document In, Structured Fields in JSON Out

    A 2-billion-parameter model that extracts exactly the fields you ask for, from any document type, outperforming every frontier LLM we tested, at a fraction of the cost.

    cover_combined_1
    In April, we released DharmaOCR-LITE, a model specialized for OCR across a wide range of documents, from contracts and court filings to invoices, IDs and forms. The paper behind it made a narrow, well-measured case for domain specialization: a smaller model trained closer to its task beating general-purpose frontier APIs on that task.

    OCR gives you the text on a page, faithful to the original formatting. That’s exactly what you want when the job is the whole document, like a contract you’ll read end to end or a manuscript you’re digitizing.

    However, there’s a different use case: you don’t want the page, you want specific fields out of it, in a shape a system downstream can consume. Every line item on an invoice, as a list. The patient name, exam type and date from a medical requisition, ready to schedule. The fields off an ID, mapped to the columns of an employee record.

    Run that document through OCR and you get back everything printed on it, line by line, with no indication of which string is the exam type, which is the date or which number is the total. Someone still has to write the code that maps each value to the right field before it reaches the database.

    A general-purpose LLM can do this work today, with careful prompting. At frontier API pricing and latency, on a task many businesses need to run at high volume, that quickly becomes the expensive way to solve a well-defined problem.

    So we built a model for it instead. The Field Extractor takes a document image and either a request for everything it can find, or an exact schema to fill, and returns structured JSON: typed, field by field, nested where the document nests. An invoice comes back with every line item as an ordered list, each with its own quantity and value, alongside the totals. An ID comes back as the fields you’ll store, under the names your system already uses for them. The same checkpoint handles all of it, with no per-type fine-tuning.

    You can try it yourself here.



    What the Model Does

    Say a batch of supplier invoices lands every morning, and you need four things off each one to push into your system: the supplier, the invoice number, the due date, the total. Same story for medical requisitions going into a scheduler, or contracts feeding a compliance system, where what matters is the parties, the term, the penalties and the fine amounts. You don’t need the page, you need certain fields. With the Field Extractor there are two ways to ask for them:

    field-extractor-1280

    • Open: no schema supplied. The model reads the page and works out which parts of it are structured fields (a label followed by a value, a table with a header row over its columns) from context and layout, not from a fixed list of field names, and returns everything it finds as key-value pairs.
    • Schema-directed: you specify the exact shape wanted, field by field, with a type for each one (string, number, or boolean), under the key names your system already uses. Ask for “service_provider” and “client_company”, and those are the exact keys that come back. Ask for a table and it fills it row by row, column by column, matching each cell to the key it belongs under. Ask for a field that isn’t on the document, and it returns null instead of inventing a value.

    The choice comes down to what you already know. Send an open request when you don’t know what the document holds. Send a schema when the output has to match a shape that already exists somewhere else.

    Either way, what comes back is JSON: the fields as keys, the values typed as requested, and null where the document didn’t have what you asked for. When you send a schema, the output follows it exactly, with the same keys and no extra fields, so it can go straight into the next system.



    How It Was Trained

    The base model is DharmaOCR-LITE v1.1, a new 2-billion-parameter version optimized from the one in the paper and already specialized for OCR through supervised fine-tuning and DPO. On top of that checkpoint we trained a LoRA adapter on 43,384 training examples covering both request modes.

    The data is organized into three streams:

    • English multi-domain data: diverse documents collected from the public web, spanning many document types.
    • Brazilian domain data: real Brazilian documents sourced internally, in Portuguese.
    • Multilingual data: a smaller share covering other European and Asian languages, for broader generalization beyond English and Portuguese.

    All three streams are annotated at the field level. The mix is deliberately multi-domain: receipts, commercial invoices, forms, bank statements, ID documents and synthetic documents, rather than one filing type.

    03_training_data_mix_v2



    Where the Benchmark Draws the Line

    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. The score is field-level F1 (matched by path, including position inside a table), multiplied by the Levenshtein similarity on the values that matched and by the share of outputs that come back as valid JSON.

    We ran the same benchmark against four general-purpose frontier configurations.

    image

    Against general-purpose LLMs, the quality gap runs from 1.8 points (Claude Opus 5, the closest) to 9.3 points (GPT-5.6 Luna, the widest).

    image

    Cost runs from roughly 6 times lower (GPT-5.6 Luna) to roughly 147 times lower (GPT-5.6 Sol). The two sides are priced differently. The frontier figures come from measured average input and output tokens per page, reasoning tokens included, against each provider’s published list pricing. Every frontier model ran with reasoning set to low; Claude Opus 5 used adaptive effort, which can skip reasoning on simpler pages while staying at the low level. Ours isn’t billed per token: the model runs self-hosted, so the figure is GPU time on a single L40S at $2.24 per hour.

    This is not a sales price. Self-hosted cost depends on the hardware, the volume and the latency each deployment needs. The comparison is here to show that a sovereign SSLM, deployed on your own infrastructure, is a real alternative to frontier APIs.



    A Test of Generalization

    SROIE and FUNSD are two public datasets in our benchmark, not used in training. Below is one example from each.

    On a SROIE receipt, we asked for all 18 fields printed on it, with no phantom fields this time, and every one comes back correct: the multi-line, unlabeled billing address captured as a single field, the two blank fields (salesperson and ref) correctly returned as null, and every number on the receipt matching to the cent.

    sroie_combined

    On a FUNSD photocopying variance form, a checklist of twelve boolean fields with one nested group of five sub-options, the model marks 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, matching the form exactly. It also reads the handwritten Bates ID off the page correctly, and returns null for the two fields left blank.

    funsd_combined



    Quality and Cost, at the Same Time

    A 2-billion-parameter model scored 0.834, above every frontier configuration we tested, from Claude Opus 5 at 0.816 to GPT-5.6 Luna at 0.741, while running on a single L40S at a lower cost per extraction than every API in the comparison. Higher quality and lower cost, measured on the same benchmark, in the same run.

    This isn’t the first time we’ve measured it. Our OCR paper put the first DharmaOCR-LITE, a 3-billion-parameter model, above every commercial frontier API tested on Brazilian Portuguese; three months later, newer and better-resourced models arrived, and the gap held. Now a 2-billion-parameter model does it on field extraction. Each result adds evidence for the thesis we started Dharma-AI with: on a bounded task, a small model trained close to that task beats a frontier model asked to do the same thing in general. In this benchmark, it also cost 6 to 147 times less to run.

    Parameter count sets the ceiling; training decides how much of it a model reaches on your task. Your business doesn’t need the biggest model available. It needs one trained for your problem.

    Try it on your own documents here. To learn more about Dharma-AI and the specialized models we build, visit dharma-ai.com.



    Sources



    Further Reading

    Explore Dharma AI on Hugging Face to try our interactive demos, download our open-source models, and discover how specialized AI systems outperform general-purpose models in real enterprise applications.

    Share.

    Related Posts

    Leave A Reply