-: In a graph like way with large language models.
Let's have a brief intro
before we start looking at some of the high level concepts
and the coding.
Basically, LangGraph
is consisting of something called nodes, edges,
and you can think of these nodes as having actions,
which are often written inside of Python functions.
It's basically, LangGraph
is the LangChain's state machine, right?
So it's a graph based approach
to orchestrating these larger language models.
On the right here,
you can see you've got this blue starting node,
which then goes into an agent.
The agent decides based on a conditional edge
whether it should continue into this action
or whether it should end.
We'll have a look
at how the start node and the end node are very key nodes,
which cause the application in a LangGraph state machine
to either start or end.
And you can design these nodes in the middle.
What's good about this is it basically makes LangGraph
an incredibly flexible modular,
but also you can still have some control
over what's happening
as you orchestrate these large language models.
This is in complete contrast
to the LangChain section we had
where you specifically hard coded these chains
and you built the if and else statements
directly into your control flow.
The workflow that you'll use when you're doing LangGraph
is kind of something like this,
where you'll initialize the LLM,
you'll have your tools that you might decide to call.
You have a state within the graph.
Now, the state could just be the messages,
the chat history,
or it could also be some other different things
that maybe there's a certain Boolean flag
that gets turned on.
We also did design the nodes
that are gonna act inside of our state machine.
So you can see here,
these yellow things represent the nodes,
and the arrows represent the edges.
So we have a state machine where we have these nodes,
and then the arrows or the directional flow
as to how the computer or the graph will be executed
is basically on the arrows.
We also have the entry point.
So the entry point,
if we're looking at the previous diagram,
would be the start one.
And we also have a graph edges, that we've talked about,
and you can compile the graph and execute the graph.
So that's what we'll be looking at
in more detail as we go on.
Now, if we're just looking at what a node is,
it's that fundamental bit of execution
that happens anywhere inside of your LangGraph as a node.
On the right here,
you've got a node called call model,
and it's a function at the moment.
And you can see it takes in some message state.
We get the messages out,
we invoke a chat model,
and then we're returning a list of messages.
Because we are returning a list,
this will also automatically
get appended onto the existing list, okay?
Now, the nodes we've created are actually called agent,
and we've got tools,
and we'll probably also call another one.
But because we've got this add node functionality,
we're calling a node of agent
is actually being referred to with this Python function.
So if you've ever written anything
where you've got like the Python in Flask
where you have your route,
you give the route a name,
and you also attach a Python function,
it's very similar as to how you create the nodes here,
where you've got the name of the node
and then you've got the Python function
that sits on that node.
Once you have a bunch of nodes,
the next thing that you have to do
is add different types of edges.
And we'll see in detail how we can add edges
and what these edges mean.
So an edge is basically the connection
between these two nodes,
and that basically means as the graph gets executed,
it will flow between various nodes,
and the code that runs at every node will also be executed.
There's a couple of gotchas
that I think it's worth just mentioning
before we go into this.
When you're returning the state,
you should always return as much state as possible
and make sure that you're actually returning the state.
Because if you don't return the state,
what will happen is the state will essentially get wiped
to some description. So that was a bit of a gotcha for me
when I was playing around with LangGraph.
Just make sure you return state inside of your nodes.
So when you're looking at the state in LangGraph,
you could just have a simple messages, for example,
or you can have something that's more interesting.
So you could have lots of different keys.
It's possible for you to use Pydantic base models
to decide what your state should be.
And to start with,
we'll just look at using the state with the messages,
but later on we can also add various other states
to handle and decide on what various types of nodes
we should flow to next inside of the graph.
Cool, I'm really looking forward
to getting into the section with you.
I think there's a lot of power inside of LangGraph.
And it's gonna help you
create more modular, composable and robust workflows.