[EAAPL-RAG010] Contextual RAG with Metadata Filtering

Category: Artificial Intelligence / Retrieval-Augmented Generation Sub-category: Metadata-Driven Contextual Retrieval Version: 1.2 Maturity: Proven Tags: rag metadata-filtering contextual-retrieval pre-retrieval-filtering faceted-search progressive-disclosure schema-design Regulatory Relevance: APRA CPS234, Privacy Act 1988 APP 3 (data minimisation), ISO/IEC 42001 Section 8.4, EU AI Act Article 10

1. Executive Summary

Contextual RAG with Metadata Filtering extends the foundational RAG pattern with a rich, queryable metadata layer that enables users and system components to scope retrieval with precision before semantic similarity search executes. Rather than searching all vectors globally, the retrieval is constrained by metadata predicates — date ranges, document categories, departmental ownership, classification levels, language, and custom domain attributes — reducing the effective search space, improving precision, and enforcing contextual boundaries that pure semantic search cannot provide.

For enterprise architects and product managers, metadata filtering is the mechanism that transforms a general-purpose knowledge search into a domain-specific, context-aware knowledge assistant. A legal counsel who queries the AI assistant expects answers sourced only from legal documents effective today, in the relevant jurisdiction, and classified at their clearance level — not answers drawn from a two-year-old draft or a policy from a different business unit. Metadata filtering encodes these contextual expectations as first-class retrieval parameters rather than requiring them to be expressed in the query text and hoped to be respected by the LLM. The pattern is the recommended baseline for all production enterprise RAG deployments over large, heterogeneous corpora.

2. Problem Statement

Business Problem

Enterprise knowledge corpora are large and heterogeneous. A financial institution's knowledge base contains policies from multiple jurisdictions, in multiple languages, at multiple classification levels, some current and some superseded. A query for "the current refund policy for corporate clients" could, without metadata filtering, retrieve a superseded policy from 2019, a policy applicable to retail clients, or a draft policy not yet approved. Each of these is semantically similar to the query but contextually wrong.

Technical Problem

Semantic similarity search optimises for vector distance, not contextual appropriateness. A document can be highly semantically similar to a query while being contextually wrong (wrong date, wrong department, wrong jurisdiction, wrong classification). Without metadata filtering, the retrieval layer has no mechanism to enforce contextual constraints — the LLM must infer them from document text, which it does unreliably, or the system must hope that contextually appropriate documents happen to score higher than contextually wrong ones.

Symptoms

• AI assistant returns answers based on superseded policies or procedures
• Answers reference documents from the wrong department or business unit, confusing users
• Multilingual queries return results in the wrong language despite the user's language preference
• Date-sensitive queries ("what are our current obligations under X") return historical documents
• Users add explicit temporal and domain constraints to every query ("current", "Australia only", "retail banking") because they have learned the system ignores context

Cost of Inaction

• User trust erosion: users who receive contextually wrong answers (superseded policy, wrong jurisdiction) lose confidence rapidly
• Compliance risk: AI system provides outdated regulatory guidance, leading to incorrect compliance decisions
• Support burden: high volume of "the AI gave me the wrong policy" reports requiring manual correction

3. Context

When to Apply

• Large heterogeneous corpora where documents have significant variation in date, category, jurisdiction, classification, or status
• Multi-department deployments where users need results scoped to their business unit or domain
• Regulated corpora where only current, approved, and appropriately classified documents should be retrieved
• Multilingual corpora where language-specific retrieval is important
• Any deployment where temporal freshness of answers is a user requirement

When NOT to Apply

• Very small corpora (< 10,000 documents) where the global search space is manageable without metadata filtering
• Corpora with no meaningful metadata differentiation (all documents have the same date, category, and status)
• Use cases where cross-context retrieval is desired (comparative analysis across time periods or departments)

Prerequisites

• A well-defined metadata schema agreed across all source systems
• Metadata populated consistently at ingestion time (missing metadata values must trigger quality alerts)
• A metadata extraction pipeline for documents that do not have explicit metadata (e.g., PDF files without embedded metadata)
• A user interface or API that exposes metadata filter parameters to users or calling applications

Industry Applicability

4. Architecture Overview

Contextual RAG with Metadata Filtering introduces a carefully designed metadata schema as a first-class architectural concern, alongside mechanisms for metadata extraction, filter construction, and progressive disclosure of context.

Metadata Schema Design

The metadata schema is the foundation of the pattern. Schema design decisions made at deployment time are difficult to change later because they require re-ingestion of the entire corpus. The schema must balance completeness (capturing all contextually relevant attributes) with practicality (all fields must be extractable and populated reliably).

A canonical enterprise RAG metadata schema includes:

• Temporal: effective_date, expiry_date, last_modified, publication_date
• Provenance: source_system, source_document_id, document_version, author, owner_department
• Classification: security_classification, data_sensitivity, contains_pii
• Content type: document_type (policy/procedure/runbook/faq/report/contract), language, format
• Domain: jurisdiction, product_line, regulatory_body, clinical_specialty (domain-specific)
• Status: lifecycle_status (DRAFT/CURRENT/SUPERSEDED/ARCHIVED)

Every field in the schema must have a defined cardinality (single-value or multi-value), a defined value set or validation rule, and a defined population source (embedded in source document, extracted by NLP, or assigned by governance process).

Metadata Extraction Pipeline

Not all enterprise documents arrive with structured metadata. The extraction pipeline must infer metadata from document content when explicit metadata is absent. This involves:

• Date extraction: identify effective dates, review dates, and publication dates from document headers, footers, and first paragraphs using NLP or document intelligence services
• Document type classification: classify the document as policy/procedure/FAQ/contract/report using a fine-tuned text classifier
• Language detection: identify the document language using langdetect or equivalent
• Entity extraction for domain metadata: extract regulatory body names, product names, jurisdiction references for domain metadata population

Metadata quality gates enforce minimum field population requirements before a document is indexed. Documents that fail quality gates enter a "metadata review" queue rather than being indexed without metadata.

Filter Construction

Metadata filters can be applied at three levels:

1. System-imposed filters (always on, not user-controllable): ACL filters (EAAPL-RAG003), lifecycle status filter (exclude ARCHIVED and DRAFT by default), classification ceiling (user's maximum clearance)

2. User-provided explicit filters: the user or calling application specifies filter values explicitly (e.g., jurisdiction: AU, date_after: 2024-01-01, document_type: policy). These can be extracted from the user's query text (NLP-based filter extraction: "current policy" → status: CURRENT) or provided via a structured filter UI

3. Context-inferred filters: the system infers filters from context — the user's profile (department, role, jurisdiction), the conversation history, or the query classification. A user authenticated with a jurisdiction of "NSW" automatically has jurisdiction IN [NSW, AU] applied to their queries without specifying it explicitly

Filters are composed with AND logic by default; OR logic is available for multi-value fields (a user's permitted departments, multiple accepted languages).

Progressive Disclosure

When metadata filtering produces too few results (fewer than K minimum relevant chunks), a progressive disclosure strategy relaxes filters in a defined order until sufficient results are found. For example: if {status: CURRENT, jurisdiction: NSW} produces 0 results, the system relaxes jurisdiction to {AU} and tries again before relaxing status to include SUPERSEDED. Each relaxation is logged, and the response includes a provenance note: "No current NSW-specific documents found; the following is based on the applicable national policy."

Progressive disclosure prevents "no results" responses while maintaining metadata filter transparency — the user always knows what filters were applied.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Filter Tamper Prevention

Metadata filter parameters must be constructed server-side from trusted sources (identity provider claims, server-side user profile). Client-supplied filter parameters must be validated against the user's authorised filter scope — a user must not be able to supply a filter parameter that elevates their access beyond their authorised scope. For example, a user with clearance: OFFICIAL-SENSITIVE must not be able to supply classification: PROTECTED as a filter parameter.

OWASP LLM Top 10 Mitigations

9. Governance Considerations

Metadata Schema Governance

The metadata schema is a shared enterprise data contract. Changes to the schema require a formal change management process: RFC, review by source system owners and data stewards, backward compatibility assessment, and a migration plan for existing indexed chunks. The schema registry must version all schema changes.

Filter Relaxation Policy Governance

The progressive disclosure relaxation order and conditions must be formally agreed by data stewards and approved by the AI governance board. The relaxation policy determines what contextual boundaries can be crossed automatically (e.g., can jurisdiction be relaxed from state to national? Can status be relaxed from CURRENT to SUPERSEDED?) — these are governance decisions, not engineering decisions.

Governance Artefacts

10. Operational Considerations

Monitoring

Service Level Objectives

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Filter Enforcement Strictness

Metadata Extraction Automation

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

15. Reference Implementations

AWS

• Metadata extraction: Amazon Textract + Comprehend
• Vector store with metadata: Amazon OpenSearch Service (supports rich filter queries on metadata fields)
• Filter composition: Lambda function constructing OpenSearch filter DSL
• Progressive disclosure: Lambda step function with configurable relaxation rules

Azure

• Metadata extraction: Azure AI Document Intelligence + Language Service
• Vector store: Azure AI Search (native filter expressions on indexed fields)
• Filter composition: Azure Functions; Azure AI Search OData filter syntax
• Progressive disclosure: Logic Apps workflow with retry logic

GCP

• Metadata extraction: Google Document AI + Cloud Natural Language
• Vector store: Vertex AI Vector Search (with numeric/string filter constraints)
• Filter composition: Cloud Run; Vertex AI filter expression builder
• Progressive disclosure: Cloud Workflows step function

Self-Hosted

• Metadata extraction: Apache Tika + spaCy
• Vector store: Weaviate (where filter), Qdrant (filter), pgvector (WHERE clause)
• Progressive disclosure: Custom Python orchestration class

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven — Metadata filtering in vector databases is a well-established capability supported in all major platforms; the pattern is deployed in production across regulated industries; the primary challenges are metadata schema governance and extraction quality, not technology readiness.

18. Revision History