feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,508 @@
|
|||
# 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)
|
||||
|
||||
```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
|
||||
|
||||
```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", "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:**
|
||||
```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 (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
|
||||
|
||||
```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": "Vegvesenets 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, feb 2026)
|
||||
- [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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue