 In this video, we're going to talk about filtering. As you log more and more data to LangSmith from your application, it becomes really important to be able to filter that and dive into different subsets of the data that you want to look at. We've built out a lot of functionality around that, and with that you can do some pretty advanced stuff. And so that's what we're going to talk about in this video. There's also documentation for this, and I'll link to this in the description below. So in order to take advantage of filtering, you can go over to Langsmith, you can go to a project of your choice, and for this one I'm going to go to ChatLangchain. And so ChatLangchain is an application that we expose that is chat over our documentation for Langchain. So you can see up here that I have this filter button and if I click into it I can see that there's one filter applied by default and this is isRoot equals true. So what this allows is this allows me to see all top level traces. So remember if I click into a trace there's actually multiple runs that are going on that's happening inside this trace. So when I set is root equals to true, this only shows me the top level view of that. If I remove this filter, then I start to see all the individual runs show up below. In addition to controlling filters from up here, I can also choose a few filters from the sidebar here. So here we have a bunch of different filter shortcuts for commonly used filters. So filters on feedback, feedback source, different types of metadata, the name, the run type, the status, any tags, things like that. And so if you want to go to a quick kind of like filter, this shortcut place is a good place to go. Inside this filter place, I'll add back this like is root equals true to just look at the top level traces for a little bit. And so there's a bunch of things that I can filter on. I can do a full text search. So I can search for traces that mention memory. So when I apply this, I can now click in. And one of in here somewhere is basically memory. So here we can see that memory is specified. So I can do a full text search over all the traces that I get. What else can I add? I can search based on input and output. I can search based on name. And so name is really useful when I want to filter sub runs. And I'll do that in a second but first I want to go through the is root equals true still I can filter based on error or not so let me filter it for where errors happen and I can click in and I can see what exactly went wrong in the error and so here it looks like it was cancelled so if I have a bunch of errors occurring I can filter to runs that had errors, and then basically, yeah, dive into them and see what's going on. So this is a good way to monitor for what bad things are happening. Speaking of bad things happening, another thing that I can filter on is based on feedback. So here in ChatLinkChain, we have a thumbs up, thumbs down. That's registered as user score. And so I can filter for where user score is zero and these are all the data points where i got negative feedback for my application so i can click into any one and i can see data points that an end user rated as bad and so that's really helpful for diving into places where the feedback was negative other things i can do or i can search for latency and so this is for like runs that might be longer than 10 seconds. I can go like that and I get a list of all the long runs. I can filter based on tag. I can filter based on metadata. So one of the things that we log in ChatLangchain is the LLM that we use. And so here I can choose where and we attach this as a metadata tag. And so I can filter for metadata where the LLM is fireworks, for example. And all of these runs use fireworks under the hood. Another thing that I can do here is I can magically create a filter with AI. So I can specify something like runs longer than 10 seconds. And then this will convert it into a filter and add it up above. And this looks like correct. So I'm going to give it some thumbs up some feedback. So if I don't want to kind of like go diving around in here for different and figure out like all the different things I need to choose manually, I can specify in natural language here and it'll run there. If I remove the is root equals true filter, another neat thing that I can do is basically search based on name. So if we go, if we remember from the top level trace, there's a bunch of subruns, and maybe I want to look at all the specific subruns. So let's look at the specific subruns for retrieve documents. So now I have all the retrieve document steps, and if I click into here, there's actually some nested things here, right? So this shows up as part of a larger trace. But basically, I can do things like filter on sub components of a chain and then I can apply the same exact filters as before. So if I want to look up where retrieve documents has a latency of more than one second, I can click into this here. And so here you know we can see that yeah, everything within here is longer than, and this is, this is just this specific kind of like subset here. There's also a concept of advanced filters. And so let me maybe, let's keep these filters and let me click here. let's keep these filters and let me click here and two three things pop up trace filters tree filters and a raw query so trace filters apply to the root run of the trace so remember i removed the is root equals true and so i have all the sub runs here but one really common thing to do is basically look for sub runs where the parent run has some attribute. Specifically in this case what I want to do is look for subruns of retrieved documents that take longer than one second where the parent had a negative feedback, let's say. So I can click here into trace filters and I have all the same options as before and so I can go feedback, user score is zero. And now if I look at a run, so I have, this is the retrieve documents where it took longer than a second because I still have that filter applied. And if I go up to the top level run and I look at feedback, it had a user score of zero. So basically what I can do is I can filter the sub runs based on the trace attributes. Again, this is really important when you're collecting things at the top level. And this could be feedback from the user. This could also be other metadata that you assign automatically at the top level, but you want to filter for sub runs. I can also do the opposite. So I can also I can also do the opposite. So I can also go back to here, I can say is root equals true. And if you notice here, I can't add trace filters, because when is root equals true, then any filter here is the same as a trace filter. But one thing I can do is a tree filter. And so this will basically filter these runs, if any run that happens below matches some criteria. So I can add something like this, and so let's do retrieve docs, and let's add another filter for latency, one second. And so now here, if I look at this, for example, I can see that this filters for where retrieve docs is greater than one second, but it gives me all of the top level traces. So I can see that this filters for where retrieve docs is greater than one second, but it gives me all of the top level traces. So I can also do something like feedback on the top level, user score is one, and this is the this is very similar to the query that I did before, but in the reverse order. So I'm filtering for top-level traces where the feedback, where the user score is one, and where there's some sub-run where retrieve docs has greater than one latency. And so if I click into here, I can see that I have the user score equals one, and the retrieve docs is greater than one second. The last thing I want to show is just copying and pasting these filters. The last thing I want to show is just copying and pasting these filters. So here, if I copy this filter, I get basically a string representation of this exact filter that I have here. What I can then do is I can paste this either into this raw query bar right here or into the SDK that we have. And this will basically apply this filter. And so you can see that it's a query language and equals is root true. I can also modify this here if I want and then when I click it, it applies it. Note that it adds it as filters. So if you have previous filters, you'll need to basically remove them. If you want the filter that you post to be the only filter present. That's pretty much it for filtering. Filtering is really, really powerful to let you dive into subsets of the data based on attributes of the trace, attributes of the parent run, attributes of child runs, and we've added a lot of functionality around that. So I hope you enjoy this feature to be able to explore your data more handily.
Filtering: Advanced run analysis with new filters and AI Query in LangSmith
Whether you’re trying to understand the experience of a specific customer segment or find traces associated with poor user feedback scores, filtering allows you to focus on the subset of traces that matter to you and to drill down into the details you need. LangSmith lets you filter based on a variety of trace attributes, and also offers full text search on inputs and outputs.

We’ve added new functionality for allowing for filtering of runs based on attributes of either their *parent* or *child* runs. This is particularly useful for filtering runs that are part of an agent (or any multi-step) workflow.

Documentation: https://docs.smith.langchain.com/monitoring/faq/filter
Blog post: https://blog.langchain.dev/langsmith-production-logging-automations/