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.
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.