Anais Dotis-Georgiou, utvikleradvokat i InfluxData – Intervju-serie

Anais Dotis-Georgiou er en utvikleradvokat for InfluxData med en lidenskap for å gjøre data vakker med hjelp av dataanalyse, AI og maskinlæring. Hun tar dataene hun samler inn, gjør en blanding av forskning, utforskning og ingeniørarbeid for å oversette dataene til noe funksjonelt, verdifullt og vakkert. Når hun ikke er bak en skjerm, kan du finne henne ute og tegne, strekke, surfe eller jage etter en fotball.

InfluxData er selskapet som bygger InfluxDB, den åpne kildekods-tidsseriedatabasen som brukes av over en million utviklere verden over. Deres mål er å hjelpe utviklere å bygge intelligente, sanntids-systemer med deres tidsseriedata.

Kan du dele litt om din reise fra å være en forskningsassistent til å bli en leder for utvikleradvokater i InfluxData? Hvordan har din bakgrunn i dataanalyse og maskinlæring formet din nåværende rolle?

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

Jeg ble deretter en salgsutviklingsrepresentant i Oracle (ORCL ) og innsett at jeg virkelig trengte å fokusere på kode. Jeg tok en kode-utdannelse på University of Texas i dataanalyse og var i stand til å bryte inn i teknologi, 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 mentalitet, men også prøvde å lære software. Så, når jeg laget innhold eller tekniske tutoriale, var jeg i stand til å hjelpe nye brukere å overvinne tekniske utfordringer samtidig som jeg plasserte samtalen i en kontekst som var relevant og interessant for dem.

Ditt arbeid ser ut til å blande kreativitet med teknisk ekspertise. Hvordan inkorporerer du din lidenskap for å gjøre data “vakker” i ditt daglige arbeid i InfluxData?

For tiden har jeg vært mer fokusert på data-ingeniørarbeid enn dataanalyse. Selv om jeg ikke fokuserer så mye på dataanalyse som jeg gjorde tidligere, nyter jeg fortsatt matematikk – jeg synes matematikk er vakker, og vil gjerne forklare matematikken bak en algoritme.

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

InfluxData er meget dedikert til åpen data-arkitektur og Apache-økosystemet. Forrige år kunngjorde vi InfluxDB 3.0, den nye kernen for InfluxDB skrevet i Rust og bygget med Apache Flight, DataFusion, Arrow og Parquet – det vi kaller FDAP-stakken. Etterhvert som ingeniørene i InfluxData fortsetter å bidra til disse oppstrøms-prosjektene, vokser samfunnet og Apache Arrow-prosjektene blir enklere å bruke med flere funksjoner og funksjonalitet, og større interoperabilitet.

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

Det har vært spennende å se tilføyelsen av LLM-er som blir gjenbrukt eller anvendt på tidsserier for null-skudds-prognoser. Autolab har en samling av åpne tidsseriedata-språkmodeller, og TimeGPT er et annet godt eksempel.

I tillegg er det spennende å se åpne kildekods-strømbehandlingsbiblioteker, inkludert Bytewax og Mage.ai, som lar brukerne utnytte og inkorporere modeller fra Hugging Face.

Hvordan sikrer InfluxData at deres åpne kildekods-initiativer forblir relevante og nyttige for utviklersamfunnet, spesielt med de raske fremskrittene i AI og maskinlæring?

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

Tidsseriedata-språkmodeller blir stadig viktigere i prediktiv analyse. Kan du forklare hvordan disse modellene transformerer tidsseriedata-prognose og anomali-deteksjon?

Tidsseriedata-språkmodeller overgår lineære og statistiske modeller samtidig som de tilbyr 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 tidsseriestatistikk.

Imidlertid, i motsetning til naturlig språkbehandling, mangler tidsseriefeltet offentlig tilgjengelige store datasamlinger. De fleste eksisterende forhånds-trente modeller for tidsserier er trent på små datasamlinger som bare inneholder noen tusen – eller kanskje bare noen hundre – eksempler. Selv om disse benchmark-datasamlingene har vært instrumental i tidsseriefeltets fremgang, utgjør deres begrensede datasamlinger og manglende generalitet utfordringer for forhånds-trening av dype læringsmodeller.

Det er dette jeg tror gjør åpne kildekods-tidsseriedata-språkmodeller vanskelige å finne. Googles TimesFM og IBMs Tiny Time Mixers har vært trent på massive datasamlinger med hundredvis av milliarder datapunkter. Med TimesFM, for eksempel, er forhånds-treningen gjort ved hjelp av Google Cloud TPU v3-256, som består av 256 TPU-kjerner med totalt 2 terabyte minne. Forhånds-treningen 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 datasamlinger ved hjelp av en lavere læringsrate og færre epoker.

Håper dette betyr at flere mennesker kan gjøre nøyaktige prediksjoner uten dypt domene-kunnskap. Imidlertid, det krever mye arbeid å veie fordelene og ulemper ved å bruke datamaskinelt kostbare modeller som tidsseriedata-språkmodeller fra både et økonomisk og miljømessig perspektiv.

Dette Hugging Face Blog-innlegget detaljerer et annet godt eksempel på tidsseriedata-prognose.

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

Den kritiske fordel er å ikke trenge å trene og gjen-trene en modell på dine tidsseriedata. Dette eliminerer håndteringen av modell-drift og utløsning av gjen-trening, ideelt sett eliminerer kompleksiteten i din prognose-pipeline.

Du trenger heller ikke å kjempe for å estimere korrelasjoner eller relasjoner for multivariate statistiske modeller. Ekstra variasjon lagt til av estimeringer kan skade de resulterende prognosene og kan få modellen til å lære spuriøse korrelasjoner.

Kan du gi noen praktiske eksempler på hvordan modeller som Googles TimesFM, IBMs TinyTimeMixer og AutoLabs MOMENT har blitt implementert i virkelige scenarier?

Dette er vanskelig å svare på; siden disse modellene er i deres relative barndom, vet lite om hvordan selskaper bruker dem i virkelige scenarier.

I din erfaring, hva slags utfordringer møter organisasjoner vanligvis når de integrerer tidsseriedata-språkmodeller i deres eksisterende data-infrastruktur, og hvordan kan de overvinne dem?

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

• Data-kompatibilitets- og integreringsproblemer: Tidsseriedata-språkmodeller krever ofte bestemte data-formater, konsistente tidsstempel og regelmessige intervaller, men eksisterende data-infrastruktur kan inkludere ustrukturert eller inkonsistent tidsseriedata spredt over forskjellige systemer, som legacy-databaser, sky-lagring eller sanntids-strømmer. For å håndtere dette, bør teamene implementere robuste ETL-pipelines for å forhåndsgjøre, rense og justere tidsseriedata.
• Modell-skalerbarhet og ytelse: Tidsseriedata-språkmodeller, spesielt dype læringsmodeller som transformers, kan være ressurskrevende og kreve betydelig beregnings- og minne-ressurser for å prosessere store volumer tidsseriedata 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 for å parallellisere modell-inferens.
• Tolknings- og tillitsverdighet: Tidsseriedata-modeller, spesielt komplekse LLM-er, kan sees på som “svarte bokser”, og gjøre det vanskelig å tolke prediksjoner. Dette kan være spesielt problematisk i regulerte industrier som finansielle eller helse.
• Data-sikkerhet og -beskyttelse: Håndtering av tidsseriedata innebærer ofte sensitiv informasjon, som IoT-sensor-data eller finansielle transaksjonsdata, så det er kritisk å sikre data-sikkerhet og -beskyttelse når tidsseriedata-språkmodeller integreres. Organisasjoner må sikre at data-pipelines og -modeller overholder beste sikkerhetspraksis, inkludert kryptering og tilgangskontroll, og deployer modeller innen sikre, isolerte miljøer.

Ser du fremover, hvordan ser du på at tidsseriedata-språkmodellene vil utvikle seg i feltet prediktiv analyse og AI? Er det noen nye trender eller teknologier som spesielt exciterer deg?

En mulig neste steg i utviklingen av tidsseriedata-språkmodeller kan være å introdusere verktøy som gjør det enklere for brukerne å deployere, aksessere og bruke dem. Mange av tidsseriedata-språkmodellene 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, kan besøke InfluxData.