ai & machine learning · natural language processing
Turn claims notes, emails and contracts into fields you can query.
Somewhere in your systems is a column of free text that people read one row at a time. Adjuster notes, support emails, contract clauses. We turn it into structured data you can search, count and route.
Natural language processing extracts meaning from text by classifying documents, pulling out entities and fields, summarizing, translating and searching by meaning.
Cohash builds NLP pipelines that combine large language models, smaller fine-tuned models and rules, chosen by accuracy, cost and data sensitivity. We measure each pipeline against a labeled test set, redact sensitive fields where needed, and write results back to your CRM or data platform.
you probably need this if
Staff read and route every inbound email or ticket by hand.
Fields from forms, claims or contracts are re-typed into a system of record.
Search fails unless people guess the exact words in the document.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Natural Language Processing, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · natural language processing3 open
openStaff read and route every inbound email or ticket by hand.
recurringFields from forms, claims or contracts are re-typed into a system of record.
blockedSearch fails unless people guess the exact words in the document.
exposure
Classification and routingField extraction to a schemaDocument processingSemantic searchSensitive data handlingThe right model for the job
startrehearsehandover
Sample and label
Baseline
Improve
Integrate and monitor
we are here
ready to hand over
Every routing decision has a confidence score attached, and an uncertain email goes to a…
Renewal terms for each contract are structured and point back to the source page.
Labeling guide and labeled evaluation set
Accuracy report per field or class
chapter 01 · where it hurts
Why teams reach out
Staff read and route every inbound email or ticket by hand.
Fields from forms, claims or contracts are re-typed into a system of record.
Search fails unless people guess the exact words in the document.
chapter 02 · what we change
How we solve it
Classification and routing
Field extraction to a schema
Document processing
Semantic search
Sensitive data handling
The right model for the job
chapter 03 · how it runs
Our approach
Sample and label
Baseline
Improve
Integrate and monitor
chapter 04 · where you end up
What changes
Every routing decision has a confidence score attached, and an uncertain email goes to a person rather than to the wrong queue.
Renewal terms for each contract are structured and point back to the source page.
Labeling guide and labeled evaluation set
Accuracy report per field or class
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Emails, tickets and notes sorted by intent, urgency or product, then routed to the right queue in Salesforce or Dynamics 365 with a confidence score attached.
Dates, amounts, parties, clause types and codes extracted into a fixed schema with validation, so output loads into a table rather than a paragraph.
OCR and layout analysis for scanned forms and PDFs, with tables and checkboxes handled explicitly rather than flattened into text.
Embeddings and hybrid keyword search over policies, contracts and knowledge bases, with document permissions respected at query time.
Personal and health data detected and redacted or tokenized before text leaves your environment, with the redaction itself tested for misses.
We use a large model for messy, low-volume text and a small fine-tuned model for high-volume narrow tasks, and plain rules where rules work. Then we compare all three on cost per thousand documents.
capability 01 / 06in production
Classification and routing
Emails, tickets and notes sorted by intent, urgency or product, then routed to the right queue in Salesforce or Dynamics 365 with a confidence score attached.
We use a large model for messy, low-volume text and a small fine-tuned model for high-volume narrow tasks, and plain rules where rules work. Then we compare all three on cost per thousand documents.
We pieced these together from Natural Language Processing situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Support mailbox routed by keyword rules nobody will edit
composite · not a client story
Beforethe situation
Thousands of emails a week hit a shared support mailbox. Queue assignment runs on a keyword rule set someone built years ago. It misroutes often enough that agents forward messages by hand, and nobody wants to touch the rules in case something else breaks.
What we dothe work
First we label a sample of recent emails against today's queue list, misrouted ones included, and test an LLM classifier against the existing rules on that sample. Once accuracy per queue is agreed, we distill to a smaller model to cut cost. Anything below the confidence threshold lands in a triage queue.
Afterwhere you end up
Every routing decision has a confidence score attached, and an uncertain email goes to a person rather than to the wrong queue. Adding a queue means labeling examples instead of editing keyword rules.
case file 02
Renewal terms locked in 8,000 scanned supplier contracts
composite · not a client story
Beforethe situation
Procurement has roughly 8,000 supplier contracts, all scanned PDFs. Renewal dates, notice periods and liability caps live in a spreadsheet that is partly stale. Auto-renewals keep sliding past their notice windows.
What we dothe work
Legal signs off the target fields: renewal date, notice period, auto-renewal flag, liability cap. OCR runs first. An LLM then pulls each field and cites the page it came from. We measure accuracy field by field on a labeled sample, and low-confidence results go to a reviewer before anything is written to the contract system.
Afterwhere you end up
Renewal terms for each contract are structured and point back to the source page. Notice deadlines show up in the contract system before they pass.
Inbound text is redacted where needed, then routed to an LLM, a smaller fine-tuned model or rules depending on the task. Extracted fields are checked against a schema and a labeled test set before they are written to the CRM or data platform.
01 · Inbound text
Emails and ticketsshared inbox · case queue → Redaction
DocumentsPDFs · forms · contracts → OCR and parsing · extract text
02 · Preparation
OCR and parsinglayout · tables → Redaction
RedactionPII · PHI fields → Model router · clean text
03 · NLP pipeline
Model routerLLM · fine-tuned model · rules → Large language model · hard cases→ CRM · schema fields→ Data platform · embeddings and labels
Large language modelClaude · OpenAI API
Labeled test setaccuracy per field → Model router · scores
04 · Systems of record
CRMSalesforce · Dynamics 365
Data platformSnowflake · Databricks
Read the diagram as text
Documents → OCR and parsing: extract text
Emails and tickets → Redaction
OCR and parsing → Redaction
Redaction → Model router: clean text
Model router → Large language model: hard cases
Labeled test set → Model router: scores
Model router → CRM: schema fields
Model router → Data platform: embeddings and labels
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Sample and label
A few hundred real documents labeled by your experts, with a short guide so labels stay consistent.
step 02
Baseline
Rules and an off-the-shelf model scored on the labeled set.
step 03
Improve
Prompts, fine-tuning or extra rules added until accuracy meets the agreed threshold per field.
step 04
Integrate and monitor
Results written to your systems, with low-confidence cases sent for human review and sampled regularly.
you keep
What you're left with
We write these for your Natural Language Processing setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
NLP engineer
LLM application engineer
Search and retrieval engineer
Data engineer for text pipelines
Model evaluation engineer
due diligence · natural language processing
Questions to ask any partner, including us.
Put these to anyone bidding on your Natural Language Processing work. The ones who've done it answer differently from the ones who've read about it.
Q1
Will you report accuracy for each field or class, or only overall?
An overall score hides weak fields. A wrong liability cap matters far more than a misspelled supplier name.
Q2
What happens to a result the model isn't confident about?
No NLP system is right every time. What matters is whether its mistakes get caught by a confidence threshold and a reviewer, or written straight into your systems of record.
Q3
Where does our text go, and is it retained or used for training by the provider?
Contracts, claim notes and emails hold personal and confidential data. The deployment route and provider terms should be settled before any text is sent.
Q4
How will you redact sensitive fields, and how do you prove the redaction worked?
Redaction that misses formats like international phone numbers or IDs typed into free text gives false comfort. It needs its own test set.
Q5
At what point would you replace the LLM with a smaller model?
LLMs are a quick way to start. At high volume, a fine-tuned smaller model can be cheaper and faster for the same task once labeled data exists.
01Should we use an LLM or traditional NLP?
It depends on volume, variety and cost. LLMs handle varied, messy text with little training data. Smaller models are cheaper and faster for one narrow task at scale. We often prototype with an LLM, then distill to a smaller model once we have labeled data.
02How accurate will it be?
We can't promise a number before seeing your documents. We agree a target per field, measure against your labeled set and send uncertain cases to people rather than guessing.
03Can the text stay inside our cloud?
Usually, yes. Many commercial models are offered through the major cloud providers' AI services, and open-weight models can run on your own infrastructure. Which route fits depends on your data rules and the accuracy each option reaches.
04Does it work for languages other than English?
Modern models handle many languages, but accuracy varies by language and domain. We include non-English documents in the test set if you have them.
05Can you process scanned documents and handwriting?
Scanned print, yes, with an OCR step before extraction. Handwriting is less reliable. It depends heavily on scan quality and on how people write. We test a sample of your real documents before anyone agrees what can be automated and what still needs a person.
related
Often paired with
Projects on Natural Language Processing usually end up touching one of these, so they're worth a look.
