ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/embedding-models-selection.md

Embedding Models - Selection and Optimization

Last updated: 2026-02
Status: GA (Azure OpenAI, Azure AI Search), Preview (Multilingual E5, Custom embeddings)
Category: RAG Architecture & Semantic Search

---

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)

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="Azure AI 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

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

# 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:

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

// 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", "Azure AI 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:

# 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):

   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:

   # 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 (1 GB storage), Standard S1 fra $250/mnd (25 GB storage)
• 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.

Azure AI Foundry for embedding fine-tuning

Azure AI 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

{"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 (Verified, feb 2026)
• Azure AI Search Vector Search (Verified, feb 2026)
• Integrated Vectorization in Azure AI Search (Verified, feb 2026)
• Matryoshka Embeddings (OpenAI) (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.