Latest / The Adults In The AI Room / Machine Learning and Algorithms - Gordon Hart - Earley AI Podcast with Seth Earley & Chris Featherstone - Episode # 027

Transcript

Machine Learning and Algorithms - Gordon Hart - Earley AI Podcast with Seth Earley & Chris Featherstone - Episode # 027 · The Adults In The AI Room

• 0:03
  SPEAKER_00: Welcome.
• 0:04
  SPEAKER_00: You're listening to the Early AI Podcast.
• 0:07
  SPEAKER_00: Here we talk with thought leaders and practitioners on what's possible and practical with AI in the enterprise as we move from the current state to a future of cognitive assistance and embedded AI in all aspects of our personal and professional lives.
• 0:22
  SPEAKER_00: Thanks so much for listening.
• 0:23
  SPEAKER_00: If this is your first time, we invite you to subscribe wherever you listen to podcasts.
• 0:28
  SPEAKER_00: And now here are your hosts, Steph Early and Chris Featherstone.
• 0:36
  SPEAKER_01: How have you been?
• 0:37
  SPEAKER_01: I know uh lots going on in your world.
• 0:39
  SPEAKER_01: Uh uh, we had the uh frigid uh thousand degree below zero um wave up here.
• 0:45
  SPEAKER_01: Um I don't know how how you were experiencing on your next of the woods.
• 0:50
  SPEAKER_03: Well, I'm just I'm just glad that it's all mutually exclusive because um not that I want anybody to freeze, but the other day, you know, I was driving from um from basically Missoula to Salt Lake City and it was negative 27 below before wind chill.
• 1:09
  SPEAKER_03: Yeah.
• 1:10
  SPEAKER_03: And you know, I mean, I mean, the coldest place on earth is somewhere in Siberia, and these people deal with 50 to 70 below on a daily basis and stuff.
• 1:19
  SPEAKER_03: And it was very, you know, it's oddly similar when you're starting to look at people and they just leave their cars running at their houses and stuff, right?
• 1:27
  SPEAKER_01: So it doesn't freeze.
• 1:28
  SPEAKER_01: Right.
• 1:29
  SPEAKER_01: It's crazy.
• 1:30
  SPEAKER_01: Yeah.
• 1:31
  SPEAKER_03: So you know, yeah.
• 1:33
  SPEAKER_01: Yeah, my friend uh Jeff Carr lives in Calgary, and that's what they do.
• 1:37
  SPEAKER_01: They uh on on those oil uh fields, they leave uh machines running 24 hours a day.
• 1:42
  SPEAKER_01: Uh and actually in Washington in Mount Washington, uh here uh in uh uh our area, it was uh something like 110 degrees below zero with the wind.
• 1:52
  SPEAKER_01: So that was like the coldest reported in Isle.
• 1:55
  SPEAKER_01: Well, welcome to today's podcast.
• 1:57
  SPEAKER_01: Our guest today is co-founder and head of product at Colina, which is a machine learning testing platform that allows machine learning and AI teams to test their models' behavior and uh effectiveness.
• 2:12
  SPEAKER_01: He's currently living in Washington, D.C.
• 2:15
  SPEAKER_01: Please welcome Gordon Hart.
• 2:16
  SPEAKER_01: Nice to have you, Gordon.
• 2:19
  SPEAKER_04: Thank you, Seth.
• 2:19
  SPEAKER_04: Thank you, Seth and Chris, for having me on today.
• 2:22
  SPEAKER_04: Uh as the founder and uh at an ML testing platform over the last two years since founding, I've done little else other than think about ML testing.
• 2:32
  SPEAKER_04: And it's my favorite thing to talk about.
• 2:34
  SPEAKER_04: So I'm excited to be here on your show today uh and chat about it with you.
• 2:38
  SPEAKER_01: So, Gordon, uh how did I I don't think it wasn't that cold for you uh down in DC.
• 2:44
  SPEAKER_04: We've had uh our first couple of days of winter kind of this week uh in early February, but it's normal, you know, in the in the 50s now again.
• 2:52
  SPEAKER_01: Yeah.
• 2:53
  SPEAKER_01: So let's jump into our topic.
• 2:55
  SPEAKER_01: Um, you know, machine learning uh uh algorithms many times are uh you know are challenging from different perspectives, right?
• 3:03
  SPEAKER_01: The performance of these algorithms sometimes uh varies from what we expect.
• 3:08
  SPEAKER_01: Uh many times there uh there's yeah there's not a lot of transparency and visibility into how neural networks work.
• 3:16
  SPEAKER_01: Uh and so let's just talk a little bit about uh why um it's challenging to test machine learning algorithms and kind of give us your your background from Afghospective, which has been your experience there.
• 3:29
  SPEAKER_04: Absolutely.
• 3:30
  SPEAKER_04: So I'll start over the past seven years.
• 3:32
  SPEAKER_04: I've been the product owner for various machine learning-based computer vision products, uh, mostly in the defense and security space across different companies.
• 3:41
  SPEAKER_04: And first, I was the head of product and first engineer at a company called Synapse, a startup based out in the Bay Area in California, where we, our mission was to automate the detection of all sorts of prohibited items in security X-ray scans.
• 3:58
  SPEAKER_04: Uh, you can think guns, knives, improvised explosive devices in an airport context or uh narcotics or other illicit substances in a uh border or international mail facility context.
• 4:11
  SPEAKER_04: And the the job that these screeners have is extremely challenging.
• 4:16
  SPEAKER_04: They're looking at uh image after image for long periods of time, looking for things that really don't occur all that frequently.
• 4:23
  SPEAKER_04: And it's uh it's just something that humans aren't that well suited to.
• 4:26
  SPEAKER_04: It's a it's a thankless task and one that is that is really challenging.
• 4:29
  SPEAKER_04: And so it seems like it's a pretty obvious candidate for automation with uh the recent advances that we've seen and the capability of a lot of these detection algorithms.
• 4:38
  SPEAKER_04: And uh that company where it was working on these detection algorithms ended up getting acquired by Palantir, where I worked on uh similar detection systems from for all different sorts of sensor modalities, from uh security cameras installed on buildings all the way up to satellites flying in low Earth orbit, uh, where we're capturing, processing, and uh performing prediction on images right there as far out on the edge as you can get.
• 5:04
  SPEAKER_04: Wow, nice.
• 5:05
  SPEAKER_04: That's great.
• 5:06
  SPEAKER_04: And there's really been one consistent thread through all of that.
• 5:09
  SPEAKER_04: As as we're uh developing these algorithms internally or buying them from other model vendors, uh the one thing that has really remained constant is that uh unexpected model behavior when you actually go to deploy these into the field is the norm.
• 5:24
  SPEAKER_04: And you really can't trust models to behave in ways that you you think are sensible as a human.
• 5:32
  SPEAKER_04: And so uh I didn't set out with the intention of founding an ML testing platform company.
• 5:38
  SPEAKER_04: I was kind of forced into it because time and time again, we're running into this where something that is completely unexpected and out of the blue uh blindsides us.
• 5:46
  SPEAKER_04: And you know, I was thinking there has to be a better way.
• 5:49
  SPEAKER_04: There has to be a better way to develop these models and validate that they're gonna do things that you uh want them to do.
• 5:55
  SPEAKER_04: They're gonna set out and achieve the objectives that you set for your product.
• 5:59
  SPEAKER_01: And you had walked through kind of uh a couple of really uh interesting examples.
• 6:04
  SPEAKER_01: Uh you want to talk about the one where you you had the uh the image that was perfectly uh uh perceivable by a human that you're out that the algorithm missed.
• 6:14
  SPEAKER_04: Yeah, absolutely.
• 6:15
  SPEAKER_04: So at Synapse with this detection system, we had uh some extremely advanced detection capabilities to the point where you could take a, let's say, a handful of small caliber handgun ammunition, like 22 bullets, and throw them in a backpack that has a laptop and a camera and chargers and all other things that make it really hard to detect these uh tiny little uh pieces of ammunition inside a bag.
• 6:41
  SPEAKER_04: And we detect every single one of them almost every single time.
• 6:44
  SPEAKER_04: And this is the kind of superhuman performance that you often expect from these ML systems.
• 6:50
  SPEAKER_04: And we had our latest and greatest model.
• 6:53
  SPEAKER_04: We've gotten our customers really excited and we installed in this new airport uh somewhere in the United States.
• 6:58
  SPEAKER_04: And the security director at this airport is, of course, very excited to give his fancy new technology a spin.
• 7:04
  SPEAKER_04: And he starts, he's okay, I'm gonna put it through the paces, starting with what I think is the easiest example.
• 7:10
  SPEAKER_04: I'm gonna take a gun, a prop gun, and put it in the center of an empty bin and run it through the machine.
• 7:15
  SPEAKER_04: And he runs it through the machine.
• 7:17
  SPEAKER_04: It's this clearly recognizable gun from the side view.
• 7:20
  SPEAKER_04: You know, even if that's all there was in the bin.
• 7:23
  SPEAKER_04: All there was the the bin itself is pretty much completely transparent under X-ray.
• 7:28
  SPEAKER_04: You just see this gun, it's very bold there, it's unmistakable, even if you've never seen an X-ray before.
• 7:33
  SPEAKER_04: And of course, just missed it.
• 7:35
  SPEAKER_04: It missed it.
• 7:36
  SPEAKER_04: It missed it.
• 7:37
  SPEAKER_04: Obvious, obvious gun.
• 7:40
  SPEAKER_04: As obvious as it can get.
• 7:42
  SPEAKER_04: And then we, you know, we're we're starting.
• 7:44
  SPEAKER_04: Probably did not make a great impression at the time.
• 7:46
  SPEAKER_04: Absolutely not.
• 7:47
  SPEAKER_04: I mean, we're we're sweating, we're we're telling him, oh, this is our best system yet.
• 7:51
  SPEAKER_04: We've been building this for years.
• 7:53
  SPEAKER_04: Every time, every model is better than the last one.
• 7:56
  SPEAKER_04: We have now 99.5% recall for guns, and we've shown him examples of extremely difficult guns, cases where a human, if you if they didn't know that there was a gun, almost certainly wouldn't have found it.
• 8:10
  SPEAKER_04: And this is not only for you know really heavy metal guns, this is also for polymer guns and guns that are made of aluminum, which are a little less common, but are very hard to detect in these x-ray scans.
• 8:20
  SPEAKER_04: And so we quote these numbers, and of course, 99.5% recall, you'd think you're gonna miss one out of every 200 guns that goes through your scanner.
• 8:29
  SPEAKER_04: And if you're a human, you're saying, okay, cool, that one in every 200 is probably gonna be the hard case.
• 8:35
  SPEAKER_04: And so, you know, the 199 easy cases.
• 8:38
  SPEAKER_04: Right.
• 8:38
  SPEAKER_04: So, so what went wrong here?
• 8:40
  SPEAKER_01: And and and how could should should have that been validated or tested?
• 8:45
  SPEAKER_01: What what was what was the um problem?
• 8:50
  SPEAKER_04: The core problem really was the approach that we were using to validate these models and decide that they're good enough for deployment in the field.
• 8:59
  SPEAKER_04: Uh, we had a large benchmark data set that we're using to test against.
• 9:04
  SPEAKER_04: It had hundreds of thousands of images with all different sorts of varieties and presentations and orientations and occlusion levels and all of that.
• 9:12
  SPEAKER_04: It was a vast and varied database of images.
• 9:16
  SPEAKER_04: And we would run a new model against that benchmark and compute some of these high-level metrics and say, you know, for example, at this threshold, we were we had 99.5% recall across this entire hundreds of thousands of images of handguns and x-ray scans.
• 9:32
  SPEAKER_04: And that is really the approach that led us into this scenario where our model has severe underperformance in an important scenario, uh, but we're unaware of it.
• 9:44
  SPEAKER_04: And this came to be came into being because we had had uh some other problems with false positives and similar scenarios.
• 9:52
  SPEAKER_04: And so we worked to uh improve the false positives in those scenarios, and that had come at the cost of well, now we're missing, we're failing in this extremely common presentation.
• 10:05
  SPEAKER_04: This this as easy as it can get when it's just the gun and the empty bin, because our evaluation didn't give us visibility into what we were doing and what we weren't doing.
• 10:14
  SPEAKER_01: So so tell me what you know, what was what was what is the typical approach for testing these models and why is that problematic and why would it miss something like that like that?
• 10:26
  SPEAKER_03: Well, I know I was just gonna add on to what you're saying too, because oftentimes, you know, in order to get really good accuracy on, let's say, a given outcome for any kind of an MMO, you have to have a ridiculous amount of data for that, right?
• 10:40
  SPEAKER_03: So I either go through an A-B test through them just to see what the accuracy is.
• 10:46
  SPEAKER_03: But, you know, one, I think the question like Seth is asking is how are you going to do this?
• 10:51
  SPEAKER_03: And then two, at scale, how do we test it at scale?
• 10:55
  SPEAKER_04: Yeah, and those are great questions.
• 10:57
  SPEAKER_04: And I think that really the the key challenge here is that when you even when you have all this data, if you're just looking at that one number, you're looking at that aggregate metric computed across your entire benchmark, that is abstracting away all of the different ways in which you succeed and ways in which you fail.
• 11:17
  SPEAKER_04: And if you have one model, let's say that has 99% recall, and we're using recall here, but really any metric, it'll change depending on the type type of problem that you're doing.
• 11:26
  SPEAKER_04: But if you have one model that has 99% recall and the next model has 99.5, you now, you know, you should miss half as many cases.
• 11:36
  SPEAKER_04: But what's the overlap of those failure modes?
• 11:39
  SPEAKER_04: As a human, you would expect, okay, sure, those extra 0.5% will come from the easier half of that 1% that my previous model missed.
• 11:47
  SPEAKER_04: But you're not really guaranteed to have that sort of overlap in your failure modes.
• 11:52
  SPEAKER_04: And unless you're testing in such a way that you get a behavioral report card that says, here's how I do in an empty bin, here's how I do in high occlusion, here's how I do uh for old and miscalibrated sensors, unless you break that big benchmark data set down into these well-scoped unit tests that are probing into performance in a particular scenario, you're you're unable to answer that question of am I going to perform acceptably in this scenario?
• 12:21
  SPEAKER_01: So basically you have an ensemble of algorithms that are each performing in a certain way.
• 12:27
  SPEAKER_01: But then when you aggregate the performance across these different algorithms that are that are specialized in different areas, lose the granularity, and then you lose some of those uh use cases.
• 12:38
  SPEAKER_01: So, how do you kind of how do you how do you uh set separate that out to get the right level of granularity or uh the component?
• 12:46
  SPEAKER_04: You could be using an ensemble of models or it could just be one single model.
• 12:51
  SPEAKER_04: But if your evaluation is just running all of those examples through your model and crunching all of those results into a single metric, that single metric is never going to tell you where you succeed and where you fail.
• 13:06
  SPEAKER_01: Okay.
• 13:06
  SPEAKER_01: So what would the so what's the alternative to that?
• 13:10
  SPEAKER_04: So the alternative is uh if you have a product that you want to succeed in scenario, then you would test specifically in A, B, C, and D, and you'd get a metric where you say, okay, my recall in scenario A is 99%, my recall in scenario B is 90%.
• 13:29
  SPEAKER_04: And you would break down your evaluation into these different scenario-based test cases that give you an understanding not only of does this model improve in the aggregate over previous models, but how are my failures distributed?
• 13:44
  SPEAKER_01: Okay, okay, that makes a lot of sense.
• 13:46
  SPEAKER_01: And you've used the term, you talked about models failing silently.
• 13:50
  SPEAKER_01: What does that really mean when a model fails silently?
• 13:54
  SPEAKER_04: Yeah, so when you're performing this form of evaluation where you just use that one big aggregate benchmark and you go from 99% in your previous model to now 99.5% in your new model for a metric like recall, but it could be F-score, AP, or anything depending on the kind of model that you're developing.
• 14:15
  SPEAKER_04: Um the silent failures are when you have a meaningful shift in the distribution of those failures of that 1% or that 0.5% that your model no longer handles well.
• 14:28
  SPEAKER_04: And to make this concrete, you know, in this example with the gun and the empty bin, we used to be okay at that example.
• 14:33
  SPEAKER_04: We would catch 100% of those.
• 14:35
  SPEAKER_04: You know, as no matter how many images we could collect like that, we'd catch every single one of them.
• 14:40
  SPEAKER_04: And we had a silent regression because we had a couple hundred or thousand of these images inside our test set, but the big performance regression in that scenario was masked by improvements elsewhere.
• 14:53
  SPEAKER_04: I see.
• 14:54
  SPEAKER_04: Okay.
• 14:54
  SPEAKER_04: We improved so much in other scenarios and hard scenarios that our our top level number went up, even though now we were really underperforming in a scenario that we used to have no problem with.
• 15:07
  SPEAKER_01: So when you think about uh testing, when you think about like if an organization is building their model or if they're purchasing a model, really uh or or you know, buying something from a vendor, who is really responsible for testing?
• 15:22
  SPEAKER_01: Because you have to test in your environment, your data, right?
• 15:26
  SPEAKER_01: I mean, obviously, if you're developing in-house, you know, are the are the do organizations in in when they're you know, they have their machine learning operations, right?
• 15:36
  SPEAKER_01: The DevOps for machine learning, do they have the capability or you know, who is responsible?
• 15:43
  SPEAKER_01: Is it the business?
• 15:44
  SPEAKER_01: Is it the developers?
• 15:45
  SPEAKER_01: And if and especially if you're using a third-party uh tool, you're expecting that the vendor has tested, but talk about those different testing scenarios and who would be responsible.
• 15:56
  SPEAKER_04: Yeah, absolutely.
• 15:58
  SPEAKER_04: So engineers or computer vision engineers who will be developing these models, they're gonna try to maximize their stats on whatever evaluation criteria you set up for them.
• 16:08
  SPEAKER_04: So if you give them one aggregate benchmark, they're doing their job if the new model has a higher number on that.
• 16:14
  SPEAKER_04: And so the the product owners, the stakeholders here who are involved in specing out what are we actually trying to solve?
• 16:22
  SPEAKER_04: What does success actually mean for us?
• 16:25
  SPEAKER_04: What are the scenarios that really hurt us as a business?
• 16:28
  SPEAKER_04: You need to represent those and encode those at into your evaluation system for your models.
• 16:34
  SPEAKER_04: Otherwise, your engineers, your team who's going to be doing the hard work here and improving your models are going to be improving against some evaluation rubric that doesn't align with your product objectives.
• 16:46
  SPEAKER_03: So let me ask you this then, because this is such a fascinating topic, by the way, Gordon, because it's such an overlooked piece.
• 16:53
  SPEAKER_03: Because what we what I feel like we do in this world is we get super hung up on accuracy scores.
• 17:02
  SPEAKER_03: But to your point, accuracy scores are only as good as the outcome that you're driving towards.
• 17:08
  SPEAKER_03: So who cares if it's accurate, but it doesn't meet the business objective, like you're saying, like codifying the res the what the outcome is driven by the stakeholders needs to be, you know, what we're actually aiming and targeting for.
• 17:24
  SPEAKER_03: But oftentimes we miss that because, you know, our training data or training the models is, you know, bad input, you know, in whatever data in, data out, right?
• 17:36
  SPEAKER_03: In terms of garbage in, garbage out.
• 17:38
  SPEAKER_03: So how is, you know, is training data and testing it mutually exclusive?
• 17:43
  SPEAKER_03: Is one more important than the other?
• 17:45
  SPEAKER_03: How do you, how do you, you know, what do you recommend in terms of when we're thinking about that for organizations?
• 17:50
  SPEAKER_04: Yeah, it's a it's a good question.
• 17:53
  SPEAKER_04: At risk of going out on a limb here, I'll I'll say that your testing data in terms of testing data versus training data is actually vastly more important because your testing data is what you're using to actually decide if your new model has the behaviors it needs to have.
• 18:12
  SPEAKER_04: You're using this testing data to inform, can I deploy this?
• 18:16
  SPEAKER_04: Does it do what I set out to do?
• 18:18
  SPEAKER_04: Is it going to be better than what I've previously deployed?
• 18:21
  SPEAKER_04: All of these business critical decisions are informed by your testing data.
• 18:25
  SPEAKER_04: And your training data is in some ways just an implementation detail.
• 18:30
  SPEAKER_04: You know, if you can use, if you can have some crazy magical architecture that only requires a couple of training examples, then that's just as good from a business perspective as an architecture where you feed in tens of millions of examples.
• 18:43
  SPEAKER_04: What matters are the imparted behaviors.
• 18:45
  SPEAKER_04: And if you don't have a meaningful way to evaluate whether or not those behaviors have been imparted on your model, then you're kind of shooting in the dark here.
• 18:54
  SPEAKER_01: So if you have a small uh training set, but your your testing data, your testing set is showing that you have a performance, and you're giving that granularity, who cares, right?
• 19:04
  SPEAKER_01: I mean, you can do it, you can do it with a small uh training set, great.
• 19:08
  SPEAKER_01: But what's what you're saying is really critical is is the testing data because that's what we're trying to uh go against.
• 19:15
  SPEAKER_01: That's where we're trying to impact uh some some type of outcome.
• 19:19
  SPEAKER_01: So that that does make sense.
• 19:22
  SPEAKER_01: And and maybe talk a little bit about, you know, when you're developing these things, you're doing it in one environment, right?
• 19:28
  SPEAKER_01: You're doing it in a POC, sandbox, uh, and maybe it's going to perform really well there.
• 19:34
  SPEAKER_01: But then when you get into the real world, you get into production deployment, uh, what variables are changing?
• 19:41
  SPEAKER_01: And what does that uh mean in terms of how are those different?
• 19:45
  SPEAKER_01: I mean, I have my ideas on how they're different, but I'd love to hear from you in terms of how those are different and what you have to account for.
• 19:53
  SPEAKER_04: Yeah, yeah.
• 19:53
  SPEAKER_04: And this is typically where a lot of the surprise comes into play.
• 19:58
  SPEAKER_04: You think you've rigidly uh strictly validated something in the POC environment in the lab, and then you go and deploy it into production and you see just things that are coming totally out of left field.
• 20:10
  SPEAKER_04: And there's a ton of reasons for this.
• 20:12
  SPEAKER_04: There's uh, of course, the data itself might be different.
• 20:15
  SPEAKER_04: In many places, it's not feasible to use the same data that you actually have access to in production, whether it's for restriction purposes or anything else.
• 20:24
  SPEAKER_04: It's not feasible to use that for uh training and testing for your development cycle.
• 20:28
  SPEAKER_04: But and that's sometimes a hard one to solve.
• 20:31
  SPEAKER_04: But there are other ways where uh your testing can still reduce the amount of uncertainty that you have about how you're going to perform in the field without requiring that perfect one-to-one matchup with your test data and your production data.
• 20:44
  SPEAKER_04: And one of those things really is uh your model is perhaps part of a larger system.
• 20:50
  SPEAKER_04: Very likely there's something capturing data, something doing pre-processing on that.
• 20:55
  SPEAKER_04: That's then fed into the model.
• 20:56
  SPEAKER_04: And then there are probably some post-processing or business logic rules applied on top of what that model puts out.
• 21:02
  SPEAKER_04: And only then are those predictions finally surfaced to the user or used to make decisions down the line.
• 21:09
  SPEAKER_04: And testing that full pipeline from pre-processing through post-processing rather than just testing that model component, can often improve your visibility into how this thing is actually gonna work when you put it out there.
• 21:22
  SPEAKER_04: And uh, but probably the most effective thing that you can do is make sure that your metrics that you're using in the lab are actually meaningful to the domain that you're gonna be deploying in.
• 21:32
  SPEAKER_04: You know, for this, for this detection in security x-ray scans, uh, what we actually learned is there's a threshold at which when you have too many false positives without true positives, without your actually detecting things that are prohibited, then operators completely lose trust.
• 21:49
  SPEAKER_04: For for an assistant, for an assistance technology like that, you need to be very conscious of that ratio.
• 21:56
  SPEAKER_04: Otherwise, there's a threshold where your system becomes worse than useless.
• 21:59
  SPEAKER_04: It's just Nuisance.
• 22:00
  SPEAKER_04: And so that was a metric.
• 22:02
  SPEAKER_04: This true positive rate versus false positive rate was a key metric for us to follow to figure out okay, well, this model might have a better recall score or better F1 score.
• 22:12
  SPEAKER_04: But on this data set, you know, on this day of data collected from this airport security terminal, it actually produced a worse attention metric, for example, what might be something that you call this.
• 22:23
  SPEAKER_04: It produced a worse attention metric, which meant it falls positive too much about things that operators are going to get annoyed by and uh underperformed relatively in terms of detecting the actual examples as they occur.
• 22:35
  SPEAKER_04: So having your evaluation metrics align with the way that your system is actually going to be evaluated in the field is a key thing that you can do to kind of get a better understanding of is this model better for what I set out to do.
• 22:50
  SPEAKER_03: Is there any types of ML models and approaches, though, where this breaks down?
• 22:55
  SPEAKER_03: Because I'm thinking about this and I'm like, okay, this is where I can control the model and or I'm gonna be using, let's say, you know, an XGBoost or a PyTorch or something like that, you know, to test my stuff.
• 23:08
  SPEAKER_03: It's pretty straightforward, right, in terms of those approaches.
• 23:11
  SPEAKER_03: But what about like when we get into generative AI models and stuff and degenerative models?
• 23:17
  SPEAKER_03: What does that look like?
• 23:18
  SPEAKER_03: Neuronets are pretty straightforward because it's you know, data in, data out, but you know, these new generative models are so, you know, kind of off the wall in terms of what they're looking at and how they're, you know, they're actually bringing results that's back.
• 23:32
  SPEAKER_03: Do you see where testing is going to break down on some of those things, or is it more of, hey, keep the approach and keep on going because we still need to, you know, generate some kind of an output.
• 23:41
  SPEAKER_03: What are your thoughts there?
• 23:43
  SPEAKER_04: Yeah, I mean, that's a very good thing to flag, Chris.
• 23:45
  SPEAKER_04: It's if you have a good answer about how to properly test generative models, I'm all ears.
• 23:52
  SPEAKER_03: I don't.
• 23:52
  SPEAKER_03: I don't.
• 23:53
  SPEAKER_03: You're the you're the expert.
• 23:54
  SPEAKER_03: That's why I'm asking.
• 23:55
  SPEAKER_03: And you like I said, I know you're, you know, you say you're going out on a limb.
• 23:59
  SPEAKER_03: And I don't, you know, I wouldn't say that you're going out on a limb because this is your domain expertise now, right?
• 24:05
  SPEAKER_03: And we want, you know, and I I I love it because it's, I think it's so much an overlooked area, especially getting into now.
• 24:13
  SPEAKER_03: Shoot, we've got models now that are testing code to make sure that code is good, right?
• 24:18
  SPEAKER_03: And it's going out well.
• 24:20
  SPEAKER_03: And now we're putting these new concepts into pipelines and into DevOps and putting it and now asking, I don't know if it's the data science team, but these groups now to make sure that they're, you know, that they're actually deploying quality.
• 24:36
  SPEAKER_03: And but then that quality is semantic because it just depends on what we're, you know, what we're testing for and the outcomes and stuff.
• 24:42
  SPEAKER_03: But now we get into some of these other models, and how do you test for that kind of stuff when, you know, for instance, a generative model may be drawing a you know, a picture.
• 24:52
  SPEAKER_03: And so is that vision model that you're using even good enough, you know, for models of models, if you if that makes sense?
• 25:00
  SPEAKER_04: Yeah, it's it's a very good question.
• 25:02
  SPEAKER_04: I think the jury is still way out on that, on how exactly to do that.
• 25:06
  SPEAKER_04: One thing that uh we've seen work kind of effectively for a lot of teams is if you have certain behaviors from these generative models that you really don't want to get out there.
• 25:18
  SPEAKER_04: You know, if you have a generative model, we really don't want this to spew hate speech.
• 25:22
  SPEAKER_04: If we have a generative image model, we really don't want to produce not safe for work imagery.
• 25:27
  SPEAKER_04: You can use a model to test your other model.
• 25:30
  SPEAKER_04: And then of course your evaluation results are only as good as the model that's trying to uh detect the occurrence of hate speech or of uh NSFW imagery.
• 25:40
  SPEAKER_04: But at least that gives you a way to uh probe these generative models and say, okay, are there any inputs we can provide it uh for which it spits out inappropriate uh outputs?
• 25:50
  SPEAKER_04: And that's that's one way that we can at least put some guardrails on this process.
• 25:56
  SPEAKER_03: Yeah, that's that's kind of what I was just you know just thinking of as you were talking about it from the perspective of listen, we use a generative model to generate, but then we use other models to validate.
• 26:07
  SPEAKER_03: And that's where we get into the testing because one generative input be or output becomes our input for these other models to make sure that what we are creating andor testing for is, like you said, is safe and or is you know, the outcome that we're trying to drive.
• 26:24
  SPEAKER_04: So yeah, exactly.
• 26:26
  SPEAKER_04: And you can evaluate those uh classification models, the ones that are trying to say is this content safe or not, you can evaluate those on manually annotated, known, high-quality, large data sets and get a relatively good idea.
• 26:42
  SPEAKER_04: They're not going to be perfect in terms of the way they perform, but you can get a good idea of what their strengths and weaknesses are.
• 26:47
  SPEAKER_04: And as long as you always uh maintain that in the back of your head when you're looking at how this model was used to evaluate a generative model, then you can still get meaningful signal from that sort of evaluation.
• 27:06
  SPEAKER_01: And you touched on this already, but maybe we could explicitly talk through is um product testing versus model testing, right?
• 27:15
  SPEAKER_01: So model, and you started to talk about this, but why don't you go through your thinking around product testing versus model testing?
• 27:22
  SPEAKER_04: Yeah.
• 27:23
  SPEAKER_04: So the pre- and post-processing algorithms that you have uh running in production that are deciding what happens to the inputs before they get fed into your model and then deciding what should be done with those outputs from that model, that's one system.
• 27:38
  SPEAKER_04: Uh, but often what we see in in production is actually you have pipelines of models where you have one model that's producing predictions that are getting fed into another model that's acting on those predictions, and then that's feeding it down and down the chain.
• 27:52
  SPEAKER_04: And your overall product is not any of those individual models.
• 27:56
  SPEAKER_04: Your overall product is that whole pipeline.
• 27:58
  SPEAKER_04: And a good example of this that we saw at Kalena is we were evaluating a pedestrian detection system.
• 28:06
  SPEAKER_04: Uh, this would be something that you would be running on the edge on uh vehicles, not just autonomous vehicles, but all sorts of vehicles these days have collision avoidance systems where uh if they think you're getting too close to a pedestrian who's about across the street, they'll alert you.
• 28:22
  SPEAKER_04: And these are these are running on almost every new car that you can buy these days.
• 28:25
  SPEAKER_04: And uh the way that the system was set up, the one that we were evaluating, you had a uh per frame object detector that was looking for people uh in each of these frames.
• 28:36
  SPEAKER_04: You fed those per frame detections into a tracking model, which was trying to resolve uh detections across frames and say this detection and this detection and this detection through time are all really the same person.
• 28:49
  SPEAKER_04: And then you're feeding those tracks into an action classification model that's trying to decide is this person crossing or about to cross?
• 28:56
  SPEAKER_04: And this is useful so that you can alert the driver or avoid these collisions.
• 29:01
  SPEAKER_04: And it's particularly useful for pedestrians who are an imminent collision risk, you know, pedestrians who are close to your vehicle.
• 29:07
  SPEAKER_04: And what we saw when we were evaluating this was that uh we could improve the first model in that pipeline.
• 29:14
  SPEAKER_04: We could improve the object detector that's detecting the people in each individual frame.
• 29:20
  SPEAKER_04: And uh if we evaluate that on a large data set, then the better model, when plugged into the actual pipeline, might actually yield worse performance at the end goal.
• 29:30
  SPEAKER_04: And that's a particularly uh, you know, that's something that you're always going to be subject to when you're evaluating your models in isolation rather than your whole product as a pipeline, is do improvements in one scenario, does a better person detector actually yield a better uh crossing pedestrian uh predictor, you know, that whole pipeline?
• 29:51
  SPEAKER_04: Does it improve it?
• 29:52
  SPEAKER_04: And in many cases, we were seeing no, you know, we could improve the object detector and be better at detecting people far off or people on the edges of the frames.
• 30:00
  SPEAKER_04: But when it came to detecting the people who mattered, people who were crossing or about to cross or who were close to your vehicle, uh, the the worst model, you know, when we were doing this evaluation, the worst model actually produced much better results uh when fed into the tracking model and the downstream action classifier.
• 30:18
  SPEAKER_04: And so this is why it's always important to keep that product level uh visibility.
• 30:22
  SPEAKER_01: So that's interesting.
• 30:23
  SPEAKER_01: So you had two models.
• 30:25
  SPEAKER_01: One was performing by itself more effectively, it was detecting those pedestrians.
• 30:31
  SPEAKER_01: But then when that was combined with the other model, which was predicting the collision or the tracking, it didn't perform.
• 30:39
  SPEAKER_01: It performed worse than the model that was not performing as well uh at the pedestrian track.
• 30:46
  SPEAKER_01: That's very, very counterintuitive, right?
• 30:48
  SPEAKER_01: You're saying that here's a model that's performing poorly, but but it's actually more effective when it's combined with these other models into that end-to-end uh product and the results that you're looking at.
• 31:02
  SPEAKER_01: So that's again, so when you start thinking about that, what what does that mean in terms of how test cases should be defined, curated, and executed?
• 31:13
  SPEAKER_01: You know, how do uh organization how should organization look at that?
• 31:16
  SPEAKER_01: I mean, you know, yeah.
• 31:20
  SPEAKER_04: If at all possible to test your end-to-end product, you should have at least some tests that are running that whole system.
• 31:28
  SPEAKER_04: Um it's usually much easier and more feasible to test these models in isolation.
• 31:34
  SPEAKER_04: And maybe the bulk of your testing should be done in isolation, such that you're uh the the team that's working on improving the detection algorithm in the pipeline can operate independently of the team that's working on improving the action classification model.
• 31:46
  SPEAKER_04: They should have their own robust individual benchmarks uh specific to that component of the pipeline, but you need to have your whole product modeled as something that you can test.
• 31:58
  SPEAKER_04: And you need to have a wide array of test data that you push through that pipeline in order to say, okay, you know, I'm not just improving these individual components at the cost of an overall uh worse product.
• 32:11
  SPEAKER_04: And one of the things that that you can do when you set up this full end-to-end testing is rather than just looking at these metrics, like what's your what's your accuracy for pedestrians who are crossing?
• 32:22
  SPEAKER_04: You know, how how well did you predict whether a pedestrian is going to cross or not?
• 32:26
  SPEAKER_04: Rather than looking at things like that, you know, look at of the pedestrians who actually matter, of the ones who you are very likely to uh hit if you don't take preventative action, the ones who are close to your vehicle or the ones who are crossing into your lane.
• 32:40
  SPEAKER_04: Uh, how does this new pipeline perform on that subset of all pedestrians?
• 32:44
  SPEAKER_04: You know, how does this impact your overall collision risk?
• 32:47
  SPEAKER_04: Because the relationship between meaningful pedestrians, the ones that you have a collision risk with, and all pedestrians in the frame, uh, you know, that might not be linear.
• 32:56
  SPEAKER_04: If you perform better on all pedestrians, you might not perform better on the ones that matter.
• 32:59
  SPEAKER_04: And that's what you need to keep your eye on when you're testing end-to-end.
• 33:03
  SPEAKER_01: Just to remind people we're a little more than halfway through, we're speaking with Gordon Part, uh, who is co-founder and head of product at Kalena, which is a machine learning testing platform that allows machine learning uh teams to test models and uh provide those uh those mechanisms.
• 33:21
  SPEAKER_01: Um so when you think about what are the recommendations for how an organization should look at that, you know, when should they care?
• 33:29
  SPEAKER_01: You know, what what are the things, what are the characteristics of the applications of products that require greater depth of testing?
• 33:35
  SPEAKER_04: So how should this be incorporated and considered in uh in in DevOps and machine learning ops and and uh I'll say uh if you're an organization that's trying to make an ML product, I really feel that you should think critically about your tests up front prior to kicking off this project.
• 34:01
  SPEAKER_04: Think about what are the actual behaviors that we need in order for this to be a success.
• 34:06
  SPEAKER_04: I've seen too many POCs fail because there wasn't a clear thesis about what behaviors they need to have and what behaviors they don't need to have in order to prove out that concept and turn that into a real product.
• 34:19
  SPEAKER_04: And uh so try to think about that up front and try to have the people who are planning and devising this product, this thing that you'll be doing, try to have them think critically about okay, if I'm doing a person detector, a person is not a person, is not a person in an image.
• 34:34
  SPEAKER_04: There are many different ways that you can that people can present.
• 34:38
  SPEAKER_04: You can have uh vastly different resolutions of cameras.
• 34:41
  SPEAKER_04: You can have people who are very close, people who are very far away.
• 34:45
  SPEAKER_04: You can have people from all different sorts of orientations, you know, if you're looking top-down on a person or face forward, and you should understand up front at least which of these scenarios are important.
• 34:56
  SPEAKER_04: And you should model those in tests such that you have a unit test, you know, a well-scoped subset of your test benchmark, targeting each of these specific scenarios that you need to care about.
• 35:09
  SPEAKER_04: And uh, this to people who are familiar with uh test-driven development in software engineering, this might sound pretty uh pretty familiar.
• 35:18
  SPEAKER_04: And that that can be a bit of a contentious framework for software development, but I think it's much more necessary for machine learning where the systems are a lot less hard to control.
• 35:28
  SPEAKER_03: Good.
• 35:28
  SPEAKER_03: Do you feel like there's a uh, you know, because I I love and I don't love the whole concepts around explainable AI, right?
• 35:37
  SPEAKER_03: Because it's more along the lines of, hey, well, here's how it works and here's what we're driving and stuff.
• 35:41
  SPEAKER_03: But I'd love to get your thoughts because I believe that this, you know, is absolutely a catalyst for saying this is the most explainable way to, you know, to get explainable AI, but this is the most explainability that you can even have.
• 35:58
  SPEAKER_03: Here's my testing framework.
• 36:00
  SPEAKER_03: Uh, what are your thoughts there?
• 36:01
  SPEAKER_03: And how does that, you know, how does this type of approach actually influence you know that notion?
• 36:07
  SPEAKER_04: Yeah.
• 36:08
  SPEAKER_04: Yeah.
• 36:08
  SPEAKER_04: So having all of the different behaviors that you want your model to have laid out in test cases and evaluating models against these test cases that say, I succeed in this scenario, I succeed in this scenario, I don't succeed in this scenario.
• 36:23
  SPEAKER_04: That test case-based evaluation behavioral report card, uh, it doesn't tell you the why, but it does tell you the one, you know, it give that is the best starting point, I think, towards explainable AI is rather than just having that top-level metric, understand your model's behaviors at the actual behavioral level, at the subclass level or the scenario level, and figure out not only does this model succeed in 90% of all circumstances that we drew at it, but what are the circumstances where it does succeed and what are the circumstances where it doesn't?
• 36:56
  SPEAKER_04: That is a perfect start towards explainable AI.
• 37:00
  SPEAKER_04: And there's a lot further than that you can go from there rather than just stopping at the what.
• 37:06
  SPEAKER_04: Um, if you have a proper automated testing system, there are lots of fun techniques that you can use to inspect that actual why.
• 37:15
  SPEAKER_04: You know, for example, in in computer vision, uh, you can render a thing called saliency maps that basically visualize which pixels in the input to my model uh most contributed to my output prediction.
• 37:28
  SPEAKER_04: And you can render this uh for a given image, and you can see, ah, okay, for this prediction, I was my model was looking primarily at this region of the image.
• 37:37
  SPEAKER_04: You know, because of this prediction, because the model predicted a, let's say, a cat, and it was looking mostly at the cat ears, and it was using the ears to decide that something was a cat.
• 37:47
  SPEAKER_04: And this is actually something that we used really successfully at Synapse, I would say.
• 37:51
  SPEAKER_04: Uh, we rendered these saliency maps for uh all sorts of different predictions, and we learned from that that, for example, our gun detectors were looking very heavily, we're relying very heavily on the presence of the trigger.
• 38:07
  SPEAKER_04: The specific shape and size of the trigger of a gun was one of the features that our models were really leaning on to identify whether or not a gun was present.
• 38:16
  SPEAKER_04: And so we went and collected a bunch of data where we either removed the trigger assembly or occluded it uh either with a big hunk of metal or by taking out that part, blacking out that part of the image uh after the fact.
• 38:30
  SPEAKER_04: And sure enough, our models really underperformed in this scenario once we were removing those salient features.
• 38:36
  SPEAKER_04: But when we fed those back into training, we were able to uh have models that were more robust to that particular case without sacrificing behavior elsewhere.
• 38:44
  SPEAKER_04: And this kind of saliency mapping can tell you the why and can help you make better models and make those more uh informed decisions about what should we do to really improve robustness.
• 38:57
  SPEAKER_03: I can't I can't think of a better way to go back to your original, you know, your other thought centered around why testing is better than training.
• 39:05
  SPEAKER_03: Because this to me, you know, like you're saying, as soon as you put it in the wild, you know, you may get vastly different results.
• 39:12
  SPEAKER_03: But if it's being tested for that, then it's the best safety net for what production usage might look like, right?
• 39:19
  SPEAKER_03: Otherwise, who the hell knows what's gonna happen, right?
• 39:22
  SPEAKER_03: Could it come out completely, completely different than what you thought.
• 39:26
  SPEAKER_01: And I really like the idea, and that makes a lot of sense, Chris.
• 39:30
  SPEAKER_01: Uh, and I really like the idea of the salem syndap because that is uh contributing to explainability and it's also contributing to scenarios and testing uh conditions.
• 39:41
  SPEAKER_01: So um are there other techniques?
• 39:43
  SPEAKER_01: So that sounds like it's a technique that um can be applied to some automated approaches.
• 39:48
  SPEAKER_01: What other are there other techniques that that you can talk about that uh your company uses that an organization can use that uh uh help to reduce the costs and reduce the time and uh uh and effort?
• 40:02
  SPEAKER_04: Yeah, so I think really the biggest uh cost and time reduction comes from having your engineers who are the experts in this and have all these techniques in their tool belt, having those, having them build those into your standard testing process, such that when you have a new model and you start your testing script or you kick off that data pipeline flow to go and test this new model, you're not only computing those top-level metrics, but you're storing all the outputs from your models in a way that's easy to visualize.
• 40:34
  SPEAKER_04: You're pre-running this saliency map extraction and uploading those to a place where you can easily visualize those.
• 40:41
  SPEAKER_04: You're lowering the barrier for any of these sorts of debugging flows to if you have a question about, hmm, I wonder what the salient parts of this image were, you can go and immediately visualize that rather than it being like, okay, over the course of the past couple of weeks, I've built up enough of a desire to render these saliency maps that I'll now go set aside an afternoon or longer to go and kick off this manual investigation.
• 41:04
  SPEAKER_04: And so automating that process and making sure that you write all of this code once and then takes, you know, you run it in a script and it takes a half hour, an hour, or something like that, and you have all of those different pieces available in a way that are very easily explorable.
• 41:19
  SPEAKER_04: That's the easiest way for you to uh really improve your results.
• 41:23
  SPEAKER_04: And and Chris, on your point about you know, testing data being so much more important than training data here, uh coming back to that.
• 41:30
  SPEAKER_04: Another thing that we saw with these salancy maps is uh this kind of explainability was showing us things that we never would have known if we hadn't done these sorts of investigations.
• 41:41
  SPEAKER_04: For example, we had a uh a database, a library, really a filing cabinet of thousands of different knives, all different sorts of shapes, sizes, uh, form factors.
• 41:53
  SPEAKER_04: Uh if you need encyclopedic knowledge of the prohibited items list for various airports across the world and uh courthouses and cruise ship lines and all that, uh, you can ask me.
• 42:04
  SPEAKER_04: I'll be able to regurgitate those at will.
• 42:06
  SPEAKER_04: But we had thousands of these threats.
• 42:09
  SPEAKER_04: And uh we thought we were doing a really good job of covering it.
• 42:12
  SPEAKER_04: You know, we we thought we had pretty good coverage, and then we started doing the salency mapping and we started seeing for fixed blade knives, uh, cheap knives typically have what's called a partial tang, which is the blade of the knife only extending part way back down into the handle.
• 42:28
  SPEAKER_04: And this is cheap, you have less metal.
• 42:30
  SPEAKER_04: And what we were seeing is that our models were relying heavily on that partial tang to predict a fixed blade knife.
• 42:37
  SPEAKER_04: And so when we saw full tang knives that have the blade, you know, that piece of metal extend all the way through the handle, the hilt of the knife, we were really, really underperforming.
• 42:47
  SPEAKER_04: And we only saw this in the field because even though we had what looked to us to be a lot of diversity in our uh testing data, it was all cheap.
• 42:55
  SPEAKER_04: It was all cheap knives sourced from overseas, and none of it had you know the full tang, which cost extra money.
• 43:01
  SPEAKER_04: And if we had had that in our testing data, then we would have been able to identify that shortcoming a lot earlier than we did.
• 43:08
  SPEAKER_01: That's awesome.
• 43:09
  SPEAKER_01: It's awesome.
• 43:11
  SPEAKER_01: So you know, when you start thinking about setting up these programs, you know, it's defining the use cases, it's defining the outcomes, it's looking at uh uh product level uh metrics, it's looking at granular uh metrics, even within an algorithm to say, you know, what are the how is it performing under certain scenarios?
• 43:32
  SPEAKER_01: What are the steps?
• 43:33
  SPEAKER_01: What are the initial steps to um setting up a comprehensive testing program?
• 43:38
  SPEAKER_01: I mean, it sounds like there's a significant amount of work that needs to be put into this.
• 43:43
  SPEAKER_01: So what's the framework for setting that up?
• 43:47
  SPEAKER_02: I would say you know, and on and on piggybacking on on uh that question, what can you automate?
• 43:54
  SPEAKER_03: Because that's gonna be a you know a huge times times the value saver.
• 43:57
  SPEAKER_03: So anyway, what can you automate?
• 43:59
  SPEAKER_03: So sorry, go ahead.
• 44:00
  SPEAKER_03: Gordon.
• 44:00
  SPEAKER_04: Yeah.
• 44:01
  SPEAKER_04: So I'll I'll start by saying most domains have some metadata that is meaningful for them, some metadata that they already have associated with all their images that they can use to render these test cases that tell you how your behavior breaks down in these specific scenarios.
• 44:20
  SPEAKER_04: And a good example of this is for a robotics company or something like that.
• 44:23
  SPEAKER_04: You'll have data collected from a lot of different locations.
• 44:27
  SPEAKER_04: And those deployment locations are going to be very meaningful for stratifying your model performance.
• 44:34
  SPEAKER_04: And that's a good way for you to kind of bootstrap a good set of test cases that you can then build over time.
• 44:40
  SPEAKER_04: For an autonomous vehicle company, you know when you collected your data, you know what time of day, you know where it was.
• 44:47
  SPEAKER_04: And it's very, very easy for you to manually annotate with how the weather was outside and the time of day and weather stratification breaking down your performance.
• 44:58
  SPEAKER_04: How do I perform in the morning?
• 45:00
  SPEAKER_04: How do I perform when in high glare scenarios?
• 45:02
  SPEAKER_04: How do I perform at nighttime?
• 45:04
  SPEAKER_04: How do I perform when it's raining or snowing outside?
• 45:07
  SPEAKER_04: You can almost certainly immediately generate these test cases with metadata that you already have and use that to bootstrap this fine-grained testing approach.
• 45:16
  SPEAKER_04: Once you have the framework in place for creating and evaluating your models on this test case level, then you'll be identifying new uh bugs, new failure modes from your model in the field.
• 45:28
  SPEAKER_04: And then you start this process that we call regression testing, where if you notice a lapse in behavior, you notice a bug from your model in the field, you create a test case with a couple hundred or thousand images maybe that verify that yes, this bug exists.
• 45:43
  SPEAKER_04: And in the gun in an empty bin scenario, that regression test would be maybe 500 examples of guns empty in a bin.
• 45:51
  SPEAKER_04: And once you have that test case, you add that to a regression test suite where now, whenever you're developing any new models, you're always testing them on the full set of these regression tests that you put together through time.
• 46:05
  SPEAKER_04: And you're getting that assurance that yes, this bug that I squashed last quarter, you know, this uh lacking the underperformance in the gun and empty bin scenario that I fixed last quarter, we are still performing well in there.
• 46:19
  SPEAKER_04: And if any regressions sneak in, you have these regression tests that are uh laying out all of the different bugs that you've spent time to fix over the past however long you've been working on your models.
• 46:30
  SPEAKER_04: And you carry, you build that moving forward, and that really gives you the peace of mind that you can change your focus.
• 46:37
  SPEAKER_04: You can focus really heads down on one area and improve in that area, and then keep that regression test, change your focus elsewhere and really get your head down there, but uh still have that peace of mind that your improvements in this one area off to the side are not going to wipe out all of the improvements that you fought so hard for in this other part.
• 46:57
  SPEAKER_01: That's great.
• 46:58
  SPEAKER_01: Here's some really valuable uh insights.
• 47:01
  SPEAKER_01: And um, I just want to remind people that uh you are at uh colina k o lot io.
• 47:10
  SPEAKER_01: Uh that's your website, and uh it's colina k o K-O-L-E-N-A-T-I-O, just one word on Twitter, and then of course there's a uh LinkedIn profile.
• 47:23
  SPEAKER_01: But um you know, Gordon, this has been terrific.
• 47:26
  SPEAKER_01: Um any final thoughts or Gordon, any final thoughts?
• 47:32
  SPEAKER_01: What do you think?
• 47:33
  SPEAKER_01: To tie tie it all up.
• 47:35
  SPEAKER_04: Yeah, I would I would uh like to say that I think model testing and there's ensuring that you get the performance that you need out of your models is something that a ton of people within an organization uh, from the engineers who are developing the models, their technical managers, the product managers associated with that team, the business leaders who are representing the business or the product, the sales or business development team who's interfacing with customers, the customers themselves, everybody along that chain is invested in model performance.
• 48:08
  SPEAKER_04: You know, they don't have the visibility necessarily, and they don't have uh the understanding of exactly how these models are performing necessarily.
• 48:16
  SPEAKER_04: But improving the visibility of this process for all of those different stakeholders uh is always worth the effort for an organization.
• 48:24
  SPEAKER_04: Uh, once you've gotten out of that initial proof of concept phase and are really trying to solve a real world problem.
• 48:29
  SPEAKER_03: I really appreciate you coming on and talking about this topic because for the longest time it's felt like such a Wild West area, which I love, you know, in the fact that there's now there's people that will, you know, innovation is one of those things that is so broad.
• 48:45
  SPEAKER_03: And so now when we start to see this as a huge gap, testing and you know, it's part of this maturity curve that we're in now, right?
• 48:54
  SPEAKER_03: Where, you know, no longer is it okay to not have these kind of mechanisms in place because, you know, it's the mysticism of new and innovative technology.
• 49:04
  SPEAKER_03: Well, bullshit, right?
• 49:05
  SPEAKER_03: Because now we, you know, we're in these areas where it's so pervasive, it's just now a new part of organizations to have a data science team.
• 49:15
  SPEAKER_03: It's just, it's just a it's a it's a fact now.
• 49:17
  SPEAKER_03: And so we've got the development, the SDETs, the you know, core engineers and the data science team is now part of this.
• 49:25
  SPEAKER_03: And I think it's it's so phenomenal to see the kind of work that you're putting together where you know it's it's no longer the exception, it's the rule, right?
• 49:35
  SPEAKER_03: And so my hat's off to you, man.
• 49:37
  SPEAKER_03: And and you know, just I hope, you know, continued success.
• 49:41
  SPEAKER_03: And is there anything that we should be looking from you personally and or from the company coming this year?
• 49:49
  SPEAKER_04: Uh I think stay tuned.
• 49:50
  SPEAKER_04: Take a take a look at our LinkedIn presence and uh website presence, and there should be some exciting news coming out about Kalena in the next couple of months.
• 49:58
  SPEAKER_01: Wonderful.
• 49:59
  SPEAKER_01: Awesome.
• 50:00
  SPEAKER_01: Thank you again for uh for your time today.
• 50:02
  SPEAKER_01: It's been a pleasure.
• 50:03
  SPEAKER_01: Uh, thank you again, uh Chris, for your help.
• 50:06
  SPEAKER_01: Thanks, guys.
• 50:07
  SPEAKER_01: Thanks.
• 50:09
  SPEAKER_03: Have a great day.
• 50:10
  SPEAKER_03: Thanks, Gordon.
• 50:14
  SPEAKER_00: Thanks for listening to the Early AI Podcast with your hosts Seth Early and Chris Featherstone.
• 50:20
  SPEAKER_00: We hope you enjoyed the program and took away some ideas that you can start to implement in your organization right now.
• 50:27
  SPEAKER_00: If you're stuck and need help, check out www.early.com for information about Early Information Science Consulting Services.
• 50:35
  SPEAKER_00: And of course, check the show notes for links to any resources we mentioned today.
• 50:39
  SPEAKER_00: That's all for now.
• 50:40
  SPEAKER_00: See you next time.