Det här är del 2 av 3 i vår artikelserie om AI i praktiken. Läs också del 1: Vad använder vi det egentligen till? och del 3: Vad görs i Tripnets AI-lab?
I första delen pratade jag om vad vi faktiskt använder AI till i vardagen. Ganska konkreta saker: texter, möten, analys och utveckling. Men ganska snabbt dyker en annan fråga upp. Varför känns vissa svar genomtänkta och andra ytliga? Varför är vissa modeller snabba men enklare, medan andra känns mer eftertänksamma? Och vad är det egentligen som händer bakom kulisserna?
En viktig sak att vara tydlig med är perspektivet i den här artikeln.
– Jag utgår till stor del från ett scenario där man arbetar med egna eller lokalt körda modeller. Då blir frågor som modellstorlek, svarstid och resursbehov väldigt konkreta, eftersom man själv ansvarar för hur lösningen körs.
Om man i stället använder färdiga tjänster som ChatGPT, Copilot eller Claude är det här mer dolt. Då väljer man oftast inte modellstorlek direkt, utan snarare mellan olika nivåer av tjänst – där prestanda, svarstid och kvalitet i praktiken styrs av leverantören och hur mycket man är beredd att betala per användning. Det innebär också att hastighet inte enbart är kopplat till modellens storlek, utan lika mycket till hur mycket beräkningsresurser som används i stunden.
Storleken på modellen – varför det spelar roll
När man pratar om AI-modeller stöter man ganska snabbt på begrepp som 7B, 20B eller 120B. Det låter tekniskt, men i grunden handlar det om hur mycket modellen kan hantera och hur komplexa samband den klarar av att hålla ihop.
En mindre modell är snabb. Den svarar direkt, fungerar bra i enklare uppgifter och lämpar sig väl i automatiserade flöden där svarstid är viktig. Men den har svårare att hålla ihop längre resonemang och tappar snabbare djup.
En mellanstor modell är ofta det som fungerar bäst i vardagen. Den klarar att resonera i flera steg, anpassa språk och hålla en röd tråd utan att bli för tung att köra. Det är här många upplever att AI börjar kännas riktigt användbar.
De riktigt stora modellerna har en annan kapacitet. De är bättre på att väga flera perspektiv, hantera komplexa problem och hålla ihop längre texter. Större modeller tenderar att vara långsammare och mer resurskrävande – men sambandet är inte absolut. I en egen miljö märks det tydligt eftersom man själv sitter på begränsade resurser. I molntjänster kan större modeller däremot upplevas som snabba, eftersom de tilldelas mer beräkningskraft. Skillnaden är att det då sker till en högre kostnad per användning.
Och det är egentligen här en viktig insikt kommer. Det handlar inte om att välja den största modellen. Det handlar om att välja rätt modell för rätt uppgift. I praktiken landar det ofta i något ganska enkelt: enklare frågor klarar sig med mindre modeller, vardagsarbete fungerar bäst i mellanstorlek och mer komplex analys kräver större modeller. Det låter självklart, men det är lätt att glömma i praktiken. Fler parametrar innebär inte automatiskt “bättre” i alla situationer. Samma modell kan upplevas väldigt olika beroende på hur mycket resurser den får tilldelat i den miljö den körs i.
Större modeller innebär:
- bättre hantering av komplexitet
- högre resurskrav och kostnad att använda
- större behov av att välja rätt uppgift
Därför är en kombination av flera modellstorlekar oftast både effektivare och mer kostnadsmedveten än att använda en enda stor modell till allt.
1.3B – små modeller
Modeller runt 1.3 miljarder parametrar är mycket snabba och resurssnåla. De lämpar sig väl för enkla, tydligt avgränsade uppgifter.
De fungerar bra för:
- korta svar
- klassificering och taggning
- enkla sammanfattningar
- automatiserade flöden där svarstiden är viktig
De fungerar sämre för längre resonemang, komplexa instruktioner och nyanserad språkhantering. Pedagogiskt kan man se dem som juniora assistenter: snabba och effektiva, men med begränsad förståelse.
20B – mellanstora modeller
Modeller runt 20 miljarder parametrar utgör ofta den bästa balansen mellan kvalitet och prestanda.
De klarar:
- flerstegsresonemang
- sammanhängande texter
- anpassning av stil och ton
- tekniska och verksamhetsnära frågor
Det är i denna storleksklass många användare upplever att modellen börjar ge svar som känns genomtänkta och konsekventa, utan att bli långsam eller tung. Därför är detta ofta den storlek som används som standard i praktiken.
120B – mycket stora modeller
Modeller runt 120 miljarder parametrar har en betydligt större kapacitet att hantera komplexitet och abstrakta samband.
De lämpar sig särskilt väl för:
- avancerad analys
- långa, sammanhängande resonemang
- granskning av antaganden
- komplexa beslutsunderlag
De ger ofta mer nyanserade svar och tappar mer sällan tråden i långa texter. Samtidigt kräver de mycket beräkningsresurser och längre svarstider, vilket gör dem olämpliga för enklare frågor. Man kan se dem som seniora experter: mycket värdefulla när problemet är svårt, men ineffektiva för vardagsuppgifter.
Träning och inferens – två olika världar
En annan sak som ofta blandas ihop är träning och användning.
Träning är processen där modellen lär sig. Det är ett omfattande arbete som kräver stora mängder data och beräkningskraft. Det är inget man gör i vardagen och inget de flesta organisationer varken har behov av eller ska ge sig på.
Det vi gör varje dag är inferens. Du ställer en fråga och modellen svarar. Det är där värdet uppstår. I en lokal lösning blir det extra tydligt, eftersom svarstiden och kvaliteten direkt påverkas av vilken modell man valt och vilka resurser man har tillgängliga. I en molntjänst är samma mekanik dold bakom tjänsten, men principen är densamma.
AI-modeller minns ingenting
Till skillnad från vad många tror har AI-modeller inget minne. Modellen startar alltid från noll. Varje gång du ställer en fråga till AI:n är det gränssnittet runt omkring som skickar med hela den tidigare konversationen, information om vem du är, inställningar du har gjort och kanske sådant du har bett AI:n komma ihåg om dig.
Du märker detta till exempel när du är i en chattgruppstråd. AI:n kan inte referera till en annan tråd och har uppenbarligen glömt vad ni pratade om igår – men det beror på att den aldrig har kommit ihåg det. Det här är viktigt att ha i åtanke när vi går vidare och pratar om användning av RAG i AI, där vi utöver tidigare konversationer och information om vem jag är även kan skicka med ytterligare data för att få AI:n att agera på önskat sätt.
RAG – när AI får tillgång till rätt information
När man vill anpassa AI till sin egen verksamhet finns det i praktiken två vägar.
Den ena är att träna om modellen, så kallad fine-tuning. Det innebär att man förändrar modellen i grunden så att den bättre passar en viss uppgift, ett visst språkbruk eller ett visst arbetssätt. Det kan vara kraftfullt, men det är också komplext, dyrt och ofta betydligt mer resurskrävande än man först tror. Dessutom blir modellen svårare att uppdatera, styra och förklara över tid.
Den andra vägen är att använda RAG, Retrieval-Augmented Generation, dvs en AI som först letar upp relevant information och sedan svarar utifrån den. Då ändrar man inte modellen alls. I stället ger man modellen tillgång till rätt information när frågan ställs. Det är i grunden ett ganska klokt upplägg. I stället för att försöka få modellen att “lära sig” hela verksamheten i förväg, låter man den hämta relevant information från dokument, databaser eller andra interna källor i samma stund som den ska svara. Modellen får alltså inte bara en fråga från användaren, utan också ett urval av relevant underlag att luta sig mot.
Kärnan i RAG:
Först hitta rätt information, sedan låta modellen formulera ett svar utifrån den.
Lite förenklat fungerar det så här:
- Användaren ställer en fråga.
- Systemet söker fram relevanta delar ur verksamhetens eget material.
- Dessa delar skickas med tillsammans med frågan till språkmodellen.
- Modellen formulerar ett svar med stöd i det underlag som just hämtats fram.
Det gör stor skillnad.
Utan RAG svarar modellen utifrån sin generella träning. Med RAG kan den också ta hänsyn till din egen verklighet: dina policys, dina rutiner, dina kundavtal, dina instruktioner och din terminologi. Det gör svaren mer relevanta, mer användbara och ofta mer korrekta i den egna kontexten.
Kunskapen blir lättare att hålla aktuell.
Om du uppdaterar ett dokument, en rutin eller en instruktion behöver du normalt inte träna om modellen. Det räcker att systemet får tillgång till den nya informationen. På så sätt blir RAG ofta både snabbare och mer flexibelt än fine-tuning.
Det är också därför jag tycker att RAG i de allra flesta fall är rätt väg att börja med.
Inte för att fine-tuning är fel, utan för att RAG ofta ger mycket effekt snabbare. Du får en AI som kan arbeta med verksamhetens egna underlag, utan att du behöver bygga om modellen från grunden. Det gör tröskeln lägre och nyttan mer direkt.
Samtidigt ska man inte tro att RAG är magi.
Kvaliteten på svaret beror mycket på kvaliteten i underlaget. Om dokumenten är gamla, motstridiga, dåligt strukturerade eller skrivna på väldigt olika sätt blir resultatet också mer osäkert. RAG ställer därför krav på ordning, tydlighet och informationsstyrning. En AI-lösning blir sällan bättre än det innehåll den får hämta sin förståelse från.
Det är just där många verksamheter har sin verkliga utmaning.
- Inte i modellen.
- Utan i informationen.
För mig är det därför klokt att se RAG som en brygga mellan AI och verksamhetskunskap. Man behåller styrkan i en generell språkmodell, men kombinerar den med det som är unikt för den egna organisationen. Det är ofta ett mer praktiskt, mer kontrollerat och mer affärsmässigt sätt att börja.
Fine-tuning kan absolut ha sin plats. Särskilt när man vill påverka modellens beteende mer på djupet, till exempel ton, klassificering eller specialiserade uppgifter i stor skala. Men för de flesta organisationer som vill få AI att förstå den egna verksamheten är RAG nästan alltid den mest rimliga startpunkten.
Det är enklare, snabbare och mer flexibelt. Och ofta är det precis det som behövs för att komma igång på riktigt.
Fine-tuning eller RAG – vad ska man välja?
Vi kan till exempel tänka oss en AI som har fått tillgång till våra processer genom RAG. Den är inte tränad på nytt från grunden och den “kan” egentligen inte Tripnet i sig. Men den kan, i stunden, hämta rätt information ur vårt eget material och använda den som grund för sina svar.
Det gör stor skillnad i praktiken. Om en kollega ställer frågan hur vi på Tripnet gör riskbedömningar kan AI:n söka fram relevanta delar ur våra styrande dokument, processbeskrivningar, metodstöd och rutiner. Den kan sedan sammanfatta detta på ett begripligt sätt och svara utifrån just vårt arbetssätt, inte utifrån en allmän uppfattning om hur riskhantering brukar fungera.
Samma sak gäller incidenthantering. Om någon frågar hur incidentprocessen fungerar hos oss kan AI:n plocka fram rätt steg, rätt ansvar, rätt eskaleringsvägar och rätt arbetssätt från vår egen dokumentation. I stället för att ge ett generiskt svar om incident management kan den beskriva hur vi faktiskt gör på Tripnet. Det gör svaret mer relevant, mer användbart och betydligt närmare verkligheten i verksamheten.
Det fina i det här är att AI:n blir ett stöd för att hitta, förstå och använda det vi redan har beslutat. Den ersätter inte processägaren. Den ersätter inte ledningssystemet. Och den ersätter inte det professionella omdömet. Men den gör det enklare att omsätta våra processer i vardagen.
För en ny kollega kan det här vara ett snabbt sätt att förstå hur vi arbetar. För en erfaren kollega kan det vara ett stöd när man vill kontrollera ett steg, ett ansvar eller ett begrepp utan att själv behöva leta i flera dokument. För ledningen kan det vara ett sätt att göra styrande information mer tillgänglig och användbar i praktiken.
Det är också här RAG blir så intressant.
AI:n behöver inte “veta allt” i förväg. Den behöver bara kunna hitta rätt underlag när frågan kommer. Om vi uppdaterar processen för riskbedömning eller justerar vår incidenthantering är det därför inte säkert att vi behöver bygga om hela lösningen. Det viktiga är att AI:n får tillgång till den uppdaterade informationen. Då kan svaren följa med verksamheten på ett helt annat sätt än om vi skulle försöka låsa fast kunskapen i själva modellen.
Ett usecase som är lätt att förstå affärsmässigt. Vi tar kunskap som redan finns i verksamheten, men som ibland är svår att hitta eller tolka, och gör den mer tillgänglig i rätt ögonblick. Det sparar tid, minskar osäkerhet och ökar chansen att vi faktiskt arbetar enligt våra egna processer.
Det betyder inte att allt blir perfekt automatiskt. Kvaliteten beror fortfarande på hur bra våra dokument är, hur aktuella de är och hur tydligt de beskriver ansvar, steg och begrepp. En AI med RAG är därför inte starkare än det ledningssystem och den informationsstruktur den får arbeta med.
Men när grunden är god, då blir nyttan väldigt konkret. I stället för att AI bara svarar “smart” kan den svara förankrat. I stället för att ge ett generellt resonemang kan den beskriva hur vi gör på Tripnet. Och det är där RAG går från att vara en teknisk metod till att bli ett faktiskt verksamhetsstöd.
Olika modeller för olika uppgifter
När man börjar arbeta med AI upptäcker man ganska snabbt att det finns många olika modeller.
Det beror inte på att någon inte har lyckats bygga “den bästa”. Det beror på att olika modeller är bra på olika saker. Vissa är bättre på språk. Andra på kod. Vissa är små och snabba, andra större och mer eftertänksamma.
Det innebär att man inte väljer en modell – man väljer flera.
AI är inte magi – det är arkitektur
När man sätter ihop det här blir en sak tydlig. AI handlar inte bara om att ställa en fråga och få ett svar. Det handlar om vilken modell man använder, vilken information modellen får tillgång till och hur man bygger lösningen runt omkring. Det är först när man börjar se AI som en del av en arkitektur som det verkliga värdet uppstår.
Vi har tidigare sett hur standardinställningar i molntjänster kan bli ett säkerhetsbeslut. AI är inget undantag. Default är inte alltid rätt.
Du har läst del 2 av 3 i vår artikelserie om AI i praktiken.
Läs gärna del 1: Vad använder vi det egentligen till? eller gå vidare till del 3: Vad görs i Tripnets AI-lab?
