Elk kind helpen lezen met Wadhwani AI

Elk kind helpen lezen met Wadhwani AI

AI-oplossing om de leesvaardigheid van kinderen in kansarme gemeenschappen te beoordelen en te verbeteren

Wadhwani AI is een non-profitorganisatie die werkt aan meerdere kant-en-klare AI-oplossingen voor kansarme bevolkingsgroepen in ontwikkelingslanden.

Via het Vachan Samiksha-project ontwikkelt het team een op maat gemaakte AI-oplossing waarmee leraren in landelijk India de leesvaardigheid van leerlingen kunnen beoordelen en een gepersonaliseerd stappenplan kunnen opstellen om de leesvaardigheid van elke leerling te verbeteren.

Het team had de oplossing geïmplementeerd in basisscholen voor pilots. Het team kampte echter met de volgende problemen die moesten worden opgelost voordat de scope van het project werd uitgebreid naar meer scholen en leerlingen:

1. Zeer hoge rekenkosten: Het Vachan Samiksha-model had GPU's nodig om inferenties te maken, waardoor het team zeer hoge kosten moest dragen om GPU-instances beschikbaar te houden gedurende de volledige implementatieperiode.
2. Schaalbaarheid was beperkt: Door het quotum aan ML-instances van GPU's dat het team kon krijgen op de beheerde ML-dienst, waarvoor het proces traag was en een business case moest worden opgesteld. Het verkrijgen van niet-beheerde ML-instances op kale Kubernetes was veel eenvoudiger; het team heeft een accent-inclusief model gebouwd om vloeiendheid in regionale talen en Engels te beoordelen
3. Sommige verzoeken duurden erg lang om te beantwoorden: De pilots werden uitgevoerd in duizenden scholen en bij miljoenen leerlingen tegelijk. Dit vereiste dat het systeem horizontaal kon opschalen wanneer de verzoekdoorvoer toenam. De beheerde ML-dienst deed er echter tot wel 9 minuten over voordat opschaling mogelijk was, wat een slechte ervaring opleverde voor de eindgebruiker

Het TrueFoundry-team werkte samen met het team om deze problemen op te lossen. Met behulp van het TrueFoundry-platform kon het team:

1. De applicatie opschalen om 10x meer verzoeken per seconde te verwerken vergeleken met de beheerde ML-dienst.
2. De gemaakte cloudkosten met ~55% verlagen, met hetzelfde niveau van betrouwbaarheid en prestaties.
3. De latentie van verzoeken met ~80% verlagen wanneer de pods horizontaal opschalen.

‍

‍

Over Wadhwani AI

Wadhwani AI werd opgericht door Romesh en Sunil Wadhwani (onderdeel van de Time100 AI-lijst) om AI in te zetten voor het oplossen van problemen waar kansarme gemeenschappen in ontwikkelingslanden mee te maken hebben. Ze werken wereldwijd samen met overheden en wereldwijde non-profitorganisaties om via de oplossing waarde te leveren. Als non-profit gebruikt Wadhwani AI kunstmatige intelligentie om sociale problemen op te lossen op het gebied van landbouw, onderwijs en gezondheid, onder andere. Enkele van hun projecten zijn:

• Plaagbeheer voor katoenvelden: De oplossing helpt oogstverliezen te verminderen door plagen die de katoenplant aantasten te detecteren en te bestrijden.
• Voorspelling van tbc-therapietrouw: Geïmplementeerd bij meer dan 100 openbare gezondheidsinstellingen, helpt het hoogrisicopatiënten te identificeren, geneesmiddelresistentie te detecteren en tbc-diagnose te ondersteunen met echografiedata.
• Antropometrie voor pasgeborenen: Een oplossing die het gewicht van een baby meet met een smartphonecamera en groei-indicatoren bijhoudt.
• COVID-19-voorspelling en -diagnose: Een oplossing die de verspreiding van de pandemie voorspelt en COVID-19-infectie detecteert met behulp van hoestgeluiden.

Wadhwani AI werkt ook samen met partnerorganisaties om hun AI-gereedheid te beoordelen — hun vermogen om AI-oplossingen effectief en duurzaam te creëren en te gebruiken. Het werk van Wadhwani AI is erop gericht AI voor het goede in te zetten en het leven van miljarden mensen in ontwikkelingslanden te verbeteren.

Wadhwani AI's tool voor mondelinge leesvaardigheid: Vachan Samiksha

Leesvaardigheid is fundamenteel voor de onderwijsbasis van elk kind. Helaas missen veel leerlingen uit landelijke en kansarme regio's in India en andere ontwikkelingslanden deze vaardigheden. Om dit probleem op fundamenteel niveau op te lossen, heeft het Wadhwani AI-team een op AI gebaseerde tool voor mondelinge leesfrequentie ontwikkeld, genaamd Vachan Samiksha.

De tool zet AI in om de leesprestaties van elk kind te analyseren. Het is op dit moment vooral gericht op landelijke en semi-stedelijke regio's van het land en wordt gebruikt bij alle leeftijdsgroepen. Om de oplossing voor het grootste deel van het land generaliseerbaar te maken, heeft het team een accent-inclusief model gebouwd om regionale talen en Engels te beoordelen. Handmatige beoordeling van deze vaardigheden heeft eigen vooroordelen en is vaak onnauwkeurig.

De oplossing wordt aan de gebruikers (leraren van de doelscholen) geleverd via een app die het model aanroept dat in de cloud is geïmplementeerd. De leerling leest een paragraaf voor, die door de applicatie wordt opgenomen en naar de cloud wordt gestuurd. In de cloud beoordeelt het model leesnauwkeurigheid, snelheid, begrip en andere complexe leerachterstanden die bij een normale beoordeling gemist zouden kunnen worden. Naast het beoordelen van deze vaardigheden stelt de applicatie ook een gepersonaliseerd leerplan op voor elke leerling om hun leerproces te faciliteren, en maakt het demografische rapporten voor acties op macroniveau door overheidsinstanties. Het team had het model voor de pilot geïmplementeerd met de beheerde ML-dienst van de cloudprovider

Toen we onze samenwerking met het Vachan Samiksha-team binnen Wadhwani AI startten, maakte het team gebruik van de native MLOps-stack van hun cloudprovider om het model te implementeren voor zijn pilot bij het onderwijsdepartement van Gujarat.

Hun infrastructuuropzet was als volgt:

1. Beheerd asynchroon endpoint: Het team wilde een asynchrone inferentie-engine, omdat het model enige tijd (~5-7 seconden) nodig kon hebben om een inferentie te maken. Wanneer de applicatie veel verkeer tegelijk kreeg, moest het de verzoeken tijdelijk opslaan voordat een worker ze kon oppakken en er inferentie op kon toepassen. Het asynchrone endpoint van de cloudprovider maakt intern gebruik van zijn native wachtrij.
2. Beheerde containerdienst: Het team gebruikte de beheerde containerdienst om de backend-service voor de applicatie te hosten.
3. Wachtrij-workers: De beheerde MLOps-dienst gebruikte gereserveerde ML-instances voor wachtrij-workers om verzoeken uit de wachtrij op te pikken en er inferentie op toe te passen.
4. Databron: De wachtrij werd geschreven naar het opslagsysteem van de cloudprovider en daaruit gelezen
5. SNS: werd gebruikt als de broker om het outputpad en de succes-/foutmeldingen vanuit de outputberichtwachtrij te publiceren

Uitdagingen waar het team tegenaan liep

Het team ondervond uitdagingen met deze opzet tijdens het uitvoeren van de eerste pilot, wat hen motiveerde om andere oplossingen te proberen:

‍

Schaalbaarheid was beperkt

Verwacht werd dat de pilot op een enorme schaal zou draaien (~6 miljoen leerlingen in een maand). Het team had er echter geen vertrouwen in dat de beheerde ML-dienst deze schaal zou kunnen ondersteunen, omdat:

1. Apart quotum: De beheerde ML-dienst heeft een apart quotum en toewijzing voor ML-instances, waarvan het lastig was er meer van te krijgen.
2. Lastig om ML-instancequotum te krijgen: Extra quotum krijgen is een traag proces, en het team moest een business case opstellen om in aanmerking te komen voor meer quotum. Zelfs toen het team meer quotum kreeg toegewezen, was dit nauwelijks 1/10e van het quotum dat het team had verwacht.
3. Niet-ML-instances krijgen is veel eenvoudiger: Het team merkte dat het verkrijgen van quotum voor niet-ML-instances veel eenvoudiger was. Het was echter lastig voor het team om dit in hun pilot te gebruiken zonder de beheerde MLOps-tools.

Ondersteuning was traag

Tijdens de pilot ondervond het team problemen met de opschaalsnelheid, en sommige pods kwamen niet op zoals verwacht. Om het probleem op te lossen, nam het team echter contact op met vertegenwoordigers van de cloudprovider, die vervolgens contact opnamen met het technische team. Dit veroorzaakte een vertraging in het systeem en leidde tot vertraging in de pilot.

Opschalen was traag

Toen het verkeer tijdens de pilot toenam, moesten de pods horizontaal opschalen (nieuwe nodes opstarten die een deel van de verzoeken uit de wachtrij konden oppakken en verwerken). Dit proces duurde ~9-10 minuten voor elke nieuwe pod die werd opgestart, wat resulteerde in vertraagde reacties en een slechte ervaring voor de eindgebruiker.

Onhoudbaar hoge kosten

GPU-instances zijn zeer duur vanwege het wereldwijde chiptekort. Tel daarbij op de 20-40% toeslag voor ML-instances die de cloudprovider rekent. Dit maakte de kosten van de instances zeer hoog en onhaalbaar voor het team op de schaal waarop ze het project wilden draaien.

Het systeem was klaar voor implementatie met TrueFoundry in minder dan een week

Toen we het Vachan Samiksha-team ontmoetten, bevonden ze zich in de periode tussen hun eerste en tweede pilot. De pilot was minder dan een week weg en we moesten:

1. Het TrueFoundry-platform opzetten op hun cloudinfrastructuur (aangezien de data zeer gevoelig was en geen data buiten de VPC van het project mocht gaan)
2. Het team aan boord nemen en hen door de verschillende functionaliteiten van het platform leiden.
3. De Vachan Samiksha-applicatie migreren naar het platform
4. De applicatie loadtesten en de horizontale opschaling benchmarken

‍

In de periode vóór de pilot:

Platforminstallatie

‍Ons team hielp het Wadhwani AI-team het platform te installeren op hun eigen kale Kubernetes. Het control plane en het workload-cluster werden beide geïnstalleerd op hun eigen infrastructuur. Alle data, UI-elementen om met het platform te interacteren, en de workloadprocessen voor het trainen/implementeren van de modellen bleven binnen hun eigen VPC. Het platform voldeed ook aan alle beveiligingsregels en -praktijken van het bedrijf.

Training en onboarding

We hielpen het team begrijpen hoe de verschillende componenten met elkaar interacteren tijdens het training- en onboardingproces. We leidden hen door het opzetten van resources, het configureren van autoscaling en het implementeren van het model.

Migratie

Het Wadhwani AI-team kon de applicatie met minimale hulp van het TrueFoundry-team zelfstandig migreren. Dit werd gedaan in een gesprek van 1 uur met het team.

Testing

‍Nadat de applicatie was geïmplementeerd, begon het team met het testen van productiebelasting erop. Het team schaalde de applicatie zelfstandig op naar meer dan 100 nodes via een eenvoudig argument op de TrueFoundry UI, wat 5x hun eerdere hoogst haalbare schaal is. Ze probeerden ook de snelheid van node-opschaling te benchmarken, die veel (3-4x) sneller was dan wat hun eerdere systeem bood.

Uitrol

Met de loadtests afgerond, implementeerde het team de pilotapplicatie en was voorbereid op de uitrol in de tweede fase van de pilot, die werd uitgerold naar 1000 scholen, 9000 leraren en meer dan 2 lakh leerlingen.

Meer controle tegen veel lagere kosten met TrueFoundry

Met een minimale inspanning van minder dan 10 uur kon het Wadhwani AI-team een aanzienlijke verbetering realiseren in snelheid, controle en kosten. Enkele van de belangrijkste veranderingen die ze realiseerden waren:

Meer controle, zichtbaarheid en onafhankelijkheid voor ontwikkelaars

De Data Scientists en Machine Learning Engineers konden meerdere elementen configureren die ofwel lastig voor hen waren om via de console van de cloudprovider te doen, of waarvoor ze afhankelijk waren van het engineeringteam:

Autoscaling-beleid voor GPU-nodes configureren

Gebaseerd op wachtrijlengte en het verhogen van het maximale aantal replica's/nodes naar 70 in plaats van de eerdere limiet van 20

Tijdgebaseerde autoscaling instellen

Omdat het meeste pilotverkeer binnenkwam tijdens schooluren, wanneer leraren met de leerlingen interacteerden, waren er minimale verzoeken, indien al, 's avonds en 's nachts. Het team kon een opschaalschema instellen waarmee de pods tijdens de daluren (avond en nacht) opschaalden naar een minimum. Dit bespaarde ongeveer 15-20% van de pilotkosten.

Benuttingsmetrics en suggesties

Het team kon het verkeer, de resourcebenutting en de reacties eenvoudig rechtstreeks vanuit de TrueFoundry UI monitoren. Ze ontvingen ook suggesties via het platform wanneer er sprake was van overprovisionering of underprovisionering van resources

‍

TrueFoundry hielp het team opschalen terwijl de kosten daalden

5x sneller opschalen

Om opschalen met TrueFoundry te testen, stuurde het team een burst van 88 verzoeken naar de applicatie en benchmarkte de prestaties van de beheerde ML-dienst van de cloudprovider versus TrueFoundry. Alle systeemconfiguraties werden gelijk gehouden, zoals de opschaallogica (gebaseerd op de wachtrijlengte, het initiële aantal nodes, instancetype, enz.)

We ontdekten dat TrueFoundry 78% sneller kon opschalen dan de beheerde ML-dienst, wat de gebruiker veel snellere reacties gaf. De end-to-end tijd die nodig was om op de query te reageren was 40% korter met TrueFoundry.

50% lagere kosten

De kosten die het team maakte voor de pilot werden met ~50% verlaagd door over te stappen naar TrueFoundry, mogelijk gemaakt door de volgende bijdragende factoren:

1. ~25-30% verlaging - Gebruik van kale Kubernetes: Beheerde ML-instances komen met een toeslag van 25-40% voor dezelfde instance wanneer direct op kale Kubernetes geprovisioneerd. Omdat TrueFoundry rechtstreeks op K8s draait, bespaarde het team hier veel kosten
2. ~15-20% verlaging - Tijdgebaseerde autoscaling: Het team plande de afschaling van pods wanneer ze lager verkeer naar de applicatie verwachtten. Dit bespaarde het team 15-20% van de cloudkosten.
3. ~20-30% verlaging - Gebruik van spot-instances: Spot-instances maken deel uit van de onbenutte infrastructuur van cloudproviders, die ze met 50-60% korting aanbieden. Door een eenvoudige vlag in de UI in te schakelen, kan het team een mix van spot- en on-demand-instances gebruiken. Spot-instances lopen risico op deprovisionering, maar TrueFoundry heeft een betrouwbaarheidslaag gebouwd die ervoor zorgt dat zelfs met spot-instances de mix van on-demand- en spot-instances wordt beheerd om gebruikers een betrouwbaar beschikbaarheidsniveau te bieden.

Hoge GPU-beschikbaarheid tegen lagere kosten

Terwijl de beheerde ML-dienst beperkt was door de beschikbaarheid van GPU-instances in dezelfde regio van de cloudprovider, kan TrueFoundry workernodes toevoegen aan het systeem die zich in elke regio of bij elke cloudprovider kunnen bevinden.
Dit betekent dat:

1. Hoge GPU-beschikbaarheid vanuit meerdere cloudproviders/regio's: Gebruikers kunnen nodes opstarten in een andere regio van de cloud met hogere GPU-beschikbaarheid, of bij andere cloudproviders zoals AWS, E2E Networks, RunPod, Azure, GCP of anderen. Dit is cruciaal, aangezien elk bedrijf te maken kan krijgen met GPU-quotumbeperkingen, en om de betrouwbaarheid van het systeem te waarborgen is dit soort back-up noodzakelijk.
2. Kostenverlaging: Verschillende cloudproviders hebben verschillende prijsstellingen voor GPU-instances. Dit kan zelfs 40-80% verschillen tussen de ene en de andere provider. TrueFoundry laat de gebruiker elke GPU-provider koppelen aan één centraal control plane en maakt naadloos opschalen over deze cloudleveranciers mogelijk, met de optie om een goedkopere leverancier te kiezen als deze beschikbaarheid heeft om kosten te besparen.

De beste tools gebruiken zonder beperkingen

TrueFoundry biedt naadloze integratie met elke tool die het team wil gebruiken. Bij de cloudprovider werd dit beperkt door de ontwerpkeuzes van de provider en hun native integraties. Het team wilde bijvoorbeeld NATS gebruiken om berichten te publiceren, wat de native dienst van de cloudprovider op dat moment niet bood. Dit soort keuzes werd door TrueFoundry triviaal gemaakt voor het Wadhwani AI-team.

‍