Bygg LLM-Benchmark: Testa 6 AI-Modeller i 13 Steg [2026]

Du har säkert sett rankningarna. En leaderboard säger att Claude Opus 5.5 toppar, en annan sätter DeepSeek V4.1-Flash först, en tredje svär på att Mistral Large 4 vinner på pris och prestanda. Problemet är att nästan ingen av dessa listor testar det du egentligen bryr dig om: dina prompter, din kodbas, din svenska text och dina kostnadskrav. Lösningen är att bygga ett eget litet LLM-benchmark, och det är enklare än det låter. I den här guiden går vi igenom hur du sätter upp en egen testrigg med öppen källkod-verktyg, kör standardiserade test som MMLU-Pro och HumanEval, och lägger till ett nordiskt testset som faktiskt speglar din verklighet.

Vi bygger ett komplett projekt i Python och Node.js som kör sida vid sida-jämförelser mellan GPT-6.1 Sol, Claude Opus 5.5, Gemini 4 Argon, DeepSeek V4.1-Flash, Mistral Large 4 och GLM-5.3, loggar kostnad och latens, och ger dig en tabell du faktiskt kan lita på. 13 steg, cirka 90 minuter om du redan har API-nycklar klara.

Guiden handlar om att bygga ett praktiskt beslutsunderlag, inte om att återskapa ett akademiskt forskningslabb. Vi går inte igenom hur man tränar egna modeller eller finjusterar vikter, det är ett separat ämne. Fokus här ligger helt på att mäta befintliga API-modeller mot varandra på ett sätt som är reproducerbart, dokumenterat och anpassat till svenska och nordiska förhållanden.

Varför bygga ditt eget LLM-benchmark 2026

Publika leaderboards är användbara för en första överblick, men de lider av tre problem. Först: kontaminering. Många benchmarkfrågor har funnits på nätet så länge att nyare modeller kan ha sett dem under träning, vilket blåser upp resultaten utan att spegla verklig förmåga. Sedan: generaliseringsgapet. Ett toppresultat på engelsk juridisk text säger väldigt lite om hur en modell hanterar svensk teknisk dokumentation eller GDPR-känsliga supportärenden. Till sist: scaffolding-skillnader. Ett SWE-bench-resultat beror lika mycket på verktygsanvändning och promptmall som på själva modellen, så två leaderboards kan rankra samma modell helt olika beroende på hur testet är riggat.

Det finns också en förtroendefråga som är värd att ta på allvar. Enligt Stack Overflows utvecklarundersökning 2025 svarar 46 procent av utvecklarna att de aktivt misstror hur korrekta AI-verktyg är, medan bara 33 procent säger att de litar på dem. Ännu mer talande: “Only 3% of developers report highly trusting AI-tool output”, enligt samma undersökning. Samtidigt uppger 84 procent att de redan använder eller planerar att använda AI-verktyg i sitt arbete, och 51 procent av yrkesutvecklarna kör AI-verktyg dagligen. Det gapet mellan användning och förtroende är precis varför ett eget benchmark är värt tiden: du slutar gissa och får siffror som gäller din egen användning, inte en generisk demo.

Ett eget benchmark ger dig också kontroll över kostnaden. Att välja fel modell för ett högvolymsflöde kan kosta tiotusentals kronor extra per månad i onödan, medan femton minuters egen testning ofta räcker för att se vilken modell som faktiskt löser din uppgift billigast. Det är den här typen av beslutsunderlag vi bygger mot i resten av artikeln.

Det finns även en upphandlingsvinkel som ofta glöms bort. När en organisation ska välja leverantör av AI-funktionalitet till en kundtjänst eller ett internt verktyg, är det sällan den högsta poängen på en global leaderboard som avgör beslutet, utan hur modellen presterar på just de uppgifter och den svenska text som ska hanteras i produktion. Ett dokumenterat, reproducerbart eget benchmark ger dig dessutom något att visa upp internt när ledningen frågar varför just den modellen valdes, istället för att behöva luta dig mot en extern lista du inte själv kan verifiera.

Datalagring och var en modell körs spelar också in för många nordiska organisationer. Vissa leverantörer erbjuder EU-regioner för sina API:er, andra kör allt via amerikanska datacenter. Om din verksamhet hanterar personuppgifter är detta värt att väga in redan när du bygger listan över vilka modeller som ens är kandidater, innan du lägger tid på att benchmarka dem.

Förutsättningar: verktyg och versioner du behöver

Du behöver inte ett kluster eller en GPU för det här projektet. Allt körs mot API:er hos modell-leverantörerna, så din dator eller en liten molnserver räcker gott. Här är vad som ska finnas på plats innan du börjar.

Verktyg	Minsta version	Syfte i projektet
Python	3.11 eller senare	Köra lm-evaluation-harness och DeepEval
Node.js	20 LTS eller senare	Köra promptfoo för sida-vid-sida-jämförelser
pip och venv	Ingår i Python	Isolerad miljö för beroenden
git	2.40 eller senare	Klona eval-ramverk och versionshantera testset
API-nycklar	Gäller per leverantör	Åtkomst till de modeller du vill testa
Diskutrymme	Cirka 2 GB fritt	Beroenden, cacheade svar och loggar

Räkna med API-kostnader utöver detta. Ett fullt körning av ett mindre benchmark mot sex modeller brukar hamna i spannet 50-300 kronor beroende på hur stort ditt testset är och hur många modeller som kostar mer per miljon token. Kör alltid ett litet pilottest innan du startar hela sviten, det återkommer vi till i avsnittet om fallgropar.

Steg 1-3: Sätt upp projektet och välj modeller att testa

Steg 1: Skapa projektstruktur och virtuell miljö

Börja med en ren mapp och en isolerad Python-miljö, så att beroenden för olika eval-ramverk inte krockar med varandra.

mkdir llm-benchmark && cd llm-benchmark
python3 -m venv .venv
source .venv/bin/activate
mkdir -p data results configs scripts
git init

Steg 2: Installera grundverktygen

Installera lm-evaluation-harness från EleutherAI och DeepEval i samma virtuella miljö. Båda är aktiva open source-projekt som uppdateras ofta, så kör alltid pip install -U innan du startar ett nytt projekt för att få senaste versionen.

pip install -U lm-eval deepeval python-dotenv pandas
npm install -g promptfoo

Spara dina API-nycklar i en .env-fil i projektroten, och lägg till den i .gitignore direkt så du inte råkar committa nycklar till git.

Steg 3: Välj vilka AI-modeller du ska testa

Det är lockande att testa allt, men börja smalt. Fem till sex modeller räcker för att få ett meningsfullt beslutsunderlag utan att körningen tar hela dagen. En rimlig startlista för 2026 täcker både de stora stängda modellerna och de ledande öppna alternativen.

Modell	Leverantör	Typ	Känd egenskap
GPT-6.1 Sol	OpenAI	Stängd	Enligt tidigare rapportering ska Sol nå Astra-nivå på kodtest till en femtedel av priset
Claude Opus 5.5	Anthropic	Stängd	Del av en snabb modellkapplöpning med flera Claude-releaser inom samma månad
Gemini 4 Argon	Google	Stängd	Rullades ut brett till företagskunder vid lansering
DeepSeek V4.1-Flash	DeepSeek	Öppen vikt	Rapporterat mycket lågt pris per token jämfört med stängda flaggskeppsmodeller
Mistral Large 4	Mistral AI	Öppen källkod	Lanserades som en modell med mycket stort parameterantal under öppen licens
GLM-5.3	Z.AI	Öppen vikt	En av flera kinesiska modeller som snabbt stängt gapet mot ledande stängda modeller

Lägg gärna till eller ta bort rader beroende på vad du faktiskt har API-åtkomst till. Poängen med egna benchmark är inte att testa alla modeller som finns, utan de som är realistiska kandidater för din applikation. Har du redan en favorit du vet fungerar bra, inkludera den som referenspunkt så att nya modeller måste mäta sig mot den du faktiskt kan jämföra mot i praktiken, inte bara mot varandra i teorin.

Steg 4: Kör ditt första standardtest med lm-evaluation-harness

lm-evaluation-harness från EleutherAI är det mest använda öppna ramverket för att köra etablerade benchmarksviter som MMLU, MMLU-Pro, GPQA och ARC mot ett API eller en lokal modell. Det stödjer de vanligaste API-formaten rakt av, så du behöver sällan skriva egen integrationskod för de stora leverantörerna.

MMLU-Pro är värt att börja med eftersom det byggdes specifikt för att vara svårare och mindre känsligt för memorering än ursprungliga MMLU, enligt EleutherAIs egen dokumentation. Frågorna är flervalsfrågor över 57 ämnesområden, men med fler och snårigare svarsalternativ.

lm_eval \
  --model openai-chat-completions \
  --model_args model=gpt-6.1-sol,api_key=$OPENAI_API_KEY \
  --tasks mmlu_pro \
  --num_fewshot 5 \
  --batch_size 4 \
  --output_path results/mmlu_pro_gpt6_1_sol.json

Upprepa samma kommando för varje modell, byt bara ut --model och --model_args. Lås --num_fewshot till samma värde för alla modeller i omgången, annars jämför du inte äpplen med äpplen. Ett typiskt terminalutdrag ser ut ungefär så här när körningen är klar:

mmlu_pro: {"acc,none": 0.7124, "acc_stderr,none": 0.0041}
Time: 14m32s | Requests: 1512 | Errors: 0

Notera acc_stderr, standardfelet. Det är lätt att glömma, men utan det kan du inte avgöra om en skillnad på två procentenheter mellan två modeller är verklig eller bara brus i urvalet.

Steg 5-6: Testa kodgenerering med HumanEval och ett SWE-bench-liknande test

HumanEval mäter kodgenerering genom att låta modellen skriva en funktion utifrån en docstring, och sedan köra dolda enhetstester mot resultatet. Måttet rapporteras oftast som pass@1, andelen uppgifter som klaras på första försöket, men pass@k förekommer också när flera samplingar tillåts. Var uppmärksam på vilket av dessa en leaderboard faktiskt redovisar, eftersom pass@10 ser betydligt bättre ut än pass@1 för samma modell.

lm_eval \
  --model anthropic-chat \
  --model_args model=claude-opus-5.5 \
  --tasks humaneval \
  --confirm_run_unsafe_code \
  --output_path results/humaneval_claude_opus_5_5.json

SWE-bench går ett steg längre och testar om en modell kan lösa verkliga GitHub-ärenden genom att producera en patch som får en riktig kodbas att gå igenom sina egna tester. Att köra full SWE-bench själv kräver containeriserade reposnapshots och är tungt att sätta upp från grunden, så för ett eget snabbtest räcker det ofta att bygga en liten egen variant: ta fem till tio verkliga buggar eller funktionsförfrågningar från ditt eget repo, be modellen skriva en patch, och köra er befintliga testsvit mot resultatet. Det är inte vetenskapligt jämförbart med den publicerade SWE-bench Verified-listan, men det säger dig något den listan aldrig kan: hur modellen presterar på just din kodbas.

Skilj alltid på SWE-bench Verified och den fullständiga SWE-bench-sviten när du läser resultat från andra källor. Verified är en manuellt kvalitetsgranskad delmängd, och siffrorna är inte direkt jämförbara med den större, brusigare originalsviten.

Vad de olika benchmarksviterna faktiskt mäter

Innan du lägger till fler sviter i din körning är det värt att veta vad varje svit faktiskt säger dig, och lika viktigt, vad den inte säger dig. Att en modell toppar MMLU betyder till exempel inte att den är bäst på att skriva säker kod, och ett starkt HumanEval-resultat säger ingenting om modellen klarar en flerstegsuppgift i en verklig kodbas med beroenden mellan filer.

Benchmarksvit	Vad den mäter	Styrka	Svaghet du bör känna till
MMLU	Bred allmänkunskap över 57 ämnesområden via flervalsfrågor	Snabb, billig, bred täckning	Känslig för memorering och för hur svaren parsas ut
MMLU-Pro	Samma breda kunskap men med svårare, mindre gissningsbara svarsalternativ	Mindre känslig för ren gissning än MMLU	Fortfarande ett flervalsformat, inte fritextresonemang
HumanEval	Kodgenerering utifrån en docstring, verifierad med dolda enhetstester	Objektivt, enkelt att automatisera	Små, isolerade funktioner, speglar inte arbete i en stor kodbas
SWE-bench Verified	Lösning av verkliga, manuellt granskade GitHub-ärenden i en riktig kodbas	Närmare verkligt utvecklararbete än HumanEval	Starkt beroende av agentens verktygsstöd, inte bara modellens råstyrka
GPQA	Doktorandnivå-frågor inom naturvetenskap, tänkta att vara sökmotorresistenta	Svårt att slå genom att bara googla svaret	Smalt fokusområde, säger lite om språk- eller skrivuppgifter

En praktisk tumregel: använd MMLU-Pro och GPQA för att få en känsla för ren resonemangsförmåga, HumanEval och ditt eget SWE-bench-liknande test för kodförmåga, och lämna resten av din testbudget till det nordiska testsetet i nästa steg, eftersom det är det enda som direkt speglar din egen användning.

Steg 7: Jämför modeller sida vid sida med promptfoo

promptfoo är byggt för just det här: en konfigurationsfil där du listar modeller, prompter och test, och verktyget kör alla kombinationer och visar resultatet i en matris i terminalen eller webbläsaren. Det är särskilt bra för dina egna, verksamhetsspecifika test, till skillnad från lm-evaluation-harness som är mer inriktat på etablerade akademiska sviter.

providers:
  - openai:gpt-6.1-sol
  - anthropic:claude-opus-5.5
  - google:gemini-4-argon
  - deepseek:deepseek-v4.1-flash
  - mistral:mistral-large-4
  - zhipuai:glm-5.3

prompts:
  - "Sammanfatta följande svenska supportärende i tre meningar: {{ticket}}"

tests:
  - vars:
      ticket: "Kunden kan inte logga in efter lösenordsbyte, får felkod 403."
    assert:
      - type: contains
        value: "403"
      - type: llm-rubric
        value: "Svaret är på svenska och nämner felkoden"

promptfoo eval -c configs/support-sv.yaml
promptfoo view

promptfoo view öppnar ett lokalt webbgränssnitt där du kan klicka dig igenom varje svar sida vid sida, vilket gör det mycket lättare att se kvalitativa skillnader som en ren poäng aldrig fångar, till exempel ton, exakthet i svensk grammatik eller om modellen hittar på fakta.

Steg 8: Mät RAG- och agentkvalitet med DeepEval

Om din applikation bygger på retrieval-augmented generation eller agenter som använder verktyg, räcker klassiska flervalsbenchmark inte. DeepEval ger dig mätvärden byggda specifikt för det här, som faithfulness (håller sig svaret till det hämtade underlaget) och answer relevancy (svarar modellen faktiskt på frågan som ställdes).

from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase

def test_rag_svar():
    test_case = LLMTestCase(
        input="Vad säger GDPR om lagringstid för supportärenden?",
        actual_output=modellens_svar,
        retrieval_context=hamtade_dokument,
    )
    faithfulness = FaithfulnessMetric(threshold=0.7)
    relevancy = AnswerRelevancyMetric(threshold=0.7)
    assert_test(test_case, [faithfulness, relevancy])

DeepEval körs som pytest, vilket gör det naturligt att lägga in i en CI-pipeline så att varje ändring i din prompt eller RAG-pipeline automatiskt kontrolleras mot regressioner innan den går till produktion. Utöver faithfulness och answer relevancy finns även ett hallucinationsmått som flaggar svar där modellen lägger till information som inte finns i det hämtade underlaget alls, vilket är särskilt värdefullt för supportbotar där ett påhittat svar om en returpolicy eller en felaktig prisuppgift kan bli kostsamt på riktigt.

Steg 9: Bygg ett eget nordiskt testset på svenska

Det här är steget de publika leaderboards aldrig gör åt dig, och det är ofta det mest värdefulla. Samla 30-50 verkliga exempel från din egen verksamhet: svenska supportärenden, interna policytexter, GDPR-scenarier, eller teknisk dokumentation med svensk terminologi. Spara dem som en enkel JSONL-fil så att de kan köras genom samma verktyg som standardbenchmarken.

{"id": 1, "prompt": "Förklara skillnaden mellan personuppgiftsansvarig och personuppgiftsbiträde enligt GDPR, på enkel svenska.", "reference": "Den personuppgiftsansvariga bestämmer syfte och medel..."}
{"id": 2, "prompt": "Skriv ett svar till en kund som fått fel faktura, håll tonen vänlig men tydlig.", "reference": null}

Håll testsetet hemligt, det vill säga inte publicerat någonstans på nätet, så att framtida modellversioner inte kan ha memorerat svaren. Separera också tydligt mellan utvecklingsexempel du använder för att finslipa din prompt och ett dolt testset du bara rör vid i slutändan, annars bygger du omedvetet in ett läckage som gör resultaten orealistiskt bra.

Tänk brett när du samlar in exempel. Blanda enkla frågor som alla moderna modeller borde klara med svårare gränsfall där du redan vet att vissa modeller brukar missa, till exempel sammansatta svenska ord, juridiska termer som skiljer sig från engelska motsvarigheter, eller frågor som kräver att modellen vågar svara “det vet jag inte” istället för att hitta på ett svar. Den sista kategorin, villighet att avstå från att gissa, är ofta viktigare för en produktionsapplikation än ett par extra procentenheter på ett allmänt kunskapstest, men det är nästan aldrig något en publik leaderboard mäter åt dig.

Steg 10: Kalibrera LLM-as-a-judge mot mänsklig bedömning

För öppna svar utan ett exakt rätt svar, som sammanfattningar eller supporttexter, behöver du en bedömare. Att använda en stark modell som domare, LLM-as-a-judge, är praktiskt men har kända snedvridningar: domarmodeller tenderar att gynna längre svar, en viss skrivstil, och ibland modeller från samma leverantör som domaren själv.

Ta ett slumpmässigt urval på 20-30 svar och låt en kollega bedöma dem manuellt utan att veta vilken modell som genererat vilket svar.
Jämför den manuella bedömningen mot domarmodellens poäng och räkna ut hur ofta de är oense.
Om oenigheten är hög, skriv om domarpromten med tydligare kriterier och testa igen innan du litar på den i stor skala.
Använd gärna två oberoende bedömningsmetoder, till exempel en regelbaserad kontroll plus en LLM-domare, och flagga fall där de inte är överens för manuell granskning.

Det här steget tar tid, men det är det som avgör om resten av benchmarket är trovärdigt eller bara ser ut att vara det.

Ett vanligt misstag är att låta samma modell som testas även agera domare över sitt eget svar, eller över en konkurrents svar, utan att inse att det ger en inbyggd fördel. Om du använder GPT-6.1 Sol som domare kommer den i genomsnitt att värdera svar som liknar dess egen skrivstil något högre, helt omedvetet. Ett sätt att minska den snedvridningen är att låta en modell som inte deltar i jämförelsen agera domare, eller att variera domarmodellen mellan körningar och se om rankningen håller sig stabil oavsett vem som dömer.

Skriv ner domarkriterierna explicit innan du kör, till exempel “ge full poäng endast om svaret är på svenska, nämner felkoden och är kortare än 100 ord”, istället för en vag instruktion som “bedöm om svaret är bra”. Vaga domarprompter är den enskilt vanligaste orsaken till att LLM-as-a-judge-resultat inte går att lita på, eftersom domaren då i praktiken får fritt spelrum att tolka vad “bra” betyder från fall till fall.

Steg 11: Hantera rate limits, kostnad och parallella körningar

API-leverantörer sätter oftast separata gränser för antal förfrågningar per minut och antal token per minut, och de två gränserna slår till oberoende av varandra. Kör du sex modeller parallellt mot ett testset på några hundra frågor kommer du med stor sannolikhet att träffa ett 429-fel, för många förfrågningar, förr eller senare. Bygg in återförsök med exponentiell backoff och jitter från början, istället för att lappa ihop det efter att en körning kraschat halvvägs.

import random
import time

def call_with_backoff(fn, max_retries=5):
    for attempt in range(max_retries):
        try:
            return fn()
        except RateLimitError:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
    raise RuntimeError("Gav upp efter upprepade 429-fel")

Spara varje enskilt råsvar till disk löpande, inte bara slutsammanställningen. Om körningen kraschar efter 400 av 500 frågor vill du kunna återuppta därifrån istället för att betala för och vänta på hela körningen igen. Separera också dina utvecklingskörningar, där du testar att konfigurationen fungerar, från de officiella körningarna vars resultat du faktiskt tänker rapportera, och cacha svar där det är säkert att göra det.

Tänk också på att parallellism är en avvägning, inte bara en hastighetsvinst. Kör du allt sekventiellt tar en svit med sex modeller och några hundra frågor lätt flera timmar, men kör du allt helt parallellt riskerar du att dränka API:et i förfrågningar och få fler fel än du vinner i tid. En rimlig startpunkt är fyra till åtta samtidiga förfrågningar per modell, och sedan justera uppåt eller nedåt beroende på hur många 429-fel du ser i loggarna under de första minuterna av körningen.

Håll också koll på det sammanlagda antalet anrop innan du trycker igång hela sviten. Multiplicera antal modeller gånger antal frågor gånger antal samplingar per fråga, lägg till domaranropen om du använder LLM-as-a-judge, och jämför det mot vad du faktiskt är beredd att betala. Det är betydligt billigare att upptäcka ett räknefel i den kalkylen innan körningen startar än efter att fakturan kommit.

Testa gärna frågorna på flera nordiska språk om din produkt används i mer än Sverige. Ett testset som bara innehåller svenska frågor missar att en modell som presterar bra på svenska inte automatiskt presterar lika bra på norska eller danska, och skillnaderna kan vara större än man tror, särskilt för mindre vanliga ord och sammansatta termer inom juridik eller teknik.

En sista detalj som ofta missas: logga alltid modellens svarstid tillsammans med poängen, inte bara i efterhand som en kuriositet. En modell som är två procentenheter bättre men tre gånger långsammare kan vara ett dåligt val för en kundtjänstbot där användaren väntar på svar i realtid, även om den vinner varje jämförelsetabell du bygger.

Steg 12-13: Logga, visualisera och tolka resultaten

Samla resultaten från alla delmoment, lm-evaluation-harness, promptfoo och DeepEval, i en gemensam CSV-fil med modell, uppgift, poäng, kostnad, latens och tidsstämpel. Det gör det enkelt att bygga en sammanfattande tabell eller ett enkelt diagram i efterhand, utan att behöva hoppa mellan tre olika verktygs egna rapportformat.

import pandas as pd

rows = []
for result_file in result_files:
    data = load_json(result_file)
    rows.append({
        "model": data["model"],
        "task": data["task"],
        "score": data["acc"],
        "stderr": data["acc_stderr"],
        "cost_sek": data["cost_sek"],
        "latency_ms": data["latency_ms"],
    })

df = pd.DataFrame(rows)
df.to_csv("results/summary.csv", index=False)
print(df.pivot(index="model", columns="task", values="score"))

När du tolkar tabellen, titta inte bara på vem som vann varje rad. Titta på standardfelet och fråga dig om skillnaden mellan den bästa och näst bästa modellen är större än felmarginalen. Titta också på kostnad per korrekt svar, inte bara kostnad per token, eftersom en billigare modell som behöver fler försök för att lösa samma uppgift kan sluta bli dyrare i praktiken.

Ett praktiskt sätt att undvika att övertolka små skillnader är att sätta en tröskel för “tillräckligt bra” innan du ser resultaten, inte efter. Bestäm till exempel i förväg att om två modeller ligger inom tre procentenheter av varandra på ditt nordiska testset räknas de som likvärdiga, och att valet då istället avgörs av pris, latens eller datalagring. Det skyddar dig mot att i efterhand hitta på en motivering för att välja den modell du redan innan testet hade en magkänsla för.

Vanliga fallgropar när du benchmarkar AI-modeller själv

Blanda inte modell med scaffold. En modell med verktygsåtkomst och en flerstegs-agentloop ska inte jämföras rakt av mot en modell som bara svarar direkt på en enda prompt, märk alltid upp vilken konfiguration resultatet gäller.
Lås temperatur och seed. Om du kör samma test två gånger och får olika poäng utan att ha ändrat något annat än att köra igen, har du troligen inte låst samplingsparametrarna.
Blanda inte modellversioner. “GPT-6.1 Sol” kan ha flera API-snapshots över tid, notera alltid exakt modell-id och datum, inte bara marknadsnamnet.
Underskatta inte promptkänslighet. Små ändringar i instruktionernas ordning eller i JSON- kontra fritextformat kan flytta resultatet flera procentenheter, kör därför samma promptmall konsekvent över alla modeller.
Glöm inte kontaminering. Ett mycket högt resultat på ett känt, publicerat benchmark kan spegla memorering snarare än verklig förmåga, komplettera alltid med ett eget, opublicerat testset.
Räkna inte bara automatiska mått. Regel- och exaktmatchning kan felaktigt underkänna ett semantiskt korrekt svar som bara är formulerat annorlunda, stickprovsgranska manuellt.
Dra inte slutsatser av för få exempel. En skillnad på 2 av 20 frågor låter dramatisk men ligger ofta inom slumpens marginal, räkna alltid standardfel innan du utropar en vinnare.

Felsökning: 8 vanliga problem och lösningar

Problem	Trolig orsak	Lösning
429-fel mitt i körningen	För hög parallellism mot leverantörens rate limit	Sänk batch-storlek och lägg till exponentiell backoff enligt steg 11
Resultat varierar mellan körningar	Temperatur eller seed är inte låst	Sätt temperatur till 0 eller ett fast seed för deterministiska test
Oväntat lågt resultat för en känd stark modell	Fel promptmall eller fel few-shot-format för just den modellen	Kontrollera modellens egen dokumentation för rekommenderat promptformat
DeepEval-testet kraschar med timeout	Domarmodellen svarar långsamt eller API-anropet saknar timeout	Höj timeout-värdet och lägg till återförsökslogik runt domaranropet
promptfoo visar tom matris	Fel providernamn eller saknad API-nyckel i miljövariabler	Kontrollera providernamnet mot promptfoos dokumentation och .env-filen
Kostnaden blir mycket högre än väntat	LLM-as-a-judge-anrop har inte räknats in i budgeten	Räkna domaranrop separat, de kan dubbla eller tredubbla totalkostnaden
Två körningar av samma test ger olika rankning	Litet testset ger stor varians mellan omgångar	Öka antalet testfall eller rapportera standardfel tillsammans med poängen
Modellen vägrar svara på vissa frågor	Inbyggda säkerhetsfilter blockerar prompten	Logga och klassificera blockerade svar separat istället för att räkna dem som fel

Avancerade tips för mer pålitliga benchmark

När grundkörningen fungerar finns det några steg till som höjer kvaliteten rejält. Kör varje stokastisk uppgift med flera samplingar, inte bara en, och rapportera medelvärde plus spridning snarare än ett enda tal. Det är särskilt viktigt för kreativa eller öppna uppgifter där en modell kan svara helt annorlunda andra gången även med samma prompt.

Bygg en liten “golden set”-mapp med 10-15 frågor där du själv skrivit det idealiska svaret, och använd den som en manuell sanity check varje gång du kör om hela sviten efter en modelluppdatering. Om en modell plötsligt presterar sämre på din golden set efter en leverantörs tysta uppdatering i bakgrunden, vet du direkt att något förändrats utan att behöva vänta på nästa fullskaliga körning.

Separera dessutom “råmodell”-resultat från “applikations”-resultat i din rapportering. En modells poäng utan verktyg säger något annat än samma modells poäng när den har tillgång till sökverktyg, kodkörning eller din interna dokumentation via RAG. Blanda aldrig dessa två i samma tabell utan tydlig märkning, det är en av de vanligaste källorna till missvisande jämförelser i publika rapporter.

Ett ofta förbisett tips är att bygga in en enkel regressionslarm i din pipeline. Spara undan resultatet från din golden set varje gång du kör om benchmarket, och skriv ett litet skript som jämför senaste körningen mot den förra. Om en modells poäng faller mer än, säg, fem procentenheter mellan två körningar utan att du ändrat något i din egen konfiguration, är det ett tecken på att leverantören bytt modellversion bakom kulisserna, och värt att undersöka innan du litar på resultatet i ett beslut.

Slutligen, var ärlig med dig själv om vad ditt benchmark kan och inte kan svara på. Ett egenbyggt test med femtio frågor på svenska ger dig en bra indikation för din specifika uppgift, men det är inte en vetenskaplig studie och bör inte presenteras som en generell sanning om vilken modell som är “bäst”. Formulera slutsatserna som “för vårt kundtjänstflöde presterade modell X bäst givet vår budget”, inte som en universell rankning.

Komplett projekt: filstruktur och nästa steg

Så här ser den färdiga projektstrukturen ut när alla steg i guiden är genomförda. Spara den som en mall du kan återanvända varje gång en ny modellgeneration släpps.

llm-benchmark/
├── .env
├── .gitignore
├── data/
│   └── nordiskt_testset.jsonl
├── configs/
│   └── support-sv.yaml
├── scripts/
│   ├── run_mmlu_pro.sh
│   ├── run_humaneval.sh
│   ├── rag_eval.py
│   └── summarize_results.py
├── results/
│   ├── mmlu_pro_gpt6_1_sol.json
│   ├── mmlu_pro_claude_opus_5_5.json
│   └── summary.csv
└── README.md

Checka in allt utom .env och de råa svarsfilerna i git, så att konfigurationen och testsetet är versionerade även om du byter dator. Nästa gång en ny modellgeneration dyker upp, GPT-7, Claude Opus 6 eller vad det nu blir, behöver du bara lägga till en ny rad i modellistan och köra om samma skript. Det är hela poängen med att bygga detta en gång ordentligt istället för att testa manuellt i en chatt varje gång en ny version släpps.

Varje mapp har ett tydligt syfte som gör det enkelt för en kollega att plocka upp projektet senare. data/ innehåller ditt hemliga, versionerade nordiska testset separat från allmänna benchmarksviter som laddas ner av verktygen själva. configs/ samlar alla promptfoo-konfigurationer, en per användningsfall, så att du kan köra bara kundtjänsttestet eller bara kodtestet utan att starta om allt. scripts/ innehåller de upprepningsbara kommandona från varje steg i den här guiden, skrivna som körbara filer istället för kommandon du måste komma ihåg att skriva för hand varje gång. results/ är den enda mappen som växer okontrollerat över tid, så lägg till en enkel städrutin som arkiverar gamla körningar efter några månader.

Lägg till en kort README med datum för senaste fullskaliga körning, vilka modell-id:n som testades, och en länk till sammanfattningstabellen. Det låter kommande dig, eller en kollega, snabbt se om benchmarket börjar bli för gammalt för att lita på, särskilt i en bransch där en ny modellgeneration kan dyka upp redan efter några veckor.

Vanliga frågor om att bygga ett eget LLM-benchmark

Behöver jag betala för API-åtkomst till alla modeller jag vill testa?

Ja, för de stängda modellerna som GPT-6.1 Sol, Claude Opus 5.5 och Gemini 4 Argon betalar du per token via leverantörens API. Öppna modeller som Mistral Large 4, DeepSeek V4.1-Flash och GLM-5.3 kan antingen köras via en hostad API-tjänst mot en avgift, eller lokalt om du har tillräcklig hårdvara, vilket tar bort löpande API-kostnad men kräver egen infrastruktur.

Hur stort testset behöver jag för ett trovärdigt resultat?

Det beror på uppgiften, men för ett eget nordiskt testset är 30-50 noggrant utvalda exempel ofta nog för att upptäcka tydliga skillnader mellan modeller. För att med säkerhet kunna säga att en liten skillnad på en eller två procentenheter är verklig snarare än brus behöver du betydligt fler exempel, vilket är varför standardfel är viktigt att rapportera tillsammans med poängen.

Kan jag använda samma benchmark för både chattmodeller och agenter?

Delvis. Grundsviterna som MMLU-Pro och HumanEval testar en modells rena förmåga utan verktyg. För agenter som använder sökning, kodkörning eller API-anrop behöver du komplettera med agentspecifika test, till exempel genom DeepEval:s agentmått eller ett eget scenariobaserat test som mäter om agenten faktiskt löser en flerstegsuppgift, inte bara om den svarar rätt på en enskild fråga.

Varför skiljer sig mitt resultat från det jag ser på publika leaderboards?

Det är väntat och faktiskt poängen. Publika leaderboards använder oftast andra promptmallar, andra few-shot-inställningar och ibland andra modell-snapshots än den du har åtkomst till via ditt API. Ditt eget resultat speglar din konfiguration, vilket är mer relevant för ditt beslut än en siffra optimerad för en generell leaderboard.

Hur ofta bör jag köra om hela benchmarket?

Kör om den fullständiga sviten varje gång en modell du använder i produktion får en ny major-version, och använd din golden set som ett snabbtest vid mindre uppdateringar. Många leverantörer uppdaterar sina modeller tyst bakom samma modellnamn, så en regelbunden lättviktskontroll, till exempel månadsvis, fångar upp oväntade prestandaförändringar innan de märks hos dina användare. Sätt gärna ett kalenderpåminnelse snarare än att lita på att du kommer ihåg det, eftersom det är lätt att skjuta upp en omkörning som “inte är akut” tills en kund faktiskt klagar på sämre svar.

Är lm-evaluation-harness och promptfoo samma typ av verktyg?

Nej, de kompletterar varandra. lm-evaluation-harness är starkast på etablerade, akademiska benchmarksviter med fasta facit, sådant som MMLU och GPQA där svaret alltid är rätt eller fel. promptfoo är byggt för att snabbt jämföra flera modeller och prompter mot dina egna, ofta öppna, testfall och ger dig ett visuellt gränssnitt för att granska svaren manuellt. I praktiken brukar de flesta team som bygger ett eget benchmark använda båda: lm-evaluation-harness för de etablerade sviterna och promptfoo för de affärsspecifika testen, med DeepEval som ett tredje lager för RAG- och agentmätvärden som inte täcks av någon av de andra två.

Finns det färdiga alternativ om jag inte vill bygga allt själv?

Ja. HELM från Stanford CRFM erbjuder breda, redan konfigurerade utvärderingar, OpenAI Evals ger ett ramverk för att definiera egna dataset och graderare, och Hugging Face Open LLM Leaderboard ger en snabb överblick över öppna modeller. Det finns också agentfokuserade ramverk som Inspect AI, utvecklat med stöd från brittiska myndigheter för säkerhets- och kapacitetsutvärdering av mer autonoma system, samt Ragas som fokuserar specifikt på RAG-mätvärden om du redan har en pipeline och bara vill lägga till utvärdering ovanpå den. Inget av dem ersätter ett eget, hemligt testset på din egen data, men de är bra komplement för att orientera dig innan du bygger vidare.