Anais Dotis-Georgiou, Developer Advocate hos InfluxData – Interview Serie

Anais Dotis-Georgiou er en Developer Advocate for InfluxData med en passion for at gøre data smukke ved hjælp af Data Analytics, AI og Machine Learning. Hun tager de data, hun indsamler, og laver 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 åbne kilde-tidsrække database, der bruges af mere end en million udviklere over hele verden. Deres mission er at hjælpe udviklere med at bygge intelligente, realtids-systemer med deres tidsrække-data.

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 data analytics og machine learning formet din nuværende rolle?

Jeg fik min bachelorgrad i kemiteknik med fokus på biomedicinsk ingeniørvidenskab og arbejdede derefter i laboratorier med vaccineudvikling og prenatal autismedetektion. Derefter begyndte jeg at programmere væske-håndtering robotter og hjalp datavidenskabsfolk med at forstå parametrene for afvigelsesdetektion, hvilket gjorde mig mere interesseret i programmering.

Jeg blev derefter salgsudviklingsrepræsentant hos Oracle og indså, at jeg virkelig behøvede at fokusere på kodning. Jeg tog et kodningsbootcamp på University of Texas i data analytics og kunne bryde ind i tech, specifikt udviklerrelationer.

Jeg kom fra en teknisk baggrund, så det hjalp med at forme min nuværende rolle. Selv om jeg ikke havde udviklingsoplevelse, kunne jeg relatere til og medføle 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 blande 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å data-ingeniørarbejde end data analytics. Selv om jeg ikke fokuserer så meget på data analytics, som jeg gjorde tidligere, nyder jeg stadig rigtig meget 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-data-rummet. Hvordan ser du, at den åbne kilde-samfund påvirker udviklingen og evolutionen af InfluxDB?

InfluxData er meget dedikeret til den åbne data-arkitektur 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ættet af projekter lettere at bruge med flere funktioner og funktionalitet, og bredere interoperabilitet.

Hvad er nogle af de mest spændende åbne kilde-projekter eller bidrag, du har set for nylig i sammenhæng med tidsrække-data og AI?

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

Derudover er forskellige åbne kilde-stream-procesningsbiblioteker, herunder Bytewax og Mage.ai, der tillader brugere at udnytte og inkorporere modeller fra Hugging Face, ret interessante.

Hvordan sikrer InfluxData, at deres åbne kilde-initiativer forbliver relevante og nyttige for udviklersamfundet, især med de hurtige fremskridt i AI og machine learning?

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

Tidsrække-sprogmodeller bliver mere og mere væsentlige i prædikativ analytics. Kan du uddybe, hvordan disse modeller transformerer tidsrække-forudsigelse og afvigelsesdetektion?

Tidsrække-LM’er overgår lineære og statistiske modeller, samtidig med at de giver zero-shot-forudsigelse. 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.

Men, til forskel fra naturligt sprogbehandling, mangler tidsrække-feltet offentligt tilgængelige store datasæt. De fleste eksisterende forudtrænede modeller for tidsrække-data 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ække-samfundets fremskridt, udgør deres begrænsede samplesæt og mangel på generalitet udfordringer for forudtræning af dybe læringmodeller.

Men dette er, hvad jeg tror, gør åbne kilde-tidsrække-LM’er svære at komme by. Google’s 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, som 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å bestemte downstream-opgaver og datasæt ved hjælp af en lavere læringsrate og færre epocher.

Håberligt indebærer denne transformation, at flere mennesker kan lave nøjagtige forudsigelser uden dyb domæneviden. Men det kræver meget arbejde at veje fordelene og ulemperne ved at udnytte regnskabsmæssigt dyre modeller som tidsrække-LM’er fra både en finansiel og miljømæssig omkostningsperspektiv.

Denne Hugging Face Blog-post detaljerer endnu et godt eksempel på tidsrække-forudsigelse.

Hvad er de vigtigste fordelene ved at bruge tidsrække-LM’er i stedet for traditionelle metoder, især i forhold til at håndtere 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ække-data. 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 forudsigelsespipeline.

Du behøver heller ikke at kæmpe for at estimere cross-serie-korrelationer eller -relationer for multivariate statistiske modeller. Yderligere varians, der tilføjes af estimeringer, kan ofte skade de resulterende forudsigelser og kan få modellen til at lære spurious korrelationer.

Kunne 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; da disse modeller er i deres relative barndom, er der lidt, 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 de specifikke udfordringer, organisationer møder. Men jeg forestiller mig, at de vil møde de samme udfordringer, der mødes, når man inkorporerer en GenAI-model i din data-pipeline. Disse udfordringer inkluderer:

• Data-kompatibilitets- og integrationsproblemer: Tidsrække-LM’er kræver ofte specifikke data-formater, konsekvent tidsstempel og regelmæssige interval, men eksisterende data-infrastruktur kan indeholde ustruktureret eller inkonsistent tidsrække-data spredt over forskellige systemer, såsom legacy-databaser, cloud-lagring eller realtids-streams. For at løse dette skal holdene implementere robuste ETL (extract, transform, load) pipelines til at forarbejde, rense og justere tidsrække-data.
• Model-skalerbarhed og -præstation: Tidsrække-LM’er, især dybe læringmodeller som transformers, 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 ville kræve, at holdene deployer modeller på skalerbare platforme som Kubernetes eller cloud-managed ML-tjenester, udnytte GPU-acceleration, når det er nødvendigt, og anvende distribueret proces-rammer som Dask eller Ray til 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 industrier som finans eller sundhed.
• Data-privatliv og -sikkerhed: Håndtering af tidsrække-data indebærer ofte følsomme oplysninger, såsom IoT-sensor-data eller finansielle transaktionsdata, så det er vigtigt at sikre data-sikkerhed og -overholdelse, når man integrerer LM’er. 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 forestiller du dig, at rollen af tidsrække-LM’er udvikler sig i feltet prædikativ analytics og AI? Er der nogen opdybende trends 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 gør det muligt for brugere at deployere, adgang 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.