Data engineering / AI & sökrelevans
Jag bygger med data — och undersöker vad "bäst" egentligen betyder.
Två projekt, samma fråga: hur hittar man ett rättvist svar i en stor mängd data — rätt dokument bland tusentals, eller rätt förare bland decennier av F1-resultat?
Examensarbete · med Casper Zanichelli · 2026
Retrieval Evaluation — när slår hybridsökning både nyckelord och semantik?
Ett exjobb om att mäta sökkvalitet på riktigt: vi byggde tre typer av sökmotorer ovanpå samma vektordatabas — klassisk textsökning, semantisk sökning och hybrider mellan dem — och benchmarkade dem enligt BEIR-ramverket för att se vilken metod som faktiskt hittar rätt dokument, och hur högt upp den rankar det.
Frågan
Innan en sökmotor eller RAG-modell kan svara på något måste den hämta rätt underlag ur en databas. Men vilken hämtningsmetod ska man lita på — snabb nyckelordssökning, semantisk sökning, eller en blandning? Vi utvärderade det systematiskt på SciFact och TREC-COVID (BEIR-dataset med färdiga svarsfacit), istället för att gissa.
Viktkurvan — huvudresultatet
Vi vägde samman semantisk sökning och textsökning med Reciprocal Rank Fusion, från 100 % text (vikt 0) till 100 % semantik (vikt 1). Vore hybriden bara ett genomsnitt skulle kurvan vara rak. Det är den inte:
Kurvan är ett uppochnervänt U på båda dataseten, med topp vid vikt 0,75 — inte vid någon av ändpunkterna. Det är det starkaste beviset för att textsökning och semantisk sökning hittar delvis olika relevanta dokument, så att kombinera dem slår båda ensamma.
nDCG@10 på SciFact. Samma mönster på TREC-COVID: 0,601 (text) → 0,748 (semantik) → 0,787 (hybrid, vikt 0,75).
Snabbt vs. bra — det finns ett pris
Hybriden vinner på rankingkvalitet, men inte gratis: den kör både text- och semantisk sökning och slår sedan ihop resultatet, vilket kostar tid.
Ren text svarar på ~49 ms men landar lägst i kvalitet. Hybriden med 75 % semantisk vikt kostar ~527 ms — långsammare än ren semantik, men med bäst nDCG av alla fem. Vilken avvägning som är rätt beror på om produkten tål halvsekundslatens.
Varför fungerar hybriden — query för query
Genomsnitt döljer att metoderna faktiskt är oense. Fråga för fråga ser det ut så här:
På 35 av 300 frågor i SciFact — och 12 av 50 i TREC-COVID — vann den "sämre" metoden, ren textsökning. Om metoderna hittade exakt samma dokument skulle alla punkter ligga på samma diagonal och en hybrid vore meningslös. Att de sprider sig är just varför fusionen fungerar.
En fälla i måtten
På TREC-COVID ligger recall@10 nere på ~0,02 för alla metoder — ser ut som ett misslyckande, men datasetet har i snitt ~493 relevanta dokument per fråga, så max möjliga på tio platser är just 10/493 ≈ 0,02. Rätt mått för rätt dataset, inte samma checklista överallt.
Sidoprojekt · Streamlit-app · 2026
Race Pulse — det enda rättvisa sättet att jämföra F1-förare
Bilarna skiljer sig enormt mellan F1-stallen, så en förare i en toppbil går inte att jämföra rakt av med en i en bottenbil. Den enda som kör exakt samma bil är stallkamraten — det är vad Race Pulse mäter, säsong för säsong och genom hela F1:s regelhistoria.
Hur jämförelsen räknas
All logik ligger separat från gränssnittet (i f1_data.py) och följer tre regler för att jämförelsen ska vara rättvis:
| Mått | Regel |
|---|---|
| Kval-H2H | Räknas bara ronder där båda förarna satte en kvaltid. |
| Lopp-H2H | Räknas bara ronder där båda blev klassificerade i mål — en förare straffas alltså inte för att stallkamraten fick motorhaveri. |
| Poäng | Summeras över hela säsongen, oavsett klassificering. |
| Median kvalgap | Medianen av skillnaden i kvalplacering. Negativt tal = föraren var i snitt snabbare. |
Två vyer
Säsongsvyn visar H2H, poäng och median-kvalgap för en vald säsong. Karriärvyn grupperar hela karriären efter reglemente-era — V8, turbo-hybrid, ground effect — så man ser formen över flera regelperioder, inte bara en säsong.
Data
Hämtas live och cachas från Jolpica-F1, den öppna efterföljaren till Ergast-API:t. Ingen API-nyckel krävs.