From Trained Model to Your Crew's Phone

The last mile is where AI projects stall

Plenty of computer-vision projects look great in a demo and never reach the people who actually need them. The model lives on a server in a data centre. The inspection happens on a pole, in a trench, or in a basement with no signal. Between those two points, most projects quietly die.

For an operations leader, that gap is the whole game. A model that can spot a defect is worthless if your crew can't run it where the work happens. So the real test of any inspection-AI tool isn't the accuracy chart; it's whether the trained model ends up on the phone in your inspector's hand, working with or without a connection.

That's the problem Forge is built to solve. You train a model on your own faults using your own team, and Forge ships it to your crews' phones. This post walks through the evidence behind that last step, packaging a model small enough for a phone, and proving the packaged version still behaves like the original.

Packaging a model small enough to live on a phone

A model trained on a server is large and expects server-grade hardware. To run on a phone, it has to be converted into a compact on-device format, smaller, lighter, and able to run on the phone's own processor.

We took several custom detection models, trained on real field-inspection imagery, and exported each one to that compact mobile format. All of them converted successfully, and the resulting files were small enough to sit comfortably on a standard work phone, in the low tens of megabytes. That's a download your crew won't think twice about, not a multi-gigabyte install.

Small files matter for a practical reason: they make over-the-air updates realistic. When you retrain a model on new defect examples, pushing the improved version to every phone in the field is a quick update, not a logistics project.

On-device model files came in at low tens of megabytes, small enough to push to every phone in the field as a routine update.

The accuracy that survives: 90%+ on real faults

Compact files are only useful if the models inside them are actually good at finding faults. Across the trained detection models in this set, the strongest reached around 94% detection (measured as mAP@0.5, a standard detection score), and three of five scored above 91% on real inspection imagery.

Those are not toy numbers on a tidy benchmark; they come from models trained on genuine field faults, the kind your inspectors deal with every day. For an operations team, detection in the low-to-mid 90s means the model is a dependable second set of eyes: catching the defects a tired crew at the end of a shift might miss, and flagging them consistently every time.

We're keeping the per-model figures rounded and high-level on purpose. The point isn't a leaderboard; it's that purpose-trained models, built on your own data, can reach field-grade accuracy and then be packaged to run on a phone.

Top model ~94% detection (mAP@0.5); three of five above 91%, on real field faults, not a tidy benchmark.

The QA proof: phone scores match the server, near-perfectly

Here's the worry every operations leader should have: when you shrink a model down to run on a phone, does it get dumber? Does the compressed version start missing things, or rank detections differently from the full server model your team trusted during testing?

So we ran a separate, focused quality check. We took one model, ran the same set of images through both the full server version and the compact on-device version, and compared the detection scores side by side. The agreement was near-perfect: a correlation of about 0.997 between the two, with an average score difference of essentially zero, and the on-device version was roughly 5.5 times smaller.

Read that carefully, because the distinction matters. This study measures how faithfully the phone version preserves the server model's scores and the order of its detections. It is not a fresh accuracy measurement on the phone; that's the separate result in the section above. What this check tells you is that compression didn't quietly change the model's judgement. The phone sees what the server saw.

Phone vs server: ~0.997 score correlation, mean score delta near zero, at roughly 5.5x smaller.

No re-tuning, and fast enough for the field

Because the phone version preserves the server model's scores so closely, something convenient falls out for free: the confidence threshold you set during testing on the server transfers straight to the phone, with the same value and no re-calibration. You decide once how cautious or aggressive the model should be, and that decision holds in the field. No separate tuning exercise for mobile.

Speed held up too. On the phone's own processor, with no cloud round-trip and no waiting on a signal, inference averaged well under 100 milliseconds per image. That's faster than a person can blink, which means the model can keep up with an inspector working at their normal pace, even somewhere with no connectivity at all.

Put together, that's the practical recipe for the last mile: a small file, accuracy that survives the trip, judgement that doesn't drift when the model is compressed, one threshold that works everywhere, and speed that disappears into the workflow.

How Forge ships your trained model to your crews

This is the value prop made literal: deploy trained models to your team's phones in days, not months. You bring the images and the knowledge of what a fault looks like. Forge handles training the custom model, packaging it for the phone, and getting it onto your crews' devices, with the QA framing above so you can trust that the phone version behaves like the one you signed off on.

No data scientists. No outside consultants. No off-the-shelf cloud vision service that only recognises generic objects and never your specific defects. Just your team's expertise, turned into a model that rides along in your inspectors' pockets.

If you run field inspection in telecoms, utilities, or infrastructure and you've watched AI projects stall before they reached the field, this is the part we've solved. Book a demo and we'll show you the path from your faults to your crew's phone.