Breaking Down Data Silos: AI and ML in Master Data Management

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 01/03/2025 01:35:50
Duration: 3449.776
Channels: 1
1
00:00:11.280 --> 00:00:15.380
Hello, and welcome to the Data Engineering podcast, the show about modern data management.
2
00:00:16.075 --> 00:00:16.815
It's 2024.
3
00:00:17.515 --> 00:00:20.015
Why are we still doing data migrations by hand?
4
00:00:20.395 --> 00:00:27.215
Teams spend months, sometimes years, manually converting queries and validating data, burning resources and crushing morale.
5
00:00:27.915 --> 00:00:40.769
DataFold's AI powered migration agent brings migrations into the modern era. Their unique combination of AI code translation and automated data validation has helped companies complete migrations up to 10 times faster than manual approaches.
6
00:00:41.710 --> 00:00:46.050
And they're so confident in their solution, they'll actually guarantee your timeline in writing.
7
00:00:46.625 --> 00:00:50.885
Ready to turn your year long migration into weeks? Visit data engineering podcast.com/datafold
8
00:00:52.385 --> 00:01:07.870
today to learn how DataFold can automate your migration and ensure source to target parity. Your host is Tobias Macey, and today, I'm interviewing Dan Bruckner about the application of ML and AI techniques to the challenge of reconciling data at the scale of business. So, Dan, can you start by introducing yourself?
9
00:01:08.890 --> 00:01:12.990
Yeah. Thanks, Tobias. It's a pleasure to be here. I'm Dan Bruckner. I'm a
10
00:01:13.290 --> 00:01:15.310
a cofounder and CTO at Tamer.
11
00:01:15.610 --> 00:01:16.270
I've been
12
00:01:16.784 --> 00:01:19.205
solving problems in this space for,
13
00:01:19.585 --> 00:01:21.685
I don't know, going on 15 years now.
14
00:01:22.064 --> 00:01:25.765
And, we we build solutions for master data management
15
00:01:26.225 --> 00:01:28.085
using AI and machine learning
16
00:01:28.465 --> 00:01:29.284
to simplify
17
00:01:30.145 --> 00:01:32.165
and, make MDM projects
18
00:01:32.630 --> 00:01:33.130
successful.
19
00:01:33.829 --> 00:01:36.490
And do you remember how you first got started working in data?
20
00:01:37.270 --> 00:01:37.770
Yeah.
21
00:01:38.070 --> 00:01:41.530
It go it goes way back. So I actually started out as a physicist.
22
00:01:42.470 --> 00:01:43.610
And my first,
23
00:01:44.149 --> 00:01:47.450
my first job out of college was working at CERN on the LHC,
24
00:01:48.854 --> 00:01:49.755
and it was
25
00:01:50.215 --> 00:01:56.634
in the days before the LHC had actually started. I was getting going. And so most of what I did was actually write code,
26
00:01:56.935 --> 00:01:58.475
solve computational problems.
27
00:01:58.854 --> 00:02:01.194
In those days, we were doing analysis over
28
00:02:01.575 --> 00:02:08.790
large volumes of simulated data and trying to model the system and and get a handle on our expectations for what was gonna happen.
29
00:02:09.170 --> 00:02:15.110
So I did that. And as I was doing it and the system wasn't running, I kinda got more interested in the computational problems
30
00:02:15.410 --> 00:02:18.070
that I was working on and and the code that I was writing.
31
00:02:18.465 --> 00:02:20.245
And so when I got back to the states,
32
00:02:21.025 --> 00:02:24.085
I decided to pivot and move into computer science,
33
00:02:24.465 --> 00:02:25.365
started programming,
34
00:02:26.225 --> 00:02:27.125
and then
35
00:02:27.585 --> 00:02:29.845
got interested in in computer science research.
36
00:02:30.385 --> 00:02:33.365
Because of my background, I kinda naturally gravitated into
37
00:02:33.980 --> 00:02:37.040
data and large scale data processing, database systems,
38
00:02:37.660 --> 00:02:38.140
and,
39
00:02:38.460 --> 00:02:41.120
eventually started working with Mike Stonebraker at MIT
40
00:02:41.820 --> 00:02:42.320
on
41
00:02:42.940 --> 00:02:44.080
research into
42
00:02:44.620 --> 00:02:46.080
large scale data integration
43
00:02:47.194 --> 00:02:48.095
approached holistically
44
00:02:49.194 --> 00:02:54.575
and approached using machine learning techniques and applying those techniques in in ways that scale to,
45
00:02:55.194 --> 00:02:57.055
extremely large volumes of data.
46
00:02:58.474 --> 00:03:00.920
And before we get too much into
47
00:03:01.299 --> 00:03:03.879
the application of ML techniques
48
00:03:04.180 --> 00:03:19.535
to that challenge of processing data, reconciling it, getting it into a usable state, I'm wondering if you can just start by giving a bit of an overview of some of the different ways that data at the organizational scale becomes unwieldy
49
00:03:20.315 --> 00:03:23.775
and some of the challenges that arise from that lack of reconciliation?
50
00:03:25.675 --> 00:03:30.895
Yeah. It's a class of problem that I think is is very common and taken for granted
51
00:03:31.480 --> 00:03:32.300
and also
52
00:03:33.080 --> 00:03:35.100
not necessarily deeply understood.
53
00:03:35.800 --> 00:03:39.740
I like to start from an analogy to software engineering
54
00:03:40.200 --> 00:03:43.260
and Conway's Law. Are you familiar with Conway's Law?
55
00:03:43.585 --> 00:03:49.045
I am. That the software design will eventually reflect the organizational
56
00:03:49.345 --> 00:03:51.685
communication patterns for better or worse.
57
00:03:52.305 --> 00:03:55.605
That's, yeah, that's exactly right. So the structure of your organization
58
00:03:56.580 --> 00:03:59.160
dictates the structure of your of your software architecture.
59
00:03:59.780 --> 00:04:03.959
And the same is true to a large extent in data and data management.
60
00:04:04.420 --> 00:04:06.680
The structure of data within a large organization
61
00:04:07.379 --> 00:04:09.480
is naturally going to reflect
62
00:04:09.845 --> 00:04:14.105
the structure of the teams and the groups and the divisions that created that data.
63
00:04:14.405 --> 00:04:14.905
And
64
00:04:15.765 --> 00:04:28.100
that can be a very good thing. It means individual teams can kind of operate naturally and independently and use the data that they need to be successful and to do do what needs doing. But it also creates
65
00:04:28.639 --> 00:04:30.180
big challenges and and
66
00:04:30.720 --> 00:04:31.540
missed opportunities
67
00:04:32.320 --> 00:04:35.940
when you start to move up a level and wanna reason about and change
68
00:04:36.385 --> 00:04:38.885
and ask questions of the the kinda data,
69
00:04:39.665 --> 00:04:41.525
the the data across the whole organization.
70
00:04:42.305 --> 00:04:44.965
Different teams are speaking fundamentally different languages.
71
00:04:45.505 --> 00:04:48.085
They often have redundant, duplicated data,
72
00:04:48.729 --> 00:04:55.389
And it can be very hard to actually use that data to communicate and to make kinda high level decisions within the org.
73
00:04:55.770 --> 00:04:57.629
From a very kinda nuts and bolts
74
00:04:58.250 --> 00:04:58.750
perspective,
75
00:04:59.210 --> 00:05:01.949
what kinds of issues are are are we talking about?
76
00:05:02.655 --> 00:05:09.955
I I as as basically a database guy, I kinda go back to the kinds of problems we're interested in are fuzzy unions
77
00:05:10.415 --> 00:05:12.835
putting together schemas across different databases,
78
00:05:13.375 --> 00:05:15.555
fuzzy joins, and fuzzy group buys.
79
00:05:15.980 --> 00:05:17.760
So, essentially, cases where
80
00:05:18.460 --> 00:05:19.760
you would like to treat
81
00:05:20.220 --> 00:05:23.760
large, sets of data as a coherent whole single database,
82
00:05:24.540 --> 00:05:28.000
but you don't have the keys. You don't have the the common attributes.
83
00:05:28.414 --> 00:05:29.955
You don't have the common identifiers,
84
00:05:30.255 --> 00:05:34.755
and so you're not actually able to just directly go and ask the questions you wanna ask.
85
00:05:35.134 --> 00:05:36.675
First, you have this problem of
86
00:05:37.134 --> 00:05:40.354
just, you know, mechanically getting all the data together,
87
00:05:41.160 --> 00:05:43.660
linking it up, getting a coherent picture
88
00:05:43.960 --> 00:05:47.020
that you can go and query and and use use for
89
00:05:47.480 --> 00:05:48.700
applications, analytics,
90
00:05:49.160 --> 00:05:51.100
what whatever it is you're trying to accomplish.
91
00:05:52.760 --> 00:05:53.260
And
92
00:05:54.205 --> 00:05:59.425
given the reflection of Conway's Law in that data ecosystem
93
00:05:59.805 --> 00:06:02.705
for the business, what are some of the attributes
94
00:06:03.085 --> 00:06:05.345
of either scale or
95
00:06:06.180 --> 00:06:14.120
team dynamics that you see being the biggest contributors to that messiness and that lack of cohesion that brings out these problems?
96
00:06:15.380 --> 00:06:16.280
Yeah. So
97
00:06:16.660 --> 00:06:21.400
there I mean, depending on the scale of the organization, there could there can be many. But, frequently,
98
00:06:21.995 --> 00:06:27.135
the kind of most common case is datasets come from applications. They come from processes,
99
00:06:28.075 --> 00:06:38.000
I guess, processes whether they're software based or not that are well established, that are designed not primarily to create data, but to solve some some problem for the business. So
100
00:06:38.699 --> 00:06:44.240
sales, marketing, you know, these kind of basic basic things that that companies do.
101
00:06:44.780 --> 00:06:47.280
As a side effect, they produce these piles of data.
102
00:06:47.915 --> 00:06:57.775
And then the the teams that that work with those processes and applications, they're very vested in kind of the way that things work. If you have other teams come in, data teams most frequently,
103
00:06:58.075 --> 00:07:16.569
to do analytics to look across different groups, different parts of the org, there's kind of a natural conflict that arises in terms of, well, we would like it all to look this way. We think it this would solve the problem for the whole organization better. And teams say, no. Like, we that's not how we operate. We can't do that. You can't just come in and change our process, change our data.
104
00:07:16.925 --> 00:07:19.185
You know, we've been doing this for for forever
105
00:07:19.885 --> 00:07:22.145
in in this way. The problem gets worse
106
00:07:22.525 --> 00:07:24.785
the larger the organization gets and especially
107
00:07:25.405 --> 00:07:25.905
for
108
00:07:26.285 --> 00:07:29.025
companies that grow through acquisition mergers.
109
00:07:29.580 --> 00:07:34.560
You start bringing in, you know, data that's arisen not just from different teams, but completely different organizations,
110
00:07:35.100 --> 00:07:37.199
start trying to put it together, consolidate.
111
00:07:37.500 --> 00:07:40.080
And those kinds of those kinds of small inconsistencies
112
00:07:41.340 --> 00:07:45.965
can can really start to undermine the process of of finding a good way to operate
113
00:07:46.265 --> 00:07:48.045
and put all the data together coherently.
114
00:07:48.905 --> 00:07:58.365
And so that process of reconciling data, bringing it together in a way that makes organizational sense so that you can start to ask those questions
115
00:07:58.745 --> 00:08:02.770
across the business is largely called master data management
116
00:08:03.070 --> 00:08:05.010
or building golden records.
117
00:08:05.710 --> 00:08:11.570
And I'm wondering if you can talk to some of the typical approaches that teams and organizations
118
00:08:12.270 --> 00:08:13.169
try to
119
00:08:13.634 --> 00:08:31.030
take to be able to actually embark upon that process of building those master records and reconciling that data and some of the scaling challenges that they run into, whether that's in terms of scaling at the compute level or scaling just in terms of time, effort, and human capacity?
120
00:08:31.730 --> 00:08:33.750
Yeah. That's a good question. That's a big question.
121
00:08:34.210 --> 00:08:43.695
And so breaking that down a bit, master data management really does cover kind of the heart of of this problem of linking linking different datasets together.
122
00:08:44.315 --> 00:08:46.335
There are a number of stages
123
00:08:46.955 --> 00:08:47.455
in
124
00:08:47.915 --> 00:08:51.615
a successful master data management, like, you kinda have to move through.
125
00:08:51.959 --> 00:08:58.300
One one stage even starts just ahead of getting into master data, which is just physically getting the data together
126
00:08:59.079 --> 00:09:04.699
up and and, you know, treating the data quality problem, essentially getting a common level of quality,
127
00:09:05.079 --> 00:09:07.339
often pulling in third party source data,
128
00:09:07.725 --> 00:09:12.144
reference data to to enrich it and and kinda get your base to a good spot.
129
00:09:12.765 --> 00:09:15.584
Then, okay, you have you have a set of sources,
130
00:09:16.285 --> 00:09:17.745
different data tables,
131
00:09:18.125 --> 00:09:21.505
database systems. You put them in one physical place,
132
00:09:22.200 --> 00:09:28.220
and now you you wanna link them together. You you wanna kinda create the the point of reference across common records
133
00:09:28.840 --> 00:09:33.820
and and just solve solve that that linkage problem, the the entity resolution problem.
134
00:09:34.440 --> 00:09:35.660
Once you've done that,
135
00:09:36.275 --> 00:09:38.055
great. Now we have a common identifier
136
00:09:38.435 --> 00:09:39.495
that we can use.
137
00:09:40.035 --> 00:09:40.695
You're gonna
138
00:09:41.395 --> 00:09:43.735
now draw in all the data from these systems
139
00:09:44.195 --> 00:09:47.175
and attempt to consolidate it, produce golden records.
140
00:09:47.555 --> 00:09:51.095
So now you have you have an identifier that links source data.
141
00:09:51.480 --> 00:10:01.899
And for each identifier, you have a a kinda a golden record, like, this is the best this is the truth about this customer or this supplier or this part in our in our in our organization.
142
00:10:02.440 --> 00:10:06.300
So you produce that record. And and now you you wanna start to manage that over time.
143
00:10:06.925 --> 00:10:07.985
As you go farther,
144
00:10:08.445 --> 00:10:11.665
you're now gonna want to push out more of that
145
00:10:12.045 --> 00:10:15.905
to the systems the source systems themselves and to downstream applications,
146
00:10:16.605 --> 00:10:17.585
analytic engines.
147
00:10:17.965 --> 00:10:18.705
So, essentially,
148
00:10:19.380 --> 00:10:27.240
solve this problem of the coexistence of a master data on one hand and all these operational and analytical datasets that exist everywhere in the organization.
149
00:10:27.780 --> 00:10:31.160
The physical problem of linking those things together and keeping them consistent
150
00:10:31.615 --> 00:10:34.355
become becomes a big challenge as you start to operationalize
151
00:10:34.975 --> 00:10:35.955
the master data.
152
00:10:36.335 --> 00:10:37.715
And they're they're kinda
153
00:10:38.735 --> 00:10:44.835
different, in different scenarios, different use cases, different folks will focus on kinda different parts of this
154
00:10:45.820 --> 00:10:48.800
this, like, journey through master data management.
155
00:10:49.180 --> 00:10:51.360
You know, maybe some projects only require
156
00:10:51.900 --> 00:10:59.920
getting that identifier. Throw the data together, get the identifier. Great. We can go, that's all we needed. We can go run with it. Maybe you're just doing some some analytics.
157
00:11:00.300 --> 00:11:05.145
So you do that as a one off. Every quarter, you produce a report. So we refresh our our
158
00:11:05.525 --> 00:11:08.825
our data. We get this high level of integrity with our master data.
159
00:11:09.205 --> 00:11:11.225
We generate our report. We're good to go.
160
00:11:11.845 --> 00:11:13.305
As you move farther along
161
00:11:13.640 --> 00:11:25.740
and want to actually take that data, operationalize it, use it on an ongoing basis, keep it fresh constantly. You know? So as new data comes into operational systems, it's immediately mastered,
162
00:11:26.120 --> 00:11:38.265
immediately incorporated with the master data. You have to start to go farther in this journey of kinda pulling together and closely integrating your your master data system with your operational database systems and and other applications.
163
00:11:39.365 --> 00:11:40.185
And the
164
00:11:40.589 --> 00:11:52.930
canonical example that's often brought to bear in this context is the idea of the customer record where you have this is our customer. This is all of the attributes about them.
165
00:11:53.285 --> 00:12:01.145
And then there's the challenge of, well, which system is the one that we actually trust the most to collect that information accurately
166
00:12:01.765 --> 00:12:04.905
or different systems collect different pieces of information.
167
00:12:05.560 --> 00:12:18.540
And then there's also the challenge of when you're dealing with people, they change locations. So you have to make sure that you have the appropriate address, but you also want to know their old addresses. And so then you have the the issue of historizing that data, and this applies across other
168
00:12:19.345 --> 00:12:22.245
business objects beyond just your customers.
169
00:12:23.025 --> 00:12:25.925
And I'm wondering if you can talk to some of the
170
00:12:26.385 --> 00:12:32.085
people problems of figuring out what are those decision points, what are the ways that we determine
171
00:12:32.540 --> 00:12:46.000
what is the place that we actually trust the most for which pieces of that data and then being able to actually manage the merging of those attributes from the multiple systems to be able to say, this is the thing that we trust the most.
172
00:12:46.445 --> 00:12:54.385
That other system over there has different information, so we're going to ignore that, or we actually need to use that in that system. But over here, we're gonna use this. I'm just wondering some of the
173
00:12:55.005 --> 00:12:56.705
some of the ways that organizations
174
00:12:57.084 --> 00:13:03.030
have to wrestle with that kind of constant decision making about what data to use where, when, and how.
175
00:13:03.650 --> 00:13:08.310
Yeah. Yeah. I I think I think what you're picking up on is a really key observation about
176
00:13:08.850 --> 00:13:11.750
master data management as, like, a problem space.
177
00:13:12.370 --> 00:13:12.870
It's
178
00:13:13.425 --> 00:13:17.445
fun it's it's not just a technical problem. If it were just a technical problem,
179
00:13:18.145 --> 00:13:25.365
putting data together, creating, like, a coherent knowledge graph is, like, we know how to do that. We can do that. In real organizations,
180
00:13:25.825 --> 00:13:27.525
it's also a political problem.
181
00:13:27.959 --> 00:13:32.860
So you're not just trying to get the data to agree. You're actually trying to get these different teams
182
00:13:33.399 --> 00:13:33.899
to
183
00:13:34.279 --> 00:13:38.060
agree and coexist and have each have their own special
184
00:13:38.519 --> 00:13:42.139
view of the data. Because, you know, we the the reason the data silos
185
00:13:42.475 --> 00:13:46.335
were created in the 1st place was all of these teams operating independently and efficiently.
186
00:13:47.115 --> 00:13:48.655
Pulling together those silos,
187
00:13:49.275 --> 00:13:54.015
you you need to you need to make sure that you don't actually interfere with the independent, happy,
188
00:13:54.555 --> 00:13:57.855
trustful operation of of everyone who created it.
189
00:13:58.220 --> 00:13:58.720
And
190
00:13:59.340 --> 00:14:02.160
what it what it comes down to is
191
00:14:02.620 --> 00:14:06.880
solving the master data management problem less from, like, a
192
00:14:07.900 --> 00:14:08.400
dictatorial,
193
00:14:08.780 --> 00:14:12.080
we will come up with the one standard that will work for everybody
194
00:14:12.765 --> 00:14:13.505
kind of approach.
195
00:14:13.965 --> 00:14:19.985
And more creating a repository for the linkage and creating a system and a common touchpoint
196
00:14:20.445 --> 00:14:23.025
for all of these different silos and applications
197
00:14:23.965 --> 00:14:25.345
to touch base
198
00:14:25.720 --> 00:14:30.300
and stay closely linked in a in a clean way. We, one of our early customers,
199
00:14:31.400 --> 00:14:32.540
very large manufacturer,
200
00:14:33.480 --> 00:14:38.460
when we started working with them, they they essentially said, okay, our our history in in
201
00:14:38.995 --> 00:14:43.975
master data management, we we have this company with many lines of business, different divisions.
202
00:14:44.835 --> 00:14:45.495
We have 26
203
00:14:46.275 --> 00:14:48.295
different major ERP systems.
204
00:14:48.755 --> 00:14:54.295
We have more, but, like, the long tail is too much to to worry about. We have 26 major ERP systems.
205
00:14:54.675 --> 00:14:56.510
All All of our parts, all of our suppliers
206
00:14:57.370 --> 00:14:59.470
exist across all these 26 systems.
207
00:15:00.170 --> 00:15:03.950
We've had several efforts at master data management.
208
00:15:04.730 --> 00:15:11.615
And what happens is we go in, we pick some of these systems, the the largest, most most popular ones that we think are the most trustworthy.
209
00:15:13.355 --> 00:15:18.415
We we collect the data. We consolidate it. We create this master. We have a new identifier.
210
00:15:20.075 --> 00:15:21.135
And at the end,
211
00:15:22.029 --> 00:15:30.930
no one wants to use it. We have 27 systems now for all of our supplier data and all of our parts data. And so if if you go and and kinda
212
00:15:31.310 --> 00:15:36.290
do the technical work, but don't also do it in a way that, that kinda meets
213
00:15:36.665 --> 00:15:38.685
the consumers of the data where they are,
214
00:15:39.064 --> 00:15:39.564
then
215
00:15:40.345 --> 00:15:43.964
the project can be a failure and and and essentially just make the problem worse.
216
00:15:44.985 --> 00:15:49.485
So it's it's really it's really critical to to find that the way to
217
00:15:50.430 --> 00:15:55.970
not just create a standard, but create a system that bridges the gap and maintains the connectivity
218
00:15:56.430 --> 00:15:57.970
between all these different consumers
219
00:15:58.430 --> 00:16:04.370
and does it in a scalable way. If you take 3 of 20 systems and say, this is the con this is how we're consolidating.
220
00:16:04.995 --> 00:16:16.295
Well, what about the 17 other teams? Like, their data's gone now. How are they they don't know it. They have no frame of reference. So you need to you need you need an approach that can scale to handle kind of the the the whole problem.
221
00:16:17.154 --> 00:16:20.779
The other interesting piece of this is that business intelligence,
222
00:16:21.160 --> 00:16:25.899
data warehousing, those have existed in some fashion for at least the past
223
00:16:26.200 --> 00:16:27.740
30 years, give or take.
224
00:16:28.200 --> 00:16:38.005
And so you would think that given that time span, this is a problem that would have been solved at least reasonably well by now. And yet even today, it's still
225
00:16:38.545 --> 00:16:48.005
a challenge that organizations are tackling and starting new projects on today, tomorrow, next week. And I'm wondering what are some of the
226
00:16:48.710 --> 00:16:51.370
evolutionary aspects of the problem that
227
00:16:51.990 --> 00:16:58.330
lead us to having to keep revisiting it and keep resolving it across organization after org after organization
228
00:16:58.870 --> 00:17:02.330
rather than it being a well established, well understood,
229
00:17:03.165 --> 00:17:04.225
more or less solved
230
00:17:04.684 --> 00:17:05.184
problem?
231
00:17:05.965 --> 00:17:09.585
Yeah. It's a good question. I'd I'd say master data management
232
00:17:10.445 --> 00:17:10.945
is,
233
00:17:12.605 --> 00:17:17.725
it's it's about I think it's going on about 3 decades old now. So we've been
234
00:17:19.200 --> 00:17:22.260
companies have been building systems to solve this problem for a while.
235
00:17:22.960 --> 00:17:23.460
And
236
00:17:24.320 --> 00:17:25.620
the traditional systems
237
00:17:26.720 --> 00:17:30.100
tend to focus on using sets of rules
238
00:17:30.720 --> 00:17:32.580
and strict data models
239
00:17:33.365 --> 00:17:35.545
to put together data from source systems,
240
00:17:35.925 --> 00:17:37.385
and and they tend to focus
241
00:17:37.845 --> 00:17:39.545
more on kinda the operational
242
00:17:39.925 --> 00:17:40.425
side.
243
00:17:40.885 --> 00:17:44.345
You know, you you do some basic data quality, you do some basic data integration,
244
00:17:44.899 --> 00:17:51.080
but, fundamentally, you get your your set of golden records and now, okay, put that in a database, like, let's go and use that.
245
00:17:51.380 --> 00:17:57.399
They tend to focus on then, you know, supporting applications downstream, but they don't necessarily do a great job of
246
00:17:57.915 --> 00:18:01.855
pulling in lots of data from the organization, linking it together coherently,
247
00:18:02.475 --> 00:18:04.255
cleaning it up, enriching it,
248
00:18:04.555 --> 00:18:08.335
sort of making sure that the master data itself is actually the best
249
00:18:08.795 --> 00:18:12.540
view there is of the data, has the highest possible quality,
250
00:18:12.840 --> 00:18:14.620
and has all of this linkage across
251
00:18:14.920 --> 00:18:15.820
across organizations.
252
00:18:16.600 --> 00:18:21.820
So currently, what's what's happening is the application of AI and machine learning to these problems
253
00:18:22.200 --> 00:18:23.100
actually unlocks
254
00:18:23.804 --> 00:18:25.024
much better solutions
255
00:18:25.325 --> 00:18:28.465
and the ability to kind of tackle this problem much more holistically
256
00:18:29.164 --> 00:18:32.625
and and do it in just a much higher fidelity way than has happened traditionally.
257
00:18:33.565 --> 00:18:38.225
So to that point of the application of ML and AI in this ecosystem,
258
00:18:39.300 --> 00:18:44.120
Machine learning in various forms has been used at various levels of
259
00:18:44.660 --> 00:18:46.360
success in this context.
260
00:18:46.740 --> 00:18:53.480
You mentioned rules based systems. That's maybe the the expert systems era of AI, which we have largely moved past.
261
00:18:54.155 --> 00:18:56.975
And then there have been a lot of different
262
00:18:57.674 --> 00:19:03.054
natural language processing techniques used for trying to do some of that entity extraction and entity resolution.
263
00:19:03.515 --> 00:19:06.095
And I'm wondering if you can just talk to some of the evolutionary
264
00:19:06.395 --> 00:19:10.850
aspects of the application of ML and AI to the problem of master data.
265
00:19:11.790 --> 00:19:13.650
Yeah. Yeah. Absolutely. So,
266
00:19:14.190 --> 00:19:26.875
you know, you're exactly right to start start with the rules. Because kinda, you know, I would I don't wanna say that rules are the wrong way to solve this problem. They're actually very good for the right use case. But I think, like, the
267
00:19:27.975 --> 00:19:34.289
just for context, like, the fundamental nature of dealing with dirty data is what there's, like, the I think it's Chekhov.
268
00:19:34.909 --> 00:19:36.289
It's like a Chekhov quotation
269
00:19:36.909 --> 00:19:49.555
that all happy families are happy in the same way, but all unhappy families are unhappy in a very different it's true of data too. All bad data is bad in a different way. And so you you need a lot of tools in your toolkit.
270
00:19:50.415 --> 00:19:50.915
So
271
00:19:51.375 --> 00:19:59.875
traditionally, rules for the approach. If you come up with a good data model, if we just model the problem well enough, if we model have a customer model
272
00:20:00.280 --> 00:20:02.940
and schema that that's good enough,
273
00:20:03.240 --> 00:20:06.700
then we can we can put all customer data into that schema,
274
00:20:07.160 --> 00:20:09.420
and we can define rules for how it should work.
275
00:20:10.440 --> 00:20:11.740
The reality is that
276
00:20:12.280 --> 00:20:13.660
data, you know,
277
00:20:14.205 --> 00:20:17.184
data can mean lots of subtly different things
278
00:20:17.965 --> 00:20:18.465
and
279
00:20:19.005 --> 00:20:21.105
and be used in subtly different ways
280
00:20:21.485 --> 00:20:29.505
and pretty much always is. And so you you have to always be ready to account for these slight differences in granularity or slight differences in shade of meaning.
281
00:20:30.270 --> 00:20:30.770
And
282
00:20:31.390 --> 00:20:32.850
so, yeah, so, essentially,
283
00:20:33.550 --> 00:20:34.450
beyond rules,
284
00:20:34.830 --> 00:20:42.050
getting into fuzzy fuzzy matching becomes big, and that starts to lead into natural language processing techniques,
285
00:20:42.725 --> 00:20:45.385
and especially techniques from information retrieval.
286
00:20:47.365 --> 00:20:47.865
And,
287
00:20:48.245 --> 00:20:49.625
you know, applying
288
00:20:50.725 --> 00:20:51.865
scalable methods
289
00:20:52.165 --> 00:20:57.840
from text search goes a very long way in dealing with fuzziness and and solving math
290
00:20:58.240 --> 00:20:59.460
fuzzy matching problems.
291
00:21:00.960 --> 00:21:03.059
Beyond that, you start to get into
292
00:21:03.840 --> 00:21:07.139
statistical techniques and and kinda traditional machine learning,
293
00:21:07.519 --> 00:21:08.019
building
294
00:21:08.720 --> 00:21:10.179
models to classify
295
00:21:11.835 --> 00:21:13.215
matches between data,
296
00:21:13.755 --> 00:21:17.935
to classify groups and taxonomies of data, and to to look for
297
00:21:19.915 --> 00:21:21.135
different different characteristics
298
00:21:21.435 --> 00:21:22.655
of the data to to
299
00:21:24.720 --> 00:21:25.940
perform reconciliation
300
00:21:26.560 --> 00:21:27.060
consolidation.
301
00:21:28.320 --> 00:21:33.140
And then you you know, once once you've entered into this statistics and machine learning world,
302
00:21:35.200 --> 00:21:36.200
the sky's the limit.
303
00:21:36.640 --> 00:21:38.660
And and, essentially, techniques
304
00:21:40.985 --> 00:21:43.725
techniques from 30 years ago and information retrieval
305
00:21:44.345 --> 00:21:47.565
are great, but you can move that all the way through up to,
306
00:21:48.345 --> 00:21:51.565
what we have today with large language models and generative AI,
307
00:21:52.430 --> 00:21:54.370
and apply that to the problem as well.
308
00:21:55.790 --> 00:21:58.850
Large language models and generative AI have definitely
309
00:21:59.230 --> 00:22:03.915
occluded the overall landscape of ML in recent years where they have,
310
00:22:04.395 --> 00:22:09.295
to some degree, become synonymous with AI even though that's not technically accurate.
311
00:22:09.835 --> 00:22:12.175
And I'm curious whether you see
312
00:22:12.715 --> 00:22:13.535
those capabilities
313
00:22:13.915 --> 00:22:15.855
as being a transformative
314
00:22:16.395 --> 00:22:19.135
shift in the space of master data management,
315
00:22:19.770 --> 00:22:20.590
record reconciliation,
316
00:22:21.370 --> 00:22:25.070
entity extraction, or if it's largely an iterative step,
317
00:22:25.530 --> 00:22:34.270
you know, maybe it's a large iteration, but not a wholly transformative piece and just a a a step change improvement in what we already had.
318
00:22:34.995 --> 00:22:39.975
Yeah. I I think this is sort of a lame answer, but I think it's a little of both.
319
00:22:40.275 --> 00:22:41.095
There are
320
00:22:41.555 --> 00:22:43.255
key ways that are incremental
321
00:22:43.635 --> 00:22:47.155
in terms of how you how you match records or,
322
00:22:48.080 --> 00:22:53.620
enrich data or classify data or parse data, applying language models can
323
00:22:54.160 --> 00:22:57.220
it it it adds another really valuable tool in the toolkit.
324
00:22:57.680 --> 00:22:59.300
I wouldn't say it completely.
325
00:23:00.325 --> 00:23:03.705
Well, actually, there are some some scenarios where it does completely
326
00:23:04.485 --> 00:23:08.985
let you throw away a lot of techniques of the past. In schema mapping, for example,
327
00:23:09.845 --> 00:23:16.500
large language models without much training are very good at, I give you 2 tables, tell me how to align them,
328
00:23:17.279 --> 00:23:19.059
from from a schema perspective.
329
00:23:20.240 --> 00:23:25.379
So for for some problems at a small scale, you know, it's just like it blows it out of the water.
330
00:23:25.725 --> 00:23:26.945
For larger scale
331
00:23:27.245 --> 00:23:27.745
problems,
332
00:23:28.365 --> 00:23:33.585
LLMs can give you a lot and can give you a lot of subtlety that using traditional techniques
333
00:23:34.125 --> 00:23:35.905
could be very difficult. So, for example,
334
00:23:37.325 --> 00:23:38.545
language model embeddings
335
00:23:39.259 --> 00:23:41.120
are extremely good at capturing
336
00:23:41.740 --> 00:23:45.919
things like synonyms, synonymous meetings across different terms, abbreviations
337
00:23:47.259 --> 00:23:47.759
without
338
00:23:48.299 --> 00:23:49.200
having to
339
00:23:49.580 --> 00:23:50.480
sort of build
340
00:23:50.860 --> 00:23:51.759
lookup tables
341
00:23:52.294 --> 00:23:53.115
and additional artifacts,
342
00:23:54.215 --> 00:24:01.434
on the side, you you sorta you get a lot of that just, like, the richness of the meaning in the language and how how language works
343
00:24:01.735 --> 00:24:08.710
for free. Except it's not actually for free. It there's a there's a cost in terms of compute. And so so it's like it occupies
344
00:24:09.730 --> 00:24:10.390
a a interesting
345
00:24:10.850 --> 00:24:13.350
spot in the trade off space where if you can
346
00:24:13.810 --> 00:24:17.110
figure out how to use it in a cost effective way alongside
347
00:24:17.650 --> 00:24:18.150
other
348
00:24:18.770 --> 00:24:20.390
cheaper, more scalable techniques,
349
00:24:21.025 --> 00:24:23.205
then you can get a tremendous amount of value.
350
00:24:23.745 --> 00:24:25.925
I think where where it's, like, really transformative
351
00:24:26.305 --> 00:24:26.805
is
352
00:24:27.185 --> 00:24:27.685
creating
353
00:24:28.225 --> 00:24:33.845
more natural user experiences and actually working with the data and solving these problems for end users.
354
00:24:34.270 --> 00:24:39.170
One of the challenges that that at Tamr we've we've wrestled with and and kinda, you know,
355
00:24:39.549 --> 00:24:42.610
learned a ton and be getting better and better at over our
356
00:24:43.070 --> 00:24:44.450
12, 13 year existence
357
00:24:44.910 --> 00:24:46.130
is the problem of taking
358
00:24:46.845 --> 00:24:51.265
complex, you know, complex data problems and complex machine learning concepts
359
00:24:51.965 --> 00:24:54.465
and encapsulating them in a simple user interface
360
00:24:55.165 --> 00:24:58.385
and making them understandable to end users who are not
361
00:24:58.940 --> 00:24:59.440
PhDs
362
00:25:00.460 --> 00:25:02.480
in machine learning, AI, and statistics.
363
00:25:03.260 --> 00:25:03.760
And
364
00:25:04.540 --> 00:25:06.640
LLMs can actually come in and
365
00:25:07.180 --> 00:25:10.160
explain concepts and complex scenarios
366
00:25:10.700 --> 00:25:12.559
in kinda straightforward ways. So
367
00:25:12.985 --> 00:25:16.524
a very, very common situation for us is our system
368
00:25:17.065 --> 00:25:19.485
is doing some record matching consolidation,
369
00:25:20.505 --> 00:25:21.885
presents the user with,
370
00:25:22.265 --> 00:25:26.284
maybe an ambiguous case. We've clustered data from 40 different systems.
371
00:25:26.990 --> 00:25:33.410
Here's 40 different records describing what we think is all the same the same actual person, one of your customers.
372
00:25:34.350 --> 00:25:34.850
And,
373
00:25:35.630 --> 00:25:43.515
what do you think? Is this are are these all in fact the same? Looking at a table with 40 records and a lot of columns is, like, kind of an overwhelming experience.
374
00:25:44.055 --> 00:25:46.795
And so it can be difficult for a human to
375
00:25:47.415 --> 00:25:53.595
parse that and decide, do they do they agree with the machine learning? Do they do they not? Do they think it's you know,
376
00:25:54.695 --> 00:25:56.315
did did it hallucinate this?
377
00:25:56.855 --> 00:25:57.355
And
378
00:25:57.710 --> 00:26:02.130
what a language model can do is actually give you ways to summarize what's on screen.
379
00:26:02.430 --> 00:26:03.570
This is very complex
380
00:26:03.950 --> 00:26:04.450
concepts.
381
00:26:04.830 --> 00:26:07.490
Tell you know, sort of draw user attention to,
382
00:26:07.950 --> 00:26:09.250
you know, hey. Look.
383
00:26:09.550 --> 00:26:12.370
All 40 records here, they all share the same last name.
384
00:26:12.765 --> 00:26:25.665
The first name for for this person is there are only 3 different values, and it's a common you know, this is a common nickname, so it it looks legit. There are a few different addresses, but it seems like maybe they moved over time. And,
385
00:26:26.045 --> 00:26:30.440
you we can kinda put that in context. Can also include, you know, we know what the,
386
00:26:31.220 --> 00:26:34.440
what the model is on the back end that produced this suggestion.
387
00:26:35.140 --> 00:26:41.480
We can provide that context to a language model as well, and it can explain. Well, you know, the the reason these got pulled together were the weightings
388
00:26:41.860 --> 00:26:43.304
for the you know, were,
389
00:26:44.105 --> 00:26:45.245
let's say, this is
390
00:26:45.865 --> 00:26:47.804
a b to c customer mastering
391
00:26:48.664 --> 00:26:49.485
data product.
392
00:26:50.345 --> 00:26:52.524
And in this data product, the model
393
00:26:53.065 --> 00:26:59.320
looks for and and puts a lot of weight on Common Alley and the name and the address and the phone number,
394
00:27:00.100 --> 00:27:03.160
sort of give users a way to engage with
395
00:27:04.020 --> 00:27:05.720
a hard problem, a very
396
00:27:06.179 --> 00:27:10.635
niche problem, but do it in a way that's that's sort of easy to understand
397
00:27:11.335 --> 00:27:12.155
and accessible.
398
00:27:12.934 --> 00:27:15.595
And why this is so important is trust.
399
00:27:16.535 --> 00:27:17.275
One of
400
00:27:18.615 --> 00:27:20.795
the one of the interesting things since,
401
00:27:21.575 --> 00:27:22.955
since the launch of ChatGPT
402
00:27:23.255 --> 00:27:24.235
and kind of
403
00:27:24.620 --> 00:27:28.800
the mainstreaming of AI and large language models
404
00:27:29.580 --> 00:27:30.080
is
405
00:27:30.460 --> 00:27:35.280
it it has it has brought this question of trust. Can you trust the robots
406
00:27:36.540 --> 00:27:37.180
to kinda,
407
00:27:37.660 --> 00:27:39.680
main, you know, mainstream consciousness?
408
00:27:40.304 --> 00:27:44.565
And we we've been dealing with this problem. We've been a machine learning company since the beginning
409
00:27:44.945 --> 00:27:50.644
and have always dealt with you know, everyone always loves to be smarter than the computer and the machine.
410
00:27:51.184 --> 00:27:52.565
And so there's always a questioning
411
00:27:53.105 --> 00:27:58.150
of I see the model is suggesting this. I wanna make sure that model isn't doing something crazy.
412
00:27:58.770 --> 00:28:01.430
With with large language models now being mainstream,
413
00:28:01.970 --> 00:28:05.350
people know that these things hallucinate. They come up with nonsense
414
00:28:05.730 --> 00:28:07.750
if you if you push them a little too far.
415
00:28:08.210 --> 00:28:08.710
And
416
00:28:09.215 --> 00:28:17.715
so there's there's this real questioning of if you're using machine learning and AI techniques to to make this data good, can I trust it? Like, is it real?
417
00:28:18.015 --> 00:28:19.635
And so being able to
418
00:28:20.415 --> 00:28:21.475
kinda take
419
00:28:22.640 --> 00:28:24.900
take our results, the results of the modeling,
420
00:28:25.679 --> 00:28:28.340
and communicate them in a way that
421
00:28:28.720 --> 00:28:32.419
sort of, like, puts the data front and center, but then also provides the context
422
00:28:32.960 --> 00:28:34.020
is really important
423
00:28:34.559 --> 00:28:35.700
for end users
424
00:28:36.240 --> 00:28:37.335
to feel like,
425
00:28:37.895 --> 00:28:41.274
yeah. This this is actually solving the problem. This is real.
426
00:28:41.895 --> 00:28:45.995
This is this is data I can trust. Like, this is the truth about our customers,
427
00:28:46.534 --> 00:28:51.274
and we should adopt this and share this. And so it's it's kind of ironic that, like, the
428
00:28:53.430 --> 00:28:54.170
the technology
429
00:28:54.790 --> 00:28:56.810
that's leading to this crisis of trust
430
00:28:57.430 --> 00:28:58.570
can also be
431
00:28:59.030 --> 00:29:07.325
a big part of the solution of kind of framing it that way. But I I think, you know, as we as we move past the the initial shock of,
432
00:29:08.585 --> 00:29:09.644
artificial intelligence,
433
00:29:10.264 --> 00:29:11.965
that's that's what we're moving into.
434
00:29:14.904 --> 00:29:25.730
As a listener of the Data Engineering podcast, you clearly care about data and how it affects your organization and the world. For even more perspective on the ways that data impacts everything around us, don't miss DataCitizens
435
00:29:26.110 --> 00:29:29.410
Dialogs, the forward thinking podcast brought to you by Calibra.
436
00:29:30.030 --> 00:29:37.010
You'll get further insights from industry leaders, innovators, and executives in the world's largest companies on the topics that are top of mind for everyone.
437
00:29:37.685 --> 00:29:39.225
In every episode of DataCitizens
438
00:29:39.525 --> 00:29:51.545
Dialogues, industry leaders unpack data's impact on the world, like in their episode, the secret sauce behind McDonald's data strategy, which digs into how AI driven tools can be used to support crew efficiency and customer interactions.
439
00:29:52.740 --> 00:29:59.240
In particular, I appreciate the ability to hear about the challenges that enterprise scale businesses are tackling in this fast moving field.
440
00:29:59.860 --> 00:30:10.405
The Data Citizens Dialogues podcast is bringing the data conversation to you, so start listening now. Follow DataCitizens Dialogues on Apple, Spotify, YouTube, or wherever you get your podcasts.
441
00:30:13.345 --> 00:30:14.085
In that
442
00:30:14.385 --> 00:30:17.445
space of large language models, their application
443
00:30:17.825 --> 00:30:20.645
to the problem of master data management,
444
00:30:21.390 --> 00:30:23.010
What are some of the
445
00:30:23.710 --> 00:30:28.770
pieces that are missing from the out of the box perspective of,
446
00:30:29.310 --> 00:30:33.250
I have a large language model. Now I actually have to stand up pieces
447
00:30:33.605 --> 00:30:37.785
x, y, and z before I can even really start to bring it to bear on the problem,
448
00:30:38.165 --> 00:30:40.505
particularly in that context of hallucination
449
00:30:40.965 --> 00:30:42.185
and trust building.
450
00:30:42.645 --> 00:30:43.225
I'm wondering
451
00:30:43.845 --> 00:30:48.505
how you have been working through that challenge of being able to
452
00:30:49.350 --> 00:30:49.850
harness
453
00:30:50.309 --> 00:30:51.210
the capabilities
454
00:30:52.150 --> 00:30:53.210
while mitigating
455
00:30:53.670 --> 00:31:01.050
the inherent risks in the problem of being able to actually build trustworthy data within inherently unpredictable
456
00:31:01.510 --> 00:31:02.010
utility.
457
00:31:03.545 --> 00:31:04.845
Yeah. Yeah. So
458
00:31:05.545 --> 00:31:06.205
I think
459
00:31:06.905 --> 00:31:07.965
well, let's see.
460
00:31:08.665 --> 00:31:10.925
I'm gonna go back a little to start.
461
00:31:11.385 --> 00:31:12.925
When we got started at Tamer,
462
00:31:13.305 --> 00:31:18.240
our our initial vision and our initial goal this was in the days when semantic web was really hot
463
00:31:19.360 --> 00:31:21.860
and knowledge graphs were becoming a big deal.
464
00:31:22.240 --> 00:31:25.620
And our vision was we want a we want a product that can build,
465
00:31:26.160 --> 00:31:29.940
produce efficiently produce the the enterprise knowledge graph.
466
00:31:30.240 --> 00:31:32.179
So within within your organization,
467
00:31:33.040 --> 00:31:35.345
you have this extremely high quality
468
00:31:35.885 --> 00:31:36.385
links
469
00:31:37.245 --> 00:31:41.105
data describing everything you do, everything you care about, all the key entities,
470
00:31:41.885 --> 00:31:42.785
your customers,
471
00:31:43.165 --> 00:31:46.225
your suppliers, your your employees, all the parts,
472
00:31:46.799 --> 00:31:48.259
and products that you produce,
473
00:31:48.720 --> 00:31:50.179
this this whole space.
474
00:31:50.960 --> 00:31:51.460
And
475
00:31:52.399 --> 00:31:58.179
so now, like, in in in this context where we are today with, with these these large scale
476
00:31:58.720 --> 00:31:59.220
models,
477
00:32:00.080 --> 00:32:01.700
that idea of this, like,
478
00:32:02.635 --> 00:32:06.335
correct knowledge graph is is still sorta the,
479
00:32:06.635 --> 00:32:11.295
I I guess, this guiding principle or or it's really this idea of, like, truth for the enterprise.
480
00:32:12.235 --> 00:32:15.420
And to get the to get, like, real value out of
481
00:32:15.900 --> 00:32:17.760
large scale artificial intelligence,
482
00:32:18.140 --> 00:32:22.240
you need to find ways and architectures to tie it back to that truth.
483
00:32:23.020 --> 00:32:25.120
It's very good at syntax
484
00:32:25.580 --> 00:32:27.120
and articulating ideas.
485
00:32:27.980 --> 00:32:31.475
We just need to do a good job giving it the right content and giving it
486
00:32:31.775 --> 00:32:32.434
the right context,
487
00:32:32.975 --> 00:32:34.595
depending on what problem it solved.
488
00:32:35.295 --> 00:32:37.395
So there's there's kind of
489
00:32:39.135 --> 00:32:40.515
an increased importance
490
00:32:41.695 --> 00:32:45.555
of data quality and data linkage and and master data management
491
00:32:45.930 --> 00:32:46.910
to be able to produce
492
00:32:47.930 --> 00:32:49.070
these common datasets,
493
00:32:50.170 --> 00:32:51.550
and and maintain them
494
00:32:51.930 --> 00:32:52.750
so that
495
00:32:53.050 --> 00:32:58.910
you can point, you know, your your GPT at it and get really good high quality trusted
496
00:32:59.465 --> 00:33:00.045
answers from
497
00:33:00.505 --> 00:33:01.245
the AI.
498
00:33:02.505 --> 00:33:04.365
I imagine that the inclination
499
00:33:05.225 --> 00:33:09.885
for people who are thinking about bringing AI to bear on this problem
500
00:33:10.185 --> 00:33:14.445
is that, oh, well, AI is very sophisticated. It has all of these
501
00:33:15.299 --> 00:33:24.360
nifty capabilities. I should be able to just set it loose on my data. It'll solve all of my problems, and I don't really have to worry about it. Maybe just click yes or no a couple of times
502
00:33:24.980 --> 00:33:25.480
versus
503
00:33:26.259 --> 00:33:30.440
what I imagine to be the reality of you actually want to use all of those
504
00:33:31.235 --> 00:33:32.535
manual and
505
00:33:32.995 --> 00:33:48.049
statistical techniques that we have been relying on for and developing for the past 30 years to do maybe the 80% case and use the LLM for that 20% case that takes 80% of the time to accelerate the process a bit. And I'm curious
506
00:33:48.429 --> 00:33:48.929
how
507
00:33:49.790 --> 00:33:51.330
you are guiding organizations
508
00:33:52.110 --> 00:33:55.570
on that strategic aspect of how, where,
509
00:33:55.950 --> 00:33:58.530
when, and why to actually bring
510
00:33:59.105 --> 00:34:01.525
these language models to bear on the problem
511
00:34:02.225 --> 00:34:10.165
in conjunction with all of the other techniques that have been developed and that we have established trust and confidence in?
512
00:34:11.265 --> 00:34:11.765
Yeah.
513
00:34:12.200 --> 00:34:16.220
We so and that that question has has kind of become
514
00:34:16.920 --> 00:34:17.420
central
515
00:34:17.799 --> 00:34:18.299
to
516
00:34:18.599 --> 00:34:21.099
to everyone these days. The the question of,
517
00:34:21.400 --> 00:34:22.299
am I comfortable
518
00:34:23.480 --> 00:34:25.019
using generative AI
519
00:34:25.480 --> 00:34:26.859
with my data?
520
00:34:27.545 --> 00:34:28.045
And,
521
00:34:28.825 --> 00:34:33.485
it sort of so, you know, the previous version of this was, am I comfortable putting our,
522
00:34:34.105 --> 00:34:39.085
you know, our most business critical important high value data assets on the cloud?
523
00:34:39.770 --> 00:34:40.750
That's now shifted.
524
00:34:41.050 --> 00:34:43.150
Most organizations are comfortable with the cloud,
525
00:34:43.530 --> 00:34:44.830
but now it's well,
526
00:34:45.290 --> 00:34:50.589
but can machine learning look at it? What if, God forbid, someone trains a model on our data
527
00:34:50.970 --> 00:34:52.270
and shares that model?
528
00:34:52.810 --> 00:34:53.470
I think
529
00:34:53.865 --> 00:34:55.805
there's there's a certain amount of just
530
00:34:56.185 --> 00:34:57.725
feeling out the
531
00:34:58.185 --> 00:35:00.925
the right level of security around these things.
532
00:35:01.385 --> 00:35:05.885
And I I I don't wanna go into that too deeply. But just for the purposes of solving
533
00:35:06.185 --> 00:35:07.485
problems in this space,
534
00:35:07.980 --> 00:35:09.200
there are big opportunities
535
00:35:10.860 --> 00:35:12.320
to improve quality
536
00:35:12.700 --> 00:35:13.440
of matching
537
00:35:14.060 --> 00:35:14.880
and mastering,
538
00:35:15.820 --> 00:35:17.120
using these new models.
539
00:35:17.500 --> 00:35:22.320
But they they need to be they need to be harnessed. There's there's been a a lot of research
540
00:35:22.875 --> 00:35:24.815
over the last few years applying
541
00:35:25.115 --> 00:35:26.415
large language models
542
00:35:27.195 --> 00:35:31.535
to these sorts of fuzzy database problems, fuzzy joins, group by schema mapping.
543
00:35:32.395 --> 00:35:32.895
And
544
00:35:33.275 --> 00:35:34.815
what they basically find is
545
00:35:35.390 --> 00:35:37.170
large language models perform
546
00:35:37.630 --> 00:35:39.090
with very little configuration
547
00:35:39.390 --> 00:35:40.210
and engineering,
548
00:35:40.990 --> 00:35:43.330
perform as well as a lot of state of the art techniques
549
00:35:44.110 --> 00:35:45.490
that that existed previously.
550
00:35:46.510 --> 00:35:49.250
The challenge is putting those techniques into a system
551
00:35:50.085 --> 00:35:51.224
and into a product
552
00:35:51.925 --> 00:35:53.785
where they're used intelligently
553
00:35:55.925 --> 00:35:56.665
in conjunction
554
00:35:57.045 --> 00:36:03.945
with other lower cost techniques of kinda more traditional machine learning, and also in conjunction with rules and and human feedback.
555
00:36:04.770 --> 00:36:09.270
One of one of our sort of founding principles at Tamr is that,
556
00:36:10.130 --> 00:36:16.470
the machine is never right a 100% of the time. You need humans in the loop to be able to review,
557
00:36:17.090 --> 00:36:17.590
to
558
00:36:18.315 --> 00:36:20.015
address complex cases,
559
00:36:20.474 --> 00:36:22.734
and to assess how well things are going.
560
00:36:23.595 --> 00:36:29.135
And so you need a system that kind of incorporates all all of these pillars of human input,
561
00:36:29.755 --> 00:36:30.974
rules based input,
562
00:36:31.515 --> 00:36:32.015
rules.
563
00:36:32.440 --> 00:36:35.180
And people users love rules. People love rules.
564
00:36:35.560 --> 00:36:40.940
The you know, they're sort of the most if you just say, like, a match means the Social Security number
565
00:36:41.240 --> 00:36:42.780
value is equal.
566
00:36:43.080 --> 00:36:45.900
Everyone loves that. They they understand what that means.
567
00:36:46.280 --> 00:36:47.340
Given the
568
00:36:47.705 --> 00:36:57.885
truth about data quality and how things exist in the real world, that rule might actually be wrong a large proportion of the time in in, you know, some a a real particular case.
569
00:36:58.425 --> 00:37:05.299
But people love that when it's wrong, they they sort of get why as opposed to if if some machine learning model is wrong,
570
00:37:05.760 --> 00:37:07.619
and they wanna know why. It's like, well,
571
00:37:08.000 --> 00:37:12.579
let me show you this random forest decision tree and talk about that.
572
00:37:13.920 --> 00:37:16.484
Let me explain carefully that. Yeah.
573
00:37:18.464 --> 00:37:21.445
So you need all of these things, and and they they all kinda,
574
00:37:21.825 --> 00:37:25.525
come together to to create a a coherent solution
575
00:37:26.065 --> 00:37:26.565
that
576
00:37:26.865 --> 00:37:27.365
doesn't
577
00:37:27.984 --> 00:37:37.849
doesn't have an absolutely overwhelming cost. Like, one one thing we haven't talked much about is if you wanna solve these problems at scale, it can become very expensive very quickly.
578
00:37:38.309 --> 00:37:41.049
By its nature, these are all matching problems. They're quadratic.
579
00:37:41.990 --> 00:37:47.795
Naively, you would be comparing everything to everything else. So if you take a naive approach, you're you're gonna,
580
00:37:48.415 --> 00:37:53.395
you're gonna burn a lot of compute and you're gonna spend a lot of money and you probably won't get the best results.
581
00:37:54.095 --> 00:37:56.755
So you you need you need a way to sort of
582
00:37:57.135 --> 00:37:57.635
identify
583
00:37:58.015 --> 00:38:00.755
the easy parts of the problem, solve them easily.
584
00:38:01.990 --> 00:38:05.610
The unsolvable part parts of the problem, send them to a human,
585
00:38:05.910 --> 00:38:08.650
and then everything in between. And and that's that's where
586
00:38:09.190 --> 00:38:09.930
that's where,
587
00:38:10.550 --> 00:38:11.530
especially the
588
00:38:11.910 --> 00:38:14.490
we're seeing the the biggest boosts from
589
00:38:15.375 --> 00:38:16.275
vector embeddings,
590
00:38:16.575 --> 00:38:20.115
large language models, and newer newer cutting edge techniques.
591
00:38:20.495 --> 00:38:24.675
They can kinda dig into those ambiguous cases and, like, get a lot of value.
592
00:38:25.775 --> 00:38:26.275
Another
593
00:38:26.895 --> 00:38:27.395
complexity
594
00:38:27.695 --> 00:38:28.675
of this space,
595
00:38:29.130 --> 00:38:34.430
particularly when you're first embarking on the process of trying to reconcile all of your organizational
596
00:38:34.730 --> 00:38:35.869
data, is
597
00:38:36.569 --> 00:38:37.470
level of
598
00:38:38.329 --> 00:38:38.829
expertise
599
00:38:39.450 --> 00:38:41.630
in the process of master data management
600
00:38:41.934 --> 00:38:44.035
as well as level of familiarity
601
00:38:44.414 --> 00:38:45.875
with the data itself,
602
00:38:46.815 --> 00:38:47.315
where
603
00:38:47.855 --> 00:38:58.660
the person who created the data figured out what the schema should be, decided what attributes to pick, may not even be with the company anymore, so you don't have all of the context, all of the information.
604
00:38:59.520 --> 00:39:01.380
And especially when you have
605
00:39:02.480 --> 00:39:03.060
a inexperienced
606
00:39:03.440 --> 00:39:09.694
team who's just starting on this process, and then you say, hey. Here. Rub some machine learning on it. It's magical.
607
00:39:10.555 --> 00:39:12.494
I'm wondering what are some of the
608
00:39:13.595 --> 00:39:18.575
potential pitfalls that you're setting them up for if they don't have an appropriate understanding
609
00:39:19.035 --> 00:39:24.340
of what are the actual capabilities and limitations of the techniques so that they can
610
00:39:24.960 --> 00:39:29.700
be appropriately skeptical or appropriately confident where where those apply appropriately.
611
00:39:30.960 --> 00:39:31.460
Yeah.
612
00:39:31.840 --> 00:39:32.340
That's,
613
00:39:33.360 --> 00:39:39.785
touching back on the political problem of master data management. You have you have to get a lot of different kinds of people involved.
614
00:39:40.405 --> 00:39:43.705
The the domain experts, the subject matter experts
615
00:39:44.245 --> 00:39:45.225
are very rarely
616
00:39:46.405 --> 00:39:47.625
the people who
617
00:39:48.245 --> 00:39:49.865
are own the project,
618
00:39:50.165 --> 00:39:50.665
essentially.
619
00:39:51.630 --> 00:39:53.170
They have to be drafted in
620
00:39:53.789 --> 00:39:54.109
and,
621
00:39:54.589 --> 00:39:57.890
to to and convinced to share their time to to really
622
00:39:58.670 --> 00:40:00.369
make make the project successful.
623
00:40:00.750 --> 00:40:03.650
And so so, yeah, there there does tend to be skepticism
624
00:40:04.029 --> 00:40:04.529
of
625
00:40:05.195 --> 00:40:18.575
what what is the, you know, what's the system doing? And if it's a if it's an AI based system, you know, the skepticism is increased, and they'll see these things. They'll look at the data, say, this doesn't make sense. This doesn't make sense. Why is it doing it this way?
626
00:40:19.119 --> 00:40:20.500
And so you you kinda
627
00:40:20.960 --> 00:40:22.900
you you need a workflow that
628
00:40:23.280 --> 00:40:32.420
kind of embraces that uncertainty to an extent or makes users comfortable with the fact that the data is bad and we're not gonna fix it all at once. It's gonna be a process.
629
00:40:33.945 --> 00:40:37.885
And so so something interesting we we we learned over the years,
630
00:40:38.345 --> 00:40:41.305
one of our earlier products was very explicitly built
631
00:40:41.705 --> 00:40:44.525
designed as a system for end users to train
632
00:40:45.065 --> 00:40:45.565
models
633
00:40:45.865 --> 00:40:47.005
to master data.
634
00:40:47.570 --> 00:40:51.110
And so there were workflows for end users to come in and
635
00:40:51.650 --> 00:40:52.310
the system,
636
00:40:52.850 --> 00:40:54.870
we used active active learning techniques
637
00:40:55.330 --> 00:40:57.430
to surface really high value examples.
638
00:40:57.890 --> 00:41:06.285
Users go in, they label the examples, and the model gets gets trained as quickly as possible. And it's kinda make this this, like, really, like, ML practitioner
639
00:41:07.065 --> 00:41:07.565
experience
640
00:41:07.865 --> 00:41:09.085
available to
641
00:41:09.704 --> 00:41:10.925
non ML experts.
642
00:41:12.105 --> 00:41:12.605
And
643
00:41:13.145 --> 00:41:24.490
that system, it you know, it's it as easy as we made it, it was still hard to use, and you still had to kinda understand machine learning. And so for subject matter experts is a challenge, and there's there's a lot of hand holding.
644
00:41:25.110 --> 00:41:29.370
So we we've we've moved towards more oh, the the models will be will be pretrained,
645
00:41:30.245 --> 00:41:36.345
and we have general models that that can apply to your domain and start at a very high level, and then you'll be tuning them.
646
00:41:37.045 --> 00:41:37.545
And
647
00:41:38.005 --> 00:41:44.505
what we found actually when we first did that, we we no longer had this kind of, like, active feedback workflow.
648
00:41:45.849 --> 00:41:52.190
And what we found was that actually damages trust with the end users. They want to give feedback to the machine,
649
00:41:53.130 --> 00:41:55.790
and they wanna have that back and forth, have that conversation.
650
00:41:56.890 --> 00:41:58.750
That's really important in kind of, like,
651
00:41:59.645 --> 00:42:01.505
gaining trust in the system.
652
00:42:01.805 --> 00:42:02.305
Was
653
00:42:02.605 --> 00:42:03.265
the system
654
00:42:04.525 --> 00:42:05.025
directing
655
00:42:05.645 --> 00:42:09.425
how you should be exploring the data, how you should be interacting with it,
656
00:42:09.885 --> 00:42:18.360
and, and how you should be understanding it. And so so we've we've kinda brought that back. So even though now it's you're not training, you're actually still,
657
00:42:18.980 --> 00:42:25.080
you can go and you can interact with with the system as if you're training it, and and it's it's this positive user experience.
658
00:42:26.500 --> 00:42:28.040
And in your experience
659
00:42:28.340 --> 00:42:28.840
of
660
00:42:29.655 --> 00:42:30.155
building
661
00:42:30.695 --> 00:42:31.195
Tamer,
662
00:42:31.575 --> 00:42:32.395
working with
663
00:42:32.695 --> 00:42:33.195
organizations
664
00:42:33.575 --> 00:42:36.235
to address this challenge of master data management,
665
00:42:36.695 --> 00:42:37.675
and incorporating
666
00:42:38.135 --> 00:42:41.995
these ML and the newer generation of generative AI
667
00:42:42.849 --> 00:42:43.349
capabilities
668
00:42:43.650 --> 00:42:44.150
into
669
00:42:44.530 --> 00:42:45.349
that system,
670
00:42:45.810 --> 00:42:54.950
what are some of the most interesting or innovative or unexpected ways that you've seen ML and AI techniques used in that context of data resolution and master data management?
671
00:42:56.145 --> 00:42:57.365
Yeah. It's a good question.
672
00:42:58.065 --> 00:42:59.685
You know, our our
673
00:43:00.065 --> 00:43:02.885
our architecture is is fairly generic. So
674
00:43:03.425 --> 00:43:04.565
we primarily
675
00:43:05.825 --> 00:43:08.485
work with structured enterprise data,
676
00:43:08.840 --> 00:43:10.460
relational database systems,
677
00:43:11.160 --> 00:43:13.740
but we can we can extend the system to,
678
00:43:14.680 --> 00:43:20.540
work with more complex data types. And so actually, we we support number of years ago, we added support for,
679
00:43:21.400 --> 00:43:21.900
geodata
680
00:43:23.075 --> 00:43:24.214
and, GeoJSON,
681
00:43:25.234 --> 00:43:26.135
essentially polygons.
682
00:43:26.994 --> 00:43:27.494
And,
683
00:43:28.755 --> 00:43:37.690
the applications that users have for that system are are are really quite interesting and surprising. And, you know, normally, you think about master data management as applying
684
00:43:38.870 --> 00:43:40.410
to fairly narrow subset
685
00:43:40.870 --> 00:43:42.970
of data, customer data,
686
00:43:43.750 --> 00:43:44.810
you know, organizations,
687
00:43:45.110 --> 00:43:45.610
people,
688
00:43:46.230 --> 00:43:47.530
parts, products.
689
00:43:48.070 --> 00:43:49.965
That's kind of the the sweet spot.
690
00:43:50.365 --> 00:43:53.025
But, with with some of these other, you know,
691
00:43:53.485 --> 00:43:56.785
data formats that we support, we've seen it applied to things like
692
00:43:57.085 --> 00:43:59.665
radar tracks, like keeping track
693
00:44:00.125 --> 00:44:02.145
of fuzzy data related to
694
00:44:03.530 --> 00:44:04.410
planes and,
695
00:44:04.970 --> 00:44:11.790
other kinds of, like, aerial phenomena and stuff like that. And it it it kinda really gets out there. It's it's it's pretty cool to see.
696
00:44:12.650 --> 00:44:15.470
In your work of building these systems,
697
00:44:16.285 --> 00:44:17.665
coming to grips with
698
00:44:18.365 --> 00:44:29.345
the constantly evolving landscape of ML and AI techniques, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process of building a product that harnesses that?
699
00:44:30.530 --> 00:44:32.390
So a big challenge that we
700
00:44:32.770 --> 00:44:39.270
frequently have thought that we've solved but sort of continue to find better solutions every couple of years
701
00:44:39.810 --> 00:44:44.390
as we you know, each each solution seems to, like, reveal another side of the problem
702
00:44:45.384 --> 00:44:47.724
is finding how to connect
703
00:44:48.825 --> 00:44:49.964
the 2 modes
704
00:44:50.345 --> 00:44:50.845
of
705
00:44:51.625 --> 00:44:53.244
solving these sorts of problems.
706
00:44:53.785 --> 00:44:55.484
We we talked earlier about,
707
00:44:56.025 --> 00:44:58.125
you know, you can you can take some data
708
00:45:00.050 --> 00:45:00.950
as a snapshot,
709
00:45:01.410 --> 00:45:03.830
as a one off project, put it all together.
710
00:45:04.290 --> 00:45:06.950
You're gonna run some large scale batch computation.
711
00:45:07.730 --> 00:45:10.310
You're gonna put it all together, and then you're gonna be done.
712
00:45:11.265 --> 00:45:18.085
But then it's like, okay. Yep. But the data is not static. What happens when customer x, y, and z all come in and,
713
00:45:19.025 --> 00:45:21.765
they they someone moved, their address changed,
714
00:45:22.545 --> 00:45:23.605
maybe some customers
715
00:45:24.099 --> 00:45:27.000
passed away and you no longer wanna be sending them
716
00:45:27.300 --> 00:45:28.359
offers in the mail,
717
00:45:29.300 --> 00:45:33.079
maybe 2 companies merge or or, you know, split up.
718
00:45:35.060 --> 00:45:38.520
Things happen in the real world, and you need to manage this on an ongoing basis.
719
00:45:38.994 --> 00:45:39.494
And
720
00:45:40.675 --> 00:45:42.055
many applications, like,
721
00:45:42.435 --> 00:45:44.295
most applications in the real world
722
00:45:44.595 --> 00:45:50.615
aren't content to just have a one off solution and kinda need this need to be able to solve the problem
723
00:45:51.970 --> 00:45:54.230
in a, you know, in a live ongoing
724
00:45:54.690 --> 00:45:56.790
updated in real time kind of fashion.
725
00:45:58.130 --> 00:45:58.630
And
726
00:45:59.410 --> 00:46:02.790
we found it's it's a major challenge kinda marrying the
727
00:46:03.734 --> 00:46:04.234
extremely
728
00:46:05.815 --> 00:46:09.674
efficient, high throughput batch oriented solutions to these problems
729
00:46:10.454 --> 00:46:12.075
with a more operational
730
00:46:12.934 --> 00:46:14.315
live system database
731
00:46:15.174 --> 00:46:18.300
to to solve it on an ongoing basis sort of in real time
732
00:46:18.620 --> 00:46:20.960
or in a in, like, a a streaming
733
00:46:21.420 --> 00:46:22.800
event driven fashion.
734
00:46:23.660 --> 00:46:29.280
And to essentially take the the core of the system, all these techniques that we've been talking about,
735
00:46:30.620 --> 00:46:31.840
rules based matching,
736
00:46:32.424 --> 00:46:35.164
lessons from natural language processing and information retrieval,
737
00:46:35.704 --> 00:46:39.404
and, you know, kind of the the latest AI has to offer,
738
00:46:40.025 --> 00:46:42.525
and apply them in consistent ways across
739
00:46:43.065 --> 00:46:45.325
2 different extremely different architectures
740
00:46:46.420 --> 00:46:50.680
and marry those together and do it in a way that end users can actually use that
741
00:46:50.980 --> 00:46:53.880
and transition from one to the other. So you, you know,
742
00:46:54.260 --> 00:46:55.800
can come in to,
743
00:46:56.820 --> 00:46:58.200
to the system and
744
00:46:58.925 --> 00:47:02.145
load a whole bunch of data, process it in a big way,
745
00:47:02.525 --> 00:47:04.865
create that initial starting point for
746
00:47:05.485 --> 00:47:07.505
what your master data should look like,
747
00:47:07.885 --> 00:47:11.585
and then, like, boom, you're up and running. It's in a live database.
748
00:47:12.150 --> 00:47:26.809
Now you can interact with it directly. You can start to point other systems at it, use it in a way where it's it's not this one off. It's not some extract that's gonna be irrelevant tomorrow and no one's gonna adopt it. It kinda becomes this living piece of of the overall architecture
749
00:47:27.555 --> 00:47:28.295
within an
750
00:47:29.634 --> 00:47:30.134
organization.
751
00:47:31.474 --> 00:47:33.494
And for people who are
752
00:47:34.194 --> 00:47:38.055
addressing these challenges of master data management, data reconciliation,
753
00:47:38.915 --> 00:47:50.020
trying to figure out what is the cross cutting view of their business? What are the cases where ML and AI are the wrong choice for some or all of that problem?
754
00:47:51.360 --> 00:47:54.260
Yeah. Good question. I I think it comes down to
755
00:47:56.055 --> 00:47:56.555
simplicity
756
00:47:57.255 --> 00:48:01.994
of the problem. Sometimes, you know, it's AI and ML are are bright and shiny. But
757
00:48:02.535 --> 00:48:03.035
for
758
00:48:03.734 --> 00:48:08.690
smaller scale problems, you know, you maybe you just you're putting together a couple of sources. Or
759
00:48:09.869 --> 00:48:15.890
maybe you're you you really just need to do this. You you have a one off. You're trying to create a, you know, this one time presentation.
760
00:48:16.670 --> 00:48:19.410
If you don't have a lot of complexity to the problem, then
761
00:48:20.030 --> 00:48:23.890
deterministic techniques are gonna are are are likely to win.
762
00:48:24.275 --> 00:48:28.535
There's nothing wrong with rules, and applying a rule can be much cheaper
763
00:48:29.235 --> 00:48:29.735
than
764
00:48:31.315 --> 00:48:33.415
applying AIML to the problem.
765
00:48:34.275 --> 00:48:35.255
So if if
766
00:48:35.635 --> 00:48:37.335
if you kinda have a low stakes
767
00:48:38.070 --> 00:48:49.610
scenario where you can just 80 20 it and get a good answer quickly, then then, yeah, like, go crazy with deterministic solutions. That that should, you know, and that that that should be the first step really of any
768
00:48:49.910 --> 00:48:50.410
approach.
769
00:48:51.965 --> 00:48:56.145
Pick the low hanging fruit, then get into the hard problem, and we'll make it really good.
770
00:48:57.325 --> 00:48:58.785
And as you continue
771
00:48:59.085 --> 00:48:59.585
to
772
00:48:59.885 --> 00:49:00.705
invest in
773
00:49:01.085 --> 00:49:07.730
and keep tabs on this evolving space of large language models and generative AI and its application
774
00:49:08.110 --> 00:49:10.370
to the challenge of data cleaning?
775
00:49:10.670 --> 00:49:14.930
What are some of the hopes or predictions that you have or any specific
776
00:49:15.790 --> 00:49:20.210
techniques or areas of effort that you're keeping a close watch on?
777
00:49:21.785 --> 00:49:23.485
Yeah. So I I think the,
778
00:49:24.505 --> 00:49:25.725
the ability to
779
00:49:26.985 --> 00:49:27.485
build
780
00:49:28.265 --> 00:49:29.405
intelligent agents
781
00:49:29.785 --> 00:49:30.285
into
782
00:49:31.625 --> 00:49:32.125
existing
783
00:49:32.505 --> 00:49:33.485
user workflows
784
00:49:34.240 --> 00:49:36.020
is is creating a big opportunity
785
00:49:36.320 --> 00:49:44.740
to you know, I like, the the first wave of this AI rollout was, like, put a chatbot in it. You got a product, put a chatbot in it. It's gonna be amazing.
786
00:49:45.200 --> 00:49:48.660
And there are some good applications for that. But I think what's what's really
787
00:49:48.995 --> 00:49:49.895
coming up next
788
00:49:50.195 --> 00:49:50.695
is
789
00:49:51.875 --> 00:49:54.295
looking at what are the problems where
790
00:49:55.555 --> 00:49:56.055
LLMs
791
00:49:56.355 --> 00:49:57.895
are extremely well suited,
792
00:49:58.675 --> 00:50:02.535
and then how can you apply those to actual, like, key features within a product
793
00:50:03.150 --> 00:50:07.410
and deploy that? Like, really starting to think of it as just like this is a
794
00:50:07.710 --> 00:50:09.809
this is this this capability we can productionize.
795
00:50:10.190 --> 00:50:17.905
Like, how do we think about our product road map and where we build that and how we use it and how we adopt it? And I I think the the upshot is
796
00:50:18.525 --> 00:50:19.665
a lot of the challenging
797
00:50:19.965 --> 00:50:20.465
work
798
00:50:20.845 --> 00:50:21.345
in
799
00:50:22.205 --> 00:50:27.505
not in solving the master data management problem, but in managing the system and the complexity of it
800
00:50:28.365 --> 00:50:30.945
can be automated to a much larger extent.
801
00:50:31.530 --> 00:50:34.270
So, you know, there's there's there's a lot of configuration
802
00:50:34.570 --> 00:50:36.830
that goes into pulling data from different systems,
803
00:50:37.130 --> 00:50:42.270
aligning all the schemas, figuring out how you wanna enrich, how you wanna apply data quality transformations,
804
00:50:42.810 --> 00:50:45.150
how you wanna pull in third party source data,
805
00:50:45.795 --> 00:50:47.175
kind of just just, like,
806
00:50:47.954 --> 00:50:51.815
creating that model of what what you want your master data to look like
807
00:50:52.194 --> 00:50:54.855
starting from what all your source data looks like.
808
00:50:55.635 --> 00:50:56.135
And
809
00:50:56.435 --> 00:51:05.760
there's there's big opportunities for LLMs to go in and and just simplify that, turn it into you know, give you a very straightforward kinda just, like, basic
810
00:51:06.140 --> 00:51:07.440
wizard like experience
811
00:51:08.460 --> 00:51:09.280
setting up
812
00:51:10.060 --> 00:51:11.680
this extremely complex
813
00:51:11.980 --> 00:51:12.480
machine
814
00:51:13.455 --> 00:51:18.435
to go and process all this data in complex ways. And then and then to manage it over time.
815
00:51:18.975 --> 00:51:19.635
It's sorta
816
00:51:20.415 --> 00:51:26.835
putting agents into the system can take the hardest parts of the user experience and either automate them away
817
00:51:27.210 --> 00:51:30.349
or, you know, make turn them into a delight for end users.
818
00:51:31.050 --> 00:51:32.190
And so we're
819
00:51:32.490 --> 00:51:35.950
focused a lot on kinda really simplifying down that that experience
820
00:51:36.570 --> 00:51:37.550
and making,
821
00:51:38.410 --> 00:51:41.550
making master data management something that isn't kinda this, like,
822
00:51:42.805 --> 00:51:47.865
scary thing that sounds like it's doomed to fail and will be very expensive, but it's more like, no. No. No. This is just
823
00:51:48.325 --> 00:51:53.945
this is this is something you need. Like, if you're not doing this, you're crazy. All your data could be 10 times better,
824
00:51:54.485 --> 00:51:54.985
and
825
00:51:55.365 --> 00:51:58.040
you won't be tearing your hair out to get there.
826
00:51:59.620 --> 00:52:01.160
I think that point too
827
00:52:01.860 --> 00:52:06.840
of figuring out what is that common cohesive schema, what is the representation
828
00:52:07.220 --> 00:52:10.920
that is going to be useful and applicable and easy to integrate
829
00:52:11.915 --> 00:52:15.855
is one of the challenges as well, and maybe the LLMs can help
830
00:52:16.155 --> 00:52:19.775
set that initial pass of here or something that it could look like.
831
00:52:20.395 --> 00:52:28.109
Because at either end of the spectrum, you have either people who are unable to see the art of the possible because it looks too daunting,
832
00:52:28.570 --> 00:52:33.470
or you have people at the other end of the spectrum who ask for the impossible because they think it's easy.
833
00:52:34.570 --> 00:52:36.990
Yeah. Yeah. Absolutely. I think, like,
834
00:52:37.690 --> 00:52:38.910
there's there's, like,
835
00:52:39.565 --> 00:52:46.465
LLMs are really good at translating. Right? Like, you can speak different languages and they can act as an intermediary and, like, you can
836
00:52:46.925 --> 00:52:50.145
and it's and it just works somehow. I think there's there's kinda, like,
837
00:52:50.925 --> 00:52:58.680
there there's a a vision for a future here of, like, what if you did master data management and there wasn't even, like, a single master data model?
838
00:52:58.980 --> 00:53:01.079
What if everyone got to keep their own model
839
00:53:01.460 --> 00:53:05.400
that they wanted from the beginning and there's an LLM in the middle that was just intelligently
840
00:53:05.700 --> 00:53:12.115
translating across these things? So everyone thinks they're speaking the same language, but it's really, you know, it's like a tower of Babel situation.
841
00:53:12.415 --> 00:53:18.195
So the the like, that's kind of the promise here. And I I I think it's it's a big opportunity. It's still there's a lot of
842
00:53:18.655 --> 00:53:23.475
challenging engineering and product development to to get to that, but that's where we're headed.
843
00:53:25.130 --> 00:53:38.415
Are there any other aspects of this overall space of master data management and the application of ML and and AI to its execution and implementation that we didn't discuss yet that you'd like to cover before we close out the show?
844
00:53:38.895 --> 00:53:42.515
I feel like I had something more to say about 3rd party data, but, honestly,
845
00:53:43.295 --> 00:53:44.675
I I think we might be good.
846
00:53:45.695 --> 00:54:02.710
Fair enough. Yeah. Well, for anybody who wants to get in touch with you and follow along with the work that you and your team are doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as being the biggest gap in the tooling or technology that's available for data management today.
847
00:54:03.570 --> 00:54:04.230
I think
848
00:54:05.405 --> 00:54:07.744
it it it feels like it comes back to
849
00:54:08.445 --> 00:54:10.065
somehow a location challenge.
850
00:54:10.445 --> 00:54:18.065
I don't know. Maybe I'm just thinking about this because this has been on the problem I've been dealing with lately. But, I feel like we haven't really solved the, like,
851
00:54:18.420 --> 00:54:19.640
cross cloud problem.
852
00:54:20.260 --> 00:54:21.000
There are
853
00:54:21.859 --> 00:54:22.920
really good systems
854
00:54:23.300 --> 00:54:24.359
on different clouds,
855
00:54:25.140 --> 00:54:31.240
and they're they don't translate 1 to 1. So there's a lot of there's a lot of, like, essential technology that's locked up
856
00:54:31.619 --> 00:54:32.119
in
857
00:54:32.925 --> 00:54:33.425
different
858
00:54:33.885 --> 00:54:34.385
proprietary
859
00:54:34.765 --> 00:54:35.745
walled gardens.
860
00:54:36.285 --> 00:54:39.425
And so it's, like, it's now very easy
861
00:54:40.285 --> 00:54:40.945
to build
862
00:54:41.885 --> 00:54:43.025
extremely powerful
863
00:54:43.805 --> 00:54:44.625
cutting edge
864
00:54:45.490 --> 00:54:46.310
data architectures
865
00:54:46.690 --> 00:54:47.990
for managing your data.
866
00:54:48.690 --> 00:55:00.550
But you have to make some pretty big decisions at at at the outset and some pretty big bets on on vendors and who you trust in the market. And it's it's gotten a lot harder to kinda
867
00:55:01.275 --> 00:55:02.095
remain independent.
868
00:55:02.875 --> 00:55:10.255
On the other hand, it's also easier to remain independent. There's a lot of amazing tools that kind of like breaking up the relational database into
869
00:55:10.635 --> 00:55:12.174
its component parts and
870
00:55:12.474 --> 00:55:15.535
using independent systems to to put it back together.
871
00:55:16.070 --> 00:55:20.090
And there's there's, like, at the same time, there there are a lot of these amazing tools
872
00:55:20.550 --> 00:55:22.090
in the open source world.
873
00:55:22.550 --> 00:55:24.250
But but it's it's kinda it's,
874
00:55:26.390 --> 00:55:30.970
it's difficult for the world to collide and to kinda put it all together into coherent
875
00:55:31.505 --> 00:55:33.125
coherent approach. So so
876
00:55:33.905 --> 00:55:38.485
yeah. And I I think there's, like, I feel like there's a little bit too much satisfaction
877
00:55:38.785 --> 00:55:39.285
with
878
00:55:40.465 --> 00:55:44.165
folks thinking if you put all the data into a single physical place
879
00:55:45.270 --> 00:55:47.210
that all of your problems are solved
880
00:55:47.910 --> 00:55:53.610
and really you're just kinda, like, kicking a bunch of problems down the road for 10 years till you get sick of your vendor and
881
00:55:53.910 --> 00:55:55.930
need to go do something dramatically different.
882
00:55:57.025 --> 00:56:03.845
Now the the data gravity problem is definitely real, and until we are able to circumvent physics, it won't go away.
883
00:56:04.145 --> 00:56:05.125
Yeah. Yeah.
884
00:56:06.865 --> 00:56:13.250
Alright. Well, thank you very much for taking the time today to join me and share your thoughts and experience on building
885
00:56:13.710 --> 00:56:23.410
these master data management workflows, bringing ML and AI to bear, and some of the ways that their current generation of LLMs and generative AI are adding new capabilities
886
00:56:23.790 --> 00:56:37.865
and techniques to that process. So they appreciate all the time and energy that you and your team are putting into bringing that to bear and making it more accessible and easier to apply to this challenge, and I hope you enjoy the rest of your day.
887
00:56:38.270 --> 00:56:41.569
Thank you. Yeah. Thanks so much for having me. This has been fantastic.
888
00:56:49.710 --> 00:56:52.849
Thank you for listening, and don't forget to check out our other shows.
889
00:56:53.265 --> 00:57:03.045
Podcast dotnet covers the Python language, its community, and the innovative ways it is being used, and the AI Engineering Podcast is your guide to the fast moving world of building AI systems.
890
00:57:03.825 --> 00:57:13.480
Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email host at data engineering podcast.com
891
00:57:13.859 --> 00:57:20.119
with your story. And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.