Underhållet av en egen AI syns inte i bygget

Att få en egen AI att fungera kan gå snabbt. Frågan är vem som sköter den om ett år. Med en egen AI avses här en modell som bolaget kör på egna servrar, till exempel en färdig öppen modell, alltså en vars grundversion går att ladda ner och köra själv. Bolag som vill hålla känslig data inom egna väggar kan välja den vägen.

De första testerna kan gå bra, och då är det lätt att skjuta upp frågan om underhållet. Någon i bolaget lär sig dessutom mycket på kort tid, vilket gör bygget lättare att försvara än den kostnad som kommer efteråt.

Studien från Google beskrev kostnaden som kommer efteråt

D. Sculley och hans medförfattare, som arbetade på Google, publicerade 2015 artikeln “Hidden Technical Debt in Machine Learning Systems” vid den vetenskapliga konferensen NIPS, numera NeurIPS. Utgångspunkten är att system som bygger på maskininlärning, alltså system som lär sig av data, går relativt snabbt och billigt att ta fram. Underhållet över tid beskriver författarna som “difficult and expensive”. De använder bilden dold teknisk skuld, det vill säga kostnader som uppstår senare för att man gick snabbt fram från början.

De pekar på flera orsaker. En är att modellen själv bara är en liten del av systemet. Författarna skriver att ett moget system kan komma att bestå av högst 5 procent maskininlärningskod och minst 95 procent kod som kopplar ihop delarna.

En annan orsak är att andra system kan börja använda modellens svar utan att någon känner till det. Då kan en ändring i modellen få följder på ställen som ingen tänkte på. En tredje är att gränsvärden som en gång sattes för hand kan sluta stämma när modellen uppdateras med ny data.

Studien räcker bara en bit för ett vanligt bolag

Artikeln handlar om system som själva tränas och uppdateras, och den kom före dagens språkmodeller. Hur väl bilden stämmer för ett bolag som kör en färdig öppen modell på egna servrar är en bedömning och inte något studien har prövat. Det som ändå är rimligt att ta med sig är att arbetet inte tar slut när den första versionen fungerar. Någon måste uppdatera, rätta när svaren blir fel och svara på frågor från dem som börjat lita på verktyget.

Tänk er ett påhittat exempel: ett bolag bygger en intern assistent som svarar på frågor ur egna dokument. Efter några månader använder säljarna den för att formulera offerter och ekonomi hämtar siffror ur den. Ingen har bestämt det, men flera är nu beroende av svaren. Om utvecklaren som byggde den byter uppdrag eller slutar finns det ingen som vet vad som är kopplat till vad.

Fyra frågor om en egen AI före beslutet

En köpt tjänst flyttar mycket av underhållet till leverantören, men ger andra beroenden och andra villkor för datan, som beskrivs i Villkoren för ett AI-verktyg beror på vilken plan som används. Ett eget bygge ger mer kontroll men också mer att ansvara för. Därför behöver kalkylen innehålla även tiden efter bygget.

Fråga först vem som ska underhålla lösningen om ett år, och vad som händer om den personen är borta. Vem som ska ha rollen och tiden för det tas upp i Den som ska driva AI-arbetet i teamet behöver mandat och tid.

Fråga sedan hur många timmar i månaden underhållet antas ta. Fråga vem som får veta om svaren blir sämre, och hur det upptäcks. Fråga till sist hur vägen från test till vanlig drift ser ut, vilket tas upp i Verktyg som används på riktigt behöver en väg till drift.

Be den som föreslår bygget skriva ner svaren på de fyra frågorna, med en uppskattning av timmar per månad. Räkna om timmarna till kronor med bolagets interna timkostnad, lägg till driftkostnaden och jämför med priset för en köpt tjänst, där även den interna tiden för administration ingår.