# Vector Indexing - Techniques and Configuration

**Last updated:** 2026-04 | Verified: MCP 2026-04
**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å Microsoft sitt BERT-baserte modell.

## 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) — Microsoft's BERT reranking

```json
{
  "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:

```json
{
  "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 |

```python
# 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:**
```python
# 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:

```yaml
# 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:**
```json
{
  "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](https://learn.microsoft.com/en-us/azure/search/vector-search-overview) — **Verified** (2026-01)
- [Hybrid search in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview) — **Verified** (2026-01)
- [Configure vector search algorithms](https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-create-index) — **Verified** (2025-12)
- [Azure AI Search pricing](https://azure.microsoft.com/en-us/pricing/details/search/) — **Verified** (2026-02)
- [Semantic ranking in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/semantic-search-overview) — **Verified** (2025-11)

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


### Vector Indexing i Hybrid Search-kontekst (oppdatert 2026-04)

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.