WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=kRkcNOsRyYg NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/kRkcNOsRyYg.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:12.800 --> 00:00:14.799 Hello everyone. s2 00:00:14.799 --> 00:00:18.480 Welcome today to get started on AIE. s3 00:00:18.480 --> 00:00:23.199 Um, so right here, uh, there's some steps for getting started. s4 00:00:23.199 --> 00:00:25.840 I went over this around 10 minutes ago. s5 00:00:25.840 --> 00:00:32.320 Um, but basically our workshop that we're going to take today is driven by a website called Graph Academy. s6 00:00:32.320 --> 00:00:37.360 And if you go to that first QR code there to the left, uh, that'll take you there. s7 00:00:37.360 --> 00:00:39.600 You have to enroll with your email. s8 00:00:39.600 --> 00:00:47.440 Um, and then if you go down to set up your environment, uh, there's a code spaces there with everything set up and you can get that rolling now. s9 00:00:47.440 --> 00:00:50.480 It'll take maybe about five minutes or so. s10 00:00:50.480 --> 00:00:53.680 Um, and you can grab your credentials then as well. s11 00:00:53.680 --> 00:00:56.160 There's um an anthropic API key. s12 00:00:56.160 --> 00:01:02.480 Uh if you have your own cloud code key um or your your own subscription, please feel free to use that. s13 00:01:02.480 --> 00:01:04.559 Otherwise, we provided one for you. s14 00:01:04.559 --> 00:01:08.960 Um and then there's another key there for reading from BigQuery tables. s15 00:01:08.960 --> 00:01:21.280 So with that in mind, uh we'll go ahead and get started with AI on your lakehouse, um which is about context coming in shapes and not necessarily queries. s16 00:01:21.280 --> 00:01:24.560 So today your team um will be myself. s17 00:01:24.560 --> 00:01:26.080 My name is Zach Blumenfeld. s18 00:01:26.080 --> 00:01:29.360 I am an AI research engineer at Neo Forj. s19 00:01:29.360 --> 00:01:44.400 Uh we also have Ben Squire over there in the back um who is our senior developer advocate um as well as Ryan here in the center um who is our partner architect helping customers get this stuff up and running. s20 00:01:44.400 --> 00:01:51.360 So, as you have questions, um I don't have a mic set up for you, but uh go ahead and raise your hand. s21 00:01:51.360 --> 00:01:56.399 I'll sort of I'll take time around every 10-15 minutes during natural breaks. s22 00:01:56.399 --> 00:02:05.280 Um and 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. s23 00:02:05.280 --> 00:02:08.479 Um and they can help get you unblocked. s24 00:02:08.879 --> 00:02:22.400 Um so what we're going to talk about today um is really about when you start using uh a lakehouse right there's sort of two sides obviously there's a warehouse which is your structured data and your tables s25 00:02:22.400 --> 00:02:34.080 um and then there's the data lake part which is all of your unstructured documents and oftent times what can happen is you're given these tools like text to SQL and vector search s26 00:02:34.080 --> 00:02:47.360 and nowadays we don't really have trouble accessing that data Um, but sometimes there are still some challenges around how do you give your agent the right type of context, whether or not they can see all the data in the way that they need s27 00:02:47.360 --> 00:02:51.760 um, and really take a slice to answer the right type of question. s28 00:02:51.760 --> 00:03:03.120 And so what we've put together today inside of our course is an agnostic data model um that basically creates a graph representation uh both from the structured side your warehouse s29 00:03:03.120 --> 00:03:10.560 um but then also provides structure for some of your documents um and then allows you to do a lot of useful stuff with that. s30 00:03:10.560 --> 00:03:14.720 Uh we do have a scenario here that we're going to go over. s31 00:03:14.720 --> 00:03:21.599 Um, we've created a fictional autofix group, uh, which is, think of it like a a Pep Boys Auto or something. s32 00:03:21.599 --> 00:03:24.080 It's a national auto repair chain. s33 00:03:24.080 --> 00:03:26.080 And they have all of these bays. s34 00:03:26.080 --> 00:03:36.560 They have these libraries of manuals on vehicles, um, as well as safety bulletins and recalls and then a warehouse of all of the repairs that they've logged. s35 00:03:36.560 --> 00:03:39.840 Um, and you have sort of your floor technicians, right? s36 00:03:39.840 --> 00:03:47.040 These are the Danny's that are listed here where they have the cars inside of the bay and they're going to need to ask some questions. s37 00:03:47.040 --> 00:03:56.159 Um, you have leadership at this organization that wants to create a co-pilot uh to be able to assist these technicians on the floor. s38 00:03:56.159 --> 00:04:02.720 Um, and then obviously you have people like Sam who are us, the AI engineers who actually have to build the thing. s39 00:04:02.720 --> 00:04:10.000 Um, 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. s40 00:04:10.000 --> 00:04:24.880 So imagine, right, you have your documents inside of cloud storage and then um you have BigQuery as your uh data warehouse, but these patterns are also extendable to data bricks as well as snowflake. s41 00:04:24.880 --> 00:04:37.840 Um and essentially if they just create a co-pilot on top of uh BigQuery and the data that they have um it can pull the data correctly um but sometimes it can be confidently wrong. s42 00:04:37.840 --> 00:04:46.560 Um, basically it could get it could pull stuff with vector search from documents and it can do text to SQL um on just a few tables. s43 00:04:46.560 --> 00:04:59.280 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 um things can get lost and fall through the cracks. s44 00:04:59.280 --> 00:05:12.320 And really where graph can come in to help with these shapes um 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 s45 00:05:12.320 --> 00:05:16.080 but oftent times it's going to be on these estate level questions. s46 00:05:16.080 --> 00:05:19.199 So things like for example, what are we missing? s47 00:05:19.199 --> 00:05:29.120 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. s48 00:05:29.120 --> 00:05:36.479 So this is sort of like proving a negative which can be very hard with something like semantic search uh which can only match similar things, right? s49 00:05:36.479 --> 00:05:38.800 It can't really find a negative example. s50 00:05:38.800 --> 00:05:42.960 Um there's also questions that we have where we want patterns across everything. s51 00:05:42.960 --> 00:05:49.759 So say, you know, you might want to ask, well, you know, what are, you know, the common types of patterns that we see? s52 00:05:49.759 --> 00:05:53.120 Is there anything that we're failing to fix over and over again? s53 00:05:53.120 --> 00:06:03.520 Or, you know, are there, you know, specific groupings of different types of recalls that are popping up and and things of this nature where you really need to traverse the entire data set. s54 00:06:03.520 --> 00:06:08.560 Um, and then the other one is just asking how records relate inside of a large SQL store. s55 00:06:08.560 --> 00:06:17.600 Um, and when you have one big lookalike schema where you have lots of similar tables, um, how do you understand how to join those together correctly? s56 00:06:17.680 --> 00:06:22.639 And so there's going to be three concrete shapes that we'll introduce you to today. s57 00:06:22.639 --> 00:06:33.919 Uh, so the first one um, we're going to call table of contents and it's somewhat like a tree structure uh, but with also different types of links between them. s58 00:06:33.919 --> 00:06:35.360 You'll see how it works. s59 00:06:35.360 --> 00:06:38.560 Um this is going to be used on the unstructured data. s60 00:06:38.560 --> 00:06:42.960 Uh on the unstructured data site as well, we have something called themes. s61 00:06:42.960 --> 00:06:52.560 Um and what themes does is it surfers surfaces global patterns inside of your data that might not be apparent um or you might not know about beforehand. s62 00:06:52.560 --> 00:06:55.680 So uncovering unknown patterns and groupings. s63 00:06:55.680 --> 00:07:08.080 Um, 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. s64 00:07:09.680 --> 00:07:17.440 And so how many people just a show of hands here are familiar with like graph and graph rag. s65 00:07:18.080 --> 00:07:24.960 Okay so a fair number of you then how many people in here have used neo forj before? s66 00:07:25.440 --> 00:07:25.840 Okay. s67 00:07:25.840 --> 00:07:29.840 Also like uh maybe 30 40% something like that. s68 00:07:29.840 --> 00:07:37.599 So this room seems like you know fair fairly uh fairly familiar with graph basics but I'll I'll go over it just here really quick. s69 00:07:37.599 --> 00:07:42.080 So Neoraj we're we're a graph intelligence platform. s70 00:07:42.080 --> 00:07:44.720 We have a graph database at at at the heart of it. s71 00:07:44.720 --> 00:07:45.440 Right. s72 00:07:45.440 --> 00:07:53.199 Um and basically when we talk about what a graph is we're talking about it from a property graph data model perspective. s73 00:07:53.199 --> 00:08:04.800 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. s74 00:08:04.800 --> 00:08:09.039 Relationships which are the verbs or associations between those things. s75 00:08:09.039 --> 00:08:15.280 So like person owns car, person drives car, person is related to other person. s76 00:08:15.280 --> 00:08:25.520 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. s77 00:08:25.520 --> 00:08:35.440 And those can be anything from strings, they can be numbers, they can be dates, they can be vectors, um um all sorts of things. s78 00:08:35.440 --> 00:08:46.800 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. s79 00:08:46.800 --> 00:08:52.800 Um, and that provides a ton of benefits that we'll see we'll see later in the course. s80 00:08:52.800 --> 00:09:04.800 So, with that in mind, why don't you go ahead and get started and go over into these if um if you haven't heard before and I'll actually just show you here really quick. s81 00:09:04.800 --> 00:09:11.519 Um inside of the workshop lakehouse, have it open here. s82 00:09:11.920 --> 00:09:16.399 I should probably restart this guy really quick. s83 00:09:16.399 --> 00:09:17.680 Start my code base. s84 00:09:17.680 --> 00:09:22.160 Um, but basically it should take you to this page. s85 00:09:22.160 --> 00:09:27.760 Um, this shouldn't wouldn't say continue course for you if you if it's your first time going to it. s86 00:09:27.760 --> 00:09:30.640 It would say enroll to take the course. s87 00:09:30.640 --> 00:09:34.640 So, you have to go through that path to enroll to take the course. s88 00:09:34.640 --> 00:09:44.160 Um, 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 uh things that we can do. s89 00:09:44.160 --> 00:09:46.720 Um, there's about 17 lessons in here. s90 00:09:46.720 --> 00:09:49.120 We've broken it up by the different shapes. s91 00:09:49.120 --> 00:09:56.320 Um, but basically if you go into the course, you can kind of click through here. s92 00:09:56.320 --> 00:09:59.040 I go over the scenario a little bit. s93 00:09:59.040 --> 00:10:03.360 But while I'll do that, I think what you should do is jump to this environment section. s94 00:10:03.360 --> 00:10:08.080 So basically, you go down to the bottom here. s95 00:10:08.080 --> 00:10:26.000 go to your environment and um from here you can say open code space and in fact I will open a new code space here just so that I can I can walk through it uh live with you as well. s96 00:10:27.760 --> 00:10:28.800 Yeah, of course. s97 00:10:28.800 --> 00:10:35.200 Um, go back to here. s98 00:10:39.360 --> 00:10:42.800 Why don't you all go ahead and capture that? s99 00:10:56.160 --> 00:10:56.560 Yes. s100 00:10:56.560 --> 00:11:00.959 So it'll create a code space in your own GitHub if you want. s101 00:11:00.959 --> 00:11:02.720 There's a link to the repository. s102 00:11:02.720 --> 00:11:04.399 You could run it locally. s103 00:11:04.399 --> 00:11:09.200 Um just keep in mind that we've set it up so that it will auto start in the code space. s104 00:11:09.200 --> 00:11:15.519 So there's another um bash script that you can run to run it locally and it will it will set everything up for you. s105 00:11:15.519 --> 00:11:19.680 Um but it it depends a little bit on your local environment. s106 00:11:19.680 --> 00:11:24.560 You have to make sure you have cloud code installed um and all these sorts of things. s107 00:11:24.560 --> 00:11:30.399 So, we'd recommend that you use a Code Space one if if you're comfortable doing it locally. s108 00:11:30.399 --> 00:11:34.640 I I I've run it locally all the time before, too. s109 00:11:38.720 --> 00:11:46.320 All right, everyone's everyone's copied the uh QR code. s110 00:11:46.800 --> 00:11:52.079 I'll give it another 10 seconds or so and then I'll I'll move back over. s111 00:11:52.640 --> 00:11:53.040 Yep. s112 00:11:53.040 --> 00:11:57.680 Ben and Ryan can help you out if if you don't have this one. s113 00:12:02.240 --> 00:12:03.920 Okay. s114 00:12:03.920 --> 00:12:09.120 So, when you start up as well, there's some workshop credentials here. s115 00:12:09.120 --> 00:12:13.920 Uh I'll I'll be uh blasting these keys uh a after the course. s116 00:12:13.920 --> 00:12:15.920 I'll leave them up for just a little bit. s117 00:12:15.920 --> 00:12:19.760 Um but basically, give it some time to start up. s118 00:12:19.760 --> 00:12:28.320 Uh- once it once it does, what you'll do is you'll go into your environment file here. s119 00:12:28.320 --> 00:12:32.240 And maybe I can make this just a little bit bigger so it's easier to see. s120 00:12:32.240 --> 00:12:38.720 You will place your anthropic key in here as well as the uh the BigQuery key. s121 00:12:38.720 --> 00:12:56.000 The other thing that you're going to want to place in uh if you go back to the course um is down here, it should give you a um Neo Forj credential. s122 00:12:56.000 --> 00:12:59.440 So, this is accessing our graph database. s123 00:12:59.440 --> 00:13:03.200 They've been all pre-provisioned, so it's going to be different for each one of you. s124 00:13:03.200 --> 00:13:04.240 You're going to have a different one. s125 00:13:04.240 --> 00:13:06.639 So, copy the one from your screen. s126 00:13:06.639 --> 00:13:11.360 Um, and you're going to put it inside of this environment file as well. s127 00:13:11.360 --> 00:13:17.040 Um, and it it will take a while, like you see with mine, the environment file hasn't uh quite popped up yet. s128 00:13:17.040 --> 00:13:22.000 So, it can take a few minutes for that all to go through. s129 00:13:27.440 --> 00:13:32.000 Um, so we'll we'll give that a little bit of time to start up. s130 00:13:32.000 --> 00:13:35.440 Hopefully, it won't take too long here. s131 00:13:38.720 --> 00:13:43.920 While that's running, I'll I'll give a little bit of an overview here of what we're going to do in the next step. s132 00:13:43.920 --> 00:13:56.079 So, basically, once we get this set up and and we get Claude up and running, um we're going to walk through um the first shape for our day, which is this connection s133 00:13:56.079 --> 00:13:57.920 semantic layer shape. s134 00:13:57.920 --> 00:14:04.480 And then after that we'll follow it with the table of contents one that we were talking about and the communities one. s135 00:14:04.480 --> 00:14:11.760 So we'll be working with the structured data first and then moving into the into the unstructured bits. s136 00:14:13.839 --> 00:14:21.920 Um once for those of you who do have it loaded basically you have your terminal down here. s137 00:14:21.920 --> 00:14:24.560 You can go ahead and call Claude. s138 00:14:24.560 --> 00:14:29.360 Um, we'll be working through Claude Code as our agent. s139 00:14:30.800 --> 00:14:54.079 Um, the internet is a little bit slow too, which is expected as you go through with this as well. s140 00:14:54.079 --> 00:14:56.560 I should um Oh, here we go. s141 00:14:56.560 --> 00:15:05.519 We'll set up show you what this looks like here in a second. s142 00:15:05.519 --> 00:15:14.000 Anthropic key as well as BigQuery one. s143 00:15:38.160 --> 00:15:40.720 All right, perfect. s144 00:15:46.000 --> 00:15:56.639 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 s145 00:15:56.639 --> 00:16:01.839 it should here give you the option to select the enthropic key. s146 00:16:01.839 --> 00:16:03.759 Just go through and press enter. s147 00:16:03.759 --> 00:16:05.440 Yes. s148 00:16:05.440 --> 00:16:08.800 And then you want to use the MCP server here. s149 00:16:08.800 --> 00:16:11.120 So you're going to select yes. s150 00:16:11.120 --> 00:16:14.560 And I'm going to skip the tour. s151 00:16:14.800 --> 00:16:25.839 And then I can ask that question just to make sure it can connect to Neo4j. s152 00:16:42.959 --> 00:16:50.800 And for me, I already have some nodes in because I'm working with um a graph that's been cached already for my previous course. s153 00:16:51.199 --> 00:16:56.000 Um for you, it will it will come up as an empty sandbox. s154 00:16:56.000 --> 00:17:07.600 So, one thing that uh I want to note here too in terms of how we're going to be working with Neo forj and with cipher, which is our graph query language. s155 00:17:07.600 --> 00:17:16.319 I think we've come to a point now where a lot of us aren't h hand typing uh our own code line by line anymore. s156 00:17:16.319 --> 00:17:20.240 We're using agents to help us build things obviously. s157 00:17:20.240 --> 00:17:24.000 And so in this workshop it's going to be the same thing. s158 00:17:24.000 --> 00:17:36.160 Basically we're going to be using something called the Neo Forj CLY um which is a CLY tool that will allow your agent to run uh queries directly against the database. s159 00:17:36.160 --> 00:17:40.720 When I was working inside of Claude, you saw it running there for a second. s160 00:17:40.720 --> 00:17:44.480 And that also ships with a Neoraj cipher skill. s161 00:17:44.480 --> 00:17:54.160 Um, 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. s162 00:17:54.160 --> 00:17:58.720 And we'll use that for some of the algorithms when we get to the theme section. s163 00:17:58.720 --> 00:18:02.160 Um, in terms of just helping us do agentic coding. s164 00:18:02.160 --> 00:18:07.760 So, I'm not going to have you guys handw write really any um cipher query code. s165 00:18:07.760 --> 00:18:15.919 I'm going to show you throughout this workshop how to use an agent to help you write that with with specs that are created. s166 00:18:15.919 --> 00:18:26.240 Um and hopefully that'll be useful for you more on on the day-to-day if you ever decide to use uh cipher um whether it be with Neo forj or not. s167 00:18:29.120 --> 00:18:33.679 Um, so how is everybody doing now? s168 00:18:33.679 --> 00:18:36.559 I I'll take a second here to stop. s169 00:18:36.559 --> 00:18:40.400 Go ahead and raise your hand if you have any questions here. s170 00:18:40.400 --> 00:18:42.880 Or are we all good? s171 00:18:42.880 --> 00:18:46.160 I have one question over there. s172 00:18:55.039 --> 00:18:55.360 Yeah. s173 00:18:55.360 --> 00:18:58.000 So the question is, can I use cursor? s174 00:18:58.000 --> 00:19:01.919 And so the answer to that is you should be able to. s175 00:19:01.919 --> 00:19:02.320 Yes. s176 00:19:02.320 --> 00:19:11.280 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. s177 00:19:11.280 --> 00:19:17.200 Um if not, when you go to open code, yeah, you can clone the repository here. s178 00:19:17.200 --> 00:19:19.840 So if you follow that link, you could clone it. s179 00:19:19.840 --> 00:19:21.360 You can get it locally. s180 00:19:21.360 --> 00:19:24.080 Um and then you'll see here there's directions. s181 00:19:24.080 --> 00:19:27.760 There's a shell file that you can run that will set everything up. s182 00:19:27.760 --> 00:19:28.799 You can take a look at what's in there. s183 00:19:28.799 --> 00:19:31.039 It's it's a bunch of basic stuff. s184 00:19:31.039 --> 00:19:31.360 Okay. s185 00:19:31.360 --> 00:19:32.080 Awesome. s186 00:19:32.080 --> 00:19:32.320 Yeah. s187 00:19:32.320 --> 00:19:34.640 And just a little bit about the structure of this thing. s188 00:19:34.640 --> 00:19:44.320 I forgot to mention um there's a lot of stuff inside of the uh inside of uh the the workspace here. s189 00:19:44.320 --> 00:19:49.039 Um obviously inside of Cloud we have our skills file. s190 00:19:49.039 --> 00:19:55.120 Um, so I've gone ahead and pre-written a skill here. s191 00:19:55.120 --> 00:20:00.000 Um, that covers basically a lot of what we're going to do. s192 00:20:00.000 --> 00:20:07.840 Uh, inside of here as well, there's uh a file called uh outline and search and theme. s193 00:20:07.840 --> 00:20:11.039 So, these are going to be the shapes that we'll be working with. s194 00:20:11.039 --> 00:20:22.160 um to query BigQuery there's just a very small um well that this is actually a a database query file but the run SQL one this one for querying bigquery just a very simple s195 00:20:22.160 --> 00:20:32.240 um um basically way of uh reaching out to BigQuery and just calling it with a uh with um a simple SQL command. s196 00:20:32.240 --> 00:20:37.760 Um and inside of these files as we'll see later there's there's places to fill in a spec. s197 00:20:37.760 --> 00:20:40.720 So that's going to be where we do some of our agentic coding. s198 00:20:40.720 --> 00:20:46.640 Um, but everything in here, if you wanted to like load this into BigQuery yourself, there's something for that. s199 00:20:46.640 --> 00:20:57.120 Um, if you want to go ahead and run this on data bricks, there's directions here to like load it into into data bricks and use Genie and AI search there if you want to compare. s200 00:20:57.120 --> 00:21:03.200 Um, and then this is just a sim link over back to the uh cloud files. s201 00:21:03.200 --> 00:21:05.039 Um, there's solution scripts as well. s202 00:21:05.039 --> 00:21:13.840 Also if you get stuck for example where for some reason the coding agent can't you know create the right query um you you can copy stuff from there. s203 00:21:13.840 --> 00:21:24.960 Um and then all of the source data too for creating both the structured and unstructured data is in here um including our uh PDF sources. s204 00:21:24.960 --> 00:21:30.080 So if you go in here we have our bulletins and our manuals and everything. s205 00:21:30.080 --> 00:21:33.760 Um this is showing you the uh the raw PDF. s206 00:21:33.760 --> 00:21:42.559 But if I go to the corpus, which is the the markdown version, uh you'd be able to to actual re actually read the contents inside of them. s207 00:21:42.559 --> 00:21:54.880 Um so anyway, with all of that, we'll go ahead and hop along to our first section here, which is going to be connections. s208 00:21:57.760 --> 00:22:04.240 So, we have basically our data inside of BigQuery right now. s209 00:22:04.240 --> 00:22:09.280 And in fact, if I go back to my overview, just to show you what it looks like really quick. s210 00:22:09.280 --> 00:22:11.440 This is the uh schema. s211 00:22:11.440 --> 00:22:14.159 Uh so, we've kept it very simple for this course. s212 00:22:14.159 --> 00:22:17.840 Obviously, in the real world, you'd have a much bigger schema than this. s213 00:22:17.840 --> 00:22:23.360 Um but we have our work orders, uh which is sort of like the middle or the star of the scheme. s214 00:22:23.360 --> 00:22:32.480 you have your vehicles, um the different uh DTC codes, procedures, uh work order parts, and then the parts themselves. s215 00:22:32.480 --> 00:22:36.559 Um and they join together in a very simple primary foreign key pattern. s216 00:22:36.559 --> 00:22:39.840 Um we'll get into our documents later in the course. s217 00:22:39.840 --> 00:22:44.640 It's just basically a a big bucket of of PDF files. s218 00:22:44.960 --> 00:22:57.600 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 s219 00:22:57.600 --> 00:22:58.720 layer. s220 00:22:58.720 --> 00:23:03.679 And to build that semantic layer, we're going to use something called Neoarta. s221 00:23:03.679 --> 00:23:06.320 Um Neoarta is a labs project. s222 00:23:06.320 --> 00:23:14.159 So at Neo Forj, we have our core engineering, which is like our, you know, cloud SAS platform, um our graph analytics stuff and all of that. s223 00:23:14.159 --> 00:23:18.159 But we also have labs projects where we move a little bit faster. s224 00:23:18.159 --> 00:23:22.080 Um, and inside of that labs project, we created this neocarta. s225 00:23:22.080 --> 00:23:25.280 Um, and what it does is it creates a metadata graph. s226 00:23:25.280 --> 00:23:34.159 Um, 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. s227 00:23:34.159 --> 00:23:43.600 Um, and if you think about it, people, you know, these words ontology and semantic layer and all these things are kind of they're thrown around a lot lately, especially this summer. s228 00:23:43.600 --> 00:23:52.720 And so the the basic uh mental paradigm that I use to kind of think through these is an ontology helps something interpret and reason about the data. s229 00:23:52.720 --> 00:23:59.840 A semantic layer helps something understand what the consistent agreed upon terms are so it can query the data accurately. s230 00:23:59.840 --> 00:24:03.039 Um and then at Neo Forj we have other things like virtual graph. s231 00:24:03.039 --> 00:24:12.400 There's a link in here in the course which will actually give you a sort of a a federated graph view of your SQL data that you can um that you can query over directly with cipher. s232 00:24:12.400 --> 00:24:20.720 We won't be using that here, but there there is um sometimes uh value in in giving sort of a graph view of the schema. s233 00:24:20.720 --> 00:24:34.960 Um but anyway, what Neo Carter will do is it we'll see in this next section um uh it has an MCP server basically that will sort of suck all the data in from the um s234 00:24:34.960 --> 00:24:39.279 from BigQuery just the metadata and it will create this graph. s235 00:24:39.279 --> 00:24:41.840 Um and that's what you do in the next section. s236 00:24:41.840 --> 00:24:45.520 So, I'll go ahead and jump to there. s237 00:24:45.520 --> 00:24:47.600 And I've already run this script. s238 00:24:47.600 --> 00:24:51.840 But basically, when you see this script, what you're going to do is you're going to copy it. s239 00:24:51.840 --> 00:24:54.240 And then you're going to go over to here. s240 00:24:54.240 --> 00:25:01.600 And then, um, you're going to bring up your terminal, which our terminal. s241 00:25:02.880 --> 00:25:05.520 And then, uh, I like to just open a new window. s242 00:25:05.520 --> 00:25:07.760 That's not my cloud window. s243 00:25:07.760 --> 00:25:10.480 Um, and you're going to allow paste. s244 00:25:10.480 --> 00:25:12.320 And then you're going to go ahead and run that. s245 00:25:12.320 --> 00:25:13.919 I've I've already run it. s246 00:25:13.919 --> 00:25:17.520 Um so I won't do it again, although it should be item potent. s247 00:25:17.520 --> 00:25:28.480 Um but basically once you run that, uh it'll create this um these six tables with these five reference join paths. s248 00:25:28.480 --> 00:25:33.039 And once you've done that, you can come back in here and even just run this to check. s249 00:25:33.039 --> 00:25:34.960 And it's kind of cool what it looks like. s250 00:25:34.960 --> 00:25:38.559 Um this is this is what it looks like inside of the graph database. s251 00:25:38.559 --> 00:25:53.679 And basically what you'll see is you have this uh this node in the middle that represents your um your well first your database and then your schema and then if you follow that out it'll be has table s252 00:25:53.679 --> 00:25:57.840 and then you'll have your table and then you have your columns. s253 00:25:57.840 --> 00:26:04.000 Um and those can also optionally have these representative values on top of them. s254 00:26:04.000 --> 00:26:18.480 Um, and so these join paths, basically when the agent reads that, um, if I was to go down here and try, so I have, um, a little example prompt down here s255 00:26:18.480 --> 00:26:28.400 and I can go into my window and go back to Claude and I can ask a question like this. s256 00:26:28.400 --> 00:26:32.960 Which vehicle received part IC 2042? s257 00:26:32.960 --> 00:26:40.799 And I in this case I'm going to tell it to use the the MCP server and the warehouse schema and all this to to go and grab everything then use the Python script. s258 00:26:40.799 --> 00:26:45.520 Um inside of the skill itself it it has directions for this as well. s259 00:26:45.520 --> 00:26:51.440 Um, but what you'll see it'll do of this. s260 00:26:55.360 --> 00:27:03.840 It'll call that MCP server for Neo Carta and it's it's going to read that metadata semantic layer graph that we have in Neo forj. s261 00:27:03.840 --> 00:27:10.559 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. s262 00:27:10.559 --> 00:27:13.200 There's not like an ETL into graph. s263 00:27:13.200 --> 00:27:17.120 What we're doing is we're using the graph as a semantic layer. s264 00:27:17.120 --> 00:27:32.080 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 uh decides to go ahead and run here. s265 00:27:43.840 --> 00:27:46.000 How is claude working for everyone right now? s266 00:27:46.000 --> 00:27:48.720 Are we seeing a lot of uh slow clouds? s267 00:27:48.720 --> 00:27:49.200 Fast. s268 00:27:49.200 --> 00:27:51.120 Yeah, slow. s269 00:27:51.120 --> 00:27:52.480 Okay. s270 00:27:52.480 --> 00:27:54.480 Interesting. s271 00:28:03.520 --> 00:28:05.120 I'll give it a little bit of time here. s272 00:28:05.120 --> 00:28:08.480 I don't know why it would be go moving. s273 00:28:08.880 --> 00:28:09.520 Huh. s274 00:28:09.520 --> 00:28:12.080 A little bit slow. s275 00:28:31.919 --> 00:28:32.159 Yeah. s276 00:28:32.159 --> 00:28:42.000 Does everyone have Yes. s277 00:28:48.720 --> 00:28:49.279 Yeah, sure. s278 00:28:49.279 --> 00:28:55.360 So, the question is, can I recount how I got to here while we're we're waiting for Claude to come along? s279 00:28:55.360 --> 00:29:02.480 So, basically, um the QR codes that are being passed around, there's two here. s280 00:29:02.480 --> 00:29:06.080 uh one of them is uh to enroll in the course. s281 00:29:06.080 --> 00:29:08.080 So the course that I'm going through is online. s282 00:29:08.080 --> 00:29:17.039 It's freely available so anyone can go uh once once you show up inside of the course basically you'll see a button here to enroll. s283 00:29:17.039 --> 00:29:19.679 Um so you have to sign in and enroll in the course. s284 00:29:19.679 --> 00:29:26.080 Uh once you do that you'll you'll click through and you'll make it to this environment section. s285 00:29:26.080 --> 00:29:33.840 Um, and when you do that, uh, it'll take about five minutes or so for everything to to populate and come up. s286 00:29:33.840 --> 00:29:37.760 Um, if you're using code spaces, you have the option to run it locally. s287 00:29:37.760 --> 00:29:48.720 Um, but then once you do that, essentially, um, 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, s288 00:29:48.720 --> 00:29:52.320 um, as well as the, uh, the BigQuery key here. s289 00:29:52.320 --> 00:29:58.320 Um, and then once you do that, you'll be able to um access all the things in the workshop. s290 00:29:58.320 --> 00:30:04.080 Basically, um, you're using, as you saw here, um, oh, cool. s291 00:30:04.080 --> 00:30:06.000 We're actually making progress. s292 00:30:06.000 --> 00:30:11.840 Um, we're using cloud code inside of inside of code spaces here. s293 00:30:15.360 --> 00:30:18.799 Sorry, can you repeat that really quick? s294 00:30:21.279 --> 00:30:21.600 Yes. s295 00:30:21.600 --> 00:30:39.840 The Neo Forj sandbox is um if I if I were to go back to that environment section um you see the button here to open code space and then you should have down here s296 00:30:39.840 --> 00:30:42.960 um your own sandbox credentials. s297 00:30:42.960 --> 00:30:51.200 So, it won't be these exact ones because it's it's different for every participant, but you'll go ahead and copy those. s298 00:30:51.200 --> 00:30:58.080 And then once you're in here, uh you'll be able to um you have your environment file. s299 00:30:58.080 --> 00:31:05.039 And inside of your environment file where you put your anthropic and your BigQuery key, you'll also put the Neo Forj ones. s300 00:31:05.039 --> 00:31:13.679 If you don't see a environment file and you see nothing or you see the end.ample, example, it just takes it a while to populate that. s301 00:31:13.679 --> 00:31:14.960 There's other things that are running. s302 00:31:14.960 --> 00:31:22.159 It's running another shell script to kind of create everything for you and um populate all the different files. s303 00:31:22.240 --> 00:31:35.600 So, my my hunch, and someone can scream at me if I'm wrong, is that if Anthropics this slow right now, it's more of a anthropic problem and not necessarily a one person's account problem. s304 00:31:35.600 --> 00:31:43.200 Um, 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. s305 00:31:43.200 --> 00:31:45.760 I think it's it's s306 00:31:45.760 --> 00:31:46.399 Yeah. s307 00:31:46.399 --> 00:31:50.559 Well, yeah, but this should also be running remotely, right? s308 00:31:50.559 --> 00:31:52.640 Is it Is it just the Wi-Fi? s309 00:31:52.640 --> 00:31:54.640 Okay. s310 00:31:55.760 --> 00:31:56.320 Yeah. s311 00:31:56.320 --> 00:31:58.640 Well, the funny thing is I would think in Well, never mind. s312 00:31:58.640 --> 00:31:59.039 I don't know. s313 00:31:59.039 --> 00:32:05.440 It's running in Codespaces, but maybe Code Spaces is still using the the local uh the local Wi-Fi. s314 00:32:05.440 --> 00:32:08.640 Um, okay. s315 00:32:08.640 --> 00:32:10.559 So, so we're back here. s316 00:32:10.559 --> 00:32:25.840 Basically, what basically what it did to grab this list is um it it went through and it it basically read um that metadata graph um and then it created the um s317 00:32:25.840 --> 00:32:28.559 the different uh queries that it wanted to run. s318 00:32:28.559 --> 00:32:38.080 You can see it ran that the small SQL uh Python file um and it it did all of its selects and it joins to be able to to pull together s319 00:32:38.080 --> 00:32:43.360 uh these tables that list out um the the answer to that question essentially. s320 00:32:43.360 --> 00:32:50.159 Um if I was to go back the question here was uh what would we ask? s321 00:32:50.159 --> 00:32:53.200 Go back to the connection shape. s322 00:32:54.320 --> 00:33:04.559 Um yeah, which vehicles received, you know, these these separate parts over here. s323 00:33:04.559 --> 00:33:13.600 Um and and it it provided that list um down here by by make apparently um and then vehicle count. s324 00:33:13.840 --> 00:33:17.200 Um so that's the basics of this first shape. s325 00:33:17.200 --> 00:33:28.000 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 um to then help essentially guide how everything joins together. s326 00:33:28.000 --> 00:33:36.480 Uh in this case, it used a primary foreign key uh relationship inside of the information schema inside of BigQuery uh to enforce that. s327 00:33:36.480 --> 00:33:45.600 Neoarta 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. s328 00:33:45.679 --> 00:33:56.640 Um, are there any uh questions about this first sort of connections graph semantic layer shape that we're working with? s329 00:33:57.600 --> 00:34:00.559 Yes, I have one over here. s330 00:34:14.240 --> 00:34:15.359 Neo for you. s331 00:34:15.359 --> 00:34:26.879 So the question was can you give us more context into the Neo Forj near quarter like what we're doing strategically um so what Neo Forj is doing strategically and this right here so s332 00:34:26.879 --> 00:34:42.159 Neo forj as a company right we're 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 s333 00:34:42.159 --> 00:34:49.839 and you need to find an optimal route from point A to B and you have to do these like variable length, you know, shortest path type of calculations. s334 00:34:49.839 --> 00:34:52.399 A graph database is very good for that. s335 00:34:52.399 --> 00:35:05.920 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 s336 00:35:05.920 --> 00:35:07.599 how tables might interrelate. s337 00:35:07.599 --> 00:35:17.920 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. s338 00:35:17.920 --> 00:35:30.160 And so we're focused a lot right now on these concepts of ontologies and semantic layers and what we're calling virtual graph where the focus isn't only just etling data in but about okay s339 00:35:30.160 --> 00:35:41.520 maybe you want to keep your data where it is and you still want to use SQL and and access it in in the ways you have been but you need some way to sort of guide the agent to be able to do that correctly. s340 00:35:41.520 --> 00:35:44.079 Um so Neo Carta is a labs project. s341 00:35:44.079 --> 00:35:56.640 We also uh just recently um in preview have released uh something called virtual graph which will be similar but it essentially gives you um almost like these push down cipher queries. s342 00:35:56.640 --> 00:36:09.680 So it gives you a graph schema of your of your database and then it allows you to run cipher directly um 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. s343 00:36:09.680 --> 00:36:20.880 So, there was a table in there um in the previous section that was kind of explaining that, but hopefully that's helpful so you understand kind of where where we're going with things. s344 00:36:23.680 --> 00:36:24.000 Yeah. s345 00:36:24.000 --> 00:36:24.320 Yep. s346 00:36:24.320 --> 00:36:25.200 Grap and Yes. s347 00:36:25.200 --> 00:36:31.599 And we're doing a ton of stuff inside of context graphs as well and and and um and all of those layers. s348 00:36:31.599 --> 00:36:33.599 Yep. s349 00:36:33.599 --> 00:36:34.000 All right. s350 00:36:34.000 --> 00:36:34.720 Awesome. s351 00:36:34.720 --> 00:36:37.760 Um any other questions? s352 00:36:37.760 --> 00:36:41.200 Okay, I have one question over here. s353 00:37:03.359 --> 00:37:03.760 Yeah. s354 00:37:03.760 --> 00:37:15.040 So, so the question is um why would we not take our OOLTP data which is right now is this warehouse of vehicle orders and and stuff and just migr s355 00:37:16.960 --> 00:37:18.240 or or some subset of it. s356 00:37:18.240 --> 00:37:20.240 Why wouldn't we just push that into the graph? s357 00:37:20.240 --> 00:37:25.760 Well, I think in a lot of cases that's easier said than done, right? s358 00:37:25.760 --> 00:37:32.960 Because if you think about a lot of production use cases, you can have terabytes of data which gets updated continuously. s359 00:37:32.960 --> 00:37:39.920 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. s360 00:37:39.920 --> 00:37:49.119 Um, and there's 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. s361 00:37:49.119 --> 00:37:57.200 And then a lot of times what people end up not really understanding until they get in those situations is the security posture. s362 00:37:57.200 --> 00:38:08.560 Because if you have sensitive data that's in one system, it might not even though you could physically move it in, you you might not actually be able to for security reasons take that data and just move it into another database. s363 00:38:08.560 --> 00:38:14.400 Um so so there's various reasons why you might not necessarily want to move your data over. s364 00:38:14.400 --> 00:38:24.480 Uh 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? s365 00:38:24.480 --> 00:38:40.000 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 s366 00:38:40.000 --> 00:38:42.000 sense to to bring the data in. s367 00:38:42.000 --> 00:38:51.680 Um and then as we'll see in the next sections when your data is already unstructured uh there's benefits to bringing it into a graph because then you can give it a graph structure. s368 00:38:51.920 --> 00:38:53.359 All right. s369 00:38:53.359 --> 00:38:55.280 I saw one other question over here. s370 00:38:55.280 --> 00:38:57.280 Yes. s371 00:39:03.040 --> 00:39:08.320 So the the question is does it rebuild the graph every time you initialize Neo Carta? s372 00:39:08.320 --> 00:39:20.880 And the answer to that question is no. What it will do is basically when uh we we ran that build connection script um it went ahead and ran an MCP server function that s373 00:39:20.880 --> 00:39:28.079 ports the data in um and then once it's ingested into Neoarta just the metadata then that stays there. s374 00:39:28.079 --> 00:39:33.839 So like for me I didn't rerun that build connections right because I just took the course last night. s375 00:39:33.839 --> 00:39:39.599 Um so like for me I and I probably could have because I I think it's an item pot and load but I just didn't want to deal with it. s376 00:39:39.599 --> 00:39:44.079 So, it was there for me and then I just ran the queries on top of it. s377 00:39:44.079 --> 00:39:46.079 Yep. s378 00:39:46.640 --> 00:39:47.040 All right. s379 00:39:47.040 --> 00:39:49.839 Any any other questions? s380 00:39:50.640 --> 00:39:53.599 I have one over here at the end. s381 00:39:53.599 --> 00:39:53.920 Yes. s382 00:39:53.920 --> 00:39:54.320 Yes. s383 00:39:54.320 --> 00:39:56.320 You s384 00:40:04.800 --> 00:40:07.839 the the Neo Forj cipher skill. s385 00:40:07.839 --> 00:40:14.960 Um, so I don't know if I might be able to uh grab it really quick. s386 00:40:14.960 --> 00:40:19.760 Um, I can show you Neo forj cipher skill. s387 00:40:26.720 --> 00:40:29.760 But this is these are all developed internally by our team. s388 00:40:29.760 --> 00:40:34.640 So if you go here actually through the Neo Forj CL, you can download a ton of these skills. s389 00:40:34.640 --> 00:40:47.119 So if you see here, there's 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 or all those things. s390 00:40:47.119 --> 00:41:03.839 Um, 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, you know, cipher 2526. s391 00:41:03.839 --> 00:41:08.160 Um, so so it it it has all of the latest. s392 00:41:08.160 --> 00:41:18.880 So I' I'd encourage you to use the Neo Forj CLI because it will basically you can load one or multiple of these skills and you'll get the latest knowledge s393 00:41:18.880 --> 00:41:30.319 there because it otherwise what what it's going to do is it's going to go on the internet and get the Stack Overflow questions from like four or five or six years ago and it's going to give you outdated bad cipher basically. s394 00:41:31.520 --> 00:41:33.119 CLI s395 00:41:33.119 --> 00:41:33.760 it is. s396 00:41:33.760 --> 00:41:35.440 Yes, it is loaded in. s397 00:41:35.440 --> 00:41:48.480 And uh if you look at the um the install file that we use inside of dev container, uh you'll see um where we installed the Neo Forj agent client, the skill. s398 00:41:48.480 --> 00:41:53.599 So the commands in there um that that basically allowed you to do that. s399 00:41:54.240 --> 00:42:00.800 All righty, 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. s400 00:42:00.800 --> 00:42:03.440 Yes, right there. s401 00:42:17.599 --> 00:42:33.280 um bronze so like the different like delta tables where um so I mean we're we're exploring basically um the traditional like SQL structured data warehouse and then NeoAR Carta s402 00:42:33.280 --> 00:42:35.599 is really customer-driven for us. s403 00:42:35.599 --> 00:42:37.680 It was made by our field team. s404 00:42:37.680 --> 00:42:50.720 So as customers come in and they have questions about less un less structured data um and even things like documents have been considered for Neo Carta and so there's this backlog that's forming right now. s405 00:42:50.720 --> 00:42:52.400 Everything's moving very fast. s406 00:42:52.400 --> 00:43:03.680 I think I mean Ryan is is somewhere in the room and he might be able to to speak on sort of what's what's the next thing for Neo Carta, but I know we're working right now on a data bricks connector s407 00:43:03.680 --> 00:43:07.839 um and maybe some metric views and other things. s408 00:43:16.720 --> 00:43:17.599 All right, awesome. s409 00:43:17.599 --> 00:43:26.800 So meet with uh with Ryan afterwards and then everyone watching on YouTube I guess can meet with Ryan afterwards but by then we'll we'll have we'll have an amazing Neil Carta. s410 00:43:26.800 --> 00:43:28.640 So all righty. s411 00:43:28.640 --> 00:43:40.640 So 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 just to give ourselves a little bit of a breather. s412 00:43:40.640 --> 00:43:43.359 So now I'm going to jump to the next section. s413 00:43:43.359 --> 00:43:50.319 And so that was working with structured data and now I want to work with unstructured data. s414 00:43:50.319 --> 00:43:53.440 And this is going to be the documents part. s415 00:43:53.440 --> 00:44:01.760 So we have if we go over to our little uh our little uh source data stuff here. s416 00:44:01.760 --> 00:44:06.640 So in this case I'm going to read them locally to load them. s417 00:44:06.640 --> 00:44:11.599 Um but you know it's reading from cloud storage reading locally. s418 00:44:11.599 --> 00:44:14.800 Um there there often isn't a huge difference. s419 00:44:14.800 --> 00:44:19.680 Um basically we have these bulletins in PDFs. s420 00:44:19.680 --> 00:44:23.440 Um we have manuals which are considerably longer. s421 00:44:23.440 --> 00:44:25.760 Um and then we have recalls as well. s422 00:44:25.760 --> 00:44:37.440 And because it's giving me this funky view, I also have them in uh in this raw corpus where they're they're inside of um these uh markdown files here. s423 00:44:37.440 --> 00:44:42.160 Um, but basically, uh, there are these multi-section documents. s424 00:44:42.160 --> 00:44:50.640 Um, and you'll see here that they have, uh, this linking that they do to go over to different sections in other documents. s425 00:44:50.640 --> 00:44:54.240 So, they're all kind of interlin together as they refer to one another. s426 00:44:54.240 --> 00:45:05.760 Um, so, for example, right inside of inside of this manual, um, it talks about these different platform codes for this ABS system, um, and diagnostic troubleshooting, right? s427 00:45:05.760 --> 00:45:07.200 and it will link over to there. s428 00:45:07.200 --> 00:45:09.359 All of this data, by the way, is I simulated. s429 00:45:09.359 --> 00:45:11.920 It's not sensitive or or anything like that. s430 00:45:11.920 --> 00:45:20.800 Um, but it's meant to simulate kind of a real world uh system where you have these manuals and bulletins and recalls of all these different vehicles. s431 00:45:20.800 --> 00:45:28.000 And um what we want to accomplish with this basically is we want to give our agent a table of contents. s432 00:45:28.000 --> 00:45:32.240 And and by a table of contents, I mean something that looks like this thing. s433 00:45:32.240 --> 00:45:38.720 So, what I want to allow the agent to do here is not just search for key terms. s434 00:45:38.720 --> 00:45:44.960 We'll give it search too, but I don't know if has anyone heard of like page index? s435 00:45:44.960 --> 00:45:46.880 Anyone know who they are? s436 00:45:46.880 --> 00:45:47.839 Maybe some of you. s437 00:45:47.839 --> 00:45:59.599 So, there's 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 not I'll call this outline. s438 00:45:59.599 --> 00:46:00.880 I'll call it table of contents. s439 00:46:00.880 --> 00:46:03.920 I need to get the terminology a little bit better aligned. s440 00:46:03.920 --> 00:46:14.560 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. s441 00:46:14.560 --> 00:46:16.640 You have the bulletins which is a subfolder. s442 00:46:16.640 --> 00:46:18.560 Then you have these documents underneath. s443 00:46:18.560 --> 00:46:21.520 And so you have this containment tree. s444 00:46:21.520 --> 00:46:30.560 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. s445 00:46:30.560 --> 00:46:34.960 So it's more than just a table of contents that's a tree that goes down. s446 00:46:34.960 --> 00:46:38.160 It also has these links, right? s447 00:46:38.160 --> 00:46:42.960 And these links and basically everything in here have a URI. s448 00:46:42.960 --> 00:46:51.520 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. s449 00:46:51.520 --> 00:46:56.240 So you see like you have your technical library here, right? s450 00:46:56.240 --> 00:46:58.079 And then slashbulletins. s451 00:46:58.079 --> 00:47:13.200 So, like if I'm down in, you know, this TSB recall notice, I know that it's part of bulletins, um, or safety bulletin, rather, not a recall, and it's part of a technical library, just like it's also linking to a manual s452 00:47:13.200 --> 00:47:14.079 here. s453 00:47:14.079 --> 00:47:19.359 Um, and you can see the name of the manual, then it's inside of the manual subfolder. s454 00:47:19.359 --> 00:47:27.280 Um, 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 s455 00:47:27.280 --> 00:47:30.079 text or or even a link to the raw text. s456 00:47:30.079 --> 00:47:41.440 And so, and then if I uh plug this in and we'll see how this works with outline later, I can actually get these sub trees so I can like dig in and drill down on these different pieces of content. s457 00:47:41.440 --> 00:47:43.680 Um, that's the general idea with this. s458 00:47:43.680 --> 00:47:53.040 And so what this gives the agent to do is not just search like vector search or or lexical search but actually kind of traverse through the documents in a sense. s459 00:47:53.040 --> 00:48:02.480 Um and the data model that we're going to use in this case we're actually going to import the data into graph. s460 00:48:02.480 --> 00:48:07.200 Um I have a I have a quick question for everyone. s461 00:48:07.200 --> 00:48:09.839 So, everyone here is knows Graphrag. s462 00:48:09.839 --> 00:48:16.560 When they think of Graphrag, and maybe someone can raise your hand and I'll I'll pick on someone for a second. s463 00:48:16.560 --> 00:48:23.359 I want you to tell me what you think like the pro the the building the graph process is for Graph Frag. s464 00:48:23.359 --> 00:48:27.359 So, I don't know if anyone wants to wants to volunteer if they're familiar. s465 00:48:27.359 --> 00:48:30.160 You're going to raise your hand. s466 00:48:30.480 --> 00:48:32.480 Yes. s467 00:48:44.640 --> 00:48:44.880 Yeah. s468 00:48:44.880 --> 00:48:53.359 And they build they build the they build the links from from the So there's different ways, right? s469 00:48:53.359 --> 00:49:02.960 And and you said I think in in your when you talk about creating um a graph, you build the links from the data that's inside of the documents, right? s470 00:49:02.960 --> 00:49:09.359 And so graph rag oftentimes we have an entity extraction piece to it as well. s471 00:49:09.359 --> 00:49:21.119 So we can use an LLM to kind of say hey like extract the different parts the different vehicles from the from the graph and have them be separate entities s472 00:49:21.119 --> 00:49:26.160 and then have those links to like the original document chunks and all all of this stuff. s473 00:49:26.160 --> 00:49:28.800 And that's great and that works really well. s474 00:49:28.800 --> 00:49:41.040 Um 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 um we're actually going to use a deterministic s475 00:49:41.040 --> 00:49:42.079 loading. s476 00:49:42.079 --> 00:49:50.559 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. s477 00:49:50.559 --> 00:50:05.200 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. s478 00:50:05.200 --> 00:50:08.880 Um, and then you'll have um next section links. s479 00:50:08.880 --> 00:50:22.800 So you get a concept of ordering as well as linked to which uses in this case we're using um these named links uh sort of like you might see inside of an Obsidian vault a little bit s480 00:50:22.800 --> 00:50:28.240 um but you can also do it with hyperlinking and other things depending on depending on what your data looks like. s481 00:50:28.240 --> 00:50:36.800 So, it's all deterministic with the containment tree for one and then the ordering of the sections as well as the links. s482 00:50:36.800 --> 00:50:42.319 Um, and the benefits of having a deterministic load like this is number one, it's going to be item potent. s483 00:50:42.319 --> 00:50:46.079 Um, so like you're not relying on an LLM in the beginning. s484 00:50:46.079 --> 00:50:48.800 Um, it's often going to be a little bit faster. s485 00:50:48.800 --> 00:51:05.839 Um and so if you already have documents which have a lot of inherent structure to them and a lot of interlinking um 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 document structure graph rather than like a full s486 00:51:05.839 --> 00:51:11.760 like entity uh you know extraction type of pipeline to create a graph. s487 00:51:11.760 --> 00:51:16.880 Um and it it explains here what I just said with the different link types. s488 00:51:16.880 --> 00:51:21.760 Um and then and and like I said before these URLs carry a hierarchy. s489 00:51:21.760 --> 00:51:41.119 So every node for example that that head node at the top here for the library will get its URI manuals will have that plus back slashmanuals um going down sort of the containment tree to the to the file name and then the different sections s490 00:51:41.760 --> 00:51:45.760 and um this is the script you're going to copy to load it in. s491 00:51:45.760 --> 00:51:50.640 So basically again you'll take this, you'll go over to here. s492 00:51:50.640 --> 00:51:52.960 Um you'll open your bash terminal. s493 00:51:52.960 --> 00:51:58.559 Now I believe I've already done this so I'm not going to run it again even though I I'm pretty sure it's item potent. s494 00:51:58.559 --> 00:52:06.400 Um but basically once you run that um what you'll end up getting is and I'll just make sure it's actually in the graph. s495 00:52:06.400 --> 00:52:07.520 It is for me. s496 00:52:07.520 --> 00:52:10.640 You'll end up getting that uh that model that we just saw. s497 00:52:10.640 --> 00:52:14.240 It should only take Well now it might take a while if the Wi-Fi is slow. s498 00:52:14.240 --> 00:52:15.760 although I don't think it should. s499 00:52:15.760 --> 00:52:28.880 Um, 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 s500 00:52:28.880 --> 00:52:30.800 followed up here into our different sections. s501 00:52:30.800 --> 00:52:39.520 And if I were to zoom in here, um, you'll see we have the has links in the next section, but then we also have the links too. s502 00:52:39.520 --> 00:52:47.440 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. s503 00:52:48.640 --> 00:52:56.079 And now that we have that, um, basically in the next section, we can go ahead and build our tool. s504 00:52:56.079 --> 00:53:11.839 Um, basically the script that goes along with our our custom autofix skill that we've created uh to um to actually like create that outline shape that we saw in the beginning, the the table of contents s505 00:53:11.839 --> 00:53:13.839 to hand our agent. s506 00:53:13.839 --> 00:53:25.200 And so if I go ahead to that next section, um, and again, like I said, what I want to do here is I'm going to go ahead and copy this. s507 00:53:25.200 --> 00:53:28.000 This is the this is the prompt. s508 00:53:28.000 --> 00:53:39.040 Um, where if I go ahead and feed that to my claude, it should go ahead and get to work. s509 00:53:44.480 --> 00:53:48.400 And because I know that's going to take a while, I'm going to have it start running here. s510 00:53:48.400 --> 00:54:04.079 But basically, what it's doing as it goes through um is if I go under and I look at my skills, um you'll see that I left inside of here s511 00:54:04.079 --> 00:54:06.160 um this wired query. s512 00:54:06.160 --> 00:54:11.839 This is this is the query that it needs to create um to be able to create that outline shape. s513 00:54:11.839 --> 00:54:23.040 And I've instructed it inside of the language here to use the Neo Forj cippher skill and reference a spec in doc outline format.m MD. s514 00:54:23.040 --> 00:54:31.680 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. s515 00:54:31.680 --> 00:54:40.800 Um, 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, s516 00:54:40.800 --> 00:54:41.280 right? s517 00:54:41.280 --> 00:54:56.000 And then it it talks here about how it needs to be human readable and uh yes, we will allow you to edit and um and some of the optional arguments it needs to have. s518 00:54:56.000 --> 00:55:03.200 So, right, because oftent times it's like pseudo code that we'll have and we don't know exactly how to put it together. s519 00:55:03.200 --> 00:55:18.720 Um, um, in this case, I did give it the hint about having a variable length path query uh to basically put everything uh put everything in order. s520 00:55:20.233 --> 00:55:22.233 [snorts] s521 00:55:28.240 --> 00:55:30.800 And then it will say when it's done. s522 00:55:30.800 --> 00:55:43.119 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 s523 00:55:43.119 --> 00:55:56.480 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 inside of the query. s524 00:55:56.480 --> 00:56:09.520 So like uh if I go back to my um me go to where it changed um if I go back to here it's it's parameterized inside of this string. s525 00:56:09.520 --> 00:56:13.040 So it gives you like an option to how deep you want to traverse. s526 00:56:13.040 --> 00:56:18.720 Um and that that's sort of the graphy nature of kind of putting together this table of contents. s527 00:56:18.720 --> 00:56:24.720 There's there's a second query in here too which is much simpler which just grabs the links after that. s528 00:56:24.720 --> 00:56:35.040 Um so that basically uh once that's done I can go ahead and um copy I'll run the whole thing. s529 00:56:35.040 --> 00:56:43.200 If if you just run the script without any depth parameter or without a specific URI, it's going to return everything in the graph. s530 00:56:43.200 --> 00:56:47.520 So it wouldn't be the way that I'd I'd run it with with a larger graph here. s531 00:56:47.520 --> 00:56:51.040 We end up with because we only have a couple hundred documents. s532 00:56:51.040 --> 00:56:53.599 Um so I can get away with it here. s533 00:56:53.599 --> 00:57:02.079 Um, but if I ran that, um, it'll it'll bring back a ton. s534 00:57:02.079 --> 00:57:08.960 And, but you can kind of see here, um, zoom out. s535 00:57:08.960 --> 00:57:11.680 So, you can see, right, that it gave me this. s536 00:57:11.680 --> 00:57:19.359 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 that it's providing. s537 00:57:19.359 --> 00:57:25.520 Um and then what you can do with this right is you can give it an optional depth parameter. s538 00:57:25.520 --> 00:57:29.200 So for example, if I just said depth equals one. s539 00:57:29.200 --> 00:57:39.440 Uh go you don't like clearing to the bottom and I say depth one. s540 00:57:39.440 --> 00:57:45.599 Then if I did that um it'll go ahead and just go one down. s541 00:57:45.599 --> 00:57:51.280 And then the other cool thing with this too is you can provide it a specific URI. s542 00:57:51.280 --> 00:58:05.839 So if I saw you know a specific URI here that I wanted to give it um then it will basically start at that Falcon 2.0 no document just like s543 00:58:05.839 --> 00:58:17.440 you know if I um if I was here now and say okay well actually you know I want to do um I want to do it but I want to do it for something that I see up above like s544 00:58:17.440 --> 00:58:34.559 maybe this links to you know this um 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 you know that document and everything it links to. s545 00:58:34.559 --> 00:58:43.760 So you can say see how an agent can go through now and sort of grab these URIs and kind of traverse all through the through the graph and give itself these hierarchical s546 00:58:43.760 --> 00:58:46.480 and and linked views. s547 00:58:50.720 --> 00:58:56.000 Um the okay yeah why don't we why don't we take a second for questions. s548 00:58:56.000 --> 00:58:59.200 So we have one in the middle here. s549 00:59:09.200 --> 00:59:28.000 Um well so later in the course I'll in the workshop here for some of the last questions I do instruct the agent to say exactly what steps it followed. s550 00:59:28.000 --> 00:59:32.240 Um are you seeing it use something different? s551 00:59:34.319 --> 00:59:36.319 Right. s552 00:59:37.280 --> 00:59:38.079 Yeah. s553 00:59:38.079 --> 00:59:41.520 So it should be apparent in the tool call history. s554 00:59:41.520 --> 00:59:50.640 Um so you can 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. s555 00:59:50.640 --> 00:59:52.640 So those should be inside of your tool calls. s556 00:59:52.640 --> 01:00:05.440 And the question by the way for everyone if if you couldn't hear um it was just how do you know that the agent's actually calling the things that it's supposed to right yeah so so for cloud code for example you can look at the tool call history s557 01:00:05.440 --> 01:00:18.960 um and informally what I'll do in this course is for some of the prompts I'll I'll just direct it to say like hey like clearly like say like what steps and logic you use to be able to to answer this question. s558 01:00:18.960 --> 01:00:28.400 Um, you know, obviously for a production system, you would you would want to look at the logs and everything, but for here and for learning, I I that's how I'll I'll expose it. s559 01:00:28.400 --> 01:00:34.240 Um, is there are there any other questions about uh trees outlines? s560 01:00:37.200 --> 01:00:37.520 Yes. s561 01:00:37.520 --> 01:00:40.000 One right here. s562 01:00:45.920 --> 01:00:47.280 Yeah. s563 01:00:47.280 --> 01:00:47.680 Yeah. s564 01:00:47.680 --> 01:01:01.280 So, um it is uh all the code for that should be in uh oh yeah, we'll need to restart. s565 01:01:01.280 --> 01:01:03.359 Um oh, that was a different codebase. s566 01:01:03.359 --> 01:01:04.799 Thank Thank goodness. s567 01:01:04.799 --> 01:01:05.280 All right. s568 01:01:05.280 --> 01:01:16.319 Um yes, inside of load, if you go to load documents, this is this is just the cipher queries. s569 01:01:16.319 --> 01:01:21.280 And then you have your parse corpus um down here. s570 01:01:21.280 --> 01:01:27.920 So yeah, it's basically just using regx in here to try to find, you know, the the right stuff. s571 01:01:27.920 --> 01:01:32.640 In this case, the documents are already fairly well structured, right? s572 01:01:32.640 --> 01:01:36.960 So mileage may vary depending on what your document sources are. s573 01:01:36.960 --> 01:01:44.160 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. s574 01:01:44.160 --> 01:01:53.599 If it's messier, you might have to use like um you know, gler or different types of looms and there's stages of complexity for that. s575 01:01:53.599 --> 01:01:54.319 All right. s576 01:01:54.319 --> 01:01:57.440 Yes, we have a question over here. s577 01:02:01.359 --> 01:02:03.359 Yes. s578 01:02:09.280 --> 01:02:10.079 Yep. s579 01:02:10.079 --> 01:02:11.599 Can be done with any model. s580 01:02:11.599 --> 01:02:24.640 The only thing that Neoarta and any of these tools well neo I'll start with neocarta neocarta is really responsible for creating that semantic layer metadata graph and providing you an MCP endpoint s581 01:02:24.640 --> 01:02:42.799 right so as long as you can access that MCP server it's model agnostic okay so that was 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 is yes we're using a skills framework and then in and then for Neo Carta s582 01:02:42.799 --> 01:02:53.760 we have MCP um Neo Carta also has a CLI so there's there's other ways to access it too um I have one question all the way in back there s583 01:03:09.839 --> 01:03:24.559 So the question is around if 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. s584 01:03:24.559 --> 01:03:28.640 So in this case, we have a very deterministic load. s585 01:03:28.640 --> 01:03:32.319 So we're deciding ahead of time what to name our relationships. s586 01:03:32.319 --> 01:03:37.280 Um, and that is a bit of a a taste or a judgment call, right? s587 01:03:37.280 --> 01:03:40.960 Uh, I tried to keep it simple here where has is very simple. s588 01:03:40.960 --> 01:03:42.799 It's a containment relationship. s589 01:03:42.799 --> 01:03:46.480 I also know that I'm going to want containment going multiple levels. s590 01:03:46.480 --> 01:03:55.359 So, I probably want a common name for all of those because if I have like has folder, has document section, it makes the cipher complicated. s591 01:03:55.359 --> 01:03:58.480 Um, so that's sort of why I kept that naming very short. s592 01:03:58.480 --> 01:04:00.160 Same with links too. s593 01:04:00.160 --> 01:04:11.359 Um the more granular you get with naming um basically the more sort of detailed uh your agent can be and your end tools can be in putting a query together. s594 01:04:11.359 --> 01:04:14.720 But then the more complicated your data model becomes. s595 01:04:14.720 --> 01:04:23.520 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 s596 01:04:23.520 --> 01:04:34.160 um 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 Neo Forj CL or humans, right? s597 01:04:34.160 --> 01:04:40.000 When we're trying to, you know, write our own uh sort of parameterized queries. s598 01:04:45.599 --> 01:04:46.079 Yep. s599 01:04:46.079 --> 01:04:47.520 Yeah, that's true too. s600 01:04:47.520 --> 01:04:58.319 Um, and we see that right that that's the whole semantic layer argument too with on the warehouse side is you can have these metrics views and other things which use business terminology that might be different from s601 01:04:58.319 --> 01:05:01.680 sort of the the physical data model that you have, right? s602 01:05:01.680 --> 01:05:09.920 Um, and so that's that's part of the reason why we have these metadata graphs to to help manage that sort of different or that delta between them. s603 01:05:09.920 --> 01:05:12.640 I'll take a couple more questions and then we'll we can move on. s604 01:05:12.640 --> 01:05:14.640 Yep. s605 01:05:27.200 --> 01:05:29.200 Yeah, that's an interesting question. s606 01:05:29.200 --> 01:05:42.640 Um, 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 s607 01:05:42.640 --> 01:05:43.359 work I do. s608 01:05:43.359 --> 01:05:47.200 I use at least full text search um, with this sort of stuff. s609 01:05:47.200 --> 01:05:53.440 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. s610 01:05:53.440 --> 01:06:04.720 Um, there's certain things that semantic search is not as great at answering that really require document navigation to understand how like everything connects together, right? s611 01:06:04.720 --> 01:06:09.039 Um, so big examples would be like proving something doesn't exist. s612 01:06:09.039 --> 01:06:11.760 Like how do you do that with semantic search, right? s613 01:06:11.760 --> 01:06:21.680 or understanding um even like how you know there might be different parts related to a specific document or something. s614 01:06:21.680 --> 01:06:33.280 You know, you could in theory do like a bunch of vector queries to keep pulling passages, but there's more, you know, chance for error that you might not catch the right document and all this sort of stuff. s615 01:06:33.280 --> 01:06:38.319 Um so yeah, not the question was if it's a replacement for semantic search and I don't think it is. s616 01:06:38.319 --> 01:06:45.119 No. Um, one more in uh back there. s617 01:06:57.039 --> 01:07:09.839 So, um the question is do we redefine the types of nodes um as well as the relationships and so is this a question of like how do you decide what the node labels should be? s618 01:07:09.839 --> 01:07:10.559 Um, yeah. s619 01:07:10.559 --> 01:07:13.760 And again, it's it's again, it's a data modeling question, right? s620 01:07:13.760 --> 01:07:19.359 Like there could be a situation where we're looking at the data model that we just went over. s621 01:07:19.359 --> 01:07:21.680 Um, well, it's not it's not here. s622 01:07:21.680 --> 01:07:25.359 It's in my uh it's in my last one. s623 01:07:25.359 --> 01:07:40.799 um when I look at the uh when I look at the shape um zoom out of that a little bit where it might be useful to have like an actual parts node or something s624 01:07:40.799 --> 01:07:54.799 right um 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 and query SQL or the or the other way around. s625 01:07:54.799 --> 01:07:57.119 Um, and that works for me. s626 01:07:57.119 --> 01:08:05.680 So, you know, it's still as as things evolved, like two years ago, I probably would have said you would need that like additional node. s627 01:08:05.680 --> 01:08:10.400 Now, it seems like agents are smart enough where maybe you don't all the time anymore. s628 01:08:10.400 --> 01:08:26.319 Um and but for some use cases, you know, especially like we see this in life sciences for example, where there's these really specific ontologies around, you know, different types of molecules and medications and things and you you really do need that represented in the graph or else s629 01:08:26.319 --> 01:08:28.799 it just your inference isn't going to make sense. s630 01:08:28.799 --> 01:08:32.239 So I hate to say it depends on use case. s631 01:08:32.239 --> 01:08:36.640 I don't want to be that person, but it it sort of does in a sense. s632 01:08:36.640 --> 01:08:37.520 All right. s633 01:08:37.520 --> 01:08:39.920 Um, oh, okay. s634 01:08:39.920 --> 01:08:47.040 Yeah, let me let me move on only because we're a little bit over halfway through and I have some more course to to get through here. s635 01:08:47.040 --> 01:08:54.719 So, um, let's go to So, we went over all of this stuff. s636 01:08:54.719 --> 01:08:56.480 Um, oh yes. s637 01:08:56.480 --> 01:09:00.319 So, we need to build our uh search query. s638 01:09:00.319 --> 01:09:14.239 So, similar to what we just did and to the the question that the gentleman had over here, uh we want to be able to um we want to be able to build s639 01:09:14.239 --> 01:09:18.480 um some sort of search as well to help augment this. s640 01:09:18.480 --> 01:09:24.400 So, um this is going to be much more simple, this search uh file. s641 01:09:24.400 --> 01:09:28.560 Um basically, I'm just going to use a lucine style index. s642 01:09:28.560 --> 01:09:32.239 Uh, and I I'm not going to use vector search here. s643 01:09:32.239 --> 01:09:43.199 It's the Neo Forj itself has um a lucine full text search index, but and I'm going to do and if you see here, it's basically doing the same thing where s644 01:09:43.199 --> 01:09:48.719 I have the uh this this wire that it has to fill in. s645 01:09:48.719 --> 01:09:51.679 Um, and it's going to use a cipher skill to do that. s646 01:09:51.679 --> 01:09:56.400 While it's it's running there, you're allowed to edit. s647 01:09:56.400 --> 01:10:01.600 Um, we might as well wait till it's done. s648 01:10:01.600 --> 01:10:03.040 All right, it's going to finish up. s649 01:10:03.040 --> 01:10:11.280 So, basically, uh, if you see here, it's the way this works is you call the full text index. s650 01:10:11.280 --> 01:10:15.120 Um, it's indexed on the document and the section nodes. s651 01:10:15.120 --> 01:10:20.560 Uh, so every node that has text in it, like we don't put folders through through this lucine index. s652 01:10:20.560 --> 01:10:23.120 Um, and then it will give you a score. s653 01:10:23.120 --> 01:10:33.280 Um and then because we have everything in those URI format um we can also scope it by subtree um basically with like a starts with filter. s654 01:10:33.280 --> 01:10:41.920 Uh so if I was to go back into this uh file um and I looked at the way that this query run I have this wear statement. s655 01:10:41.920 --> 01:10:47.199 Um so I'm applying this as a post filter basically where I'm doing the full text search first. s656 01:10:47.199 --> 01:10:50.560 Um and then I am filtering it by the URI. s657 01:10:50.560 --> 01:10:56.320 So I can say like only search under like this section of the manuals basically. s658 01:10:56.320 --> 01:11:01.920 Um so it just helps me refine my my search a little bit with those hierarchical URIs. s659 01:11:01.920 --> 01:11:13.600 Uh, and the other thing that I do, um, and and I do this because I work like in in the the research role that I have, I work with so many different AI models and on so many different platforms. s660 01:11:13.600 --> 01:11:22.480 Like you wouldn't think about it, but like choosing like and wiring like options to be like work with like six different vendors for vectors is kind of tough. s661 01:11:22.480 --> 01:11:27.760 So what I often do for this is I'll use something called semantic expansion. s662 01:11:27.760 --> 01:11:37.840 Um and basically what it does is it it instructs the AI model to say hey like use your world knowledge if someone asks for you know an engine shuttering s663 01:11:37.840 --> 01:11:40.560 that it might be a misfire or something else too. s664 01:11:40.560 --> 01:11:44.719 So it and because this is a lucine index um I can do that. s665 01:11:44.719 --> 01:11:52.560 So for example right I can say like misfire or rough idle and it will search for either of those. s666 01:11:52.560 --> 01:12:07.440 Um, if I go back to my bash script and I run that now that the uh thing's filled it in and then you'll see it'll give me my uh documents with with the scoring for for the different ones. s667 01:12:07.440 --> 01:12:10.960 And it I can also search as I was saying before under recall. s668 01:12:10.960 --> 01:12:16.640 So I can search for coils under just the recall uh subfolder library. s669 01:12:16.640 --> 01:12:18.800 So that would be the idea here. s670 01:12:18.800 --> 01:12:32.000 Um, so you can see it's still leveraging uh that hierarchical containment shape, the tree, um, but it's doing it through the URI um, ID structure so that it doesn't have to do as much graph reversal. s671 01:12:32.000 --> 01:12:35.920 It just sort of filters down to to things underneath. s672 01:12:37.520 --> 01:12:42.159 Um, all righty. s673 01:12:42.159 --> 01:12:43.520 Awesome. s674 01:12:43.520 --> 01:12:52.640 Um, are there any quick questions just around the search piece there? s675 01:12:52.640 --> 01:12:54.080 The lucine search. s676 01:12:54.080 --> 01:12:57.360 We have one question over here. s677 01:13:09.280 --> 01:13:09.600 Yeah. s678 01:13:09.600 --> 01:13:20.400 So the question is we just loaded the documents into the into lucine and then we're searching underneath different sections appropriate sections. s679 01:13:20.400 --> 01:13:20.719 Yeah. s680 01:13:20.719 --> 01:13:26.640 So basically if it might make more sense if we actually took a look at the the query that we're running here. s681 01:13:26.640 --> 01:13:32.560 So here's the I'll make it this big. s682 01:13:32.560 --> 01:13:38.719 Um so here's here's the cipher query and I'll I'll create a space here so you can kind of see it better. s683 01:13:38.719 --> 01:13:45.760 So we have a lucine index that we've set and we set it when we loaded the graph. s684 01:13:45.760 --> 01:13:49.040 We set it on the document and the section nodes. s685 01:13:49.040 --> 01:14:00.800 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 lucine s686 01:14:00.800 --> 01:14:04.159 is whatever I've fed it in with that script. s687 01:14:04.159 --> 01:14:14.800 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. s688 01:14:14.800 --> 01:14:26.880 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. s689 01:14:26.880 --> 01:14:32.000 So it's applying that post filter afterwards if that makes sense. s690 01:14:32.000 --> 01:14:32.960 Yeah. s691 01:14:32.960 --> 01:14:34.960 Yep. s692 01:14:36.719 --> 01:14:39.280 You have a question. s693 01:14:55.520 --> 01:15:04.320 So the question is if say you already have a graph and you haven't created your lucine index yet, could you prompt claude code to basically do this for you? s694 01:15:04.320 --> 01:15:11.520 Um so I I think yes to be honest I might have done that with this course initially. s695 01:15:11.520 --> 01:15:14.159 I might have actually had Claude do it. s696 01:15:14.159 --> 01:15:18.320 I can't remember because I' I've rebuilt this in in a in a few different ways. s697 01:15:18.320 --> 01:15:23.760 Um, but I think the answer to that is yes, your mileage may vary depending on your data. s698 01:15:23.760 --> 01:15:30.400 A lot of times with when you set up a lucine index too, it's like especially it's very flexible inside of Neo forj. s699 01:15:30.400 --> 01:15:38.640 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. s700 01:15:38.640 --> 01:15:47.120 So, you know, there there's a lot 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, s701 01:15:47.120 --> 01:15:48.560 you know, all those various options. s702 01:15:48.560 --> 01:15:57.120 But in general, yes, you you can have um you can use agentic coding to to help put this together for you. s703 01:15:57.280 --> 01:16:22.719 Um yes, in the middle there So the question is how important is it that the name of the documents be accurate for the agent to traverse it effectively? s704 01:16:22.719 --> 01:16:24.719 Um, s705 01:16:30.880 --> 01:16:32.719 I think I think it would. s706 01:16:32.719 --> 01:16:33.199 Yeah. s707 01:16:33.199 --> 01:16:42.480 If 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. s708 01:16:42.480 --> 01:16:46.640 So, it might misinterpret what a document means, right? s709 01:16:46.640 --> 01:16:53.520 Um that's why having the search augmentation alongside of it is useful because it can actually look in the document. s710 01:16:53.520 --> 01:16:58.800 Um with these things what I've seen because I use this actually for my own knowledgebased management. s711 01:16:58.800 --> 01:17:02.560 I have my own open source library that I use which has these tools. s712 01:17:02.560 --> 01:17:08.239 Um the biggest problem is when you have documents that are outdated or drifted, right? s713 01:17:08.239 --> 01:17:18.080 Um, so I've thought about, well, maybe we need to add like a last updated date or something or like um whether or not a document should be authoritative, right? s714 01:17:18.080 --> 01:17:21.199 Um, and the document naming is actually important. s715 01:17:21.199 --> 01:17:24.480 Um, and link naming as well is important too. s716 01:17:24.480 --> 01:17:35.600 Um, so if you're if you have links that um don't have like um I forget what it's called, but like in Obsidian, you can sort of you can name the you can give it um s717 01:17:35.600 --> 01:17:37.199 uh a synonym or something, right? s718 01:17:37.199 --> 01:17:45.199 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 s719 01:17:45.199 --> 01:18:05.840 um so that's when sometimes using like a language model inside of the ingest if you don't have that could could be beneficial um yes over here so when you get a new document that comes in s720 01:18:05.840 --> 01:18:21.199 um so the nice thing about this is that it's all an item potent 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 s721 01:18:21.199 --> 01:18:33.199 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 s722 01:18:33.199 --> 01:18:40.000 um work is you can say oh well I have one document that changed and I just want to update that one node. s723 01:18:40.000 --> 01:18:42.560 You just have to be aware of the fact that it links to other things. s724 01:18:42.560 --> 01:18:57.520 So it's like well if you got if you changed if you updated this document over here um if you changed its name then you have to you know did your other documents also update like the URL reference to that document. s725 01:18:57.520 --> 01:19:00.640 So there's little edge cases there that you have to work through. s726 01:19:00.640 --> 01:19:05.600 But um if you're able to do that maybe we can talk after and I can show you. s727 01:19:05.600 --> 01:19:12.080 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 sinking. s728 01:19:12.080 --> 01:19:14.080 Yep. s729 01:19:14.239 --> 01:19:15.440 All righty. s730 01:19:15.440 --> 01:19:21.440 Um is do you have your hand up back there? s731 01:19:21.440 --> 01:19:23.120 You're just scratching your head. s732 01:19:23.120 --> 01:19:24.400 All right. s733 01:19:24.400 --> 01:19:28.960 Um then I guess we have one question here. s734 01:19:48.719 --> 01:19:50.719 right? s735 01:20:04.960 --> 01:20:10.080 the default after something like page index would be search. s736 01:20:11.199 --> 01:20:12.080 Yeah. s737 01:20:12.080 --> 01:20:12.480 Yeah. s738 01:20:12.480 --> 01:20:23.280 So I think the question is the question basically like um for the way that the agent reasons about it that it would call outline first to then use like search. s739 01:20:23.280 --> 01:20:24.000 Yeah. s740 01:20:24.000 --> 01:20:24.239 Yeah. s741 01:20:24.239 --> 01:20:25.760 It it could work that way. s742 01:20:25.760 --> 01:20:31.760 It could work some way where it will search first to find a relevant document and then try to find everything it links to. s743 01:20:31.760 --> 01:20:35.360 In which case, it would be the opposite way around. s744 01:20:35.360 --> 01:20:36.880 All right, awesome. s745 01:20:36.880 --> 01:20:43.920 Let's um let's move on here then to make sure that we have time for all of our questions. s746 01:20:43.920 --> 01:20:47.199 Um so what are we doing here? s747 01:20:50.480 --> 01:20:57.360 This is just more asking more full text search. s748 01:20:57.360 --> 01:21:01.199 Why don't we because we're at 39. s749 01:21:02.320 --> 01:21:08.880 Well, I think we already effectively went over a lot of this material here. s750 01:21:08.880 --> 01:21:16.000 Um, some of this is designed so that if you come back to it later, it kind of overdocuments what I'm talking about. s751 01:21:16.000 --> 01:21:22.000 So these steps and some of the optional work will help you understand cipher a little bit better. s752 01:21:22.000 --> 01:21:27.199 Um and kind of exactly how exactly how all the pieces fit together. s753 01:21:27.199 --> 01:21:35.280 But given given the pace that we're moving at, why don't I go ahead and jump over to our um theme section. s754 01:21:35.280 --> 01:21:42.719 So I'm going to skip over the optional practice lesson here and I'm going to go right into into themes. s755 01:21:43.280 --> 01:21:50.960 So this is going to be our third and uh last shape of today. s756 01:21:51.120 --> 01:22:02.639 The 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. s757 01:22:02.639 --> 01:22:20.320 So when you have documents that have a lot of interlinking um 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. s758 01:22:20.320 --> 01:22:35.679 Um, so you can see like this, you know, um, uh, this this this guide here that's a um that's a manual is being linked to by all of these different repair procedures. s759 01:22:35.679 --> 01:22:41.600 And if if you zoom out, what ends up happening is you'll get natural clusters of things. s760 01:22:41.600 --> 01:22:56.080 And this also happens a lot like in these kaparthy style like knowledge bases where you'll see that like concepts will naturally start grouping together and a graph can help you surface those themes s761 01:22:56.080 --> 01:23:01.679 those things that you didn't actually know existed before. s762 01:23:01.679 --> 01:23:06.639 And so we're going to use something called lien community detection. s763 01:23:06.639 --> 01:23:12.480 By a show of hands, how many people in this room are familiar with what graph data science is? s764 01:23:12.800 --> 01:23:14.080 Well, yes. s765 01:23:14.080 --> 01:23:14.480 Okay. s766 01:23:14.480 --> 01:23:15.840 So, so not too many of you. s767 01:23:15.840 --> 01:23:21.600 Do how many people know what community detection in a graph is? s768 01:23:21.679 --> 01:23:21.920 Okay. s769 01:23:21.920 --> 01:23:23.199 So, we we have some of you. s770 01:23:23.199 --> 01:23:38.080 So, so community detection is this idea where right if if I have this graph um and you can kind of see if I zoom out if you if especially if you're running it locally you can see that there's these like natural little like clusters s771 01:23:38.080 --> 01:23:56.880 right of nodes that are highly interlin together and so the idea is like well what if we can like try to label these clusters such that within a cluster things are highly interconnected so like this little globule of nodes becomes a cluster cluster, then this globule becomes a cluster and this one down here. s772 01:23:56.880 --> 01:24:03.280 Um, and and if if we can do that, we can start understanding our data at a global scale really well. s773 01:24:03.280 --> 01:24:10.159 So, this is like that initial like Microsoft graph rag idea too of like of global versus local search, right? s774 01:24:10.159 --> 01:24:15.920 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. s775 01:24:15.920 --> 01:24:20.560 We're just going off of literally the the structure of the documents. s776 01:24:20.560 --> 01:24:30.400 The algorithm that we're going to use for that labeling is called Leiden, which is similar to Louane, which if you talk about community detection, Luane will come up a lot. s777 01:24:30.400 --> 01:24:35.920 Leiden is I almost see it as like a um the sort of next step. s778 01:24:35.920 --> 01:24:40.400 It's a little bit more efficient um in in the way that it runs. s779 01:24:40.400 --> 01:24:45.520 And um it it's using Neo Forj's graph data science library. s780 01:24:45.520 --> 01:24:55.280 So basically what we have to do or what what we do to make it very performant is in addition to just having the database we have this other um projection s781 01:24:55.280 --> 01:25:09.520 where we'll take a part of the graph into memory um 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 s782 01:25:09.520 --> 01:25:16.719 performing this clustering and then identifying um basically the different interconnected communities. s783 01:25:17.040 --> 01:25:20.080 and um these clusters. s784 01:25:20.080 --> 01:25:30.719 If I um keep going down, basically the 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. s785 01:25:30.719 --> 01:25:38.400 And so it's a little bit hard to see because it's a sliding window, but basically we'll have what are what we're calling themes. s786 01:25:38.400 --> 01:25:41.360 And these themes are going to be these buckets of documents. s787 01:25:41.360 --> 01:25:46.480 we'll have a sense of how tightly or loosely they're interlin using um this conduance metric. s788 01:25:46.480 --> 01:25:56.320 It's basically like going to be this metric around like how interconnected the nodes inside cluster are versus how much they um are connected outside of the cluster. s789 01:25:56.320 --> 01:26:00.320 So we can say something's tightly interlin or loosely interlin. s790 01:26:00.320 --> 01:26:13.280 um we'll use the labels on the links as the top shared targets and we will um talk about the most linked docs and so so the highest centrality docs s791 01:26:13.280 --> 01:26:27.840 inside each of them and so what we end up with without any sort of um tagging or labeling by AI or a language model um is just simply from the document structure we can tell that this first one s792 01:26:27.840 --> 01:26:36.239 um is about you know um BCM um and and bus and all these sorts of things. s793 01:26:36.239 --> 01:26:45.840 And then if if I go down like this next cluster is going to be about brakes um and rotor pads and um hydraulic lines. s794 01:26:45.840 --> 01:26:47.600 So it's all braking stuff. s795 01:26:47.600 --> 01:26:51.520 So you end up with these very natural sort of clusters that come up. s796 01:26:51.520 --> 01:27:02.000 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. s797 01:27:02.000 --> 01:27:16.239 Uh 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 um our spec as well. s798 01:27:16.239 --> 01:27:26.320 Um, so collapsing the sections and it talks a little bit here and I I kind of want to give us the last half an hour to go through the final questions. s799 01:27:26.320 --> 01:27:34.159 So I'll speedrun this a little bit, but basically when we create this projection and I'll just go ahead and and copy this thing. s800 01:27:34.159 --> 01:27:36.800 Maybe I'll I'll do this script thing first. s801 01:27:36.800 --> 01:27:50.400 So like we did before, um, inside of here, uh, if I look inside of my themes.py Pi file I I have this wire for this for the projection that piece where we take the graph and put it into memory. s802 01:27:50.400 --> 01:27:56.159 Um the actual liiden algorithm here I'm just calling it with that graph data science library. s803 01:27:56.159 --> 01:28:00.159 Um so in theory you can you can kind of agent code all of these. s804 01:28:00.159 --> 01:28:02.560 Um but I'll just do this one. s805 01:28:02.560 --> 01:28:04.239 Um oh that's not good. s806 01:28:04.239 --> 01:28:07.520 I want to be able to make sure I copy the right thing. s807 01:28:07.520 --> 01:28:16.880 So, similar to before, um, we have our, um, sure that the right thing that I just gave it. s808 01:28:16.880 --> 01:28:17.280 Yeah. s809 01:28:17.280 --> 01:28:21.199 So, we're telling it to use a cipher skill and the GDS skill to put this together. s810 01:28:21.199 --> 01:28:30.159 If you went inside of our docs, you have the uh, theme format one, which will give it the the shape that we want and everything. s811 01:28:30.159 --> 01:28:35.120 Um, and it will tell us kind of how we want all the headers and things to be formatted. s812 01:28:35.280 --> 01:28:44.880 Um, and so we'll go ahead and um create that create that for me. s813 01:28:44.880 --> 01:28:48.000 And while it's creating that, I'll talk a little bit about the projection. s814 01:28:48.000 --> 01:28:54.239 So there's some graph manipulation that we do to bring it efficiently into a projection. s815 01:28:54.239 --> 01:29:06.159 Um, basically we collapse the relationships on the URI so that the if we have sections that interlink with each other like one section of a doc interlinks to another subsection, s816 01:29:06.159 --> 01:29:08.880 we just aggregate that all to the document level. s817 01:29:08.880 --> 01:29:21.199 Um, 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 um, easier that way as well. s818 01:29:27.920 --> 01:29:28.480 All righty. s819 01:29:28.480 --> 01:29:31.760 So, that looks like it's coming along. s820 01:29:34.400 --> 01:29:35.520 Yes. s821 01:29:35.520 --> 01:29:37.120 Okay. s822 01:29:37.120 --> 01:29:40.719 So, it went ahead and created that for us. s823 01:29:40.719 --> 01:29:52.800 Um, and then once we get that back, uh, I can go ahead and copy the script that it just helped me create and I can run that inside of my terminal. s824 01:29:54.239 --> 01:29:57.440 Let me just make a new terminal. s825 01:29:57.440 --> 01:30:02.400 So, I can go ahead and and call that theme script that we just edited. s826 01:30:02.400 --> 01:30:04.400 And then it will do that community detection. s827 01:30:04.400 --> 01:30:08.320 And you'll see here that I'll get that view. s828 01:30:08.320 --> 01:30:20.800 Um so I have my you can see like the this you know circuit you know one I have all my different uh documents that are that are grouped together and I kind of understand now s829 01:30:20.800 --> 01:30:25.440 um all the different areas of the vehicles that that my documents go over. s830 01:30:25.440 --> 01:30:28.960 Um there's other parameters that you can feed this. s831 01:30:28.960 --> 01:30:42.000 Um so for example we have a gamma parameter and basically what that will do is uh basically tells it kind of um how how much to split everything into. s832 01:30:42.000 --> 01:30:45.440 So it's one parameter that we're exposing. s833 01:30:45.440 --> 01:30:49.199 If you went to the graph data science documentation there's many others. s834 01:30:49.199 --> 01:30:53.120 Um but like I got 13 groups running it here. s835 01:30:53.120 --> 01:30:56.960 If I if I try to make it more refined with gamma equal to two. s836 01:30:56.960 --> 01:30:58.560 So it's one by default. s837 01:30:58.560 --> 01:31:01.600 it will give me I think in this case 14. s838 01:31:01.600 --> 01:31:06.639 Um so it basically splits it up into more groups. s839 01:31:06.639 --> 01:31:14.960 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. s840 01:31:14.960 --> 01:31:22.000 Basically um as you go along and you start to understand your corpus better, you may want to tune some of these hyperparameters. s841 01:31:22.000 --> 01:31:25.760 Um and this gave us 14 different themes. s842 01:31:26.719 --> 01:31:31.199 Um, let's see what we have here. s843 01:31:36.239 --> 01:31:36.480 Yeah. s844 01:31:36.480 --> 01:31:40.239 And it never really names a theme is sort of the point of this. s845 01:31:40.239 --> 01:31:45.199 So like everything that you get um is just directly from the document. s846 01:31:45.199 --> 01:31:58.800 If I was to look at like the the theme here, the names of the links, the the names of the the top files that were read, all of those things are just directly from the data. s847 01:31:58.800 --> 01:32:10.159 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. s848 01:32:10.159 --> 01:32:15.920 So, it gives the agent the ability to kind of jump between multiple tools like this. s849 01:32:18.320 --> 01:32:23.120 Um and so this the these sorts of things are good for these estate level questions. s850 01:32:23.120 --> 01:32:26.159 So things like where are issues concentrated? s851 01:32:26.159 --> 01:32:28.960 Where's documentation thing thin? s852 01:32:28.960 --> 01:32:36.400 Where does new documentation possibly belong on some other different type of subject that just came in for adding more data. s853 01:32:36.400 --> 01:32:38.159 Um all righty. s854 01:32:38.159 --> 01:32:46.000 So that brings us to the end of themes and we have 27 minutes about left. s855 01:32:46.000 --> 01:32:54.719 Are there any questions around this themes uh algorithm that anyone has really quickly? s856 01:32:54.719 --> 01:32:57.679 Uh yes. s857 01:32:57.679 --> 01:32:59.679 Yep. s858 01:33:24.000 --> 01:33:24.400 Yeah. s859 01:33:24.400 --> 01:33:36.560 So that's a good question and the question is once you get the themes so all the line algorithm will do is assign an ID to these different groups right s860 01:33:36.560 --> 01:33:49.920 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 s861 01:33:49.920 --> 01:33:51.440 the different groups. s862 01:33:51.440 --> 01:33:53.360 Here we're doing the former. s863 01:33:53.360 --> 01:33:57.440 We're just taking what's in the data and we're just showing it to you. s864 01:33:57.440 --> 01:34:04.000 Um, and the advantage of that is every time I run it, it'll be the same as long as the data stays the same. s865 01:34:04.000 --> 01:34:06.800 If the data changes, it will change to reflect the data. s866 01:34:06.800 --> 01:34:08.639 So, it's very stable. s867 01:34:08.639 --> 01:34:21.199 The disadvantage to it would be if your links in your documents um, and the titles and things that are being scooped up, because this is really only looking basically at document metadata and link metadata. s868 01:34:21.199 --> 01:34:27.760 um if those things aren't already wellleeled, this view might not be super informative right off the bat. s869 01:34:27.760 --> 01:34:41.679 That's why you have, you know, with like the 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 um hierarchical level summaries, s870 01:34:41.679 --> 01:34:42.000 right? s871 01:34:42.000 --> 01:34:50.400 So after they get the light in community, which is the same algorithm that they use, they'll do a summary that'll be LLM driven on top of each theme. s872 01:34:50.400 --> 01:34:52.560 Um, so that's possible to do. s873 01:34:52.560 --> 01:35:00.800 Um, but then obviously it costs more money, it's slower, and the you if you run it twice, it might not return the same thing. s874 01:35:00.800 --> 01:35:03.760 So there's trade-offs between uh each way of doing it. s875 01:35:03.760 --> 01:35:07.920 I'm showing you the sort of lighter way of doing it and the easier way. s876 01:35:07.920 --> 01:35:13.679 Um, just because it's faster and if you're just getting started with this, it might be easier to to start there. s877 01:35:13.679 --> 01:35:18.480 Um, may we have time for maybe one maybe two more questions. s878 01:35:18.480 --> 01:35:22.080 Um, yes. s879 01:35:25.199 --> 01:35:27.760 Temporal data. s880 01:35:31.840 --> 01:35:32.560 Yeah. s881 01:35:32.560 --> 01:35:46.480 I mean, um, I've seen customers, you know, basically every time because because the way Leiden works is it's it really is this algorithm that where it will suck everything into a projection. s882 01:35:46.480 --> 01:35:51.600 it will create its labels and it'll it'll die down and then it will go away. s883 01:35:51.600 --> 01:36:03.120 So if your data is being updated constantly um you can recreate your ids um and you can have almost like a time series of of different theme ids for example s884 01:36:03.120 --> 01:36:19.679 um 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 um 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 um fraud detection s885 01:36:19.679 --> 01:36:33.920 so like looking at um like credit chargeback fraud or like some of these other like um anti-moneylaundering type of stuff to look at clusters and for that they'll have to do it temporally like they have to keep running it um to kind of see how things change over time and then predict the future. s886 01:36:33.920 --> 01:36:34.080 Right. s887 01:36:34.080 --> 01:36:36.320 So they're used in those scenarios too. s888 01:36:36.320 --> 01:36:38.320 Yep. s889 01:36:38.880 --> 01:36:39.600 All right. s890 01:36:39.600 --> 01:36:43.600 One more maybe and then I'm gonna have to move on. s891 01:36:45.360 --> 01:36:45.760 All right. s892 01:36:45.760 --> 01:36:47.199 I Okay. s893 01:36:47.199 --> 01:36:49.199 Yes. s894 01:37:01.600 --> 01:37:10.719 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? s895 01:37:14.239 --> 01:37:15.440 Yeah. s896 01:37:15.440 --> 01:37:22.000 Um so for this view I think it's showing like 14 themes. s897 01:37:22.000 --> 01:37:24.159 So there are cuto offs that you can make. s898 01:37:24.159 --> 01:37:33.360 So for example you can say like for communities that are smaller than X threshold like you don't necessarily need to highlight them. s899 01:37:33.360 --> 01:37:42.960 Sometimes small communities are very important which is why that conduance metric which is powering that tightly interlin loosely inter interlin you can also make that a cutoff. s900 01:37:42.960 --> 01:37:52.719 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. s901 01:37:52.719 --> 01:37:55.520 Do I understand that correctly? s902 01:38:00.880 --> 01:38:04.560 to make sure that the relationships on the nodes are correct. s903 01:38:04.560 --> 01:38:26.639 And um so yeah. s904 01:38:26.639 --> 01:38:27.040 Yeah. s905 01:38:27.040 --> 01:38:33.840 I mean, so in this scenario, we're really sort of trusting, we're taking the source data kind of at its word, right? s906 01:38:33.840 --> 01:38:37.360 If something links to a document, it links to the document, right? s907 01:38:37.360 --> 01:38:45.360 If it's erroneously linking to a document or there's a section that's malformatted, um, we wouldn't necessarily catch that. s908 01:38:45.360 --> 01:38:58.560 But I suppose a good thing about something like an outline shape is that you can have your agent traverse it um automatically without you necessarily seeing it in small pieces and it might be able to catch some of those things, right? s909 01:38:58.560 --> 01:39:10.159 Um 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. s910 01:39:10.159 --> 01:39:11.679 Um but it's a good question. s911 01:39:11.679 --> 01:39:14.320 I don't know if we have a perfect solution to it. s912 01:39:14.320 --> 01:39:19.280 It's cleaning and cleaning messy data has always been a, you know, a thing. s913 01:39:19.280 --> 01:39:20.239 Yep. s914 01:39:20.239 --> 01:39:21.119 All righty. s915 01:39:21.119 --> 01:39:29.040 Let's go ahead and and move on because I only have 20 minutes left and I anticipate this last uh section will be this is the the meatiest one. s916 01:39:29.040 --> 01:39:33.679 So hopefully we'll have enough time to go through it especially because Claude has been slow. s917 01:39:33.679 --> 01:39:38.080 So cross your fingers um because this one is probably the heavier use of claude. s918 01:39:38.080 --> 01:39:45.679 So there is a section here around just using the Neo Forj CLY because we're just 20 minutes in. s919 01:39:45.679 --> 01:39:50.639 Um I'm probably end I'm not going to go through it all the way but I'll talk about it for a couple minutes. s920 01:39:50.639 --> 01:39:54.639 The Neo Forj CLY is a a Cly tool. s921 01:39:54.639 --> 01:39:56.719 So I can run it in the command line. s922 01:39:56.719 --> 01:40:11.199 So here for example um if I opened up a terminal window I can go ahead and copy it in and it will run a uh query for me and it also has the ability here to grab the graph schema. s923 01:40:11.199 --> 01:40:21.520 Um and what that enables me to do is um basically understand what's in the graph and then write a query based on that. s924 01:40:21.520 --> 01:40:32.080 And if you have your agent which in this case because we're using a coden agent it can access the neo forj cli it gives it the ability to do this graph reasoning read the schema and then do flexible queries. s925 01:40:32.080 --> 01:40:39.679 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? s926 01:40:39.679 --> 01:40:42.080 It has to write its own custom cipher query. s927 01:40:42.080 --> 01:40:44.159 It can do that very efficiently. s928 01:40:44.159 --> 01:40:48.159 Um, and I've seen a lot of improvements using this along with the skills. s929 01:40:48.159 --> 01:40:55.199 So much better than the text to cipher experience that we've had like even as as soon as a year ago or six months ago. s930 01:40:55.199 --> 01:41:04.000 Um, if you are going to be writing cipher or doing anything text to cipher with an agent, I'd highly recommend using the Neo Forj CLY. s931 01:41:04.000 --> 01:41:08.000 Um, as well as the cipher and GDS skills that we were just going over. s932 01:41:08.000 --> 01:41:15.600 So, with that in mind, I'll go ahead and take it on to our, in this case, our last section. s933 01:41:15.600 --> 01:41:21.280 If you were to take this offline, there's otherformational sections that come after it. s934 01:41:21.280 --> 01:41:26.719 Um but basically we're going to start asking um some questions. s935 01:41:26.719 --> 01:41:40.000 Uh the first question that we're going to ask it and I will jump right 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 s936 01:41:40.000 --> 01:41:52.639 right we had sort of our 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 s937 01:41:52.639 --> 01:41:57.280 what fix what have we done that has fixed this on similar vehicles. s938 01:41:57.280 --> 01:42:09.679 Um, and the motivation behind this, right, and behind a lot of the data is as an auto repair shop, you want to minimize your um, comeback ratio, which is basically s939 01:42:09.679 --> 01:42:16.080 how many times a customer has to come back because, you know, the fix didn't work, right? s940 01:42:16.080 --> 01:42:27.280 Um, and so the data, especially on the warehouse side, will show um some of that history combined with the documentation on the actual parts and the recalls and the bulletins. s941 01:42:27.280 --> 01:42:37.280 So, what I've done here is similar to the gentleman's questions before, I uh I have it explained the steps that it used for the different shapes. s942 01:42:37.280 --> 01:42:40.800 You can see it's loading um the auto server skill. s943 01:42:40.800 --> 01:42:48.480 So that was the um the skill that we have here where we've also contains all of the scripts we've been working with. s944 01:42:48.480 --> 01:42:55.199 So the outline search and theme script it has access to as well as the run SQL and the MCP server. s945 01:42:55.199 --> 01:42:58.719 Um that was this skill that we were talking about before. s946 01:42:58.719 --> 01:43:00.400 So I've pre-written that for this. s947 01:43:00.400 --> 01:43:13.280 You can read it um if you like, but it basically gives it um some general guidance on how to access the warehouse and also deal with the different shapes in the command interface. s948 01:43:13.280 --> 01:43:16.159 And you'll see what it will do here. s949 01:43:16.159 --> 01:43:19.440 Um it will look for the document code. s950 01:43:19.440 --> 01:43:21.440 It'll do a full text search. s951 01:43:21.440 --> 01:43:25.920 It'll use the tree shape here to find cross links and causes. s952 01:43:25.920 --> 01:43:28.800 Um and then it will get the join paths. s953 01:43:28.800 --> 01:43:33.199 Um, and it will actually do the query for the VIN. s954 01:43:33.199 --> 01:43:42.480 Um, and when it does that, it will go ahead and come back with basically the part number that needs to be replaced. s955 01:43:42.480 --> 01:43:49.040 And in this case, there was like an old ignition coil that got revised that it had to replace it with. s956 01:43:49.040 --> 01:43:56.639 Um, so if you look right, it at first it did full text search to sort of ground uh the document with the right code. s957 01:43:56.639 --> 01:44:02.239 Um so it looked for the code and also the misfire or rough idle. s958 01:44:02.239 --> 01:44:07.520 Um it found uh the uh top hit which is this engine type. s959 01:44:07.520 --> 01:44:09.440 It confirmed its grounding. s960 01:44:09.440 --> 01:44:15.600 So it shows the links from that uh manual over to these different procedures. s961 01:44:15.600 --> 01:44:18.880 And then from there it did a join path. s962 01:44:18.880 --> 01:44:25.360 Um it basically looked at all the work orders um with that DTC code uh for that part. s963 01:44:25.360 --> 01:44:35.600 Um and then it was able to bring back the ultimate question which is like you know from all the parts that were replaced and how we dealt with that code it went to the warehouse to grab that information. s964 01:44:35.600 --> 01:44:38.080 So you can see like this is a simple question. s965 01:44:38.080 --> 01:44:55.199 So if you were using vector search and like Genie, like their AI search and Genie and like data bricks, you could do this, but what often happens is to to basically find what it would need to do that linking on that tree shape, it would have to do much more vector hits, s966 01:44:55.199 --> 01:45:14.320 which each of those is is a chance, right, for this to run into an issue and not find the right document or potentially hallucinate and get something on a misfire that maybe wasn't n't related to that specific part, but because it grounded in the tree shape and everything, it was able to to get the right information s967 01:45:14.320 --> 01:45:17.840 and then link that back to the table. s968 01:45:17.840 --> 01:45:23.840 Um, and so it can be helpful and it can help with efficiency in these smaller questions. s969 01:45:23.840 --> 01:45:31.040 Um, but then what can happen is when you get to the estate level questions is where it can get really interesting. s970 01:45:31.040 --> 01:45:35.840 So, I'm going to go ahead and just copy this question and I'm going to let it start running. s971 01:45:35.840 --> 01:45:41.280 Um it seems like claude is moving faster now which is good but I'll talk about it as it's running. s972 01:45:41.280 --> 01:45:55.040 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 s973 01:45:55.040 --> 01:46:04.400 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 and all this sort of stuff s974 01:46:04.400 --> 01:46:15.920 um 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? s975 01:46:15.920 --> 01:46:27.760 Because it's sort and it's sort of like proving a negative or a mismatch because you're you're sort of saying like, you know, I I don't know what I'm looking for. s976 01:46:27.760 --> 01:46:30.080 I'm looking for a gap though. s977 01:46:30.080 --> 01:46:40.320 And you can imagine that with a tool like vector search, this would be a very hard question because sim or any type of similarity or lexical search because like if you're just doing that alone s978 01:46:40.320 --> 01:46:43.360 by definition, you're search you can't really search for a negative. s979 01:46:43.360 --> 01:46:45.360 You have to search for things that are there. s980 01:46:45.360 --> 01:46:56.880 Um, 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, s981 01:46:56.880 --> 01:47:03.119 particularly if they're around patterns where you might not even know what you're looking for yet. s982 01:47:03.199 --> 01:47:05.199 Yes. s983 01:47:05.600 --> 01:47:15.760 And so this one takes a while to run because it at at a certain point here, it does have to take a large number of codes and join some data together. s984 01:47:15.760 --> 01:47:24.960 Um, but you'll see at the end here, it'll it'll kind of uh trickle in and it it'll it'll tell you how it went about finding everything. s985 01:47:24.960 --> 01:47:35.280 Um, and oftent times what you see with these, it'll 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. s986 01:47:35.280 --> 01:47:45.760 um run through a lot of different things here. s987 01:47:46.320 --> 01:47:54.239 Um, another thing just to just while it's working on that, I did tell it here for sake of clarity to not use the near forjly. s988 01:47:54.239 --> 01:48:01.520 And the reason that I I have that here is so that you can see it using the um the different shapes. s989 01:48:01.520 --> 01:48:07.520 Um, just for sake of understanding how the different shapes kind of fit together and work. s990 01:48:07.520 --> 01:48:20.080 Once you hand your agent the Neo Forj CLY um 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. s991 01:48:20.080 --> 01:48:31.040 Um, and I'd say that as our sort of Texas cipher capabilities and as we keep building up more skills, it'll start to prefer more free form Neo forj Cly stuff s992 01:48:31.040 --> 01:48:33.679 uh much more frequently. s993 01:48:34.320 --> 01:48:37.280 And this one can sometimes take a little while to work through. s994 01:48:37.280 --> 01:48:41.360 So, I'll give it a another 20 seconds or so. s995 01:48:41.360 --> 01:48:44.560 Or maybe I can even open it up to a few questions while we're here. s996 01:48:44.560 --> 01:48:46.000 While we're waiting for this one. s997 01:48:46.000 --> 01:48:48.000 Yep. s998 01:49:02.960 --> 01:49:12.400 So, basically what it's going to do is it's going to look at the um well, I actually have to have it come back and remind me exactly how it um s999 01:49:12.400 --> 01:49:14.239 how it goes through. s1000 01:49:14.239 --> 01:49:26.480 Um 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. s1001 01:49:26.480 --> 01:49:33.280 Um and then there's also going to be high comeback history on using some of the wrong parts. s1002 01:49:33.280 --> 01:49:42.080 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 s1003 01:49:42.080 --> 01:49:44.159 potentially the wrong part. s1004 01:49:44.159 --> 01:49:54.880 Um so then there's that half of it and then there's some um documentation that we have um that's just not covered because we're using DTC codes that's just not covered inside of the warehouse. s1005 01:49:54.880 --> 01:49:59.600 So we'll know that like certain documentation hasn't really been hit at all. s1006 01:49:59.600 --> 01:50:08.320 Um, so here it actually took a little bit more of a um, and it will do this sometimes. s1007 01:50:08.320 --> 01:50:10.880 Here it used semantic expansion. s1008 01:50:10.880 --> 01:50:17.440 Um, so it actually went in and did a much more comprehensive um, semantic expansion search. s1009 01:50:17.440 --> 01:50:20.480 It's supposed to in this case use the outline. s1010 01:50:20.480 --> 01:50:28.239 I think because it had the hierarchical URI um, it was probably able to do this a little bit better. s1011 01:50:28.239 --> 01:50:35.040 Um but if I go back up um where did it show? s1012 01:50:35.040 --> 01:50:41.440 Um yeah it well it was able to show here the field codes essentially um that it was missing. s1013 01:50:41.440 --> 01:50:54.080 So um there was basically two field codes um that got a um yeah the headline mismatch or diagnosed with the wrong procedure. s1014 01:50:54.080 --> 01:51:05.199 Um, so there's basically this mismatch um where a couple of these parts on the library document. s1015 01:51:05.199 --> 01:51:05.520 Yeah. s1016 01:51:05.520 --> 01:51:11.199 So there where the correct repair isn't um referred to basically. s1017 01:51:11.199 --> 01:51:14.320 Um and that's causing a problem for the warehouse. s1018 01:51:14.320 --> 01:51:18.960 Um and then there's other um DTC codes that occur in the field. s1019 01:51:18.960 --> 01:51:19.520 Exactly. s1020 01:51:19.520 --> 01:51:24.400 that have two um that have no code level documentation which are these two. s1021 01:51:24.400 --> 01:51:29.040 So there's codes that are occurring which basically aren't documented that it was able to find. s1022 01:51:29.040 --> 01:51:37.119 Um 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 s1023 01:51:37.119 --> 01:51:40.239 all of the links a little bit more efficiently. s1024 01:51:40.239 --> 01:51:45.520 It wouldn't have done the comprehensive full text search crawl that took it a while in this case. s1025 01:51:45.520 --> 01:51:54.480 Um, but even here because it had the hierarchical URIs and that semantic expansion on the um, full text search, it was able to eventually find it. s1026 01:51:54.480 --> 01:52:02.560 Um, 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. s1027 01:52:02.560 --> 01:52:07.599 Um, the other thing here, the last one that I'll run because we only have eight minutes left. s1028 01:52:07.599 --> 01:52:10.560 Um, I'll go ahead and copy it here. s1029 01:52:10.560 --> 01:52:19.360 Um, and this one is primarily, if I go ahead and copy it, um, is going to leverage our, uh, theme shape. s1030 01:52:19.360 --> 01:52:29.920 So, um, this is asking for common patterns across all our bulletins and recalls um, and how many of the cars sort of each affects. s1031 01:52:29.920 --> 01:52:36.320 So, we have our work order history inside of our uh, warehouse. s1032 01:52:36.320 --> 01:52:47.360 And uh basically what we want to find out is like which you know how does the sort of themes that we have correlate with um our work order history. s1033 01:52:47.360 --> 01:52:56.400 Um and to do that it runs that theme pattern to be able to pull out the highle themes and then correlate it back to our work orders. s1034 01:52:57.040 --> 01:52:58.400 And so it's a coverage question. s1035 01:52:58.400 --> 01:53:14.800 So you can see it'll run the themes and then um eventually here it will go ahead and bring back um all of the all the relevant information. s1036 01:53:14.800 --> 01:53:19.040 But basically what it's doing is it's it's finding the themes. s1037 01:53:19.040 --> 01:53:29.360 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 the right theme. s1038 01:53:31.760 --> 01:53:36.080 While this is running, are there any other questions about this theme shape or anything? s1039 01:53:36.080 --> 01:53:38.159 I know other people there's Yes. s1040 01:53:38.159 --> 01:53:40.400 Go ahead. s1041 01:53:43.679 --> 01:53:44.000 Sorry. s1042 01:53:44.000 --> 01:53:46.639 Say that one more time. s1043 01:53:50.320 --> 01:53:53.679 how during the graph construction. s1044 01:53:56.080 --> 01:53:57.920 Yeah. s1045 01:53:57.920 --> 01:53:58.159 Yeah. s1046 01:53:58.159 --> 01:54:02.880 So the shapes that I that I are actually defined inside of our specs. s1047 01:54:02.880 --> 01:54:09.280 So if you go here, our outline shape um our specs in our docs. s1048 01:54:09.280 --> 01:54:15.520 So this was defined more thinking through like here's what we want it to look like for the agent. s1049 01:54:15.520 --> 01:54:22.239 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. s1050 01:54:22.239 --> 01:54:31.599 Um, and all of the documents were loaded essentially um into that data model that I went over about an hour and a half before towards the beginning of the course. s1051 01:54:31.599 --> 01:54:36.800 Um, it's that has containment tree with all the links between it. s1052 01:54:37.520 --> 01:54:44.880 Um, and you can see here it'll um it'll bring back the um that it used themes. s1053 01:54:44.880 --> 01:54:46.719 it didn't use search. s1054 01:54:46.719 --> 01:54:58.080 Um, and then it uh also uh queried the um if I go up here, you can see the cars affected. s1055 01:54:58.080 --> 01:55:07.280 So, it basically went to the warehouse with that connection shape um and it was able to sort of group them under um the different uh theme types. s1056 01:55:07.280 --> 01:55:15.760 So, it's like that theme, the different theme types um that we have and then kind of with the cars and the work orders grouped underneath by percentages. s1057 01:55:15.760 --> 01:55:19.280 Um yes, over here. s1058 01:55:21.280 --> 01:55:24.719 Yeah, either one. s1059 01:55:32.880 --> 01:55:37.520 Do do I have a sense of accuracy of how well these do when the knowledge bases expand? s1060 01:55:37.520 --> 01:55:43.760 Um, for this I haven't run any specific benchmarking on like exactly what I've shown you today. s1061 01:55:43.760 --> 01:55:55.679 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 uh that will basically say like how effective is this query pattern against s1062 01:55:55.679 --> 01:56:02.719 you know ordinary vector search for example and you would use that to prove it out on on a specific type of data set. s1063 01:56:02.719 --> 01:56:09.920 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. s1064 01:56:09.920 --> 01:56:14.719 Um, and it can always use work in terms of how you were to like build the skill, right? s1065 01:56:14.719 --> 01:56:21.119 To make sure it guides through the right thing so it uses, you know, each step efficiently essentially. s1066 01:56:23.920 --> 01:56:25.840 Are there any other questions? s1067 01:56:25.840 --> 01:56:27.840 Yep. s1068 01:56:38.800 --> 01:56:40.800 Yeah. s1069 01:56:52.960 --> 01:56:55.840 Well, maybe I don't fully understand. s1070 01:56:55.840 --> 01:57:00.719 So, you have um a connection point between between what? s1071 01:57:00.719 --> 01:57:09.199 Between Yeah. s1072 01:57:14.400 --> 01:57:16.400 Yeah. s1073 01:57:17.520 --> 01:57:17.840 Yeah. s1074 01:57:17.840 --> 01:57:19.760 No, we do not have so right now. s1075 01:57:19.760 --> 01:57:27.920 So, now that I understand your question, the question is, is there a link between the connection structured data graph and the unstructured one? s1076 01:57:27.920 --> 01:57:28.880 And there is not. s1077 01:57:28.880 --> 01:57:40.880 In this case, it's they're completely unlin and the agent is sort of extracting, you know, a part from one or it's extracting like um yeah, basically like a code, s1078 01:57:40.880 --> 01:57:41.520 right? s1079 01:57:41.520 --> 01:57:44.000 And then referring back to the document. s1080 01:57:44.000 --> 01:57:48.320 So, it's it's using that to kind of do its own join in real time. s1081 01:57:48.320 --> 01:57:54.080 You could create that linking and that could be valuable for more deterministic mapping. s1082 01:57:54.080 --> 01:58:04.960 Um 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. s1083 01:58:04.960 --> 01:58:12.000 Um and this is that and then if you wanted to later create those connections or those links you could. s1084 01:58:12.400 --> 01:58:15.840 Um any other questions? s1085 01:58:16.639 --> 01:58:17.280 All righty. s1086 01:58:17.280 --> 01:58:19.040 Well, thank you everyone. s1087 01:58:19.040 --> 01:58:22.639 Hopefully that was uh informative. s1088 01:58:22.639 --> 01:58:27.760 If you want to go back, the the workshop's available for you to take, it's it's online. s1089 01:58:27.760 --> 01:58:33.599 I am going to have to take the anthropic key and the big query down eventually. s1090 01:58:33.599 --> 01:58:39.280 I'll I'll leave the BigQuery one up uh for a while, but the anthropic one I'll have to eventually take down. s1091 01:58:39.280 --> 01:58:45.280 So, unfortunately, you will need to provide your own key, but other than that, you should be able to take it just fine. s1092 01:58:45.280 --> 01:58:47.599 Um, and I think that's all I have. s1093 01:58:47.599 --> 01:58:49.840 So, I'll leave it for my next guest. s1094 01:58:49.840 --> 01:58:54.080 Hopefully you guys have enough time to jump into your next session. s1095 01:59:06.787 --> 01:59:08.787 [music]