Kunstig intelligens:
Demokratisering av KI – og utfordringene
Demokratisering av KI bringer nye utfordringer for designere av innvevde systemer.
Yann LeFaou ser på hvordan demokratiseringen av KI presenterer nye utfordringer for designere av innvevde systemer når de ønsker å lage «ML i kanten»-applikasjoner som fungerer effektivt, samtidig som de oppfyller minimumskravene til prosessor- og lagringskapasitet og lavest mulig strømforbruk for IoT-enheter.
Fra overvåking og adgangskontroll til smarte fabrikker og prediktivt vedlikehold, blir utrullingen av kunstig intelligens (KI) bygget rundt maskinlæringsmodeller (ML) allestedsnærværende i industrielle IoT-kantprosesseringsapplikasjoner. Med denne allestedsnærværende utbredelsen har byggingen av KI-aktiverte løsninger blitt «demokratisert» – den har gått fra å være en spesialdisiplin for dataforskere til en disiplin som designere av innvevde systemer forventes å forstå. Utfordringen med en slik demokratisering er at designere ikke nødvendigvis er godt rustet til å definere problemet som skal løses og til å fange opp og organisere data på den mest passende måten. I tillegg, i motsetning til forbrukerløsninger, finnes det få eksisterende datasett for industrielle KI-implementeringer, noe som betyr at de ofte må opprettes fra bunnen av, fra brukerens egne data.
Blir dagligdags
KI er blitt mainstream, og dyp læring og maskinlæring (henholdsvis DL og ML) ligger bak mange applikasjoner vi nå tar for gitt, som naturlig språkbehandling, maskinsyn, prediktivt vedlikehold og datautvinning. Tidlige implementeringer av KI var sky- eller serverbaserte, og krevde mye prosessorkraft og lagring, samt høy båndbredde mellom KI/ML-applikasjoner og kanten (endepunktet). Og selv om slike oppsett fortsatt er nødvendige for generative KI-applikasjoner som ChatGPT, DALL-E og Bard, har vi de siste årene sett ankomsten av kantprosessert KI, der data behandles i sanntid på innhentingsstedet. Kantprosessering reduserer avhengigheten av skyen betraktelig, gjør det generelle systemet/applikasjonen raskere, krever mindre strøm og koster mindre. Mange anser også sikkerheten for å være forbedret, men det kan være mer nøyaktig å si at hovedfokuset på sikkerhet endres fra å beskytte kommunikasjon underveis mellom skyen og endepunktet til å gjøre kantenheten sikrere.
Nettverkskanten
KI/ML i utkanten av nettverket kan implementeres på et tradisjonelt innvevd system, der designere har tilgang til kraftige mikroprosessorer, grafiske prosessorenheter og en overflod av minneenheter; ressurser som ligner på en PC. Det er imidlertid en økende etterspørsel etter IoT-enheter (kommersielle og industrielle) som har KI/ML i nettverkskanten, og de har vanligvis begrensede maskinvareressurser og er i mange tilfeller batteridrevne.
Potensialet for KI/ML i utkanten av systemer som kjører på ressurs- og strømbegrenset maskinvare har gitt opphav til begrepet TinyML. Eksempler på bruk finnes i industrien (for eksempel for prediktivt vedlikehold), bygningsautomasjon (miljøovervåking), konstruksjon (tilsyn med personellsikkerhet) og sikkerhet.
Dataflyten
KI (og dermed dens undersett maskinlæring) krever en arbeidsflyt fra datainnsamling/datafangst til modelldistribusjon (figur 1). Når det gjelder TinyML, er optimalisering i alle trinn av arbeidsflyten avgjørende på grunn av begrensede ressurser i det innvevde systemet.
For eksempel regnes TinyML-ressurskrav som en prosesseringshastighet på 1 til 400 MHz, 2 til 512 KB RAM og 32 KB til 2 MB lagringsplass (Flash). Med en effekt på 150 µW til 23,5 mW er det også ofte utfordrende å operere innenfor et så lite strømbudsjett.
Dessuten er det en mer omfattende vurdering, eller rettere sagt avveining, når det gjelder å bygge inn KI i et ressursbegrenset innvevd system. Modeller er avgjørende for systemoppførsel, men designere finner seg ofte i å inngå kompromisser mellom modellkvalitet/nøyaktighet, noe som påvirker systemets pålitelighet/pålitelighet og ytelse; hovedsakelig driftshastighet og strømforbruk.
En annen viktig faktor er å bestemme hvilken type KI/ML som skal brukes. Vanligvis finnes det tre typer algoritmer som kan brukes: overvåkede, uovervåkede og forsterkede.
Løsninger
Selv designere med god forståelse av KI og ML kan slite med å optimalisere hvert trinn i KI/ML-arbeidsflyten og finne den perfekte balansen mellom modellnøyaktighet og systemytelse – så hvordan kan innvevd-designere uten tidligere erfaring håndtere utfordringene?
For det første er det viktig å ikke miste fokus på at modeller som er distribuert på ressursbegrensede IoT-enheter vil være effektive hvis modellen er liten og KI-oppgaven er begrenset til å løse et enkelt problem.
Bedre utviklingsmiljøer
Heldigvis har fremkomsten av ML (og spesielt TinyML) til innvevde systemer resultert i nye (eller forbedrede) integrerte utviklingsmiljøer (IDE), programvareverktøy, arkitekturer og modeller – hvorav mange er åpen kildekode. For eksempel er TensorFlow Lite for mikrokontrollere (TF Lite Micro) et gratis og åpen kildekode-programvarebibliotek for ML og KI. Det ble designet for å implementere ML på enheter med bare noen få KB minne. Programmer kan også skrives i Python, som også er åpen kildekode og gratis.
MPLAB
Når det gjelder IDE-er, er Microchips MPLAB X et eksempel på et slikt miljø. Dette IDE kan brukes med selskapets MPLAB ML, en MPLAB X-plugin spesielt utviklet for å bygge optimalisert KI IoT-sensorgjenkjenningskode. Drevet av AutoML automatiserer MPLAB ML hvert trinn i KI ML-arbeidsflyten, noe som eliminerer behovet for repeterende, kjedelig og tidkrevende modellbygging. Funksjonsekstrahering, trening, validering og testing sikrer optimaliserte modeller som tilfredsstiller minnebegrensningene til mikrokontrollere og mikroprosessorer, slik at utviklere raskt kan opprette og distribuere ML-løsninger på Microchip Arm® Cortex-baserte 32-bits MCUer eller MPUer.
Inn i flyten
Oppgaver for optimalisering av arbeidsflyt kan forenkles ved å starte med standard datasett og modeller. Hvis for eksempel en ML-aktivert IoT-enhet trenger bildegjenkjenning, er det fornuftig å starte med et eksisterende datasett med merkede statiske bilder og videoklipp for modelltrening (testing og evaluering). Merk at merkede data er nødvendig for overvåkede ML-algoritmer.
Mange bildedatasett finnes allerede for datasynsapplikasjoner. Men siden de er ment for PC-, server- eller skybaserte applikasjoner, har de en tendens til å være store. ImageNet inneholder for eksempel mer enn 14 millioner annoterte bilder
Datasett
Avhengig av ML-applikasjonen kan det hende at bare noen få delsett er nødvendige; for eksempel mange bilder av mennesker, men bare noen få av livløse objekter. Hvis for eksempel ML-aktiverte kameraer skal brukes på en byggeplass, kan de umiddelbart utløse en alarm hvis en person som ikke bruker hjelm kommer inn i synsfeltet. ML-modellen må trenes, men muligens bare bruke noen få bilder av personer som bruker eller ikke bruker hjelm. Det kan imidlertid være nødvendig med et større datasett for hjelmtyper og et tilstrekkelig spekter innenfor datasettet for å ta hensyn til ulike faktorer, for eksempel forskjellige lysforhold.
Å ha riktige live inndata og datasett, forberede dataene og trene modellen tar hensyn til trinn 1 til 3 i figur 1. Modelloptimalisering (trinn 4) er vanligvis et tilfelle av komprimering, som bidrar til å redusere minnekrav (RAM under behandling og NVM for lagring) og behandlingsforsinkelse.
Når det gjelder prosessering, sliter mange KI-algoritmer, som konvolusjonelle nevrale nettverk (CNN-er), med komplekse modeller. En populær komprimeringsteknikk er beskjæring (se figur 2), som det finnes fire typer av: vektbeskjæring, enhets-/nevronbeskjæring og iterativ beskjæring.
Kvantisering er en annen populær komprimeringsteknikk. Dette er prosessen med å konvertere data i et høypresisjonsformat, for eksempel flyttall 32-bit (FP32), til et format med lavere presisjon, for eksempel et 8-bits heltall (INT8). Bruken av kvantiserte modeller (se figur 3) kan tas med i betraktning i maskintrening på en av to måter.
• Kvantisering etter trening innebærer bruk av modeller i for eksempel FP32-format, og når treningen anses som fullført, kvantisering for implementering. For eksempel kan standard TensorFlow brukes til innledende modelltrening og optimalisering på en PC. Modellen kan deretter kvantiseres og, gjennom TensorFlow Lite, bygges inn i IoT-enheten.
• Kvantiseringsbevisst trening emulerer inferens-tid-kvantisering, og skaper en modell som nedstrøms verktøy vil bruke til å produsere kvantiserte modeller.
Selv om kvantisering er nyttig, bør den ikke brukes overdrevent, da den kan tilsvare å komprimere et digitalt bilde ved å representere farger med færre biter og/eller ved å bruke færre piksler – dvs. det vil være et punkt hvor bildet blir vanskelig å tolke.
Oppsummering
Som det fremgår av våre innledende betraktninger, er KI nå godt og vel innenfor domenet til innvevde systemer. Denne demokratiseringen betyr imidlertid at designingeniører som tidligere ikke har trengt å forstå KI og ML, står overfor utfordringene med å implementere KI-baserte løsninger i sine design.
Selv om utfordringen med å lage ML-applikasjoner og utnytte begrensede maskinvareressurser til det fulle kan være skremmende, er det ikke en ny utfordring – i hvert fall ikke for erfarne designere av innvevde systemer. Den gode nyheten er at det finnes et vell av informasjon (og opplæring) tilgjengelig innen ingeniørmiljøet, i tillegg til IDE-er som MPLAB X, modellbyggere som MPLAB ML og datasett og modeller med åpen kildekode. Dette økosystemet hjelper ingeniører med varierende forståelsesnivåer å raskere komme frem til AL- og ML-løsninger som nå kan implementeres på 16-bits og til og med 8-bits mikrokontrollere.