What this shows is how easy it is for mapping services to register false positives when the right checks and balances aren’t in place. Take, for example, vehicle probes that determine the presence of vehicles on the road. If there was no traffic on the road for a certain period, a conventional AI solution might conclude that the road is closed, and provide that information to drivers, causing them to avoid the area and look for alternative routes, causing unwanted disruption. This solution takes a ‘one size fits all’ approach, and while this would work in countries with high-density populations, in Australia, it’s not as accurate – due to our sparse population. It is a given – authorities must have access to accurate information around road accessibility, particularly in times of emergency that require swift evacuation.
The approach we take at Intelematics is different. Every piece of information we receive is verified through three sources. If we get information through probes (e.g. from GPS units) saying a road is congested, we then verify it against sensors located in copper cabling under the roads. While many companies have access to probes, not many have access to these in-road sensors. If the sensors also tell us that the road is congested, we then verify it against the journalistic data we receive, which could be a Tweet from a road authority, warning of an incident on a particular road. Only once the information has been through the three source verification process, do we communicate an alert. We take the perspective of the driver, the road, and reputable third parties to give context. We don’t make assumptions, and as a result, we record only a few false positives.
While this gives us incredibly accurate information, it is also a time-consuming process – so you can understand why we were so keen for it to be automated.
How to train your robot
When it came to automating the process, we knew it would be necessary to invest in training data sets upfront. Training data sets are the difference between your machine learning and AI model working and not working. Let me give you another example.
Devices like Amazon Alexa and Google Home are supposed to be programmed to register your voice, interpret what you’re asking and then carry out the command. They are supposed to use machine learning and AI to perform this function. We all get frustrated with these devices because they so often fail to carry out seemingly simple commands; however, I would argue they’ve been set up to fail.
These devices haven’t been programmed with proper training sets. In essence, that means the machine learning hasn’t even occurred. Every time a Google Home, or an Amazon Alexa fails to perform a task, the information is sent to an offshore centre, where a human listens to your voice and interprets your command, and then codes that information back to a database that will be used to train the machine better. This means that these devices are on the equivalent of their AI and machine learning ‘learners’ plate’ – they haven’t done their 120 hours, and they’re not yet fully competent. They’re apprentices, learning on the job.
On the other hand, our Toasti has already put in the work to become a qualified expert before being released to the market. The way we did this was straightforward. As I said, there’s no magic in machine learning – it’s all about repetition.
We introduced Toasti to six other human colleagues who would teach it how to interpret data. Whenever a piece of communication from social media, an email, an API or FTP came in, we would assign the key information a code, to then upload to our interface to be communicated to our customers. For training purposes, the key information we focused on was the location, cause and effect.
For example, if we received a piece of communication that said: single-car incident at Somerton Road, emergency services on-site directing traffic, expect delays – then our team of people would input to our interface (for example) code 201 for the location (Hume Highway, Somerton exit specifically) 301 for the cause (a single-car incident) and 401 for effect (lane closures causing delays). Of course, our probes and sensors would’ve already detected unusual activity in the area, but we code the information into the interface only after it has been validated through a third-party source.
That coded information would then be translated into machine language and fed into GPS’ provided to drivers by our customers, which then helps navigate routes accordingly.
While initially, this process was carried out by humans, Toasti was learning from its human colleagues and trying its hand at coding the right information into the interface at the same time. In the early days, each of Toasti’s output was verified by a human operator before being uploaded to the interface. This was Toasti’s learning period. Only once Toasti reached 85% accuracy was it allowed to then upload coded information to the interface unsupervised.