ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/embedding-models-selection.md

# Embedding Models - Selection and Optimization

**Last updated:** 2026-06-19  
**Status:** GA (Azure OpenAI, Azure AI Search), Preview (Multilingual E5, Custom embeddings)  
**Category:** RAG Architecture & Semantic Search
**Type:** reference
**Source:** https://learn.microsoft.com/azure/search/vector-search-overview

---

## Innhold

- [Introduksjon](#introduksjon)
- [Kjernekomponenter og nøkkelegenskaper](#kjernekomponenter-og-nøkkelegenskaper)
- [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)
- [Fine-tuning av embedding-modeller](#fine-tuning-av-embedding-modeller)
- [Kilder og verifisering](#kilder-og-verifisering)

## Introduksjon

Embedding-modeller er selve grunnmuren i moderne RAG-systemer og semantisk søk. De oversetter tekst — enten spørsmål, dokumenter eller metadata — til numeriske vektorer som gjør det mulig å finne semantisk liknende innhold basert på mening, ikke bare nøkkelord. Valget av embedding-modell påvirker direkte retrieval-kvalitet, latency, kostnad og hvor godt systemet håndterer domene-spesifikk terminologi eller flerspråklige dokumenter.

I Microsoft-økosystemet tilbys embeddings primært gjennom **Azure OpenAI Service** (text-embedding-ada-002, text-embedding-3-small, text-embedding-3-large) og **Azure AI Search** (som integrerer både OpenAI-modeller og åpen kildekode-embeddings som E5 via Azure AI). Riktig valg krever forståelse av dimensjonalitet, kostnad, domenetilpasning, flerspråklighet og håndtering av store dokumentvolumer.

Mange organisasjoner starter med standard OpenAI-modeller uten å vurdere om domene-spesifikke embeddings (f.eks. rettet mot juridisk, medisinsk eller teknisk språk) eller multilingual-støtte kan gi markant bedre kvalitet — eller om høyere dimensjonalitet faktisk er nødvendig for deres use case.

---

## Kjernekomponenter og nøkkelegenskaper

### Tilgjengelige embedding-modeller i Azure

| Modell | Dimensjoner | Maks tokens | Bruksområde | Status | Pris (per 1M tokens, ca.) |
|--------|-------------|-------------|-------------|--------|---------------------------|
| **text-embedding-ada-002** | 1536 | 8191 | Generell RAG, legacy baseline | GA | $0.10 |
| **text-embedding-3-small** | 1536 (eller 512) | 8191 | Kostnadseffektiv, generell bruk | GA | $0.02 |
| **text-embedding-3-large** | 3072 (eller 256-1024) | 8191 | Høy presisjon, komplekse domener | GA | $0.13 |
| **multilingual-e5-small** | 384 | 512 | Flerspråklig, kompakt | Preview | Via Azure AI (gratis i preview) |
| **multilingual-e5-large** | 1024 | 512 | Flerspråklig, høy kvalitet | Preview | Via Azure AI |
| **Custom embeddings** | Variabel | Variabel | Domene-spesifikk fine-tuning | Announced | Custom pricing |

**Nøkkelegenskaper per modell:**
- **Dimensjonalitet:** Høyere dimensjoner = bedre representasjon av nyansert semantikk, men større indekser og høyere kostnad
- **Token-kapasitet:** 8191 tokens tilsvarer ca. 6000 ord (norsk/engelsk), tilstrekkelig for de fleste chunks
- **Språkstøtte:** OpenAI-modeller håndterer 100+ språk, men med fallende kvalitet utenfor engelsk; E5-modeller er optimalisert for multilingual quality
- **Matryoshka-dimensjonalitet:** text-embedding-3-modellene støtter dynamisk reduksjon (f.eks. 3072 → 512) uten retraining, nyttig for kostnadsoptimalisering

### Eksempel: Generering av embeddings (Azure OpenAI, Python)

```python
from openai import AzureOpenAI

client = AzureOpenAI(
    api_key="YOUR_AZURE_OPENAI_KEY",
    api_version="2024-02-01",
    azure_endpoint="https://YOUR_RESOURCE.openai.azure.com"
)

response = client.embeddings.create(
    model="text-embedding-3-small",  # eller "text-embedding-3-large"
    input="Microsoft Foundry gir en unified plattform for LLM-utvikling.",
    dimensions=512  # valgfritt: reduser fra 1536 til 512 for mindre indeks
)

embedding_vector = response.data[0].embedding
print(f"Dimensjoner: {len(embedding_vector)}")  # 512
```

### Eksempel: Azure AI Search med embeddings

```json
{
  "name": "products-index",
  "fields": [
    {"name": "id", "type": "Edm.String", "key": true},
    {"name": "content", "type": "Edm.String", "searchable": true},
    {"name": "contentVector", "type": "Collection(Edm.Single)", "dimensions": 1536, "vectorSearchProfile": "vector-profile"}
  ],
  "vectorSearch": {
    "profiles": [
      {
        "name": "vector-profile",
        "algorithm": "hnsw-config"
      }
    ],
    "algorithms": [
      {
        "name": "hnsw-config",
        "kind": "hnsw",
        "hnswParameters": {"metric": "cosine", "m": 4, "efConstruction": 400}
      }
    ]
  }
}
```

---

## Arkitekturmønstre

### 1. Single Embedding Model (Standard)

**Beskrivelse:** Én embedding-modell for både indeksering av dokumenter og query embedding.

**Når bruke:**
- Generelle RAG-scenarioer (kunnskapsbase, FAQ, support)
- Engelsk eller primært engelsk innhold
- Modenhetsnivå: Grunnleggende til mellomliggende

**Fordeler:**
- Enkel å implementere og vedlikeholde
- Forutsigbar kostnad
- Garantert konsistens mellom query og dokumenter

**Ulemper:**
- Ikke optimalisert for spesifikke domener
- Suboptimal for multidomenescenarier (f.eks. juridisk + teknisk)

### 2. Domain-Specific Embeddings

**Beskrivelse:** Bruk av fine-tuned eller domene-spesifikke embeddings (f.eks. BioBERT for medisin, Legal-BERT for jus).

**Når bruke:**
- Høy tetthet av domene-spesifikk terminologi (jus, medisin, ingeniørfag)
- Kritisk at semantisk likhet fanger domeneforståelse (f.eks. "force majeure" vs "act of God")
- Modenhetsnivå: Avansert

**Fordeler:**
- Markant bedre retrieval-kvalitet i spesialiserte domener
- Reduserer behov for post-reranking

**Ulemper:**
- Høyere initielle kostnader (fine-tuning, custom hosting)
- Krever ekspertise for trening/validering

### 3. Multilingual Embeddings med Språkfiltrering

**Beskrivelse:** Bruk av multilingual embeddings (E5, mBERT) kombinert med metadata-filtrering på språk.

**Når bruke:**
- Dokumenter på flere språk (norsk, svensk, engelsk)
- Brukere forventer å søke på eget språk og få relevante treff på andre språk
- Modenhetsnivå: Mellomliggende til avansert

**Fordeler:**
- Én indeks for alle språk
- Cross-language retrieval mulig
- Lavere vedlikeholdskostnad enn separate indekser

**Ulemper:**
- Noe lavere kvalitet enn språk-spesifikke modeller
- Krever testing av språkparitet (engelsk får ofte bedre kvalitet)

---

## Beslutningsveiledning

### Velg embedding-modell basert på use case

| Scenario | Anbefalt modell | Begrunnelse |
|----------|-----------------|-------------|
| Generell RAG (engelsk) | **text-embedding-3-small** | Kostnadseffektiv, god kvalitet, rask |
| Kompleks domene (juridisk, teknisk) | **text-embedding-3-large** | Høyere dimensjonalitet fanger nyansert semantikk |
| Flerspråklig (norsk + engelsk + svensk) | **multilingual-e5-large** | Optimalisert for multilingual quality, lavere kostnad |
| Kostnadsoptimalisering (store volumer) | **text-embedding-3-small (512 dims)** | Redusert dimensjonalitet = mindre indeksstørrelse |
| Høy presisjon, kritisk applikasjon | **text-embedding-3-large (3072 dims)** + reranking | Maksimal semantisk dekning + post-processing |
| Domene-spesifikk terminologi | **Custom fine-tuned embeddings** | Treningsdata fra eget domene |

### Dimensjonalitet: Trade-offs

| Dimensjoner | Fordeler | Ulemper | Egnet for |
|-------------|----------|---------|-----------|
| **256-512** | Lavere kostnad, raskere søk, mindre storage | Lavere presisjon, vanskeligere å fange nyansert semantikk | FAQ, enkel klassifisering, kostnadsoptimalisering |
| **1024-1536** | God balanse mellom kvalitet og kostnad | Middels storage | Generell RAG, dokumentsøk |
| **3072** | Høyeste presisjon, fanger subtile semantiske forskjeller | Høyere kostnad, større indeks, tregere søk | Komplekse domener, kritiske applikasjoner |

**Tommelfingerregel:** Start med 1536 dimensjoner (text-embedding-3-small). Reduser til 512 hvis storage/kostnad er kritisk. Øk til 3072 hvis retrieval-kvalitet er utilstrekkelig.

### Vanlige feil og misforståelser

| Feil | Hvorfor det er problematisk | Riktig tilnærming |
|------|----------------------------|-------------------|
| **Bruke ada-002 i 2025-2026** | Dyrere og eldre enn text-embedding-3-small | Migrer til text-embedding-3-small |
| **Anta at høyere dimensjonalitet alltid er bedre** | Overhead i kostnad/storage uten målbar kvalitetsforbedring | Mål retrieval-kvalitet før du øker dimensjoner |
| **Gjenbruke generelle embeddings for juridisk innhold** | "Rettskraftig dom" og "endelig avgjørelse" feiltolkes | Vurder domene-spesifikk fine-tuning |
| **Blande embeddings fra ulike modeller i samme indeks** | Vektorer ikke sammenliknbare, retrieval feiler | Reindekser alle dokumenter ved modellendring |
| **Ikke teste multilingual paritet** | Engelsk får høy kvalitet, norsk får dårlig retrieval | Mål retrieval-kvalitet per språk, juster reranking |

### Røde flagg arkitekten bør se etter

- **"Vi indekserer 500 000 dokumenter med text-embedding-3-large (3072 dims)"** → Storage og kostnad blir enormt; vurder dimensjonsreduksjon
- **"Vi har norske juridiske dokumenter, bruker OpenAI embeddings uten reranking"** → Domene-spesifikk terminologi fanges dårlig; vurder custom embeddings eller Legal-BERT
- **"Vi har 10 språk i samme indeks, men søk på norsk gir dårlige resultater"** → Multilingual embeddings kan favorisere engelsk; test språkparitet
- **"Vi bytter fra ada-002 til text-embedding-3-small uten reindeksering"** → Gamle og nye vektorer ikke kompatible, retrieval feiler

---

## Integrasjon med Microsoft-stakken

### Azure OpenAI Service

```python
# Eksempel: Bruk av embeddings i Azure OpenAI
client = AzureOpenAI(azure_endpoint="https://YOUR_RESOURCE.openai.azure.com", api_version="2024-02-01")

embedding = client.embeddings.create(
    model="text-embedding-3-small",
    input="Hvordan integrere Azure AI Search med Copilot Studio?",
    dimensions=1536
)
```

### Azure AI Search (Integrated Vectorization)

Azure AI Search kan automatisk generere embeddings under indeksering via **skillsets**:

```json
{
  "skills": [
    {
      "@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill",
      "name": "embedding-skill",
      "context": "/document/content",
      "resourceUri": "https://YOUR_RESOURCE.openai.azure.com",
      "deploymentId": "text-embedding-3-small",
      "modelName": "text-embedding-3-small",
      "dimensions": 1536,
      "inputs": [{"name": "text", "source": "/document/content"}],
      "outputs": [{"name": "embedding", "targetName": "contentVector"}]
    }
  ]
}
```

**Fordeler med integrated vectorization:**
- Automatisk embedding-generering under indeksering
- Ingen separat kode for embedding-pipeline
- Enklere reindeksering ved modellendring

### Copilot Studio og Power Platform

Copilot Studio kan kobles til Azure AI Search som **knowledge source**. Embeddings genereres automatisk når dokumenter lastes opp, men standardmodellen (typisk ada-002 eller text-embedding-3-small) kan ikke endres direkte i UI.

**Workaround for custom embeddings:**
1. Pre-generere embeddings eksternt
2. Lagre i Azure AI Search
3. Konfigurer Copilot Studio til å bruke eksisterende indeks

### Microsoft Agent Framework og Semantic Kernel

```csharp
// Semantic Kernel: Bruk av embeddings for memory
var embeddingGenerator = new AzureOpenAITextEmbeddingGenerationService(
    deploymentName: "text-embedding-3-small",
    endpoint: "https://YOUR_RESOURCE.openai.azure.com",
    apiKey: "YOUR_KEY"
);

var memoryBuilder = new MemoryBuilder();
memoryBuilder.WithAzureOpenAITextEmbeddingGeneration(embeddingGenerator);
var memory = memoryBuilder.Build();

await memory.SaveInformationAsync("facts", "Microsoft Foundry støtter prompt flow.", "fact-1");
var results = await memory.SearchAsync("facts", "Hva er Foundry?", limit: 3);
```

---

## Offentlig sektor (Norge)

### Datasuverenitet og residency

- **Azure OpenAI embeddings:** Data prosesseres i Azure-regionen du har deployed modellen (typisk West Europe, North Europe). No-logging policy for OpenAI API, men **ikke garantert for EU Data Boundary** (data kan krysse EU-grenser under inferens).
- **Multilingual E5 (Azure AI):** Hostet i Azure, kan konfigureres for EU-residency.
- **Custom embeddings (self-hosted):** Full kontroll, kan hostes i Azure Norway regions (anbefales for Høy/Kritisk data).

**Anbefaling for offentlig sektor:**
- **Lav/Middels risiko:** Azure OpenAI embeddings i West Europe OK (dokumenter offentlig informasjon)
- **Høy risiko:** Custom embeddings hostet i Azure Norway eller multilingual E5 med EU-residency

### GDPR og AI Act

- **Persondata i embeddings:** Hvis dokumenter inneholder persondata, **må embeddings behandles som persondata** (vektorer kan teoretisk brukes til re-identifikasjon via inversion attacks, selv om praktisk svært vanskelig).
- **Rettighet til sletting:** Embedding-vektorer må slettes ved brukerforespørsel (GDPR Art. 17). Azure AI Search støtter dokument-sletting, men ikke selektiv sletting av embeddings uten reindeksering.
- **AI Act (høyrisiko-systemer):** Hvis RAG brukes til automatiserte beslutninger (f.eks. tilskudd, klagesaksbehandling), må embedding-modellen dokumenteres (hvilken modell, treningsdata, bias-testing).

**Anbefaling:**
- Lagre metadata som kobler embedding-ID til dokument-ID for GDPR-sletting
- Dokumenter embedding-modell og versjon i systemdokumentasjon
- Test for bias i multilingual embeddings (engelsk vs norsk kvalitet)

### Forvaltningsloven og etterprøvbarhet

Offentlige vedtak må kunne etterprøves. Hvis RAG brukes til å hente grunnlagsdokumenter, må systemet logge:
- Hvilke dokumenter ble hentet (citation tracking)
- Hvilken embedding-modell genererte query-vektoren
- Score/relevans per dokument

**Implementering:**
```python
# Logging for etterprøvbarhet
search_result = search_client.search(
    search_text=None,
    vector_queries=[VectorizedQuery(vector=query_embedding, k_nearest_neighbors=5, fields="contentVector")],
    select=["id", "title", "content"]
)

for doc in search_result:
    log_entry = {
        "query": user_query,
        "embedding_model": "text-embedding-3-small",
        "document_id": doc["id"],
        "score": doc["@search.score"],
        "timestamp": datetime.utcnow()
    }
    logger.info(log_entry)
```

---

## Kostnad og lisensiering

### Prismodell (Azure OpenAI, per februar 2026)

| Modell | Pris per 1M tokens |
|--------|---------------------|
| text-embedding-ada-002 | $0.10 |
| text-embedding-3-small | $0.02 |
| text-embedding-3-large | $0.13 |

**Eksempel: Indeksering av 100 000 dokumenter (gjennomsnitt 1000 tokens per dokument)**
- **text-embedding-3-small:** 100M tokens × $0.02 / 1M = **$2**
- **text-embedding-3-large:** 100M tokens × $0.13 / 1M = **$13**

**Storage-kostnad (Azure AI Search):**
- **1536 dimensjoner:** Ca. 6 KB per vektor (inkl. overhead)
- **3072 dimensjoner:** Ca. 12 KB per vektor
- **100 000 dokumenter (1536 dims):** 600 MB → Basic tier OK
- **100 000 dokumenter (3072 dims):** 1.2 GB → Krever Standard tier

### Kostnadsoptimaliseringstips

1. **Bruk dimensjonsreduksjon (Matryoshka):**
   ```python
   response = client.embeddings.create(
       model="text-embedding-3-large",
       input="...",
       dimensions=1024  # Reduser fra 3072 til 1024
   )
   ```
   **Effekt:** 3x mindre storage, 2-3x raskere søk, marginalt tap av kvalitet (test først).

2. **Batch embedding-generering:**
   ```python
   # Send 100 dokumenter per API-kall (maks 8191 tokens totalt)
   response = client.embeddings.create(
       model="text-embedding-3-small",
       input=[doc1, doc2, ..., doc100]
   )
   ```
   **Effekt:** Lavere latency, samme kostnad per token.

3. **Cache query embeddings:**
   - Lagre embeddings for vanlige spørsmål (FAQ) i Redis/Azure Cache
   - Spare embedding-kostnad for repeterte queries

4. **Vurder multilingual E5 for flerspråklige scenarioer:**
   - Gratis i preview (per feb 2026)
   - Lavere kostnad når GA (forventet $0.01-0.03 per 1M tokens)

### Lisensiering

- **Azure OpenAI Service:** Krever Azure-abonnement, ingen separate lisenser for embedding-modeller
- **Azure AI Search:** Basic tier fra $75/mnd (15 GB storage per partisjon for nye services; eldre: 2 GB), Standard S1 fra $250/mnd (160 GB; eldre: 25 GB)
- **Custom embeddings (self-hosted):** Ingen lisenskostnad utover compute (Azure ML, Kubernetes)

---

## For arkitekten (Cosmo)

### Nøkkelspørsmål til kunden

1. **Språk og geografi:**
   - "Hvilke språk skal systemet håndtere? Er norsk primærspråk eller sekundært?"
   - "Forventer brukere å søke på ett språk og få treff på andre språk?"

2. **Domene og terminologi:**
   - "Inneholder dokumentene domene-spesifikk terminologi (juridisk, medisinsk, teknisk)?"
   - "Har dere eksempler på spørsmål som ofte feiler i dagens søk?"

3. **Volum og kostnad:**
   - "Hvor mange dokumenter skal indekseres initialt? Hva er forventet vekst per år?"
   - "Hva er budsjett for embedding-generering og storage?"

4. **Kvalitet vs. kostnad:**
   - "Hva er viktigst: høyest mulig retrieval-kvalitet eller lavest mulig kostnad?"
   - "Er det OK med 10% lavere presisjon hvis vi halverer kostnadene?"

5. **Compliance og residency:**
   - "Inneholder dokumentene persondata eller sensitiv informasjon (GDPR)?"
   - "Er det krav om at data ikke forlater Norge/EU?"

6. **Eksisterende infrastruktur:**
   - "Bruker dere allerede Azure OpenAI? Hvilken modell?"
   - "Har dere kompetanse til å drifte custom embeddings (Azure ML, Kubernetes)?"

7. **Testing og validering:**
   - "Hvordan måler dere retrieval-kvalitet i dag? Har dere golden dataset?"
   - "Hva er akseptabel recall@5 / precision@5 for deres use case?"

8. **Multimodalitet:**
   - "Skal systemet håndtere bilder, tabeller eller kun tekst?"
   - "Trenger dere embeddings for metadata (tags, kategorier) i tillegg til innhold?"

### Vanlige fallgruver

| Fallgruve | Konsekvens | Hvordan unngå |
|-----------|------------|---------------|
| **Ikke teste retrieval-kvalitet før produksjon** | Dårlig brukeropplevelse, høy support-last | Opprett golden dataset (50-100 query-dokument-par), mål recall@5/precision@5 |
| **Blande embeddings fra ulike modeller** | Retrieval feiler fullstendig | Reindekser ALLE dokumenter ved modellendring |
| **Ignorere språkparitet i multilingual embeddings** | Norske queries gir dårlige resultater | Test retrieval-kvalitet per språk, juster reranking-vekter |
| **Overforenkle dimensjonalitetsvalg ("høyere er alltid bedre")** | Unødvendig høy kostnad og latency | Benchmark 512, 1536 og 3072 dimensjoner mot golden dataset |
| **Ikke dokumentere embedding-modell i systemdokumentasjon** | GDPR/AI Act compliance-problem | Logg modellnavn, versjon, treningsdata (hvis tilgjengelig) |

### Anbefalinger per modenhetsnivå

| Modenhetsnivå | Anbefaling | Begrunnelse |
|---------------|-----------|-------------|
| **Grunnleggende** (første RAG-prosjekt) | text-embedding-3-small (1536 dims), Azure AI Search integrated vectorization | Enklest å sette opp, lavest risiko, god kvalitet |
| **Mellomliggende** (har RAG i prod, vil optimalisere) | text-embedding-3-small (512 dims) + reranking | Kostnadsoptimalisering, bedre kvalitet via post-processing |
| **Avansert** (komplekse domener, multilingual) | text-embedding-3-large (1024-3072 dims) eller custom embeddings | Høyere presisjon, domene-spesifikk tuning |
| **Offentlig sektor (compliance-kritisk)** | Custom embeddings hostet i Azure Norway | Full kontroll over data residency og modell-dokumentasjon |

---

## Fine-tuning av embedding-modeller

### Hvorfor fine-tune?

General-purpose embedding-modeller (text-embedding-3) presterer godt på standardoppgaver, men kan underlevere på domenespesifikke termer, norsk fagspråk, eller spesialisert terminologi. Fine-tuning tilpasser embedding-modellen til kundens datadomene.

### Microsoft Foundry for embedding fine-tuning

Microsoft Foundry støtter fine-tuning av embedding-modeller via **Custom Models** (preview):

| Aspekt | Detaljer |
|--------|----------|
| **Støttede modeller** | text-embedding-3-small, text-embedding-3-large |
| **Treningsdata** | JSON Lines med query-document pairs |
| **Minimum samples** | 100 positive pairs (anbefalt 1000+) |
| **Output** | Fine-tuned deployment med egne dimensjoner |
| **Evaluering** | Recall@k, NDCG, MRR mot valideringssett |

### Treningsdata-format

```jsonl
{"query": "hva er regelverket for kunstig intelligens i norge", "document": "AI-forordningen (EU AI Act) trådte i kraft...", "label": 1}
{"query": "azure openai prising", "document": "Direktoratetets budsjett for 2025...", "label": 0}
```

**Tips for norsk/skandinavisk:**
- Inkluder norske fagtermer og forkortelser som positive pairs
- Bruk synonympar (f.eks. «KI» ↔ «kunstig intelligens», «AI» ↔ «maskinlæring»)
- Balancer bokmål og nynorsk om relevant

### Evaluering: Fine-tuned vs. General-purpose

| Metrikk | General-purpose | Fine-tuned | Typisk forbedring |
|---------|----------------|------------|-------------------|
| Recall@5 (domene) | 70-80% | 85-95% | +10-15 pp |
| Recall@5 (generell) | 85-90% | 80-88% | -2-5 pp (trade-off) |
| Norsk fagspråk precision | 60-75% | 80-92% | +15-20 pp |

**Viktig trade-off:** Fine-tuning forbedrer domene-retrieval men kan redusere generell kvalitet. Test alltid med et bredt evalueringssett.

### Beslutningsveiledning for fine-tuning

| Scenario | Fine-tune? | Begrunnelse |
|----------|-----------|-------------|
| Generell RAG, standard norsk | Nei | text-embedding-3-small er god nok |
| Domene-spesifikt fagspråk | Ja | Fagtermer mangler i general-purpose |
| Norsk offentlig sektor (forvaltning) | Vurder | Lovtekst og forvaltningstermer er spesifikke |
| Multilingual (norsk + engelsk) | Nei | text-embedding-3 håndterer multilingual godt |
| <500 treningsdokumenter | Nei | For lite data, bruk synonym maps i stedet |

### Alternativ: Domenespesifikk reranking

For teams som ikke har nok treningsdata for fine-tuning, er en domene-tilpasset **reranker** et enklere alternativ:
- Bruk general-purpose embeddings for retrieval (text-embedding-3)
- Tren en cross-encoder reranker på domenespesifikke query-document pairs
- Krever færre treningseksempler (50-100 pairs)

---

## Kilder og verifisering

### Primærkilder (Microsoft Learn)

- [Azure OpenAI Embeddings](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/embeddings) (Verified, feb 2026)
- [Azure AI Search Vector Search](https://learn.microsoft.com/en-us/azure/search/vector-search-overview) (Verified, 2026-06-19)
- [Integrated Vectorization in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/vector-search-integrated-vectorization) (Verified, feb 2026)
- [Matryoshka Embeddings (OpenAI)](https://platform.openai.com/docs/guides/embeddings/embedding-models) (Baseline, referert i Azure docs)

### Sekundærkilder

- OpenAI Embeddings Pricing (Verified, https://azure.microsoft.com/en-us/pricing/details/cognitive-services/openai-service/)
- Multilingual E5 (Baseline, Microsoft Research paper, preview-status bekreftet via Azure AI docs)

### Konfidensnivå

- **Modellnavn, dimensjoner, pricing:** Verified (Azure offisiell dokumentasjon)
- **Multilingual E5 status:** Baseline (preview bekreftet, GA-priser antatt)
- **Custom embeddings:** Assumed (announced feature, detaljer fra early access docs)
- **GDPR/AI Act anbefalinger:** Verified (basert på EU-regelverk og Microsoft compliance-dokumentasjon)

---

**For Cosmo:** Bruk denne referansen når kunden nevner "embedding-problemer", "dårlig retrieval-kvalitet på norsk", "for høye Azure AI Search-kostnader" eller "vi vurderer å bytte embedding-modell". Start alltid med å kartlegge språk, domene og volum før du anbefaler modell. Test ALLTID retrieval-kvalitet med kundens egne data før produksjonsutrulling.