AI-utveckling: från problem till kontrollerad drift

Vad AI-utveckling faktiskt omfattar

AI-utveckling är arbetet från ett avgränsat problem till ett system som kan användas, kontrolleras och följas upp. Modellen är bara en del. Data, mätning, programvara, behörighet, användargränssnitt och mänskliga arbetsmoment avgör om lösningen fungerar.

OECD beskriver ett AI-system som ett maskinbaserat system som, för uttryckliga eller underförstådda mål, drar slutsatser från indata och skapar utdata som förutsägelser, innehåll, rekommendationer eller beslut. System kan ha olika grad av självständighet och anpassning efter driftsättning.

Källa: OECD:s förklaring av definitionen av ett AI-system

Den definitionen är bred. Ett projekt kan handla om att klassificera supportärenden, förutse maskinfel, hitta avvikelser i bilder eller skapa textutkast. Utvecklingsarbetet ser olika ut, men samma frågor återkommer: vilket problem ska lösas, vilket underlag finns, hur mäts kvalitet och vem ansvarar för resultatet?

Börja med ett problem som går att mäta

Skriv problemet utan att nämna AI. "Vi behöver AI i kundservice" är inte mätbart. "Handläggare lägger fyra timmar i veckan på att sortera inkommande frågor, och en femtedel behöver flyttas till en annan kö" beskriver ett arbetsflöde.

Dokumentera:

• vem som använder resultatet,
• vilket beslut eller arbetsmoment det stödjer,
• nuvarande tid, kvalitet och kostnad,
• vilken konsekvens ett fel får,
• vilka fall som inte ska ingå,
• vem som kan bedöma om resultatet är rätt.

Google rekommenderar i sin vägledning för maskininlärning att bygga en stabil kedja och tydliga mätetal före mer komplexa modeller. En enkel regel eller bättre sökning kan ibland lösa problemet utan maskininlärning.

Källa: Google, Rules of Machine Learning

Sätt en jämförelsepunkt

Ett AI-resultat behöver jämföras med något. Det kan vara dagens manuella arbete, en enkel regelmodell eller en tidigare teknisk lösning. Utan jämförelsepunkt går det inte att veta om den nya modellen tillför värde.

Välj mått som motsvarar verksamhetens mål. För en klassificering kan det vara missade viktiga ärenden, felaktiga larm och tid till rätt kö. För text kan det vara faktarättningar, redigeringstid och andel utkast som kan användas. För underhåll kan det vara missade fel och onödiga inspektioner.

Ett enda genomsnitt döljer ofta de fel som betyder mest. Redovisa därför olika feltyper och resultat för relevanta grupper, produktvarianter och miljöer.

Data: källa, rättighet och representativitet

Data behöver vara relevant för den uppgift som systemet ska lösa. Mer data hjälper inte om materialet mäter fel sak, innehåller systematiska fel eller kommer från en annan miljö.

Kartlägg:

1. Varifrån varje datamängd kommer.
2. Vem som ansvarar för den.
3. Vilka rättigheter och begränsningar som gäller.
4. Hur uppgifterna har samlats in och märkts.
5. Vilka grupper och situationer som saknas.
6. Hur fel, dubbletter och gamla uppgifter hanteras.
7. Hur länge data får sparas.

Dela inte data slumpmässigt om samma person, maskin eller händelse då kan hamna både i träning och prov. Systemet kan annars verka bättre än det är genom att känna igen närliggande exempel.

För generativ AI är kunskapskällorna en egen del. Dokument behöver tydliga ägare, giltighetsdatum och behörigheter. En modell som söker i gamla eller motstridiga dokument ger välformulerade men opålitliga svar.

Välj teknisk metod efter uppgiften

Alla problem behöver inte en egentränad modell.

Regler och vanlig programvara passar när logiken är stabil och kan beskrivas tydligt.

Klassisk maskininlärning kan passa för prognoser och klassificering när det finns strukturerade historiska exempel.

Djupa neurala nätverk används ofta för bild, ljud och stora textmängder, men kräver mer data, beräkning och kontroll.

En befintlig generativ tjänst kan passa för sammanfattning, utkast och frågesvar. Då ligger en större del av modellutvecklingen hos leverantören, medan organisationen fortfarande ansvarar för användningen, källorna och kontrollen.

Sökning kombinerad med generering kan låta modellen formulera svar utifrån valda dokument. Det minskar inte behovet av källkontroll, men gör det möjligt att visa underlaget.

Valet bör väga kvalitet, kostnad, svarstid, dataskydd, leverantörsberoende och möjlighet att felsöka.

Bygg den första hela kedjan

En tidig prototyp bör omfatta hela vägen från verklig indata till ett resultat som användaren kan bedöma. En hög modellpoäng i ett anteckningsblock säger lite om kameran, datakällan, behörigheten eller gränssnittet inte fungerar.

Den första kedjan kan vara enkel:

1. Läs in representativ data.
2. Kontrollera format och saknade värden.
3. Kör en enkel metod.
4. Visa resultat och osäkerhet.
5. Låt en ämneskunnig person bedöma.
6. Logga fel och återkoppling.
7. Spara vilken version av data och kod som användes.

Google lyfter risken för skillnader mellan träning och drift. Samma signaler och definitioner behöver användas i båda miljöerna, annars kan en modell få fel indata trots att den tekniskt körs utan fel.

Träning, validering och oberoende prov

När en egen modell tränas bör data delas efter ett bestämt upplägg. Träningsdelen används för att anpassa modellen. Valideringsdelen används för val under arbetet. En separat provdel används först när valen är klara.

Om provdelen används om och om igen blir den i praktiken en del av utvecklingen. Resultatet blir då för optimistiskt. För tidsberoende data ska äldre perioder normalt ligga före nyare så att provet liknar framtida användning.

Dokumentera även manuella val: vilka exempel som togs bort, vilka mått som prioriterades och hur gränsvärden sattes. De valen påverkar resultatet lika mycket som modellkoden.

Utvärdera mer än teknisk träffsäkerhet

NIST:s AI Risk Management Framework beskriver tillförlitlighet, säkerhet, robusthet, ansvar, transparens, förklarbarhet, integritet och hantering av skadlig partiskhet som egenskaper som behöver vägas tillsammans.

Källa: NIST AI Risk Management Framework

Ett prov bör därför omfatta:

• kvalitet på vanliga fall,
• ovanliga och svåra fall,
• avsiktligt manipulerad indata,
• skillnader mellan relevanta grupper,
• hantering av personuppgifter,
• svarstid och tillgänglighet,
• kostnad per användning,
• när systemet ska avstå,
• hur en människa tar över.

För generativa system ska faktapåståenden, källor, olämpligt innehåll och försök att styra modellen genom indata ingå.

Mänsklig kontroll behöver utformas

Att skriva "människa i loopen" räcker inte. Personen behöver ha tid, kunskap, underlag och mandat att ändra eller stoppa resultatet.

Bestäm:

• vilka resultat som måste granskas,
• vilken källa granskaren ser,
• hur osäkerhet visas,
• hur en rättning registreras,
• när systemet lämnar över,
• vem som fattar det slutliga beslutet.

Om samma person rutinmässigt godkänner hundratals förslag utan möjlighet att kontrollera dem är kontrollen formell, inte verklig.

Från prov till begränsad drift

Flytta inte direkt från en demonstration till full användning. Börja med få användare, begränsad data och en reservrutin. Låt systemet ge förslag innan det får utföra en åtgärd.

Sätt stoppregler. Det kan vara ett allvarligt fel, en viss nivå av missade fall, en personuppgiftsincident eller att en datakälla blir otillgänglig. En stoppregel ska kunna utlösas av den som ser problemet.

NIST:s ramverk ordnar riskarbetet i funktionerna Govern, Map, Measure och Manage. Arbetet är återkommande, inte en engångskontroll före lansering.

Källa: NIST AI RMF Playbook

Övervakning efter start

Data och användning förändras. En modell för försäljning kan påverkas av nya produkter. En bildmodell kan få annat ljus. Ett generativt verktyg kan ändras av leverantören utan att den lokala koden ändras.

Följ:

• indata som avviker från provmaterialet,
• kvalitet och feltyper över tid,
• ändringar i datakällor,
• användarnas rättningar,
• incidenter och klagomål,
• kostnad och svarstid,
• nya användningssätt utanför det godkända.

Spara versioner av kod, data, instruktioner och leverantörsinställningar. Vid ett fel behöver verksamheten kunna se vad som var i drift och återgå till ett säkert läge.

Roller i ett AI-projekt

Ett fungerande team behöver fler perspektiv än modellutveckling.

• Verksamhetsägaren ansvarar för mål och godkänd användning.
• Ämnesexperten bedömer resultat och konsekvenser.
• Dataansvarig känner källor, kvalitet och rättigheter.
• Utvecklare bygger och provar kedjan.
• Säkerhets- och dataskyddsfunktioner bedömer information och åtkomst.
• Systemägaren ansvarar för drift, loggar och förändringar.
• Användare bidrar med verkliga fall och rapporterar fel.

Samma person kan ha flera roller i ett litet projekt, men ansvaret behöver fortfarande vara uttalat.

Exempel: bildanalys i vården

FDA:s lista över AI-aktiverade medicintekniska produkter visar att AI används i flera medicinska områden, särskilt inom bildrelaterade produkter. Listan består av produkter som har identifierats genom offentlig information om marknadstillstånd och är enligt FDA inte fullständig.

Källa: FDA:s lista över AI-aktiverade medicintekniska produkter

Det visar en viktig skillnad: en modell som hittar mönster i medicinska bilder är inte automatiskt en färdig vårdprodukt. Avsedd användning, kliniskt underlag, säkerhet, arbetsflöde och ansvar behöver bedömas tillsammans.

Tekniker och verktyg

Python och R används ofta för dataanalys, medan flera språk kan bära tjänster runt modellen. TensorFlow och PyTorch är exempel på ramverk för neurala nätverk. Molntjänster kan ge beräkningskraft och färdiga komponenter.

Tekniknamnet avgör inte kvaliteten. Välj verktyg som teamet kan förvalta, säkerhetskopiera och övervaka. Undvik en kedja där ingen förstår hur data flyttas mellan komponenterna.

För varje extern tjänst behöver avtal, lagring, underleverantörer, åtkomst, export och avveckling granskas. En tekniskt lyckad lösning kan ändå vara olämplig om verksamheten inte kan kontrollera informationen.

Sammanfattning

AI-utveckling börjar med ett mätbart problem och en jämförelsepunkt. Därefter följer dataarbete, en enkel fullständig kedja, oberoende prov, mänsklig kontroll och begränsad drift.

Den viktigaste frågan är inte hur avancerad modellen är. Det är om systemet löser rätt uppgift, fungerar på verkliga fall, hanterar information säkert och kan stoppas när det inte gör det.