Small & Specialised Models
Agentic systems run on models. Most of the time a frontier model behind an API is the right choice. Sometimes it isn't: the task is narrow, the output has to conform exactly, the data can't leave your network, or the API bill and its dependency have become the problem. For those cases I develop small, domain-specific models built for one purpose.
Small language models and domain-specific models
This extends my work from building agentic systems to developing the models inside them.
A general-purpose model is very good at many things, and you pay for all of them on every call. A small model trained for one task does that task consistently, runs on modest hardware, and keeps behaving the same way because nobody else is updating it. For retrieval, extraction, routing and other well-defined steps, that is often the better trade.
Three kinds of small model have their own pages: LLM fine-tuning for generative tasks, structured output and tool calling; classifier training for routing and categorisation; and ASR fine-tuning for speech recognition, where my own published fine-tunes show the approach working. This page covers the rest: the embedding models, rerankers, extraction models and on-device models that pipelines also depend on. I build them myself or advise your team while they build them.
Specialised models I build
Bespoke models that sit inside pipelines, agents and workflows.
Embedding model fine-tuning
General embedding models don't know that two of your product codes, or two terms of art in your field, mean nearly the same thing. Fine-tuning an embedding model on pairs from your own documents improves retrieval for RAG pipelines and semantic search.
Rerankers
A small cross-encoder that re-scores the top results from search or retrieval against the query, trained on your own relevance judgements, so the passages a model reads first are the right ones.
Extraction and NER models
Named entity recognition and field extraction models that pull names, dates, amounts, reference numbers or domain-specific entities out of documents and messages, returned in a fixed structure.
Accessory models for pipelines
Small models that handle a single stage of a larger pipeline, such as tagging, filtering, extraction or routing, so the expensive model only sees the work that needs it.
Replacing API dependencies
Where a workflow calls a third-party model API for a narrow task, a model you own can take its place. You stop depending on another provider's pricing, rate limits and model changes for something your process needs every day.
Reliable structured output
Models trained to produce output that conforms to a fixed schema every time, for the tool calls and MCP connections where a malformed response breaks the workflow.
On-device and edge AI
Small language models (SLMs) and compact task models quantised to run on laptops, phones, embedded devices or a single local server, for offline use and low latency.
On-premises models
For organisations with data residency or sovereignty requirements, models small enough to run inside your own infrastructure, so sensitive data never goes to an outside provider.
Why output conformity matters more now
MCP and tool calling are a big step forward. They also make standardisation more important.
When a model only wrote text for a person to read, a slightly different format each time did no harm. Once the model is calling tools, its output is the input to another system. A missing field, an unexpected value or a different date format turns into a failed call, a wrong record or a workflow that stops halfway.
The more of your operations run through tool calls and MCP connections, the more of that reliability depends on the model producing the same structure every time. A model trained on your schema is one way to get there. Choosing it is part of the consulting below: sometimes validation and a well-specified prompt are enough, and I'll say so.
Consulting: from training data to deployment
Many teams want to build the model in-house. I can plan it with them and stay involved through rollout.
Training data plan
A plan for how the training dataset will be put together: what data you already have, what has to be collected or labelled, how much is needed, and how your team produces it internally.
Training plan
A plan for creating the model itself: the base model, the training approach, how results will be evaluated, and the stages from first experiment to a model ready for production.
Post-training and reinforcement learning
Recommendations on which methodology to follow, whether supervised fine-tuning, preference tuning or reinforcement learning, based on the task and the data you can realistically produce.
Fine-tuning providers and compute
Which provider to fine-tune with, and on what: managed fine-tuning services, serverless GPU or dedicated GPU instances, compared on cost, control and where your data goes.
Deployment recommendations
How the finished model is served: as an internal API inside your network, as a public API, or on serverless inference, and how it plugs into the agents and pipelines that will use it.
Implementation partnering
Working alongside your team through implementation, or building it for you, from the first dataset to the model running in production.
Hiring me for Small & Specialised Models
A small model for one narrow job in your pipeline (embeddings, reranking, extraction, structured output), built by me or planned with your team and built in-house.
Who it's for
- Pipelines where one step depends on an expensive or unreliable API call
- Retrieval that misses because general embeddings don't know your domain
- Data that can't leave your network, or models that must run on a device
- Teams that want to build the model in-house and need a plan and a second pair of eyes
What you get
- A specialised model (embedding, reranker, extraction or small LM) you own
- A training data plan and a training plan
- An eval against the API or general model it replaces
- Deployment recommendations, or the deployment itself
- Partnering through implementation if your team builds it
What I need from you
- The task and where it sits in your pipeline
- Representative inputs and expected outputs
- Where the model has to run, and any latency or hardware limits
- A technical contact, especially if your team is building it
How it runs
Typically 4–8 weeks for a build; a planning-only engagement is shorter.
- Week 1
Task and baseline
Define the step the model replaces and score the current approach.
- Weeks 1–2
Data and training plan
What data exists, what has to be produced, base model and method.
- Weeks 2–6
Build or partner
I train it, or your team does with me reviewing each stage.
- Weeks 5–8
Evaluate and deploy
Compare against the baseline and plug it into the pipeline.
Training work has no public price list. Each model is scoped after a short call and quoted as a fixed price, paid against milestones.