Blutrain
  1. Home
  2. Capabilities
  3. Natural Language Processing

Capability

Systems that read at a volume people cannot.

Contracts, tickets, claims, invoices, complaints, clinical notes. The text already exists and someone is reading all of it — usually the most expensive person available, usually at the worst possible time.

01 / The problem

Where this usually goes wrong.

Language models made this category look trivial. Ask one to summarise a document and it does, immediately and convincingly. The demo is so good that the actual engineering problem gets skipped entirely.

That problem is: how do you know the summary is right? Across ten thousand documents, without reading them? A system that is subtly wrong on 4% of contracts and gives no indication which 4% is more dangerous than no system at all, because people stop checking.

02 / What we build

The parts of the system.

Retrieval you can inspect
Documents chunked with structure preserved, indexed with both semantic and keyword search, and every generated answer traceable to the passages it came from. If a claim cannot be traced to a source, it does not get shown.
Extraction with confidence and abstention
Structured fields pulled from unstructured text with a calibrated confidence score, and an explicit threshold below which the system routes to a human instead of guessing.
A real evaluation set
A few hundred documents annotated by people who know the domain, covering the awkward cases as well as the typical ones. This is the single highest-value artefact in an NLP project and the one clients are most often asked to skip.
Cost and latency control
Caching, routing simple cases to smaller models, and a hard ceiling on spend per document. Costs in this category scale linearly with success, which surprises people at exactly the wrong moment.

03 / How it is measured

What we agree to be judged on.

Set before the build starts, against a measured baseline, and reported honestly afterwards — including where the numbers are disappointing.

Field-level accuracy
Measured per extracted field against human annotation, not as a single aggregate. The date field and the liability clause do not fail at the same rate or with the same consequence.
Groundedness
What proportion of generated statements are actually supported by the retrieved source. This is how fabrication is measured rather than hoped away.
Abstention behaviour
How often the system correctly declines. A system that never says 'I am not sure' is not confident, it is uncalibrated.
Review time saved
Measured against the current manual process, including the time spent checking the system's output — which is the number that is usually left out.

04 / Honest limits

What this will not do.

Language models do not know things; they produce plausible continuations. With good retrieval and strict grounding this is manageable, but it never reaches zero. Any workflow where a confident error is unacceptable needs a human decision point, and we will design one in rather than pretend otherwise.

Domain language also drifts. A model tuned on last year's claim vocabulary will quietly degrade as terminology, products and templates change, which is why re-evaluation is a scheduled activity rather than a launch task.

05 / When it applies

You probably need this if:

  • Skilled staff spend hours reading documents to extract a handful of fields
  • Support tickets are triaged manually and inconsistently
  • Knowledge exists in documents nobody can find when they need it
  • A chatbot pilot produced confident answers nobody could verify

Recognising two or more of these is a reasonable trigger for a diagnostic. Recognising none of them is a reasonable trigger for not spending money here yet.

Next step

Is natural language processing the right instrument for your problem?

The diagnostic exists to answer exactly that, including the possibility that the answer is no. It is time-boxed, fixed-fee, and the written assessment is yours.