I weekenden udkom en teknisk guide, der faktisk kan bruges. Part 13 — Design the Recommender System på Towards AI går hele vejen fra mål til skema: fra forretningskrav til latency-budget. Stramt skåret, jordnær — og vigtigst: den binder arkitekturvalg sammen med drift, evaluering og de fejl, der vælter prototyper i produktion.
Kort fortalt beskriver guiden et end-to-end design af et skalerbart anbefalingssystem. Ikke som en pæn figur, men med konkrete valg: ranking over klassifikation, retrieval før ranking, tidsbaserede datasplit, negative samples, feature stores for at undgå training-serving skew, Recall@K og NDCG@K som faste målepunkter og en live pipeline, der sigter mod ca. 200 ms. Rammen er klar, selv om der er ubesvarede spørgsmål om fx hardware og QPS.
Hvad artiklen hævder
Guiden, skrevet af Utkarsh Mittal og udgivet via Towards AI, er senest opdateret 22. juni 2026. Den er Part 13 i en serie og linker tilbage til Part 12. Hovedpointen: reelle forretningsmål kan sjældent labels direkte; derfor optimerer man på proxy-signaler i en ranking-opsætning — ikke via en simpel ja-nej klassifikation.
Derudover argumenterer den for en totrins-arkitektur, hvor en hurtig retrievalfase skærer kandidatlisten ned, før en rigere ranking-model arbejder. Den dækker cold-start og sparsitet, beskriver konstruktion af labels og negatives, anbefaler tidsbaserede splits for at undgå lækage, og peger på feature stores for at holde træning og serving i sync. På modelsiden nævnes to-tower retrieval med dot-produkt og softmax-træning, baseline-ranking med fx LightGBM og brede-dybe modeller samt kalibrering og eventuelt multi-task.
Hvorfor ranking og proxy-signaler
Forretningsmål som fastholdelse eller livstidsværdi kan ikke gøres sande eller falske på en enkelt visning. Derfor er klassifikation sjældent det rigtige centrum. Ranking er. Man sætter kandidater op mod hinanden og optimerer placering, ofte ud fra klik, konvertering eller tid brugt — signaler, der allerede findes i logs.
Prisen er bias i proxyerne. Klik kan belønne clickbait; tid på side kan straffe hurtige beslutninger; konverteringer er sparsomme. Artiklen anerkender skævhederne og holder fokus på at gøre det målbart nu, med kalibrering mod forretnings-KPI’er og løbende online-tests. Fornuftigt — men det kræver disciplin i eksperimenterne.
Totrinsarkitektur med retrieval og ranking
Skala bider. Med et katalog i hundredtusinder eller millioner kan man ikke rangere alt for hver forespørgsel. Retrieval henter de ~200–1000 mest lovende kandidater på 5–30 ms, typisk via approximate nearest neighbor-søgning eller to-tower embeddings. Først derefter bruger man 50–120 ms på en tungere ranker, der læser flere features og kontekst.
Latencymatematikken er enkel og ubøjelig. Har du 200 ms end-to-end på p99, og frontend + netværk tager 40–60 ms, er der måske 120–140 ms tilbage. Det skal række til retrieval, feature-lag, ranking — plus margin. Så bliver prækomputation, caching og tidlige aborts ikke nice-to-have, men nødvendige for at holde SLO’er.
Data og træning med cold-start og sparsitet
Cold-start er ikke kun nye brugere eller produkter — også nye kontekster, kampagner og sæsonskift. Artiklen lægger op til at udnytte indholdsbaserede features og simple popularitetspriors i retrieval som værn mod nul-data-situationer. Praktisk oversat: lever noget fornuftigt fra første visning.
Negativesampling bruges til at lære, hvad brugeren ikke valgte. Her advarer guiden mod lækage og anbefaler tidsbaserede splits, så fremtidsinformation ikke siver ind. Overses ofte, især når batch-jobs genbruges uden låste timestamps. Tidslåste features og labels samt auditbare datasnaps er vejen ud.
Feature stores og risikoen for skew
Training-serving skew er en stille dræber. Et feature beregnet med en SQL-udvidelse i batch og en hurtig Python-beregning i serving kan ligne hinanden — og alligevel afvige nok til at flytte metrikker. Artiklen peger på feature stores som mekanisme for konsistens og versionering, både batch og realtid.
Minimumskravene er nøgterne: versionering af feature-definitioner, historiske backfills, realtidsberegning hvor det er kritisk og tydelige kontrakter for skema og datatyper. Rest-risikoen består, så overvågning af feature-drift skal være førstegangsborger — ikke efterslæb.
Rankingmodeller og kalibrering
Som baseline nævnes gradient-boostede træer, fx LightGBM: hurtig iteration, rimelig forklarlighed og stærk performance på tabulære features. Ovenpå kan brede-dybe modeller kombinere memorisering og generalisering. To-tower-arkitekturen hører hjemme i retrieval, hvor dot-produkt og softmax-træning passer godt til ANN-søgning.
Det vigtige greb er kalibrering af sandsynligheder, så offline-målinger holder vand, og eventuelt multi-task, hvis forretningsmål konflikter. Uden kalibrering kan CTR stige uden, at konvertering følger med. Her bliver kalibrering limen mellem modelscore og forretning.
Evaluering med Recall@K og NDCG@K
Retrieval måles fornuftigt med Recall@K — kommer det rigtige item med i kandidatlisten? Ranking evalueres bedre med NDCG@K, fordi placering vægtes. Guiden insisterer på error slicing: nye brugere, lav aktivitet, bestemte kategorier eller sprog. De slices afslører fejl, en samlet NDCG kan skjule.
Praktisk note: mål både offline og online, og forvent uenighed. Offline-gevinst garanterer ikke online-løft, især ved datadrift. Derfor er pipeline-stabilitet og hyppige, små eksperimenter bedre end sjældne, store skift. Billigere end en uges mørklægning og rollback.
Live pipeline og et 200 ms budget
Guiden beskriver en live-kæde, der skal lande omkring 200 ms. Tidsforbruget går på kandidatgenerering, featureindhentning, rangering — plus netværk, serialisering, logging. For at holde budgettet nævnes kvantisering af modeller, micro-batching hvor det giver mening, smart caching af både features og resultater samt fallbacks, hvis noget sander til.
Shadow mode får særbehandling: nye modeller ser trafikken og logger beslutninger uden at påvirke brugerne. Lav risiko, højere driftsomkostning. Dobbelt inference visse steder, ekstra storage, og krav til dataintegritet. Svært at argumentere imod, hvis man vil undgå blindflugt ved større releases.
Online evaluering og sikker eksperimentering
A\/B-bucketing er standard: stabil tildeling, lækagesikring mellem varianter og nok trafik pr. bucket til meningsfuld statistik. Interleaving er et nyttigt supplement i ranking-domæner: to lister blandes, og man får hurtigere præferencesignal uden en fuld A\/B-cyklus. Ikke altid smukt for UX, men effektivt ved korte beslutningssløjfer.
Faldgruberne er kendte: heterogen trafik, ændrede brugerflows midt i testen og events, der ikke er eksklusivt knyttet til en variant. Artiklen peger på klare stopkriterier, låste logs og forregistrering af hypoteser. Mindre fristelse til p-hacking i travle teams.
Systemrot i praksis
Guiden peger på fire måder, et recommender-system forfalder på: monitoreringshuller (features drysser fra, kilder tørrer ud), popularitets-spiraler (vindere vinder, kvalitet stagnerer), offline–online-mismatch (offline-gevinst flytter ikke online-KPI’er) og — igen — training-serving skew.
Operationelt oversat: mål feature-freshness, distributionsdrift, coverage på nye items og fairness-slices. Indfør popularitetsdæmpning eller eksploration, så listen ikke låser sig til gårsdagens topscorere. Kør løbende små eksperimenter, så skævheder ikke vokser i skyggen. Ikke glamourøst, men det forlænger systemets halveringstid.
Konsekvenser for projekter og roadmap
Følger man guiden, flytter det prioriteringen. Feature store, realtime-features og tidsbaserede splits først — før man forelsker sig i en avanceret ranker. Byg en robust retrieval-pipeline (fx two-tower med ANN-indeks), og investér i en dyrere ranking-stage, når kandidaterne er trimmet. Omkostningsbilledet følger med: ANN-indeks og cache-lag giver flere millisekunder pr. krone end endnu en større model.
Evaluering rykker fra månedlige rapporter til kontinuerlige dashboards. Recall@K og NDCG@K bliver baseline, med slices for cold-start og lav aktivitet. Eksperimentplatform og stabil bucketing er en tidlig investering. Og latency-SLO’er bør være formelle — ikke et tal i en slide, men en kontrakt, der styrer designvalg.
Hvad mangler og hvad bør verificeres
Nogle huller skal lukkes, før anbefalingerne flyttes direkte ind i en produktionsplan. Forfatterkrediteringen viser både “Editorial Team” og “Author(s): Utkarsh Mittal” — fint at få bekræftet, hvis man vil citere formelt. Serienoterne peger på Part 12 som forløber, hvilket underbygger, at Part 13 er del af en større helhed.
Den tekniske del mangler parametre. 200 ms-budgettet er rimeligt, men uden hardwareprofil, QPS, batchstørrelser og modelstørrelser er det svært at overføre direkte på tværs af miljøer. Two-tower-træning beskrives med dot-produkt og softmax, men uden detaljer om negative-sampling-strategi og hyperparametre. Det samme gælder feature store-realisering: ingen specifikke produktvalg — teams må vælge mønster og værktøj selv.
Praktisk betydning for workflows
Oversat til praksis betyder guiden, at dataplatform og MLOps ikke kan være halehæng. Uden versionerede features, tidslåste labels og reproducerbare træningsjobs får man hverken audits eller sikre rollback-stier. Eksperimenter kræver stabil bucketing og logning fra dag ét — ellers drukner sammenligninger i støj.
På driftssiden bør inference-laget behandles som et produkt i sig selv. Kvantisering og batching skal ind i CI\/CD — ikke være et manuelt efterspil. Caching-lag til både features og resultater skal have klare invalidationsregler. Og shadow-mode-kørsler skal have en datakontrakt, så de ikke forurener online-metrics eller bryder privacy-regler.
Så hvad gør man nu
Skriv jeres latency-SLO ned — ikke et mål, en SLO. Fordel budgettet pr. stage. Byg en simpel, robust retrieval først, gerne two-tower med ANN-indeks. Hold ranking-baseline nede på noget som LightGBM, mens I lærer data og driftsmønstre at kende. Kalibrer. Og mål Recall@K og NDCG@K med et par velvalgte slices.
Dernæst: tidsbaserede splits i alle offline-evalueringer, konsistente negatives og en feature store-løsning, der kan versionere definitioner og levere realtidsfeatures, hvor det er kritisk. Indfør shadow mode for nye modeller, og hold fast i små, sikre eksperimenter. Det er her, forskellen mærkes i drift.
