Ett auktionshus lägger ut några hundra nya objekt i veckan. Beskrivningarna är korta, kategorierna slarviga, och det enda sättet att hitta något intressant är att bläddra igenom allt.
Så jag byggde något som gör det åt mig: hämtar objekten, kategoriserar dem, tittar på bilderna, översätter det som är på engelska och gissar vad saken är värd. Fyra olika AI-uppgifter i en kedja — och det mest lärorika var när den slutade fungera utan att sluta rapportera framgång.
Olika modeller för olika jobb
Det första man vill göra är att välja ”den bästa modellen” och skicka allt dit. Det är fel av två skäl: den bästa modellen är långsammast, och de olika stegen är olika svåra.
Kategorisering, bildanalys och översättning är rutinuppgifter — en medelstor multimodal modell klarar dem snabbt och billigt. Att resonera om marknadsvärde är något annat: det kräver bredare kunskap om vad saker faktiskt säljs för, och där går en betydligt större modell in trots att den tar längre tid per objekt.
Fördelningen är inte en optimering man gör i efterhand. Den är designen.
Uppgraderingen som tystade allt
Här kommer historien som är värd hela inlägget.
Jag bytte bildanalysmodellen mot en nyare och bättre. Det är den sortens ändring man gör på en rad, känner sig nöjd med, och går vidare från.
Nästa genomkörning: 680 av 720 objekt fick ”timeout, hoppar över”.
Orsaken var trivial när den väl syntes. Varje bild hade en tidsbudget på trettio sekunder, satt efter den gamla modellen. Uppmätt efteråt: den gamla tog omkring fem sekunder per bild, den nya omkring trettiosju. Alltså sju gånger långsammare — och strax över gränsen.
Det obehagliga är inte att den var långsam. Det är att ingenting gick sönder. Jobbet startade, körde igenom hela listan, hoppade över nästan varje objekt och avslutades snyggt. Loggen fylldes av rader som var för sig såg ut som normal felhantering. Ur systemets perspektiv fungerade allt.
Läxan generaliserar långt utanför auktioner: när du byter modell byter du hela prestandaprofilen, och varje timeout som är avstämd mot den gamla blir ett tyst filter. En modelluppgradering är inte en konfigurationsändring — den är en kapacitetsändring, och ska mätas som en sådan innan den släpps.
Det finns dessutom en obekväm följdfråga. Om systemet kan hoppa över 94 procent av sitt arbete utan att någon märker det — hur mycket av det arbetet behövdes egentligen? Den frågan tog längre tid att skaka av sig än buggen tog att fixa.
Var, och hur, är två olika frågor
En senare funktion var att frilägga objektet på bilden — få bort auktionshusets bord, golv och kartonger så att listvyerna blir läsbara.
Den självklara ansatsen är att be en stor bildmodell göra hela jobbet. Jag delade i stället upp det: den multimodala modellen får svara på var objektet finns — en ruta i bilden — och ett litet specialiserat verktyg får svara på hur kanten ska klippas, med mjuka övergångar kring hår, glas och skuggor.
Uppdelningen gav två fördelar. Den räcker för de allra flesta objekten, och den slapp en tung segmenteringsmodell som hade behövt en egen server. En generell modell som pekar och ett specialverktyg som utför är ofta både billigare och bättre än en stor modell som gör allt.
Två minuter som såg ut som ett trasigt system
En driftdetalj värd att spara: efter att bibliotek för bildbehandling lagts till tog tjänsten två minuter att starta i stället för en sekund. Under den tiden svarade den med fel, och det såg ut som att hela driftsättningen misslyckats.
Orsaken var att biblioteket gjorde tung initiering redan vid import — innan något ens använt det. Fixen var att importera det först när funktionen faktiskt anropas. Starttiden gick tillbaka till en sekund, och kostnaden flyttades till första användningen, där den hör hemma.
Det är en generell fälla i AI-relaterade beroenden: de laddar modeller och kompilerar saker vid import. Ett program som startar långsamt är inte bara irriterande — det ser ut som ett trasigt program för allt som hälsokontrollerar det.
Så vet du att det funkar
Räkna det som lyckades, inte det som misslyckades. Ett jobb ska rapportera ”412 av 720 objekt behandlade” — inte ”klart”. Hade den siffran funnits hade timeout-problemet upptäckts samma kväll i stället för veckor senare.
Mät tiden per anrop och spara den. Det gör en modelluppgradering till en jämförelse i stället för en känsla.
Titta på utfallet med egna ögon. Slumpa fram tio objekt och läs vad modellen skrivit om dem. Kategoriseringar som är fel på ett systematiskt sätt syns aldrig i statistiken — bara i texten.
Vad jag tar med mig
Nyare är inte snabbare. Vi är vana vid att en uppgradering gör saker bättre på alla sätt. För modeller gäller det inte — bättre svar och längre tid är ofta samma sak, och det är en avvägning man måste göra medvetet.
Ett skippat objekt måste synas. Felhantering som är för snäll döljer att systemet inte gör sitt jobb. ”Hoppar över” ska räknas, summeras och rapporteras — annars är det inte felhantering, det är förnekelse med loggutskrift.