AI engineering
ML & computer vision
Forecasting, classification, ranking, detection and segmentation — the work where a trained model beats a prompt on accuracy, latency and cost. We start with the simplest model that could work and only escalate when the numbers ask us to.
- Forecasting & prediction
- Classification & ranking
- Object detection
- Segmentation & OCR
- Model serving
- Drift monitoring
What we build
- Baseline and benchmark
- The simplest model that could work, scored first, so every later gain is measured against it.
- Trained models
- Tabular, vision or ranking models trained on your data with a documented method.
- Inference services
- Served behind a typed API, sized for your latency target and traffic shape.
- Edge and on-device deployment
- Quantised and exported where inference has to run without a round trip.
- Monitoring and retraining
- Drift detection, scheduled evaluation and a retraining path that is already wired.
Problems this solves
- Problem
- A language model is being used for a task it is slow and expensive at.
- Approach
- Benchmark a purpose-trained model against it on your data, on accuracy, latency and cost per prediction.
- Outcome
- The right tool wins on evidence, and often the cheaper one is also the more accurate.
- Problem
- The model was accurate at launch and quietly is not any more.
- Approach
- Monitor input drift and outcome quality in production, with alerting and a retraining pipeline already built.
- Outcome
- Degradation is caught by a monitor rather than by a complaint.
- Problem
- A promising notebook has no route into production.
- Approach
- Rebuild it as a versioned, tested service with reproducible training and a deployment pipeline.
- Outcome
- The model becomes a system your team can change without fear.
How we approach it
Discover
We establish what beating nothing looks like — the majority class, the rule you use today, a person doing it. A model that cannot clear that is a finding, and it is much cheaper to have in week two.
Design
The metric is chosen to match the cost of being wrong, before anything is trained. Precision and recall are rarely worth the same amount, and where the threshold sits is a business decision.
Engineer
The simplest model that clears the bar goes first. Data, features and code are versioned together, so a result can still be reproduced six months later.
Evaluate & harden
We evaluate on the slices that matter rather than on the average, because a model that looks strong overall and fails on your busiest segment has failed. Latency and cost per inference are held to budget.
Launch & operate
Drift is monitored against the training distribution and retraining is a scheduled pipeline with a gate. A model nobody is watching is a model quietly getting worse.
What we build it with
The first thing we run on a new problem: three candidates, one metric chosen for the class balance, and a printout that decides whether to escalate.
"""Baseline first. Escalate only when the numbers ask you to."""
from sklearn.dummy import DummyClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import average_precision_score
from xgboost import XGBClassifier
CANDIDATES = [
("majority class", DummyClassifier(strategy="prior")),
("logistic regression", LogisticRegression(max_iter=1000)),
("gradient boosting", XGBClassifier(n_estimators=400)),
]
for name, model in CANDIDATES:
model.fit(X_train, y_train)
scores = model.predict_proba(X_valid)[:, 1]
# Average precision, not accuracy — the positive class in
# this problem is 3% of the data and accuracy would say 97%.
ap = average_precision_score(y_valid, scores)
print(f"{name:>20} AP {ap:.3f}")
# A model only ships if it beats the row above it by more than
# the spread across folds. Most of the time, it does not.Languages
- Python
ML & computer vision
- PyTorch
- scikit-learn
- XGBoost
- Ray
- OpenCV
- YOLO
- ONNX Runtime
Observability & evaluation
- MLflow
Questions we get asked
How much data do we need?
Less than most people expect for a first useful model, and more than they expect for the last few points of accuracy. We start by benchmarking a simple model on what you already have, which tells us whether the constraint is data volume, labelling quality or the framing of the problem.
Can the model run on our own hardware or at the edge?
Yes. We export to ONNX or TensorRT and quantise where accuracy allows, so inference can run on your own servers or on a device without a round trip. We measure the accuracy cost of that trade before committing to it.
Do you also handle labelling?
We design the labelling scheme, write the guidelines and build the review loop, and we can work with your team or a labelling vendor to run it. Inconsistent labels are the most common cause of a disappointing model, so this is treated as engineering rather than admin.
How do you know it still works six months later?
Input drift and outcome quality are monitored in production against the same metrics used in training, with alerting on both. The retraining pipeline ships with the model, so acting on a drift alert is a run rather than a project.
Tell us what you are trying to ship.
A first call is 30 minutes and costs nothing. Bring the problem rather than a spec — the useful part is usually working out whether this is the right shape of solution at all.
contact@algologix.coWe reply within 24 hours.