Anais Dotis-Georgiou, Developer Advocate på InfluxData – Intervjuserie

Anais Dotis-Georgiou är en Developer Advocate för InfluxData med en passion för att göra data vacker med hjälp av Data Analytics, AI och Machine Learning. Hon tar den data hon samlar in, gör en mix av forskning, utforskning och ingenjörskap för att översätta data till något som är funktionellt, värdefullt och vackert. När hon inte sitter bakom en skärm kan du hitta henne utomhus och rita, stretcha, åka bräda eller jaga efter en fotboll.

InfluxData är företaget som bygger InfluxDB, den öppna källkods-tids-serie-databasen som används av mer än en miljon utvecklare runt om i världen. Deras uppdrag är att hjälpa utvecklare att bygga intelligenta, realtids-system med deras tids-serie-data.

Kan du berätta lite om din resa från att vara en forskningsassistent till att bli en Lead Developer Advocate på InfluxData? Hur har din bakgrund inom data-analys och maskinlärning format din nuvarande roll?

Jag tog min kandidatexamen i kemiteknik med fokus på biomedicinsk teknik och arbetade sedan i laboratorier med vaccinutveckling och prenatal autismdetektering. Därefter började jag programmera vätskehanteringsrobotar och hjälpa data-vetare att förstå parametrarna för avvikelse-detektering, vilket gjorde mig mer intresserad av programmering.

Jag blev sedan en säljutvecklare på Oracle (ORCL ) och insåg att jag verkligen behövde fokusera på kodning. Jag gick en kodnings-utbildning på University of Texas inom data-analys och kunde bryta in i tech, specifikt utvecklar-relationer.

Jag kom från en teknisk bakgrund, så det hjälpte till att forma min nuvarande roll. Även om jag inte hade utvecklar-erfarenhet kunde jag relatera till och sympatisera med människor som hade en ingenjörs-bakgrund och sinne men också försökte lära sig programvara. Så när jag skapade innehåll eller tekniska handledningar kunde jag hjälpa nya användare att övervinna tekniska utmaningar samtidigt som jag satte samtalet i en kontext som var relevant och intressant för dem.

Ditt arbete verkar kombinera kreativitet med teknisk expertis. Hur integrerar du din passion för att göra data “vacker” i ditt dagliga arbete på InfluxData?

På senare tid har jag fokuserat mer på data-ingenjörskap än data-analys. Även om jag inte fokuserar på data-analys lika mycket som jag gjorde tidigare, så tycker jag fortfarande om matematik – jag tycker att matematik är vacker, och jag hoppar på chansen att förklara matematiken bakom en algoritm.

InfluxDB har varit en hörnsten i tids-serie-data-området. Hur ser du på den öppna källkods-gemenskapens inflytande på utvecklingen och evolutionen av InfluxDB?

InfluxData är mycket engagerat i den öppna data-arkitekturen och Apache-ekosystemet. Förra året tillkännagav vi InfluxDB 3.0, den nya kärnan för InfluxDB skriven i Rust och byggd med Apache Flight, DataFusion, Arrow och Parquet – vad vi kallar FDAP-stacken. När ingenjörerna på InfluxData fortsätter att bidra till dessa uppströms-projekt, så växer gemenskapen och Apache Arrow-samlingen av projekt blir lättare att använda med fler funktioner och funktioner, och bredare interoperabilitet.

Vilka är några av de mest spännande öppen-källkods-projekten eller bidragen du sett nyligen i sammanhanget med tids-serie-data och AI?

Det har varit kul att se tillägget av LLM:er som återanvänds eller tillämpas på tids-serier för zero-shot-prognostisering. Autolab har en samling av öppna tids-serie-språkmodeller, och TimeGPT är ett annat bra exempel.

Dessutom är olika öppen-källkods-ström-behandlings-bibliotek, inklusive Bytewax och Mage.ai, som tillåter användare att utnyttja och inkorporera modeller från Hugging Face ganska spännande.

Hur ser InfluxData till att deras öppen-källkods-initiativ förblir relevanta och fördelaktiga för utvecklar-gemenskapen, särskilt med de snabba framstegen inom AI och maskinlärning?

InfluxData-initiativen förblir relevanta och fördelaktiga genom att fokusera på att bidra till öppen-källkods-projekt som AI-specifika företag också utnyttjar. Till exempel, varje gång InfluxDB bidrar till Apache Arrow, Parquet eller DataFusion, så gynnar det varje annat AI-teknik och företag som utnyttjar det, inklusive Apache Spark, DataBricks, Rapids.ai, Snowflake, BigQuery, HuggingFace och mer.

Tids-serie-språk-modeller blir alltmer viktiga i prediktiv analys. Kan du förklara hur dessa modeller förvandlar tids-serie-prognostisering och avvikelse-detektering?

Tids-serie-LM:er presterar bättre än linjära och statistiska modeller samtidigt som de också tillhandahåller zero-shot-prognostisering. Detta innebär att du inte behöver träna modellen på din data innan du använder den. Det finns också inget behov av att justera en statistisk modell, som kräver djup expertis inom tids-serie-statistik.

Men, till skillnad från naturlig-språk-behandling, så saknar tids-serie-området offentligt tillgängliga stora dataset. De flesta existerande för-tränade modeller för tids-serier är tränade på små exempel-storlekar, som innehåller bara några tusen – eller kanske till och med hundratals – exempel. Även om dessa benchmark-dataset har varit instrumentala i tids-serie-gemenskapens framsteg, så utgör deras begränsade exempel-storlekar och brist på allmängiltighet utmaningar för för-träning av djupa inlärnings-modeller.

Detta är vad jag tror gör att öppen-källkods-tids-serie-LM:er är svåra att komma över. Google’s (GOOGL ) TimesFM och IBM’s Tiny Time Mixers har tränats på enorma dataset med hundratals miljarder data-punkter. Med TimesFM, till exempel, så utförs för-tränings-processen med hjälp av Google Cloud TPU v3–256, som består av 256 TPU-kärnor med totalt 2 terabyte minne. För-tränings-processen tar ungefär tio dagar och resulterar i en modell med 1,2 miljarder parametrar. Den för-tränade modellen är sedan finjusterad på specifika nedströms-uppgifter och dataset med hjälp av en lägre inlärningshastighet och färre epoker.

Hoppas att denna transformation innebär att fler människor kan göra precisa prognoser utan djup domän-kunskap. Men, det kräver mycket arbete för att väga för- och nackdelarna med att utnyttja beräknings-kostsamma modeller som tids-serie-LM:er från både ett finansiellt och miljö-mässigt perspektiv.

Denna Hugging Face Blogg-inlägg detaljerar ett annat bra exempel på tids-serie-prognostisering.

Vilka är de viktigaste fördelarna med att använda tids-serie-LM:er jämfört med traditionella metoder, särskilt när det gäller att hantera komplexa mönster och zero-shot-prestanda?

Den kritiska fördelen är att du inte behöver träna och om-träna en modell på din tids-serie-data. Detta eliminerar hoppfullt den online-maskin-lärande-problemet med att övervaka modellens drift och utlösa om-träning, idealiskt sett eliminerar komplexiteten i din prognostiserings-pipeline.

Du behöver inte heller kämpa för att uppskatta korrelationer eller relationer mellan multi-variata statistiska modeller. Ytterligare varians som läggs till av uppskattningar skadar ofta de resulterande prognoserna och kan orsaka att modellen lär sig falska korrelationer.

Kan du ge några praktiska exempel på hur modeller som Google’s TimesFM, IBM’s TinyTimeMixer och AutoLab’s MOMENT har implementerats i verkliga scenarier?

Detta är svårt att svara på; eftersom dessa modeller är i sin relativa barndom, så vet man lite om hur företag använder dem i verkliga scenarier.

I din erfarenhet, vilka utmaningar möter organisationer vanligtvis när de integrerar tids-serie-LM:er i sin befintliga data-infrastruktur, och hur kan de övervinna dem?

Tids-serie-LM:er är så nya att jag inte vet de specifika utmaningarna organisationer möter. Men, jag föreställer mig att de kommer att möta samma utmaningar som de möter när de inkorporerar någon GenAI-modell i sin data-pipeline. Dessa utmaningar inkluderar:

• Data-kompatibilitets- och integrerings-problem: Tids-serie-LM:er kräver ofta specifika data-format, konsekventa tids-stämplar och regelbundna intervall, men befintlig data-infrastruktur kan innehålla ostrukturerad eller inkonsekvent tids-serie-data spridda över olika system, såsom äldre-databaser, moln-lagring eller realtids-strömmar. För att hantera detta bör teamen implementera robusta ETL-pipelines för att förbehandla, rensa och justera tids-serie-data.
• Modell-skalbarhet och prestanda: Tids-serie-LM:er, särskilt djupa inlärnings-modeller som transformers, kan vara resurs-krävande och kräva betydande beräknings- och minnes-resurser för att bearbeta stora mängder tids-serie-data i realtid eller nära-realtid. Detta kräver att teamen distribuerar modeller på skalbara plattformar som Kubernetes eller moln-hanterade ML-tjänster, utnyttjar GPU-acceleration när det behövs och använder distribuerade bearbetnings-ramverk som Dask eller Ray för att parallellisera modell-inferens.
• Tolkbarhet och tillförlitlighet: Tids-serie-modeller, särskilt komplexa LM:er, kan ses som “svarta lådor”, vilket gör det svårt att tolka prognoser. Detta kan vara särskilt problematiskt i reglerade branscher som finans eller hälsovård.
• Data-säkerhet och säkerhet: Att hantera tids-serie-data innebär ofta känslig information, såsom IoT-sensordata eller finansiella transaktionsdata, så det är viktigt att säkerställa data-säkerhet och regelefterlevnad när man integrerar LM:er. Organisationer måste säkerställa att data-pipelines och modeller följer bästa säkerhets-praxis, inklusive kryptering och åtkomst-kontroll, och distribuerar modeller inom säkra, isolerade miljöer.

Om man ser framåt, hur ser du på rollen för tids-serie-LM:er i utvecklingen av prediktiv analys och AI? Finns det några framväxande trender eller teknologier som särskilt exciterar dig?

En möjlig nästa steg i utvecklingen av tids-serie-LM:er kunde vara att introducera verktyg som möjliggör för användare att distribuera, komma åt och använda dem mer lätt. Många av de tids-serie-LM:er jag har använt kräver mycket specifika miljöer och saknar en bredd av handledningar och dokumentation. Ultimat, dessa projekt är i sina tidiga skeden, men det kommer att vara spännande att se hur de utvecklas under de kommande månaderna och åren. Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka InfluxData.