Evals-driven development: Så testar du LLM-applikationer i CI/CD

Ingen seriös utvecklare skulle deploya kod till produktion utan tester. Ändå är det precis vad de flesta gör med sina LLM-applikationer: någon justerar en prompt, det "känns bättre" i ett par exempel, och så går det live. Sedan upptäcker man att svaren blev sämre på alla de fall man inte råkade testa. Evals-driven development löser det genom att behandla LLM-beteende som något mätbart - en testsvit för icke-deterministisk output, körd automatiskt i CI/CD precis som vanliga enhetstester.

Jag inför evals i varje seriöst LLM-projekt inom AI Engineering, eftersom det är det enda som förvandlar prompt-pillande till ingenjörskonst. Utan det bygger du på tur, och tur skalar inte.

Varför vanliga tester inte räcker

Ett vanligt enhetstest jämför output mot ett exakt förväntat värde. Det fungerar inte för LLM:er, som kan formulera samma korrekta svar på hundra olika sätt. En eval mäter istället om svaret uppfyller kriterier: innehåller det rätt fakta? Håller det rätt ton? Undviker det att hitta på? Refererar det till källan? Du flyttar från "är detta exakt rätt sträng" till "är detta ett bra svar", och det kräver andra sorters kontroller. Det är just den övergången som gör evals till en egen disciplin.

Tre sätt att utvärdera

• Regelbaserade kontroller: snabba och billiga. Innehåller svaret det obligatoriska? Är det giltig JSON? Håller det sig under en längd? Nämner det något det inte får? Börja här - mycket går att fånga med enkel logik.
• Modell-som-domare: en LLM bedömer en annan LLM:s svar mot kriterier du formulerar. Kraftfullt för subjektiva egenskaper som ton och hjälpsamhet, men kalibrera domaren mot mänskliga bedömningar så att du litar på den.
• Mänsklig granskning: det dyraste men ibland nödvändiga. Använd det sparsamt, för att kalibrera de automatiska metoderna och för de fall som verkligen betyder något.

Bygg en facit-uppsättning som speglar verkligheten

Hjärtat i evals är ett dataset med representativa indata och en uppfattning om vad ett bra svar är. Det vanligaste misstaget är att bara testa de lätta, lyckade fallen. Den verkliga nyttan kommer från kantfallen: de tvetydiga frågorna, de fientliga inmatningarna, det som tidigare gått fel i produktion. Varje gång något felar live ska det bli ett nytt testfall, så att samma fel aldrig kan smyga sig tillbaka. Med tiden blir den uppsättningen ett av era mest värdefulla tillgångar - en levande specifikation av vad systemet ska klara.

Evals i CI/CD: grinden som fångar regressioner

Poängen är att köra evals automatiskt vid varje ändring - en ny prompt, en modelluppdatering, en justerad parameter. Pipelinen kör sviten, jämför resultatet mot baslinjen och varnar om något försämrats. Det här fångar den lömskaste sortens fel i LLM-system: den där en förbättring på ett område tyst försämrar ett annat. Utan grinden upptäcker du det först när en användare klagar; med den ser du det innan ändringen ens mergas. Det är samma trygghet som vanliga tester ger, applicerad på det som annars är omöjligt att överblicka.

Börja litet - men börja

Du behöver inte ett perfekt eval-ramverk för att få värde. Tio väl valda testfall som körs vid varje promptändring är oändligt mycket bättre än noll, och de fångar de flesta grova misstagen direkt. Börja med de regelbaserade kontrollerna och de viktigaste fallen, och bygg ut allt eftersom systemet och förståelsen mognar. Det viktiga är att sluta deploya på känsla - resten är förfining. Den som väntar på det perfekta ramverket testar aldrig alls.

Relaterat

• RPA möter AI-agenter: När UiPath/Automation Anywhere ersätts av LangGraph
• Claude Code vs Cursor vs Windsurf 2026: Vilken AI-kodassistent passar svenska team?
• MCP-servrar i produktion: Bygg din första Model Context Protocol-integration

Ett exempel på en eval-svit i drift finns i kundcase.

Vill du ta det vidare?

Jag hjälper svenska bolag att bygga eval-sviter och köra dem i CI/CD - så att ni slutar deploya LLM-ändringar på känsla. Boka ett förutsättningslöst samtal så går vi igenom er pipeline.