What research on LLM extraction accuracy actually tells us
There is a growing body of work examining how reliably LLMs extract structured data from web pages. The findings are consistent: accuracy degrades in predictable ways, and the failure modes are structural, not incidental.
The most documented failure categories:
- Implicit inference — the model fills in a field using reasoning rather than a value that exists on the page (e.g., inferring a job title from a description)
- Field mapping errors — two visually similar fields get swapped (sale price vs. original price, start date vs. completion date)
- Schema conformance — when a value is missing, the model returns a plausible default instead of null
- Partial completeness — a list of ten items comes back with six, with no error signal
- Fabrication — a value that does not exist on the page is invented wholesale
- Context leakage — the model fills a gap using its training knowledge rather than page content
None of these produce an error. They produce data that looks correct.
Why this matters more at scale
At a few hundred pages, a small error rate is manageable. At tens of thousands of pages, it becomes a data quality problem that requires its own validation layer, retry logic, and ongoing monitoring.
Concrete examples of where LLM extraction drifts:
- Ecommerce: a crossed-out original price and a sale price look identical in text — LLMs swap them roughly once every hundred or more rows
- Real estate: street address, city, postcode, and region are all text elements — LLMs merge or mislabel them
- Job listings: salary range, equity, and bonus are all numeric in similar formats — LLMs conflate them into one field
- Clinical data: multiple date fields per page with similar values — LLMs assign the wrong date to a label based on proximity
These are not edge cases. They are predictable failure patterns tied to how language models process ambiguous or structurally similar content.
The token cost problem compounds the accuracy problem
LLM extraction has a second constraint: cost scales with page size.
Stripped HTML (scripts and styles removed) averages roughly 39K tokens per page. Full HTML averages closer to 573K tokens. Most developers who want a reliable pipeline without custom preprocessing pass full HTML — and the cost difference is roughly 15x per page.
Cost comparison at 120,000 pages/month:
| Approach | Monthly cost |
|---|---|
| GPT-5 nano (stripped HTML) | ~$285 |
| GPT-4o-mini (stripped HTML) | ~$773 |
| GPT-5 nano (full HTML) | ~$3,480 |
| GPT-4o-mini (full HTML) | ~$10,320 |
| Minexa Startup plan | $60 |
Minexa's cost is not affected by HTML size. There is no token-based pricing.
How Minexa approaches extraction differently
Minexa.ai is a deterministic AI web scraping API. Instead of passing page content to a language model at extraction time, it locks onto specific DOM elements during a one-time training step and extracts values directly from those positions on every subsequent run.
What this eliminates by design:
- No implicit inference — only values present in the HTML are returned
- No fabrication — missing values return null, never a invented default
- No field mapping drift — each column is bound to a specific DOM element
- No schema conformance errors — the structure is fixed at training time
- No silent failures — if a page does not match the trained scraper, Minexa returns an explicit error
Container locking prevents a specific class of errors: capturing data from visually similar but unrelated sections (related items sidebars, footer content, ads). The extraction scope is fixed to the trained container.
What a production API call looks like
import requests
data = {
"batches": [{
"scraper_id": 6241,
"columns": ["top_30"],
"urls": ["https://example.com/listings/page-1"],
"scraping": {
"js_render": True,
"provider": "service3",
"proxy": "verified",
"retry": 3
}
}],
"threads": 5
}
headers = {"Content-Type": "application/json", "api-key": "YOUR_KEY"}
response = requests.post("https://api.minexa.ai/data/", json=data, headers=headers)
The scraper_id references a scraper trained once via the browser extension. The columns parameter accepts ["top_30"] to return the 30 highest-ranked fields, or explicit field names like ["price", "address", "availability"]. Both cost the same.
Get started with the Minexa API
Speed difference at scale
LLM extraction requires passing each page's content to a model, which interprets structure before extracting anything. Minexa's deterministic approach skips that interpretation step entirely.
- Per-page extraction: hundreds of milliseconds vs. seconds per LLM call
- At 10,000+ pages, the gap translates to hours of processing time
- Parallel threads amplify the difference further
The practical takeaway for production pipelines
LLMs work well as a layer on top of deterministic extraction — for summarization, classification, enrichment. Using them as the extraction engine itself introduces variability that is hard to validate at scale and expensive to correct.
If you already have your own scraping stack and just need reliable structured output, Minexa supports passing pre-fetched HTML via file_urls — extraction only, no re-crawling, lowest credit cost.
For teams building AI pipelines, RAG systems, or any workflow where data accuracy has to be guaranteed on every run, deterministic extraction removes an entire category of risk.
Read more: large-scale web scraping architecture — what breaks at volume
Top comments (1)
The article highlights how LLMs can introduce subtle errors in web extraction, such as implicit inference and field mapping errors, which can be challenging to detect. I've experienced similar issues when working with LLMs for data extraction, particularly when dealing with structurally similar content. The idea of using a deterministic AI approach, like Minexa, to lock onto specific DOM elements during training and extract values directly from those positions is intriguing. By eliminating implicit inference and fabrication, this approach can significantly improve data accuracy. How do you think the trade-off between the cost of using a deterministic AI approach and the potential data quality benefits plays out in real-world scenarios, especially when dealing with large volumes of data?