AI/ML: What Your R&D Team Needs To Know

From research and prototyping to commercial development, AI/ML requires making decisions and trade-off's. This is where the PM needs to provide loads of context to the R&D team: what are the customer problem(s) are that we are trying to solve? What parameters and trade-off's would be acceptable to a customer? Have we considered the cost trade-offs of operating in practice? ​

---

For example:

• is the program intended to deliver a incremental improvement over what exists in the industry today? Or is this a "big bet" to do something very innovative? The former implies use of well-established models, whereas the latter could mean focusing on more speculative research that could take longer and has a smaller chance of a big payoff.

 

• What quality of data will we be able to get in practice, in the field? Has the business considered the cost of obtaining that data, and the cost of performing FMT (filter, merge, transform) / ETL (extract, transform, load)?

 

• What is the cost of an error? The product will make mistakes with some margin of error. Is this a program where mistakes are ok to make because the cost is low. For example, if Netflix recommends a movie you don't like, that's forgivable. If medical software recommends a certain medication that harms a patient, that is not! This kind of cost/benefit analysis allows the R&D team to surface requirements such as “must be at least as accurate as the current process,” or “must provide transparency into how decisions are being made”.

 

• If drift occurs, or without human intervention is the cost still economically viable?

From a data scientist's point of view, whether a model is sufficient to support the business case might be a higher bar than whether the model is a good model. Clear business strategy and customer context upfront can help guide the direction to take the development (kill the research and start fresh, re-focus it, etc.)

Test environment vs. Real-world environment 

Skimping on QA strategy, test environments and real-world testing are classic software development pitfalls. With AI/ML programs, again this problem is amplified. The biggest challenges in commercial success lie in the substantial delta between the test environment and test data, and the highly variable nature of the field. Pitfalls include:

• Test data is not a large enough sample size,
• Test data not representative of reality
• Data in the field requires so much ETL that it is not viable to work with in practice, or data changes from the time it was captured to the time it's processed, leading to lack of accuracy
• Data in the field produces different errors/outliers/rare cases not seen in prototyping that skew results or generate unexpected behaviour
• In research, the features of the data that best predicted results are not available in the data in practice
• Model seemed to be fine in prototype but revealed to simply not be the right model in the field (e.g. due to correlation vs. causation assumptions in the smaller test data set)
• Drift - data changes over time and the model doesn't keep up
• Model works but can't be made performant enough to be commercially viable within the time to deliver
• Business case problems - data sources cost more than expected, the cost of maintaining&retraining the model are too high 

Careful modelling of the different data sources and their attributes - features, availability, timing, anticipated errors and drift - can lay the foundation for the right QA strategy what to test, where to test, and how to judge success.

Give the team the big picture

In AI/ML programs, once production starts, research usually continues in parallel. Managing both as one cohesive team is a new challenge for traditional program managers.

From a process perspective, sometimes the method of communicating the requirements from research to production is by simply giving them the researcher’s Jupyter notebook, or a set of Python or R scripts. If the prod team redevelops and optimizes the code for production while the research team continues from their base notebook, you have the problem of versioning the code and identifying changes.

From a human perspective, it can be easy to assume that because the individual team members are often highly educated and experienced, especially data scientists who may have a PhD. Nevertheless these are still just people, and people see the world through their own lens until the manager gives them the big picture.

To ensure a well-oiled research and production machine:

• Always provide the big picture. Ensure the scientists understand the goals and challenges of production, and the production team understand the goals and challenges of the scientists, as they may otherwise underestimate the risks of each other's parts.
• give the research team production requirements so that the data scientists share in the compromises made with engineers. Conversely, have the data scientists design tests and test data for production
• Ensure whoever is managing has a deep understanding of both sides, including the goals and challenges, and particular terminology, to foster trust with all team members and bridge communication gaps.

​Back in the 1970s and 80s, software development was a sort of "black magic", where both benefits and risks could take you by surprise, forcing management to plan carefully. We have since made leaps and bounds in the maturity and predictability of our software engineering practices, to the point that we take for granted that anything can be engineered given enough time and budget. In a sense, AI takes us back to those early days where anything was possible, but nothing was to be taken for granted. The risks are high, but in a way. that's a good thing - it should increase the maturity of our management processes and responsibility.