Machine Learning Models And Observational Studies

I thought it was common knowledge. We perform an observational study every time we train a machine learning model. When I said that in 2016, many data scientists sent back the mind-blown emoji.

Today there are many more data science educators talking about experimental methods. There are entire systems built to manage experiments. I worked with a team earlier this summer, and no one on that team had been taught observational study design principles.

The team has 3 members with over 7 years of experience. The most experienced has been doing data science longer than I have.

I posted this image on LinkedIn about the gap between boot camp curriculum and real-world data science.

A boot camp founder took that personally and wrote a lengthy comment. It's critical for people to disagree with me, but one line in his comment was eye-opening. He called the deep expertise concepts theoretical and said that the practical skills were the only ones that really mattered.

I looked at the boot camp's curriculum, and their courses teach "How to develop and verify complex prediction models." A predictive model requires study design knowledge to verify. An understanding of knowledge management and SCMs makes for a better validation process. Without those, a data scientist misrepresents a descriptive model as reliable enough to support a prediction.

Even boot camp founders lack the foundational knowledge to succeed in data science. The connection between models and observational studies is still not well understood. This time I'm sending back the mind-blown emoji.

A Simple Framework For Data Science Projects

Changing habits is part of improving the data science process. Lightweight frameworks are the most effective in my experience. The easier adoption is, the more likely the team will continue to use it long enough to see the benefits. Even basic observational study designs lead to better models.

Objectives: Translate the business question or problem into a research question and define the value/need of answering it.

1. Which data sets were used, and what was the selection methodology?

2. Which variables will be observed?

3. What outcome or system will be better defined by the project?

4. Which models will be evaluated, and what was the selection methodology?

5. What risks are introduced by data quality or source issues?

6. What potential confounders exist in the data?

7. What assumptions have been made that will not or cannot be validated?

I implement a review process that's not unlike a code review. I've even used code or document repositories to store and version experiments. Most have a workflow management tool that automates the process.

Another data scientist reviews the design and provides feedback. Domain experts review the assumptions, data selection, and potential confounders. I like the visual nature of causal graphs for experimental review, but early maturity processes don't need that level of detail.

The Benefits Of More Detailed Processes

For many data science teams, this is their first documented workflow. It is a great starting point for defining the complete workflow and introducing continuous improvement cycles. What looks like a small change can save businesses millions in wasted initiatives. The return per initiative rises as well.

My clients see returns go from the low $100Ks to millions in 3 months, even at SMEs. The results at $1B+ revenue generating clients are much more pronounced with returns moving into the $10Ms. 1-2 years later (the larger the company, the longer it takes), with several improvement cycles, data project timelines have dropped from months to weeks. Resources are freed up to work on longer-term innovation initiatives.

None of this works until an experiment design process is introduced to the data science workflow. Model reliability requirements are the other side of the improvement coin. The first improvement cycle for the experiment design process is to add reliability requirements to the objective. I implement a 4-level reliability model, with level 1 being the lowest.

Level 1: Pulling data into reports.

Level 2: Descriptive models and analytics.

Level 3: Predictive models.

Level 4: Prescriptive and diagnostic models.

The business question should be supported with use cases. How will people use the work product? What decisions will they make? What processes are being automated? What functionality is supported?

The process introduces user-centric data science design principles slowly. Users are integrated into the requirements gathering, design, validation, acceptance, and continuous improvement phases. Relationships are built between the business, and the data team. Trust building is part of the data science workflow.

Adoption and user satisfaction rates rise. My goal is to drive both into the 90%'s; it takes about a year to get there. This approach has helped me build the habits necessary for businesses to become data-driven and stop abandoning data products.

There's room for product managers to enter the process and bring customer-facing initiatives to the data team. The first successful feature release is a tipping point for data science. Revenue changes C-level leadership's perspective. Models have a defined value on the balance sheet, and that's a defining moment for the data team.

Trouble Ahead For Our Field

There are ugly implications for businesses that have yet to integrate an experiment design process. Teams are deploying unreliable models to production and providing decision-makers with overextended data. The firm believes it is data-driven and will achieve better outcomes.

Companies are engaging consultants like me to measure their data science initiatives' performance and impacts. Every consultant I have talked to ranks these engagements in their top 5 most common. Finance and healthcare companies are at the leading edge of this trend.

People are hesitant to accept and trust data. Adoption and acceptance are challenging at early data maturity companies. Business users and customers are prone to revert to their old workflows. It's a challenge to build habits and much harder to maintain them.

When I tell clients their current models' shortcomings and actual value creation, it's demoralizing. The business has invested heavily in becoming data-driven. C-level executives have sponsored initiatives and evangelized their success to the board. Most companies spend 3 years and over $10M to learn hard lessons.

Maturing from pilot projects to high-value implementations hits this barrier in most businesses. Interest in data and AI strategies is growing as businesses look to them for solutions.

Drivers For Data Strategy Adoption

Over the next 2 years, every business that hasn't already started the process will. According to multiple studies, that's as many as 75% of all companies. Our challenge is always talent, even in data and AI strategy.

I talked with 5 people thinking about starting their data strategy consulting business this month alone. The surge in demand is motivating people to meet it. In 2015, I was one of the only people working on this problem, so it's nice to finally have some company.

Competition is not always bad. It validates the need, and for the longest time, only about 20 of us were working in this space. Validation means I don't have to spend as much time teaching the need as I did from 2015-2020. It also provides a broader picture of business needs and the drivers for data strategy adoption.

I'll cover those in my next post.