Language models are very good at the parsing problems that used to need a hundred regexes — and a bad, expensive choice for the ones a regex already solves.
Extraction gets you the raw text. The work that decides whether the dataset is usable is what happens next, and it is usually messier than the scraping.
Consider a single field — the price — as it actually appears across a few hundred sites:
A regex handles the first two variants. By the fifth you are writing special cases, and by the fiftieth you have a thousand lines of parsing code that nobody can safely change.
This is exactly the shape of problem language models are good at: high variety, low volume per variant, and a clear notion of what the right answer looks like.
The rule I use: if you can write the rule down, write the rule. Use a model where the rule would be "you know it when you see it".
Good candidates:
Bad candidates, where a model is slower, costlier and less reliable than five lines of code:
The mistake I see most often is asking a model for JSON in the prompt and then parsing whatever comes back. That works until it does not, and it fails silently in the middle of a large batch.
Every current Claude model supports structured outputs — you supply a JSON Schema and the response is constrained to match it. That turns "usually valid JSON" into "valid JSON or an explicit error", which is the difference between a pipeline you can leave running and one you have to babysit.
Define the schema tightly. Enumerate the values you will accept for a category field rather than leaving it as a free string, and include an explicit "unknown" option — a model given no way to say it does not know will invent something.
This is where people either overspend badly or dismiss the approach on bad arithmetic.
The current Claude lineup, priced per million tokens of input and output:
A short parsing task — a messy product record in, a clean structured record out — runs somewhere around 400 tokens in and 150 out. On Haiku that is roughly 0.0011 dollars per record, so about 1.10 dollars for a thousand records. Ten thousand product records cleaned for around eleven dollars is cheap against any amount of engineering time.
Two things make the difference between that number and a bill ten times larger:
Use the smallest model that passes your evaluation. Parsing and classification are exactly the tasks the cheaper models handle well. Reach for a larger model when the task needs genuine reasoning, not when it needs careful pattern matching. Test the cheap one first; if it passes, you are done.
Batch, and cache the instructions. If you send the same long system prompt with every record, you pay for it every time. Prompt caching makes repeated prefixes read at roughly a tenth of the input price, which matters enormously when the instructions are long and the records are short. Send records in batches rather than one at a time and the per-record overhead collapses.
A model that returns a confidently wrong answer is worse than one that errors, because you will not notice.
Every AI parsing step I build ships with deterministic checks behind it:
That last one is the alarm that matters. A parsing step that quietly starts returning unknown for a third of records has broken, and the null rate catches it long before anyone notices the numbers look odd.
Deterministic first, model second, validation third. Extract the raw values with code. Handle everything with a knowable rule using that code. Route only the leftovers — the genuinely ambiguous ones — to a model. Then validate everything that comes back with rules again.
Done that way, the AI step usually touches ten to twenty percent of records, which keeps both the cost and the blast radius small.
If you have a dataset that is technically complete and practically unusable, that is the job. Send me a sample of the mess and what you want the clean version to look like.
Contact me at sam@autosmartcode.com for a free quote within 24 hours.