Techuitdagingen van start-ups - Een AI-zoekmachine voor databases

Ieder jaar beginnen er in de lage landen tientallen techstart-ups, die grootse dromen hebben, maar technische hobbels moeten overwinnen om die waar te maken. In dit artikel bespreken we waar SeMi Technologies zoal tegenaan liep bij het ontwikkelen van zijn databasezoekmachine Weaviate.

Databases bevatten soms miljarden datapunten. Daar doorheen spitten is een hels karwei. Uiteraard is er een zoekfunctie, maar die vereist wel dat je een trefwoord intoetst dat vervolgens in de data terugkomt. Maar wat nou als je antwoord op een vraag wil? Dan heb je niks aan een trefwoord. Met hele vragen weet die zoekfunctie geen raad.

Bob van Luijt werkt al zo’n twintig jaar met databases en is dus als geen ander bekend met dit zoekprobleem. Volgens Van Luijt heeft eigenlijk iedereen wel last van zulke zoekproblemen. "Als jij je bankierenapp opent en je probeert een transactie te zoeken, maar je kunt ‘m niet vinden, is dat een zoekprobleem. Als jij naar een ziekenhuis gaat voor een consult en de arts zit tien minuten te zoeken in het systeem naar wat er ook alweer aan de hand was, is dat ook een zoekprobleem."

Een aantal jaar geleden zag Van Luijt de kans om dit probleem aan te pakken. De wereld van databasetechnologie kreeg toen met een nieuwe machinelearninginnovatie te maken die slimmere zoekopdrachten mogelijk maakt.

• Bedrijf: SeMi Technologies
• Opgericht: 2019, Amsterdam
• Initiatiefnemers: Bob van Luijt, Micha Verhagen en Etienne Dilocker
• Product: een vectordatabase geoptimaliseerd voor zoeken
• Productiefase: de Weaviate-software staat open source op GitHub en wordt regelmatig geüpdatet
• Prijs: de software is gratis te gebruiken, wel zijn er betaalde licentieabonnementen

Weaviate, zoals Van Luijts zoekoplossing heet, is een AI-first vector search engine. Die moet geïntegreerd worden in een datalandschap. Als database is Weaviate dus geen consumentenproduct en daardoor iets heel anders dan Google of Yahoo. "Wij zijn slechts onderdeel van de infrastructuur. Weaviate is volledig api-gebaseerd", legt Van Luijt uit. "Onze interface bestaat uit GraphQL- en RESTful-api’s. Ontwikkelaars moeten Weaviate altijd integreren in een applicatie." De taak van Weaviate is om het zoeken in die applicaties vervolgens snel en efficiënt te laten gebeuren, ook bij miljarden dataobjecten, aan de hand van machinelearningmodellen.

Bob van Luijt

Dat zoeken moet door AI dus 'slimmer' gebeuren dan in traditionele databases. Van Luijt geeft een voorbeeld: "Als je een document hebt waarin staat: 'de Eiffeltoren in Parijs', dan moet je bij traditionele databases of op 'Eiffeltoren' of 'Parijs' zoeken om die tekst te vinden. Maar als je zoekt op 'bezienswaardigheden in Frankrijk' heb je een probleem, want dat staat er niet letterlijk in. Dat is wat de machinelearningmodellen die in onze zoekmachine ingebouwd zitten, oplossen. Zij kunnen die connecties leggen onder de motorkap."

De technologie zou bijvoorbeeld voor webshops gebruikt kunnen worden. Bij een online winkel die pompoenzaden verkoopt kan de AI-zoektechnologie ervoor zorgen dat die producten ook verschijnen tussen de zoekresultaten als de klant zoekt op 'Halloween', zelfs als er op de site nergens een verwijzing wordt gemaakt naar Halloween. De geïntegreerde database legt dan zelf de connectie tussen 'pompoenen' en 'Halloween'.

Een 'traditionele' zoekmachine als Google maakt allang gebruik van dergelijke AI-technologie. Alleen kan Google dan weer niet gebruikt worden als database, verklaart Van Luijt. "Het is net tomatensoep. Van tomaten kun je tomatensoep maken, maar van tomatensoep kun je geen tomaten maken. Je kunt niet zeggen: goh, de tomatensoep genaamd Google Search smaakt wel heel lekker, dus doe mij maar een paar van die tomaten om mijn data in te hangen. Zo werkt het niet. Je kunt ook niet zeggen: Airbnb werkt wel heel goed voor het vinden van slaapplekken, laat ik dat nu gebruiken voor het vinden van airbikes, bijvoorbeeld."

Stug zoekprobleem

Het idee van Weaviate ontstond zo’n zes jaar geleden. Van Luijt was als freelance IT-consultant al veel bezig met data structureren toen begin 2016 het piepjonge algoritme Word2Vec onder zijn aandacht kwam. Dit algoritme kan van elk individueel woord van een tekstcorpus een vector maken. Vectoren zijn een soort coördinaten die zich in de honderden dimensies bevinden. Aan één woord kunnen in de vectorruimte meer dan duizend coördinaten gehangen worden. Door met Word2Vec vectoren van woorden te maken, kan het algoritme die associëren met bijpassende woorden. Hoe meer semantische connecties woorden met elkaar hebben, hoe dichter de coördinaten van die woorden bij elkaar geplaatst worden in die vectorruimte. Het algoritme gebruikt verschillende bronnen, zoals Wikipedia, om die connecties te bepalen.

Google vond die vectortechnologie ook wel interessant. Kort voordat Van Luijt Word2Vec ontdekte, maakte Google bekend bezig te zijn met iets genaamd 'RankBrain'. Dit zoekresultaatalgoritme moest op termijn PageRank gaan vervangen, omdat RankBrain meer gebruik ging maken van die vectoren en machinelearning om betere zoekresultaten te kunnen leveren. Van Luijt kwam erachter dat er helemaal nog niet gewerkt werd aan een dergelijke technologie om het zoekprobleem in databases op te lossen, terwijl dat voor veel mensen nog altijd een hoop ergernissen oplevert. Nu hij wist van het bestaan van die machinelearninginnovaties, besloot hij iets te gaan ontwikkelen.

In zijn vrije tijd werkte Van Luijt mondjesmaat aan het concept, maar in 2017 kon hij het ook in de praktijk gebruiken toen hij werd ingezet voor een freelance iot-project bij ING. "Dat had ook te maken met het structureren van data en daar efficiënt doorheen zoeken, een beetje een semantischwebidee", blikt Van Luijt terug. Voor dat project zag hij de gouden kans om Weaviate in te zetten om data van verschillende bronnen aan elkaar te linken door graphverbindingen en de vectoren. Dat werkte behoorlijk goed.

Iemand binnen ING Labs, de start-upaccelerator van de bank, zag dat ook in en gaf Van Luijt de kans om verder aan de software te werken binnen de accelerator. Daar ontmoette hij Micha Verhagen en Etienne Dilocker, die ook enthousiast waren over Weaviate. Dilocker stelde voor om met z’n drieën een bedrijf te beginnen waarmee ze de AI-zoekmachine van de grond af aan zouden opbouwen. En zo geschiedde.

Een visualisatie van het abstracte concept van vectoren: elk bolletje is een vector (coördinaat) en wordt met de machinelearningalgoritmes in een digitale, multidimensionale ruimte geplaatst. Hierbij worden vectoren die veel semantische connecties hebben dichter bij elkaar geplaatst. 'Appel' en 'banaan' zijn beide stukken fruit, en staan dus, bijvoorbeeld, dichter bij elkaar dan 'appel' en 'vlees', die minder overeenkomsten hebben.

Gegevens vectoriseren

De intelligente zoektechnologie die Weaviate gebruikt wordt 'word embedding aan de hand van machinelearning' genoemd, legt Van Luijt uit. Om deze in de software te kunnen gebruiken, moeten in de eerste plaats de juiste machinelearningmodellen ingezet worden. De modellen die in Weaviate geplaatst zijn, worden net als de api's niet zelf gemaakt, maar geadopteerd, bijvoorbeeld van Hugging Face of andere opensourceplatformen. Ze hebben allerlei verschillende taken. Als een gebruiker met Weaviate wil zoeken, worden er meerdere van die modellen gebruikt om het juiste antwoord te vinden.

Bij het stellen van een vraag, zoals 'Wat is de populatie van Californië?', wordt er bijvoorbeeld eerst een zoekalgoritme gebruikt die zo snel mogelijk een stuk of twintig kandidaten terugstuurt. Het algoritme verwacht dat in een van die kandidaten het antwoord verstopt zit. Omdat dat nog steeds veel eigen zoekwerk vereist, wordt daarna een ander soort machinelearningmodel gebruikt: een question-answeringmodel. Dat gaat nog een keer door die twintig kandidaten heen en bepaalt dan in welke van de twintig het juiste antwoord verstopt zit. De truc is alleen om dat alles in zo weinig mogelijk milliseconden voor elkaar te krijgen.

Een voorbeeld van hoe zoeken met Weaviate werkt: links is de query 'huizenprijzen' ingevuld met als voorwaarde dat alleen artikelen van de Financial Times gebruikt mogen worden met meer dan 500 woorden. Rechts staat het artikel waarvan de AI met zo’n 75 procent zekerheid denkt dat het het juiste antwoord bevat

Efficiëntiekwesties

De software zo snel en efficiënt mogelijk die vectoren te laten zoeken en dus door de data te laten fietsen, was een grote uitdaging gedurende het gehele ontwikkelproces. Van Luijt: "Als je dat normaal doet op een zogeheten bruteforcemanier, wordt je applicatie supertraag. Dat gaat niet, dus moesten we een andere oplossing verzinnen."

De oplossing is uiteindelijk gevonden in algoritmes die approximate nearest neighbor worden genoemd. "Als je een query in de vectorruimte plaatst, probeert dat algoritme naar de dichtstbijzijnde buur te gaan, want dat is waarschijnlijk het antwoord op je vraag", legt Van Luijt uit. Door een schatting te maken in plaats van honderd procent zekerheid te vereisen, wordt veel geheugen bespaard en bovendien gaat dat een stuk sneller. De snelheidskous is daarmee niet af: dat aspect blijft volgens Van Luijt nog dag in dag uit een uitdaging.

Er zijn een heleboel lastige vraagstukken waar Weaviate nog dagelijks antwoorden op zoekt. Van Luijt somt er een aantal op. "Hoe kun je de import zo efficiënt mogelijk doen aan de hand van een algoritme, dus hoe bouw je zo efficiënt mogelijk zo’n index op? Hoe kun je dat zo goedkoop mogelijk doen? Hoe kun je je memoryfootprint zo laag mogelijk houden? Hoe kun je zo veel mogelijk op een disk opslaan, want dat is efficiënter dan data in-memory opslaan, en hoe kun je dat doen terwijl de userexperience zo efficiënt mogelijk blijft? Hoe kun je de snelheden om te indexeren en te queryen verhogen?"

'Als een gebruiker een usecase heeft waar onze technologie wel voor geschikt is, maar diegene denkt dat dat niet zo is, is dat het ergste wat kan gebeuren'Er wordt volgens Van Luijt momenteel research over al die vragen gedaan en gepubliceerd, waarbij er telkens gekeken wordt of de nieuwgevonden oplossingen bruikbaar zijn voor Weaviate. Deze snelheids- en efficiëntiekwesties zijn niet zo een-twee-drie op te lossen en daarmee erg hardnekkig: het perfecte antwoord is nog niet gevonden en over vijftig jaar waarschijnlijk nog steeds niet.

Deficiënte documentatie

Behalve blijvende uitdagingen die zich diep in de softwarestack afspelen, vindt Van Luijt dat ook de userexperience zeker niet onderbelicht mag blijven: je kunt de perfecte oplossing bouwen, maar als gebruikers niet begrijpen hoe die software werkt of wat je ermee moet doen, kun je er niks mee. Ook dat blijft zwoegen. Van Luijt: "Als iemand onze technologie wil gebruiken, maar zijn usecase is niet geschikt voor onze database, is dat prima. Daar zijn andere databases voor. Als een gebruiker een usecase heeft waar onze technologie wel voor geschikt is, maar diegene denkt dat dat niet zo is, is dat het ergste wat kan gebeuren. Dan wil je meteen weten waarom."

Omdat Weaviate open source is, is het relatief makkelijk om met een grote hoeveelheid gebruikers in contact te komen en feedback te ontvangen. Daardoor wordt het meteen duidelijk als er verwarring ontstaat onder gebruikers. Zo herinnert Van Luijt zich nog een probleem met de opslag. Weaviate slaat de eerste 25 miljoen dataobjecten op via werkgeheugen, en gaat daarna over naar diskopslag. "Bij een database met 50 miljoen dataobjecten gaat je import dus eerst heel snel en na de eerste 25 miljoen heel langzaam, omdat-ie dan alles op een disk gaat opslaan."

Gebruikers begonnen alleen massaal aan Weaviate te vragen hoe het komt dat na die 25 miljoen datapunten ineens alles langzamer werd. "Wij kwamen er toen achter dat dat geen probleem was in de software, maar in de documentatie. We hadden niet uitgelegd aan de gebruiker: als je dit niet zelf instelt, zit er een limiet op van 25 miljoen. Je kunt dat dus gewoon instellen en verhogen." Het is volgens Van Luijt belangrijk dat gebruikers zoveel mogelijk kunnen aanpassen als ze dat willen, maar dan moeten ze dus wel weten hoe dat moet. Het is een belangrijke les die Weaviate heeft geleerd en ook de reden dat de documentatie op de website nu zo alomvattend is gemaakt.

De opslagdefault is door Weaviate niet al hoger gezet, omdat de memoryfootprint dan te hoog wordt, verduidelijkt Van Luijt. Ook hierbij is de afweging tussen efficiëntie, snelheid en geheugen dus leidend geweest.

Weaviates uitgebreide documentatie

Een gat in de kaas

Omdat de AI-zoekmachinetechnologie net nieuw was toen Van Luijt er met zijn team op dook, heeft hij als groot voordeel dat zijn bedrijf een voorsprong heeft op veel van de directe concurrentie. Dat betekent niet dat hij volledig vrij spel heeft, want naast de directe concurrent is er bij databasetechnologie nog een tweede belangrijke concurrentiegroep: displacementconcurrentie, noemt Van Luijt die. "Mensen hacken zoekmachines die al bestaan en voegen er allerlei toeters en bellen aan toe om op die manier een oplossing te creëren."

Hoewel zoiets volgens Van Luijt zelden goed uitpakt en er uiteindelijk toch een gericht product moet komen, noemt hij het logisch dat zo’n houtje-touwtjeoplossing wel altijd eerst geprobeerd wordt. "Softwareontwikkeling is niks anders dan: er is ergens een oplossing voor, mensen willen meer, ze hacken er allerlei shit omheen, en op een gegeven moment begint die toren te wiebelen en valt-ie om. Op dat punt moet je nieuwe software van begin af aan opbouwen om dat specifieke, nieuwe probleem op te kunnen lossen."

'Dit is echt nog maar het begin van Weaviate'

Dat wordt de disruptietheorie genoemd, legt Van Luijt uit. "Technologie ontwikkelt zich en mensen willen steeds meer. Dan ontstaat er, vanuit een dichte kaas, op een gegeven moment een soort gatenkaas. Mensen willen meer en dus trekken ze de kaas als een elastiek uit elkaar. In dat gat kun je vervolgens springen. Dat hebben wij gedaan." Geen 'gat in de markt' dus, maar een 'gat in de kaas', noemt Van Luijt zijn businessidee om met vectoren door data te zoeken.

Weaviate is er alleen nog niet. Hoewel de software 'versie 1.0' al voorbij is, zegt Van Luijt nog niet helemaal tevreden te zijn over de mogelijkheden van de software. Voordat dat punt is bereikt, moet er nog een hoop gebeuren. Nóg meer data opslaan aan de hand van machinelearningmodellen, ofwel vectoriseren, is een grote uitdaging waar het bedrijf nu voor staat. "Er is een bedrijf dat in real time al het nieuws dat binnenkomt, bijvoorbeeld nu over Oekraïne, wil vectoriseren. Het is superwaardevol als je al het nieuws wat daarover wordt gepubliceerd, in alle talen, kunt vectoriseren en daar door die machinelearningmodellen trends uit kunt laten komen. Je kunt je voorstellen hoeveel data daar nu in real time over binnenkomt: miljarden datapunten en vectoren. Dergelijke cases zijn nu alleen nog echt te hoog gegrepen."

Omdat deze markt van AI-first-databasetechnologie zo nieuw is, is het volgens Van Luijt ook nog gewoon een kwestie van wachten op nieuwe ontwikkelingen en daar op inspringen. Hij maakt zich er momenteel dus geen zorgen over. "Dit is echt nog maar het begin. Wij zijn nu net bezig een eigen kaas te maken die nog volop aan het groeien is, en wie weet hoe dat er over twintig jaar uitziet."

Techuitdagingen van start-ups

In de serie Techuitdagingen van start-ups lichten we de technische problemen waar jonge start-ups mee worstelen uit. Ken je kleine techstart-ups met een interessant verhaal? Laat het ons weten. Let op: het gaat niet om commerciële uitingen en de redactie bepaalt onafhankelijk of een onderwerp interessant genoeg is.

Eerder in deze reeks verschenen:

• DuckDB's databasesysteem voor snelle analyses
• Een braillecontroller voor smartphones
• Een buitenspeelcontroller ontwerpen

Dit artikel kun je gratis lezen zonder adblocker

Alle content op Tweakers is gratis voor iedereen toegankelijk. Het enige dat we van je vragen is dat je de advertenties niet blokkeert, zodat we de inkomsten hebben om in Tweakers te blijven investeren. Je hoeft hierbij niet bang te zijn dat je privacy of veiligheid in het geding komt, want ons advertentiesysteem werkt volledig zonder thirdpartytracking.

Bekijk onze uitleg hoe je voor Tweakers een uitzondering kunt maken in je adblocker.

Ben je abonnee? Log dan in.

Reacties (8)

Vroeger was er custom development nodig om dit voor elkaar te krijgen terwijl het nu OOTB komt. Recent heeft Elastic ook al support voor NLP inference voorzien: https://www.elastic.co/gu...arning/master/ml-nlp.html.
Dit lijkt nu effectief de volgende stap te worden in het search engine domein.

*opa met een vraag hier*
Wat mij opvalt is dat er heel veel functionaliteit die in een database zit ongebruikt blijft. Ik heb databases met miljarden records beheerd met stored procedures, functions etc. en vraag me vaak af waarom alles buiten de database moet. Het AI deel lijkt (misschien geheel onterecht) dan niet zo heel baanbrekend, maar meer een alternatieve oplossing voor iets wat al kon. Het zou mooi zijn als iemand dat uit kan leggen want uit het stuk van tweakers haal ik dat niet.
*opa modus uit*

Wanneer je data zich in een database bevindt is het inderdaad niet eenvoudig om de keuze te maken. Het hangt dan af van de mogelijkheden van je DB, maar ook van de kennis van je technische mensen en niet onbelangrijk: hoe professioneel is je DB opgezet.
Beschik je over de mogelijkheid met je DB om ngrams/fields weights/custom relevance ranking toe te passen?
Heb je een OLTP/OLAP setup? Is je OLTP voorzien om x aantal searches per sec. met een joins van X tabellen te ondersteunen terwijl je transacties geen hinder ondervinden? Hoe uptodate is de data in je OLAP, kan deze de nodige performance leveren?

Vooral dat laatste is een belangrijk punt om te kiezen voor een dedicated search engine: snelheid en performance impact. Persoonlijk vind ik het belangrijk om zo volledig mogelijk gebruik te maken van de search mogelijkheden die de beheertool van je data je geeft. Pas daarna ga je kijken naar een dedicated search engine.

Maar in sommige gevallen gaat het ook om data die niet in een DB zit, bvb contracten in PDF/Office/image formaten, documentatie in bestanden, etc. en dan dan kom je automatisch bij een dedicated search engine terecht.

Stored procedures etc. ondersteunen geen neurale netwerken. En als je ze zelf zou ontwerpen binnen de bestaande mogelijkheden, dan zou het ontzettend veel trager zijn.
De woorden waarop gezocht wordt staan niet in de bestaande database. Maar zijn als een soort netwerk gelinkt aan elkaar en dat wordt gebruikt om clusters te vormen met zoekwoorden. Ipv te zoeken op 1 woord, zoals kan in sql, zoek je dus op het gehele cluster. Maar daarvoor moet je eerst de clusters gedefinieerd hebben. En dat kan dus met AI (met een variant op een neuraal netwerk).
Je zoekt op meat en krijgt resultaten voor chicken en misschien ook fish (zie plaatje in het artikel)

[Reactie gewijzigd door Anoniem: 450173 op 3 april 2022 13:32]

Volgens mij, als ik het goed begrijp, wil men dat je vragen kan beantwoorden waarvan je van tevoren niet weet dat die gesteld worden.

In normale databases (die idd makkelijk miljoenen tot miljarden records kunnen doorzoeken) kan je vragen snel beantwoorden... mits je weet wat gevraagd gaat worden (want daar bouw je dan je indexes op en je zet je data zo klaar dat de vraag ook snel beantwoord kan worden als je relaties er bij wilt zoeken).

Het item heet “een AI zoekmachine voor databases”, dus vandaar dat ik me interesseer in wat dit toe gaat voegen. In een DB kun je best data hebben/opbouwen waarvan iets is te vertellen wat je nog niet wist. (ondanks dat alles vast staat in tabellen en velden.)

Da databases zijn een probleem voor zoekmachines. Ik heb hier 15 jaar geleden al aan gewerkt.
Steeds meer zaken zijn inmiddels in databases opgeslagen en niet meer in gewone HTML- pagina's.
Voor zoekmachines zijn databases moeilijk toegankelijk. Veel databases hebben wel een zoekmachine, maar die werken volgens veel verschillende manieren. De inhoud van de databases is dan verborgen voor het grootste deel van de wereld.

Interessant stuk,
Heb zelf een accelerator geschreven welke een veel simpeler database moet doorzoeken, een CAN database, waar een in komend bericht gematch moet worden aan een index in het geheugen van pakweg 60.000 indexes groot.
Een simpele for(i=0, i<60k, i++) doet er soms 5 seconden over op een Atmega328p,
Met accelerator algoritme, 1 tot 2 mS. (Hoewel ik een for altijd vermeid omdat je tijdens je for geen andere instructies kan uitvoeren).
Het vergt alleen 64byte aan Sram om me hash in te laden.