Powering AI with Connected Data with Stephen Chin – KubeCon Europe 2025
Graph technologies are essential for managing complex data relationships in AI applications. Quality data is crucial for large language models to prevent inaccuracies. Biases in training data affect LLM reliability, making accurate data management vital for enterprise applications. Companies like Klarna showcase the power of connected data systems. As AI integration grows, developers must adapt to dynamic environments, with cloud native technologies ensuring scalability for AI workloads.
Transcript
This is Textron tv. Hey everybody. We're back at CubeCon Cloud Native Con and we're here with Steven Chin, who's vice president of developer relations for Neo four J.
And we're gonna be talking about graph technologies and graph databases. Steven, welcome to show. Thanks.
Awesome to be here at Q Con. I think this is a huge conference this year. It's crazy.
It's just 13,000 of our closest friends. It's all good. I'm, you know, I think at least that graph technologies and are kind of the unsung heroes of this movement into ai, because I, all this data needs to be kind of tracked and managed, and the relationships between all of that is, um, difficult to keep it all together.
So are people discovering graph technologies more these days? And, and when do I finally encounter them? Yeah, so like, I think when you look at LMS and, and gene AI technology, it's, it's only as good as the data which backs it.
So, um, the models are, are getting better and, and more powerful. But if they don't have the right data, if they're not grounded in like, like facts and you, they can't see the connections between data. They'll give hallucinations, they'll give answers which are not factually correct, especially for business use cases.
This is a big problem and graphs are a great way of solving this problem because they're a connected form of data that, you know, humans like, like we can actually look at, we can understand and we can evaluate the correctness of it. So it's a, it's a really powerful tool. And there's a, actually a lot of good research, um, which has shown that graph databases provide higher accuracy of LLMs when you pair it together in knowledge graph plus an lm and also they allow you to explain the results that are coming back.
So if you getting results from your lm, now you can figure out it, it came from this cluster of nodes, like this is where the information source was for this data. And then you can evaluate whether it's a, a good response, whether it's actually factually correct or whether the m is extrapolating. 'cause it's, it's missing that critical information.
And I'm not sure that everybody kind of gets this, but the LLMs are probabilistic in the sense that they're giving you a best guess based on the data that they're exposed to. So the better the data, the better the guess. Yeah.
Yeah. And actually, I mean, this was much more prevalent with the early models, but they're prone to have biases in the data. I mean, they're, they're trained off us, and, you know, humans are imperfect.
We have a lot of biases. The, the ability of the, the, um, folks building large language models to tune biases out is limited to the complexity. The more complex the question and the problem, the, the more prevalent biases are in, in the resulting answers.
So it becomes a, a big problem. You're building particularly enterprise applications, right, where you, you have large enterprise knowledge bases, you're, you're pulling them into a, a rag system, like a retrieval augmented generation system to pair that with an lm and you wanna make sure, like if it's a customer service application, you're giving factual correct information back to an end user. If it's a pharmaceutical information, like, um, use case, you're giving the correct drug information or the correct product information back to people.
And these are mission critical services where you, you can't afford to have the LM like guess about what the right answer would be. Right. And I think a lot of people don't always appreciate the simple fact about enterprise applications is they need to be more deterministic.
Right? I gotta do the same thing the same way a hundred percent of the time. And if I have some random guess, you know, Murphy's Law will say that if I'm wrong 3% of the time it will be with the most important, the Most critical.
Yeah. And I think one of the other big benefits of pulling data into a connected graph, and, um, c Klarna is a great use case for this. They just had a, a big announcement about their, um, Kiki, um, internal system that they use for all of their, um, integration of different data from sales, from customers, from hr, and they integrate this all together into an assistant.
And basically they're, they're using NEO four J as the connected graph backing all of this information, and then they're exposing a, a chatbot and an interface, which is now used by 85% of their employees. Um, now when the, um, CEO first came came out about this, he, he joked about the fact that, you know, Salesforce was going away and SAS apps were dead. Um, he, he, he later, but went back and said, well, okay, Salesforce isn't going going away anytime soon.
But it's true that the, the way we think about connected data in large application, large enterprise is going to change. Because if your application is only, um, has a limited view, it can only see employee data, it can only see supply chain data, it can only see maybe customer information, then the ability for it to give back really good responses that are relevant to the business and in context won't happen unless you have the all of that data across your organization connected. And that's really only possible if you, if you have a connected database, a connected graph that's backing your LM application.
Yeah. And we're hearing a lot about AI agents and as I think about that whole workflow, so I'm gonna have an AI agent that's trained in a specialist in a certain task that is associated with a data set that agent's gonna have to, at some point advertise what it knows mm-hmm. To somebody else, other agents out that are out there.
And the thing that's gonna connect those two things to let them know what they do to each other is a graph. Yeah. Yeah.
Actually, another great use case for graphs and gen AI is as the memory for agents. So it serves as a good, um, structured memory for LMS to, to aggregate what they know, what questions they've answered, what sort of information they've collected, and then to use that as an interface to other agents in a system. So we're seeing not only retrieval from graphs where, where you have knowledge stored in, in large graph repositories, but also the LMS themselves using graphs as a, a form of memory and communication in agentic frameworks.
And that's really exciting because, you know, if you wanna, for example, like, like automate and replace a variety of SaaS applications, the way you'll do it architecturally gen AI is you'll have a, a reasoning agent, which will then communicate with a bunch of other agents which have domain specific information and it'll ask the appropriate agents to get the information it needs to fulfill the request from the end user. Yeah. One of the things I've kind of discovered at this show is that, um, the way we code is changing because we're gonna build these applications where the code and the data are much more tightly intertwined and the data's changing constantly.
Um, are developers kinda ready for this? 'cause it seems like I have to wrap my head around a whole different way of thinking about building software. Yeah, no, no.
I mean, I think a lot's changed in like how we develop software in the AI world. So, um, it used to be like you're, you have an application, it's deterministic, so you know exactly what results are gonna be provided from it. And then you, you know, you package and you deploy it using, you know, helm and containers and then you go to production.
Now with, um, lms, you additionally have like a large trained data set, which is evolving, and you need to be able to, um, manage that and version that and then have that be part of your deployment workflow. So like you, you have a tested version of your data, which the LMS are using, which then will get deployed, and then you're evolving that and updating that. And it creates like, like a whole different challenge in how you use cloud native platforms to deploy and run applications and even going like upstream to developers.
Now, most developers, well most good developers are using LLMs and copilot and, um, gen AI tools to, to build their applications, right? So even the, the code that you're writing is partially being generated and augmented by LLM. So the, the way we're doing application development has even changed drastically.
You and I have been kicking around this conference for a long time, many years, and we've all been watching this Kubernetes thing evolve. Have we kind of like finally hit upon what I might call the killer app for cloud native in the form of ai? Because it seems like all that stuff is built on Kubernetes and containers and now we have graphs and it finally feels like that primordial soup of stuff has got a use case.
Yeah, yeah, yeah. I think that at the, the scale for like the amount of, of GPUs, the amount of processing, the, the scale you need to drive and, and run effective AI workloads, um, cloud native technologies are the only answer, right? So if you're, if you're deploying at that scale, you need to containerize things, you need it reproducible, you need, um, artifact repositories where you're storing all of your models, storing all of your applications.
And, you know, when you get to the deployment side of ai, there is no area which is more well researched and well understood and well studied then kind of the, the cloud native workflow for how you build and deploy things on cloud providers using Kubernetes and cloud native technology. So I think that's also where gen AI is converging. And as we have more open models where you can also deploy and run your own models on your own private cloud or your own infrastructure, then you can have even self-contained AI applications where they're all of your data, all of your models are contained inside of your, um, firewall.
What is your best advice then to folks as they kind of look at all this? 'cause I know we have some pretty well-defined workflows for Cloud native, but the number of platforms and the number of things that I gotta manage can be overwhelming. So how do I kind of wrap my head around this?
Yeah, so I mean, I think especially as we're looking towards kind of an agent future for, for how LMS and how different applications are, um, working. If you're not heavily in a heavily constrained industry like, you know, government or something where you, you really have to have all of your data and assets behind the, um, the security perimeter, the, I think the optimal approach is going to be agents talking to other agents for different companies and businesses and providing the, the best results in kind of this converged, um, AI cloud infrastructure. So, um, a lot of startups now, they're, they're building agents for specific purposes.
They're building agent platforms. Um, a lot of these are backed by graph technologies 'cause it's a natural fit for how you build agents. And, um, it provides a seamless architecture where you can build and develop one part of a bigger application stack and fit it into a, a larger agent X reasoning system.
All right. Hey folks, you heard it here. It's gonna be complex.
There's a lot of moving parts, but if you want to preserve your sanity, get yourself a graph. Steven, thanks for being on the show. Thank you.
All right folks, we'll be back in a minute.