AI on Your Lakehouse: Context Comes in Shapes, Not Queries — Zach Blumenfeld, Neo4j

Hello everyone, welcome today to Get Started on AIE. Um, soright here there's some steps for getting started; I went over this around 10 minutes ago. But basically, our workshop that we're going to take today is driven by a website called Graph Academy, and if you go to that first QR code there to the left, that'll take you there.

You have to enroll with your email, and then if you go down to "Set up your environment," there's a Codespaces there with everything set up, and you can get that rolling now. It'll take maybe about 5 minutes or so, and you can grab your credentials then as well.

There's an Anthropic API key; if you have your own Claude Code key or your own subscription, please feel free to use that, otherwise we provided one for you. And then there's another key there for reading from BigQuery tables.

So with that in mind, we'll go ahead and get started with "AI on your lakehouse," which is about context coming in shapes and not necessarily queries. So today your team will be myself. My name is Zach Blumenfeld, I am an AI research engineer at Neo4j.

We also have Ben Squire over there in the back, who is our Senior Developer Advocate, as well as Ryan here in the center, who is our Partner Architect helping customers get this stuff up and running. So as you have questions, I don't have a mic set up for you, but go ahead and raise your hand.

I'll sort of, I'll take time around every 10, 15 minutes during natural breaks, and I can take some questions, but also flag Ben and Ryan as well if you're going through some steps and you're having some trouble setting things up, and they can help get you unblocked.

So what we're going to talk about today is really about when you start using a lakehouse,right? There's sort of two sides, obviously. There's a warehouse, which is your structured data and your tables, and then there's the data lake part, which is all of your unstructured documents.

And oftentimes what can happen is you're given these tools like Text2SQL and vector search, and nowadays we don't really have trouble accessing that data, but sometimes there's still some challenges around how do you give your agent theright type of context, whether or not they can see all the data in the way that they need, and really take a slice to answer theright type of question.

And so what we've put together today inside of our course is an agnostic data model that basically creates a graph representation both from the structured side, your warehouse, but then also provides structure for some of your documents, and then allows you to do a lot of useful stuff with that.

We do have a scenario here that we're going to go over. We've created a fictional auto fix group, which is, think of it like a Pep Boys Auto or something. It's a national auto repair chain, and they have all of these bays, they have these libraries of manuals on vehicles, as well as safety bulletins and recalls, and then a warehouse of all of the repairs that they've logged.

And you have sort of your floor technicians,right? These are the Dannies that are listed here, where they have the cars inside of the bay, and they're going to need to ask some questions. You have leadership at this organization that wants to create a co-pilot to be able to assist these technicians on the floor, and then obviously you have people like Sam, who are us, the AI engineers who actually have to build the thing.

And so if they already have their data in a warehouse, what we're going to be looking at today is the example on BigQuery. So imagine,right, you have your documents inside of cloud storage, and then you have BigQuery as your data warehouse, but these patterns are also extendable to Databricks as well as Snowflake.

And essentially, if they just create a co-pilot on top of BigQuery and the data that they have, it can pull the data correctly, but sometimes it can be confidently wrong. Basically, it can get, it can pull stuff with vector search from documents, and it can do Text2SQL on just a few tables, but when those tables become massive and you get hundreds of tables, or when you have large document stores where you have hundreds and thousands and millions of documents, things can get lost and fall through the cracks.

And really where Graph can come in to help with these shapes is not only in these single questions that someone might have about how, you know, I have a broken part that I need to replace and how do I repair this vehicle, but oftentimes it's going to be on these estate-level questions.

So things like, for example, what are we missing? Like what documentation maybe don't we not have to cover all of the different cars that are coming in, or what documentation maybe are we not leveraging at all. So this is sort of like proving a negative, which can be very hard with something like semantic search, which can only match similar things,right?

It can't really find a negative example. There's also questions that we have where we want patterns across everything. So say, you know, you might want to ask, well, you know, what are, you know, the common types of patterns that we see?

Is there anything that we're failing to fix over and over again, or, you know, are there, you know, specific groupings of different types of recalls that are popping up and things of this nature where you really need to traverse the entire dataset.

And then the other one is just asking how records relate inside of a large SQL store, and when you have one big lookalike schema where you have lots of similar tables, how do you understand how to join those together correctly.

And so there's going to be three concrete shapes that we'll introduce you to today. So the first one we're going to call table of contents, and it's somewhat like a tree structure, but with also different types of links between them.

You'll see how it works. This is going to be used on the unstructured data. On the unstructured data side as well, we have something called themes, and what themes does is it surfaces global patterns inside of your data that might not be apparent or you might not know about beforehand.

So uncovering unknown patterns and groupings. And then the third one, which when we take the course we're actually going to go over first, is this connection shape, which is essentially a semantic layer on top of your data warehouse.

And so how many people, just a show of hands here, are familiar with like Graph and Graph RAG? Okay, so a fair number of you then. How many people in here have used Neo4j before?

Okay, also like maybe 30, 40 percent, something like that. So this room seems like, you know, fairly familiar with Graph basics, but I'll go over it just here really quick. So Neo4j, we're a graph intelligence platform. We have a graph database at the heart of it,right?

And basically when we talk about what a graph is, we're talking about it from a property graph data model perspective. And so everything inside of our database and our analytics platform is modeled to these three different types of elements, which is nodes that represent people, places, and things, relationships which are the verbs or associations between those things.

So like person owns car, person drives car, person is related to other person. And then we have properties that go on these both the relationships, or sometimes we'll call those edges, and the nodes, which are sometimes called vertices.

And those can be anything from strings, they can be numbers, they can be dates, they can be vectors, all sorts of things. And so the basic idea with a graph,right, is as you start adding data to it, it's almost like a bunch of pre-joined tables and everything's already interconnected and you can hop between all the nodes very easily, and that provides a ton of benefits that we'll see later in the course.

So with that in mind, why don't you go ahead and get started and go over into these. If you haven't heard before, and I'll actually just show you here really quick, inside of the workshop lakehouse, I have it open here.

I should probably restart this guy really quick. Start my code base. But basically, it should take you to this page. This shouldn't, wouldn't say continue course for you. If it's your first time going to it, it would say enroll to take the course.

So you have to go through that path to enroll to take the course. And then basically the whole thing from here on out is just going to be me guiding you through this course and kind of showing you all the different things that we can do.

There's about 17 lessons in here. We've broken it up by the different shapes. But basically, if you go into the course,

you can kind of click through here. I go over the scenario a little bit, but while I'll do that, I think what you should do is jump to this environment section. So basically, you go down to the bottom here, you go to your environment,

and from here you can say open code space. And in fact, I will open a new code space here just so that I can walk through it live with you as well.

Yeah, of course.

Go back to here.

Why don't you all go ahead and capture that?

Yes, so it'll create a code space in your own GitHub. If you want, there's a link to the repository. You could run it locally. Just keep in mind that we've set it up so that it will auto start in the code space.

So there's another Bash script that you can run to run it locally, and it will set everything up for you. But it depends a little bit on your local environment. You have to make sure you have Claude Code installed and all these sorts of things.

So we'd recommend that you use the code space one if you're comfortable doing it locally. I've run it locally all the time before too.

Allright.

Everyone's copied the QR code?

I'll give it another 10 seconds or so, and then I'll move back over.

Yep, Ben and Ryan can help you out if you don't have this one.

Okay. So when you start up as well, there's some workshop credentials here. I'll be blasting these keys after the course. I'll leave them up for just a little bit. But basically, give it some time to start up. Once it does, what you'll do is you'll go into your environment file here, and maybe I can make this just a little bit bigger so it's easier to see.

You will place your Anthropic key in here as well as the BigQuery key. The other thing that you're going to want to place in, if you go back to the course,

is down here it should give you

a Neo4j credential. So this is accessing our graph database. They've been all pre-provisioned, so it's going to be different for each one of you. You're going to have a different one. So copy the one from your screen, and you're going to put it inside of this environment file as well.

And it will take a while, like you see with mine, the environment file hasn't quite popped up yet. So it can take a few minutes for that all to go through.

So we'll give that a little bit of time to start up. Hopefully it won't take too long here.

While that's running, I'll give a little bit of an overview here of what we're going to do in the next step. So basically, once we get this set up and we get Claude up and running, we're going to walk through the first shape for our day, which is this connection semantic layer shape.

And then after that, we'll follow it with the table of contents one that we were talking about and the communities one. So we'll be working with the structured data first and then moving into the unstructured bits.

Once, for those of you who do have it loaded, basically you have your terminal down here. You can go ahead and call Claude. We'll be working through Claude Code as our agent.

The internet is a little bit slow too, which is expected.

As you go through with this as well, I should, oh, here we go. We'll set up.

Show you what this looks like here in a second. The Anthropic key, as well as

BigQuery one.

Allright, perfect.

And if it does this where it's trying to get you to do a subscription, basically what you do is you'll go plus, open up a new terminal window, and then it should here give you the option to select the Anthropic key.

Just go through and press enter, yes. And then you want to use the MCP server here. So you're going to select yes, and I'm going to skip the tour. And then I can ask

that question just to make sure it can connect to Neo4j.

And for me, I already have some nodes in because I'm working with a graph that's been cached already from my previous course.

For you, it will come up as an empty sandbox. So one thing that I want to note here too in terms of how we're going to be working with Neo4j and with Cypher, which is our Graph Query language, I think we've come to a point now where a lot of us aren't hand typing our own code line by line anymore.

We're using agents to help us build things, obviously. And so in this workshop, it's going to be the same thing. Basically, we're going to be using something called the Neo4j CLI, which is a CLI tool that will allow your agent to run queries directly against the database.

When I was working inside of Claude, you saw it running there for a second. And that also ships with a Neo4j Cypher skill that allows the agent to sort of leverage how to put queries together in the most modern way, as well as something called a GDS skill, which stands for Graph Data Science, and we'll use that for some of the algorithms when we get to the theme section in terms of just helping us do agentic coding.

So I'm not going to have you guys handwrite really any Cypher query code. I'm going to show you throughout this workshop how to use an agent to help you write that with specs that are created. And hopefully that'll be useful for you more on the day-to-day if you ever decide to use Cypher, whether it be with Neo4j or not.

So how is everybody doing now? I'll take a second here to stop. Go ahead and raise your hand if you have any questions here. Or are we all good? I have one question over there.

Can

I just point that?

Yeah, so the question is, can I use Cursor? And so the answer to that is you should be able to, yes. I haven't personally tested it, but if you go up to the top, there should be a link to the repository that we're using.

If not, when you go to open code, yeah, you can clone the repository here. So if you follow that link, you could clone it. You can get it locally. And then you'll see here there's directions. There's a shell file that you can run that will set everything up.

You can take a look at what's in there. It's a bunch of basic stuff. Okay, awesome. Yeah, and just a little bit about the structure of this thing I forgot to mention. There's a lot of stuff inside of the

workspace here. Obviously, inside of .claud, we have our skills file. So I've gone ahead and pre-written a skill here that covers basically a lot of what we're going to do. Inside of here as well, there's a file called outline and search and theme.

So these are going to be the shapes that we'll be working with. To query BigQuery, there's just a very small, well, that's actually a database query file, but the run sequel on this one for querying BigQuery, just a very simple, basically way of reaching out to BigQuery and just calling it

with a simple SQL command. And inside of these files, as we'll see later, there's places to fill in a spec. So that's going to be where we do some of our agentic coding. But everything in here, if you wanted to load this into BigQuery yourself, there's something for that.

If you want to go ahead and run this on Databricks, there's directions here to load it into Databricks and use Genie and AI search there if you want to compare.

And then this is just a SIM link over back to the .claud files. There's solution scripts as well. So if you get stuck, for example, where for some reason the coding agent can't create theright query, you can copy stuff from there.

And then all of the source data too for creating both the structured and unstructured data is in here, including our PDF sources. So if you go in here, we have our bulletins and our manuals and everything. This is showing you the raw PDF, but if I go to the corpus, which is the Markdown version, you'd be able to actually read the contents inside of them.

So anyway, with all of that, we'll go ahead and hop along to our first section here, which is going to be connections.

So we have basically our data inside of BigQueryright now. And in fact, if I go back to my overview just to show you what it looks like really quick, this is the schema. So we've kept it very simple for this course.

Obviously, in the real world, you'd have a much bigger schema than this. But we have our work orders, which is sort of like the middle or the star of the schema. You have your vehicles, the different DTC codes, procedures, work order parts, and then the parts themselves.

And they join together in a very simple primary foreign key pattern. We'll get into our documents later in the course. It's just basically a big bucket of PDF files. And so what we want to do here is to help our agent be able to effectively join everything together.

We're going to give it a graph representation of a semantic layer. And to build that semantic layer, we're going to use something called NeoCarta. NeoCarta is a labs project. So at Neo4j, we have our core engineering, which is like our cloud SaaS platform, our graph analytics stuff, and all of that.

But we also have labs projects where we move a little bit faster. And inside of that labs project, we created this NeoCarta. And what it does is it creates a metadata graph. Also, although we're not leveraging it here, you can add business terminology and business processes and a whole bunch of other things into a graph structure.

And if you think about it, people, these words ontology and semantic layer and all these things are kind of, they're thrown around a lot lately, especially this summer. And so the basic mental paradigm that I use to kind of think through these is an ontology helps something interpret and reason about the data.

A semantic layer helps something understand what the consistent agreed-upon terms are so it can query the data accurately. And then at Neo4j, we have other things like virtual graph. There's a link in here in the course which will actually give you a sort of a federated graph view of your SQL data that you can query over directly with Cypher.

We won't be using that here, but there is sometimes value in giving sort of a graph view of the schema. But anyway, what NeoCarta will do is it will see in this next section,

it has an MCP server basically that will sort of suck all the data in

from BigQuery, just the metadata, and it will create this graph. And that's what you do in the next section. So I'll go ahead and jump to there. And I've already run this script, but basically when you see this script, what you're going to do is you're going to copy it, and then you're going to go over to here, and then you're going to bring up your terminal, which, oh, our terminal.

And then I like to just open a new window. That's not my Claude window. And you're going to allow paste, and then you're going to go ahead and run that. I've already run it, so I won't do it again, although it should be idempotent.

But basically, once you run that, it'll create

these six tables with these five reference join paths. And once you've done that, you can come back in here and even just run this to check. And it's kind of cool what it looks like. This is what it looks like inside of the graph database.

And basically what you'll see is you have this node in the middle that represents your, well, first your database and then your schema. And then if you follow that out, it'll be has table, and then you'll have your table, and then you have your columns.

And those can also optionally have these representative values on top of them.

And so these join paths, basically when the agent reads that, if I were to go down here and try. So I have a little example prompt down here, and I can go into my window and go back to Claude.

And I can ask a question like this, which vehicle received part IC 2042? And in this case, I'm going to tell it to use the MCP server and the warehouse schema and all this to go and grab everything, then use the Python script.

Inside of this skill itself, it has directions for this as well. But what you'll see it'll do, where did this?

It'll call that MCP server for NeoCarta, and it's going to read that metadata semantic layer graph that we have in Neo4j. And so if you notice, the thing that we're doing here really is we're not using the graph to copy the data over.

There's not like an ETL into graph. What we're doing is we're using the graph as a semantic layer. So we're just pulling metadata about the columns and the rows and all of these things. And we're going to use that to inform a text to SQL query.

Once it decides to go ahead and run here.

How is Claude working for everyoneright now? Are we seeing a lot of slow Claudes? Fast? Yeah, slow? Okay. Interesting.

I'll give it a little bit of time here. I don't know why it would be moving.

Huh, a little bit slow.

Does everyone have a QR code?

Yeah, does everyone have?

Yes.

Is it possible to just, for some people who are a little bit further behind, just recount how you got to here just while you're waiting?

Yeah, sure. So the question is, can I recount how I got to here while we're waiting for Claude to come along? So basically, the QR codes that are being passed around, there's two here. One of them is to enroll in the course.

So the course that I'm going through is online. It's freely available. So anyone can go. Once you show up inside of the course, basically you'll see a button here to enroll. So you have to sign in and enroll in the course.

Once you do that, you'll click through and you'll make it to this environment section. And when you do that, it'll take about five minutes or so for everything to populate and come up. If you're using CodeSpaces, you have the option to run it locally.

But then once you do that, essentially you're going to come in here and you're going to get your credentials, and you're going to grab the Anthropic API key as well as the BigQuery key here. And then once you do that, you'll be able to access all the things in the workshop, basically.

You're using, as you saw here,

oh, cool, we're actually making progress. We're using Claude code inside of CodeSpaces here.

Sorry, can you repeat that really quick?

Yes, the Neo4j sandbox

is, if I were to go back to that environment section,

you see the button here to open CodeSpace, and then you should have down here your own sandbox credentials. So it won't be these exact ones because it's different for every participant, but you'll go ahead and copy those. And then once you're in here, you'll be able to, you have your .environment file, and inside of your .environment file where you put your Anthropic and your BigQuery key, you'll also put the Neo4j ones.

If you don't see a .environment file and you see nothing or you see the .env.example, it just takes it a while to populate that. There's other things that are running. It's running another shell script to kind of create everything for you and populate all the different files.

So my hunch, and someone can scream at me if I'm wrong, is that if Anthropic's this slowright now, it's more of an Anthropic problem and not necessarily a one-person's account problem. If it continues being bad, I might try to provide another key from a different account, but I don't actually think that that's what the problem is.

I think it's.

Is it just the Wi-Fi?

Yeah. Well, yeah, but this should also be running remotely,right?

I think it's the Wi-Fi.

Is it just the Wi-Fi? Okay.

The Wi-Fi is like 8 gigabitsright now.

Yeah. Well, the funny thing is I would think, well, never mind. I don't know. It's running in CodeSpaces, but maybe CodeSpaces is still using

the local Wi-Fi.

Okay. So we're back here. Basically, what it did to grab this list is

it went through and it basically read that metadata graph, and then it created the different queries that it wanted to run. You can see it ran the small SQL Python file, and it did all of its selects and its joins to be able to pull together these tables that list out the answer to that question, essentially.

If I were to go back, the question here was, what would we ask? Go back to the connection shape.

Yeah, which vehicles received these separate parts over here. And it provided that list down here by make, apparently, and then vehicle count.

So that's the basics of this first shape. And you can imagine that as your data starts to grow and you start to get more and more tables, it's very useful to have this semantic layer to then help essentially guide how everything joins together.

In this case, it used a primary foreign key relationship inside of the information schema inside of BigQuery to enforce that. NeoCarta can also use things like query logs, or you can sort of manually put together how you want things to join with other terminology and metrics.

Are there any questions about this first sort of connections graph semantic layer shape that we're working with?

Yes, I have one over here.

I guess just the question is,

give us a little bit more context around the Neo4j and the order of the process and how it connects together.

So the question was, can you give us more context into the Neo4j near quarter, like what we're doing strategically? So what Neo4j is doing strategically and thisright here. So Neo4j as a company,right, where for a long time you've been able to import data into our database and represent things as a graph, which is very useful if you're trying to run these graph-specific queries,right?

So if you have a supply chain, for example, and you need to find an optimal route from point A to B, and you have to do these variable length, shortest path type of calculations, a graph database is very good for that.

But the other thing that a graph database is really great at doing is not just making those complicated queries run faster, but actually providing a view or a representation of the data that allows an agent to understand how tables might interrelate.

So that even though the end join, it might only be a three or four hop join, you might have had to understand hundreds of tables or something to be able to arrive at that conclusion. And so we're focused a lotright now on these concepts of ontologies and semantic layers and what we're calling virtual graph, where the focus isn't only just ETL-ing data in, but about, okay, maybe you want to keep your data where it is and you still want to use SQL and access it in the ways you have been, but you need some way to sort of guide the agent to be able to do that correctly.

So NeoCarta is a labs project. We also just recently in preview have released something called Virtual Graph, which will be similar, but it essentially gives you almost like these push-down cipher queries. So it gives you a graph schema of your database, and then it allows you to run cipher directly, which can be useful because then you sort of have the view down at the query interface level and not just at the metadata semantic layer level.

So there was a table in there in the previous section that was kind of explaining that. But hopefully that's helpful so you understand kind of where we're going with things.

Yeah, that's great. I use that in Grafiti and Bumblebee.

Yeah, yeah, Graph, and yes. And we're doing a ton of stuff inside of context graphs as well

and all of those layers. Yep. Allright, awesome. Any other questions? Okay, I have one question over here.

I guess the indication of using graph as a layer on top of the actual existing tables, is the indication that the existing layer will be transacted in? Why don't we just put that into the graph itself? Is it indicating that it's like any sort of graph or not specific to the architecture?

We're also trying to gauge the status.

Yeah, so the question is, why would we not take our OLTP data, whichright now is this warehouse of vehicle orders and stuff, and just push that into the graph,right? Or some subset of it. Why wouldn't we just push that into the graph?

Well, I think in a lot of cases that's easier said than done,right? Because if you think about a lot of production use cases, you can have terabytes of data which gets updated continuously. And so,right, if you had to put that into the graph, you would then have to find some way of syncing that while you move everything in.

And there might be a lot of extra properties or things that you might need to build a custom ETL where there's some things that you might not want in the graph. And then a lot of times what people end up not really understanding until they get in those situations is the security posture.

Because if you have sensitive data that's in one system, it might not, even though you could physically move it in, you might not actually be able to, for security reasons, take that data and just move it into another database.

So there's various reasons why you might not necessarily want to move your data over. Where you do get an advantage of the ETL over just this metadata and semantic layer graph is if you have graph queries that need that performance,right?

So like that supply chain case that I had earlier, like if you're doing these really large recursive joins and you need them to happen very quickly, or you need to run graph algorithms, maybe you need to produce graph embeddings, or you need to do some sort of clustering or something, in that case it makes a lot more sense to bring the data in.

And then as we'll see in the next sections, when your data's already unstructured, there's benefits to bringing it into a graph because then you can give it a graph structure. Allright. I saw one other question over here. Yes.

So the question is, does it rebuild the graph every time you initialize NeoCarta? And the answer to that question is no. What it will do is basically when we ran that build connection script, it went ahead and ran an MCP server function that ports the data in.

And then once it's ingested into NeoCarta, just the metadata, then that stays there. So like for me, I didn't rerun that build connections,right? Because I just took the course last night. So like for me, and I probably could have because I think it's an idempotent load, but I just didn't want to deal with it.

So it was there for me, and then I just ran the queries on top of it. Yep.

Allright, any other questions?

I have one over here at the end. Yes, yes, here.

For the SQL, for writing ciphers, just the structure of it and how you landed on that skill.

The Neo4j cipher skill?

Yeah.

So I don't know if I might be able to grab it really quick. I can show you Neo4j cipher skill.

But these are all developed internally by our team. So if you go here actually through the Neo4j client, you can download a ton of these skills. So if you see here, there's the cipher one, but then we also have the different ones for like agent memory, for cloud infrastructure, for different drivers, like if you're using Java or Go or all those things.

So I can't necessarily say exactly how we landed on this particular skill, MD, but what I will tell you is it was created by us and our internal teams who are like always up to date on the latest cipher 2526.

So it has all of the latest. So I'd encourage you to use the Neo4j client because it will basically, you can load one or multiple of these skills and you'll get the latest knowledge there. Because otherwise what it's going to do is it's going to go on the internet and get the Stack Overflow questions from like four, five, or six years ago, and it's going to give you outdated, bad cipher, basically.

Is the Neo4j CLI loaded into this?

It is, yes. It is loaded in. And if you look at the install file that we use inside of dev container, you'll see

where we installed the Neo4j agent client and the skill. So the commands in there that basically allowed you to do that.

Allrighty, I'll take one more question, and then I think I'll have to move on to the next section unless there isn't another one. Yes,right there.

What were your thoughts on using this new semantic layer on that system that's hardware and maybe doesn't have, let's say, like ROMs, URLs, and it doesn't have too much structure?

ROMs, so like the different delta tables where? So, I mean, we're exploring basically the traditional SQL structured data warehouse. And then NeoCarta is really customer-driven for us. It was made by our field team. So as customers come in and they have questions about less structured data, and even things like documents have been considered for NeoCarta.

And so there's this backlog that's formingright now. Everything's moving very fast. I think, I mean, Ryan is somewhere in the room, and he might be able to speak on sort of what's the next thing for NeoCarta. But I know we're workingright now on a Databricks connector and maybe some metric views and other things.

Allright, awesome. So meet with Ryan afterwards. And then everyone watching on YouTube, I guess, can meet with Ryan afterwards. But by then, we'll have an amazing NeoCarta. Allrighty, so let me go ahead and move on for sake of time because we're coming 15 minutes on the halfway point.

And it might be nice to take a few-minute break at some point in the middle just to give ourselves a little bit of a breather. So now I'm going to jump to the next section. So that was working with structured data, and now I want to work with unstructured data.

And this is going to be the documents part. So we have, if we go over to

our little source data stuff here. So in this case, I'm going to read them locally to load them. But it's reading from cloud storage, reading locally. There often isn't a huge difference. Basically, we have these bulletins in PDFs.

We have manuals, which are considerably longer. And then we have recalls as well. And because it's giving me this funky view, I also have them

in this raw corpus where they're inside of these Markdown files here. But basically, they're these multi-section documents. And you'll see here that they have this linking that they do to go over to different sections in other documents. So they're all kind of interlinked together as they refer to one another.

So for example,right inside of this manual, it talks about these different platform codes for this ABS system and diagnostic troubleshooting,right? And it will link over to there. All of this data, by the way, as I simulated, it's not sensitive or anything like that.

But it's meant to simulate kind of a real-world system where you have these manuals and bulletins and recalls of all these different vehicles. And what we want to accomplish with this basically is we want to give our agent a table of contents.

And by a table of contents, I mean something that looks like this thing. So what I want to allow the agent to do here is not just search for key terms. We'll give it search too. But I don't know if, has anyone heard of like page index?

Anyone know who they are? Maybe some of you. So there's this idea of navigation through your documents, where basically almost like a human, if you look at the table of contents inside of a book, and I'll call this outline, I'll call it table of contents.

I need to get the terminology a little bit better aligned. But the idea here is that you can sort of read the indentations, and you can see how you have a document, or in this case, a library. You have the bulletins, which is a subfolder, then you have these documents underneath.

And so you have this containment tree. And then in addition to that containment tree that gives you all these sections, you also have these links that'll take you to a different document. So it's more than just a table of contents.

It's a tree that goes down. It also has these links,right? And these links, and basically everything in here has a URI. And the idea is that if we can come up with a good graph representation, we can basically make it so that these URIs, which are hierarchical, so you see like you have your technical library here,right?

And then slash bulletins. So like if I'm down in this TSB recall notice, I know that it's part of bulletins, or no, safety bulletin rather, not a recall. And it's part of a technical library. Just like it's also linking to a manual here.

And you can see the name of the manual, and then it's inside of the manual subfolder. And if I have that, I can take that, and I can plug it in, and I can actually grab a node from the graph that has like the raw text or even a link to the raw text.

And then if I plug this in, and we'll see how this works with outline later, I can actually get these subtrees so I can like dig in and drill down on these different pieces of content. That's the general idea with this.

And so what this gives the agent to do is not just search, like vector search or lexical search, but actually kind of traverse through the documents in a sense.

And the data model that we're going to use, in this case, we're actually going to import the data into Graph.

I have a quick question for everyone. So everyone here knows Graph RAG. When they think of Graph RAG, and maybe someone can raise your hand, and I'll pick on someone for a second, I want you to tell me what you think like the building the graph process is for Graph RAG.

So I don't know if anyone wants to volunteer if they're familiar. You're going to raise your hand. Yes.

You find the tree class, like the building type. And then you find the architecture model, and then you find the connection to the indentation class.

Yeah, and they build the links

from the, so there's different ways,right? And you said, I think when you talk about creating a graph, you build the links from the data that's inside of the documents,right? And so Graph RAG, oftentimes we have an entity extraction piece to it as well.

So we can use an LLM to kind of say, hey, like extract the different parts, the different vehicles from the graph, and have them be separate entities, and then have those links to like the original document chunks and all of this stuff.

And that's great, and that works really well. Here, what I'm going to show you is something that's much more lightweight. And I think maybe to the point that you were making,

we're actually going to use a deterministic loading. So if you see here, the way that this graph structure is going to work is you're going to have your library, and then you're going to have this containment tree that reflects what we saw.

And all this is really doing is it's breaking down, you see the folders, the document, and then these documents have sections. And they can have multiple sections that will also nest underneath each other at different section levels. And then you'll have next section links, so you get a concept of ordering, as well as linked to, which uses, in this case, we're using these named links, sort of like you might see inside of an Obsidian vault a little bit.

But you can also do it with hyperlinking and other things depending on what your data looks like. So it's all deterministic with the containment tree for one, and then the ordering of the sections, as well as the links.

And the benefits of having a deterministic load like this is, number one, it's going to be idempotent. So like you're not relying on an LLM in the beginning. It's often going to be a little bit faster. And so if you already have documents which have a lot of inherent structure to them and a lot of interlinking, sometimes just to get something up and running quickly, it can be very beneficial to approach a graph like this where I'd say it's more of a lexical or a document structure graph rather than like a full entity extraction type of pipeline to create a graph.

And it explains here what I just said with the different link types. And like I said before, these URLs carry a hierarchy. So every node, for example, that head node at the top here for the library will get its URI.

Manuals will have that plus backslash manuals going down sort of the containment tree to the file name and then the different sections.

And this is the script you're going to copy to load it in. So basically, again, you'll take this, you'll go over to here, you'll open your bash terminal. Now, I believe I've already done this, so I'm not going to run it again, even though I'm pretty sure it's idempotent.

But basically, once you run that, what you'll end up getting is, and I'll just make sure it's actually in the graph. It is for me, you'll end up getting that model that we just saw. It should only take, well, now it might take a while if the Wi-Fi's low, although I don't think it should.

But it'll create this graph for you where you have, again, your top of the folder structure, which is our technical library, our folders, and then you can see we have our documents followed up here into our different sections.

And if I were to zoom in here, you'll see we have the has links in the next section, but then we also have the links to. And I can go in and click on these, and you can see kind of how the thing grows and everything kind of links to each other.

And now that we have that, basically in the next section, we can go ahead and build our tool, basically the script that goes along with our custom autofix skill that we've created

to actually create that outline shape that we saw in the beginning, the table of contents to hand our agent. And so if I go ahead to that next section,

and again, like I said, what I want to do here is I'm going to go ahead and copy this. This is the prompt where if I go ahead and feed that to my Claude, it should go ahead and get to work.

Nope.

And because I know that's going to take a while, I'm going to have it start running here. But basically what it's doing as it goes through

is if I go under and I look at my skills, you'll see that I left

inside of here this wired query. This is the query that it needs to create to be able to create that outline shape. And I've instructed it inside of the language here to use the Neo4j cipher skill and reference a spec in doc outline format.md.

So this is generally how I like to write more complicated cipher queries, more complicated graph queries is I'll write a spec for it. And so if I go to my docs folder, you'll see I'll have my specs in here.

And I have my outline format spec where I say this is the shape,right? And then it talks here about how it needs to be human readable. And yes, we will allow you to edit.

And some of the optional arguments it needs to have. So,right? Because oftentimes it's like pseudocode that we'll have, and we don't know exactly how to put it together.

In this case, I did give it the hint about having a variable length path query to basically put everything in order.

And then it will say when it's done. And so basically what you'll get out of that is if I go back here, and it will talk a little bit about like one of the keys to this you'll see in the file is it does this thing here, which it goes has, which is that containment edge.

And you see this star 0.25. It's actually parameterized inside of the query. So like if I go back to my, let me go to where it changed. If I go back to here, it's parameterized inside of this string.

So it gives you like an option to how deep you want to traverse. And that's sort of the graphy nature of kind of putting together this table of contents. There's a second query in here too, which is much simpler, which just grabs the links after that.

So that basically once that's done, I can go ahead and copy. I'll run the whole thing. If you just run the script without any depth parameter or without a specific URI, it's going to return everything in the graph.

So it wouldn't be the way that I'd run it with a larger graph here. We end up with, because we only have a couple hundred documents, so I can get away with it here. But if I ran that,

it'll bring back a ton that you can kind of see here.

Zoom out. So you can see,right, that it gave me this. And you can see how a lot of these documents, again, it's not just the structure, it's like the links between all of them that it's providing. And then what you can do with this,right, is you can give it an optional depth parameter.

So for example, if I just said depth equals one,

you don't like clearing

down to the bottom, and I say depth one. Then if I did that,

it'll go ahead and just go one down. And then the other cool thing with this too is you can provide it a specific URI. So if I saw a specific URI here that I wanted to give it,

then it will basically start at that Falcon 2.0 document. Just like if I was here now and say, okay, well, actually, I

want to do it, but I want to do it for something that I see up above, like maybe this links to

this coil identification thing. I can go ahead and snag that URI, and then I can put it in the script. And then it will basically give me that document and everything it links to. So you can see here how an agent can go through now and sort of grab these URIs and kind of traverse all through the graph and give itself these hierarchical and linked views.

Question?

Okay. Yeah, why don't we take a second for questions? So we have one in the middle here.

Why don't we go look at the agent responses that can actually do URI connections throughout the two or three years?

Well.

Like agents, or how do we know from the response that it's actually used to connect to?

So later in the course, in the workshop here, for some of the last questions, I do instruct the agent to say exactly what steps it followed. Are you seeing it use something different?

No, I asked a question I got the response.

Right.

How do I know that it's actually using?

Yeah. So it should be apparent in the tool call history. So you can look at the different tool calls that it made. Because in the case, for example, of connections, it's calling an MCP server. So those should be inside of your tool calls.

And the question, by the way, for everyone, if you couldn't hear, it was just how do you know that the agent's actually calling the things that it's supposed to,right? Yeah. So for Claude Code, for example, you can look at the tool call history.

And informally, what I'll do in this course is for some of the prompts, I'll just direct it to say like, hey, clearly say what steps and logic you use to be able to answer this question.

Obviously, for a production system, you would want to look at the logs and everything. But for here and for learning, that's how I'll expose it. Are there any other questions about trees, outlines?

Yes, oneright here.

Just the build process in the beginning, is that just using like an LP library or processing?

Yeah. Yeah. So

it is, all the code for that should be in, uh-oh. Yeah, we'll need to restart. Oh, that was a different code base. Thank goodness. Allright.

Yes. Inside of load, if you go to load documents,

this is just the cipher queries, and then you have your parse corpus

down here. So yeah, it's basically just using regex in here to try to find theright stuff. In this case, the documents are already fairly well structured,right? So mileage may vary depending on what your document sources are. In this case,right, if you have a lot of manuals that are often structured the same way, then you can get away with sort of regex and plain NLP techniques.

If it's messier, you might have to use like Gliner or different types of LLMs, and there's stages of complexity for that. Allright. Yes, we have a question over here.

Yes.

Does it be done with any model?

Yep. Can be done with any model. The only thing that NeoCarda and any of these tools, well, I'll start with NeoCarda. NeoCarda is really responsible for creating that semantic layer metadata graph and providing you an MCP endpoint,right? So as long as you can access that MCP server, it's model agnostic.

Okay. So that was a question about basically we're using Opus 4.8 here, and can we use any other type of model? And the answer to that question is yes. We're using a skills framework, and then for NeoCarda, we have MCP.

NeoCarda also has a CLI, so there's other ways to access it too. I have one question all the way in back there.

Is

the question around, if I'm understanding correctly, how do you decide what to name your relationships and how descriptive they have to be and who is naming the relationships? So in this case, we have a very deterministic load. So we're deciding ahead of time what to name our relationships.

And that is a bit of a taste or a judgment call,right? I tried to keep it simple here where has is very simple. It's a containment relationship. I also know that I'm going to want containment going multiple levels, so I probably want a common name for all of those.

Because if I have like has folder, has document, has section, it makes the cipher complicated. So that's sort of why I kept that naming very short. Same with links too. The more granular you get with naming, basically the more sort of detailed your agent can be and your end tools can be in putting a query together, but then the more complicated your data model becomes.

And so it's a little bit of a thing that you have to manage because if you end up in like a production scenario where you have hundreds of different types of relationships, that might get hard to manage inside of a context window, and it can lead to models maybe not having the easiest time putting those cipher queries together with something like the Neo4j CLI or humans,right, when we're trying to write our own sort of parameterized queries.

Someone non-technical might need a different structure for those relationships?

Yep. Yeah, that's true too. And we see that,right? That's the whole semantic layer argument too on the warehouse side is you can have these metrics views and other things which use business terminology that might be different from sort of the physical data model that you have,right?

And so that's part of the reason why we have these metadata graphs too to help manage that sort of difference or that delta between them. I'll take a couple more questions, and then we can move on. Yep.

Do you think that the replacement for semantic database or like how to have the hybrid approach or?

Yeah, that's an interesting question.

I think it would be naive to call it a replacement because most of the people that I see using this will eventually incorporate some sort of hybrid vector retrieval or full text search. Work I do, I use at least full text search with this sort of stuff.

So I don't think it's a replacement, but as we'll see later in the course when we get to some of the estate level questions, there's certain things that semantic search is not as great at answering that really require document navigation to understand how everything connects together,right?

So big examples would be like proving something doesn't exist, like how do you do that with semantic search,right? Or understanding even like how there might be different parts related to a specific document or something. You could in theory do like a bunch of vector queries to keep pulling passages, but there's more chance for error that you might not catch theright document and all this sort of stuff.

So yeah, the question was if it's a replacement for semantic search, and I don't think it is, no.

One more in back there.

Do you also?

So the question is, do we redefine the types of nodes as well as the relationships? And so is this a question of like how do you decide what the node labels should be? Yeah. And again, it's a data modeling question,right?

Like there could be a situation where we're looking at the data model that we just went over. Well, it's not here. It's in my last one.

When I look at the shape,

zoom out of that a little bit where it might be useful to have like an actual parts node or something,right? Here for this type of use case, I'm letting the agent kind of infer parts and extract them from the documents and then use that to go find something from the metadata graph in Query SQL or the other way around.

And that works for me. So it's still, as things evolved, like two years ago, I probably would have said you would need that like additional node. Now it seems like agents are smart enough where maybe you don't all the time anymore.

But for some use cases, especially like we see this in life sciences, for example, where there's these really specific ontologies around different types of molecules and medications and things, and you really do need that represented in the graph or else your inference isn't going to make sense.

So I hate to say it depends on use case. I don't want to be that person, but it sort of does in a sense. Allright.

Okay. Yeah. Let me move on only because we're a little bit over halfway through, and I have some more course to get through here. So

let's go to, so we went over all of this stuff. Oh, yes. So we need to build our search query. So similar to what we just did and to the question that the gentleman had over here, we want to be able to, we want to be able to build some sort of search as well to help augment this.

So this is going to be much more simple, this search file. Basically, I'm just going to use a Lucene style index, and I'm not going to use vector search here. The Neo4j itself has a Lucene full text search index.

And if you see here, it's basically doing the same thing where I have

this wire that it has to fill in, and it's going to use a cipher skill to do that. While it's running there, you're allowed to edit.

Well, we might as well wait till it's done. Allright. It's going to finish up. So basically, if you see here, the way this works is you call the full text index. It's indexed on the document and the section nodes.

So every node that has text in it, like we don't put folders through this Lucene index. And then it will give you a score. And then because we have everything in those URI format, we can also scope it by subtree, basically with like a starts with filter.

So if I was to go back into this file and I looked at the way that this query run, I can have this where statement. So I'm applying this as a post filter basically where I'm doing the full text search first, and then I am filtering it by the URI.

So I can say like only search under like this section of the manuals basically. So it just helps me refine my search a little bit with those hierarchical URIs. And the other thing that I do, and I do this because I work like in the research role that I have, I work with so many different AI models and on so many different platforms.

Like you wouldn't think about it, but like choosing and wiring like options to work with like six different vendors for vectors is kind of tough. So what I often do for this is I'll use something called semantic expansion.

And basically what it does is it instructs the AI model to say, "Hey, like use your world knowledge if someone asks for an engine shuddering that it might be a misfire or something else too." And because this is a Lucene index, I can do that.

So for example,right, I can say like misfire or rough idle, and it will search for either of those. If I go back to my Bash script and I run that now that the thing's filled it in, and then you'll see it'll give me my documents with the scoring for the different ones.

And I can also search, as I was saying before, under recall. So I can search for coils under just the recall subfolder library. So that would be the idea here. So you can see it's still leveraging that hierarchical containment shape, the tree, but it's doing it through the URI ID structure so that it doesn't have to do as much graph traversal.

It just sort of filters down to things underneath.

Allrighty. Awesome. Are there any quick questions just around the search piece there, the Lucene search? We have one question over here.

And

then

yeah, so the question

is we just loaded the documents into Lucene, and then we're searching underneath different sections.

Appropriate sections.

Yeah. So basically it might make more sense if we actually took a look at the query that we're running here. So here's the, oh, make it this big.

So here's the cipher query, and I'll create a space here so you can kind of see it better. So we have a Lucene index that we've set, and we set it when we loaded the graph. We set it on the document and the section nodes.

So every time that I call this index full text query nodes, it's going to hit the name of the index, which is content search. And then this parameter Lucene is whatever I've fed it in with that script. And so that's going to do our initial filter to just a bunch of documents and sections.

Because we've structured our IDs for every node as a URI that's hierarchical, if I know that I only want to search underneath recall notices, I can hand it that URI, and it will say only nodes whose URI starts with that thing.

So it's applying that post filter afterwards, if that makes sense.

Yeah.

Yeah. Yep.

You have a question?

Just a quick follow on. If you're creating this search script with Lucene in quote, can you just say, take a look at the data, create an index for me, and introduce like that, or do you have to go deep into the data?

So the question is if, say, you already have a graph and you haven't created your Lucene index yet, could you prompt Claude code to basically do this for you? So I think yes. To be honest, I might have done that with this course initially.

I might have actually had Claude do it. I can't remember because I've rebuilt this in a few different ways. But I think the answer to that is yes. Your mileage may vary depending on your data. A lot of times when you set up a Lucene index too, it's like especially it's very flexible inside of Neo4j.

So it's like you can set it up on top of one node or multiple nodes, multiple properties on one node, multiple properties between multiple nodes. So that flexibility can also be a little bit of an Achilles heel too when you ask an AI model to do because it might not understand all those various options.

But in general, yes, you can use agentic coding to help put this together for you.

Yes, in the middle there.

So the documents that you rebuilt, how important is it that the names of the documents are actually really relevant to the effectiveness of the agent being able to traverse it?

So the question is, how important is it that the name of the documents be accurate for the agent to traverse it effectively?

Like does the performance go down?

I think it would, yeah. If your documents weren't named very well and you had that outline view, then the agent doesn't have as much to go off of when it's trying to traverse. So it might misinterpret what a document means,right?

That's why having the search augmentation alongside of it is useful because it can actually look in the document. With these things, what I've seen, because I use this actually for my own knowledge base management, I have my own open source library that I use, which has these tools.

The biggest problem is when you have documents that are outdated or drifted,right? So I've thought about, well, maybe we need to add like a last updated date or something, or like whether or not a document should be authoritative,right?

And the document naming is actually important, and link naming as well is important too. So if you have links that don't have like a, I forget what it's called, but like in Obsidian, you can sort of name the, you can give it

a synonym or something,right, where you name the link. Like that can be very helpful if that's there,right? Because then it's like, oh, I know exactly why I'm linking out to this other thing. So that's when sometimes using like a language model inside of the ingest, if you don't have that, could be beneficial.

Yes, over here.

So when you get a new document that comes in, so the nice thing about this is that it's all an idempotent load, which means that say your entire graph went away tomorrow, as long as your documents didn't change, if you load them, you'll get the same graph.

So worst case scenario, yes, you would have to reload the whole graph, but this load is deterministic. Now you can also, and I've experimented with this again in some of my other work, is you can say, oh, well, I have one document that changed and I just want to update that one node.

You just have to be aware of the fact that it links to other things. So it's like, well, if you changed, if you updated this document over here, if you changed its name, then you have to, did your other documents also update like the URL reference to that document?

So there's little edge cases there that you have to work through. But if you're able to do that, maybe we can talk after and I can show you. You can have like just add to like this part of the tree and clean up this part of the tree.

So you can do like partial syncing. Yep. Allrighty.

Do you have your hand up back there?

Sorry.

You're just scratching your head. Allright.

Then I guess we have one question here.

So I asked the agent if he has 2,000 pages per day. He has 3,000 files,right? So it says all of that 500 files could be done via PageIndex. It's saying that only the detailed documents you can. PageIndex seems to be one of the ways to retrieve data,right?

Right.

So only it's saying the detailed documents you need to add. And after that, so I already started doing that. It's saying once you PageIndex, the default is that I should do PageIndex. It's the next step,right?

The default after something like PageIndex would be search?

The search index would be search,right?

Yeah. Yeah. So I think the question is the question basically like for the way that the agent reasons about it, that it would call outline first to then use like search? Yeah. Yeah. It could work that way. It could work some way where it will search first to find a relevant document and then try to find everything it links to, in which case it would be the opposite way around.

Allright. Awesome. Let's move on here then to make sure that we have time for all of our questions. So what are we doing here?

This is just more asking more full text search. Why don't we, because we're at 39. Well, I think we already effectively went over a lot of this material here.

Some of this is designed so that if you come back to it later, it kind of over-documents what I'm talking about. So these steps and some of the optional work will help you understand cipher a little bit better and kind of exactly how all the pieces fit together.

But given the pace that we're moving at, why don't I go ahead and jump over to our theme section? So I'm going to skip over the optional practice lesson here, and I'm going to goright into themes.

So this is going to be our third and last shape of today.

The idea with this is if you run, so this cipher query is basically going to be loading a graph, and I'm just looking at that links to relationship between the documents. So when you have documents that have a lot of interlinking, it's always nice to think about using a graph because this structure basically.

What it's saying here is,right, we have these manuals, these recalls, and these bulletins, and they link and they refer to each other. So you can see like

this guide here that's a manual is being linked to by all of these different repair procedures. And if you zoom out, what ends up happening is you'll get natural clusters of things. And this also happens a lot like in these Caparthi style knowledge bases where you'll see that concepts will naturally start grouping together.

And a graph can help you surface those themes, those things that you didn't actually know existed before. And so we're going to use something called Leiden community detection. By a show of hands, how many people in this room are familiar with what graph data science is?

Well, yes. Okay. So not too many of you. How many people know what community detection in a graph is? Okay. So we have some of you. So community detection is this idea where,right, if I have this graph, and you can kind of see if I zoom out, especially if you're running it locally, you can see that there's these natural little clusters,right, of nodes that are highly interlinked together.

And so the idea is like, well, what if we can try to label these clusters such that within a cluster, things are highly interconnected. So like this little globule of nodes becomes a cluster, then this globule becomes a cluster, and this one down here.

And if we can do that, we can start understanding our data at a global scale really well. So this is like that initial Microsoft Graph RAG idea too of global versus local search,right? We're doing something very similar here, but we're doing it in a very lightweight way where we're not really doing any LLM extraction.

We're just going off of literally the structure of the documents. The algorithm that we're going to use for that labeling is called Leiden, which is similar to Luvane, which if you talk about community detection, Luvane will come up a lot.

Leiden is, I almost see it as like

the sort of next step. It's a little bit more efficient in the way that it runs. And it's using Neo4j's graph data science library. So basically what we have to do, or what we do to make it very performant, is in addition to just having the database, we have this other projection where we'll take a part of the graph into memory, and then we'll run these high concurrency algorithms on top of that so that if you have a graph that has, say, millions or billions of nodes, we can start performing this clustering and then identifying basically the different interconnected communities.

And these clusters, if I keep going down, basically the format that we're going to go for here, sort of the view that we're going to show our agent is this one. And so it's a little bit hard to see because it's a sliding window.

But basically we'll have what we're calling themes. And these themes are going to be these buckets of documents. We'll have a sense of how tightly or loosely they're interlinked using this conduance metric. It's basically like going to be this metric around like how interconnected the nodes inside the cluster are versus how much they are connected outside of the cluster.

So we can say something's tightly interlinked or loosely interlinked. We'll use the labels on the links as the top shared targets. And we will talk about the most linked docs, and so the highest centrality docs inside each of them.

And so what we end up with, without any sort of tagging or labeling by AI or a language model, is just simply from the document structure, we can tell that this first one is about

BCM and bus and all these sorts of things. And then if I go down, like this next cluster is going to be about brakes and rotor pads and hydraulic lines. So it's all braking stuff. So you end up with these very natural sort of clusters that come up.

And so this is very useful from sort of a whole estate-wide question because you can start to understand in your data kind of how everything kind of groups and clusters together. And so the way that we build that is similar to what we were doing before, where we have that script

and we have our spec as well. So I'm collapsing the sections. And it talks a little bit here, and I kind of want to give us the last half an hour to go through the final questions. So I'll speed run this a little bit.

But basically when we create this projection, and I'll just go ahead and copy this thing. Maybe I'll do this script thing first. So like we did before, inside of here, if I look inside of my themes.py file, I have this wire for the projection, that piece where we take the graph and put it into memory.

The actual Leiden algorithm here, I'm just calling it with that graph data science library. So in theory, you can kind of agentic code all of these, but I'll just do this one. Oh, that's not good. I want to be able to make sure I copied theright thing.

So similar to before, we have our,

make sure that it's theright thing that I just gave it. Yeah. So we're telling it to use the cipher skill and the GDS skill to put this together. If you went inside of our docs, you have the theme format one, which will give it the shape that we want in everything, and it will tell us kind of how we want all the headers and things to be formatted.

And so we'll go ahead and

create that

for me. And while it's creating that, I'll talk a little bit about the projection. So there's some graph manipulation that we do to bring it efficiently into a projection.

Basically, we collapse the relationships on the URI so that if we have sections that interlink with each other, like one section of a doc interlinks to another subsection, we just aggregate that all to the document level. And that creates kind of a cleaner interpretation to how our documents link together rather than just all our individual sections.

And we can get out the communities easier that way as well.

Allrighty. So that looks like it's coming along. Yes. Okay. So it went ahead and created that for us. And then once we get that back, I can go ahead and copy the script that it just helped me create.

And I can run that inside of my terminal.

Let me just make a new terminal. So I can go ahead and call that theme script that we just edited. And then it will do that community detection. And you'll see here that I'll get that view. So I have my, you can see like this circuit one.

I have all my different documents that are grouped together. And I kind of understand now all the different areas of the vehicles that my documents go over. There's other parameters that you can feed this. So for example, we have a gamma parameter.

And basically what that will do is it basically tells it kind of how much to split everything into. So it's one parameter that we're exposing. If you went to the graph data science documentation, there's many others. But like I got 13 groups running it here.

If I try to make it more refined with gamma equal to 2, so it's 1 by default, it will give me, I think in this case, 14. So it basically splits it up into more groups. A lot of these community detection algorithms, also because they're hierarchical, you can choose to sort of, you can choose your level of granularity that you want, basically.

As you go along and you start to understand your corpus better, you may want to tune some of these hyperparameters. And this gave us 14 different themes.

Let's see what we have here.

Yeah. And it never really names a theme, is sort of the point of this. So like everything that you get is just directly from the document. If I was to look at like the theme here, the names of the links, the names of the top files that were read, all of those things are just directly from the data.

And then because you get the URIs, the IDs of some of these documents, you can start doing the thing where you can go back to the outline shape or the search shape, and you can like search underneath all of these things.

So it gives the agent the ability to kind of jump between multiple tools like this.

And so these sorts of things are good for these estate-level questions. So things like where are issues concentrated, where's documentation thin, where does new documentation possibly belong on some other different type of subject that just came in for adding more data.

Allrighty. So that brings us to the end of themes. And we have 27 minutes about left. Are there any questions around this themes

algorithm that anyone has really quickly?

Yes.

Yep. Just going back to the one where you can identify

the cluster terms and talk about which one would be their naming. Is that something that you do typically with just, I guess, regarding the find and found for that, or are you more into. And it comes up with what it means that actually represents?

Yeah. So that's a good question. And the question is, once you get the themes, so all the Leiden algorithm will do is assign an ID to these different groups,right? And then what you do after that is sort of your choice.

And your question is, are you just sort of taking from the data and just putting that there, or are you making some sort of inference afterward to label the different groups? Here we're doing the former. We're just taking what's in the data and we're just showing it to you.

And the advantage of that is every time I run it, it'll be the same as long as the data stays the same. If the data changes, it will change to reflect the data. So it's very stable. The disadvantage to it would be if your links in your documents and the titles and things that are being scooped up, because this is really only looking basically at document metadata and link metadata, if those things aren't already well labeled, this view might not be super informativeright off the bat.

That's why you have, with like the Graph RAG methods that Microsoft came up with, they do a lot of heavy entity extraction because then what that will give is this sort of, and they'll do hierarchical level summaries,right? So after they get the Leiden community, which is the same algorithm that they use, they'll do a summary that'll be LLM-driven on top of each theme.

So that's possible to do. But then obviously it costs more money, it's slower, and if you run it twice, it might not return the same thing. So there's trade-offs between each way of doing it. I'm showing you the sort of lighter way of doing it and the easier way just because it's faster.

And if you're just getting started with this, it might be easier to start there. Maybe we have time for maybe one, maybe two more questions. Yes.

How would you define this to say like temporal data?

Temporal data?

Yeah. Like as in it's getting updated every day or every.

Yeah. I mean, I've seen customers basically every time, because the way Leiden works is it really is this algorithm where it will suck everything into a projection. It will create its labels and it'll die down and then it will go away.

So if your data is being updated constantly, you can recreate your IDs and you can have almost like a time series of different theme IDs, for example. And then you can, if you want, create summaries sort of at the snapshot of when they existed, or you can see how they evolved over time.

But it's a very common use case. A lot of people will actually use this. Even before AI, they'll use this for things like fraud detection. So like looking at credit chargeback fraud or like some of these other anti-money laundering type of stuff to look at clusters.

And for that, they'll have to do it temporarily. Like they have to keep running it to kind of see how things change over time and then predict the future,right? So they're used in those scenarios too. Yep.

Can I just.

Allright. One more maybe, and then I'm going to have to move on. Allright. Okay. Yes.

Can I just.

So the question is, if you have a really big graph, how do you take this view that's being sent to the AI model and make it manageable?

Basically, so you close the activity graph.

Yeah. So for this view, I think it's showing like 14 themes. So there are cutoffs that you can make. So for example, you can say like for communities that are smaller than X threshold, like you don't necessarily need to highlight them.

Sometimes small communities are very important, which is why that conduance metric, which is powering that tightly interlinked, loosely interlinked, you can also make that a cutoff. So if I'm interpreting your question correctly, it's sort of filtering down kind of the amount of information to what's most important to show the AI model on a larger graph.

Do I understand that correctly?

Can I just.

To make sure that the relationships on the nodes are correct. And so.

Can I just.

Yeah. Yeah. I mean, so in this scenario, we're really sort of trusting, we're taking the source data kind of at its word,right? If something links to a document, it links to the document,right? If it's erroneously linking to a document or there's a section that's malformatted, we wouldn't necessarily catch that.

But I suppose a good thing about something like an outline shape is that you can have your agent traverse it automatically without you necessarily seeing it in small pieces. And it might be able to catch some of those things,right?

So I suppose it does give you that navigation would give you a way to kind of have an agent supervise the graph and understand like malformed data or data that's been a problem. But it's a good question. I don't know if we have a perfect solution to it.

Cleaning messy data has always been

a thing. Yep. Allrighty. Let's go ahead and move on because I only have 20 minutes left, and I anticipate this last section will be, this is the meatiest one. So hopefully we'll have enough time to go through it, especially because Claude has been slow.

So cross your fingers because this one is probably the heavier use of Claude. So there is a section here around just using the Neo4j CLI. Because we're just 20 minutes in, I'm probably not going to go through it all the way, but I'll talk about it for a couple minutes.

The Neo4j CLI is a CLI tool. So I can run it in the command line. So here, for example, if I opened up a terminal window, I can go ahead and copy it in, and it will run a query for me.

And it also has the ability here to grab the graph schema. And what that enables me to do is

basically understand what's in the graph and then write a query based on that. And if you have your agent, which in this case, because we're using a coding agent, it can access the Neo4j CLI. It gives it the ability to do this graph reasoning, read the schema, and then do flexible queries.

So this is very useful if you have a question that you didn't anticipate and the agent's sort of gluing things together between the shapes,right? It has to write its own custom cipher query. It can do that very efficiently.

And I've seen a lot of improvements using this along with the skills. So much better than the text-to-cipher experience that we've had, like even as soon as a year ago or six months ago. If you are going to be writing cipher or doing anything text-to-cipher with an agent, I'd highly recommend using the Neo4j CLI as well as the cipher and GDS skills that we were just going over.

So with that in mind, I'll go ahead and take it on to our, in this case, our last section. If you were to take this offline, there's other informational sections that come after it. But basically, we're going to start asking some questions.

The first question that we're going to ask it, and I will jumpright to it because a lot of this documentation we've already went over, is if you remember from the beginning, we had our different personas,right? We had sort of our, who we called our Danny, which is the floor technician,right?

And they might have a question like, "Hey, for this VIN with this specific code that I'm getting, what have we done that has fixed this on similar vehicles?" And the motivation behind this,right, and behind a lot of the data is as an auto repair shop, you want to minimize your comeback ratio, which is basically how many times a customer has to come back because the fix didn't work,right?

And so the data, especially on the warehouse side, will show some of that history combined with the documentation on the actual parts and the recalls and the bulletins. So what I've done here is similar to the gentleman's questions before, I have it explain the steps that it used for the different shapes.

You can see it's loading the auto server skill. So that was

the skill that we have here where we've also contains all of the scripts we've been working with. So the outline search and theme script, it is accessed to, as well as the run SQL and the MCP server. That was this skill that we were talking about before.

So I've pre-written that for this. You can read it if you like, but it basically gives it some general guidance on how to access the warehouse and also deal with the different shapes in the command interface. And you'll see what it will do here.

It will look for the document code. It'll do a full text search. It'll use the tree shape here to find cross links and causes. And then it will get the join paths.

And it will actually do the query for the VIN. And when it does that, it will go ahead and come back with basically the part number that needs to be replaced. And in this case, there was like an old ignition coil that got revised that it had to replace it with.

So if you look,right, at first it did full text search to sort of ground the document with theright code. So it looked for the code and also the misfire or rough idle. It found the top hit, which is this engine type.

It confirmed its grounding. So it shows the links from that manual over to these different procedures. And then from there, it did a join path. It basically looked at all the work orders with that DTC code for that part.

And then it was able to bring back the ultimate question, which is like from all the parts that were replaced and how we dealt with that code, it went to the warehouse to grab that information. So you can see like this is a simple question.

So if you were using vector search and like Genie, like their AI search in Genie and like Databricks, you could do this. But what often happens is to basically find what it would need to do that linking on that tree shape, it would have to do much more vector hits, which each of those is a chance,right, for this to run into an issue and not find theright document or potentially hallucinate and get something on a misfire that maybe wasn't related to that specific part.

But because it grounded in the tree shape and everything, it was able to get theright information and then link that back to the table.

And so it can be helpful and it can help with efficiency in these smaller questions. But then what can happen is when you get to the estate level questions is where it can get really interesting. So I'm going to go ahead and just copy this question and I'm going to let it start running.

It seems like Claude is moving faster now, which is good. But I'll talk about it as it's running. So this is a question around, "Hey, are there mismatches between our documented procedures and problems that we're seeing in the field?

And what documents are missing or sort of on the other half, like what documentations are we not leveraging at all inside of our warehouse data,right?" Because we have our documents, which tell us about like the recalls and the bulletins and all this sort of stuff and the manuals.

But then we also have the work order history from our warehouse. And so this is a question that someone in a supervisor role or someone in an analytics role might be interested in,right? Because it's sort of like proving a negative or a mismatch because you're sort of saying like, "I don't know what I'm looking for.

I'm looking for a gap though." And you can imagine that with a tool like vector search, this would be a very hard question or any type of similarity or lexical search because like if you're just doing that alone, by definition, you can't really search for a negative.

You have to search for things that are there. And so what I found and I think what we found as a company is that graphs can be very useful when you start having these more global types of questions, these estate level questions that you want to ask, particularly if they're around patterns where you might not even know what you're looking for yet.

Yes.

And so this one takes a while to run because at a certain point here, it does have to take a large number of codes and join some data together. But you'll see at the end here, it'll kind of trickle in and it'll tell you how it went about finding everything.

And oftentimes what you see with these, it'll use some of the document data with some shapes and then it will go back and it will go back to the warehouse and query from there.

We'll run through a lot of different things here.

Another thing, just while it's working on that, I did tell it here for sake of clarity to not use the Neo4j CLI. And the reason that I have that here is so that you can see it using the different shapes

just for sake of understanding how the different shapes kind of fit together and work. Once you hand your agent the Neo4j CLI, it becomes very powerful because it can start writing custom cipher queries. And there will be instances where it'll prefer doing that over some prefix shape.

And I'd say that as our sort of text-to-cipher capabilities and as we keep building up more skills, it'll start to prefer more freeform Neo4j CLI stuff much more frequently.

And this one can sometimes take a little while to work through. So I'll give it another 20 seconds or so. Or maybe I can even open it up to a few questions while we're here, while we're waiting for this one.

Yep.

So you think that Claude is going to be able to find this section or is

there a... Is it like checking documents that somewhere in the TPU that the TLA and the CLI wants to look at?

So basically what it's going to do is it's going to look at the... Well, I actually have to have it come back and remind me exactly

how it goes through. But basically what you can see from the work orders, what has been worked on,right? And then you can sort of take the codes from there and see what documents it has been using. And then there's also going to be high comeback history on using some of the wrong parts.

And so you sort of get this view of, "Okay, well, there's a bunch of documentation that we're maybe not hitting because we're getting all these comebacks from like using potentially the wrong part." So there's that half of it.

And then there's some documentation that we have that's just not covered because we're using DTC codes that's just not covered inside of the warehouse. So we'll know that like certain documentation hasn't really been hit at all.

So here it actually took a little bit more of a... And it will do this sometimes. Here it used semantic expansion. So it actually went in and did a much more comprehensive semantic expansion search. It's supposed to, in this case, use the outline.

I think because it had the hierarchical URI, it was probably able to do this a little bit better. But if I go back up, where did it show?

Yeah, well, it was able to show here the field codes essentially that it was missing. So there was basically two field codes that got a, yeah, the headline mismatch or diagnosed with the wrong procedure. So there's basically this mismatch where a couple of these parts among them are something that's on the library document.

Yeah. So where the correct repair isn't referred to basically. And that's causing a problem for the warehouse. And then there's other DTC codes that occur in the field exactly that have two that have no code level documentation, which are these two.

So there's codes that are occurring which basically aren't documented that it was able to find. It's a shame here that it didn't use the outline. It's supposed to do that because basically when it uses the outline, it's able to traverse through and find all of the links a little bit more efficiently.

It wouldn't have done the comprehensive full text search call that took it a while in this case. But even here, because it had the hierarchical URIs and that semantic expansion on the full text search, it was able to eventually find it.

But it's a good lesson that when it does use the outline, it can come back faster because it can traverse out on the different links. The other thing here, the last one that I'll run because we only have eight minutes left.

I'll go ahead and copy it here. And this one is primarily, let me go ahead and copy it, is going to leverage our theme shape. So

this is asking for common patterns across all our bulletins and recalls and how many of the cars sort of each affects. So we have our work order history inside of our warehouse. And basically what we want to find out is like how does the sort of themes that we have correlate with our work order history?

And to do that, it runs that theme pattern to be able to pull out the high level themes and then correlate it back to our work orders.

And so it's a coverage question. So you can see it'll run the themes.

And then eventually here we'll go ahead and bring back

all of the relevant information. But basically what it's doing is it's finding the themes. It's going to go and pull sort of the types of fixes that it has in the work order history. And then it's going to do a join of sorts to kind of group them under theright theme.

While this is running, are there any other questions about this theme shape or anything? I know other people there. Yes, go ahead.

How do you assign this to a client?

Sorry, say that one more time.

A client is assigned to a client issue, is it during the graph construction?

During the graph construction.

When we are defining this shape.

Yeah. Yeah. So the shapes that are actually defined inside of our specs. So if you go here, our outline shape, our specs and our docs. So this was defined more thinking through like here's what we want it to look like for the agent.

And then once we define that, we come up with sort of the query structure that we want and we use that to inform our data model. And all of the documents were loaded essentially into that data model that I went over about an hour and a half before towards the beginning of the course.

It's that has containment tree with all of the links between it.

And you can see here it'll bring back that it used themes, it didn't use search. And then it

also queried the, if I go up here, you can see the cars affected. So it basically went to the warehouse with that connection shape and it was able to sort of group them under the different theme types. So it's like that theme, the different theme types that we have and then kind of with the cars and the work orders grouped underneath by percentages.

Yes, over here.

Is it either one or the other?

Yeah, either one.

So if you have sensitive items like a vehicle. How accurate is your coverage from the dependency or not?

Do I have a sense of accuracy of how well these do when the knowledge bases expand? For this, I haven't run any specific benchmarking on like exactly what I've shown you today. But I will say that when we do have customers that run these, they'll often come up with their own custom ontologies and then they will run benchmarks that will basically say like how effective is this query pattern against ordinary vector search, for example.

And you would use that to prove it out on a specific type of data set. Here for this course, this is more conceptual to understand kind of like the different shapes that you would use to help ground your data.

And it can always use work in terms of how you were to like build the skill,right, to make sure it guides through theright thing so it uses each step efficiently, essentially.

Are there any other questions? Yep.

In this case, the parts codes were a weird mix between the two different graphs, documents and tables and data.

Yeah.

In cases where that is a different cluster, for example, like say data and you have like a good connection between the data points and say an economic analysis or something like that.

Maybe I don't fully understand. So you have a connection point between

what? Between.

Let's say a company you have the financial statements between the databases and the production data.

Yeah.

Also you have like the CEO comments about the business.

Yeah.

You don't have any relationship.

Yeah, no, we do not have. Soright now, so now that I understand your question, the question is, is there a link between the connection structured data graph and the unstructured one? And there is not in this case. They're completely unlinked.

And the agent is sort of extracting a part from one or it's extracting like, yeah, basically like a code,right? And then referring back to the document. So it's using that to kind of do its own join in real time.

You could create that linking and that could be valuable for more deterministic mapping. Here we didn't do it. And the main reason I didn't do it was really for speed of getting started because I did kind of want to provide code that would be easy and also model agnostic.

And this is that. And then if you wanted to later create those connections or those links, you could.

Any other questions?

Allrighty. Well, thank you, everyone. Hopefully that was informative. If you want to go back, the workshop's available for you to take. It's online. I am going to have to take the Anthropic key and the BigQuery key down eventually.

I'll leave the BigQuery one up for a while, but the Anthropic one I'll have to eventually take down. So unfortunately, you will need to provide your own key. But other than that, you should be able to take it just fine.

And I think that's all I have. So I'll leave it for my next guest. Hopefully you guys have enough time to jump into your next session.