Frank Liu, driftchef på Zilliz – Intervjuserie

Frank Liu är driftchef på Zilliz, en ledande leverantör av vektordatabas och AI-teknologier. De är också de ingenjörer och forskare som skapade LF AI Milvus®, världens mest populära öppen källkodsvektordatabas.

Vad var det som initialt drog dig till maskinlärning?

Min första exponering för kraften i ML/AI var som undergraduate-student på Stanford, trots att det var en aning utanför mitt huvudämne (elektroteknik). Jag drogs initialt till EE som ett område eftersom förmågan att destillera komplexa elektriska och fysiska system till matematiska approximationer kändes mycket kraftfullt för mig, och statistik och maskinlärning kändes likadant. Jag tog fler kurser i datorseende och maskinlärning under min masterutbildning, och jag skrev min masteruppsats om att använda ML för att poängsätta den estetiska skönheten i bilder. Allt detta ledde till mitt första jobb i Computer Vision & Machine Learning-teamet på Yahoo, där jag hade en hybridroll i forskning och programvaruutveckling. Vi var fortfarande i den för-transformatoriska AlexNet- och VGG-eran då, och att se ett helt fält och en industri röra sig så snabbt, från dataförberedelse till massivt parallellt modelltränings- och modellproduktionsarbete, har varit fantastiskt. På många sätt känns det lite löjligt att använda frasen “då” för att hänvisa till något som hände mindre än 10 år sedan, men sådan är den progression som har gjorts inom detta område.

Efter Yahoo tjänstgjorde jag som CTO för ett startup-företag som jag var med och grundade, där vi använde ML för inomhuslokalisering. Där måste vi optimera sekventiella modeller för mycket små mikrokontrollenheter – en mycket annorlunda men likväl relaterad ingenjörsutmaning jämfört med dagens stora LLM och diffusionsmodeller. Vi byggde också hårdvara, dashboards för visualisering och enkla molnbaserade applikationer, men AI/ML tjänstgjorde alltid som en kärnkomponent i det arbete vi utförde.

Även om jag har varit inom eller i närheten av ML i bättre delen av 7 eller 8 år nu, har jag fortfarande mycket kärlek för kretsdesign och digital logikdesign. Att ha en bakgrund inom elektroteknik är, på många sätt, otroligt hjälpsamt för mycket av det arbete jag är involverad i dessa dagar. Många viktiga koncept inom digital design, såsom virtuell minne, grenprediktion och samtidig exekvering i HDL, ger en fullständig vy av mycket av ML och distribuerade system idag. Medan jag förstår lockelsen av CS, hoppas jag på en återupplivning av mer traditionella ingenjörsfält – EE, MechE, ChemE, etc… – inom de närmaste åren.

För läsare som är ovana vid termen, vad är ostrukturerad data?

Ostrukturerad data hänvisar till “komplex” data, som i princip är data som inte kan lagras i ett fördefinierat format eller passa in i en befintlig datamodell. Till exempel hänvisar strukturerad data till alla typer av data som har en fördefinierad struktur – numerisk data, strängar, tabeller, objekt och nyckel/värdeslagringar är alla exempel på strukturerad data.

För att verkligen förstå vad ostrukturerad data är och varför det traditionellt har varit svårt att bearbeta denna typ av data med hjälp av datorer, hjälper det att jämföra det med strukturerad data. I de enklaste termer kan traditionell strukturerad data lagras via en relationsmodell. Ta till exempel en relationsdatabas med en tabell för att lagra bokinformation: varje rad i tabellen kunde representera en viss bok indexerad av ISBN-nummer, medan kolumnerna skulle ange den motsvarande kategorin av information, såsom titel, författare, publiceringsdatum, och så vidare. Numera finns det mycket mer flexibla datamodeller – wide-column-lagring, objektdatabaser, grafdatabaser, och så vidare. Men den övergripande idén förblir densamma: dessa databaser är avsedda att lagra data som passar en viss datamall eller datamodell.

Ostrukturerad data, å andra sidan, kan betraktas som i princip en pseudo-slumpmässig blob av binär data. Den kan representera vad som helst, vara godtyckligt stor eller liten, och kan omvandlas och läsas på ett av många olika sätt. Detta gör det omöjligt att passa in i någon datamodell, för att inte tala om en tabell i en relationsdatabas.

Vilka är några exempel på denna typ av data?

Mänsklig genererad data – bilder, video, ljud, naturligt språk, etc. – är utmärkta exempel på ostrukturerad data. Men det finns också en mängd mindre vardagliga exempel på ostrukturerad data. Användarprofiler, proteinstrukturer, genomssekvenser och till och med mänsklig läsbar kod är alla utmärkta exempel på ostrukturerad data. Den primära anledningen till att ostrukturerad data traditionellt har varit så svår att hantera är att ostrukturerad data kan ta vilken form som helst och kan kräva mycket olika körningar för att bearbeta.

Med bilder som exempel kan två foton av samma scen ha mycket olika pixelvärden, men båda har ett liknande innehåll. Naturligt språk är ett annat exempel på ostrukturerad data som jag gärna hänvisar till. Fraserna “Elektroteknik” och “Datorsystem” är extremt nära relaterade – så mycket att EE- och CS-byggnaderna på Stanford ligger bredvid varandra – men utan ett sätt att koda den semantiska betydelsen bakom dessa två fraser, kan en dator naivt tro att “Datorsystem” och “Samhällsvetenskap” är mer relaterade.

Vad är en vektordatabas?

För att förstå en vektordatabas hjälper det att förstå vad en inbäddning är. Jag kommer till det om en stund, men den korta versionen är att en inbäddning är en högdimensionell vektor som kan representera semantiken i ostrukturerad data. I allmänhet är två inbäddningar som ligger nära varandra i termer av avstånd mycket sannolikt att korrespondera till semantiskt liknande indata. Med modern ML har vi kraften att koda och omvandla en mängd olika typer av ostrukturerad data – bilder och text, till exempel – till semantiskt kraftfulla inbäddningsvektorer.

Från ett företags perspektiv blir ostrukturerad data otroligt svår att hantera så fort mängden växer förbi en viss gräns. Här kommer en vektordatabas som Zilliz Cloud in. En vektordatabas är specialbyggd för att lagra, indexera och söka över enorma mängder ostrukturerad data genom att utnyttja inbäddningar som den underliggande representationen. Sökning över en vektordatabas görs vanligtvis med frågevektorer, och resultatet av frågan är de topp N mest liknande resultaten baserat på avstånd.

De allra bästa vektordatabaserna har många av de användbarhetsfunktioner som traditionella relationsdatabaser har: horisontell skalning, cachelagring, replikering, redundans och frågeexekvering är bara några av de många funktioner som en riktig vektordatabas bör implementera. Som en kategori-definierare har vi varit aktiva i akademiska kretsar också, med publicerade papper i SIGMOD 2021 och VLDB 2022, de två bästa databaskonferenserna idag.

Kunde du diskutera vad en inbäddning är?

Generellt sett är en inbäddning en högdimensionell vektor som kommer från aktiveringarna av en mellanliggande lager i ett multilager-neuronnätverk. Många neuronnätverk är tränade för att producera inbäddningar själva, och vissa applikationer använder sammanfogade vektorer från flera mellanliggande lager som inbäddningen, men jag kommer inte att gå in för djupt i någon av dem just nu. En mindre vanlig men lika viktig metod för att generera inbäddningar är genom handgjorda funktioner. Istället för att låta en ML-modell automatiskt lära sig rätt representationer för indata, kan bra gammal funktionell utveckling fungera för många applikationer också. Oavsett den underliggande metoden är inbäddningar för semantiskt liknande objekt nära varandra i termer av avstånd, och denna egenskap är vad som driver vektordatabaser.

Vilka är några av de mest populära användningsfallen med denna teknik?

Vektordatabaser är utmärkta för alla applikationer som kräver någon form av semantisk sökning – produktrekommendation, videoanalys, dokumentsökning, hot- och bedrägeridetektering och AI-drivna chattbotar är några av de mest populära användningsfallen för vektordatabaser idag. För att illustrera detta har Milvus, den öppen källkodsvektordatabas som skapats av Zilliz och den underliggande kärnan i Zilliz Cloud, använts av över tusen företagsanvändare över en mängd olika användningsfall.

Jag är alltid glad att prata om dessa applikationer och hjälpa folk att förstå hur de fungerar, men jag njuter verkligen av att gå igenom några av de mindre kända vektordatabas-användningsfallen också. Upptäckt av nya läkemedel är ett av mina favorit-“nisch”-vektordatabas-användningsfall. Utmaningen för denna specifika applikation är att söka efter potentiella kandidatläkemedel för att behandla en viss sjukdom eller symptom bland en databas med 800 miljoner föreningar. Ett läkemedelsföretag som vi kommunicerade med kunde förbättra läkemedelsupptäcktsprocessen avsevärt, samt minska på hårdvaruresurserna, genom att kombinera Milvus med en keminformationsbibliotek som heter RDKit.

Cleveland Museum of Arts (CMA) AI ArtLens är ett annat exempel jag gärna tar upp. AI ArtLens är ett interaktivt verktyg som tar en frågebild som indata och drar visuellt liknande bilder från museets databas. Detta kallas vanligtvis för omvänd bildsökning och är ett ganska vanligt användningsfall för vektordatabaser, men den unika värdepropositionen som Milvus tillhandahöll till CMA var förmågan att få applikationen igång och körande inom en vecka med ett mycket litet team.

Kunde du diskutera vad den öppna plattformen Towhee är?

När vi kommunicerade med folk från Milvus-samhället, fann vi att många av dem ville ha ett enhetligt sätt att generera inbäddningar för Milvus. Detta var sant för nästan alla olika organisationer som vi talade med, särskilt för företag som inte hade många maskinläringsingenjörer. Med Towhee syftar vi till att lösa denna lucka via vad vi kallar “vektordata ETL”. Medan traditionella ETL-pipelines fokuserar på att kombinera och omvandla strukturerad data från flera källor till ett användbart format, är Towhee avsett att fungera med ostrukturerad data och explicit inkluderar ML i den resulterande ETL-pipelinen. Towhee uppnår detta genom att tillhandahålla hundratals modeller, algoritmer och omvandlingar som kan användas som byggblock i en vektordata ETL-pipeline. Utöver detta tillhandahåller Towhee också en lättanvänd Python-API som gör det möjligt för utvecklare att bygga och testa dessa ETL-pipelines i en enda rad kod.

Medan Towhee är ett eget oberoende projekt, är det också en del av den bredare vektordatabas-ekosystem som Zilliz skapar kring Milvus. Vi ser Milvus och Towhee som två högt kompletterande projekt som, när de används tillsammans, kan verkligen demokratisera ostrukturerad databearbetning.

Zilliz nyligen höjde en 60M Series B-runda. Hur kommer detta att accelerera Zilliz uppdrag?

Jag vill först tacka Prosperity7 Ventures, Pavilion Capital, Hillhouse Capital, 5Y Capital, Yunqi Capital och andra för att tro på Zilliz uppdrag och stödja oss med denna Series B-utvidgning. Vi har nu höjt totalt 113M, och denna senaste rundan av finansiering kommer att stödja våra ansträngningar att skala ut ingenjörs- och marknadsföringsteam. Specifikt kommer vi att förbättra vår hanterade molntjänst, som för närvarande är i tidig åtkomst men planeras att öppnas för alla senare i år. Vi kommer också att fortsätta att investera i banbrytande databas- och AI-forskning, som vi har gjort under de senaste 4 åren.

Finns det något annat som du skulle vilja dela om Zilliz?

Som företag växer vi snabbt, men vad som verkligen särskiljer vårt nuvarande team från andra i databas- och ML-utrymmet är vår enskilda passion för vad vi bygger. Vi är på en mission att demokratisera ostrukturerad databearbetning, och det är absolut fantastiskt att se så många begåvade personer på Zilliz som arbetar mot ett enda mål. Om något av det vi gör låter intressant för dig, känns du fri att kontakta oss. Vi skulle älska att ha dig ombord.

Om du vill veta mer, är jag också personligen öppen för att prata om Zilliz, vektordatabaser eller inbäddningsrelaterade framsteg inom AI/ML. Min (figurativa) dörr är alltid öppen, så känns du fri att kontakta mig direkt på Twitter/LinkedIn.

Slutligen, tack för att du läste!

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Zilliz.