Latest / The Data Splash / How Data Teams Power AI - with Abe Gong
Transcript
- Ido Bronstein: Welcome everyone to the Data Splash podcast brought to you by Upriver. If you are a data engineer, a data leader, or just someone trying to make sense of what the hell is going on with AI and data right now, you are in the right place. Here with me today is Abe Gong. Hey Abe, great to have you here. Abe was the CEO and co-founder of Great Expectations, the famous open source that everybody here ⁓ is using every day, I believe. So today we are going to talk about what is happening for data teams and how they are managing their knowledge inside of an organization in order to ⁓ enable ⁓ ⁓ automation through the whole organization. But before we jump in, we start with our little tradition, the 30 Second No time to think, just instinct. So Abe, are you ready? Abe: Think so, let's go for it. Ido Bronstein: Let's go for it, yes! most overhyped phase in data right now. Abe: probably context graph. It's a good phrase. There's something real there, but it's also hugely overhyped. Ido Bronstein: Dream destination vacation. Abe: my parents are taking me on a safari to Nairobi this summer. yeah, call call that a dream. Ido Bronstein: Will Full Stack Data Engineer be the most common data title in 2028? Abe: Probably not. It's a good title, but probably ⁓ Ido Bronstein: Not. Okay. Thank you very much, Abe. So let's jump to business. First of all, if you can start with a short brief about you and how you arrived to the concept of knowledge bases inside organizations. Abe: I'm not sure how short I can make it, so keep me on track here. But just giving you some of my background, I came up through data engineering and data science, starting my career out of grad school in 2012, like 10 years ago. And at that time, I kept getting hired to build data teams to build cool algorithms and discovered everywhere I went that the actual problems were all on the engineering side. You had to get a the supply chain for the data to work before you could do the algorithm stuff. So when you do that, partly from a technical perspective and also just like from a functional company building perspective, you end up thinking a lot about what are the things that people need to know in order to get their work done. And yeah, so that makes me fascinated with concept of knowledge management and it's a big part of what I'm working on now. Ido Bronstein: Yeah. Yeah, amazing. So it's interesting that you came from the downstream usage. You saw that you started with the algorithm and you suddenly understand that the real work is what I already know right now before I can do some sophisticated algorithm. And I think this is exactly what people feel right now that they are trying to leverage very cool ⁓ models. But ⁓ then remember that they need to explain the model. what you have, what you know, and only then he can really to work. So yeah, it's all garbage in and garbage out ⁓ for an ⁓ overall view. I think that is one the reasons that I am really excited to talk with you about because today I think every organization that I talked with that without really incorporate this knowledge of what is happening right now in the organization, what is the business, what is customers, what is... the different departments that they have in the internal organization advanced models won't be really effective. ⁓ if companies really want to change their work and be what we call it like AI native, they have to first understand how they are building the internal knowledge base. And this is how I see that. Abe: Mm-hmm. Yeah, like I've seen so many teams that are trying to, for example, attach agents to a CRM and then they realize, ⁓ we need to deduplicate our CRM first, right? Like, otherwise we're going to end up sending, you know, the wrong offers to the wrong people. There are a lot of horror stories about scaling AI ⁓ on data way. Ido Bronstein: Yeah, so would you define like a knowledge base? Abe: I'm still fishing for like the really concise boiled down definition, but I think memory is a good place to start. I think in general, when you talk about a knowledge base, people think, well, it should kind of know all the things that you know. But I think, I think memory gets complicated when you start thinking about the read and the write access patterns that you need from it. And what I mean by that is it's not just remembering what one person did or what one agent did. You're remembering many different people, many different agents. ⁓ And then ideally, you're not just keeping a log of stuff, like a log doesn't feel like a full knowledge base. There's some layer of curation there. There's some layer of extracting the important parts, understanding how they connect together, and then surfacing them in a way where they become more useful in the future. Ido Bronstein: Interesting. So I think that first of all, when I'm thinking about knowledge base, it is some kind of like database, not database in the traditional way, but some kind of a central storage that condense the entities and relationship and the meaning inside organization. would you agree on like this very high level definition? Abe: would agree an aspirational way. I think that you want a knowledge base to do that. But when I look around at the things that people are calling knowledge bases, you have, for example, like the giant SharePoint folder that has 15 years of documents in it. They're not very organized. They're certainly not tied together in a relational database type of way. ⁓ In theory, they could But it's a lot of work to get to that point. And then kind of at the other end of the spectrum, you have all these people running OpenClaw or Hermes or personal agents. And in that case, the knowledge base is often like a Wiki, right? It's like a folder that has a bunch of markdown files in it. And I don't think that that's the ideal knowledge base, but it's actually adequate for a lot of tasks. Ido Bronstein: Yeah. Abe: So ⁓ I guess I'm stretching the definition because I think... I think it's useful to think about all of those things collectively as knowledge bases and then start to understand what operations are and aren't supported by different infrastructure. Ido Bronstein: Interesting, but I think that something very, that you said that knowledge need to be curated. So we can call like a 50 year old drive with like thousands of documents and knowledge base, but it's not really usable. And there is a lot of the duplication of like, ⁓ definition, ⁓ things change over time. So. What is really interesting for me is to think about that like in the old day when you have all this fraud data that was garbage. And then in order to use that, you needed to curate that across all the, for example, medallion architecture or classical data pipelines. So in that manner, from what I hear from you, it's basically kind of the same, but in a bit of a broader view when it's not just tables, it's documents, it's that claw, gather from all around the and save in markdown files. And from you need to curate it, something that is really represent the ongoing business. Abe: Mm-hmm. I think that's right. I would just push on the when you say you need to curate it, I just would say why. And for me, the why is in order to support certain operations, you need to curate it. something like the giant SharePoint, like does it support search? Yeah, can search across it. How useful is search on its own? Not very, right? Like if you pull up a document from 10 years ago, do you still trust it? Is it still current? In order to make that, ⁓ in to make that judgment. You have to compare it with a bunch of other things and do a broader if you want to call it that. And so, yeah, just having the raw data in a place where you can search it, it's a start, but it definitely doesn't cover everything you'd want to do. So ⁓ I'm to think of it in terms of ⁓ a scale ⁓ of well, it's a sliding scale, but it's made up of discrete operations. Like which specific things can you do with this knowledge base? It gets more useful as you enable ⁓ other functionality. And this thing we call curation. A lot of it is making it so that can look in one place and be confident that that's the right answer without having to look in a lot of other places. Ido Bronstein: Yeah, so in the end, everything come back to trust. When I'm getting piece of knowledge, how much can I trust it before I need to further investigate and like learn things? ⁓ we a bit touch on that, but let's do that like in a more like orderly way. How do you see companies today manage their knowledge bases? Abe: Yeah, I strongly agree on that. Not. I mean, every CIO has an information strategy, like a technology strategy and a knowledge management strategy. One of the things I think is really interesting is those are still largely separate in most places. I think forward thinking organizations are starting to really engage with the idea of how do we, like, we've been storing stuff for a long time. How do we start curating that now? But Yeah, one of the reasons why I don't love the term context graph is I it implies that the problem is a strictly technical problem. And I think a lot of it comes down to how is it going to be used? Who's going to be looking at it? When are they going to need it? And unless know those things, it's very hard to design a knowledge base that works really effectively. ⁓ You can the storage layer and some parts of the query layer for it. ⁓ But You know, I guess one microcosm of this is the whole semantic layers discussion that's going on in data teams. Like your semantic layer is fundamentally a business problem. The hard part is getting buy from around the organization. There's also a technical phase to it, but ⁓ unless you can get people to agree on what's a useful definition, it doesn't matter how good your query is. Ido Bronstein: Yeah, interesting. Abe: interviewing me, but I would love to turn it around because you're saying interesting stuff there, too. Are you seeing something different what I'm describing? Ido Bronstein: So I think it's evolving. So today when you are not looking on knowledge bases, the traditional company look on unstructured and structured data separately. So you have all the unstructured data that company put it under some kind of a search. Usually it can be Glean or all the Gemini tools in a G Suite. And it's really not curated. And people are trusting agents that will give them the right information when they need. And there is a need, as you said, to double check and validate that this is the right info. Sometimes it works, sometimes it doesn't work. For sure, it's not something that you can act upon that automatically. ⁓ structure side of things, I think that semantic layer ⁓ really catching for the first time because suddenly is a ⁓ broader opportunity here because right now, semantic layer is not only for analysts. Now every user in the ⁓ organization open. a Claude cowork talk with the data. So in that manner, in the first time semantic a broader meaning. So the buy-in to manage that properly is So I think this is why now is really starting to be implemented. And the thing that I see in that manner that the tools that we have now, Claude Abe: Mm-hmm. Ido Bronstein: codecs, cursor, really help us to incorporate this semantic or context or knowledge, I don't know. We need to decide on a name an industry, I think. Abe: as long as it's not context graphs. Ido Bronstein: And I think that the ability to create skills and really put all the context that I have in a markdown file. this market is really usable. It's something magical that really help us to federate our ability to create and collect this context from all around the organization. So I will say shortly what I'm seeing right now. above your unstructured data, semantically start get traction and people starting to use skills. Abe: Mm-hmm. Ido Bronstein: as knowledge collector all around the business. Abe: Yeah. Yeah. riffing on that for a minute. The you're laying out the landscape makes a lot of sense to me. ⁓ And think what I'm pointing at is even once you have search on the unstructured stuff, there's so much more you could do with it if you did curation. ⁓ And just kind fascinated by the technical problems and the problems, like the human social problems of how do get that curation done? So anyway, a lot of what I was saying I think would fall into that bucket. on the other side, kind of an analogy. if you ⁓ to folks software engineering, like really pushing hard on agentic engineering, ⁓ everybody's talking the bottleneck around review now, right? And how previously writing the code was the slow part and then review, like ⁓ you needed review promptly, but like that wasn't the issue. ⁓ Now that can just pour out lines and lines and lines of code and they're often correct or mostly correct, suddenly review is the bottleneck, right? And there's a whole industry growing up with people trying to solve that. The way you describe kind of the value of the semantic layer strikes me as being sort of the same problem in reverse, but it's less of a problem. like if you go back five years, 10 years, people talked about data democratization in organizations forever. And basically the issue was analysts were the bottleneck. you had to have kind of somebody to translate between the business need and ⁓ how to actually query the database. And that really constrained how much you could get out of your data systems. now agents are getting good enough that that bottleneck is being relieved. And so ⁓ whole notion of like fully democratized data access, it does not, ⁓ there's real challenges to it, but it doesn't feel like a pipe dream to me anymore. So anyway, I Ido Bronstein: Yeah. Abe: see this analogy to ⁓ basically the constraints in the system have shifted strongly. In one place, it's making review the bottleneck. In place, it's meaning the analysts are no longer the bottleneck. Just, yeah, just like really interesting. Ido Bronstein: Yeah I think the new bottleneck is again, like structuring this knowledge, so everything will be grounded. Abe: totally. Yeah. Yeah. Yeah. Cause like ⁓ reason why a lot of previous data democratization efforts fell down ⁓ if everybody could just kind of hit Looker ⁓ ⁓ you know, Metabase or whatever people were using. It was very predictable. Like you, you open the tools up, you let everybody use them. And then about three to six months later, you would have nine different definitions of churn and endless arguments about like, how do we actually define our metrics as an organization? Ido Bronstein: Yeah. Abe: But now, like the metric definition part, wouldn't say it's a solved problem. It's a solvable problem. If you build the right infrastructure, ⁓ right skills, the right ⁓ you can solve it. Ido Bronstein: Exactly. Exactly. I totally agree. And I think this in that manner, I like really enable us to dream farther and really believe in this data organization idea. So I think it's connected me very good to the next question how ⁓ you think the need to knowledge base affect traditional data team? And ⁓ reasons that I'm asking before in the past data team, was focused on structured data, raw data pipelines, get expectation tests, models. But now there is this new notion of knowledge. This is unrelated at all to the classic data pipeline. But when you are looking at that from an organizational perspective, the data team is the ones that, in my opinion at least, needs to be in charge of this knowledge. because like he is the central place that collect all the different raw data that you need to curated in order to create this knowledge base. So where do you see those data team in the future? Abe: I agree with your vision of what data teams should be doing. I think it be a struggle for a lot of teams. The reason I think a of data people have defined themselves in terms of their technical skill set. ⁓ Like, ⁓ I'm good writing SQL, ⁓ or I know to a regression analysis, or maybe I'm good at pipelines in Spark or something like that. And those technical skills... I don't think they are completely commoditized yet, but ⁓ AI is definitely making a lot of them a lot faster and easier. And I think there's always been a split between data teams that define themselves ⁓ in terms of their technical prowess or in terms of their value to the business. And I think now it's kind of becoming an existential thing. You've got to justify the value of the team to the business. And you can be the trusted team within the business that helps helps people get out like solvent, the gnarly complicated organizational alignment questions of agreeing on definitions and, yeah, kind of like building that information architecture together. ⁓ Then can be hugely, hugely valuable because suddenly agents are your consumers and, you know, you're playing a really important, valuable role, ⁓ but yeah, think it's a mixed bag. I think, some executive teams have just not been willing to let data teams play that role. and I think there are a lot of data teams that have not thought of their role in those terms. I basically it's time to like step up and think of yourself as kind of a crucial player ⁓ within the organization and the technical side, like it remains important, but it's a means that end. It's not, it's not the primary reason that you exist. Ido Bronstein: Yeah. Yeah. And first of all, super interesting. And I think that we are continuing the line from, you and I talk on this with Shachar in our episode, between like the days like the data engineers was DBAs, they need to think indexes and storage to the point that they thought on more abstract models and DBT objects. Abe: Mm-hmm. Ido Bronstein: And ⁓ that like over this, I think 20 years, the technology part just shrink ⁓ and the size just got bigger and bigger. And right now we are going to see the extreme of that. And it's happening to data engineers. It's also happening with the software engineers. Like it's happening to all the industries that the technical part is not the bottom leg most of the time anymore. So. Abe: I think that's right. Yeah. Ido Bronstein: Yeah. So I think this is very interesting perspective to think about the new age data team the judge of the organization. This is basically how I infer what you said, like needs to get into between different people, different team, different department on what right what is ⁓ not right. And encapsulate that in knowledge base. ⁓ Abe: Yeah, it's a little bit like the role that finance teams play in many organizations where they become kind of like the auditor and the arbiter and the kind of like final deciders of like what's really worth investment. And I think there are good things and bad things about it, but at the end of the day, most organizations, ⁓ organizations especially, ⁓ something centralized like that. Ido Bronstein: Okay. Mm-hmm. Abe: think most CFOs orgs are not equipped to do what we're talking about. I think there's a much deeper layer of like really, really understanding how the product works, how the service is delivered that I think data teams are better positioned for. But yeah, at the end of the day, I think it does end up being that like kind of auditing role you described. Ido Bronstein: Yeah. Yeah, I agree. But to be honest, think that the technology is still not there yet. I think that the technology part needs to be a bit more abstract. Like today data teams still needs a lot of technical skills. They need to know the... And there is a lot of bottlenecks in this autonomous data engineer concept. Abe: Right. Like we're not fully there yet. But I think I flipped in the last two years of thinking, ⁓ we're to plateau and it's going be a long time before you have agents kind of performing anything close to whole human roles. Like it's going take years to get there. It's not going to happen right away. But I think the writing's on the wall. think ⁓ agents are going to be able to perform a lot of the technical work within the next few years. So, you know, ⁓ It does like, you still have to write SQL today. You still have to commit stuff and push code. But, you know, I'm planning for a future where most of that is delegated to agents. And it's this higher level of thinking and reasoning and consensus building within an organization that becomes the valuable skillset. Ido Bronstein: So for me, I feel very comfortable with that. I think that the technology is... really evolving super fast. Everybody is amazed on where it is today. But it is interesting to see how it really ends up for those teams. as you said, the teams that will succeed to elaborate, dispatch themselves from the technical identity and transition to more business oriented thinking are the ones that are going to really Stay and affect the business. Abe: Yeah, well, and I think thing that I wouldn't want to lose there is I think that the technical thinking gives you a rigor of being able to take apart problems and kind of build logically coherent arguments that like it's not like that's unique to software people or unique to data people, but ⁓ that technical work really flexes the muscle and teaches you certain patterns. And so, ⁓ know, even if that's not writing code, even if that's surfacing in Ido Bronstein: Yeah. Abe: How do you think about how to build the right metrics? Or how do you think about which teams to get on board when? I think that skill set is still useful. It's more of a, I'm blanking on the word, but like a very technical, what is the word I'm looking for? Ido Bronstein: Yeah. ask me that. This is ⁓ my expertise to be honest ⁓ critical thinking ⁓ Abe: Yeah, unfair question. Critical thinking, that's what I was going to say. Yeah, like really well-grounded critical thinking. I think data people tend to be very good at that. I think that'll be valuable. It's just going to be expressed in different ways over time. Ido Bronstein: Yes. Yeah. last question for our podcast today. What be the effect of the business? This is what matters like knowledge base is not interesting. What is interesting is how it's going to affect and change how our business is operated. Abe: Yeah, I think the prize here is getting to a place where humans and agents can really successfully collaborate. And is the I could just nerd out about forever because like, think human collaboration is, it's more art than science right now. It's not like, it's very hard replicate a good collaborative culture. Ido Bronstein: Love that, love that. Abe: Yeah, it's very hard to like really, really zero in on what makes it work. There's this like specific type of very human chemistry. now we've got this new type of intelligence that has different strengths and different weaknesses and can scale up infinitely as long as you can pay for the tokens ⁓ and can much, much faster in certain places. But it's also totally idiotic at some things that are ⁓ obvious people most of the time. like we understand collaboration among humans. And now we're mixing in this new type of intelligence and you've got to get it to perform well. think the organizations that figure that out are going to live on a totally different plane than the other ones. And I just can't see any way where that would work without something like a really well-functioning, well-curated knowledge base. But exactly what that means, I think, is still, you know, we're unpacking it right now. Ido Bronstein: I love this analogy, I have to say, to think about your knowledge base as your organizational culture, because this is like organizational culture, how you think between different people that work on different tasks. So, and this common ground between those people are the culture. And this is exactly the things that we try to get in this knowledge base. what the state of the organization. that is the aggregated knowledge of each one of the operators in this organization. So I will be careful to say that we will see that an organization with good culture is going to create, it's going to mirror to good knowledge base that will really help them to use their own human to human culture in their human to agent interaction. Abe: I think that's right. like, well, to take it a step farther, like, just because you have a really good culture now doesn't mean that it's going to be adaptive for the world to come. like, in general, I'd much rather be building from a good culture than a bad culture. But I just don't see any possible world where we introduce a whole new kind of intelligence to our organizations. And it doesn't change the like organizational laws of physics that make things work. So like, Ido Bronstein: Mm-hmm. Mm-hmm. Abe: There are teams running experiments on things like, can you superpower an engineering manager so they can now manage 30 people instead of ⁓ or six or eight or whatever was the rule of thumb before? Maybe that'll completely fall on its face. But if it turns out that that works and you can have flatter organizations because of it, like, okay, the law of the physics just changed. Ido Bronstein: Yeah. Yeah. Abe: yeah, I think good culture will breed good ⁓ evolution in culture. but it's gonna have to evolve. Ido Bronstein: what I meant. Yeah. Yeah. ⁓ Maybe I think that like good, like in the future, good culture means good knowledge base because it's mirror one another in a sense. ⁓ Abe: Yeah. I mean, one level that I really strongly agree on is I think a good knowledge base is going to make culture legible, right? In the past, culture was basically like it's almost entirely invisible to people outside a company and even to like managers or people working within the culture. At best, you could kind of see what your team was doing and maybe, you know, one layer up, one layer down your neighbors in the organization. But like as a whole, the culture is mostly this invisible thing happening around you. all of sudden, you know, our skill files, like you can diff skill files. And I don't think we're at this stage of practice yet, but I think we're going to get to the point where we start to be able to measure those and say like, some of these are better than others. Right. of the organizational habits that we have, like ⁓ they're just different. Like they, they are more performative. Ido Bronstein: Abe. A quick takeaway from my side at least, and I'm sure that the audience will love to comment their own takeaways. First of all, the knowledge base is the foundations for the new evolution of AI. ⁓ Without it, it's garbage garbage out. You cannot really leverage the model. without it So my takeaway from this ⁓ episode, first all, a knowledge base is the base for the new evolution of businesses when they want to leverage AI without that garbage in garbage out. Secondly, it's going to affect each person in the organization, especially on the data team that will shift their role from technical role to more judge inside organization that will decide what is right and what is not right. And lastly, we can think about the knowledge base as the enabler to agent human interaction. this one thing that synchronize all the organization and let it in an autonomous way. This is what I take. Thank you so much Abe for being here. Abe: Yeah, thanks, Ido This has been an awesome conversation. Ido Bronstein: Alright that is a wrap. So again, huge thanks to Abe for bringing the insight and keeping it real. If you enjoy this, follow the Data Splash podcast. We have got a lot more coming your way. Until next time, keep your data flowing and we will see you in the next stream.