Hoe machine learning in technische patronen op te nemen

Dr. Steven Gustafson is Noonum’s CTO en een AI-wetenschapper, gepassioneerd door het oplossen van moeilijke problemen terwijl ze plezier hebben en geweldige teams bouwen.

Nadat ik als AI-wetenschapper, AI-producteigenaar of hoofdwetenschapper veel end-to-end machine learning (ML) en kunstmatige intelligentie (AI)-systemen heb ontwikkeld, heb ik gezien hoe managers in software-engineering vaak geen rekening houden met de nuances van ML-systemen . Omdat ik de afgelopen drie jaar de CTO van een startup was, kon ik onderzoeken hoe ik ML kon opnemen in de belangrijkste technische ontwerppatronen. Door samen te werken met een CTO of engineermanager die zowel AI als software begrijpt, kunnen de beste engineeringarchitectuur en beheerpatronen verder reiken dan traditionele softwareapplicaties zoals databases en webapplicaties om een ​​ML-fabriek beter te controleren en te optimaliseren.

Continue integratie en implementatie

Verminder het risico van het vrijgeven van kapotte applicaties. Bouw altijd met unit- en componenttests en implementeer met verificatietests met code die zelf onder versiebeheer staat. Nadat u zich hebt gecommitteerd aan een ontwikkelingsvertakking, wordt het systeem geïmplementeerd in een ontwikkelomgeving.

Zodra alle end-to-end en handmatige rooktests zijn voltooid, wordt een handmatige actie geïmplementeerd in de productie. ML-modellen zijn inbegrepen, evenals de pijplijn die het ML-model uitvoert. Gouden standaardgegevens worden gebruikt om te verifiëren dat ML-modellen en pijplijnen nauwkeurig zijn. Terugdraaien naar software- en databaseversies in goede releases omvat terugdraaien naar de ML-modellen en hun gegevens, die allemaal automatisch kunnen worden geïntegreerd en ingezet.

Infrastructuur als code

Probeer ook te voorkomen dat u de infrastructuur verkeerd implementeert of configureert. Gebruik code om de infrastructuur te specificeren en voer scripts uit om de infrastructuur die het systeem nodig heeft opnieuw te maken en te verifiëren. Evenzo moet de infrastructuur die nodig is om de ML-modellen te bouwen en te testen, en om ze in productie te laten lopen, als code worden gedefinieerd. Zodra alle infrastructuur die is gekoppeld aan de ontwikkeling en implementatie van ML-modellen als code is gespecificeerd, kan deze worden bijgewerkt om wijzigingen in de ML-modellen of het gebruik ervan op te vangen, of de infrastructuur kan indien nodig worden teruggedraaid naar het laatst werkende ML-model.

End-to-end-tests

Handmatige rooktesten zijn altijd nuttig en het is een voortdurende taak om de tests fris en up-to-date te houden met nieuwe functies, gebruiksscenario’s en gegevens. Voorspellingen van ML-modellen zijn niet anders. Als een deel van de app wordt bediend door een aanbeveling voor een ML-model, identificeer dan de beweringen die kunnen worden gedaan, zoals waar er ten minste vijf suggesties in een toepassing moeten zijn of of een e-mailwaarschuwing correct is opgesteld, of dat het model kan omgaan met ontbrekende gegevens zoals verwacht. Een defect ML-model of -pijplijn mag niet worden vrijgegeven en slechte resultaten opleveren in de app.

Alarmen en meldingen over processen

In een ML-systeem zijn er inkomende gegevens, worden modellen uitgevoerd, wordt de uitvoer van de modellen opgeslagen en geanalyseerd en worden toepassingstabellen gemaakt. Al deze processen draaien op regelmatig geplande taken of maken deel uit van een wachtrij- of eventingsysteem.

Telkens wanneer een script faalt, logt u de fout in en stuurt u deze naar een alarmerend dashboard (om later fouten te debuggen) en brengt u werknemers op de hoogte via e-mail, Slack of een andere methode. Wanneer een melding overbodig is, pas dan het alarm aan: Elk alarm moet een gebeurtenis zijn die om actie vraagt. Vergelijkbaar met latentie in een applicatie, bewaar en analyseer de resultaten van een ML-modelapplicatie die helpt bij gegevenswijzigingen, druk op de infrastructuurcapaciteit of gewoon onverwachte afwijkingen van voorspellingstypen.

Modeltests en versiebeheer

Unittests en versiebeheer zijn de standaarden voor de meeste software, maar niet voor de ontwikkeling van ML-modellen of de onderliggende gegevens. ML-modellen zijn berucht vanwege het creëren van onbedoelde resultaten als gevolg van nieuwe gegevens. Pas eerst versiebeheer toe op de code die wordt gebruikt om het model te genereren op basis van een specifieke set gegevens, die ook onder zijn eigen versiebeheer moet vallen. De gegevens en het model moeten op elkaar worden afgestemd voor repliceerbaarheid en rollback-behoeften.

Om een ​​nieuw model te implementeren, kunnen wijzigingen in modelversies plaatsvinden in wat een “commit” wordt genoemd, vergelijkbaar met elke repository-upgrade, en het nieuwe model wordt vervolgens getrokken en in de ontwikkelingspijplijn geplaatst. Het implementatieproces moet voorspellingstests uitvoeren op validatiegegevens (alleen gebruikt in deze stap) om ervoor te zorgen dat het verwachte kwaliteitsniveau wordt gehandhaafd, en er moeten waarschuwingen worden gegeven als de nauwkeurigheid daalt of onder een minimumtolerantie komt.

Functionele stijl architectuur

ML-systemen vereisen een aanzienlijke hoeveelheid gegevensverwerking en -transformatie. Wanneer ML-systemen worden ontwikkeld, gebeurt dit meestal in fasen en is het uiteindelijk erg procedureel: gegevens worden gecompileerd in een bestand, opgeschoond en in een tabel geladen, verwerkt en in een cluster geplaatst, door een model gevoerd en opgeslagen in een database. Dit eerste ontwerp wordt gebruikt om het model te maken, de gegevens te begrijpen en grip te krijgen op de prestaties. De geïmplementeerde toepassing kan echter zeer complex en moeilijk te beheren worden als dit patroon wordt gerepliceerd.

In plaats daarvan zorgt een functionele benadering van het maken van discrete transformaties in gegevens en het doorgeven van resultaten aan de volgende fase ervoor dat processen beter kunnen worden geoptimaliseerd en beheerd, waardoor geheugen- en opslagvereisten worden verminderd en tegelijkertijd de efficiëntie wordt verhoogd. Om te voorkomen dat een gegevenssysteem wordt overspoeld door voorspellingen van het ML-systeem op te slaan, worden wachtrij- en berichtensystemen gebruikt om het volume aan gebeurtenissen te beheren. Omdat elastische cloudsystemen van tijd tot tijd knooppunten kunnen verliezen, kunnen wachtrijen en berichten bovendien bufferen voor gegevens die in het ML-systeem komen en ervoor zorgen dat alles wordt verwerkt.

Door de creatie, updates en releases van ML-modellen te ondersteunen als onderdeel van het volledige proces van softwareontwikkeling, wordt een algeheel robuuster systeem gecreëerd. Hierdoor kunt u klanten en gebruikers beter van dienst zijn en tegelijkertijd het leven van uw ingenieurs en wetenschappers aangenamer en efficiënter maken.


Forbes Technology Council is een community die alleen op uitnodiging toegankelijk is voor CIO’s, CTO’s en technologiemanagers van wereldklasse. Kom ik in aanmerking?


Leave a Reply

Your email address will not be published.