True ML Talks #8 - Machine Learning Platform @ Intuit

Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
We zijn terug met een nieuwe aflevering van True ML Talks. In deze aflevering duiken we diep in Intuit's ML Platform NumaFlow en spreken we met Vigith Maurice.
Vigith is principal engineer bij Intuit voor het AI ops-platform. Zoals iedereen weet die TurboTax, Credit Karma, Mint, QuickBooks en Mailchimp heeft gebruikt, is Intuit het wereldwijde technologieplatform dat u helpt financieel zelfvertrouwen te bereiken.
📌
Onze gesprekken met Vigith behandelen de volgende aspecten:
- ML-use cases binnen Intuit
- NUMA-benadering voor realtime anomaliedetectie
- Inzichten in Argo Workflows
- ML-modellen implementeren met Kubernetes en Numaflow
- Retrainingssystemen, Numaflow vs Flink
- Beveiligings- en compliance-maatregelen in AIOps bij Intuit
- MLOps vs AIOps
- Teaser voor Vigith's KubeCon-presentatie
Bekijk de volledige aflevering hieronder:
Use cases van ML @ Intuit
De operationeel georiënteerde ML-use case
Het AIOps-team van Intuit heeft een andere use case voor ML, die gericht is op de operationele kant van de organisatie. Deze use case heeft tot doel platformproblemen snel te detecteren en op te lossen, waardoor de gemiddelde tijd tot detectie en herstel wordt verkort. Enkele aspecten van deze use case zijn:
- Het bouwen van een Operational Data Lake: Het team van Vigith bouwde een operationeel data lake dat realtime gegevens verzamelt van elke laag van het runtime-systeem, met een focus op zuiver niet-PII geanonimiseerde metrics.
- Realtime analyse: Het team analyseert deze gegevens met een latency van minder dan een minuut om waarschuwingen of incidenten te detecteren en aan te maken op basis van de ernst van het probleem.
- Hoge throughput en lage latency: De ML-benadering die het team van Vigith gebruikt verschilt van traditionele klantgerichte ML, omdat ze te maken hebben met een hoge schaal van 250 Kubernetes-clusters en een miljard events die dagelijks worden ingevoerd voor analyse en verwerking.
- Het voorspellen van afwijkende events: Het systeem van het team volgt het data mesh-principe en schematiseert het gehele systeem om een uniforme aanpak te bieden voor het analyseren van gegevens op schaal. Dit helpt hen om afwijkende events op het gebied van resource-CPU, beveiliging en andere gebieden te voorspellen.
De klantgerichte ML-use case
Bij Intuit richten verschillende ML-use cases zich op het verbeteren van de klantervaring. Enkele van deze use cases omvatten:
- Fraudefrequentie-detectie: Gebruik van ML-algoritmen om frauduleuze activiteiten te detecteren, zoals identiteitsdiefstal, valse facturen en phishing-scams.
- Documenten scannen: Gebruik van ML-modellen om documenten te scannen en automatisch belangrijke informatie te extraheren, zoals bonnetjes, facturen en belastingformulieren.
- Forecasting: Gebruik van ML-technieken om toekomstige trends te voorspellen, zoals omzet, vraag en inkomsten.
- Zoeken in documenten: Gebruik van ML-algoritmen om de nauwkeurigheid en relevantie van zoekopdrachten te verbeteren, waardoor klanten gemakkelijker kunnen vinden wat ze zoeken.
Een schaalbaar platform bouwen voor realtime anomaliedetectie: een NUMA-benadering
Realtime anomaliedetectiesystemen moeten enorme hoeveelheden onbegrensde datastromen verwerken. Traditionele machine learning (ML)-systemen werken op basis van een request-responsemodel waarbij de payload wordt verwerkt om een voorspelling te genereren. Een realtime anomaliedetectiesysteem vereist echter een asynchrone, op directed acyclic graph (DAG) gebaseerde pipeline die verschillende dataformaten en taal-onafhankelijke bewerkingen kan afhandelen.
Intuit heeft een schaalbaar platform gebouwd voor realtime anomaliedetectie dat gebruikmaakt van een NUMA-benadering (New, Unique, and Mature Architecture). De NUMA-benadering bestaat uit twee delen: Numalogic, een reeks modellen die zijn goedgekeurd en dagelijks worden gebruikt, en het NUMAflow-platform, waarop de Numalogic-modellen draaien.
De op DAG gebaseerde pipeline in het NUMAflow-platform omvat een source (een onbegrensde datastroom), vertices (taal-onafhankelijke bewerkingen) en een sink (output van de anomaliescore). De pipeline bevat een pre-processingstap voor feature engineering, een inference-stap en een post-processingstap om scores te normaliseren naar een voor mensen leesbaar formaat.
Het platform is zeer schaalbaar en kostenefficiënt en gebruikt belastingberekeningen om het aantal benodigde verwerkingseenheden te bepalen. Het systeem kan opschalen of afschalen naar nul verwerkingseenheden op basis van het volume van de inkomende data. Het platform is gebouwd om bestand te zijn tegen node- en poortmigraties, auto-scaling en systeemstoringen.
Over het algemeen bieden de NUMA-benadering en het NUMAflow-platform een zeer efficiënte en effectieve oplossing voor realtime anomaliedetectiesystemen.
📌
Architectuur voor afschalen naar nul in AIOps-systemen:
AIOps-systemen vereisen de mogelijkheid om resources op en af te schalen op basis van de hoeveelheid data die in realtime wordt verwerkt. Om dit te bereiken, zijn de scheduling-logica en de dataverwerkingslogica gescheiden. Dit gebeurt door het implementeren van een custom Kubernetes controller met een ingebouwd auto-scalingalgoritme. Dit algoritme is in staat om de verwerkingssnelheid van een vertex en de tijd die nodig is om een bericht te verwerken te begrijpen, en gebruikt deze informatie om automatisch de toegewezen resources aan het systeem aan te passen.
Het gebruik van een custom controller verschilt van de native Kubernetes Horizontal Pod Autoscaler (HPA), die niet kan afschalen naar nul. Door een custom controller te gebruiken, kan het AIOps-systeem afschalen naar nul wanneer het geen data verwerkt, wat helpt om onnodige verspilling van resources te voorkomen.
Om onafhankelijke schaalbaarheid van elke vertex mogelijk te maken, gebruikt het systeem een buffer tussen twee vertices. Deze buffer zorgt ervoor dat de data efficiënt wordt verwerkt en maakt het mogelijk om elke vertex onafhankelijk te schalen op basis van de specifieke vereisten. Dit is belangrijk omdat verschillende processen in een AIOps-systeem verschillende resourcevereisten kunnen hebben, en het onafhankelijk schalen helpt om het resourcegebruik te optimaliseren.
Een van de coolste functies is de mogelijkheid om af te schalen naar nul, en dat is voor ons een absolute must. - Vigith
Open Source Ecosystem en AIOps: inzichten in Argo Workflows
Argo workflows zijn een populair hulpmiddel geworden voor het beheren van machine learning workflows, waarbij Intuit aanzienlijk heeft bijgedragen aan de ontwikkeling ervan. Het succes van Argo ligt in het open-source karakter, wat zorgt voor feedback en bijdragen van gebruikers over de hele wereld. Door de software open te stellen, stromen ideeën en innovaties vanuit de community binnen, waardoor Intuit zijn oplossingen kan verbeteren op basis van de feedback van gebruikers.
Vergeleken met andere DAG-orchestrators zoals Airflow is Argo geschikt voor trainingstaken, maar het is batch-georiënteerd. Gebruikers vroegen om een vergelijkbaar systeem dat streamingdata kon verwerken. Intuit reageerde hierop door Numaflow te creëren, een streaming-georiënteerd systeem. De twee systemen, Argo en Numaflow, kunnen samenkomen om een always-on inference-systeem te creëren voor realtime dataverwerking. Met Numaflow heeft het bedrijf het Argo-systeem geherstructureerd om meer functionaliteiten op te nemen en de werking te verbeteren. De open-sourceaanpak is gunstig gebleken voor Intuit en de gehele community, wat een gezamenlijke inspanning mogelijk maakt om AIOps-workflows te verbeteren.
U kunt hier meer lezen over Argo Workflows:
ML-modellen implementeren met Kubernetes en Numaflow
Het implementeren van machine learning (ML)-modellen met Kubernetes en Numaflow kan een uitdagende taak zijn, vooral gezien de latency en verkeerspatronen die aanzienlijk variëren. Intuit gebruikt een uniek serving-systeem in het operationele AIOps-platform. Wanneer data wordt ontvangen, is het inference-proces vergelijkbaar met elke andere user-defined function (UDF), ongeacht of het gaat om conversie van protobuf naar data of om inference. Numaflow biedt een SDK voor verschillende talen, waarbij Python het meest complex is om te ondersteunen vanwege het gedrag bij een hoge throughput, wat multi-process en procedureel Python vereist. Voor andere talen is dit geen probleem.
Om een handler-functie te maken, hoeft de gebruiker alleen een functie te schrijven die specificeert hoe een door Numaflow aangeleverd bericht moet worden afgehandeld. De functie neemt een bericht aan en retourneert een flat map, die respectievelijk dient als input en output. De handtekening van de functie is van toepassing op elke vertex, ongeacht de taak.
Als het op modellen aankomt, worden deze opgehaald en gecachet op basis van de probleemstelling. Een bericht wordt ontvangen, verwerkt en geretourneerd als inference, die naar de volgende vertex wordt gestuurd. Afhankelijk van de use case kan het model op verschillende manieren worden opgeslagen. Voor een hoge throughput en een sterk gedecentraliseerde architectuur wordt een key gebruikt. Voor een gecentraliseerde architectuur wordt een referentie geplaatst in DynamoDB naar S3. Over het algemeen is het doel om het proces voor een ML-engineer te vereenvoudigen; deze hoeft alleen de klassenaam te wijzigen, omdat de rest wordt geabstraheerd.
Het platform gebruikt gRPC in plaats van REST, en afhankelijk van de probleemstelling wordt een combinatie van technieken gebruikt om de model lifecycle te beheren. MLflow wordt gebruikt om de lifecycle te beheren wanneer dat geschikt is, terwijl andere technieken worden gebruikt voor een meer gedecentraliseerde architectuur waar MLflow geen optie is. De belangrijkste conclusie voor een ML-engineer is om een handler-functie te schrijven die input en output accepteert en het systeem de rest te laten afhandelen.
U kunt hier meer lezen over Numaflow:
Retrainingssystemen, Numaflow vs Flink
Het retrainingssysteem dat door Numaflow wordt gebruikt, varieert afhankelijk van de use case. Voor complexere situaties met 20 requests per seconde zet Numaflow een volledige Argo workflow in met meerdere stappen om data op te halen en de model store bij te werken. Voor lichtere systemen gebruikt Numaflow een User-Defined Function (UDF) die een functie uitvoert om het gewenste resultaat te bereiken.
Verschil tussen Numaflow en Flink
- Verwerkingssnelheid: Numaflow geeft prioriteit aan het loskoppelen van de berichtverwerkingssnelheid van de latency, terwijl Flink gericht is op een hoge throughput met een lage latency, wat het beter geschikt maakt voor verwerking van data met een hoge throughput.
Dit verschil in throughput komt doordat Numaflow is ontworpen voor zware rekenprocessen en input/output (I/O)-intensieve activiteiten, terwijl Flink beter geschikt is voor verwerking van data met een hoge throughput. - Data-serialisatieformaat: Flink gebruikt zijn eigen efficiënte en goed gedefinieerde serialisatieformaat, terwijl Numaflow een black-box-benadering gebruikt die het moeilijk maakt om hashcodes en equals te definiëren voor een efficiënte opslag en retrieval van berichten.
U kunt hier meer lezen over Apache Flink:
Beveiligings- en compliance-maatregelen in AIOps bij Intuit
- Intuit heeft strenge beveiligingsmaatregelen getroffen, waaronder encryptie-algoritmen op applicatieniveau.
- Het AIOps-systeem bij Intuit volgt een waterdichte compartimenteringsaanpak, waarbij elke namespace is geïsoleerd en versleuteld met TLS voor data at rest en in transit.
- Het AIOps-team bij Intuit volgt de beveiligingsprincipes van Argo, een open-sourceproject onder de CNCF, voor het versleutelen van data op alle lagen, inclusief metrics-endpoints.
- Het AIOps-systeem voor klantdata bij Intuit heeft nog strengere beveiligingsbeperkingen, met goed gecontroleerde en bijgehouden data waar zelfs gebruikers geen toegang toe hebben. Operationele data is om deze reden losgekoppeld van klantdata, maar er zijn nog steeds beveiligingsmaatregelen van kracht.
MLOps vs AIOps
Machine Learning Operations (MLOps) en Artificial Intelligence Operations (AIOps) zijn twee termen die vaak door elkaar worden gebruikt, maar ze hebben daadwerkelijk verschillende principes en processen.
MLOps richt zich voornamelijk op het beheren van de model lifecycle, terwijl AIOps meer gecentreerd is rond het operationele domein.
In AIOps gebruiken we doorgaans technologieën zoals HyperLogLog en op latency gebaseerde sketches, die zijn ontworpen om te werken met operationele data. Deze technologieën kunnen foutpercentages hebben van ongeveer 0,89 en maken benaderingen mogelijk. We vertrouwen ook op statistische significantie om problemen te detecteren en te isoleren, met als doel de Mean Time to Resolution (MTTR) te verkorten.
In tegenstelling tot AIOps maakt MLOps gebruik van andere technologieën zoals MLflow en diverse heuristieken om de lifecycle van een model te beheren. Bij Intuit hebben ze ook patronen zoals feature management ontwikkeld om de model lifecycle te optimaliseren. Hun doel in MLOps is het beheren van de gehele model lifecycle, van training tot deployment, monitoring en optimalisatie.
Teaser voor Vigith's KubeCon-presentatie: Klantgerichte AIOps met anomaliedetectie
Vigith's aankomende presentatie op KubeCon draait om klantgerichte AIOps en anomaliedetectie. De nadruk ligt op alarmering op basis van de ervaring van de klant in plaats van die van het systeem. Dit betekent dat er complexe afhankelijkheidsgrafieken worden gebouwd op basis van tracing-data en dat anomalieën worden geïsoleerd in plaats van alleen gedetecteerd.
Het platform maakt gebruik van een verzameling dimensies en metrics om samengestelde key-anomaliedetectie uit te voeren op tijdreeksgegevens, waardoor anomalieën op een zeer specifiek niveau kunnen worden gelokaliseerd. Het doel van dit project is het bieden van een gegeneraliseerde oplossing voor anomaliedetectie, waardoor het een "Do It Yourself anomalie"-systeem wordt.
De presentatie van Vigith zal de mogelijkheden van het platform tonen en demonstreren hoe het succesvol is geïmplementeerd bij Intuit voor AIOps. Mis deze kans niet om meer te leren over de nieuwste ontwikkelingen op het gebied van klantgerichte AIOps en anomaliedetectie.
Lees ons vorige bericht in de TrueML-serie
Blijf kijken naar de TrueML YouTube-serie en lees de TrueML blogserie.
TrueFoundry is een ML Deployment PaaS over Kubernetes om developer-workflows te versnellen, terwijl ze volledige flexibiliteit behouden bij het testen en implementeren van modellen, met gegarandeerde beveiliging en controle voor het infra-team. Via ons platform stellen we Machine Learning-teams in staat om modellen binnen 15 minuten te deployen en te monitoren met 100% betrouwbaarheid, schaalbaarheid en de mogelijkheid om binnen seconden terug te draaien. Dit helpt hen kosten te besparen en modellen sneller naar productie te brengen, wat leidt tot echte zakelijke waarde.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.
















.png)

.webp)



.webp)








.webp)





