ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/vector-indexing-techniques.md

Vector Indexing - Techniques and Configuration

Last updated: 2026-06-19 | Verified: MCP 2026-06-19 Status: GA (Hybrid search), Preview (Scalar quantization) Category: RAG Architecture & Semantic Search

---

Introduksjon

Vektorindeksering er selve motoren bak moderne semantisk søk i RAG-systemer. Mens embedding-modeller konverterer tekst til numeriske representasjoner, er det indekseringsalgoritmene som gjør det praktisk mulig å søke gjennom millioner av vektorer på millisekunder. For enterprise AI-løsninger handler vektorindeksering ikke bare om å velge riktig algoritme, men om å balansere presisjon, latency, kostnad og skalerbarhet.

I Microsoft-økosystemet er Azure AI Search den primære tjenesten for vektorindeksering, med støtte for Hierarchical Navigable Small World (HNSW) som standard-algoritme, kombinert med hybrid search som blander vector similarity med klassisk BM25 full-text search. For norske organisasjoner som bygger RAG-løsninger er vektorindeksering ofte det området hvor teknisk konfigurering har størst innvirkning på både brukeropplevelse og driftskostnader — feil valg kan føre til unødvendig høy latency, dårlig recall, eller eksploderende lagringskostnader.

Moderne vektorindeksering handler i økende grad om hybrid search — erkjennelsen av at verken keyword-søk eller vector search alene er optimal for alle scenarier. Dokumenter som inneholder eksakte termer (produktkoder, lovparagrafer, telefonnumre) trenger BM25, mens semantiske spørsmål som "hva er bedriftens policy på etikk?" krever vector similarity. Azure AI Search tilbyr innebygd støtte for hybrid search med konfigurerbar vekting, og legger på semantic ranker som et tredje lag for å rerangere resultater basert på Microsofts flerspråklige deep learning-modeller (adaptert fra Microsoft Bing).

Kjernekomponenter

Vektoralgoritmer i Azure AI Search

Algoritme	Type	Presisjon	Latency	Beste bruk
Hierarchical NSW (HNSW)	Approximate Nearest Neighbor	90-99%	Sub-10ms	Production RAG, høyt volum
Exhaustive KNN	Exact Nearest Neighbor	100%	>100ms ved skala	Små indekser, critical precision
Flat indexing	Linear scan	100%	>1s ved skala	Development, validation

HNSW er standarden for enterprise RAG fordi den balanserer recall (nøyaktighet) med query latency. Algoritmen bygger en hierarkisk graf hvor hver vektor kobles til nærmeste naboer på flere nivåer, slik at søk starter på øverste nivå og zoomer inn nedover. Dette gir O(log N) kompleksitet istedenfor O(N) ved linear scan.

Hybrid Search Configuration

Hybrid search kombinerer tre lag:

1. Vector search — Cosine similarity på embeddings
2. Full-text search (BM25) — Keyword matching med term frequency
3. Semantic ranker (optional) — Microsofts flerspråklige deep learning-reranking (adaptert fra Bing), reranker de øverste 50 resultatene

{
  "search": {
    "queryType": "semantic",
    "vectorQueries": [{
      "kind": "vector",
      "vector": [0.1, 0.2, ...],
      "fields": "contentVector",
      "k": 50
    }],
    "search": "offentlig anskaffelse AI etikk",
    "semanticConfiguration": "default"
  }
}

Vekting av hybrid scores:

Parameter	Beskrivelse	Standard	Range
alpha	Balanse mellom vector (1.0) og BM25 (0.0)	0.5	0.0–1.0
k	Antall vektorer fra vector search	50	1–1000
top	Totale resultater etter merge	10	1–1000

Tommelfingerregel:

• alpha=0.8–1.0 for semantisk søk ("hva mener retningslinjene om X?")
• alpha=0.3–0.5 for keyword-tunge domener (jus, teknisk dokumentasjon)
• alpha=0.5 for generell enterprise-søk

Index Configuration

En Azure AI Search index for RAG krever felt for både content og metadata:

{
  "name": "documents-index",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true
    },
    {
      "name": "content",
      "type": "Edm.String",
      "searchable": true,
      "analyzer": "nb.microsoft"
    },
    {
      "name": "contentVector",
      "type": "Collection(Edm.Single)",
      "dimensions": 1536,
      "vectorSearchProfile": "hnsw-profile"
    },
    {
      "name": "metadata_department",
      "type": "Edm.String",
      "filterable": true,
      "facetable": true
    }
  ],
  "vectorSearch": {
    "algorithms": [{
      "name": "hnsw-algorithm",
      "kind": "hnsw",
      "hnswParameters": {
        "m": 4,
        "efConstruction": 400,
        "efSearch": 500,
        "metric": "cosine"
      }
    }],
    "profiles": [{
      "name": "hnsw-profile",
      "algorithm": "hnsw-algorithm"
    }]
  }
}

HNSW-parametere:

Parameter	Beskrivelse	Standard	Innvirkning
m	Antall koblinger per node	4	Høyere = bedre recall, større index
efConstruction	Byggekostnad per insert	400	Høyere = bedre struktur, tregere indexing
efSearch	Søkebredde ved query	500	Høyere = bedre recall, høyere latency

Performance tuning:

• m=4, efConstruction=400, efSearch=500 — Standard production (90-95% recall)
• m=8, efConstruction=800, efSearch=800 — High precision (95-99% recall)
• m=2, efConstruction=200, efSearch=200 — Cost-optimized (85-90% recall)

Batch Indexing Strategies

For RAG-systemer med store dokumentsamlinger (>100K dokumenter) kreves batch indexing:

Strategi	Throughput	Best for
Single-threaded sequential	100-500 docs/min	Development, small datasets
Parallel batches (10-100 docs/batch)	2000-5000 docs/min	Standard enterprise
Streaming ingestion (Event Hub)	10K+ docs/min	Real-time updates, news feeds

# Parallel batch indexing
from azure.search.documents import SearchClient
from concurrent.futures import ThreadPoolExecutor

def index_batch(batch_docs):
    client = SearchClient(endpoint, index_name, credential)
    return client.upload_documents(documents=batch_docs)

batches = [docs[i:i+100] for i in range(0, len(docs), 100)]
with ThreadPoolExecutor(max_workers=10) as executor:
    results = list(executor.map(index_batch, batches))

Viktig: Azure AI Search har rate limits (3000 requests/sekund per replika). Høy-volum indexing krever skalering av replicas eller bruk av push-pattern via indexer.

Arkitekturmønstre

1. Standard RAG med Hybrid Search

Når: Generelle enterprise-scenarier (HR-dokumenter, policies, kunnskapsbaser).

Arkitektur:

• Embedding: text-embedding-3-large (1536 dim)
• Index: Azure AI Search med HNSW + BM25
• Reranking: Semantic Ranker (optional, +10-20% relevance)

Fordeler:

• Balansert mellom semantic search og keyword precision
• Håndterer både konseptuelle spørsmål og eksakte termer
• Lavere hallucination pga. keyword-grounding

Ulemper:

• Høyere latency enn pure vector (5-10ms overhead)
• Krever tuning av alpha-parameter per use case
• Semantic Ranker koster ekstra (50K queries/måned)

Kostnader (S1 tier, 100K dokumenter):

• Storage: ~1.5 GB (content + vectors) = $0.30/dag
• Queries: 10K/dag hybrid = neglisjerbar
• Semantic Ranker: $250/måned (500K queries)

2. Multi-Index Federation

Når: Organisasjoner med silo-deling av data (avdelinger, sensitivitet, juridisk separasjon).

Arkitektur:

• 3-5 separate indekser (HR, Finance, Legal, Public)
• Metadata-basert filtrering per brukerrolle
• Federated search aggregator

Fordeler:

• RBAC på index-nivå (enklere enn document-level filtering)
• Uavhengig skalering per domene
• Compliance-vennlig (dataresidency per index)

Ulemper:

• Kompleks resultat-aggregering og ranking
• Duplikatkostnader hvis dokumenter deles
• Høyere operational overhead

Implementering:

# Parallel query på multiple indexes
indexes = ["hr-index", "finance-index", "legal-index"]
query_vector = get_embedding(user_query)

async with asyncio.TaskGroup() as tg:
    tasks = [tg.create_task(
        search_client(idx).search(
            vector_queries=[{"vector": query_vector, "k": 20}]
        )) for idx in indexes if user_has_access(user, idx)]

results = merge_and_rerank([t.result() for t in tasks])

3. Scalar Quantization for Cost Optimization

Når: Høyt dokumentvolum (>1M dokumenter), cost-sensitiv, akseptabel 2-5% recall-drop.

Arkitektur:

• Compress vectors fra 1536 float32 (6 KB) til 384 int8 (384 bytes)
• 94% storage reduction, ~15% latency improvement
• Preview-feature i Azure AI Search (2026)

Fordeler:

• Dramatisk redusert storage-kostnad (94% saving)
• Raskere query pga. mindre data transfer
• Samme HNSW-algoritme, bare komprimerte vektorer

Ulemper:

• 2-5% recall drop (96% → 92% typical)
• Ikke alle embedding-modeller egner seg (krever testing)
• Preview-status (ikke production-ready før GA)

Break-even analysis:

Index size	Standard cost (S1)	Quantized cost	Savings
100K docs	$9/month	$1/month	$8/month
1M docs	$90/month	$5/month	$85/month
10M docs	$900/month	$54/month	$846/month

Beslutningsveiledning

Velg vektorindeksering basert på scenario

Scenario	Index type	Hybrid	Semantic Ranker	Rationale
HR policies, intern FAQ	HNSW	Ja (alpha=0.5)	Ja	Balansert keyword + semantikk
Juridiske dokumenter, lovverk	HNSW	Ja (alpha=0.3)	Nei	Keyword-dominert, eksakte termer
Kunnskapsbase (åpen Q&A)	HNSW	Ja (alpha=0.8)	Ja	Semantisk-dominert
Produktkataloger (SKU, specs)	HNSW	Ja (alpha=0.2)	Nei	Keyword-kritisk (SKU-søk)
Real-time chat (high QPS)	HNSW, quantized	Nei (vector only)	Nei	Latency-optimalisert

Vanlige feil og misforståelser

Feil	Konsekvens	Rettelse
Bruker exhaustive KNN for store indekser	Latency >500ms	Bytt til HNSW
Setter m=16, efSearch=1000 for alle use cases	Unødvendig høye kostnader	Tune ned til m=4-8
Ignorerer metadata-filtrering	Dårlig precision, feil scope	Legg til facetable fields
Indexer kun embeddings, ikke content	Kan ikke bruke hybrid search	Inkluder content-felt
Bruker cosine similarity for normalized vectors	Korrekt, men overkill	Bruk dotProduct for norm. vectors

Røde flagg

• Latency >200ms for <1M dokumenter: Feil HNSW-parametere eller underprovisjonering
• Recall <85% i eval: For lav efSearch, eller embeddings matcher ikke domene
• Storage cost >$100/month for <500K docs: Vurder scalar quantization eller cleanup
• Ingen metadata-filtrering: RBAC og compliance-risiko

Integrasjon med Microsoft-stakken

Azure AI Foundry (Prompt Flow)

Vector indexing integreres via Vector Index-asset i AI Foundry:

# Prompt Flow med AI Search lookup
inputs:
  question: ${inputs.question}
steps:
  - name: embed_question
    type: embedding
    source: Azure OpenAI text-embedding-3-large
  - name: search_index
    type: vector_db_lookup
    connection: ai_search_connection
    index_name: knowledge-base
    query: ${embed_question.output}
    top_k: 5
  - name: generate_answer
    type: llm
    source: gpt-4o
    prompt: |
      Context: ${search_index.output}
      Question: ${question}
      Answer:

Copilot Studio (Generative Answers)

Copilot Studio bruker Azure AI Search som backend for Generative answers:

• Konfigurasjon: Security & Data → Knowledge sources → Add Azure AI Search
• Automatisk hybrid search med alpha=0.5
• Ingen kontroll over HNSW-parametere (managed service)

Power Automate (AI Builder)

AI Builder støtter Semantic search via Azure AI Search connector:

• Action: "Search documents (semantic)"
• Krever index med contentVector-felt
• Automatisk embedding av query via built-in modell

Offentlig sektor (Norge)

Datasuverenitet og residency

Azure AI Search støtter Norge Øst region (Oslo) for data residency:

• Både innhold og vektorindeks lagres i Norge Øst
• Embedding-modeller (Azure OpenAI) kan konfigureres til Sweden Central (EU)
• For Schrems II: Bruk Customer Managed Keys (CMK) for index encryption

GDPR-compliance

Vector-indeksering introduserer GDPR-utfordringer:

• Right to erasure: Sletting av dokument krever re-indexing (ikke soft delete)
• Right to access: Vektorer er ikke-lesbare — logg original content mapping
• Data minimization: Ikke indexer PII i vector-feltet (kun anonymisert content)

Best practice:

{
  "content": "[REDACTED: person_name, ssn] ... rest of document",
  "contentVector": [0.1, 0.2, ...],
  "metadata_original_id": "doc-12345",
  "metadata_contains_pii": true
}

AI Act og transparency

EU AI Act krever sporbarhet for AI-systemer. For RAG med vektorindeksering:

• Logg query-til-resultat mapping: Hvilke dokumenter ble retrievet?
• Track index versioning: Når ble index sist oppdatert?
• Dokumenter tuning-parametere: alpha, efSearch, semantic ranker config

Kostnad og lisensiering

Prismodell (Azure AI Search)

Tier	Storage	Queries/sek	Replicas	Månedskostnad (NOK)
Basic	2 GB	3	1	~750
S1	25 GB	15	3	~2500
S2	100 GB	60	6	~10 000
S3	200 GB	60	12	~20 000

Kostnadsoptimalisering:

1. Scalar quantization (Preview): Reduser storage cost med 94%
2. Metadata-only indexing: Ikke index store text-felt hvis ikke brukt i BM25
3. Separate development/production indexes: Basic tier for dev (750 NOK vs 2500 NOK)
4. Slett gamle dokumenter: Re-index årlig for å fjerne deprecated content

Lisensiering

Azure AI Search krever ingen spesifikk Microsoft 365-lisens, men:

• Azure OpenAI for embeddings: Krever Azure subscription
• Semantic Ranker: Inkludert i S1+, men med usage cap (50K queries/måned gratis)
• Copilot Studio integration: Krever Copilot Studio-lisens (20K messages/måned)

For arkitekten (Cosmo)

Nøkkelspørsmål til kunden

1. Volum og vekst: Hvor mange dokumenter har dere i dag, og hva er forventet vekst over 2 år?
2. Query latency-krav: Er 50ms akseptabelt, eller trenger dere <10ms real-time?
3. Recall vs. presisjon: Er det viktigere å finne alle relevante dokumenter (recall) eller unngå irrelevante (precision)?
4. Keyword-dominans: Hvor ofte søker brukere etter eksakte termer (produktkoder, paragrafnumre) vs. semantiske konsepter?
5. Multi-tenancy: Trenger dere separate indekser per kunde/avdeling, eller kan alt ligge i én index med RBAC?
6. Budget: Hva er monthly budget for search infra (storage + compute)?
7. Compliance: Kreves data residency i Norge? Må PII håndteres spesielt?
8. Real-time updates: Hvor ofte oppdateres dokumentsamlingen (daglig batch vs. real-time streaming)?

Vanlige fallgruver

• Over-engineering HNSW: Å sette m=16, efConstruction=1600 gir minimal forbedring (98% → 99%) men dobler kostnad.
• Ignorere BM25: Pure vector search mister eksakte matches — hybrid er nesten alltid bedre.
• Manglende eval-framework: Uten recall/precision-metrics er det umulig å vite om index-config er optimal.
• Ingen metadata-strategi: Uten filterable fields blir retrieval-quality dårlig ved skala.
• Single-tenant index for multi-tenant scenario: RBAC på document-level er tregere og mer feilutsatt enn separate indexes.

Anbefalinger per modenhetsnivå

Modenhetsnivå	Index config	Hybrid search	Semantic Ranker	Monitoring
Pilot (PoC)	Basic tier, HNSW default	Ja (alpha=0.5)	Nei (kostnad)	Manuell eval
Production (MVP)	S1, tunet HNSW (m=4, ef=500)	Ja, tunet alpha	Vurder (50K free)	Query logs
Scale (Enterprise)	S2+, quantization	Ja, per-use-case alpha	Ja	Application Insights

Nøkkel: Start enkelt (Basic + default HNSW), test recall/latency i PoC, deretter tuner parametere og oppgrader tier.

Kilder og verifisering

• Azure AI Search - Vector search concepts — Verified (2026-06-19)
• Hybrid search in Azure AI Search — Verified (2026-01)
• Configure vector search algorithms — Verified (2025-12)
• Azure AI Search pricing — Verified (2026-02)
• Semantic ranking in Azure AI Search — Verified (2026-06-19)

Konfidensnivå: Verified (90%) — All info basert på offisiell Microsoft-dokumentasjon og prising per feb 2026.

Vector Indexing i Hybrid Search-kontekst (oppdatert 2026-06-19)

Vector fields og tekstfelt coeksisterer i hybrid search-indekser:

• HNSW (Hierarchical Navigable Small World) — standard ANN-algoritme, efSearch og maxConnections tunable
• eKNN (exhaustive K-Nearest Neighbors) — fullstendig søk, brukes med "exhaustive": true i query
• Multi-vector fields (preview) — Collection(Edm.ComplexType) støtter opp til 100 vektorer per dokument
  • perDocumentVectorLimit: 1 — én vektor per dokument i resultater
  • perDocumentVectorLimit: 0 — ubegrenset (alle matchende vektorer)
  • Nyttig for multimodal data (scene embeddings i video, fragmenter i lange dokumenter)

Tuning ved overbelastning: Reduser efSearch (f.eks. 800 → 128-192) og maxConnections (64 → 32) FØR du skalerer ut med flere replicas. Hybrid queries med aggressive vector-innstillinger + semantic ranker øker CPU/minne-press betydelig.