Anais Dotis-Georgiou, Developer Advocate at InfluxData – Intervju-serie

Anais Dotis-Georgiou er en Developer Advocate for InfluxData med en lidenskap for å gjøre data vakker med hjelp av Data Analytics, AI og Machine Learning. Hun tar data hun samler inn, gjør en blanding av forskning, utforsking og ingeniørarbeid for å oversette data til noe funksjonelt, verdifullt og vakkert. Når hun ikke er bak en skjerm, kan du finne henne utenfor og tegne, strekke, brette eller jage etter en fotball.

InfluxData er selskapet som bygger InfluxDB, den åpne kildekode-tidsrekke-databasen som brukes av mer enn en million utviklere over hele verden. Deres misjon er å hjelpe utviklere bygge intelligente, sanntids-systemer med deres tidsrekke-data.

Kan du dele litt om din reise fra å være en forskningsassistent til å bli en Lead Developer Advocate at InfluxData? Hvordan har din bakgrunn i data-analyse og maskinlæring formet din nåværende rolle?

Jeg tok min bachelorgrad i kjemisk ingeniør med fokus på biomedisinsk ingeniør og arbeidet deretter i laboratorier med vaksineutvikling og prenatal autismedeteksjon. Deretter begynte jeg å programmere væske-håndtering roboter og hjalp data-vitenskapsmenn å forstå parameterne for anomali-deteksjon, noe som gjorde meg mer interessert i programmering.

Jeg ble deretter en salgsutviklingsrepresentant hos Oracle og innsett at jeg virkelig trengte å fokusere på kode. Jeg tok et kode-bootcamp ved University of Texas i data-analyse og var i stand til å bryte inn i tech, spesielt utvikler-relasjoner.

Jeg kom fra en teknisk bakgrunn, så det hjalp å forme min nåværende rolle. Selv om jeg ikke hadde utvikler-erfaring, kunne jeg relatere til og sympatisere med mennesker som hadde en ingeniør-bakgrunn og sinn, men også prøvde å lære software. Så, når jeg lagde innhold eller tekniske tutoriale, kunne jeg hjelpe nye brukere å overvinne tekniske utfordringer samtidig som jeg plasserte samtalen i en kontekst som var relevant og interessant for dem.

Ditt arbeid synes å blande kreativitet med teknisk ekspertise. Hvordan inkorporerer du din lidenskap for å gjøre data ‘vakker’ i ditt daglige arbeid hos InfluxData?

For tiden har jeg vært mer fokusert på data-ingeniør-arbeid enn data-analyse. Selv om jeg ikke fokuserer så mye på data-analyse som jeg gjorde tidligere, liker jeg fortsatt matematikk – jeg synes matematikk er vakker, og vil hoppe på en mulighet til å forklare matematikken bak en algoritme.

InfluxDB har vært en hjørnestein i tidsrekke-data-rommet. Hvordan ser du på hvordan den åpne kildekode-samfunnet påvirker utviklingen og evolusjonen av InfluxDB?

InfluxData er svært dedikert til åpen data-arkitektur og Apache-økosystemet. I fjor kunngjorde vi InfluxDB 3.0, den nye kjerne for InfluxDB skrevet i Rust og bygget med Apache Flight, DataFusion, Arrow og Parquet – det vi kaller FDAP-staken. Etterhvert som ingeniørene hos InfluxData fortsetter å bidra til disse oppstrøms-prosjektene, vokser samfunnet og blir Apache Arrow-samlingen av prosjekter enklere å bruke med flere funksjoner og funksjonalitet, og bredere interoperabilitet.

Hva er noen av de mest spennende åpne kildekode-prosjektene eller bidragene du har sett nylig i sammenheng med tidsrekke-data og AI?

Det har vært kjekt å se tillegg av LLM-er som blir gjenbrukt eller brukt til tidsrekke for null-skudds-prognose. Autolab har en samling av åpne tidsrekke-språk-modeller, og TimeGPT er et annet godt eksempel.

I tillegg er det flere åpne kildekode-strøm-prosesserings-biblioteker, inkludert Bytewax og Mage.ai, som tillater brukerne å utnytte og inkorporere modeller fra Hugging Face, ganske spennende.

Hvordan sikrer InfluxData at deres åpne kildekode-initiativer forblir relevante og nyttige for utvikler-samfunnet, spesielt med de raske fremgangene i AI og maskinlæring?

InfluxData-initiativene forblir relevante og nyttige ved å fokusere på å bidra til åpne kildekode-prosjekter som AI-spesifikke selskaper også utnytter. For eksempel, hver gang InfluxDB bidrar til Apache Arrow, Parquet eller DataFusion, er det til nytte for alle andre AI-teknologi og selskaper som utnytter det, inkludert Apache Spark, DataBricks, Rapids.ai, Snowflake, BigQuery, HuggingFace og mer.

Tidsrekke-språk-modeller blir stadig viktigere i prediktiv analyse. Kan du utdype hvordan disse modellene transformerer tidsrekke-prognose og anomali-deteksjon?

Tidsrekke-språk-modeller overstiger lineære og statistiske modeller samtidig som de også gir null-skudds-prognose. Dette betyr at du ikke trenger å trene modellen på dine data før du bruker den. Det er heller ingen behov for å justere en statistisk modell, som krever dypt ekspertise i tidsrekke-statistikk.

Men, i motsetning til naturlig språk-behandling, mangler tidsrekke-feltet offentlig tilgjengelige store skala-datasett. De fleste eksisterende forhånds-trente modeller for tidsrekke er trent på små prøvestørrelser, som bare inneholder noen tusen – eller kanskje bare noen hundre – prøver. Selv om disse benchmark-datasettene har vært instrumental i tidsrekke-samfunnets fremgang, er deres begrensede prøvestørrelser og manglende generalitet en utfordring for forhånds-trening av dypt-læring-modeller.

Det sier seg selv at dette er hva jeg tror gjør åpne kildekode-tidsrekke-språk-modeller vanskelige å komme over. Google sin TimesFM og IBM sin Tiny Time Mixers er trent på massive datasett med hundredvis av milliarder datapunkter. Med TimesFM, for eksempel, er forhånds-trening-prosessen gjort med Google Cloud TPU v3–256, som består av 256 TPU-kjerner med totalt 2 terabyte minne. Forhånds-trening-prosessen tar omtrent ti dager og resulterer i en modell med 1,2 milliarder parametre. Den forhånds-trente modellen blir deretter fin-justert på bestemte nedstrøms-oppgaver og datasett med en lavere læringshastighet og færre epoker.

Heldigvis antyder denne transformasjonen at flere mennesker kan gjøre nøyaktige prediksjoner uten dyp domenekunnskap. Men det krever mye arbeid å veie fordelene og ulemper ved å utnytte komputasjonelt dyre modeller som tidsrekke-språk-modeller fra både et finansielt og miljømessigt perspektiv.

Denne Hugging Face Blog-posten detaljerer et annet godt eksempel på tidsrekke-prognose.

Hva er de viktigste fordelene med å bruke tidsrekke-språk-modeller sammenlignet med tradisjonelle metoder, spesielt når det gjelder å håndtere komplekse mønster og null-skudds-ytelse?

Den kritiske fordelen er å ikke trenge å trene og gjen-trenge en modell på dine tidsrekke-data. Dette eliminerer håndtering av online maskin-læring-problemet med å overvåke modellens drift og utløse gjen-trening, ideal sett eliminerer kompleksiteten i din prognose-pipeline.

Du trenger heller ikke å slite for å anslå korrelasjonene eller relasjonene mellom variablene for multivariate statistiske modeller. Ekstra variasjon lagt til av anslag kan skade de resulterende prognosene og kan få modellen til å lære feilaktige korrelasjoner.

Kan du gi noen praktiske eksempler på hvordan modeller som Google sin TimesFM, IBM sin TinyTimeMixer og AutoLab sin MOMENT er implementert i virkelige scenarioer?

Dette er vanskelig å svare på; siden disse modellene er i deres relative barndom, er det lite som er kjent om hvordan selskaper bruker dem i virkelige scenarioer.

I din erfaring, hvilke utfordringer møter organisasjoner vanligvis når de integrerer tidsrekke-språk-modeller i deres eksisterende data-infrastruktur, og hvordan kan de overvinne dem?

Tidsrekke-språk-modeller er så nye at jeg ikke vet de spesifikke utfordringene organisasjoner møter. Men jeg forestiller meg at de vil møte de samme utfordringene som de møter når de inkorporerer noen GenAI-modell i deres data-pipeline. Disse utfordringene inkluderer:

• Data-kompatibilitets- og integrerings-problemer: Tidsrekke-språk-modeller krever ofte bestemte data-formater, konsistente tidsstempel og regelmessige intervaller, men eksisterende data-infrastruktur kan inkludere ustrukturert eller inkonsistent tidsrekke-data spredt over forskjellige systemer, som legacy-databaser, sky-lagring eller sanntids-strømmer. For å løse dette, bør teamene implementere robuste ETL-pipelines for å forhåndsbearbeide, rense og justere tidsrekke-data.
• Modell-skalerbarhet og ytelse: Tidsrekke-språk-modeller, spesielt dypt-læring-modeller som transformerer, kan være ressurs-krevende og kreve betydelig beregnings- og minne-ressurser for å prosessere store mengder tidsrekke-data i sanntid eller nær-sanntid. Dette ville kreve at teamene deployer modeller på skalerbare plattformer som Kubernetes eller sky-managed ML-tjenester, utnytte GPU-akselerasjon når det er nødvendig, og bruke distribuerte prosesserings-rammeverk som Dask eller Ray til å parallellisere modell-inferens.
• Tolknings- og tillits-verdier: Tidsrekke-modeller, spesielt komplekse LLM-er, kan sees på som “svarte bokser”, noe som gjør det vanskelig å tolke prediksjoner. Dette kan være spesielt problematisk i regulerte industrier som finansielle eller helse-industrier.
• Data-privatitet og sikkerhet: Håndtering av tidsrekke-data innebærer ofte sensitiv informasjon, som IoT-sensor-data eller finansielle transaksjons-data, så det er viktig å sikre data-sikkerhet og overholdelse når man integrerer LLM-er. Organisasjoner må sikre at data-pipelines og modeller overholder beste sikkerhets-praksis, inkludert kryptering og tilgangskontroll, og deployer modeller innen sikre, isolerte miljøer.

Ser du fremover, hvordan ser du på rollen til tidsrekke-språk-modeller i feltet prediktiv analyse og AI? Er det noen nye trender eller teknologier som spesielt interesserte deg?

En mulig neste skritt i evolusjonen av tidsrekke-språk-modeller kunne være å introdusere verktøy som gjør det mulig for brukerne å deployere, aksessere og bruke dem enklere. Mange av tidsrekke-språk-modellene jeg har brukt, krever svært spesifikke miljøer og mangler en bredde av tutoriale og dokumentasjon. Til slutt, disse prosjektene er i deres tidlige stadier, men det vil være spennende å se hvordan de utvikler seg i de kommende månedene og årene.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, bør besøke InfluxData.