Den enklare AI-pipelinen vinner oftast

Varje AI-automationsprojekt får förr eller senare ett ögonblick då någon föreslår ett steg till. En scraper för att hämta mer källdata. En andra modell som kontrollerar den första modellens svar. Ett regelsystem som fångar de kanter modellen missar. Varje steg låter rimligt för sig.

Vi nådde det ögonblicket i ett projekt tidigare i år, och gjorde tvärtom. Vi tog bort steg.

Pipelinen som redan var “klar”

Den ursprungliga designen hämtade data från flera källor, körde den genom en scraper, kedjade ihop flera bearbetningssteg och lämnade sedan resultatet till en modell. Den fungerade. Men den gick sönder på sätt som var svåra att felsöka. En källwebbplats ändrade layout, ett steg fick timeout, ett mellanformat stämde inte med vad nästa steg förväntade sig. Varje fel såg annorlunda ut, och varje fel krävde sin egen lagning.

Vi ersatte hela kedjan med ett anrop till en enda modell, med rätt indata och en väl skriven prompt. Samma kvalitet på resultatet. En bråkdel av det som kan gå fel.

Varför den komplexa versionen byggs ändå

Ingen sätter sig ner och bygger något skört med flit. Den flerstegiga versionen uppstår för att varje tillägg är lokalt motiverat: “modellen kanske missar det här, så vi lägger till en kontroll” eller “vi borde verifiera mot en andra källa, bara för säkerhets skull”. Varje beslut går att försvara på egen hand. Staplade på varandra får man ett system där ingen längre kan förklara helheten, och där felsökning betyder att man spårar genom fem komponenter i stället för en.

Moderna modeller klarar också mer än vad många pipelines utgår från. En väl avgränsad prompt med bra kontext ersätter ofta två eller tre av de “stödjande” stegen, som byggdes på för att kompensera för en tidigare, svagare modell.

Frågan som ska komma före varje nytt steg

Innan du lägger till ett steg i en AI-pipeline, fråga vilket specifikt fel det förhindrar. Inte i teorin, utan ett fel du har sett eller kan namnge konkret. “Det kanske hjälper” är inget skäl att lägga till en komponent. “Vi såg att det föll på just det här sättet två gånger” är det.

Kan du inte namnge felet är steget spekulativ komplexitet, och det är där underhållskostnaden i tysthet byggs upp. Det är dessutom oftast billigare. Färre komponenter betyder färre saker som kan gå sönder, färre integrationer att betala för och färre ställen där en leverantörs API-ändring kan slå ut ert flöde.

Så gör vi annorlunda nu

I nya automationsuppdrag utgår vi från den minsta pipeline som rimligen kan fungera, sätter den i drift och lägger bara till ett steg när vi har sett felet det ska lösa, inte före. Det är en mindre imponerande arkitekturbild. Det är också den som fortfarande går utan tillsyn sex månader senare.

Om en automation känns mer komplicerad än problemet förtjänar är det oftast en signal, inte ett krav. Vi kan titta på den tillsammans med dig.