AI/ML is a relatively new domain on the market and there are slight confusions using the related terminology even among specialists.

Non-technical clients might have a slightly unrealistic understanding of what ML can or cannot do. Even with the technical clients it is important to make sure to establish a common ground, to ensure that you use the same terminology and have the same understanding over the development lifecycle of an AI solution, the roles involved at each step.

Example: I happened to find myself in few discovery meetings with potential clients to discuss and assess their ML use cases, but realized that in fact the problems brought by the clients were either big data problems, or even devops ones. Most of the time these situations happened because of the terminology misunderstanding and created frustrations on either the client and our side.

A personal recommendation for what I find to be the most accurate terminology is the online course “AI for everyone” by Andrew Ng. This course targets especially non-technical persons and offers an easy-to-understand perspective on what AI is and what AI can or cannot do.

ML is rather a multi-disciplinary field standing at the confluence of business and technology. Business insights are always the key ingredients that lead to a successful solution and very often to innovation.

There is a temptation among technical teams to use the latest technologies just for the sake of experimenting new things, but the business function must always be the one who determines goals and outcomes during the design and implementation process.

Example: After delivering a deep learning solution workshop to one of our AI savvy clients, we were presented with a strong opinion by our customer to select AutoML for this particular problem. But the results were not as expected: our deep learning model remained one of the top preferences among the other optimized models outputted by the AutoML. What made the difference between our solution and AutoML was mostly the data cleaning and preparation step. We based the design of the solution on business insights, while the usual AutoML platforms only offered standard solutions for text cleaning and embedding.

As previously mentioned, the business should be the primary functional organization that drives the goals for an intended solution. Therefore, there should be a continuously tight collaboration between the AI development team and the business team during all development processes.

Business input is critically needed at least in these two phases: discovery phase and validation phase. During the discovery phase, business knowledge helps in modeling the solution, while in the validation phase, the business team will validate/invalidate the solution according to the established success criteria. In the latter case, their input and analysis will guide things towards a new round of optimizations.

Example: The first example that came into my mind when thinking of this, is when we developed a fraud detection solution for one of our clients. At the beginning of our collaboration we were given the problem specifications along with a dataset of financial data, but without any other data insights. Despite our efforts, we were not able to get the involvement of the business team to provide us answers to some basic questions, such as: what ‘normal’ transactions looked like?, or: what is the probability to have fraudulent data? All this created tension on the development team side, and a few months of unnecessary investment on the client side. When finally the client became aware of the blocker and assigned a business resource to the project, we were able to move forward and make some real progress. We shortly figured out how to properly clean the data by eliminating unnecessary or redundant features, even identifying inconsistent data that needed to be fixed. Moreover, we were able to define a validation methodology that helped us measure the progress through the optimization process and in the end, to quantitatively validate the solution.

If the technology that solves your problem already exists, don’t hesitate to use it.

Building a new solution from scratch when there is not necessarily needed will delay the delivery due date and will introduce additional costs that can affect the client’s trust.

Allow yourself enough time for the discovery phase to properly assess the problem and to find the facts that help you decide if an existing solution does the job, or a customized one is really needed.

There are many open source solutions on the market, such as deep learning predefined architectures, pretrained models, NLP preprocessing tools, word embeddings, part of speech extraction, object detection, image captioning and many many others. They are all intended to support the AI community and speed up the development process, therefore it is worth taking advantage of them.

Example: A trivial example here is face detection. In one of our projects, we had to preprocess the input images and restrict the region of interest to the person's face. Therefore we used some existing libraries which nicely did the job, and allowed us to deliver a successful PoC. Later in the process, we had to readdress the face detection module and propose a lighter model to reduce the computation time and reach the requested real time conditions. In this case, an existing solution helped us prove the concept, win the project and gain time for the production ready solution, which was exactly what we needed at that time.

In case the addressed problem requires a customized solution, now is your chance to prove your ML skills and allow yourself to be creative.

Building an AI solution is like painting a masterpiece. Usually you have a clear understanding of the final point you want to reach, but there are endless techniques, tools and processes that can get you there. Frankly speaking, the careful selection and implementation of those details will truly determine the outcome and make the difference between a successful solution or a mediocre one.

After defining the problem specifications and getting all the needed insights in the discovery phase, it follows the designing (or modeling) step. This is the core step where basically the business knowledge is ‘translated’ into a machine language so that the machine will be able to learn from data what it takes to replicate the business process.

The creativity in the modeling step should come from the intuition behind the concepts of AI that develops from experience. This experience based intuition will guide the process of preprocessing the data and the choice of the most suitable ML algorithms/techniques for a specific use case.

Example: We had a NLP use case where we had to identify a specific pattern in text. We proposed a custom solution, a very light ML model that took as input the fixed sized vector containing the searching keywords and its neighbours together with their corresponding part of speech and obtained an 85% accuracy. A parallel approach was developed using Bert transformer, the state of the art language model, but obtained only 64% accuracy. The custom model brought not only a significant qualitative improvement, but also an improvement of the execution time and a drop in the infrastructure costs of a few thousands dollars per month.

When you develop a ML solution and the results are not as expected, it is usually due to one of these two reasons: either the proposed model architecture is not suitable, or the data you train is not good enough.

When the architecture has been tested and deemed solid, then is the time to take a hard look at the dataset.

Example: We were supposed to solve a ML problem for one of our clients, where we had to map some medical records into some specific categories. We implemented the solution using the latest NLP techniques at that time, but the results didn’t seem to be accurate. We hit our best results after reviewing and optimizing the model architecture and focusing our attention on the data that was best suited for ML input. One dynamic in the equation that we didn’t expect was human variability that was a high factor and a primary reason for our solution not delivering the expected results. After a few rounds of refining the data by the business team and re-initiating into the NLP process, we shortly managed to obtain a 20% higher accuracy in proper record classification.

There are times that building and deploying a PoC will deliver excellent results. However, when scaling the solution off an enterprise architecture, be open to the fact that the quality of the output might not be reliable or in alignment with the same results as the PoC.

It is known in the ML practice that it is hard to provide precise estimations, since the success of the project is closely related to the quality and accessibility of the data. You may provide estimations for a first functional version, but it might take a few more steps to optimize the solution to reach qualitative results. And optimization often means to start the whole process all over from the beginning, meaning twice the initial development time. Moreover, this loop might need to be repeated a few times until reaching the expected performance.

When reaching the end of the ML workflow and the quality of the results is not aligned to the acceptance criteria, there is no reason to panic, it is part of the ML process. It is important to have in mind from the beginning this recursive nature of the development process and set realistic expectations together with the client so that you can allow yourself to reassess the proposed solution and not give up after the first iteration.