A common way to test the "quality" of an AI solution is to ask for how many r’s are in the word raspberry. LLMs are notoriously bad in such questions, but that does not mean we have to accept defeat with our AI application. Let us figure out how we can handle these types of tests.
The more complex our applications get, the harder it is to follow along our graph. Luckily for us, there is the concept of subgraphs that let us split our graph into parts that we can reuse.
For this post we create a minimalistic text writing pipeline that puts the quality checks into a subgraph. Let us see how we can do that.
When we switch from our hand-written long-term memory solution in last week's post to a pre-build SqliteSaver, we not only need less code, but we gain new options. One of the benefits of saving the whole state to a database is that we can inspect the current workflow and rerun them after we fixed a problem. Let us see how that works.
Last week we added short-term memory to our LangGraph application. That works great as long as we stay in the same session. But when we want to keep the memory around between sessions, we need a different approach.
In this post we create our hand-written approach for a long-term memory solution. Do this only to understand what is going on and not to use it in production. For that purpose, we can use pre-build solutions that we explore next week.
A while back we added a chat history to our LLM client so that we did not need to constantly repeat ourselves. This problem is now back in our LangGraph workflows. Luckily for us, LangGraph has a simple way to add memory to our workflows. Let us see how we can do that.
Last week we created a basic LangGraph example for the human-in-the-loop pattern. We ended up with a solution that run our tools but only after we approved the run. While this works, it gets cumbersome in no time. Especially when we have many tools and most of them are safe to use.
In this post we use a policy-based approach that allows us to create a list of safe tools for that we do not need a manual intervention. Let us see how we can build that.
Last week we learned how to build our own tools to use in LangGraph. Sometimes those tools could be dangerous, and we want to approve their usage before they run. For that we can use the Human-in-the-Loop (HITL) pattern.
LangGraph gets interesting as soon as we start to integrate it with our tasks. For that we need custom tools so that the LLM can interact with our data. Let us see how we can create our own tools and use them in LangGraph.
The more complex our control flow in our LangGraph application, the harder it is to understand what is going on. Luckily for us, we have multiple ways to visualise our graphs. Let us find out how we can do that.
Last week, we created a simple LangGraph application as our starting point. In this post, we will look at different ways to manage control flow and how nodes can interact with each other. While this sounds even more boring than our last post, here is where things start to get interesting.