Så bygger jag 12 specialiserade AI-översättare
När jag började arbeta med översättningar för Medborgarskapskollen såg problemet först enkelt ut: original på svenska, ett antal målspråk och en språkmodell som redan kan översätta.
När jag började arbeta med översättningar för Medborgarskapskollen såg problemet först enkelt ut: original på svenska, ett antal målspråk och en språkmodell som redan kan översätta. Men ju mer materialet närmade sig myndighetsnära information, provfrågor och pedagogiska förklaringar, desto tydligare blev det att "översätt korrekt" är alldeles för grovt som produktkrav.
Jag ville inte ha tolv olika personligheter som improviserade. Jag ville ha en gemensam sannings- och kvalitetsmodell, plus tolv språkprofiler som hanterar verkliga språkspecifika problem. Därför byggde jag översättningssystemet i två lager: global policy och specialiserad språkfil.
En generell prompt missar fel som bara finns i ett språk
En generell instruktion kan säga:
Bevara betydelsen. Skriv naturligt. Använd enkel svenska som utgångspunkt.
Det låter rimligt men säger nästan ingenting om vad som händer när ett svenskt samhällsbegrepp saknar en etablerad motsvarighet, när ett målspråk har flera standardvarianter eller när en direktöversättning råkar få en politisk eller juridisk laddning som originalet inte har.
För frågebanken är dessutom semantisk precision inte den enda dimensionen. Översättningen får inte göra frågan lättare genom att lägga till en förklaring i svarsalternativet. Den får inte göra ett distraktoralternativ orimligt. Den får inte byta neutral myndighetsterminologi mot ett ord som signalerar värdering.
Det gjorde att jag behövde definiera översättning som ett kontrakt, inte en stiluppgift.
Lager 1: en global translation policy
Den globala policyn gäller för alla språk och fungerar som innehållslås. Den innehåller bland annat:
Det sista är viktigt. Om originalfrågan är tvetydig ska översättaren inte "rädda" den genom att välja den tolkning som känns mest rimlig. Då har vi tappat spårbarheten. Originalet ska tillbaka till sakgranskning.
Lager 2: en språkprofil per språk
Ovanpå den globala policyn lägger jag regler som bara är relevanta för målspråket. För de språk jag arbetat med — bland annat arabiska, bengali, hindi, urdu, dari, persiska, tigrinja, bosniska/kroatiska/serbiska, polska, turkiska, spanska och somaliska — skiljer sig problemen markant.
En språkprofil kan innehålla:
Poängen är inte att skapa enorma språkmanualer. Poängen är att flytta sådant som annars upptäcks om och om igen i manuell QA till ett återanvändbart regelverk.
Jag separerar sakterm från språklig realisering
Ett återkommande problem i samhälls- och myndighetsnära text är att termen i källspråket bär en specifik institutionell betydelse. Den ska inte behandlas som vilket vardagsord som helst.
Jag använder därför en enkel terminologimodell:
Då är det konceptet som är stabilt, inte den svenska ordformen. Om två översättare föreslår olika måltermer kan vi diskutera vilken som bäst representerar samma koncept i rätt register.
Det här blir särskilt viktigt när ett ord har en begriplig direktöversättning som ändå inte är vad modersmålstalare faktiskt använder för den svenska institutionen.
Jag klassar varje term innan jag väljer en lösning
Inte alla ord ska lösas genom att välja närmaste synonym. I myndighetsnära material kan två ord som känns lika på målspråket ändå representera olika juridiska eller administrativa begrepp. Jag skiljer därför på tre typer av motsvarighet: en direkt motsvarighet som översätts normalt, en funktionell motsvarighet som är begriplig men inte exakt samma institution eller begrepp, och fall utan säker motsvarighet där jag behåller den svenska termen och förklarar den kort om formatet tillåter. Det hindrar modellen från att göra ett osäkert val osynligt.
Termregistret behöver därför mer än en godkänd måltext. Jag vill se statusen bakom varje term — godkänd, preliminär eller kontextberoende — plus en kort motivering och ett exempel på sammanhang. En rubrik och en förklarande brödtext kan kräva olika lösning för samma begrepp, så termlistan får aldrig bli en blind ersättningsmotor. Är statusen preliminär eller kontextberoende hamnar frågan hos en reviewer i stället för att tystas ner till ett flytande men missvisande ordval.
Frågor kräver en egen QA-modell
Vanlig brödtext kan ibland tåla en liten stilistisk omformulering. En provfråga är känsligare eftersom varje ord påverkar mätningen.
Jag granskar därför minst fem saker separat:
- stem fidelity — frågan frågar samma sak,
- correct-answer fidelity — rätt alternativ är fortfarande entydigt rätt,
- distractor plausibility — felalternativen är fortfarande rimliga,
- difficulty preservation — översättningen avslöjar inte svaret,
- register — språket är vuxet, begripligt och neutralt.
Det är förvånansvärt lätt för en språkmodell att förbättra en "konstig" distraktor och därmed ändra frågans design. Därför ska översättaren veta att vissa konstigheter är pedagogiska artefakter, inte språkfel.
Tre typer av drift avslöjar om svårighetsgraden hållit
En korrekt översättning kan ändå vara ett dåligt test, om den råkar ge en ledtråd som saknas i originalet eller blir betydligt svårare grammatiskt. Jag tittar därför efter tre typer av drift: hint drift, där översättningen avslöjar svaret; complexity drift, där meningsbyggnaden blir mycket svårare; och scope drift, där frågan blir bredare eller smalare än originalet. Svarsalternativ måste granskas separat i det här arbetet, eftersom ett distraktoralternativ kan bli grammatiskt uppenbart eller kulturellt orimligt efter översättning även när frågestammen är oklanderlig. Varje upptäckt drift blir regressionstest för nästa version av språkreglerna — samma tänk som i övrig AI-QA, där de verkliga felen är det bästa råmaterialet för framtida evals.
Backtranslation är ett verktyg, inte ett facit
Jag använder ibland backtranslation som diagnostik. Om en arabisk version översätts tillbaka till svenska och plötsligt säger något mycket starkare än originalet har vi en tydlig signal.
Men backtranslation kan inte ensam avgöra kvalitet. Två idiomatiska formuleringar kan backtranslate olika och ändå vara lika korrekta. Därför använder jag det som ett larm, inte som automatisk godkännanderegel.
Ett mer robust QA-flöde ser ut så här:
Neutralitet måste vara explicit
I flera språk finns ordval som är grammatiskt korrekta men mer värderande än den svenska källan. Det kan gälla benämningar på grupper, statliga institutioner, migration, religion, kön, medborgarskap eller internationella organisationer.
Jag vill därför att språkprofilen uttryckligen säger:
Det här låter självklart. I praktiken är det en av de saker som lätt tappas när modellen optimerar för "naturligt språk". Idiomatik får aldrig vinna över neutralitet i saktext.
Translitterering är ett produktbeslut
Ett annat område som inte kan lämnas åt modellen från fall till fall är translitterering. Ska ett svenskt myndighetsnamn översättas, translittereras, behållas på svenska eller visas i kombination?
Jag använder en hierarki:
För en utbildningsprodukt är igenkänning viktig. Användaren ska kunna läsa vår text och sedan känna igen ordet på ett brev, en webbplats eller ett prov.
Jag vill ha ett globalt termregister, inte tolv separata sanningar
Om varje språkfil innehåller sin egen fullständiga terminologi blir underhåll dyrt. Jag föredrar en gemensam koncepttabell med språkfält.
Språkprofilen beskriver hur termer ska väljas och realiseras. Termregistret beskriver vilken term som är godkänd för ett visst koncept.
När en svensk källterm ändras kan vi då hitta alla berörda språkversioner. Det är samma grundidé som claim-level fact checking: gör beroenden explicita så att förändringar kan propageras.
AI:n ska kunna säga "terminology unresolved"
Den sämsta typen av översättningsfel är ofta den som låter helt naturlig. Därför behöver modellen ett legitimt abstention-state.
Jag använder hellre:
än att modellen väljer en term med hög språklig självsäkerhet. För språk med mindre digitalt träningsunderlag eller stora registervariationer är den möjligheten extra viktig.
Versionering per språk
När en språkprofil utvecklas vill jag kunna se vad som ändrats. Därför behandlar jag den ungefär som kod:
Det hjälper vid regressioner. Om 30 nya översättningar plötsligt använder ett annat ord kan jag koppla beteendet till en ändrad regel i stället för att gissa om modellen "blev sämre".
Evals ska vara språk- och uppgiftsspecifika
Jag vill inte bara testa "är översättningen korrekt?". Jag vill ha fällor som motsvarar verkliga fel.
För varje språk är det värdefullt med testfall för:
- myndighetstermer,
- namn och egennamn,
- siffror och datum,
- negation,
- rätt/fel-alternativ,
- köns- eller artighetsformer där de påverkar betydelsen,
- neutralitet,
- translitterering,
- källtext med avsiktlig tvetydighet.
Det sista testet ska resultera i flaggning, inte kreativ förbättring.
Vad jag inte automatiserar fullt ut
Jag tycker AI är mycket bra på första översättningen, terminologikontroll, jämförelse mellan språkversioner och identifiering av avvikelser. Jag är mer försiktig med slutgodkännande av känsliga eller mycket specifika termer.
Det är därför jag inte bygger "12 autonoma översättare". Jag bygger tolv specialiserade produktionsprofiler i samma QA-system. Människan finns kvar där språkets naturlighet, kulturell laddning eller institutionell terminologi faktiskt kräver bedömning.
Arkitekturen jag skulle använda i produktion
I en större implementation skulle jag lagra:
Varje översättning pekar på originalversion, språkprofilversion och termregisterversion. Då går det att reproducera varför en text såg ut som den gjorde.
Det är mycket mer än vad som behövs för en enkel marknadsföringssida. Men för hundratals frågor, artiklar och tolv språk är det skillnaden mellan "AI kan översätta" och ett system som faktiskt går att underhålla.
Min viktigaste lärdom
Det mest värdefulla jag fick av att bygga språkfilerna var inte bättre prompts. Det var att problemen blev synliga som typer av problem. När man väl kan säga "det här är en translittereringsfråga", "det här är term provenance", "det här är difficulty preservation" eller "det här är neutralitetsglidning" går det att bygga regler, evals och review-states runt dem.
Då behöver en ny översättning inte börja från noll. Den ärver ett globalt sanningskontrakt, en språkspecifik profil och ett växande bibliotek av testfall. Det är den modellen jag tror skalar: en källa, ett gemensamt kvalitetslager och flera specialiserade språkrealisationer.
Hur jag skulle köra en batch på 50 frågor
För en batch vill jag först frysa originalversionen. Sedan får varje språk en separat arbetsyta. Modellen översätter inte 50 frågor och skickar direkt till publicering; den producerar både text och QA-metadata.
Efter första passet kör jag tvärfrågekontroller: används samma konceptterm konsekvent i hela batchen? Har negation hanterats lika? Finns ett svarsalternativ som plötsligt blivit mycket längre än de andra och därmed signalerar rätt svar? Den typen av corpus-QA hittar problem som en fråga i taget inte visar.
Vad native review faktiskt ska göra
En modersmålsgranskare ska inte behöva börja från tomt dokument. Systemet bör ge exakt de fall där maskinen är osäker eller där regeln kräver mänsklig bedömning. Reviewern kan då fokusera på idiomatik, register, institutionell begriplighet och kulturell laddning. Alla ändringar ska kunna återföras till språkprofilen eller termregistret när de är generaliserbara. Annars lär sig systemet inget av manuell QA.
Min produktionschecklista för A012
Den fullständiga checklistan — versionerad input, provenance för externa fakta, ett explicit state för osäkerhet och minst ett negativt eval per hard-fail — beskriver jag i artikeln om vägen från forskningsartikel till produktionsklar AI-skill.
Språkversionen får aldrig bli en parallell faktadatabas
Ett stort underhållsproblem uppstår om en översättare börjar bädda in förklaringar i måltexten för att göra den "tydligare". Då kan den svenska sidan uppdateras medan den arabiska eller somaliska versionen fortsätter bära en äldre, lokalt tillagd förklaring som ingen längre vet finns. Jag låser därför saklig enrichment till original-/knowledge-lagret. Översättningslagret får realisera godkänd betydelse, inte skapa ny betydelse.
Om ett begrepp behöver förklaras för målgruppen ska förklaringen finnas som ett separat, versionshanterat source segment som alla språk kan översätta. Då går det att uppdatera kunskapen en gång och se vilka språkversioner som behöver ny review.
Variantfrågan måste lösas innan produktion
För vissa språk räcker inte språknamnet som specifikation. Persiska och dari ligger nära varandra men skiljer sig i terminologi och bruk. Bosniska, kroatiska och serbiska har stor ömsesidig begriplighet men också norm- och identitetsfrågor. Arabiska har modern standardarabiska och många vardagsvarianter. En produkt måste därför bestämma vilken standard den faktiskt erbjuder och varför.
Jag vill inte att modellen växlar variant beroende på vad den "tycker låter naturligt". Språkprofilen ska säga vilken norm som gäller för UI, pedagogisk text och eventuella dialognära delar. Om användaren senare ska kunna välja variant kan det bli en produktfunktion, men då ska det vara explicit.
Names, acronyms och svenska institutioner
Ett annat problem är akronymer. "Migrationsverket" kan behöva översättas semantiskt för förståelse men användaren kommer samtidigt möta den svenska formen i vardagen. Jag föredrar därför ofta ett first-occurrence-mönster:
och därefter den etablerade måltermen eller svenska benämningen enligt språkprofilen. Samma sak kan gälla SFI, CSN, riksdagen och andra institutioner. Målet är både begriplighet och igenkänning.
Det här bör inte improviseras per artikel. Termregistret ska styra om first occurrence behöver dubbelform, om akronym ska behållas och om translitterering får användas.
Automatiserad consistency QA över hela korpusen
När antalet texter växer blir consistency QA viktigare än enstaka perfekt översättningar. Jag skulle köra batchkontroller som söker efter:
- ett
concept_idmed flera måltermer utan godkänt alias, - samma svenska egennamn translittererat på flera sätt,
- siffror eller datum som förändrats,
- bortfall av negation,
- svarsalternativ med onormal längdskillnad efter översättning,
- frågor där samma source_version har olika faktainnehåll mellan språk.
Det här är perfekt för scripts och LLM-review i kombination. Script kan hitta kandidater deterministiskt. Modellen kan bedöma om variationen faktiskt är fel eller legitim kontextuell grammatik.
Vad jag skulle mäta för att veta om systemet blir bättre
Jag skulle inte mäta kvalitet med en generell "translation score". Jag vill hellre följa operativa feltyper:
Det gör det möjligt att se att ett språk behöver bättre termregister medan ett annat har problem med frågedesign eller register. Systemet lär sig då på rätt nivå.
Hur jag skulle onboarda språk nummer 13
Den verkliga vinsten med arkitekturen syns när ett nytt språk ska in. Jag börjar inte med "översätt allt". Jag kopierar inte heller regler från ett närliggande språk och hoppas.
Först definieras variant, script, register, translittereringspolicy och de viktigaste institutionstermerna. Sedan körs ett pilotset med frågor som medvetet innehåller svåra fenomen: negation, myndighetsnamn, nära distraktorer, datum, samhällsbegrepp och neutralitetskänsliga uttryck. Native review av pilotsetet blir data till språkprofilen. Först därefter skalar jag batchproduktionen.
På så sätt blir varje nytt språk en kontrollerad expansion av samma system, inte ett nytt separat översättningsprojekt.
Hur jag skiljer språkligt fel från produktfel
När en översatt fråga känns fel behöver reviewern klassificera orsaken. Är måltexten grammatiskt fel? Är den semantiskt korrekt men onaturlig? Har källfrågan en tvetydighet som blir tydligare i målspråket? Eller är själva pedagogiska konstruktionen svag? Jag använder därför felkoder som LANGUAGE, TERMINOLOGY, SOURCE_AMBIGUITY, QUESTION_DESIGN och FACT. Då hamnar felet hos rätt ägare. Annars riskerar språkteamet att korrigera ett sakproblem lokalt och skapa divergens mellan språk.
UI-text och långform behöver olika regler
Samma språkprofil kan inte styra allt på exakt samma sätt. En knapp, ett felmeddelande och en myndighetsförklaring har olika utrymme och register. Jag delar därför åtminstone upp UI, QUESTION, EXPLANATION och ARTICLE. UI tillåter ofta kortare, mer idiomatisk formulering. Frågor prioriterar mätmässig ekvivalens. Förklaringar får vara pedagogiska men måste fortfarande följa samma faktakälla. Artiklar behöver dessutom konsistent terminologi över längre text.
Hur jag skulle hantera uppdateringar i originalet
När en svensk text ändras vill jag inte bara skicka hela dokumentet till ny översättning. Systemet bör kunna diff:a source segments och markera exakt vilka målsegment som är stale. Om en mening ändrar ett belopp ska det bli en high-risk update. Om bara skiljetecken ändras kan reviewbehovet vara lägre. Segmentnivå gör det möjligt att underhålla tolv språk utan att manuellt läsa allt från början varje gång.
Första publiceringen är början på QA, inte slutet. Efter lansering vill jag samla korrigeringar från support, användare och språkgranskare som strukturerad feedback. Om samma turkiska term korrigeras tre gånger ska det bli en termregel, inte tre isolerade patchar. Om användare återkommande missförstår en arabisk fråga kan problemet vara översättning, pedagogik eller originalfrågan. Feedbacken ska därför gå tillbaka till samma felklassificering och förbättra språkprofil, termregister eller source content beroende på rotorsak.
Hur jag undviker att "enkelt språk" blir barnsligt språk
Målgruppen kan behöva tydlig och lättillgänglig text utan att bli tilltalad som ett barn. Därför skiljer jag på enkelhet och förenkling. Korta meningar kan hjälpa, men viktiga facktermer måste fortfarande läras ut eftersom användaren kommer möta dem i Sverige. Språkprofilen ska därför prioritera tydlig syntax och etablerade ord, men inte ersätta varje institutionell term med en vag vardagsparafras.
Det här är extra viktigt i utbildningsmaterial. Om målet är att förbereda någon för ett verkligt samhällsbegrepp måste termen synas, gärna med en kort förklaring första gången. En översättning som gör allt "lättare" kan pedagogiskt bli sämre eftersom den tar bort just det vokabulär användaren behöver lära sig.
Human QA ska ge strukturerad feedback
När en native reviewer ändrar en mening vill jag få mer än den nya meningen. Reviewgränssnittet bör kunna fråga: vilken typ av ändring var detta? TERM, GRAMMAR, REGISTER, SEMANTIC, NEUTRALITY, QUESTION_DIFFICULTY eller OTHER. Om ändringen är generaliserbar ska reviewern kunna föreslå en regel eller termuppdatering. Då går mänsklig tid till att förbättra systemet, inte bara reparera enskilda outputs.
Det gör också kvalitet mätbar över tid. Om SEMANTIC-felen sjunker men REGISTER-felen ligger kvar vet jag att kärnöversättningen fungerar men språkprofilen behöver bättre exempel. Om QUESTION_DIFFICULTY ökar efter en ny modellversion blir det ett regressionstest. Den feedbackloopen är mycket mer värdefull än en allmän rating på "bra översättning".
Referenser för översättnings-QA
Relaterade artiklar
- Hur jag gör språk-specifika instruktioner för arabiska, bengali, dari, urdu och somaliska
- Hur jag bygger frågebanker som inte överanpassas till ett facit
- De vanligaste mekaniska mönstren i AI-prosa
- Hur jag hanterar regler, belopp och datum i AI-genererade artiklar
- Så testar jag om en Humanizer faktiskt förbättrar texten