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.
Agents in LangChain allow us to use the LLM as a reasoning engine and take actions based on their abilities. We used them successfully with our CSV files or when we queried a database. However, while we get a lot of flexibility, we often wish for a middle ground that gives us not only flexibility, but a bit more control on what is going on.
We can use LangGraph for this purpose. This low-level orchestration framework allows us to build simple agents or direct a large network of independent agents to solve problems for us. Let us get started with the most basic part and add from there.
While the command line Python Friday RAG is nice, a user interface that looks more like other chatbots would be a nice enhancement. Luckily for us, there are a few tools we can use that do not need much code. Let us see how that can look like.
Last week we turned blog posts written in Markdown into embeddings in Chroma. That gives us the data that we need for our Python Friday RAG (Retrieval Augmented Generation). In this post we reuse the LangChain configuration that helped us in various posts to connect our script to a local LLM running inside LM Studio.
After we found with Chroma a flexible vector store, we have everything together to build a RAG (Retrieval Augmented Generation) for the Python Friday blog that uses LangChain and a local LM Studio.
In this post we focus on extracting metadata from the Markdown files I use in this MkDocs Material powered blog. We split the Markdown into useful chunks and turn the metadata for the blog post into a metadata dictionary to use with Chroma. Let us explore how we can do this first part.
When we use the search function of Chroma, we can ask for cats and find documents related to felines. While this is great to get all cat related content, it may match on too many documents. This "fuzzy" search is a feature made possible by the embedding of our search term and how vectors relate to each other. But that also means we cannot simply get a stricter mode if we need one.
Chroma offers us an addition to the query method that allows us to filter based on the metadata of a document. That way we can combine the "fuzzy" vector search with a strict search based on metadata. Let us see how we can use it with our data.
We paused our AI journey after we figured out a way to work with large PDF files. It is now time to continue and find a solution to create and store vectors in a way that we can incrementally add new documents. The vectors, or embeddings, represent the semantic meaning and are a key part of the "chat with our docs" feature.
There are a handful solutions we can use. I start with Chroma (or ChromaDB) because it is an open-source vector database designed specifically to make building AI applications easy. It is built on top of SQLite, what helps us to work with the persisted data should we want to know more about how the magic works behind the scenes. Let us explore how we can use Chroma to calculate and store embeddings.
Last week we created a minimalistic bot that let us ask questions on a PDF file. As long as the PDF file and our prompt fits into the context windows of the LLM, that can be done without much infrastructure. Unfortunately, most interesting PDF files are way larger, and we do not want to ignore them. Let us find a way to split our PDF file into chunks so that the file size no longer matters.