For text pipelines judged on cost and latency, not novelty
NLP Development
Not every text problem needs a large language model, and treating every one as though it does gets expensive at volume. This practice engineers text pipelines for classification, extraction and search, choosing the technique that wins on cost and latency for your actual traffic. Conversation belongs to a chatbot; this is the pipeline underneath it.
How a text pipeline earns its keep at volume
Classification, extraction and the cost comparison that decides which technique wins.
90 secSample frame · video pending01Before any pipeline is built
The decision most text projects skip
Routing every request through a large model feels simple until the bill and the latency arrive together. Four questions settle whether a purpose-built pipeline is the right constraint for your volume.
What is your actual request volume?
A handful of daily requests rarely justifies a custom pipeline. A queue in the thousands changes the cost and latency maths substantially.
Does the task need reasoning, or just classification?
Sorting text into known categories is a narrower problem than open-ended reasoning, and narrower problems usually have a cheaper, faster solution available.
What does a large-model call cost at your volume?
Per-call pricing that looks trivial in a demo compounds quickly at production traffic, which is exactly where a lighter pipeline earns its cost back.
How will accuracy be measured over time?
A pipeline without ongoing evaluation drifts quietly as language and content shift, so measurement needs to be built in from the first release.
| LLM call per request | Purpose-built pipeline | |
|---|---|---|
| Cost at volume | Scales with every request | Scales with infrastructure, not requests |
| Latency | Depends on model response time | Typically faster at the same task |
| Explainability | Limited without extra tooling | Scores and features are inspectable |
| Setup effort | Minimal for a single call | Requires training and evaluation data |
| Right for | Low volume, varied requests | High volume, defined categories |
02Agreed before any build
The ledger that keeps the scope honest
The engagement draws four lines before a pipeline gets built. You supply the text, this practice builds the pipeline, you take delivery of the system, and specific decisions stay with you throughout. Every scenario draws that boundary somewhere different, depending on the volume and risk behind your situation.
- Your side
You bring
- A sample of the text volume needing routing
- The categories or destinations text should sort into
- Current cost and latency of the manual process
- Our side
We build
- A classification model sized to your actual volume
- A measured choice between a lightweight classifier and an LLM call
- A routing pipeline wired into your existing systems
- Your side
You receive
- Automated routing running at your real volume
- A documented cost per item below the manual process
- A fallback path for text the classifier is unsure about
Never leaves you
- The categories and routing rules themselves
- Ownership of the labelled training text
- Authority over the confidence threshold for automatic routing
Where the line sitsA lightweight classifier often beats an LLM call on cost and latency at real volume, measured honestly before committing.
03What actually drives the number
Four drivers, not a flat rate card
Text-pipeline work is priced against the assessment, not a template, because these four factors change the effort by multiples.
Request volume and cost sensitivity
High-volume traffic justifies more upfront pipeline engineering, because the per-request savings compound quickly once the system is live.
Labelled example availability
Existing labelled text accelerates training significantly. Starting from unlabelled documents adds an annotation phase most estimates leave out.
Domain vocabulary complexity
General language models handle everyday text well. Specialised terminology in regulated or technical domains needs targeted training data.
Integration into existing systems
A standalone classifier is straightforward. Feeding results into an existing CRM, search index or workflow tool multiplies integration effort.
04Evidence and proof
Pipelines judged on cost per request, not a proof of concept.
NLP proof is measured cost and accuracy against real text, not a curated demo. Every record here waits for written client approval before production.
Explore case studies
Student feedback stopped taking a marker's full weekend to read.
Pillar Learning collected open-text feedback that sat unread until grading pressure eased. A classification and extraction pipeline now surfaces themes as responses arrive.
- Feedback themes surfaced automatically
- The large majority
- Time to first insight
- Same day, not term-end
Maintenance logs became searchable instead of merely archived.
Nexa Foundry stored maintenance logs as free text nobody could search reliably. An entity extraction pipeline now pulls part numbers, dates and fault codes into a structured record.
- Logs with structured fields extracted
- Nearly all, going forward
- Manual re-entry required
- Eliminated
Watching the cost comparison land in a spreadsheet, not a slide, made the decision easy to defend internally.
Sample · pending client approval
05Read this first
When a custom text pipeline is not the right fit
Selling a custom pipeline to a team whose actual volume never justifies the engineering would cost more than it earns us in trust. The exits are marked before the pitch. When a build is justified, it runs on trained classifiers, an evaluation harness and the search or workflow system already in place.
- Chatbot Development
The need is a conversational interface, not a pipeline
If users should be able to ask questions and get answers, a chatbot is the right product, with pipeline work underneath it if needed.
- AI Agent Development
The task needs to take action, not classify text
If the outcome is a system change rather than a label or extracted field, the right build is an agent, not a text pipeline.
- LLM Development
The volume is too low to justify a custom pipeline
At low volume, a general-purpose large language model call is often the cheaper and faster route until traffic grows.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The categories or fields are defined | Threshold and priorities | Pipeline delivery and evaluation |
| Delivery pod | The scope will grow with volume | Priorities each cycle | Engineering, quality, releases |
| Team extension | Your leads run delivery well | Architecture and standards | Named engineers and continuity |
06Straight answers
Asked before a text-pipeline budget commits.
01Are pre-LLM techniques still worth using?
Often, yes. Classic classifiers and rule-based extraction can beat a large language model on cost and latency at volume, and this practice benchmarks both before recommending either.
02Does this practice handle multiple languages?
Yes, when the training text and evaluation set cover the languages that matter to your traffic. Coverage is scoped against your actual usage, not assumed upfront.
03How is NLP different from a chatbot build?
NLP engineers the underlying pipeline: classification, extraction and search relevance. A chatbot is a conversational product that may use such a pipeline underneath its answers.
04What does an LLM API cost at real volume?
Enough to justify a lighter pipeline once traffic grows, in most cases. The assessment runs that comparison against your actual request volume rather than a demo estimate.
05How accurate is entity extraction on messy documents?
Accuracy depends on document consistency and training data quality, which the assessment measures against your own samples before any commitment to a target figure.
06Can you handle specialised or technical vocabulary?
Yes, through training data drawn from your own documents rather than general language. Specialised vocabulary is exactly where generic models tend to underperform.
07Does this integrate with our existing search or CRM?
Yes, integration is scoped against the specific system your pipeline needs to feed, since routing, extraction and search results all need a landing place.
08Can a pipeline be upgraded to use an LLM later?
Yes, the two are not mutually exclusive. A pipeline can hand harder cases to a large model while keeping routine ones on the cheaper path.