AI & Machine Learning Engineering
Kornspire engineers production AI: retrieval-augmented generation, document understanding, classification and forecasting, with evaluation harnesses, guardrails, cost control and human review where accuracy matters.
The problem
The demo that cannot be shipped
A prototype that answers ten curated questions well tells you almost nothing about production. The hard part arrives afterwards: what happens on the question nobody anticipated, how a wrong answer is detected, what the feature costs at a thousand times the volume, whether the output can be attributed to a source, and who is accountable when it is wrong.
Signals you have this problem
- An AI prototype exists but nobody can define what 'good enough' means numerically
- Output quality is judged by impression rather than a test set
- Per-request cost and latency at real volume are unknown
- There is no path for a human to catch a wrong answer before it reaches a customer
Our approach
Evaluation first, and the cheapest model that passes it
We define the task and build an evaluation set with expected outcomes before choosing a model. Then we start with the simplest approach that could pass — often retrieval with a well-structured prompt rather than fine-tuning — and escalate only when evaluation shows we must. Guardrails, cost and latency budgets, logging and a human-review path are built in from the beginning, not added after a failure.
Feasibility and evaluation design
Task definition, a representative evaluation set with expected outputs, quality thresholds, and an honest view of whether AI is the right tool at all.
Retrieval-augmented generation
Document ingestion and chunking, embeddings and vector search, reranking, and answers with citations back to the source passage.
Document and language understanding
Extraction into structured fields, classification and routing, summarisation, with confidence scoring and review thresholds.
Predictive and forecasting models
Feature engineering, leakage-aware training and validation, calibration, drift monitoring and scheduled retraining.
Guardrails and safety
Input and output validation, prompt-injection defences for tool-using systems, scope limits, refusal behaviour and abuse logging.
Cost, latency and reliability engineering
Model selection against measured quality, caching, batching, streaming responses, fallback models and per-feature budget alerting.
MLOps and monitoring
Versioning of prompts, models and datasets; evaluation in CI; production quality sampling; and alerting on regression or drift.
Outcomes
What changes for you
- A numeric definition of acceptable quality, measured on every change
- Answers traceable to a source rather than asserted
- Known cost and latency per request at projected volume
- A human-review path wherever a wrong answer would be consequential
Deliverables
What you receive
- Evaluation set and quality report with thresholds
- Implemented feature with guardrails and logging
- Cost and latency model at projected volume
- Prompt, model and dataset versioning
- Monitoring for quality regression and drift
- Documentation of limitations and the human-review path
Evidence
What you can check before you call
Each item below links to something you can verify yourself — our own product, this website, or the engineering playbook we publish.
- Our product
An AI booking assistant in live use
Upkilo's assistant handles enquiries, rescheduling and common questions, and hands over to staff when it cannot help.
See the AI chatbot on upkilo.com(opens in a new tab)
How it runs
The engagement, step by step
- 01
Define and evaluate
Specify the task, build the evaluation set, set the quality bar. If the bar cannot be defined, the feature is not ready to build.
- 02
Prototype against the bar
Start with the simplest viable approach, measure it, and escalate model or technique only when the evaluation requires it.
- 03
Engineer for production
Guardrails, cost and latency budgets, caching, fallbacks, logging, and the review path for low-confidence output.
- 04
Monitor and improve
Sample production output, watch for regression and drift, keep the evaluation set growing from real failures.
- Python
- TypeScript
- PyTorch
- scikit-learn
- Hosted LLM APIs
- Vector databases
- OpenTelemetry
- Model evaluation harnesses
Typical engagements
What this looks like in practice
Illustrative shapes of work rather than client stories. We publish client work only with the client's consent and with real figures, so these describe the problem and the approach instead.
Answering questions over internal documents
Retrieval over your own policies and manuals, with citations and a refusal when the corpus does not contain the answer.
Structured extraction from incoming documents
Turning invoices, forms or contracts into structured records, routing anything below the confidence threshold to a reviewer.
Demand or capacity forecasting
A calibrated forecast with uncertainty intervals, monitored for drift and retrained on a schedule.
Answers
AI & Machine Learning Engineering: questions
What is AI and machine learning engineering?
AI and machine learning engineering is the work of turning a model — whether a hosted large language model or a trained predictive model — into a dependable product feature, including its data pipeline, evaluation, guardrails, cost profile and human-review path.
Should we fine-tune a model or use retrieval?
Retrieval first, in almost every case. Most business requirements are about grounding answers in your own current data, which retrieval addresses directly, cheaply and with citations — and your data can change without retraining. Fine-tuning is appropriate for consistent format or style, for a narrow specialised task, or when latency and cost at high volume favour a smaller specialised model. The evaluation set decides, not preference.
How do you prevent an AI feature from inventing answers?
By grounding responses in retrieved source passages and citing them, instructing and testing for refusal when the sources do not support an answer, validating output structure, and scoring confidence so low-confidence cases route to a human. These reduce fabrication substantially; they do not eliminate it, and we do not claim they do. Any feature whose wrong answer would be consequential keeps a human in the loop.
What will an AI feature cost to run?
That is modelled before build, not discovered afterwards. Cost per request depends on model choice, input size, retrieval strategy and cache hit rate; we measure it on your evaluation set, project it to your expected volume, and set budget alerting. Where cost is the binding constraint, we optimise for it explicitly — usually through a smaller model, tighter retrieval and caching.
Who owns the data used to build the feature?
You do. We document which data is sent to which provider, what that provider's retention and training position is, and where processing physically happens — so data-residency and DPDP Act questions have written answers. Where those constraints require it, self-hosted or regional model deployment is designed in instead.
Deep dives
5 detailed articles on this topic
Longer technical pieces, each covering one specific decision inside this service. Written to be argued with, not skimmed.
Keep reading
Related services
Considering ai & machine learning engineering?
Tell us the outcome you need and the constraints you are working inside. You will get a straight answer about whether this is the right service, a smaller one, or none of ours.
Prefer email? hello@kornspire.com