A weekly series for the DNA team

Choosing the right AI approach for each task

Clients often ask which AI approach they should use. The usual answer is "it depends". Each session in this series sets out, for one task, what the answer depends on and which options to consider.

[01]  Why this seriesThe problem

Why the answer depends on the situation

Consider a common question: what is the best way to get the contents out of a few thousand PDF contracts?

There is no single answer. Small scripts, classic OCR, cloud document services, specialist vendors, open models and the big general models like Gemini, GPT and Claude can all do it. Each is the right choice in some situations. The choice depends on factors such as:

How many documents?Digital or scanned?How long?Lots of tables?Charts and diagrams?How accurate?Budget?Where can the data go?What happens next?

The options also change every few months: an approach that was too expensive last year may now be the cheapest adequate option. Each session takes one task and sets out the current options, how they work, what they cost, and which to try first in common situations.

[02]  The ideaThe Pareto frontier

The Pareto frontier

Plot every option

Each dot is one way of doing the task. Up means better results on a fair test. Right means more expensive per unit of work.

Draw the frontier

An option is on the frontier if nothing else is both better and cheaper. Only these options merit detailed evaluation.

Exclude dominated options

Every option below the line is beaten on both quality and cost by an option on it. This is usually most of the market.

Apply client constraints

Constraints such as "must run in our Azure tenant" remove options. This moves the frontier and may change the best choice.

Illustrative data. Real charts are in each session.

[03]  FormatSession structure

Session structure

01

How we got here

A short history, explaining why several approaches remain in use.

02

How each approach works

How each approach works internally, illustrated with real examples.

03

Who the players are

Vendors, open models and cloud services, including which can run on Azure, Google Cloud or AWS.

04

How they are measured

The main public benchmarks, who runs them, and their limitations.

05

Where the frontier is

Quality against cost, from benchmarks other people have run, with sources and dates.

06

What to recommend

Dated default picks for common client situations, and what to test them against.

[04]  SessionsOrder may change

Sessions

01Ready

Document extraction

Getting text, tables and fields out of PDFs and scans. Covers PDF libraries, OCR, cloud services, specialist models and vision language models.

Open the session →
02Planned

Web search and research agents

Search APIs, "deep research" tools and agents that browse. Their accuracy and cost per answer.

03Planned

Automated research and optimisation

Agents that run experiments in a loop to improve a model, a prompt, a piece of code or a business metric.

04Planned

Coding agents

Code completion tools and agents that implement changes and open pull requests, and their uses in data work.

05Planned

Structured outputs and data cleaning

Turning messy text and tables into clean, typed data. Schemas, validation, and matching records.

06Planned

Retrieval and RAG

Chunking, embeddings, rerankers, and when a long context window is simpler than retrieval.

07Planned

Speech and transcription

Speech to text, telling speakers apart, and turning calls and meetings into usable data.

08Planned

Classification and tagging at scale

Labelling millions of records with small models, large models, or a mix of the two.

[05]  Ground rulesHow to read these sessions
  1. Results come from published benchmarks.We do not run our own tests. We report public results, who produced them, and any likely bias.
  2. Every number has a source and a date.Prices and scores change quickly. Each session is a snapshot from the date shown on it.
  3. Benchmarks are combined only when comparable.Scores are blended only when the benchmarks measure the same thing. Each chart shows how many benchmarks back each point.
  4. Default picks indicate what to test first.Each default pick identifies the option to test first on the client's own documents. It does not replace that test.