Show Your Work

When I had the opportunity to be on Reid Hoffman’s Masters of Scale podcast, he mentioned that AI companies needed to come up with a phrase that would briefly describe their differentiators. I quickly quipped,

“Bast AI builds AI that shows its work.”

I have pride and sorrow in having this as Bast’s most understood differentiator. Pride in that we have built software designed to explain and show the work and choices made. Sorrow in that showing your work is not currently the default modality for AI systems. It’s absurd to see how much money has been spent on AI systems that aren’t explainable. My sorrow is short-lived because I do not doubt that Bast’s version of AI software will be the default; it is the next generation of AI systems.

AI systems that can show and explain how and why they predict the answer are trusted systems; these systems are partners for humans and thus will be widely adopted. Adoption is the first of many problems that we have solved with our software. This blog is dedicated to necessity; she is the mother of invention and is beautiful only after you have had the pleasure and tenacity to do the work and admire the frustration. The only way out is through.

My CTO and I were on the phone with a prospective new teammate for Bast, and after 90 minutes of a deep dive, he relayed the following.

“I looked at your website and thought to myself, they purport to solve all the issues with LLMs and GenAI. But after 90 minutes of the deep dive, it occurred to me that you have not only solved all these issues, but you are showing me how much experience you have that others lack. You have worked to solve problems that most AI system developers will never even encounter.”

This engineer reminded me of something I often forget. I have created and led teams that have fixed more AI systems than others have built. I have anecdotes, battle scars, and stories that cover the range of designing, developing, deploying, testing, duct-taping, and supporting AI systems.

I am a victim of the Dunning Kruger bias — I know how much I don’t know about AI systems. Most — if not all of the data scientists/developers I have worked with, trained, or encountered have asked me the golden question.

“How can I belong to a team that gets to deploy their model into production and have it be used.”

My answer is the same — join a delivery team in a large corporation and solve your client’s problems using data and the scientific method. Single developers design or build their models; most never make it to production. There is a reason for this: AI is a team sport, people desperately believe there is an easy button, and humans value what they pay for.

Ironically, so many “data” people have not waded through the data to understand what was happening in the systems. Our necessity to solve our clients’ problems taught us how to innovate in so many ways and to be curious about how we can do something better the next time and how we can do more with less. These are the drivers in everything we have built: an insatiable curiosity about what the data says, a frugality with non-renewable resources, a team including domain experts who understand the problem we are solving, and a desire to use the right tool for the right problem. We try to fit form with function and tap the power of limits.

Back when we were still at IBM, and I was working to create an understanding in data scientists that they needed to start with the business problem they were solving, I got an inkling of what was to come. This was back in 2012, and we started creating a profession and a career path for data scientists that would allow them to test their mettle against other certified data scientists and have their work peer-reviewed.

Our data science profession requires projects that show the scientist understands the entire cycle of implementing a data science project with a business outcome. In 2015–2016, everyone wanted to do the latest, most incredible thing — first predictive analytics and then machine learning and deep learning. Because GPUs or graphical processing units could process large amounts of data, it became reasonable for people to shove large datasets into “piles of linear algebra” and have the AI system output the “features or predictors” of the data set. There are obvious problems in not understanding your dataset — it means that you likely don’t understand the problem you want to solve and don’t do the work to see if you have the suitable dataset with the right variation to solve the business problem.

The more obvious issue with this approach is quite apparent — if you don’t sanitize or understand your inputs, you have no control over your outputs.

It would be reductive and unfair of me to state that nothing has come of this hopefully brief quest for larger GenAI models that require so much of our earth’s resources to build and train. We now live in a world where many more humans know what AI is. For this alone, I am thankful because we must have as many of the 8 billion humans aware of what AI is and what it can do for our ecosystem. I would prefer we had a representative sample, and 1.6B people are working to develop and deliver AI systems.

TL;DR

Contact us if you want to replace that LLM or GPT model with a for-real full-stack AI brain. If you want a quick guide, use the infographic below or copy and paste these questions into any generative AI system to see whether the answers lead you back to Bast. Or if you want to see the answers I got from OpenAI.

Questions:

Can you tell me the difference between an AI system that includes a data pipeline vs. one that doesn’t?

Can you tell me the difference between an AI system that includes a knowledge graph to ground context and increase NLU vs. one that doesn’t?

Can you tell me the difference between an AI system that includes a data pipeline for a feedback loop vs. one that doesn’t?

Can you tell me the difference between an AI system that uses microservices code architecture to scale over Kubernetes clusters vs one that doesn’t?