AI engineering
LLM engineering
Making a language model reliable enough to put in front of a customer — grounded in your data, measured against your cases, and deployed where your data is allowed to go.
What this is
The work, described plainly
The gap between a promising demo and a system you can defend is almost entirely engineering. Retrieval that returns the right passage, prompts that survive edge cases, an evaluation set that catches a regression before a customer does, and a deployment target that satisfies whoever owns the data.
Retrieval usually matters more than the model. A smaller model reading the correct paragraph beats a larger one guessing, and it costs less per call. Most of the work is in chunking, indexing, and ranking — the unglamorous part that decides whether the answer is right.
Fine-tuning is a last resort, not a first move. It is worth it for format and tone, or for a narrow task with plenty of examples. It is rarely the fix for a knowledge problem, and it is the most expensive way to find that out.
What you get
What is actually handed over
Concrete deliverables, not phases on a timeline.
Retrieval pipeline
Chunking, embedding, indexing, and ranking, tuned against your documents rather than a public benchmark.
Evaluation harness
Real cases with known-good answers, scored automatically, so prompt and model changes are measured rather than debated.
Scoped knowledge boundaries
Public, customer-specific, and internal content kept separate, with retrieval that cannot widen its own scope.
Deployment
Hosted API, private endpoint, or open-weight models on your own hardware, depending on where the data is permitted to go.
Is this you
Signals this is the right fit
- You have documentation people cannot find answers in.
- A prototype works in the demo and fails on real questions.
- Your data cannot be sent to a third-party provider.
- You need to prove the system is not getting worse over time.
Typical stack
Chosen per project against your constraints, not applied by default. This is what the work usually involves.
- Claude, GPT, Llama, Mistral
- pgvector, Qdrant
- Structured outputs and JSON schema
- Prompt and output logging
- vLLM and Ollama for self-hosting
FAQ
Questions people actually ask
Fine-tune or retrieve?
Retrieve, in most cases. If the problem is that the model does not know your facts, retrieval fixes it and fine-tuning does not. Fine-tuning is for when the model knows the facts but will not produce them in the shape you need.
How do you know whether it got better?
An evaluation set built from your real cases, with expected answers, run on every change. Without it, "it seems better" is the only available measure, and it is usually wrong.
Can we run this entirely on-premise?
Yes, with open-weight models. Expect to trade some answer quality for control, and to budget for GPU hosting. We will tell you before you buy hardware whether your use case survives that trade.
Start here
Tell us what is slow, manual, or breaking.
Answer a few questions and get a written brief back — scope, proposed architecture, and what it would take to build.