Evidence at a glance
OCR Reads the Page; Field Extraction Organizes What Matters
OCR turns the page into text. But a business system may need an invoice number, due date, and total—or a patient’s name and exam type. A block of recognized text does not say which value belongs in which field; someone or something still has to map it. Dharma-AI’s earlier DharmaOCR-LITE focused on OCR. Field Extractor is designed to take document images and return selected fields as JSON.
Dharma-AI argues that using a general-purpose LLM for frequent extraction can make API cost and latency burdensome, even though careful prompting can handle the task. That is the company’s rationale for the product, not an independently established conclusion about every workload. Whether this model fits depends on the documents and deployment.
Use Open Extraction for Unknown Fields, a Schema for Known Ones
Field Extractor supports two request modes. Open mode takes no field list: the model uses page content and layout to identify structures such as label-value pairs and tables, then returns the fields it finds as key-value pairs. It is intended for cases where the caller does not yet know what fields a document contains.
In schema-directed mode, the caller specifies the field names, types, and structure—for example, strings, numbers, or booleans. The blog says the model returns the requested keys, uses `null` when a requested field is absent, and adds no extra fields. For tables, the intended output maps cells by row and column; the company gives invoice line items as an example of an ordered list. The published material does not provide a separate evaluation across complex table types.
One Adapter for Both Modes, Trained on Several Document Types
Dharma-AI says Field Extractor builds on DharmaOCR-LITE v1.1, which had already been trained for OCR through supervised fine-tuning (SFT) and direct preference optimization (DPO). The team then trained a LoRA adapter on 43,384 examples covering both request modes. The blog describes the base model as having 2 billion parameters.
The training data has three streams: English documents from multiple domains collected from the public web, real Brazilian documents in Portuguese sourced internally, and a smaller share of other European and Asian languages. The examples are annotated at the field level and include receipts, commercial invoices, forms, bank statements, IDs, and synthetic documents. The linked DharmaOCR-LITE model card describes a 3-billion-parameter model; the blog does not explain how that relates to the 2-billion-parameter version it names.
A 546-Document Benchmark, Reported by the Developer
Dharma-AI’s benchmark contains 546 documents and 1,638 cases across three scenarios: extracting all fields without a schema, using a partial schema containing only real fields, and including requested fields that do not appear in the document. The score combines field-level F1 matched by path, Levenshtein similarity for matched values, and the share of outputs that are valid JSON.
The company reports an aggregate score of 0.834, above Claude Opus 5 at 0.816 and GPT-5.6 Luna at 0.741 among the configurations it tested. The blog says the frontier models ran with low reasoning; Claude Opus 5 used adaptive effort. The result applies to this company-run benchmark and these configurations. It does not establish that the model beats every general-purpose model or works equally well on every document.
The Cost Claim Depends on What Is Being Compared
Dharma-AI reports self-hosting costs about 6 to 147 times less than the APIs it tested, with GPT-5.6 Luna and GPT-5.6 Sol at the two ends of that range. The API estimates use each provider’s published rates and measured average input and output tokens per page, including reasoning tokens. The self-hosted estimate is based on GPU time for one L40S at $2.24 per hour.
That figure is not a quote that applies to every deployment. Dharma-AI notes that self-hosting costs vary with hardware, volume, and latency requirements. GPU-hour costs and per-token API charges are different pricing measures, so the reported gap should be read as a comparison under the company’s stated assumptions—not as savings every user will realize.
What the SROIE and FUNSD Examples Show—and Do Not Show
Dharma-AI says SROIE and FUNSD were held out from training and presents one example from each. On an SROIE receipt, the model was asked to extract all 18 fields in open mode. The blog notes that it returned a multi-line, unlabeled billing address as one field, used `null` for two blank fields, and matched the receipt’s numbers.
The FUNSD example is a photocopied form with 12 boolean fields, including a nested group of five options. The company says the model marked the single checked option true and the other 11 false. It also read the handwritten Bates ID and returned `null` for two blank fields. These examples show results on two documents; they are not a systematic evaluation across document types, scan quality, or languages.