Multi-faceted filtering

What you'll learn

• Explain the difference between ranking a chunk and allowing it.
• Order four filters by cost: metadata, score, keyword, diversity.
• Diagnose a filter that empties the result because it ran after the search.
• Choose which facets to write at ingestion so later filters have something to test.

Lesson 4 of T6.1 ended on a failure MMR cannot fix: last year's refund policy competing with this year's. Similarity cannot tell the two apart, and diversity keeps whichever came first. A rule that can tell them apart has to look at something other than the text's meaning.

That is a filter: a yes-or-no test on a chunk. Ranking decides the order of chunks; filtering decides which chunks are allowed at all. A Larkspur question about refunds on annual plans should never see the superseded policy, however well it scores.

Notebook 05a builds four filters on a customer table. Each row of customers-100.csv becomes a document whose metadata holds country, company, city, subscription date and website. It embeds them with all-MiniLM-L6-v2 in Chroma, retrieves the top 10 for Which customers work for companies in Chile? with relevance scores, and passes them through this chain:

Figure 1: The four filters in 05a, cheapest first.

Each filter removes a different kind of wrong chunk, at a different price:

Table 1: The four filters and their cost.

The order is a cost decision. Exact checks run first, and the one filter that calls the embedding model runs last, on whatever survives. Each filter is optional, so the same function serves a question with a known country and one without.

The diversity filter is a hard cut at one similarity. MMR from lesson 4 of T6.1 makes the same trade softly, weighing redundancy against relevance with λ.

The four filters in 05a only remove. They run on the 10 chunks the search returned, so if a Chilean customer ranked 11th, no filter brings it back. A strict combination can remove all ten and leave nothing. We call this post-filter starvation: the filter is right and the result is empty, because the search spent its slots on chunks the filter was always going to reject.

When the condition is known before the search, push it into the store:

Figure 2: The same condition before and after ranking. Only the pre-filter guarantees 10 matching chunks when 10 exist.

Chroma takes the condition as a filter argument on the similarity search and ranks only the matching chunks, so every one of the 10 slots goes to a match. Keep post-filters for conditions the store cannot express, such as the diversity check.

Here is the arithmetic of starvation, for a condition that one chunk in twenty satisfies and spread evenly through the ranking (Illustrative):

Table 2: Matches reaching the model for a rare condition (illustrative).

The settings in 05a are specific to its setup. A relevance threshold of 0.35 belongs to all-MiniLM-L6-v2 on that table. The substring test for chile would also accept any longer word that contains those letters.

A filter can only test a field that exists. For the Larkspur handbook the useful facets are written at ingestion: the handbook section, which T5.3's header splitter records, and the version and date fields of the T5.2 metadata schema.

Key distinction: a facet missing at ingestion cannot be recovered by retrieval. If the old refund policy was indexed without a version, no filter, MMR setting or reranker can reliably drop it.

1. Pre-filter on version. Every handbook query filters to the current version in the store, before ranking. That removes last year's refund policy outright.
2. Pre-filter on section when the question names a topic the router is sure of, such as Refunds.
3. Post-filter on score with the floor from lesson 1 of T6.1, so an out-of-scope question still returns nothing.
4. Leave diversity to MMR on the survivors, at the λ lesson 4 of T6.1 settled on.

Lesson 6 of T6.1 steps back from single techniques and compares whole retriever patterns, including what they cost when they nest.

The code for this lesson is in these notebooks. Colab runs one in your browser: install the packages its first cell imports and set the API keys it reads. To run every notebook as written, clone the repository and use its uv environment.

• Ranking orders chunks; filtering decides which are allowed. Run cheap exact checks (metadata, score, keywords) before the diversity check that needs an embedding call per chunk.
• Post-filters only remove from what the search returned and can leave nothing (post-filter starvation). When a condition is known up front, pass it to the store so every slot goes to a match.
• Write facets such as section, version and date at ingestion; a field that was never written cannot be filtered on.