What Is Dharma Field Extractor? The Beginner's Guide to Turning Any Document Into Structured JSON

CodexFuse Team · 2026-11-05T11:51:55.239Z · 20 min read min read

What Is Dharma Field Extractor? The Beginner's Guide to Turning Any Document Into Structured JSON

Dharma Field Extractor is a 2-billion-parameter AI model that reads a document image and returns just the fields you ask for, typed as structured JSON. This guide answers the question what is Dharma Field Extractor in plain terms, and it covers the two ways to ask for fields, the vendor's own benchmark numbers, the cost claim behind them, and the parts of the story that are still unconfirmed one day after launch.

Dharma-AI, a Brazilian research lab that specialises in small language models, announced the model on November 4, 2026. The announcement arrived as a blog post on Hugging Face, and this guide was written on November 5, 2026, one day later, when no independent test of the model existed yet.

The problem it attacks is familiar to anyone who runs a back office. Invoices, forms, IDs, contracts and medical requisitions arrive as images or scans, and the useful part is never the whole page. It is four or five fields that have to land in a system, spelled the same way every time, with the right type, and with nothing invented when a field is missing.

This guide explains what the model does, how its two request modes work, what its training data looked like, what the vendor's benchmark actually measures, what the 6x to 147x cost claim really means, and what you should check before trusting it with your documents.

What Is Dharma Field Extractor?

Dharma Field Extractor is a 2-billion-parameter model that takes a document image as input and returns structured JSON containing only the fields a downstream system asked for. Dharma Field Extractor explained in one sentence: you show it a page and either ask for everything structured on it or hand it an exact schema, and it returns typed fields, nested where the document nests, with null wherever the document did not have what you asked for.

The model is built for one bounded job. It does not chat, write essays, or browse the web.

It reads a page, finds the structured parts, a label followed by a value or a table with a header row over its columns, and returns them as JSON that can go straight into a database, an API, or the next step of a pipeline. If you want to fingerprint an extraction result before storing it, a SHA-256 hash generator produces a fixed-length digest of the JSON text, so you can tell later whether anything changed.

Dharma-AI positions the model as self-hosted, running on a single rented GPU rather than behind a per-token API. That is the same rented-server idea behind VPS hosting, except the server carries a GPU and the cost is counted in GPU hours instead of API calls.

One checkpoint handles every document type, according to the vendor, with no per-type fine-tuning. That claim is the company's own, and no independent test had checked it a day after launch.

How Dharma Field Extractor Turns a Document Into JSON

The input is a document image, not a PDF file or a block of pasted text. The model reads the page the way a person would, taking labels, values, tables and layout together rather than just the raw characters in reading order. In short, Dharma Field Extractor document to JSON conversion works like this:

1. Send the document image with either an open request or an exact schema.
2. The model reads the layout and works out which parts are structured fields.
3. It matches each value to the key it belongs under, row by row in tables.
4. It types each value as requested: string, number, or boolean.
5. It returns JSON, with null for any field the document did not contain.

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 with the fields a system already stores, under the key names that system already uses. The same checkpoint handles invoices, forms, IDs and contracts, with no per-type fine-tuning, according to the vendor.

Nested structure survives the trip. A table inside a document stays a table in the JSON, and a group of related fields stays grouped, so the receiving system does not have to rebuild the shape from a flat list.

Open Requests vs Schema-Directed Extraction: Which Mode Do You Need?

The choice comes down to what you already know. Send an open request when you do not know what the document holds, and send a schema when the output has to match a shape that already exists somewhere else.

An open request supplies no schema at all. The model works out from context and layout which parts of the page are structured fields, then returns everything it finds as key-value pairs. This is the mode for exploring a new document type, or for a mixed pile of documents where nobody has listed the fields in advance.

Dharma Field Extractor schema directed extraction works the other way around. You specify the exact shape you want, 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.

Either way, the output follows the same rule: JSON with the fields as keys, the values typed as requested, and null where the document did not 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 without a cleanup step.

What "Null Instead of an Invented Value" Means, and Why It Matters

A field that is not on the document returns null instead of an invented value. That single design choice is the difference between a tool a back office can trust and one it cannot.

Picture an invoice with no due date printed on it. A model that guesses a date hands the accounts team a deadline that never existed, and nobody finds out until a payment is late. A model that returns null hands them a blank they can see, route to a human, and fill in from the real record.

Hallucinated values are the quiet failure mode of document extraction. A wrong total that looks plausible sails through every check, while a null is visible and can be handled. The vendor's benchmark deliberately tests this behaviour: one of its three scenarios adds fields that do not exist on the document, specifically to see whether the model invents them.

DharmaOCR-LITE Explained: The Dharma OCR Lite Field Extractor Base Model

Dharma Field Extractor is built on DharmaOCR-LITE v1.1, a new 2-billion-parameter version of the company's OCR model. The base model was already specialised for OCR through supervised fine-tuning and DPO, a preference-tuning method, before the Field Extractor's LoRA adapter was trained on top of it.

Do not confuse the versions. DharmaOCR-LITE first appeared in April 2026, and the paper behind it describes a 3-billion-parameter Lite model and a 7-billion-parameter Full model. The Field Extractor's base is a newer 2-billion-parameter version, v1.1, which is 1 billion parameters, or one third, smaller than the 3-billion-parameter paper model.

The company behind it is Dharma-AI, a Brazilian lab focused on specialised small language models. Its co-founder Gabriel Pimenta de Freitas Cardoso is named on the announcement alongside Paulo Henrique de Medeiros Araujo, Bruno Duarte and Francisco de Almeida Rocha Alves.

The OCR background matters because extraction starts with reading. A model that misreads a total cannot extract it correctly, however good its JSON shaping is. Dharma-AI's thesis is that a small model trained close to one task beats a frontier model asked to do the same thing in general, and the Field Extractor is the company's test of that thesis beyond OCR.

How It Was Trained: 43,384 Examples in Three Streams

The Field Extractor is a LoRA adapter trained on top of the DharmaOCR-LITE v1.1 checkpoint, on 43,384 training examples covering both request modes. LoRA is a method that trains a small set of extra weights while leaving the base model mostly untouched, which keeps training cheap and the result compact.

Document types in the training data include receipts, commercial invoices, forms, bank statements, ID documents and synthetic documents. All examples were annotated at field level, which is what teaches the model to return a value under the right key instead of copying a whole page of text.

The training set is about 26.5 times the size of the benchmark case count: 43,384 examples against 1,638 benchmark cases. That ratio is our own arithmetic from the vendor's figures, and it says the model had far more examples to learn from than the benchmark had cases to test it on.

Dharma Field Extractor vs Frontier LLMs: What the Vendor's Benchmark Actually Shows

Dharma-AI reports that its 2-billion-parameter model scored 0.834 on its own field-extraction benchmark, ahead of Claude Opus 5 at 0.816 and GPT-5.6 Luna at 0.741. Those numbers come from a benchmark the company designed, ran and reported itself, and no independent replication existed a day after launch. Read them as the vendor's claim, not as a settled result.

Our own arithmetic on the vendor's figures: the 1.8-point gap over Opus 5 is a 2.2 percent relative lead, and the 9.3-point gap over Luna is a 12.6 percent relative lead. The vendor's own words put the quality gap at 1.8 to 9.3 points, which matches. A 1.8-point lead is real but narrow, and it is the number to keep in mind before repeating the headline version of this story.

The benchmark covers 546 documents across 1,638 total cases, exactly three cases per document: extracting every field with no schema, a partial schema naming only real fields, and a schema that also includes deliberately nonexistent fields. Four frontier configurations were tested in total, but only Opus 5 and Luna are named with scores in the vendor's text. The other two appear only in a chart image, so this guide does not name them or quote their scores.

The score itself is not plain accuracy. It is field-level F1, matched by path including position inside a table, multiplied by the Levenshtein similarity of the matched values, multiplied by the share of outputs that come back as valid JSON. Every frontier model ran with reasoning set to low, and Claude Opus 5 used adaptive effort, which can skip reasoning on simpler pages while staying at the low level.

Two independent observers flagged the same caveat on launch day. The dev.to summary notes that all numbers come from the vendor with no independent replication cited, and the ExplainX news roundup stresses that the benchmark and cost model are the company's own. This guide agrees with both, and it keeps the claim bounded to field extraction from documents, exactly as the vendor's own thesis does.

The 6x to 147x Cost Claim, Explained Honestly

Dharma-AI claims its model costs roughly 6 times less than GPT-5.6 Luna and roughly 147 times less than GPT-5.6 Sol per extraction, a range the company presents as 6x to 147x cheaper than frontier APIs. That is a vendor claim built on the vendor's own cost model, and the range is wide enough to deserve a closer look.

Our arithmetic: the two endpoints differ by a factor of 24.5, so 6 to 147 times cheaper is a very wide range, not a single figure. The implied savings above are what the vendor's ratios imply, not measured savings.

The two sides of the comparison 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.

The Field Extractor is not billed per token at all: it runs self-hosted, priced as GPU time on a single L40S at 2.24 dollars per hour. The vendor states plainly that this is not a sales price, and that self-hosted cost depends on the hardware, the volume and the latency each deployment needs.

That hourly rate is 53.76 dollars a day, or 1,612.80 dollars a month, if the GPU runs continuously.

But that is a GPU rental rate, not a per-page price. The vendor gives no pages-per-hour throughput, so no per-document cost can be derived from it, and this guide does not invent one. The honest way to read the claim is that a self-hosted specialist can be far cheaper per page at high volume, while the exact saving depends on your own volume, hardware and latency needs.

The cost logic only works at volume. A team extracting a dozen invoices a month will not feel the difference, because the GPU still has to be rented and kept running. A team extracting tens of thousands of pages a month is where per-page API costs compound and a fixed GPU starts to win.

Two Held-Out Tests: SROIE Receipts and FUNSD Forms

The vendor also reports two held-out tests on public datasets that were not used in training: SROIE, a receipt dataset, and FUNSD, a form-understanding dataset. These are vendor-chosen examples from its own write-up, not independent tests, but they show the kind of correctness the model is aiming for.

The FUNSD example is the more telling one. A photocopied variance form with a checklist of 12 boolean fields and one nested group of five sub-options came back with exactly the checked box marked true and the other 11 false. A handwritten Bates ID was read correctly, and the two fields left blank returned null instead of guesses.

Held-out matters because a model can look good on data it trained on. These two datasets were kept out of training, so the results speak to generalisation rather than memorisation, at least on the vendor's own examples.

Where It Fits: Invoices, Forms, IDs, Contracts and Medical Requisitions

The vendor's own examples sketch the target user clearly. Supplier invoices arrive every morning and four fields have to land in a system: the supplier, the invoice number, the due date, the total.

Medical requisitions need a patient name, an exam type and a date. Contracts need the parties, the term, the penalties and the fine amounts. IDs need to be mapped to the columns an employee record already uses.

The common thread is volume plus structure. Back-office pipelines process the same document types again and again, the fields are known in advance, and a wrong value costs more than a slow one. That is the shape of work where a small specialist can beat a generalist, and it is also the shape where a null is more useful than a guess.

It is not a general document tool. The model does not summarise a report, answer questions about a contract, or chat about a form.

It extracts fields. Teams that need full-document OCR or open-ended document questions are looking for a different tool, and developers wiring extraction into agent workflows should first understand what MCP over MOQT is, because the transport between an agent and its tools shapes how clean JSON like this gets used.

The other honest boundary is language. The training data is English-first, with Brazilian Portuguese documents and a smaller multilingual share. The vendor does not claim equal performance across languages, and this guide does not either.

What Is Still Unconfirmed: Licence, Weights and How to Try It

As of November 5, 2026, the day this guide was written, Dharma-AI had stated no licence, no weight availability, no download link, no API pricing and no commercial terms for the Field Extractor. The announcement blog post says none of those things, and the dev.to summary flags the same gap explicitly.

No dedicated Hugging Face model page for the Field Extractor was found, and no GitHub repository for it was found either. Do not go looking for a download link this guide can give you, because none was verified. The blog footer mentions open-source models in a generic line pointing at the company's organisation page, but that is not a licence or a download for this model, and this guide does not call the Field Extractor open-source, open-weights, free or downloadable.

The vendor does link a demo portal, but when it was opened on November 5, 2026, it resolved to a login page with a Portuguese interface, offering OCR testing, comparison, API keys and documentation sections. Say it plainly: the demo asks you to log in, and there is no evidence it can be tried without an account.

One more distinction belongs here. The DharmaOCR models were described by a third-party guide as source-available under a non-commercial licence, with a separate commercial agreement needed for production use.

That is about DharmaOCR, a different model, and it must not be transferred to the Field Extractor. The Field Extractor's terms are simply unconfirmed, and they may change, so check the vendor's Hugging Face page for the current status before relying on it.

None of this makes the model a bad bet. It makes it a one-day-old announcement with strong vendor numbers and open questions, which is the normal shape of a launch this fresh. The right move is to treat the benchmark as a claim to verify on your own documents, not as a result to build a budget on.

Should You Use It? A Beginner's Checklist

Use the checklist below as a decision aid, not as a recommendation. Every item is a question to answer with your own documents before committing to any extraction tool.

1. Name the fields first. If you cannot list the exact fields and types you need, start with an open request on a sample batch and let the model show you what it finds.
2. Test the null behaviour. Send documents with missing fields on purpose and confirm the model returns null instead of inventing values.
3. Run your own benchmark. Take fifty of your own documents, extract them with the Field Extractor and with a frontier API, and compare field by field before believing any vendor score.
4. Check the licence and access before you build. Confirm the licence, the weight availability and the commercial terms on the vendor's own pages, and confirm whether the demo needs an account.
5. Count your volume before counting the saving. A self-hosted GPU only beats per-token pricing when the page count is high enough, so work out your monthly pages first and price both routes.

Developers who run extraction code in disposable environments should also read how to use Claude Code for building the pipeline and how to use E2B for running it in a sandbox, since both cover the tooling around the model rather than the model itself.

Sources

Dharma-AI, "Dharma Field Extractor: Any Document In, Structured Fields in JSON Out", Hugging Face blog, November 4, 2026 — the vendor announcement and primary source for the model, its modes, its training data, its benchmark and its cost claim.

RuntimeWire, "Dharma-AI's Gabriel Pimenta ships a 2B model that extracts document fields as JSON", November 4, 2026 — launch-day news item confirming the date, the model size, the training examples and the contributors.

dev.to, "Dharma AI Releases 2B Field Extractor for Document to JSON", November 4, 2026 — summary that flags the vendor-only nature of the numbers and the unconfirmed licensing and weight availability.

The Chenab Times, "Dharma-AI Releases Field Extractor for Efficient Document Data", November 5, 2026 — secondary coverage repeating the vendor claims, with no independent testing.

ExplainX, "AI News Today, November 5, 2026" — news roundup stressing that the benchmark and cost model are the company's own.

CV Brief, Thursday, 5 November 2026 — newsletter listing the model as a document-to-JSON structured data pipeline.

Cardoso et al., "DharmaOCR: Specialized Small Language Models for Structured OCR that outperform Open-Source and Commercial Baselines", arXiv:2604.14314, April 15, 2026 — the paper behind the DharmaOCR-LITE base model.

Dharma-AI organisation page, Hugging Face — the vendor's organisation page, fetched November 5, 2026.

Dharma-AI demo portal — the vendor's linked demo, which resolved to a login page when opened on November 5, 2026.

Frequently Asked Questions

What is Dharma Field Extractor in simple terms?

Dharma Field Extractor is a 2-billion-parameter model that reads a document image and returns just the fields you ask for as typed JSON. You either ask for everything structured on the page or hand it an exact schema, and it returns the fields with the right types and null for anything missing.

What is the difference between open and schema-directed extraction?

Open extraction supplies no schema: the model finds every structured field on the page and returns it as key-value pairs. Schema-directed extraction fills exactly the fields and types you specify, under the key names your system already uses, with null for anything the document does not contain.

Does Dharma Field Extractor beat Claude Opus 5 and GPT-5.6?

On Dharma-AI's own 1,638-case benchmark it scored 0.834, against 0.816 for Claude Opus 5 and 0.741 for GPT-5.6 Luna. Those are vendor-reported numbers from a benchmark the company designed and ran itself, with no independent replication as of November 5, 2026.

How much cheaper is it than frontier LLMs?

The vendor claims roughly 6 times to 147 times lower cost per extraction, based on its own cost model: self-hosted GPU time on a single L40S at 2.24 dollars per hour, against per-token API list prices. No per-page price was published, and the vendor itself says the hourly figure is not a sales price.

Is Dharma Field Extractor open-source, and can I download it?

As of November 5, 2026, no licence or weight availability had been stated for the Field Extractor, and no model page or GitHub repository for it had been found. The vendor links a demo portal that asks you to log in. Check the vendor's Hugging Face page for the current status before relying on it.