ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/multi-index-federation.md

Multi-Index Federation and Cross-Search

Last updated: 2026-06-19 | Verified: MCP 2026-06-19 Status: GA (single-index), Not supported (native cross-index) Category: RAG Architecture & Semantic Search

---

Introduksjon

Et av de vanligste spørsmålene fra enterprise-arkitekter er: "Kan vi søke på tvers av flere Azure AI Search-indekser i en enkelt spørring?" Svaret er nei — Azure AI Search støtter ikke native multi-index federation. Hvert søk er alltid avgrenset til én enkelt indeks.

Dette er en bevisst designbeslutning, ikke en begrensning. Enkelt-indeks-søk gir konsistente scorer, unified ranking, og forutsigbar ytelse. Cross-index-søk ville kreve score-normalisering, resultat-merging, og distribuert ranking — noe som introduserer betydelig kompleksitet og uforutsigbarhet.

For scenarioer der data logisk tilhører separate indekser (ulike skjemaer, compliance-krav, eller ulike formål), må applikasjonslaget implementere orkestrering. Denne filen beskriver arkitekturmønstre, routing-strategier og best practices for slike scenarioer.

Viktig funn: Microsofts offisielle FAQ sier eksplisitt: "Can I search across multiple indexes? No. A query is always scoped to a single index."

Multi-region støtte: Azure AI Search er en single-region service, men du kan oppnå høyere reliability ved å deploye identiske search services i flere regioner. Data synkroniseres via push eller pull (indexer) APIer. Load balancing håndteres av Azure Front Door, Traffic Manager, eller Application Gateway. Data residency: innhold lagres i regionen du velger, uten kryssregional dataflyt uten eksplisitt autorisasjon.

Multi-vector fields (Preview): Azure AI Search støtter nå multiple vektorer i ett dokumentfelt via Collection(Edm.ComplexType) — opp til 100 vektorer per dokument. Nyttig for multimodal data og lange dokumenter. perDocumentVectorLimit-parameteren kontrollerer antall matchende vektorer per dokument i query-resultater.

Kjernekomponenter

Hvorfor Azure AI Search ikke støtter cross-index queries

Utfordring	Forklaring
Scoring-isolasjon	BM25-scores er relative til dokumentfrekvens innenfor indeksen — scorer fra ulike indekser kan ikke sammenlignes direkte
Skjema-forskjeller	Ulike indekser kan ha helt ulike felt, datatyper og analysatorer
Ingen unified ranking	Ingen innebygd mekanisme for å re-ranke resultater på tvers av indekser
Ingen distribuerte transaksjoner	Oppdateringer til flere indekser er ikke atomiske

Enkelt-indeks vs. multi-indeks

Aspekt	Enkelt indeks	Multiple indekser
Query-logikk	Enkel, unified	Kompleks, krever orkestrering
Scoring	Konsistent	Inkonsistent mellom indekser
Vedlikehold	Enklere	Mer komplekst
Filtrering	Native, effektiv	Per-indeks, applikasjons-merging
Sikkerhet	Dokumentnivå-filtrering	Indeks-nivå isolasjon
Skalerbarhet	Vertikal (større tier)	Horisontal (flere services)

Nyere relevante features (2025)

Feature	Status	Relevans
Multi-vector field support	GA (2025)	Lagre multiple vektorer per dokument i én indeks
Agentic Retrieval	Preview	LLM-assistert query planning, men fremdeles single-index
Targeted vector filters	Preview	Filtre spesifikt for vektor-subqueries

Arkitekturmønstre

Mønster 1: Enkelt indeks med filtrering (anbefalt)

Flyt: Data fra multiple kilder → Felles indeks med type/kilde-felt → Filtrering ved søk

# Alle dokumenttyper i én indeks med type-felt
results = client.search(
    search_text="anskaffelsesregler",
    filter="doc_type eq 'regelverk' and department eq 'HR'",
    select=["title", "content", "doc_type", "department"],
    top=10
)

Fordeler:

• Enklest implementering
• Unified scoring og ranking
• Native filtrering, facettering
• Ingen orkestreringskode nødvendig

Ulemper:

• Skjemaet må være tilstrekkelig fleksibelt for alle dokumenttyper
• Indeksen kan bli stor (skalering vertikalt)
• Alle dokumenter deler analysatorer og innstillinger

Beste for: De fleste enterprise-scenarioer der data har lignende struktur.

Mønster 2: Parallell query med applikasjons-merging

Flyt: Query → Fork til N indekser (parallelt) → Samle resultater → Score-normalisering → Merged resultat

from azure.search.documents import SearchClient
from azure.identity import DefaultAzureCredential
import asyncio

async def query_multiple_indexes(query_text, indexes):
    credential = DefaultAzureCredential()

    async def query_index(index_name):
        client = SearchClient(
            endpoint=endpoint,
            index_name=index_name,
            credential=credential
        )
        results = []
        async for result in client.search(search_text=query_text, top=10):
            results.append({
                "source_index": index_name,
                "score": result["@search.score"],
                **result
            })
        return results

    # Parallelle queries
    tasks = [query_index(idx) for idx in indexes]
    all_results = await asyncio.gather(*tasks)

    # Flatten og normaliser
    merged = []
    for results in all_results:
        merged.extend(results)

    # MERK: Score-normalisering nødvendig her
    merged = normalize_scores(merged)
    merged.sort(key=lambda x: x["normalized_score"], reverse=True)

    return merged[:10]

def normalize_scores(results):
    """Min-max normalisering per indeks."""
    by_index = {}
    for r in results:
        idx = r["source_index"]
        if idx not in by_index:
            by_index[idx] = []
        by_index[idx].append(r)

    for idx, items in by_index.items():
        scores = [i["score"] for i in items]
        min_s, max_s = min(scores), max(scores)
        range_s = max_s - min_s if max_s != min_s else 1
        for item in items:
            item["normalized_score"] = (item["score"] - min_s) / range_s

    return results

Fordeler:

• Støtter fundamentalt ulike skjemaer
• Compliance-isolasjon mellom indekser
• Horisontal skalering

Ulemper:

• Score-normalisering er heuristisk, ikke eksakt
• Økt latency (selv med parallellisering)
• Kompleks kode å vedlikeholde
• Resultater kan "konkurrere" unfairly mellom indekser

Beste for: Scenarioer med fundamentalt ulike datatyper (HR-håndbok vs. produktkatalog).

Mønster 3: Query routing basert på intent

Flyt: Query → Intent-analyse (LLM/classifier) → Route til riktig indeks → Enkelt-indeks søk → Resultat

def route_query(query_text):
    """Bestem hvilken indeks som er mest relevant."""
    # Enkel keyword-basert routing
    if any(word in query_text.lower() for word in ["anskaffelse", "kontrakt", "anbud"]):
        return "regelverk-index"
    elif any(word in query_text.lower() for word in ["personal", "ferie", "lønn"]):
        return "hr-index"
    else:
        return "general-index"

# Eller med LLM-basert intent-klassifisering
def route_query_llm(query_text):
    response = openai_client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{
            "role": "system",
            "content": "Classify the query into one of: regelverk, hr, general"
        }, {
            "role": "user",
            "content": query_text
        }]
    )
    intent = response.choices[0].message.content.strip()
    return f"{intent}-index"

Fordeler:

• Kun én indeks queries per request (lavest latency)
• Tydelig domene-separasjon
• Skalerbar routing-logikk

Ulemper:

• Routing-feil betyr at brukeren ikke finner det de leter etter
• LLM-basert routing legger til latency og kostnad
• Krever vedlikehold av routing-logikk

Beste for: Klart adskilte domener med liten overlapp.

Mønster 4: Multi-region search services

Flyt: Query → Nearest region service (via Traffic Manager) → Lokalt søk → Resultat

For geo-distribuerte brukere der latency er kritisk:

• Identiske indekser i flere regioner
• Synkronisering via push/pull API
• Azure Traffic Manager, Front Door, eller Application Gateway for routing

Beste for: Globale applikasjoner med latency-krav.

Beslutningsveiledning

Valg av indeks-topologi

Trenger du ulike skjemaer per datakilde?
├── Nei → Enkelt indeks med filtrering (Mønster 1)
└── Ja → Er datakildene compliance-adskilt?
    ├── Ja → Multi-indeks med routing (Mønster 3)
    └── Nei → Kan skjemaene generaliseres?
        ├── Ja → Enkelt indeks med complex types
        └── Nei → Multi-indeks med parallell query (Mønster 2)

Vanlige feil

1. Opprette separate indekser for hvert datasett — Start med filtrering i én indeks
2. Sammenligne BM25-scores direkte mellom indekser — Scores er relative, ikke absolutte
3. Sekvensiell querying av multiple indekser — Bruk alltid parallell utførelse
4. Implementere cross-index joins — Azure AI Search støtter ikke dette
5. Ignorere skjema-denormalisering — Dupliser data hvis nødvendig for søkbarhet

Røde flagg

• Behov for mer enn 3-4 indekser → Vurder om indeksdesignet er suboptimalt
• Brukere klager over manglende resultater → Mulig routing-feil i multi-indeks-oppsett
• Inkonsistente scorer mellom søk → Score-normalisering trenger kalibrering

Integrasjon med Microsoft-stakken

Tjeneste	Rolle
Azure Traffic Manager	Geo-basert routing mellom search services
Azure Front Door	Lastbalansering og CDN for multi-region
Azure Application Gateway	L7 load balancing for search requests
Azure API Management	API-gateway med routing-logikk for multi-indeks
Semantic Kernel	Orchestration-framework for multi-indeks RAG

Offentlig sektor (Norge)

Data-klassifisering og indeks-separasjon

• Ugradert data: Kan samles i én indeks med filtrering
• Fortrolig/begrenset: Bør ha egen indeks med strengere tilgangskontroll
• Sikkerhetsgradert: Kan kreve egen search service i isolert nettverk

Compliance-krav

• Arkivloven: Dokumenter fra ulike arkivserier kan kreve logisk separasjon
• Forvaltningsloven: Tilgangskontroll per sak/avdeling
• GDPR: Persondata kan kreve egen indeks for enklere sletting (right to be forgotten)

Anbefalt tilnærming

For de fleste offentlige virksomheter:

1. Primærindeks: All ugradert dokumentasjon i én indeks med avdelings-/kategori-filtrering
2. Sekundærindeks: Persondata eller begrenset informasjon med RBAC
3. Routing: Intent-basert routing for å bestemme hvilken indeks som søkes

Kostnad og lisensiering

Kostnadsimplikasjoner av multi-indeks

Topologi	Kostnadsfaktorer
Enkelt indeks	Én search service, standard lagring og query-kostnad
Multiple indekser (én service)	Delte ressurser, men økt lagring
Multiple search services	Separate kostnader per service, duplikert lagring
Multi-region	Multiplisert lagring + synkroniseringskostnad

Kostnadsoptimering

• Start med enkelt indeks — Unngå unødvendig kompleksitet og kostnad
• Bruk replika-fordeling fremfor separate services der mulig
• Vurder search service tier basert på samlet indeksstørrelse og query-volum
• Synkroniser incrementally i multi-region — ikke full re-indeksering

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. Hvor mange datakikylder har dere, og har de lignende eller ulik struktur?
2. Er det compliance-krav som krever fysisk separasjon av data?
3. Trenger brukerne å søke på tvers av alle datakilder, eller er domenene adskilte?
4. Hva er latency-kravene — kan parallell multi-indeks query aksepteres?
5. Har dere geo-distribuerte brukere som trenger multi-region?
6. Hva er budsjett — én stor service vs. flere mindre?

Fallgruver

• Å designe for cross-index fra start uten å vurdere filtrering i enkelt indeks
• Å underestimere kompleksiteten i score-normalisering og resultat-merging
• Å anta at fremtidige Azure-oppdateringer vil løse cross-index — dette er et bevisst designvalg
• Å bruke LLM for query routing uten fallback til bredere søk

Anbefalinger per modenhetsnivå

Nivå	Anbefaling
Starter	Enkelt indeks med filtrering — alltid start her
Intermediær	Legg til separate indekser kun ved compliance-krav, med intent-routing
Avansert	Multi-region med synkronisering, custom orkestrering, semantic reranking av merged resultater

Viktig designprinsipp

Default til enkelt indeks med filtrering. Opprett separate indekser kun når du har en konkret, dokumentert grunn — ikke "for sikkerhets skyld."

Grunner som rettferdiggjør separate indekser:

• Fundamentalt ulikt skjema (tekst vs. strukturert data)
• Compliance-krav til fysisk separasjon
• Ulik livsyklus (hyppig vs. sjelden oppdatering)
• Ulike tilgangsmodeller (intern vs. ekstern)

Kilder og verifisering

Verified (MCP-research)

• Azure AI Search FAQ — Cross-index queries
• Multi-region deployments
• Grounding data design — Index topology
• Multi-vector field support
• Tutorial: Index from multiple data sources
• GitHub: Multiple search services (.NET)

Baseline (modellkunnskap)

• Score-normaliserings-kode
• Routing-eksempler
• Offentlig sektor-anbefalinger