Lokal bge-m3 ersätter Claude-estimering i scoring-fasen av AI Relevansstrategi-skillen. Inte för att bge-m3 är "smartare", utan för att den löser det problem skillen ställer (vector similarity) i en uppgift där LLM:er är fel verktyg.
AI Relevansstrategi (Vector Strategy) bygger på en enkel premiss: AI-sökmotorer (ChatGPT, Perplexity, Gemini) hämtar content via vector retrieval. När en användare frågar något konverterar systemet frågan till en vektor och hämtar de chunks vars vektorer ligger närmast.
Vår scoring-fas mäter exakt det: hur nära varje textstycke ligger ett målsökord i den semantiska rymden. Resultatet är ett cosine similarity score per chunk.
Tidigare gjorde vi den mätningen med Claude. Men cosine similarity är inte en reasoning-uppgift. Det är en geometrisk operation. LLM:er är inte byggda för det. Embedding-modeller är.
Embedding-modellen omvandlar text till en lång rad siffror, en vektor i hög-dimensionell rymd. Bge-m3 jobbar i 1024 dimensioner. Två texter med liknande betydelse hamnar nära varandra i den rymden. Olika texter hamnar längre ifrån.
Det här är vad RAG-system gör. Det är vad ChatGPT gör när den hämtar fakta från sin context. Det är vad Perplexity gör för citationer. Vi mäter alltså med samma metod som AI-sökmotorerna själva använder, vilket är hela poängen med Vector Strategy som metod.
Bge-m3 är en open source embedding-modell från Beijing Academy of AI. Den är multilingual (100+ språk inkl. svenska), tränad med kontrastiv inlärning, och topprankad på MTEB-benchmarken för flerspråkig retrieval.
| Modell | BAAI/bge-m3 |
| Storlek | 567M parametrar, 1.2 GB på disk, ~600 MB RAM under körning |
| Dimensionalitet | 1024 dimensioner per vektor |
| Kontextfönster | 8192 tokens (≈ 6000 ord) per chunk |
| Språkstöd | 100+ språk, designad multilingual från grunden |
| Licens | MIT (öppen, kommersiell användning OK) |
| Körning | Lokalt via Ollama på M1 Pro, sub-sekund per scoring |
Skillens scoring-fas (score_chunks.py) byggdes om med en engine-abstraktion. Tre läges-fallback i ordning:
# Default: lokal Ollama med bge-m3 python score_chunks.py --target "skinnsoffa" --input extract.md --output scores.json # Auto-fallback om Ollama saknas men OPENAI_API_KEY finns python score_chunks.py --engine openai ... # Sista fallback: Claude-estimering inline (icke-deterministisk)
Tröskelvärdena för svag/medel/stark är engine-specifika eftersom olika embedding-modeller har olika absolutskala. Kalibrerade på 60 chunks över 5 cases:
| ollama:bge-m3 | svag < 0.76, stark ≥ 0.81 (smal distribution, [0.66, 0.84]) |
| openai:text-embedding-3-small | svag < 0.65, stark ≥ 0.75 (legacy, ada-002-kalibrerat) |
| ai-estimerad | svag < 0.65, stark ≥ 0.75 (Claude använder hela 0 till 1-skalan) |
Det här är inte en ersättning av Claude. Det är att flytta Claude till rätt nivå i pipeline. Claude är fortfarande oumbärlig för Fas 5 till 9 (gap-analys mot konkurrenter, drivande faktorer, rekommendationer per chunk, mönsteranalys, fan-out). Den jobbar bara inte längre med grov-mätningen.
Vector mätinstrument. Producerar siffror. Bit-identisk varje körning. Inga tokens. 1024-dim cosine similarity per chunk mot target.
Tolkning. Tar siffrorna och chunk-texten som input. Avgör vad som är false positives, gör konkurrentbenchmark, skriver rekommendationer, identifierar sitewide-mönster.
Det här är den underskattade vinsten. När scoring är deterministisk kan vi för första gången köra samma textsnutt mot samma target om och om igen och faktiskt mäta om en omskrivning blev bättre eller sämre. Tidigare gick det inte. Variationen mellan körningar var större än effekten av textförändringen.
Tre versioner mot samma target ("skinnsoffa"). Tre olika scores. Ingen tvekan om att v3 mäter bättre. Vi kan stå för siffrorna inför kund. Tidigare hade vi behövt köra varje version 5 gånger och räkna medelvärde för att vara säkra.
Skillen kör nu lokalt på min M1. Det är beviset att lokal embedding-modell fungerar i produktion. Frågan är hur vi paketerar och skalar det.
Kan vi köra bge-m3 (eller motsvarande) på server-nivå så hela byrån har tillgång? Cloudflare Workers AI har bge-m3 som beta. En central Ollama-instans på vår infrastruktur är ett annat alternativ. Containerized via Docker?
Hur passar det här in i Viviane? Om Viviane redan har en LLM-backend kan en embedding-endpoint vara en naturlig komplettering. Då blir scoring tillgängligt som en intern API för andra workflows, inte bara AI Relevansstrategi.
Vilka andra användningsfall har vi för embedding-modeller? Klustring av kund-content, semantisk sök i content-bibliotek, dedupe-detection i FAQ-batchar, fan-out av sub-intentioner i Vector Strategy Fas 9. Det här är ett mätinstrument vi inte hade tidigare.
När är embedding-modell rätt verktyg och när är LLM rätt? Heuristik: om uppgiften är geometrisk likhet, klustring, ranking eller retrieval, är det embedding. Om uppgiften är reasoning, omformulering, analys eller generering, är det LLM. Båda har sin plats. Använd inte LLM som embedding-modell.
Hur paketerar vi det här som intern tjänst? Ett wrapper-API över Ollama? En pre-byggd Docker-image som varje teammedlem kan köra lokalt? En nodpool på server-sidan med queue? Det är inte tekniskt svårt, det är en distributionsfråga.
Bytet är inte gjort på känsla. Vi körde en benchmark på riktig kunddata för att jämföra metoderna mot varandra på det som spelar roll i en SEO-leverans: rankar de chunkarna likadant, ger de samma score varje körning, hur dyr är varje metod.
| 5 test-case | CDON Apple AirPods, ILVA soffor, Ekeby skinnsoffa, Takteam antialgbehandling, Mitsubishi Hero. Olika branscher, olika sökord-typ. |
| 60 chunks | Alla extrakt-text-stycken över 25 ord från sidorna i de 5 casen. |
| 5 metoder | bge-m3 (lokal), embeddinggemma (lokal mindre), Claude Opus, Claude Sonnet, Claude Haiku. |
| 2 körningar per metod | För att mäta variation. Totalt 50 mätserier. |
Vi körde varje metod två gånger med exakt samma input. Mätte hur mycket scorearna skilde sig mellan körning 1 och 2. För en kund som vill jämföra rapporter över tid är det här hela skillnaden mellan "vi mäter samma sak" och "siffrorna driver".
Stapelns längd = hur mycket samma chunk kan ändra score mellan körning 1 och 2. Lime stapel = ingen drift. Orange = drift.
Vector Strategy-rapporten lyfter fram chunks som är för svaga och behöver skrivas om. Frågan: hittar bge-m3 samma svaga chunks som Claude Opus skulle ha pekat ut? Svar: ja, ungefär 7 av 10.
bge-m3 ligger i nivå med Haiku på att hitta de chunks som behöver fixas. Det är den primära jobbet i Vector Strategy.
Token-budget per analys, summerat över alla 5 cases och 2 körningar (totalt 10 mätningar per metod). Detta är vad en analys faktiskt kostar i Claude-tokens när scoring-fasen är inräknad.
Haiku är inte billigare i praktiken eftersom den lägger till resonemang som Opus skippar. Bge-m3 kör helt utanför token-ekonomin.