Enhet 4 / 11

AI på enheten: Core ML, TensorFlow Lite och ML Kit

Vinster:

  • Möjlighet att välja på enheten eller molnet och välja rätt verktyg (ML Kit, Core ML, TensorFlow Lite) baserat på integritet, offlinebehov, modellstorlek och batterikriterier
  • Möjlighet att förhindra tysta fel genom att verifiera indataförbearbetning (storlek och normalisering) från modellens dokument i modellintegration
  • Förmåga att utvärdera konfidenspoängen och mäta resultatet med användarens godkännande och på den verkliga enheten, utan att presentera lågkonfidensförutsägelser som absolut sanning.

Hittills har vi använt AI som ett hjälpmedel för att påskynda utvecklingsprocessen. Nu går vi vidare till AI:s andra roll: talangen som är inbäddad i applikationen. Moderna telefoner har kraften att köra AI-modeller som bildigenkänning, textöversättning, taltranskription etc. direkt på enheten (på enheten — i telefonens egen processor utan att gå till servern). AI på enheten; Det erbjuder stora fördelar jämfört med molnlösningar när det gäller hastighet, integritet och offlinedrift. I den här enheten kommer vi att lära oss hur man bäddar in AI i applikationen med iOS Core ML, plattformsoberoende TensorFlow Lite (nu känd som LiteRT) och Googles färdiga lösning ML Kit, och hur man använder AI som assistent i denna integration.

På enheten eller molnet?

Detta är det första och viktigaste arkitektoniska beslutet. AI på enheten tar inte bort data från telefonen – en enorm vinst för integriteten. Det är också omedelbart och fungerar offline eftersom det inte finns någon nätverkslatens. Det begränsas dock av enhetens processorkraft och minne; Mycket stora modeller (t.ex. modeller med gigantiska tungor) får inte plats i telefonen eller laddar ur batteriet. Cloud AI, å andra sidan, erbjuder obegränsad kraft, men skickar data till servern, kräver nätverk och skapar latens.

kriterium

På enheten

Moln (moln API)

Sekretess

Data finns kvar på enheten, stark

Data går till servern, uppmärksamhet behövs

hastighet

Omedelbart, inget nätverk

Beror på nätverkslatens

offline

Det fungerar

Fungerar inte

Modellstorlek

Begränsad (telefonresurs)

obegränsad

batteri/värme

Effekter vid hård användning

Server under belastning, enheten avslappnad

Kostnad

Gratis (enhetskälla)

Avgift per användning

Beslutsregel: Välj på enheten om personlig/känslig data bearbetas, måste fungera offline eller om omedelbart svar är viktigt. Om du behöver en mycket stor modell, vänd dig till molnet. Denna enhet är fokuserad på enheten; Vi kommer att täcka moln AI i nästa enhet.

Tips: Gör alltid enheten som standard för en funktion som hanterar känslig data (hälsa, biometri, plats). Frasen "data lämnar inte enheten" är ovärderlig för både integritetsefterlevnad och användarförtroende, och gör stor skillnad i butikens sekretessetikett.

Tre sätt: ML Kit, Core ML, TensorFlow Lite

ML Kit (Google) är det enklaste sättet att börja: det ger färdiga funktioner som textigenkänning (OCR — läsa text i en bild), ansiktsavkänning, streckkodsläsning, översättning på några få rader. Du behöver inte träna din egen modell. Core ML (Apple) är det mest effektiva sättet att köra din egen modell eller en färdig modell på iOS; Den använder Apples Neural Engine (artificiell neural nätverksprocessor) hårdvara. TensorFlow Lite/LiteRT är en plattformsoberoende lösning som låter dig köra din egen tränade modell på både Android och iOS.

Det allmänna integrationsflödet med AI går så här:

  1. Talangdefinition. Ett tydligt mål, som "Jag vill läsa texten på bilden."
  2. Val av väg. Om det finns redo talang, ML Kit; Core ML/TF Lite om specialmodell finns tillgänglig.
  3. Modellformat. .mlmodel (Core ML), .tflite (TF Lite). Förklarar AI-transformationsstegen.
  4. Integrationskod. Laddar modellen, förbearbetar indata, tolkar utdata.
  5. Prestationstest. Hastighet, minne, batterimätning på riktig enhet.
Varning: Det vanligaste AI-misstaget vid modellintegrering på enheten är förbearbetning av indata – att konvertera bilden till den storlek och det färgformat som modellen förväntar sig. Om modellen förväntar sig 224x224 pixlar och du ger den 300x300 blir resultatet meningslöst, men du får inget felmeddelande. Verifiera förbearbetningsvärdena från modellens dokument.

Att känna till gränserna för modellen

En enhetsmodell fattar beslut baserat på den data som den tränades på. En objektigenkänningsmodell som tränas endast på foton tagna under dagen kommer att vara fel på nattbilder. Modellen har en konfidenspoäng (tillförsikt — hur säker modellen är på sitt svar, vanligtvis mellan 0 och 1); Det är farligt att presentera resultat med låg förtroende för användaren som exakta. Till exempel ska en applikation för skanning av hudfläckar inte säga "definitivt godartad", utan bör säga "modellens förutsägelse är detta, kontakta en läkare". Modellresultatet är en rekommendation, inte en diagnos.

tre minifodral

Fall 1 — Acceleration med OCR. En utgiftsspårningsapp har tagit bort bördan av att manuellt mata in kvitton med ML Kit-textigenkänning. Användaren tar ett foto av kvittot och belopp och datum fylls i automatiskt. Den manuella inmatningstiden minskade från 40 sekunder till 8 sekunder per kvitto. Teamet fick alltid användaren att bekräfta mängden AI:en läste; eftersom skrynkliga kvitton hade en felmarginal på 6 %. Automation + mänskligt godkännande var den rätta balansen.

Fall 2 — Förbearbetningsfel. Ett team integrerade en anläggningsigenkänningsmodell med TensorFlow Lite; På testaren var resultaten slumpmässiga. Problemet var att koden som AI:en genererade inte normaliserade bilden till det [0,1] intervall som modellen förväntade sig (pixelvärdena lämnades på 0-255). När normalisering lades till ökade noggrannheten från 30 % till 89 %. Lektion: förbearbetning är tyst men dödlig.

Fall 3 – Sekretessvinst. En hälsoapplikation upptäckte anomali från pulsdata med Core ML-modellen på enheten. Datan gick aldrig till servern. Detta val gjorde det möjligt för applikationen att ta emot frasen "samlar inte in data" i App Stores sekretessetikett och ökade nedladdningshastigheten jämfört med konkurrenterna. Valet på enheten var både etiskt och kommersiellt lönsamt.

Svag prompt / Stark prompt

Svag uppmaning: "Lägg till bildigenkänning i min app."

Kraftfull uppmaning: "Lägg till belopps- och datumläsningsfunktionen i min Android/Kotlin-applikation. - Använd Google ML Kit Text Recognition (på enheten, offline) - Ta bild från kameran eller galleriet - Extrahera mängden och datumet från den igenkända texten med regex - Presentera resultatet för användaren för godkännande i fältet REDIGERBARA, automatiskt spara och förhandsbearbeta situationen för kameran och bearbeta kameran. förklara stegen."

Kopierbara mallar

Sökvägsvalsmall: "Jag vill göra följande funktion: [funktion]. Ska det vara på enheten eller molnet? Jämför utifrån: integritet, offlinebehov, modellstorlek, batteri, kostnad. Rekommendera lämpligt verktyg (ML Kit / Core ML / TF Lite) och motivera."

Integrationsmall:"Skriv [modell/kapacitet] integration för [plattform]:1) Modellladdning2) Indataförbearbetning (förväntad storlek och normalisering)3) Inferensanrop4) Utdatatolkning och kontroll av konfidenspoäng5) Varning till användaren om resultat med lågt förtroendePåminn mig om att verifiera förbearbetningsvärdena från modellens dokumentation."

Konfidenspoängmall:"Tänk på konfidenspoäng i denna slutledningskod:- Presentera resultatet "exakt" under tröskelvärdet (t.ex. 0,6)- Visa "detta är en uppskattning"-anteckning för användaren- Referera till expert om kritiskt område (hälsa, säkerhet)[kod]"

Prestandaverifieringsmall: "Lista mätvärdena jag behöver mäta på den faktiska enheten för denna modellintegration på enheten: slutledningstid, minnesökning, batteripåverkan, uppvärmning. Berätta om mätmetoden för varje."

Vanliga misstag

  • Hoppa över förbearbetning eller göra det felaktigt. Fel storlek/normalisering ger tyst fel resultat.
  • Ignorerar självförtroendepoängen. Att presentera en uppskattning med låg förtroende som korrekt kommer att vilseleda användaren.
  • Testar modellen i emulatorn. Den faktiska enhetens hastighet och batteri är mycket olika; alltid mäta på riktig hårdvara.
  • Skickar känslig data till molnet i onödan. Att välja moln när det är möjligt på enheten är en integritetsrisk.
  • Bortse från modellstorlek. Appar med stora modeller ökar nedladdningsstorleken och kraschar på låg hårdvara.
  • Att glömma träningsgränsen för modellen. Modellen är felaktig i det tillstånd där den inte ser (natt, annat språk); Gör detta tydligt för användaren.

Sammanfattningsvis

AI på enheten ger integritet, hastighet och offline-drift genom att lagra data på telefonen; Gränsen är enhetens effekt och modellstorlek. ML Kit används för färdiga funktioner, Core ML (iOS) och TensorFlow Lite (plattformsoberoende) används för anpassade modeller. Integrationens tysta mördare är felaktig förbearbetning; Inmatningsstorleken och normaliseringen verifieras från modellens dokumentation. Varje resultat kommer med ett konfidenspoäng, och låga konfidensförutsägelser presenteras inte som absolut sanning. Beslut mäts på den verkliga enheten, inte emulatorn.

Applikationsuppgift

För en "textläsning från foto" eller "streckkodsläsning"-funktion, fråga AI:n om den ska vara på enheten eller i molnet med "Path select-mallen", och be sedan om en ML Kit-baserad ritning med "Integrationsmallen". Verifiera att förbearbetningssteget och användarens godkännande/redigeringsflöde finns i koden. Sätt en tröskel för förtroendepoäng och skriv vad du kommer att göra om resultatet är lågt förtroende.

checklista

  • [ ] Jag fattade beslutet på enheten/molnet baserat på kriterier
  • [ ] Jag valde rätt verktyg (ML Kit / Core ML / TF Lite)
  • [ ] Jag verifierade förbearbetningsdimensionen och normaliseringen från modellens dokumentation
  • [ ] Jag kontrollerade förtroendepoängen och varnade för låga förtroenderesultat
  • [ ] Jag presenterade resultatet för användaren med godkännande/redigering, jag sparade det inte blint
  • [ ] Jag mätte prestanda på den riktiga enheten, inte emulatorn