Collaborative Learning and Conversational Intelligence with Digitate’s Maitreya Natu

Hello, and welcome to the latest edition of the Textron AI Leadership Video series. I'm your host, Mike Bazar. Today we're with Mattea na, who's chief data Scientist for Digitate, and we're talking about collaborative learning and collaborative intelligence and how AI may just change the way we all interact with, uh, not just machines, but each other.

Hey, Matea, welcome to the show. Thank you, Mike. We are all of course, talking these days about whether or not AI is gonna replace humans, but perhaps we should be having a different conversation, and it's gonna be more about how maybe AI is gonna change the way we learn and the way we interact with each other.

What should we be focused on? A great starting point. Um, we strongly believe that true power of AI can be harnessed when AI works in tandem with natural intelligence and human and machines are able to collaborate to create new metaphors of what we like to call augmented intelligence.

Uh, and that's where collaborative learning and conversational intelligence kind of play a pivotal role. So instead of worrying about AI replacing humans, I guess we should worry about more about how they can coexist, um, and perform better, In effect, with generative ai, the machines have learned how to talk to us, but do we need to maybe learn how to interact with the machines in there? And maybe ultimately, if we all do that, how to do that in a, in a cohesive way, because it's not just me and one machine, it's everybody around me and their machines.

And how does that all come together? So what do you see that's working? What, what should we be thinking about?

Yeah, in fact, uh, I have two different point of views here. Um, machines also need humans to improve their effectiveness. Um, and humans of course need machines, um, or some way to interact with machines to make the best use of, um, the AI and AI driven insights.

Uh, let me talk with some example. Let's talk in the world of IT operations that there is a machine that is able to automatically resolve incidents automatically. A URL fails, an application goes down, and as a material machine is able to automatically find the cause, find the fix, apply the fix, uh, solve the problem.

But in order to do that, machine needs human in the loop at many places. Um, it needs human to help it, uh, help handle exceptions or unknown conditions. It needs human to often verify and validate the actions that it is trying to take.

It sometimes needs humans to identify the right places to look for. So that's where machine needs humans and on concepts like collaborative learning come into play. On the other hand, humans also have problem to consume AI driven insights.

We like to call it as insight fatigue. So many insights get generated about performance, capacity, risk, compliance, availability, security, and it becomes very overwhelming for the humans to use these insights. And that's where conversational intelligence comes to play on making it easy for the humans to identify just the right insights to consume, uh, and also give a sense of trustworthiness, explainability for humans to adapt or adopt AI in their day-to-day operations.

That's how I look at, uh, this whole game. Right. Um, is there something we should be doing in the realm of training then for people?

And, um, and what approach is that? Because I feel like right now it's more trial and error and a lot more error than trial. Yeah.

Um, definitely. Um, well, well, a couple of aspects. Uh, putting ride guardrails on what data are we training these machines on, uh, is extremely important.

Uh, making sure that these machines are not hallucinating, uh, making sure that, uh, they're responding only within the context that, that you want them to respond to. And at the same time, especially when the machines are, um, say in the space of AIOps where you are also in the line of, um, production, where you are taking actions into business critical applications, you need to put some guide like, um, um, action firewalls where there is always a, uh, a way to validate, uh, what actions are being performed, what is the reason behind it, getting a sense of explainability and trustworthiness behind those actions. So the first mile on what to train it on, and the last mile on what actions it is taking, both need, um, right, uh, security guardrails to be in place for it to work seamlessly.

How do we put those guardrails in place? 'cause I think people are struggling with the speed at which decisions are made, so it's hard to figure out how to put a guardrail in around something that's happening in a split second. Um, well, uh, the guard is on the first mile where you are training it, um, um, to reason, um, that that doesn't have to be in real time in split second because that is happening over a period of time where you're training the engine to understand the system and reason about it.

Uh, the guardrails on the last mile, I agree, they had to be, um, they had to be like split second guardrails. And that's where every action or every inside that the AI engine is taking, um, the engine has to be trained in a way that it is providing explainability, it's providing confidence, it is giving a sense of trustworthiness so that you know that some things which are safe, which are harmless, can be straight through processing. And some things which are business critical, which are seen for the first time need to go through, uh, a certain level of validation verification.

Um, that's the, the, that's the reality of the game, that you can't really let an AI machine go through and do whatever it wants to do without having, uh, any security checks in place. But you have to find a golden medal on where you, where, where you do straight to processing and where you put human in the room. A lot of folks don't seem to know exactly how their AI model works.

So are those the ones that we should be most concerned about? 'cause essentially there are a black box that nobody can explain, and if we can't explain it, we can manage it, right? Uh, more than being worried about, what we have realized is that when you provide a black box insight, there is a big, uh, resistance to adopt that insight.

Uh, business teams are not really willing to take it on its face value. Let's say I'm forecasting demand for tomorrow or next week. People would still want to validate it using their own Excel sheets, their own pivots and retos to make sure that the number is somewhere in the ballpark, uh, range of what their intuition or gut feeling is.

Uh, and that is where, uh, we have to focus more on things like explainable intelligence. Um, there are many ways to do that. You use a black box algorithm to, to predict something or to identify an anomaly or identify a fraud, and you try to generate its equivalent proof of how you reach that logic using a white box algorithm, uh, by white box algorithm, I mean, algorithms that provide visual or textual evidences behind why they are reasoning the way they are reasoning.

Um, finding a right balance of a black box algorithm with a white box algorithm usually helps in, um, establishing that trust. Um, that's also a good trustworthy intelligence practice. Um, in my experience, um, in many, many business critical scenarios, um, business teams are willing to compromise on accuracy a little bit, but they want explainability, they want evidences for why the machine is doing what it's doing.

So yeah, my answer would be that a right mix of black box and white box algorithms and using the tricks of explainable intelligence will be a way forward. Mm-Hmm. There's a saying about ai, it's basically, it's one thing to be wrong, it's another thing to be wrong, it's scale.

Um, how do we kind of figure out, um, what our level of risk here is? Because it's one thing to use AI to come up with say, a email that doesn't make any sense. It's quite another thing to have an entire factory running on an AI engine that suddenly hallucinates Interesting question.

And let me try to draw parallels with what we see day in, day out, and, um, I'm thinking about it. Um, Yeah. Um, the way we have tried to, uh, handle the situation is, uh, by assessing, um, a score of a risk and trustworthiness to the AI insight.

Every AI insight that is coming out has to be, um, has to be rated on different levels of trust. Um, how often have you seen this? How often, um, have you seen its effectiveness?

Um, can I trust it? Uh, what is the urgency or criticality of that insight? What is the potential impact, good, bad, ugly, that it can do?

Um, it is extremely essential to, um, not go for this one size fits all approach. When it comes to AI driven insights. You have to bucketize them into different levels of urgency, criticality, and have different types of firewalls against these insights.

Um, you can also not leave an AI engine uncared, even if it has, uh, it has been behaving consistently for, um, for a significant period of time. Every time you see something unknown, something unseen, there is, it is essential to have the practice of bringing a human, the loop to validate, verify, and let it, uh, through after that. So having that element of giving a score to every area insight and keeping a human in the loop every time you see something unknown unseen, is usually a practice that we follow when it comes to, uh, using AI in the IT operations space.

Mm-Hmm. How much of it is the issue, the AI model itself, or is the issue, the data that was used to train the AI model isn't trustworthy? So maybe we should be scoring the data that we're using first before we even get to the AI model.

Second, I agree with you 100%. Uh, so often it is the data that is a problem, and we end up blaming the AI model. Um, data often contains biases.

Um, data is often incomplete. Um, another huge challenge that we face is small data problems. Everybody is focusing on big data solutions, big data algorithms, but in reality, there are so many events which are by default rare in nature.

Uh, and those are the important ones that need to be addressed. And you have so very, so very little data for such events. Uh, and when you try to train an AI model with small data, um, it, it usually is not able to, uh, perform well.

Um, and even with big data, there is a problem of, um, quality. So the approach that we usually recommend is, uh, an automated data quality assessment where every data is assessed in terms of volume, variety, veracity, and velocity. And, uh, instead of giving, um, uh, qualitative course scores to these, we try to give quantitative scores, numeric scores on how good it is on volume, velocity, variety, veracity, uh, identify gaps.

And only I narrow down the data that is good enough for training an AI model. Use that to make sure that there are no data related forms. You can't do this manually, you can't do it subjectively.

You need automated ways to assess data quality, give numeric scores to it so that it's easily consumable by the users who are providing the data. Mm-Hmm. But then when it comes to models, a good practice that we have learned is that never trust one model.

An ensemble of models and an ensemble of algorithms works well. Their democracy is a great thing to have. If you have 15 different models and 14 of those 15 models are saying one thing, you, you have a higher degree of trust in what that model is saying.

Uh, and then a higher degree of trust on what that data is also saying. And of course, while building this model, you don't use the entire data as is you sample that data, provide different samples to different models, and see that are you reaching the same insight by all the models? So this ensemble approach is, is a very safe, uh, safety net when it comes to dealing with data and dealing with models ambiguities.

Mm-Hmm. We talked about the relationship between the builders of the AI models and the rest of the business. Do the data scientists need to be a little more business savvy?

Because, you know, you'll hear stories about how the data science team created a model that discovered that we have a significant drop in revenue every seven days. And the business people will look at you and say, of course we do. We're closed on Sundays.

So yeah, how do we, how do we kind of bridge that? It's a cultural issue as much as it is a technical issue, Of course. I mean, and not just that the insights are incorrect or, uh, mis um, obviously known to the business leaders.

If the data science folks are aware of business, their quality of insights and their quality of recommendations also improve significantly. Um, you, you raised a, a great example, and we have also seen it, uh, time and time again. We, we raised a, we generated an insight that, hey, there is a day of week pattern and your, uh, response times are very low on weekdays, uh, on weekends and very high on weekdays.

And, uh, people said that, yeah, we reduce our cloud capacities on weekend, and so the response times are high, otherwise they're low, and we know the practice. And if a data scientist is aware of this, they will be able to coate correlate response times with available cloud capacity. And then that insight has a lot more meaning than just an observation.

Um, we think that there is this journey from observation to insight to recommendations. Um, without domain knowledge, you often stop only at observation. And observation is something like, Hey, I'm, I'm identifying an increasing trend in this time series.

That's what a data scientist would be happy with. That observation turns into an, into an insight when somebody realize that, hey, this time series is a CPU utilization time series. That increasing trend means that the cpu, this CPU can range between zero 200.

And this increasing trend shows me that my CPU is likely to saturate in next 40 days. That's where an observation turns into an insight by the knowledge of domain. And that knowledge of domain has to be taken one more step ahead to turn it into a recommendation so that the user understand that, hey, this is a server that is surveying a business critical application.

It doesn't have a backup, so I need to solve this problem by horizontal scale and not vertical scale. Such things are possible only when you understand the domain, the domain of the technology or the domain of the business or whatever it's needed. So otherwise, people will only stop at observations.

They will not be able to go to insights, definitely not to the recommendations. So what is your best advice for achieving this collaborative intelligence then? Do I just throw everybody in a room and lock the door and keep their own pizzas under the door until somebody figures out what's going on?

Or is there a methodology to the madness? Yes. I mean, there is definitely a methodology to the madness.

Uh, so when it comes to collaborative learning, and I'm gonna split, uh, my thumb rules into two, um, when I say collaborative learning, uh, I talk about places where machines need human health. Uh, and when I say conversational intelligence, I talk about where humans need assistance to work with machines. They are slightly different.

So when I talk of collaborative learning, some rules of thumbs are, um, you have to make sure that you are making the, the human in the loop experience, uh, very easy. Um, you have to ask just the right questions at the right time. Let me take an example that, uh, machine is trying to, as I said, uh, do auto triage automatically resolve a problem and fix it?

That's what the machine is trying to do. And when it needs human in the loop, it has to do two things very well. One is ask just the right questions at the right time and know when to trust humans and when to trust data.

These are two big levers while ensuring, uh, collaborative learning. Uh, when it comes to conversational intelligence, the rules of thumbs are, uh, so conversation intelligence is where humans should not be getting inundated by insight fatigue. So first is, um, understand the context and just provide the right insights that might be relevant to the user.

And second is bring explainability behind the insights. These two would be very important rule of thumb for, uh, bringing conversational intelligence. Uh, let me take an example there as well.

Let's say, um, you are, um, the line of business head for, uh, billing of a retail store. You are coming to this AI machine, and AI machine is throwing you hundreds of insights that, Hey, I'm seeing risk here and trends here and saturation there and so on. You will hate it.

You would rather say, gimme red or tell me five areas that need my attention. And now the AI machine should be smart enough to just answer that. Now, it observes you that outta MyFi insights.

What is it that you're looking for? Let's say you are looking at why the point of sale server is failing so often in this store, and then the AI machine understand that, hey, you're looking at availability of a point of sale and leads the conversion by finding the causes, recommending the fixes, or showing similar scenarios that you had seen in the past and fixed in a certain way. Then the business, uh, business teams would be able to adopt that AI machine not feel threatened by it, or not feel uncomfortable, comfortable with it as well.

Uh, so these rules would have to be very useful. All right, folks, you heard that here. I think we need some sort of social contract between the machines and the humans and how we're all gonna go forward together.

Hey, Mateo, thanks for being on the show. Thank you. And thank you all watching the latest episode of the Techstrong AI video series.

You can find this episode and others on our website. Until then, we'll see you next time.