# Vector Storage and Embedding Cost Optimization

**Last updated:** 2026-06-19
**Status:** GA
**Category:** Cost Optimization & FinOps for AI
**Type:** reference
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs

---

## Innhold

- [Introduksjon](#introduksjon)
- [Kjernekomponenter](#kjernekomponenter)
- [Arkitekturmønstre](#arkitekturmønstre)
- [Beslutningsveiledning](#beslutningsveiledning)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
- [Kilder og verifisering](#kilder-og-verifisering)

## Introduksjon

Vector storage og embeddings utgjør ofte den største kostnadsposten i moderne RAG-løsninger (Retrieval Augmented Generation). En typisk embedding-modell genererer vektorer på 1536 dimensjoner (text-embedding-ada-002) eller opptil 3072 dimensjoner (text-embedding-3-large), der hver dimensjon lagres som et 32-bit flyttall (float32). Dette gir en råstørrelse på 6-12 KB per dokument, før man tar høyde for algoritme-overhead og indekseringsstrukturer.

For organisasjoner som indekserer millioner av dokumenter, kan kostnadene raskt løpe fra seg — både i form av Azure-lagringsregning og minnekrav for søkeytelse. Heldigvis finnes det nå flere Microsoft-støttede teknikker som kan redusere vector index-størrelse med opptil 92,5 % uten vesentlig tap av søkekvalitet.

Denne referansen dekker fem hovedområder for kostnadsoptimalisering: (1) valg av embedding-modell og dimensjonalitet, (2) quantization (scalar og binary), (3) lagringsoptimalisering, (4) Matryoshka Representation Learning (MRL) for dimension-reduksjon, og (5) algoritmevalg og skaleringsstrategier. Sammen utgjør disse en helhetlig tilnærming til å bygge kostnadseffektive, skalerbare vector search-løsninger på Microsoft Azure.

## Kjernekomponenter

### Embedding-modell-valg

| Modell | Dimensjoner | Pris (input, per 1M tokens) | Pris (output) | Bruksområde |
|--------|-------------|------------------------------|---------------|-------------|
| **text-embedding-ada-002** | 1536 | ~$0.10 USD | N/A | Legacy, god baseline-ytelse |
| **text-embedding-3-small** | 1536 (default) | ~$0.02 USD | N/A | Kostnadseffektiv, god ytelse, MRL-støtte |
| **text-embedding-3-large** | 3072 (default) | ~$0.13 USD | N/A | Høyeste kvalitet, MRL-støtte, støtter truncation |

**Konfidensgradering:**
- Ada-002: Verified (Microsoft Learn, januar 2026)
- text-embedding-3-*: Verified (Microsoft Learn, januar 2026)
- Prisene er omtrentlige og kan variere per region og avtaletype

### Quantization-teknikker

| Metode | Kompresjon | Lagringsreduksjon | Kvalitetsimpakt | Rescoring |
|--------|------------|-------------------|-----------------|-----------|
| **Scalar (int8)** | float32 → int8 | 4x reduksjon | Minimal (med rescoring) | Krever original float32 |
| **Binary** | float32 → 1 bit | Opptil 28x reduksjon | Lav (med oversampling) | Kan bruke dot-product |
| **float16** | float32 → float16 | 2x reduksjon | Neglisjerbar | Ikke nødvendig |

**Benchmark (Azure AI Search interntesting):**
- Baseline (float32): 21.36 MB storage, 4.83 MB vector index
- Scalar quantization: 17.76 MB storage, 1.22 MB vector index (75 % reduksjon)
- Binary quantization: 4.92 MB storage, 1.22 MB vector index (77 % total reduksjon)
- **Alle teknikker kombinert**: 4.92 MB storage, 1.22 MB vector index (92,5 % reduksjon)

### Dimension-reduksjon (MRL)

Matryoshka Representation Learning (MRL) er bakt inn i text-embedding-3-modellene. Dette betyr at man kan trunkere dimensjoner fra 3072 → 1024 eller 1536 → 512 med minimal tap av semantisk informasjon.

| Modell | Original dim. | Trunkert dim. | Lagringsreduksjon | MTEB-score (approx) |
|--------|---------------|---------------|-------------------|---------------------|
| text-embedding-3-large | 3072 | 1024 | 3x | ~95 % av original |
| text-embedding-3-small | 1536 | 512 | 3x | ~92 % av original |

MRL fungerer best i kombinasjon med binary quantization. Anbefalt minstegrense: 1024 dimensjoner ved bruk av binary quantization (under 1000 gir merkbar kvalitetsforringelse).

### Lagringsoptimalisering

Azure AI Search lagrer vektorer i to kopier:
1. **Index copy** (i minne, brukes til query execution)
2. **Stored copy** (på disk, brukes til retrieval i query response)

Ved å sette `stored: false` kan man spare opptil 50 % disklagring, men man mister muligheten til å returnere vektorer i query-responser. Dette er akseptabelt i de fleste RAG-scenarier der kun tekst/metadata returneres.

**Advarsel:** Ved `stored: false` må man re-sende fullstendige vektorer ved partial document updates, ellers går data tapt.

### Vector index-algoritmer

| Algoritme | Minnekrav | Query-latens | Bruksområde |
|-----------|-----------|--------------|-------------|
| **HNSW** | Høy (graph i minne) | 20-50 ms (standard tier) | Produksjon, høy throughput |
| **Exhaustive KNN** | Lav (paged loading) | Høyere | Utviklingsmiljø, små datasett |

HNSW (Hierarchical Navigable Small Worlds) er anbefalt for produksjon, men krever at hele grafen ligger i minne. Dette driver opp vector quota-forbruk. Exhaustive KNN laster data on-demand og teller ikke mot vector quota, men er tregere.

## Arkitekturmønstre

### Mønster 1: Maksimal kompresjon (Binary + MRL + no stored)

**Beskrivelse:**
Kombinerer binary quantization, MRL dimension-reduksjon, og `stored: false` for absolutt laveste kostnader.

**Fordeler:**
- Opptil 96 % reduksjon i vector index size
- 50 % disklagringsreduksjon
- Raskere queries (mindre data å scanne)
- Lavere minnekrav

**Ulemper:**
- Krever text-embedding-3 modeller
- Kan ikke returnere vektorer i responses
- Krever omhyggelig testing av search quality (NDCG-metrics)
- Partial document updates må inkludere fullstendige vektorer

**Egnet for:**
- Store datasett (10M+ dokumenter)
- Tight budsjetter
- Embeddings > 1024 dimensjoner
- Scenarier der kun tekst/metadata returneres

**Konfigurasjon (Azure AI Search):**
```json
{
  "vectorSearch": {
    "compressions": [{
      "name": "binary-mrl",
      "kind": "binaryQuantization",
      "rescoringOptions": {
        "enableRescoring": true,
        "defaultOversampling": 10,
        "rescoreStorageMethod": "discardOriginals"
      },
      "truncationDimension": 1024
    }]
  }
}
```

### Mønster 2: Balansert tilnærming (Scalar + float16)

**Beskrivelse:**
Bruker scalar quantization (int8) med float16 som base-type, beholder original vektorer for rescoring.

**Fordeler:**
- God balanse mellom kostnad og kvalitet
- Støtter rescoring med original precision
- Enklere å implementere enn binary
- Kan returnere vektorer i responses

**Ulemper:**
- Krever lagring av både quantized og original vektorer
- Mindre kompresjon enn binary (4x vs 28x)
- Høyere minnekrav enn binary

**Egnet for:**
- Medium datasett (1M-10M dokumenter)
- Scenarier med strenge kvalitetskrav
- Behov for vector-retur i responses
- Organisasjoner som er nye på quantization

**Konfigurasjon (Azure AI Search):**
```json
{
  "fields": [{
    "name": "contentVector",
    "type": "Collection(Edm.Half)",
    "dimensions": 1536,
    "vectorSearchProfile": "scalar-profile"
  }],
  "vectorSearch": {
    "compressions": [{
      "name": "scalar-int8",
      "kind": "scalarQuantization",
      "scalarQuantizationParameters": {"quantizedDataType": "int8"},
      "rescoringOptions": {
        "enableRescoring": true,
        "defaultOversampling": 10,
        "rescoreStorageMethod": "preserveOriginals"
      }
    }]
  }
}
```

### Mønster 3: Hybrid (Full-precision + Quantized fields)

**Beskrivelse:**
Kombinerer ett high-precision vector field (float32, ingen quantization) med ett quantized field (binary) i samme index. Bruker quantized field for rask pre-filtering, deretter rescoring mot full-precision.

**Fordeler:**
- Maksimal search quality
- Rask pre-filtering
- Fleksibilitet i query-strategi

**Ulemper:**
- Høyeste lagringskostnad
- Kompleks index-design
- Dobbel embedding-generering ved indeksering

**Egnet for:**
- High-value search-scenarier (medisinsk, juridisk)
- Hybrid search (vector + keyword) med strenge krav
- Organisasjoner med budsjett til premium quality

**Konfigurasjon (Azure AI Search):**
```json
{
  "fields": [
    {
      "name": "contentVectorFull",
      "type": "Collection(Edm.Single)",
      "dimensions": 3072,
      "vectorSearchProfile": "full-precision-profile"
    },
    {
      "name": "contentVectorCompressed",
      "type": "Collection(Edm.Single)",
      "dimensions": 1024,
      "vectorSearchProfile": "binary-profile"
    }
  ]
}
```

## Beslutningsveiledning

### Beslutningstabell

| Scenario | Anbefalt tilnærming | Forventet besparelse |
|----------|---------------------|---------------------|
| **Stor kunnskapsbase (10M+ docs), tight budsjett** | Binary + MRL (1024 dim) + stored:false | 90-95 % |
| **Medium dataset (1-10M docs), balansert kvalitet/kostnad** | Scalar + float16 + MRL (optional) | 70-80 % |
| **Liten dataset (<1M docs), høy kvalitetskrav** | float16 eller float32, ingen quantization | 0-50 % |
| **Legacy ada-002 embeddings, migrering planlagt** | Scalar quantization, behold originals | 60-70 % |
| **text-embedding-3-large, ny løsning** | Binary + MRL (1024 dim) | 92-96 % |

### Vanlige feil

1. **Bruke binary quantization med <1000 dimensjoner**
   - Fører til merkbar kvalitetsforringelse
   - Løsning: Øk til minimum 1024 dimensjoner eller bruk scalar

2. **Glemme å teste NDCG-metrics før produksjon**
   - Quantization er lossy — alltid valider
   - Løsning: Sammenlign NDCG@10 mellom baseline og quantized index

3. **Sette stored:false uten å forstå konsekvensene**
   - Partial updates vil slette vector data
   - Løsning: Implementer full document replacement i update-logikk

4. **Oversampling satt for lavt**
   - Default er 4, anbefalt er 10-20 for binary quantization
   - Løsning: Tuner oversampling basert på query-tester

5. **Gjenbruke gamle vector profiles etter quantization-endringer**
   - Quantization-config krever ny vector profile
   - Løsning: Opprett ny profile, re-indekser dokumenter

### Røde flagg

- **Vector quota 90 %+ utnyttet:** Vurder umiddelbart quantization eller oppgradering til nyere search service (post-April 2024 har høyere quotas)
- **Storage costs >50 % av total AI Search bill:** Sjekk om `stored: false` kan brukes
- **Query latency >200ms:** For høy dimensjonalitet eller feil SKU (vurder dimension-reduksjon eller S2/S3 tier)
- **Embedding costs >30 % av total AI-kostnad:** Bytt til text-embedding-3-small fra ada-002 eller -large

## Integrasjon med Microsoft-stakken

### Azure AI Search

**Vector quantization (GA siden 2024-07-01):**
```http
POST https://[service].search.windows.net/indexes?api-version=2025-09-01
{
  "name": "cost-optimized-index",
  "fields": [...],
  "vectorSearch": {
    "profiles": [{
      "name": "binary-profile",
      "algorithm": "hnsw-algo",
      "compression": "binary-comp"
    }],
    "algorithms": [{
      "name": "hnsw-algo",
      "kind": "hnsw",
      "hnswParameters": {"m": 4, "efConstruction": 400, "metric": "cosine"}
    }],
    "compressions": [{
      "name": "binary-comp",
      "kind": "binaryQuantization",
      "rescoringOptions": {
        "enableRescoring": true,
        "defaultOversampling": 12,
        "rescoreStorageMethod": "discardOriginals"
      },
      "truncationDimension": 1024
    }]
  }
}
```

**Query med oversampling:**
```http
POST https://[service].search.windows.net/indexes/cost-optimized-index/docs/search?api-version=2025-09-01
{
  "vectorQueries": [{
    "kind": "vector",
    "vector": [0.2, 0.33, ...],
    "fields": "contentVector",
    "k": 5,
    "oversampling": 12.0
  }]
}
```

### Azure OpenAI Embeddings

**text-embedding-3 med dimension-parameter (MRL):**
```python
from openai import AzureOpenAI

client = AzureOpenAI(
    azure_endpoint="https://<resource>.openai.azure.com",
    api_key="<key>",
    api_version="2024-02-01"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="Eksempeltekst for embedding",
    dimensions=1024  # Redusert fra 3072
)
vector = response.data[0].embedding
```

### Cosmos DB for MongoDB vCore

Støtter HNSW og IVF vector indexing med half-precision (float16):
```javascript
db.collection.createIndex(
  { "contentVector": "cosmosSearch" },
  {
    cosmosSearchOptions: {
      kind: "vector-hnsw",
      dimensions: 1536,
      similarity: "COS",
      compression: "half"  // Halverer storage
    }
  }
)
```

### Azure SQL Database

Vector extension (preview) støtter float32 vektorer, men ikke native quantization. Anbefaling: Bruk pre-quantized embeddings fra client-side eller Azure AI Search for store datasett.

### Semantic Kernel

Støtter Azure AI Search connector med full quantization-konfigurasjon:
```csharp
var searchClient = new SearchIndexClient(endpoint, credential);
var vectorStore = new AzureAISearchStore(searchClient);
var collection = vectorStore.GetCollection<DataModel>(
    "cost-optimized-index",
    new VectorStoreRecordDefinition { VectorProperty = "contentVector" }
);
```

## Offentlig sektor (Norge)

### GDPR og datasuverenitet

**Vector storage i Norge/EU:**
- Azure AI Search støtter Norway East og Norway West (full data residency)
- Embedding-generering (Azure OpenAI): Norway East støttes for text-embedding-3 (verifiser regionstatus i Azure Portal)
- Ved quantization: original vektorer kan slettes (`discardOriginals`), reduserer data residency-kompleksitet

**Schrems II-compliance:**
- Vector data klassifiseres som personopplysninger hvis de er koblet til identifiserbare personer
- Anbefaling: Anonymiser metadata, bruk `stored: false` for vektorer
- Vurder customer-managed keys (CMK) i Azure Key Vault for ekstra kontroll

### Budsjettprosesser

**Kostnadsprognoser for offentlige virksomheter:**

Eksempel: 5 millioner dokumenter, gjennomsnittlig 2000 tokens per dokument

| Komponent | Baseline (float32) | Optimalisert (binary + MRL) | Besparelse |
|-----------|--------------------|-----------------------------|------------|
| **Embedding-generering (engangs)** | 10M tokens × $0.13/M = $1,300 | 10M tokens × $0.02/M = $200 (text-emb-3-small) | $1,100 (85 %) |
| **Azure AI Search (S2, storage)** | ~$800/måned | ~$100/måned | $700/måned |
| **Vector quota (S2, 1 partition)** | 200 GB (overskrides) | 15 GB (godt innenfor) | Unngår oppgradering |
| **Totalt første år** | $1,300 + $9,600 = $10,900 | $200 + $1,200 = $1,400 | $9,500 (87 %) |

**Merknad:** Tall er omtrentlige. Bruk Azure Pricing Calculator for nøyaktige estimater basert på region og avtaletype (EA, CSP).

### Skaleringsscenarier

**Scenario 1: Kommunal kunnskapsbase**
- 500K dokumenter (vedtekter, møtereferater, saksbehandling)
- Budsjett: 50K NOK/år
- Anbefaling: text-embedding-3-small + scalar quantization + S1 tier
- Forventet kostnad: ~30K NOK/år

**Scenario 2: Fylkeskommune (helsesektor)**
- 10M dokumenter (pasientjournaler, medisinske retningslinjer)
- Strenge kvalitetskrav (NDCG >0.90)
- Anbefaling: text-embedding-3-large + binary quantization (1536 dim) + S3 tier + rescoring
- Forventet kostnad: ~250K NOK/år

## Kostnad og lisensiering

### Prismodell (Azure AI Search)

**Vector quota (per partition, post-April 2024 services):**

| Tier | Vector quota | Pris/måned (1 partition) | Egnet datasett |
|------|--------------|--------------------------|----------------|
| **Basic** | 5 GB | ~$75 USD | <100K docs |
| **S1** | 35 GB | ~$250 USD | 100K-1M docs |
| **S2** | 150 GB | ~$1,000 USD | 1M-5M docs |
| **S3** | 300 GB | ~$2,000 USD | 5M-20M docs |

**Viktig:** Eldre services (pre-April 2024) har lavere quotas. Sjekk oppgraderingsmulighet: `az search service show --name <service> --resource-group <rg>`.

**Serverless (Preview, MCP 2026-06):** Azure AI Search tilbyr nå også en **Serverless**-prismodell (forbruksbasert: Compute Units/time + per-GB/mnd lagring) ved siden av Dedicated-tierne over. For store, men sporadisk aksesserte vektor-indekser kan Serverless redusere idle-kost. Per juni 2026 er den i preview (West Central US, Switzerland North, Japan East), uten SLA, mangler enkelte features (index aliases, debug sessions, shared private link), og støtter ikke migrering til/fra Dedicated.

### Embedding-kostnader (Azure OpenAI)

| Modell | Input (per 1M tokens) | Use case |
|--------|----------------------|----------|
| text-embedding-ada-002 | $0.10 USD | Legacy |
| text-embedding-3-small | $0.02 USD | Kostnadsoptimalisert |
| text-embedding-3-large | $0.13 USD | Premium quality |

**Estimat:** 1M dokumenter á 500 tokens = 500M tokens input
- Ada-002: $50 USD
- text-embedding-3-small: $10 USD (80 % besparelse)

### TCO-eksempel (3-årsperiode)

**Baseline (ingen optimalisering):**
- 5M dokumenter, text-embedding-ada-002, float32, Azure AI Search S2
- Embedding: $2,500 (engangs)
- Search: $12,000/år × 3 = $36,000
- **Totalt:** $38,500

**Optimalisert (binary + MRL + text-embedding-3-small):**
- Embedding: $500 (engangs)
- Search: $1,500/år × 3 = $4,500 (lavere tier, mindre storage)
- **Totalt:** $5,000

**Besparelse:** $33,500 (87 %) over 3 år.

### Lisensiering (Microsoft 365 Copilot context)

Hvis vector search brukes som grunnlag for Copilot for Microsoft 365:
- Krever Microsoft 365 E3/E5 + Copilot-lisens ($30/bruker/måned)
- Azure AI Search koster ekstra (ikke inkludert i Copilot-lisens)
- Vurder Microsoft Foundry for unified billing (preview, februar 2026)

## For arkitekten (Cosmo)

### Spørsmål å stille klienten

1. **"Hvor mange dokumenter planlegger dere å indeksere (nå og om 2 år)?"**
   - Under 1M: Quantization er nice-to-have
   - 1-10M: Quantization anbefales sterkt
   - Over 10M: Quantization er kritisk

2. **"Hva er budsjettrammen for AI-infrastruktur i året?"**
   - Sammenlign mot TCO-estimat for å vurdere optimalisering

3. **"Trenger dere å returnere vektorer i API-responser?"**
   - Ja → Behold `stored: true`, vurder scalar over binary
   - Nei → Bruk `stored: false` for 50 % diskbesparelse

4. **"Hva er akseptabel search quality-degradering (NDCG-score)?"**
   - >0.95: Bruk scalar eller konservativ binary
   - 0.85-0.95: Binary med rescoring
   - <0.85: Ikke akseptabelt, bruk float16

5. **"Har dere eksisterende embeddings, eller starter dere fra scratch?"**
   - Eksisterende ada-002 → Vurder scalar quantization uten re-embedding
   - Ny løsning → Gå direkte til text-embedding-3-small/large med MRL

6. **"Hvilke compliance-krav gjelder (GDPR, Schrems II, helsepersonelloven)?"**
   - Identifiser behov for Norge-region, CMK, `discardOriginals`

7. **"Hva er forventet query-volum (QPS) og latenskrav?"**
   - Høy QPS (>100): HNSW med quantization
   - Lav QPS (<10): Exhaustive KNN for å spare vector quota

8. **"Planlegger dere partial document updates eller full replacement?"**
   - Partial → Ikke bruk `stored: false` uten mitigering
   - Full replacement → `stored: false` er trygt

### Fallgruver

1. **Over-optimalisering for små datasett**
   - Under 100K dokumenter: Quantization-kompleksitet overgår kostnadsbesparing
   - Anbefaling: Start med float16, optimaliser senere ved vekst

2. **Undervurdere testing-innsats**
   - Quantization krever NDCG-validering, A/B-testing, oversampling-tuning
   - Budsjetter 2-4 uker for POC og kvalitetsvalidering

3. **Ignorere vector quota-grenser**
   - Azure AI Search blokkerer indeksering ved quota-overskridelse
   - Monitorér quota via Azure Portal eller `Get Index Statistics` API

4. **Bruke feil rescoring-metode**
   - `preserveOriginals` (scalar): Krever lagring av float32
   - `discardOriginals` (binary): Kan ikke rescores mot originals, kun dot-product
   - Mismatch fører til indexing-feil

5. **Manglende kapasitetsplanlegging**
   - HNSW overhead: 1-20 % av raw vector size (avhenger av dimensjoner og `m`-parameter)
   - Regn inn overhead i quota-estimat

### Anbefalinger per modenhetsnivå

**Nivå 1 (Starter med RAG):**
- Bruk text-embedding-3-small (dimensioner: 1536)
- Ingen quantization, bare float16
- Azure AI Search Basic eller S1
- **Mål:** Lær grunnleggende før optimalisering

**Nivå 2 (Har produksjonsløsning, ønsker kostnadsreduksjon):**
- Implementer scalar quantization
- Vurder MRL (dimensions: 1024) hvis text-embedding-3
- Test NDCG-impact i staging-miljø
- **Mål:** 60-70 % kostnadsreduksjon med lav risiko

**Nivå 3 (Skalerer til millioner av dokumenter):**
- Binary quantization + MRL (1024 dimensioner)
- `stored: false` hvis ikke behov for vector-retur
- Automatisert NDCG-monitoring i CI/CD
- **Mål:** 90 %+ kostnadsreduksjon, industriell skalering

**Nivå 4 (Optimaliserer på marginer):**
- Custom quantization-logikk (int4, product quantization)
- Hybrid index-design (multiple vector fields)
- Fine-tuned embedding-modeller for domenet
- **Mål:** Maksimal ROI, konkurransefortrinn

*(Verified MCP 2026-04)*

## Kilder og verifisering

### Microsoft Learn (MCP-verifisert, februar 2026)

1. **Azure AI Search — Vector compression overview**
   https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-configure-compression-storage
   Confidence: Verified (fetched via MCP microsoft_docs_fetch)

2. **Scalar and binary quantization**
   https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-quantization
   Confidence: Verified (fetched via MCP microsoft_docs_fetch)

3. **MRL dimension truncation**
   https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-truncate-dimensions
   Confidence: Verified (MCP search results, januar 2026)

4. **Azure AI Search pricing and cost management**
   https://learn.microsoft.com/en-us/azure/search/search-sku-manage-costs
   Confidence: Verified (MCP search results, januar 2026)

5. **Vector index size and limits**
   https://learn.microsoft.com/en-us/azure/search/vector-search-index-size
   Confidence: Verified (MCP search results, januar 2026)

6. **Azure OpenAI embeddings models**
   https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
   Confidence: Verified (MCP search results, januar 2026)

7. **Azure OpenAI cost management**
   https://learn.microsoft.com/en-us/azure/foundry/concepts/manage-costs
   Confidence: Verified (MCP search results, januar 2026)

8. **Storage optimization for vectors**
   https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-storage-options
   Confidence: Verified (MCP search results, januar 2026)

### Tekniske artikler

9. **Azure AI Search: Cut Vector Costs Up To 92.5%**
   https://techcommunity.microsoft.com/blog/azure-ai-services-blog/azure-ai-search-cut-vector-costs-up-to-92-5-with-new-compression-techniques/4404866
   Confidence: Verified (Microsoft Tech Community, referert i MS Learn)

10. **Matryoshka Representation Learning (arXiv)**
    https://arxiv.org/abs/2205.13147
    Confidence: Baseline (akademisk paper, ikke Microsoft-first-party)

### Python code samples

11. **Vector quantization and storage options (Azure samples)**
    https://github.com/Azure/azure-search-vector-samples/blob/main/demo-python/code/vector-quantization-and-storage/README.md
    Confidence: Verified (Microsoft GitHub, februar 2026)

### Konfidensnivå per seksjon

| Seksjon | Konfidensgradering | Kilde |
|---------|-------------------|-------|
| Embedding-modell-valg | Verified | MS Learn 1, 6, 7 |
| Quantization-teknikker | Verified | MS Learn 2, 9 |
| Dimension-reduksjon (MRL) | Verified | MS Learn 3, 10 |
| Lagringsoptimalisering | Verified | MS Learn 8 |
| Arkitekturmønstre | Verified | MS Learn 2, 11 |
| Azure AI Search-integrasjon | Verified | MS Learn 1, 2, 3 |
| Azure OpenAI-integrasjon | Verified | MS Learn 6, 7 |
| Cosmos DB-integrasjon | Baseline | (basert på Cosmos DB docs, ikke MCP-verifisert) |
| Kostnad og lisensiering | Verified | MS Learn 4, 7 |
| Offentlig sektor (Norge) | Baseline | (tilpasset generell GDPR-kunnskap) |

---

**Sist oppdatert av:** Cosmo Skyberg, Microsoft AI Solution Architect
**MCP-research utført:** Februar 2026
**Neste review:** August 2026 (etter Azure AI Search GA-updates)