Databricks AI Extract Precision Mode: What Changes for Document Processing Projects?

TL;DR

• Precision Mode is a new setting inside the existing ai_extract function, not a separate product. Set mode to precision, or toggle it in the Information Extraction UI.
• It is generally available. Databricks did not publish pricing in the announcement.
• Reported accuracy: 94.7% across roughly 9,000 documents, seven points ahead of GPT-5.6 Sol, the strongest frontier-model chunk-and-merge baseline they benchmarked against.
• Evaluated on ten internal datasets and five named public benchmarks: VAREX, RealDocBench, LongExtractBench, LEDGER and the Caselaw Access Project.
• It targets three specific failure modes, not extraction generally: documents too long for one pass, outputs too deeply nested to survive intact, and schemas that need reasoning rather than pattern matching.
• Tested against documents up to 2,000 pages and schemas with more than 300 deeply nested fields.
• Named customers: Panasonic, EY-Parthenon, Intercontinental Exchange.
• Our take: seven points is a real gain and an unglamorous one. It matters most to organisations holding a stalled business case, because the specific objection that stalled it may no longer be true.

What was actually announced

Precision Mode is a new mode within ai_extract, the document-extraction function already in the platform. It pairs two things:

The second half is the interesting part architecturally. The standard approach to a document too large for a context window is chunk-and-merge: split it, extract from each piece, staple the results together. That is also the baseline Databricks benchmarked against, and the seven-point gap is the gap between stapling and reconciling.

The three problems it targets

Databricks is specific about the failure modes, and the specificity is worth reading closely, because it tells you whether your use case is in scope:

1. Long documents needing cross-page reconciliation. Their example: a lease where a term on page 1 depends on a clause on page 80. Chunking destroys that relationship, because neither chunk contains both facts.

2. Large nested outputs that get truncated. An invoice with thousands of line items produces an output big enough that the tail is silently lost. Silently is the operative word.

3. Complex schemas requiring reasoning. Synthesising across multiple documents, or applying conditional logic, rather than locating a field and copying it.

The benchmark

94.7% accuracy across roughly 9,000 documents, outperforming the strongest frontier-model chunk-and-merge baseline, GPT-5.6 Sol, by seven points. Test documents ran up to 2,000 pages, with schemas exceeding 300 deeply nested fields and thousands of line items.

The evaluation covered ten internal datasets and five public benchmarks. Databricks names them as:

Internal (10): datasets inspired by customer workloads across financial services, manufacturing and healthcare.

Public (5):

• VAREX
• RealDocBench
• LongExtractBench
• LEDGER
• Caselaw Access Project — used specifically for the long-document stress test

That list is worth noting for one reason: five named public benchmarks is more disclosure than most vendor accuracy claims come with, and it means the comparison is at least partly reproducible by someone who wants to check it.

Named early customers are Panasonic, EY-Parthenon and Intercontinental Exchange, with document types including 10-K filings, bills of lading, technical manuals, invoices, clinical notes and patent applications.

Why this matters for enterprises

1. Seven points is boring, and that is the point

Seven percentage points is not the kind of number that trends. It is, however, the kind of number that changes an operating model.

At 88% accuracy, a human checks everything, because you cannot know which 12% is wrong. At 95%, the conversation can move to exception handling: which extractions get flagged, who reviews them, what the fallback is. That is a different workflow with a different cost base, and it is the reason a marginal-sounding gain can unstall a project.

On a thousand documents, seven points is seventy fewer errors somebody has to find by hand. That arithmetic is ours, not Databricks', but it is the arithmetic a business case runs on.

2. The three failure modes are a scoping checklist

Most published guidance on document AI is about model choice. Databricks has instead named three structural reasons extraction breaks, and they map cleanly onto the kinds of documents enterprises actually hold.

If your problem is short, flat forms, this release changes little for you and simpler tooling was already sufficient. If your problem is 200-page contracts where obligations reference each other, or invoices whose line items outnumber the output budget, you were in the failing category and may no longer be.

That is a scoping question you can answer in an afternoon, without a vendor.

3. Extraction accuracy is not the same as extraction confidence

This is the gap worth watching. The announcement reports accuracy. It does not, in the material we have read, describe how the system signals when it is unsure.

That distinction decides the operating model. A system that is 95% accurate and silent about which 5% is wrong still needs full human review. A system that is 95% accurate and flags its own low-confidence extractions needs review of the flagged subset only. The second is dramatically cheaper to run, and it is the question we would put to Databricks before designing a workflow around this.

4. It runs where the data already is

ai_extract is callable from SQL and usable across the platform. For organisations already on Databricks, that removes the integration work, the second vendor and the data-movement question that usually accompanies a document-AI pilot. That is not a small operational advantage, and it is the strongest argument for evaluating this over a standalone extraction vendor.

The Cosmos Thrace perspective

We have not run Precision Mode in a client environment yet. This is a reading of the announcement, published while it is current, and we will say plainly when that changes.

What we can say from delivering data platform work across Europe is that document-extraction projects rarely die for the reason the post-mortem records. The recorded reason is usually accuracy. The actual reason is usually that nobody agreed what happens when the model is wrong.

A 95% system and an 88% system fail differently in aggregate, but the design question they force is identical: who reviews, on what trigger, and what is the cost of a miss reaching a customer or a regulator. Teams that never answered that question will stall at 95% exactly as they stalled at 88%.

So our honest advice is not "the technology is ready now." It is narrower and more useful. If your business case named accuracy as the blocker, that line is out of date and the case deserves reopening. If your business case never had an exception-handling design, the new number will not save it.

One more note on the benchmark, in the spirit of how we read every vendor figure including our own: 94.7% is Databricks' number, about Databricks' product, on an evaluation Databricks designed. That does not make it wrong. It makes it a strong reason to run your own documents through it rather than a substitute for doing so.

What to do this month

1. Reopen the shelved business case. Find the sentence where somebody wrote that accuracy was not sufficient. That sentence may now be false. This costs an afternoon.

2. Check yourself against the three failure modes. Long documents with cross-page dependencies, deeply nested outputs, schemas needing reasoning. If none apply, this release is not aimed at you.

3. Run your own worst documents. Not the clean sample. The 300-page contract with scanned appendices that everybody avoids. Benchmarks are built on curated corpora; your estate is not curated.

4. Ask the confidence question. How does the system indicate uncertainty, and can that signal drive a review queue? Design the workflow around the answer, not around the headline number.

5. Price it before you plan it. Pricing was not stated in the announcement. Get it confirmed before it lands in a business case.

Sources

1. Databricks — "Databricks Document Intelligence: Pushing the Frontier of Complex Document Extraction": https://www.databricks.com/blog/databricks-document-intelligence-pushing-frontier-complex-document-extraction

Related reading

• Databricks Lakebridge: What It Does, and What It Doesn't — the same argument applied to migration tooling: what the tool now does for free, and what it leaves you
• Databricks migration services hub — how we scope and run a migration, by source system