Anais Dotis-Georgiou, Developer Advocate hos InfluxData – Intervieuserie

Anais Dotis-Georgiou er en Developer Advocate for InfluxData med en passion for at gøre data smukke med hjælp af Data Analytics, AI og Machine Learning. Hun tager de data, hun indsamler, og gør en blanding af forskning, udforskning og ingeniørarbejde for at oversætte dataene til noget, der har funktion, værdi og skønhed. Når hun ikke er bag en skærm, kan du finde hende udenfor, hvor hun tegner, strækker, surfer eller jagter efter en fodbold.

InfluxData er det selskab, der bygger InfluxDB, den open source-tidsrække database, der bruges af mere end en million udviklere verden over. Deres mission er at hjælpe udviklere med at bygge intelligente, realtids-systemer med deres tidsrækkedata.

Kan du dele lidt om din rejse fra at være en forskningsassistent til at blive en Lead Developer Advocate hos InfluxData? Hvordan har din baggrund i dataanalyse og maskinlæring formet din nuværende rolle?

Jeg fik min bachelorgrad i kemiteknik med fokus på biomedicinsk ingeniørkunst og arbejdede derefter i laboratorier, hvor jeg udviklede vacciner og opdagede autisme hos foster. Derefter begyndte jeg at programmere væske-håndtering robotter og hjalp datavidenskabsmænd med at forstå parametrene for afvigelsesdetektion, hvilket gjorde mig mere interesseret i programmering.

Jeg blev derefter en salgsudviklingsrepræsentant hos Oracle (ORCL ) og indså, at jeg virkelig behøvede at fokusere på kodning. Jeg tog et kodningskursus på University of Texas i dataanalyse og kunne derefter bryde ind i teknologi, specifikt udviklerrelationer.

Jeg kom fra en teknisk baggrund, så det hjalp med at forme min nuværende rolle. Selv om jeg ikke havde udviklingserfaring, kunne jeg relatere til og forstå mennesker, der havde en ingeniør-baggrund og -tankegang, men også forsøgte at lære software. Så når jeg skabte indhold eller tekniske tutorials, kunne jeg hjælpe nye brugere med at overvinde tekniske udfordringer, samtidig med at jeg satte samtalen i en kontekst, der var relevant og interessant for dem.

Dit arbejde synes at kombinere kreativitet med teknisk ekspertise. Hvordan inkorporerer du din passion for at gøre data “smukke” i dit daglige arbejde hos InfluxData?

For nylig har jeg været mere fokuseret på dataingeniørarbejde end dataanalyse. Selv om jeg ikke fokuserer så meget på dataanalyse, som jeg gjorde tidligere, nyder jeg stadig matematik – jeg synes, matematik er smuk, og vil springe på en chance for at forklare matematikken bag en algoritme.

InfluxDB har været en hjørnesten i tidsrække-dataområdet. Hvordan ser du, at den open source-samfund påvirker udviklingen og evolutionen af InfluxDB?

InfluxData er meget dedikeret til den åbne dataarkitektur og Apache-økosystemet. Sidste år annoncerede vi InfluxDB 3.0, den nye kerne for InfluxDB, skrevet i Rust og bygget med Apache Flight, DataFusion, Arrow og Parquet – det, vi kalder FDAP-stakken. Da ingeniørerne hos InfluxData fortsætter med at bidrage til disse upstream-projekter, vokser samfundet og bliver Apache Arrow-sæt af projekter lettere at bruge med flere funktioner og muligheder, samt bredere interoperabilitet.

Hvad er nogle af de mest spændende open-source-projekter eller bidrag, du har set i forbindelse med tidsrække-data og AI?

Det har været fedt at se tilføjelsen af LLM’er, der er genbrugt eller anvendt på tidsrækker til zero-shot-forecasting. Autolab har en samling af åbne tidsrække-sprogmodeller, og TimeGPT er et andet godt eksempel.

Dertil kommer forskellige open source-stream-processing-biblioteker, herunder Bytewax og Mage.ai, der giver brugerne mulighed for at udnytte og inkorporere modeller fra Hugging Face, hvilket er ret spændende.

Hvordan sikrer InfluxData, at deres open source-initiativer forbliver relevante og nyttige for udviklersamfundet, især med den hurtige udvikling i AI og maskinlæring?

InfluxData-initiativer forbliver relevante og nyttige ved at fokusere på at bidrage til open source-projekter, som AI-specifikke virksomheder også udnytter. For eksempel bidrager InfluxDB til Apache Arrow, Parquet eller DataFusion, hvilket gavner hver anden AI-teknologi og virksomhed, der udnytter det, herunder Apache Spark, DataBricks, Rapids.ai, Snowflake, BigQuery, HuggingFace og mange flere.

Tidsrække-sprogmodeller bliver mere og mere vigtige i forudsigelsesanalyse. Kan du uddybe, hvordan disse modeller transformerer tidsrække-forecasting og afvigelsesdetektion?

Tidsrække-LM’er overgår lineære og statistiske modeller og giver også zero-shot-forecasting. Dette betyder, at du ikke behøver at træne modellen på dine data, før du bruger den. Der er heller ingen behov for at justere en statistisk model, som kræver dyb ekspertise i tidsrække-statistik.

Derimod mangler tidsrækkefeltet offentligt tilgængelige, store datasæt. De fleste eksisterende forudtrænede modeller for tidsrækker er trænet på små samplesæt, der kun indeholder få tusinde – eller måske endda kun hundredvis – af samples. Selv om disse benchmark-datasæt har været instrumental i tidsrækkefællesskabets fremgang, udgør deres begrænsede samplesæt og mangel på generalitet udfordringer for forudtræning af dybe læringmodeller.

Det er, hvad jeg tror, gør, at open source-tidsrække-LM’er er svære at komme by. Google’s (GOOGL ) TimesFM og IBM’s Tiny Time Mixers er blevet trænet på massive datasæt med hundredvis af milliarder af datapunkter. Med TimesFM, for eksempel, er forudtræningsprocessen udført ved hjælp af Google Cloud TPU v3-256, der består af 256 TPU-kerner med i alt 2 terabyte hukommelse. Forudtræningsprocessen tager omtrent ti dage og resulterer i en model med 1,2 milliarder parametre. Den forudtrænede model bliver derefter finjusteret på specifikke downstream-opgaver og datasæt ved hjælp af en lavere læringsrate og færre epochs.

Forhåbentligt indebærer denne transformation, at flere mennesker kan lave præcise forudsigelser uden dyb domæneviden. Det kræver dog meget arbejde at veje fordelene og ulemperne ved at udnytte beregningskrævende modeller som tidsrække-LM’er fra både et økonomisk og miljømæssigt synspunkt.

Dette Hugging Face Blog-indlæg detaljerer endnu et godt eksempel på tidsrække-forecasting.

Hvad er de vigtigste fordele ved at bruge tidsrække-LM’er i forhold til traditionelle metoder, især i forhold til komplekse mønstre og zero-shot-præstation?

Den kritiske fordel er, at du ikke behøver at træne og gen-træne en model på dine tidsrækkedata. Dette eliminerer håbefuldt det online maskinlæringsproblem med at overvåge modellens drift og udløse gen-træning, idealt eliminerer kompleksiteten i din forecast-pipeline.

Du behøver heller ikke at kæmpe for at estimere tværsériekorrelationer eller -relationer for multivariate statistiske modeller. Den ekstra varians, der tilføjes af estimeringer, skader ofte de resulterende forudsigelser og kan få modellen til at lære spurious korrelationer.

Kan du give nogle praktiske eksempler på, hvordan modeller som Google’s TimesFM, IBM’s TinyTimeMixer og AutoLab’s MOMENT er blevet implementeret i virkelige scenarier?

Dette er svært at svare på; da disse modeller er i deres relative barndom, er der ikke meget, der er kendt om, hvordan virksomheder bruger dem i virkelige scenarier.

I din erfaring, hvilke udfordringer møder organisationer typisk, når de integrerer tidsrække-LM’er i deres eksisterende data-infrastruktur, og hvordan kan de overvinde dem?

Tidsrække-LM’er er så nye, at jeg ikke kender til de specifikke udfordringer, organisationer møder. Jeg forestiller mig dog, at de vil møde de samme udfordringer, som de møder, når de inkorporerer enhver GenAI-model i deres data-pipeline. Disse udfordringer inkluderer:

• Data-kompatibilitets- og integrationsproblemer: Tidsrække-LM’er kræver ofte specifikke dataformater, konsistente tidsstempel og regelmæssige interval, men eksisterende data-infrastruktur kan inkludere ustruktureret eller inkonsistent tidsrække-data, der er spredt over forskellige systemer, såsom legacy-databaser, cloud-lagring eller realtids-streams. For at løse dette problem skal holdene implementere robuste ETL-pipelines (extract, transform, load) for at forarbejde, rense og justere tidsrække-data.
• Model-skalerbarhed og ydeevne: Tidsrække-LM’er, især dybe læringmodeller som transformatorer, kan være ressourcekrævende og kræve betydelige beregnings- og hukommelsesressourcer for at behandle store mængder tidsrække-data i realtid eller nær-real tid. Dette vil kræve, at holdene deployer modeller på skalerbare platforme som Kubernetes eller cloud-managed ML-tjenester, udnytter GPU-acceleration, når det er nødvendigt, og anvender distribuerede procesrammer som Dask eller Ray for at parallelisere model-inferens.
• Fortolkning og tillid: Tidsrække-modeller, især komplekse LM’er, kan ses som “sorte kasser”, hvilket gør det svært at fortolke forudsigelser. Dette kan være særligt problematisk i regulerede brancher som finans eller sundhed.
• Data-sikkerhed og -beskyttelse: Håndtering af tidsrække-data indebærer ofte følsomme oplysninger, såsom IoT-sensor-data eller finansielle transaktionsdata, så det er afgørende at sikre data-sikkerhed og overholdelse. Organisationer må sikre, at data-pipelines og -modeller overholder bedste sikkerhedspraksis, herunder kryptering og adgangskontrol, og deployer modeller inden for sikre, isolerede miljøer.

Set fremad, hvordan ser du, at rollen af tidsrække-LM’er udvikler sig i feltet forudsigelsesanalyse og AI? Er der nogen opstående tendenser eller teknologier, der især begejstrer dig?

En mulig næste skridt i udviklingen af tidsrække-LM’er kunne være at introducere værktøjer, der giver brugerne mulighed for at deployere, få adgang til og bruge dem mere let. Mange af de tidsrække-LM’er, jeg har brugt, kræver meget specifikke miljøer og mangler en bredde af tutorials og dokumentation. Til sidst er disse projekter i deres tidlige stadier, men det vil være spændende at se, hvordan de udvikler sig i de kommende måneder og år.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge InfluxData.