Skip to main content
Filters restrict knowledge searches to documents matching specific criteria. Attach metadata when adding content, then filter by that metadata when searching.
Pass a configured Knowledge instance backed by a vector database that supports metadata filtering.

Why Use Filters

  • Personalization: Retrieve documents for a specific user or group
  • Tenant scoping: Apply trusted server-side filters before each search
  • Precision: Reduce noise by narrowing results to relevant documents
Treat knowledge filters as retrieval constraints. Enforce authorization separately. Run-level knowledge_filters can replace agent defaults. Derive authorization filters in trusted server code and prevent untrusted clients from supplying replacements.

Manual Filtering

Pass filters explicitly when creating the agent or searching:
Keys within one dictionary filter are combined with AND logic.

Agentic Filtering

Let the agent extract filters automatically from the query. The agent analyzes the user’s question and determines which filters to apply.
This requires a Contents DB to track available filter keys.

Manual vs Agentic Filtering

Traditional vs Agentic RAG

Filters work with both RAG approaches:
Use one approach at a time. Agentic RAG (search_knowledge=True) is recommended for most use cases.

Metadata Design

Good metadata enables effective filtering:
Tips:
  • Use consistent values (always "engineering", not sometimes "eng")
  • Include temporal data for time-based filtering
  • Add scope metadata for trusted server-side filtering

Supported Vector Databases

Filtering is supported on:
  • ChromaDB
  • Couchbase
  • LanceDB
  • Milvus
  • MongoDB
  • PgVector
  • Pinecone
  • Qdrant
  • SurrealDB
  • Upstash
  • Valkey
  • Weaviate

Next Steps

Advanced Filtering

Complex filters with OR, NOT, and comparisons

Content DB

Required for agentic filtering

Search & Retrieval

How filtering affects search