WEBVTT 00:00.000 --> 00:03.000 -: In a graph like way with large language models. 00:03.000 --> 00:04.200 Let's have a brief intro 00:04.200 --> 00:06.750 before we start looking at some of the high level concepts 00:06.750 --> 00:07.583 and the coding. 00:08.880 --> 00:10.260 Basically, LangGraph 00:10.260 --> 00:13.470 is consisting of something called nodes, edges, 00:13.470 --> 00:16.205 and you can think of these nodes as having actions, 00:16.205 --> 00:19.200 which are often written inside of Python functions. 00:19.200 --> 00:20.760 It's basically, LangGraph 00:20.760 --> 00:22.770 is the LangChain's state machine, right? 00:22.770 --> 00:24.450 So it's a graph based approach 00:24.450 --> 00:26.880 to orchestrating these larger language models. 00:26.880 --> 00:27.713 On the right here, 00:27.713 --> 00:30.027 you can see you've got this blue starting node, 00:30.027 --> 00:32.340 which then goes into an agent. 00:32.340 --> 00:36.720 The agent decides based on a conditional edge 00:36.720 --> 00:39.780 whether it should continue into this action 00:39.780 --> 00:41.070 or whether it should end. 00:41.070 --> 00:41.903 We'll have a look 00:41.903 --> 00:46.903 at how the start node and the end node are very key nodes, 00:47.340 --> 00:50.250 which cause the application in a LangGraph state machine 00:50.250 --> 00:51.750 to either start or end. 00:51.750 --> 00:55.050 And you can design these nodes in the middle. 00:55.050 --> 00:57.600 What's good about this is it basically makes LangGraph 00:57.600 --> 01:00.180 an incredibly flexible modular, 01:00.180 --> 01:02.160 but also you can still have some control 01:02.160 --> 01:03.690 over what's happening 01:03.690 --> 01:05.970 as you orchestrate these large language models. 01:05.970 --> 01:07.207 This is in complete contrast 01:07.207 --> 01:10.020 to the LangChain section we had 01:10.020 --> 01:13.080 where you specifically hard coded these chains 01:13.080 --> 01:14.850 and you built the if and else statements 01:14.850 --> 01:16.470 directly into your control flow. 01:16.470 --> 01:19.260 The workflow that you'll use when you're doing LangGraph 01:19.260 --> 01:20.640 is kind of something like this, 01:20.640 --> 01:22.202 where you'll initialize the LLM, 01:22.202 --> 01:25.380 you'll have your tools that you might decide to call. 01:25.380 --> 01:27.540 You have a state within the graph. 01:27.540 --> 01:29.130 Now, the state could just be the messages, 01:29.130 --> 01:29.963 the chat history, 01:29.963 --> 01:32.040 or it could also be some other different things 01:32.040 --> 01:33.780 that maybe there's a certain Boolean flag 01:33.780 --> 01:35.070 that gets turned on. 01:35.070 --> 01:36.870 We also did design the nodes 01:36.870 --> 01:39.960 that are gonna act inside of our state machine. 01:39.960 --> 01:40.950 So you can see here, 01:40.950 --> 01:43.006 these yellow things represent the nodes, 01:43.006 --> 01:46.136 and the arrows represent the edges. 01:46.136 --> 01:48.923 So we have a state machine where we have these nodes, 01:48.923 --> 01:51.450 and then the arrows or the directional flow 01:51.450 --> 01:54.988 as to how the computer or the graph will be executed 01:54.988 --> 01:57.484 is basically on the arrows. 01:57.484 --> 01:59.622 We also have the entry point. 01:59.622 --> 02:00.612 So the entry point, 02:00.612 --> 02:02.370 if we're looking at the previous diagram, 02:02.370 --> 02:03.930 would be the start one. 02:03.930 --> 02:07.290 And we also have a graph edges, that we've talked about, 02:07.290 --> 02:10.486 and you can compile the graph and execute the graph. 02:10.486 --> 02:12.118 So that's what we'll be looking at 02:12.118 --> 02:14.302 in more detail as we go on. 02:14.302 --> 02:16.800 Now, if we're just looking at what a node is, 02:16.800 --> 02:18.750 it's that fundamental bit of execution 02:18.750 --> 02:22.353 that happens anywhere inside of your LangGraph as a node. 02:23.310 --> 02:24.143 On the right here, 02:24.143 --> 02:26.702 you've got a node called call model, 02:26.702 --> 02:28.830 and it's a function at the moment. 02:28.830 --> 02:31.050 And you can see it takes in some message state. 02:31.050 --> 02:32.217 We get the messages out, 02:32.217 --> 02:34.204 we invoke a chat model, 02:34.204 --> 02:36.836 and then we're returning a list of messages. 02:36.836 --> 02:39.030 Because we are returning a list, 02:39.030 --> 02:40.770 this will also automatically 02:40.770 --> 02:44.040 get appended onto the existing list, okay? 02:44.040 --> 02:47.040 Now, the nodes we've created are actually called agent, 02:47.040 --> 02:47.902 and we've got tools, 02:47.902 --> 02:50.310 and we'll probably also call another one. 02:50.310 --> 02:53.160 But because we've got this add node functionality, 02:53.160 --> 02:55.319 we're calling a node of agent 02:55.319 --> 02:58.275 is actually being referred to with this Python function. 02:58.275 --> 03:00.060 So if you've ever written anything 03:00.060 --> 03:02.024 where you've got like the Python in Flask 03:02.024 --> 03:04.110 where you have your route, 03:04.110 --> 03:05.190 you give the route a name, 03:05.190 --> 03:06.990 and you also attach a Python function, 03:06.990 --> 03:09.690 it's very similar as to how you create the nodes here, 03:09.690 --> 03:11.160 where you've got the name of the node 03:11.160 --> 03:12.360 and then you've got the Python function 03:12.360 --> 03:13.695 that sits on that node. 03:13.695 --> 03:15.437 Once you have a bunch of nodes, 03:15.437 --> 03:17.280 the next thing that you have to do 03:17.280 --> 03:18.942 is add different types of edges. 03:18.942 --> 03:21.556 And we'll see in detail how we can add edges 03:21.556 --> 03:23.490 and what these edges mean. 03:23.490 --> 03:25.140 So an edge is basically the connection 03:25.140 --> 03:26.140 between these two nodes, 03:26.140 --> 03:29.790 and that basically means as the graph gets executed, 03:29.790 --> 03:31.560 it will flow between various nodes, 03:31.560 --> 03:35.277 and the code that runs at every node will also be executed. 03:35.277 --> 03:36.491 There's a couple of gotchas 03:36.491 --> 03:38.250 that I think it's worth just mentioning 03:38.250 --> 03:40.110 before we go into this. 03:40.110 --> 03:41.795 When you're returning the state, 03:41.795 --> 03:44.934 you should always return as much state as possible 03:44.934 --> 03:47.550 and make sure that you're actually returning the state. 03:47.550 --> 03:49.499 Because if you don't return the state, 03:49.499 --> 03:53.370 what will happen is the state will essentially get wiped 03:53.370 --> 03:55.830 to some description. So that was a bit of a gotcha for me 03:55.830 --> 03:57.133 when I was playing around with LangGraph. 03:57.133 --> 04:00.060 Just make sure you return state inside of your nodes. 04:00.060 --> 04:02.430 So when you're looking at the state in LangGraph, 04:02.430 --> 04:05.280 you could just have a simple messages, for example, 04:05.280 --> 04:08.190 or you can have something that's more interesting. 04:08.190 --> 04:09.586 So you could have lots of different keys. 04:09.586 --> 04:12.450 It's possible for you to use Pydantic base models 04:12.450 --> 04:15.000 to decide what your state should be. 04:15.000 --> 04:16.470 And to start with, 04:16.470 --> 04:18.390 we'll just look at using the state with the messages, 04:18.390 --> 04:20.580 but later on we can also add various other states 04:20.580 --> 04:24.450 to handle and decide on what various types of nodes 04:24.450 --> 04:26.700 we should flow to next inside of the graph. 04:26.700 --> 04:27.900 Cool, I'm really looking forward 04:27.900 --> 04:29.340 to getting into the section with you. 04:29.340 --> 04:31.920 I think there's a lot of power inside of LangGraph. 04:31.920 --> 04:32.753 And it's gonna help you 04:32.753 --> 04:37.293 create more modular, composable and robust workflows.