Machine Learning Development
A model makes the work it's given faster, mistakes included
So we fix the work first, from the decision a model feeds to who checks what it flags. Then we build the model that makes that work faster.
Book a 30-minute callMost of the gap is closed by the work around the model
Between a model's first output and something your team can safely act on, there is always a gap. That gap is the first-output deficit, and it's widest where output lands in work nobody redesigned. So the system around a model matters as much as the model itself. Every output meets the checks your team set, and the occasional one that fails goes back with the correction logged, which becomes labelled data for the next round of training. The rest go straight through to the people who decide, far faster than before.
0 passed first time · 0 corrected after a failed check · example run
The model is the last thing we choose
We build classification, forecasting, document extraction and retrieval systems. Which one fits is settled by the work it has to serve, and every one of them has to beat a baseline, be judged on a measure that matches the cost of being wrong, and be monitored once it's live.
A credit team needs a threshold it can defend, not just a score
Your credit policy decides how many defaults among approved loans it will accept, and who follows up the applications that get flagged. The model then serves that policy. We train a random forest against a single decision tree as the baseline and calibrate it, so a score of 0.3 means about a 30 per cent risk. Accuracy, which is meaningless at a five per cent arrears rate, never decides anything. What you gain is a loan book triaged in minutes, with the reasons behind every flagged score.
- random forest
- calibration
- stratified CV
- SHAP
- PSI drift
The technical detail
Hyperparameters tuned by randomised search over stratified folds. A score of 0.3 is roughly a 30 per cent risk, so the threshold can be set as a rule that approves as many as possible while defaults among the approved stay under your cap. Where records carry dates, validation is split by time.
A forecast is only useful if planners trust its range
Planners need to know how wrong a forecast might be before they order stock on it, so the range matters as much as the number. We start from the strongest simple forecast, the same week last year, and a model earns its place only by beating it in a rolling-origin backtest, using lagged sales, prices, and Ghanaian public holidays and pay days. Branch orders can then be set each week from figures with an honest margin, instead of from last year's numbers and a hunch.
- gradient boosting
- exponential smoothing
- WAPE
- MASE
- prediction intervals
The technical detail
Every origin of the backtest is scored, not just the last. Forecasts carry prediction intervals so planners see the likely range, and branches with little history borrow strength from similar branches.
An invoice reader has to know when it isn't sure
Most invoices in Ghana arrive as a photo taken at an angle, which defeats template matching, and no reader gets every field right. So we settle first what happens to the uncertain ones, then build OCR with layout-aware extraction that scores every field and sends anything below threshold to a person. The clear invoices are posted in seconds, and your staff spend their time only on the few that need them.
- OCR
- layout-aware extraction
- per-field precision
- format validation
The technical detail
Precision and recall are reported per field, not as one accuracy figure. TIN and Ghana Card numbers are validated against their formats before posting, and corrections made in the review queue become labelled training data.
In English and Twi, the hard part is the data, not the model
One message can be a complaint and a payment query at once, and many switch between English and Twi mid-sentence. Before any model, the categories have to match how your team actually handles enquiries. We then treat it as multi-label classification, with class weights for the rare, urgent labels. Labelled Twi data is usually what's missing, so where it doesn't exist yet, the feasibility assessment plans how to collect and label it. Once it works, urgent messages reach the right person first, in whichever language they were written.
- multi-label
- class weights
- macro F1
- data labelling
- API in a container
The technical detail
Evaluated on macro-averaged F1 against messages your own staff have labelled, so the small categories count as much as the common ones. Served behind an API, so it plugs into the tools your staff already use.
Mepa wo kyɛw, my payment from yesterday hasn't reflected and the shop says I owe.
payment querycomplainturgent
Ɛte sɛn? I want to change the delivery address for my order.
delivery change
An answer your documents don't support shouldn't be written
A language model's first answer reads well whether or not it's right, so the documents it may draw on, and who keeps them current, are settled before anything is built. Retrieval runs before generation, every claim in the answer is checked against the passages retrieved, and an answer the documents don't support is refused. Staff get answers in seconds that they can trace to the page they came from.
- hybrid retrieval
- reranking
- claim checking
- local models
The technical detail
Lexical and dense retrieval combined, then reranked, and evaluated on a question set your own experts wrote and answered. Where dollar-priced APIs don't make sense, a smaller model runs on your own infrastructure.
QuestionHow many days of annual leave can a staff member carry over?
AnswerUp to five days, used by the end of March. HR policy, section 4.2
QuestionCan I claim mileage for a trip to Kumasi?
AnswerYour documents don't cover this, so no answer is given.
Before you pay for a build, we measure the gap on your data
Every build starts with a written feasibility assessment, for a fixed fee we send by the end of the next working day after our first call. It begins with the decision the model would serve, and its baseline shows how far a simple model already gets on your own data. That tells you the honest size of the gap before you commit, which is also why the length of a build is set out there, for your project, rather than guessed on a website.
Feasibility assessment
What the written report covers
- The decisionWhat the model would flag, who acts on it, and what each kind of error costs
- The dataExploratory analysis of volume, quality and whether the labels exist
- A baselineThe simplest model that could work, scored on held-out data
- The evaluationThe metric that matches the cost of error, and the level worth reaching
- The risksLikely failures, leakage and bias, and what needs monitoring
- Hosting and data protectionWhere it runs under Act 843, and what drives running costs
- The verdict and the planBuild it, don't, or build it once a stated condition is met. Then the stages, how long each takes, and a fixed fee.Build itDon't build itBuild it once…
Questions before you book
Who owns the model, the data and the code?
You do. Your data stays yours throughout, and once the build is paid for, the trained model and the code written for it are yours too. The general tools and methods we bring to every project stay ours, and you get a permanent licence to use them in the system we built for you.
What if we don't have enough data, or it isn't good enough?
Some builds work with a modest amount of well-organised data, others need years of history. The feasibility assessment tells you which, and if your data can't support the build, it says so and what would change the answer, before you pay for one.
How accurate will it be?
Nobody can honestly promise a figure before seeing your data. The feasibility assessment tests a baseline on a sample of it and agrees the metric and the level the model has to reach, and the build is judged against that.
Where is our data kept?
Where you need it to be. We agree hosting, access and data protection with you before we build, in line with the Data Protection Act, 2012 (Act 843).
What does it take to keep it running?
Running costs depend on where it runs and how often it's used, and the feasibility assessment sets them out before you commit, including whether a smaller model on your own servers would cost less than a hosted one billed in dollars. After handover you can run it yourselves with our documentation, or keep us on a monthly retainer to monitor it, retrain it as your data changes and fix anything that breaks.
Book a 30-minute call
Start with one problem
Tell us what you’d like the model or tool to do and what data you have. After the call you get a fixed fee for a feasibility assessment.
- We reply immediatelyWith a link to book your 30-minute call.
- A 30-minute callTo understand the problem and what a good result would look like.
- A written scope and a fixed feeBy the end of the next working day after the call. You’re under no obligation to go ahead.
Prefer email or a call? info@asledatalabs.com or +233 55 348 0047.