Metadata filters: searching within the right department, period or case

Metadata filters narrow a RAG system’s search to documents that match the department, period, document type or case relevant to a question. This reduces the chance that the model draws on the wrong or outdated document. It can make answers more precise and help keep retrieved information within the right context.

A filter works only when metadata is accurate and the question provides enough context to choose the right subset. Access rights must also be enforced when information is retrieved; a missing or incorrect filter can exclude relevant material or expose information to someone who should not see it. Metadata filters are an important part of RAG, but they do not replace reliable sources, authorization or review.

What metadata adds to a search

Metadata describes a document rather than providing the answer someone is looking for. It can include the source, date, department, document type, version, status and access level. For example, a document might be marked as coming from human resources, applying to a particular period and representing current policy.

When documents are ingested, these attributes are stored alongside the text passages the system searches. The distinction matters: semantic search finds text that is related in meaning to the question, while metadata filtering limits the collection of documents in which the system searches. How documents are divided into passages also matters; see chunking explained.

Why semantic search can miss without filters

Semantic search looks for passages that resemble a question in meaning. This is useful when a user does not use the same words as the source document. But similarity alone does not establish that a passage is current, applicable or from the right department.

An older policy document may use almost the same wording as a current one. Two cases may also use similar terms. Without suitable boundaries, a passage from either source can rank highly and be supplied to the model as context. The model may then produce a convincing answer based on information that does not apply to the question.

A filter reduces this risk by deciding which documents can be considered before the search. It does not make retrieval foolproof: incorrect metadata or a badly chosen filter can exclude the right document. Quality therefore depends on the sources, search settings and how answers are evaluated. See also measuring RAG quality.

Filtering before or after retrieval

With pre-filtering, the system narrows the search space before retrieving semantically similar passages. If someone asks for the current expense policy for a department, the system can first select documents for that department with a current status. It then searches for relevant passages within that selection.

With post-filtering, the system searches broadly and removes results that do not meet the criteria afterwards. This can be useful when some criteria only become clear after the search, but it has a drawback: irrelevant results may already have been retrieved, while the right document may have fallen outside the initial set. Post-filtering should not be the only safeguard for access rights. Limit what a person can retrieve during the search, and check permissions again when information is shown.

Filtering can improve precision, but an overly narrow selection can leave too little context. The system should be able to say that it found no suitable source or ask for clarification. That is more reliable than filling in an answer from documents that only partly fit. For an overview of how this kind of system works, see RAG explained.

Populating, updating and securing metadata

Metadata starts in the ingestion process. Where possible, take attributes from reliable source systems, such as a document management environment, and define which values are allowed. If departments are named in different ways, filters may miss documents. Missing, conflicting or incorrectly entered values cause similar problems.

Make clear who is responsible for updating metadata. A document can move from draft to approved, or from current to expired. If its status is not updated, an old document may remain in search results. When documents are ingested or changed, check that required fields are present and that their values match the source.

Access levels need particular care. A document should only be retrieved for someone who is allowed to see it. Base that decision on current identity and permissions, not only on a text label stored with the document. An access control error in the search layer could expose or summarize information for an unauthorized user.

Dates, versions and the meaning of the question

A date or status filter helps distinguish current information from expired material. Still, “newest” does not always mean “applicable”: a newer attachment might apply only to a specific department or period. Define what date fields mean, such as publication date, effective date or last modified date, and use them consistently.

The system can infer filters from a question when the user names a department, period or case. But questions are often incomplete. “What is the policy?” does not specify which policy or version is meant. If the system silently chooses a department or date, it may select the wrong documents. In that situation, it should ask for clarification, or use a predefined default only when that is appropriate for the application. When designing the system, consider how it selects RAG sources and supports its answers.

Testing and checklist

Test filters with example questions from different situations: a question that names a department and period, one without a case, a reference to an older version, and a user with limited access. Check which documents and passages were retrieved, which were excluded, and whether the answer says when suitable sources are missing. Repeat the tests when metadata, source files or filter rules change.

Use this checklist during design and maintenance:

• Define the required metadata, such as source, department, document type, date, version, status and access level.
• Use consistent values and check for missing or conflicting metadata during ingestion.
• Apply current access rights before protected content is retrieved or displayed.
• Distinguish current from expired documents and define what each date field means.
• Ask for clarification when a question lacks enough context for a reliable filter choice.
• Test that the right sources are found and that irrelevant or unauthorized sources stay out of the results.