Krönika
← Tillbaka till bloggen

Bruce Lee, Tesla och Trav

Vad Teslas beslut att droppa LiDAR, Bruce Lees träningsfilosofi och svensk trav har gemensamt — och vad det betyder för prediktionsmodeller.

17 april 2026 Krönika Maskininlärning Feature Engineering
Bruce Lee, en Tesla, en sensortäckt skrotbil och en travhäst — artikelns tre trådar

Det dök nyligen upp en tweet om autonoma fordon — Tesla mot Waymo — som visade sig handla om något mycket större. Något som gäller för alla prediktionsmodeller som någonsin byggts. Inklusive min, V85Modellen.

Argumentet bygger på Rich Suttons bitter lesson: att generella metoder som skalar med beräkningskraft konsekvent slår handbyggda arkitekturer. Tesla droppade radar, sedan ultraljudssensorer, och gick helt end-to-end — en enda inmatningstyp, inlärd direkt från råa kamerabilder utan handbyggda mellansteg. Deras förmåga att hantera svåra situationer accelererade efter förenklingen, inte före. Waymo gick åt andra hållet: LiDAR, radar, kameror och ett handkodat fusionslager för att samordna dem. De sitter fortfarande fast i geografiskt avgränsade zoner.

Min första reaktion var den uppenbara: Tesla använder inte en enda feature. Det stämmer. Men det missar poängen.

Waymos LiDAR är genuint starka data. Förmodligen bättre än kamera i svagt ljus och regn. Nära verklig mänsklig syn i rumslig precision. Problemet är inte sensorn. Problemet är vad det kostar att behålla den vid sidan av allt annat.

Varje ytterligare modalitet adderar kalibrering, tidssynkronisering, konflikthantering och ett fusionslager av handskriven logik för när sensorerna inte är överens. Det fusionslagret skalar inte med beräkningskraft. Det skalar med ingenjörstimmar. Man sätter ett tak på vad teamet kan resonera kring explicit.

Att droppa radar innebar inte att förlora det radar kunde mäta. Det innebar att tvinga visionssystemet att lära sig det i stället. Lärande skalar. Ingenjörstimmar gör det inte.


Ett slag, tiotusen gånger

Bruce Lee sa en gång att han fruktade den man som hade övat ett slag tiotusen gånger mer än den som kunde tiotusen slag men bara övat vart och ett en handfull gånger.

Det är samma insikt från en annan vinkel.

Teslas end-to-end-vision är det enda slaget. Inte en feature — en inmatningstyp, tränad i en skala ingen annan matchat. Modellen upptäcker hundratals features inuti den inmatningen: djup, hastighet, skymda objekt, hur skuggor skiftar innan ett hinder dyker upp. Den hittar dem genom repetition, inte genom ingenjörsarbete.

Waymo är mannen som kan tiotusen slag. LiDAR säger det här, radar säger det där, regel 4 847 hanterar specialfallet när de inte är överens i regn i en vänstersväng. Varje slag är rimligt. Men repetitionerna är utspridda, och taket är det ingenjörerna bestämde sig för att koda in.


Applicera det på trav

En prediktionsmodell har en pipeline. Min ser ungefär ut så här:

Träning → Scoring → Viktjustering → Kupongoptimering

Det sista steget — kupongbygge, budgetvillkor, spikval — är irreducerbart. Det är ett kombinatoriskt optimeringsproblem. Ingen mängd träningsdata får det att försvinna.

Det tredje steget är mer intressant. Efter scoring blandar jag in signaler som anlände efter att träningen stängdes: oddsrörelser, streckfördelning, sena kuskbyten. Den blandningslogiken är handskriven. Den förbättras inte med data. Den förbättras med mitt resonemang, vilket innebär att varje specialfall jag inte tänkt på är en blind fläck. Den renare arkitekturen är att låta de signalerna komma in vid scoringtillfället som features, så att modellen lär sig deras relation till utfall direkt från loppen.

Men båda de stegen är nedströmsproblem.

Det steg som spelar mest roll är steg ett.


Beslutet innan modellen börjar

Feature-urval är det beslut som fattas innan modellen börjar.

Allt nedströms — scoringens träffsäkerhet, viktjusteringar, kupongkvalitet — begränsas av vad man låter modellen se under träning. En svag feature-uppsättning är ett tak man bygger innan första träningskörningen. Och man kommer aldrig att se vad modellen kunde ha lärt sig av något man valde att exkludera.

Man kan bara inkludera features man kan mäta. Det ger redan en slagsida mot det som har spårats historiskt, det som är enkelt att extrahera, det som passar in i en rad. Det som faktiskt avgör lopp — hur en häst tog sig genom fältet, en kusks trygghet på en specifik bana, hur ett stalls form cyklar — är ofta osynligt. Man bygger kring det man har och behandlar det som signal för att det är allt man har.

Sedan börjar features kalcifieras. Något korrelerar i en tidig version. Det får vikt. Modellen lär sig att kompensera för det på andra ställen. Tre versioner senare går det inte att ta bort det rent, för allt runtomkring har anpassat sig efter det. Det var inte nödvändigtvis bra signal. Men det är strukturellt nu — en vårta på taket som ingen planerade och som ingen enkelt kan ta bort.

Det är så teknisk skuld ackumuleras i en modell. Ingen lägger dit den med flit. Den växer.


Vi är inte ensamma om det här

Jag vet det här för att jag har levt det. Och det visar sig att nästan alla andra som bygger i det här området har gjort det också.

Under de senaste månaderna har jag haft kontakt med ett antal utvecklare som arbetar med liknande problem inom trav och hästspelsprediktion i bredare mening. Olika angreppssätt, liknande utmaningar. Vissa har tillgång till enorm beräkningskapacitet. Andra har metodiskt samlat på sig över tio års ren historisk data — en ackumulerande fördel som är nästan omöjlig att replikera snabbt. Andra har avfärdat vissa features som irrelevanta, bara för att tyst ompröva dem en eller två modellversioner senare. Jag har gjort samma sak.

Jag vill tacka dem för deras öppenhet och transparens. De här samtalen sker inte tillräckligt ofta i en bransch där alla i slutändan konkurrerar om samma pool av pengar. Men i slutändan behöver vi alla lära av varandra för att vinna. Problemen vi var och en brottas med är mer lika varandra än de olika arkitekturerna antyder.


Börja från noll

Frågan jag ständigt kommer tillbaka till är enkel: vad skulle jag inkludera om jag byggde feature-uppsättningen från grunden idag, utan arv?

Inte det jag har. Inte det jag alltid har använt. Inte det som alltid har funnits tillgängligt. Vad skulle jag faktiskt välja, med vetskapen om vilka signaler som visat sig vara meningsfulla över tusentals lopp?

Det ärliga svaret är att en del av det som finns i den nuvarande modellen troligen inte borde vara kvar. Features som var rimliga i v1, när data var tunnare och modellen behövde all hjälp den kunde få, har kanske inte förtjänat sin plats sedan dess.

Tesla ställde samma fråga om radar. Svaret kostade dem en sensor som var genuint användbar. Men det gav dem ett system som kunde lära sig allt den sensorn visste, och mer, utan ett tak på hur bra det kunde bli.

Bruce Lees slag har fortfarande mekanik. Han bara övade tills den var osynlig.

Målet är inte färre features. Det är att varje feature har förtjänat sin plats.