[EAAPL-RAG002] Multi-Source Retrieval-Augmented Generation

Category: Artificial Intelligence / Retrieval-Augmented Generation Sub-category: Heterogeneous Source Integration Version: 1.3 Maturity: Proven Tags: rag multi-source source-connectors normalisation attribution conflict-resolution federation Regulatory Relevance: APRA CPS230, Privacy Act 1988, ISO/IEC 42001 Section 6.1, NIST AI RMF (Map 1.5)

1. Executive Summary

Enterprise knowledge is never stored in a single system. Policy documents live in SharePoint, technical runbooks in Confluence, customer data in Salesforce, financial reports in ERP exports, and operational metrics in data warehouses. Multi-Source RAG extends the foundational RAG pattern (EAAPL-RAG001) to orchestrate retrieval across these heterogeneous sources simultaneously, normalise their disparate formats into a unified embedding space, attribute answers to their authoritative origin, and resolve conflicts when sources contradict each other.

For enterprise leaders, this pattern eliminates the organisational friction of designating a "single system of record" before deploying AI assistants. Instead, the system learns to weight sources by authoritative context, surfacing the most relevant answer regardless of where it lives. The business outcome is a knowledge assistant that answers questions drawing simultaneously on policy, product, operational, and people data — the equivalent of asking the most informed person in the organisation, who happens to have read everything. Pilot deployments in financial services and government have demonstrated 35–50% reductions in time-to-answer for cross-functional knowledge queries, with source attribution enabling compliance teams to audit the basis of every answer.

2. Problem Statement

Business Problem

Enterprise knowledge is siloed across dozens of systems maintained by different teams with different governance models. A question as straightforward as "What is our current refund policy for corporate clients?" may require consulting a CRM record, a policy document in SharePoint, a product team's Confluence page, and a legal team's approved exceptions list — across four systems with four different search interfaces.

Technical Problem

Different source systems produce documents in incompatible formats (PDF, HTML, JSON, database rows, Markdown), with incompatible metadata schemas, at different refresh rates, with different access control models. A naive multi-source approach that concatenates results from independent keyword searches produces low-quality, unranked context with no cross-source relevance normalisation. When sources disagree (e.g., a policy document and a Confluence page cite different values for the same policy parameter), the system has no principled mechanism to resolve the conflict.

Symptoms

• Users querying the AI assistant receive answers drawn only from one source system even when better information exists elsewhere
• Source attribution in responses is absent or incorrect, making audit trails unreliable
• Contradictory answers are generated when the same question is asked repeatedly, sourced from different systems on different runs
• Integration team spending weeks building bespoke connectors for each new data source without a reusable connector framework

Cost of Inaction

• Incomplete answers leading to incorrect operational decisions or customer communications
• Connector fragmentation: each new source system requires bespoke integration, with no amortisation across the knowledge platform
• Inability to unify enterprise search into a single interface — users maintain separate search habits for each system

3. Context

When to Apply

• Organisations with knowledge spread across 3+ source systems that users need to query simultaneously
• Deployments where the authoritative source of truth varies by document type (legal: SharePoint; operational: Confluence; customer: CRM)
• Scenarios where source attribution and conflict resolution are required for compliance
• Enterprise search modernisation programmes replacing multi-system search with a unified AI-powered interface

When NOT to Apply

• Single-source deployments (use EAAPL-RAG001)
• Sources are geographically or organisationally distributed with data sovereignty constraints (use EAAPL-RAG004 Federated RAG)
• Real-time data sources with sub-minute freshness requirements (use EAAPL-RAG006 Streaming RAG)
• Sources contain exclusively structured relational data (use SQL-generation or Graph RAG patterns)

Prerequisites

• API access or connector availability for all target source systems
• Unified identity model enabling ACL resolution across source systems (e.g., Azure AD groups that map to permissions in each source)
• Metadata schema alignment work to identify common fields (document type, effective date, owner, classification) across sources
• Source governance: each source system must have a designated data owner responsible for quality and freshness

Industry Applicability

4. Architecture Overview

Multi-Source RAG introduces a Source Abstraction Layer and a Normalisation Engine between raw source connectors and the unified embedding pipeline. These two components are the architectural differentiators from single-source RAG.

Source Connector Framework

Rather than building bespoke connectors, the pattern mandates a connector framework that abstracts each source into a standard document event model: {document_id, source_system, content_raw, metadata, acl_principals, fetched_at, content_hash}. Connectors are classified as pull (polling schedule), push (webhook/event stream), or on-demand (query-time API call). The connector framework handles authentication, rate limiting, error handling, and delta detection (comparing content hashes to avoid re-ingesting unchanged documents).

Each source system is assigned a source profile: a configuration object capturing the source's authority score by document type, the metadata mapping from source schema to canonical schema, the ACL mapping from source permissions to enterprise identity groups, and the refresh schedule. Source profiles are stored in a configuration registry, not hardcoded, enabling new sources to be onboarded without code changes.

Normalisation Engine

Raw documents from different sources arrive in incompatible formats. The normalisation engine applies format-specific parsers (PDF via Apache Tika, HTML via BeautifulSoup, JSON via schema mapping, Markdown via AST parser) to produce a canonical document structure. Critically, normalisation also includes semantic normalisation: the engine identifies domain-specific terminology that differs across sources (e.g., "customer" in CRM vs. "client" in legal documents vs. "policyholder" in insurance) and maps them to canonical concepts. This enables cross-source retrieval of semantically equivalent content regardless of surface form.

Unified Embedding Space

All normalised chunks are embedded using a single embedding model, producing a unified vector space where semantic similarity is meaningful across source provenance. This is why embedding model lock-in is more consequential in multi-source deployments: different embedding models produce incomparable vector spaces, so the model must be fixed across all sources and changed atomically.

Source provenance (which system the chunk came from) is stored as metadata, not encoded in the embedding. This separation allows retrieval to be source-agnostic (finding the most semantically relevant content regardless of source) while enabling post-retrieval source filtering and attribution.

Source-Weighted Retrieval

After the initial ANN retrieval returns top-K candidates from across all sources, a source relevance weighting step re-scores candidates by combining the semantic similarity score with a source authority weight for the query type. For example, a query about regulatory compliance would upweight chunks from the compliance SharePoint library and downweight chunks from informal Confluence pages, even if the Confluence page has a marginally higher embedding similarity. Authority weights are configured per-query-type in the source profiles and can be overridden by explicit query metadata (e.g., user specifying "search only official policy documents").

Conflict Resolution

When retrieved chunks from different sources make contradictory claims, the conflict resolver applies a deterministic resolution strategy:

1. Recency-first: if effective dates differ, the more recent document's claim takes precedence
2. Authority-first: if one source is designated authoritative for the domain, it takes precedence regardless of date
3. Explicit conflict surfacing: when neither rule resolves the conflict, the system surfaces both claims to the user with source attribution, explicitly noting the discrepancy ("Policy document A states X; Confluence page B states Y. The authoritative source is A.")

The conflict resolver is configurable per source-pair and per document type, allowing organisations to encode their own authority hierarchies.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Cross-Source ACL Enforcement

The most critical security requirement in multi-source RAG is ensuring that a user cannot retrieve content from source system B via the RAG interface when they lack direct access to source system B. The ACL Normaliser maps all source-system permissions to enterprise identity groups at ingestion time, and the pre-retrieval filter enforces these mappings at query time. The ACL mapping must be kept in sync with source-system permission changes — a scheduled ACL re-sync job must run at a minimum daily.

Data Classification Propagation

If a CRM record carries a CONFIDENTIAL classification, that classification must propagate through normalisation, chunking, embedding, and retrieval to the final response. The assembled context window classification must be the maximum of all included chunk classifications.

OWASP LLM Top 10 Mitigations

9. Governance Considerations

Source Authority Governance

Each source system must have a designated data steward who owns the source profile configuration, including authority weights and metadata mappings. Changes to authority weights require approval from the data steward and an AI governance representative, because they change which answers users receive.

Conflict Resolution Audit Trail

Every conflict resolution decision must be logged: which sources conflicted, which resolution rule was applied, and what decision was made. This log is a governance artefact for auditors reviewing the basis of AI-generated answers.

Governance Artefacts

10. Operational Considerations

Monitoring

Service Level Objectives

Disaster Recovery

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Source Integration Approach

Conflict Resolution Strategy

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

15. Reference Implementations

AWS

• Connectors: AWS Glue with connectors for S3, RDS, Salesforce (via AppFlow), SharePoint (via custom Lambda)
• Normalisation: AWS Lambda (Python) + Apache Tika on Fargate
• Vector store: Amazon OpenSearch with k-NN; source_id as metadata field
• Conflict resolution: Lambda function + DynamoDB for resolution rules

Azure

• Connectors: Azure Logic Apps + Microsoft Graph API; Azure Data Factory for DB sources
• Normalisation: Azure Functions + Azure AI Document Intelligence
• Vector store: Azure AI Search with multi-index federation or unified index with source facets
• Conflict resolution: Azure Functions with Cosmos DB for conflict log

GCP

• Connectors: Cloud Run jobs + Pub/Sub for event-driven; Dataform for DB exports
• Normalisation: Cloud Run + Document AI
• Vector store: Vertex AI Vector Search; AlloyDB pgvector with source_id column
• Conflict resolution: Cloud Functions + Firestore for resolution log

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven — Multi-source RAG is deployed in production at many enterprises; connector frameworks are mature; the primary operational challenge is ongoing connector maintenance and ACL sync.

18. Revision History