Stel je dit eens voor, je bent aan het werk in een bedrijfsapplicatie. Misschien is het het oude, portaal, een klantenservice, database of de interne wiki met al die regels die je moet volgen. Je typt een vraag in de zoekbalk. Iets als, hoe dien ik een onkostennota in voor een klantendiner? Je drukt op enter en wat krijg je? Niets. Of erger nog, een lijst met willekeurige pdf's van drie jaar geleden die min of meer overeen komen met de woorden die je hebt getypt. Zoeken is iets wat we elke dag doen. En meestal is het verschrikkelijk. Maar het punt is, dat hoeft niet zo te zijn. Wat als je apps echt zouden begrijpen wat je vraagt? Wat als ze konden zoeken zoals Google en het juiste antwoord zouden vinden, zelfs als je niet de perfecte woorden gebruikt? Vandaag bespreken we Azure Eyes' arch. Wat het precies is, hoe het onder de motorkap werkt en waarom het de zoekmachine is waarop moderne apps zijn gebouwd.

Pak je koffie erbij en laten we beginnen. Waarom zoeken niet goed werkt? Om te begrijpen waarom zoeken meestal faalt, moeten we kijken hoe de meeste apps dat eigenlijk doen. De traditionele manier heet trefwoordzoekopdracht of lexicaal zoeken. Je typt het woord laptop in het vak en het systeem zoekt elk document op dat precies dat woord bevat. Onder de motorkap gebruiken veel van deze systemen een algoritme genaamd BM25. Het is niet ingewikkeld, maar op zijn eigen manier wel slim. BM25 rangschikt resultaten op basis van een paar factoren. Hoe vaak je zoekterm in een document voorkomt, hoe lang het document is en hoe zeldzaam de zoekterm is in de gehele dataset. Zie het als een zeer geavanceerde woordenteller die op basis van die factoren bepaalt welke documenten het meest relevant zijn. Dit is waar het misgaat. Menselijke taal is rommelig. Mensen stellen vragen niet met dezelfde woorden als die in de documenten worden gebruikt.

Laat me een concreet voorbeeld geven. Een gebruiker typt dit in een ondersteuningsportaal. Mijn laptop loopt steeds vast tijdens videogesprekken. Een trefwoordzoekopdracht zal braaf zoeken naar documenten die laptop, loopt, vast, tijdens, video en, gesprekken, bevatten. Maar wat als het beste artikel over dit onderwerp de titel heeft problemen met systeemvastlopers tijdens Teams vergaderingen oplossen? Of CPU-frotteling beheren op laptops in een dockingstation? De trefwoordzoekopdracht mist die volledig. Waarom? Omdat de woorden niet overeen komen. Het kernprobleem is dit. Trefwoordzoeken begrijpt spelling. Het begrijpt karakterpatronen, maar het begrijpt geen betekenis. Je krijgt resultaten met de juiste letters, maar vaak met de verkeerde inhoud. Dus als exacte woordovereenkomst zoveel gaten laat vallen, wat is dan het alternatief? De nieuwe manier, vectorse arg. Vectorse arg is dus een compleet andere manier van werken.

In plaats van exacte woorden te matchen, matcht het de betekenis. Dat klinkt abstract, dus laten we het vereenvoudigen. De simpelste definitie die je moet weten is, een vector is gewoon een lijst getallen die iets voorstelt waar een computer mee kan werken. Dat is alles een lijst met getallen. Een embedding is een speciaal soort vector die de betekenis van tekst vastlegt. Het neemt een zin, een alinea, of zelfs een heel document en zet dit om in een lange reeks getallen. De computer begrijpt de woorden niet, maar wel de getallen. Hier is een analogie die helpt. Zie factoren als coördinaten op een kaart. Op een kaart liggen vergelijkbare plaatsen dicht bij elkaar. In vectorruimte komen vergelijkbare concepten dicht bij elkaar te staan. De vector voor koning en de vector voor koningin liggen bij elkaar omdat ze verwante ideeën vertegenwoordigen. De vector voor koning en de vector voor appel liggen ver uit elkaar.

De computer weet niet wat koning in menselijke zin betekent, maar kan de afstand meten tussen de coördinaten en die van elk ander woord of document. Het is alsof je een gps hebt voor ideeën. Het systeem weet hoe ver concepten uit elkaar liggen door simpelweg naar de getallen te kijken. Wanneer je zoekt met factoren, zet het systeem je zoekopdracht om in een embedding. Vervolgens vindt het de documenten waarvan de embeddings het dichtst bij die van jou liggen. Het vindt zaken die semantisch vergelijkbaar zijn, die betekenis delen, niet alleen woordenschat. Stel je voor dat je zoekt naar een document over het oplossen van problemen met een bevroren laptop. Bij zoekwoorden moet je precies bevroren of vastlopen typen. Maar met vectorse arg kun je typen, mijn computer loopt steeds vast en vindt het het juiste document. Dat is de kracht van het begrijpen van betekenis. Laten we teruggaan naar ons voorbeeld van de defecte zoekopdracht.

Een gebruiker typt, mijn laptop loopt steeds vast. Met vectorse arg kan het systeem het artikel over systeemvastlopers tijdens Teams vergaderingen tonen, ook al komen die woorden niet in de zoekopdracht voor. Waarom? Omdat de betekenis van systeemvastloper in vectorruimte heel dichtbij, computer loopt vast, ligt. Deze concepten bevinden zich dicht bij elkaar op die kaart. Het systeem geeft niet om de exacte woorden, het geeft om wat je bedoelt. Dit is de doorbraak. Computers beginnen intentie te begrijpen, niet alleen spelling. Ze vinden antwoorden die een zoekopdracht op trefwoorden volledig zou missen. Maar vectorse arg heeft ook een zwakte. Het kan exacte overeenkomsten missen die absoluut cruciaal zijn. Als een technicus zoekt naar een specifieke foutcode zoals fout X80070570, geeft een vectorzoekopdracht mogelijk prioriteit aan documenten over schijfouten of best NS-systeem corruptie in plaats van aan het exacte document dat die specifieke code ontleed.

Het ruilt precisie in voor begrip. We hebben dus twee methoden. Zoeken op trefwoorden is geweldig voor precisie. Het vindt exact de juiste termen, product-idees en contractnummers. Vectorzoeken is geweldig voor betekenis. Het vindt het juiste antwoord, zelfs als je niet de juiste woorden gebruikt. Elk heeft zijn blinde vlekken. En dat roept hem voor de hand liggende vraag op. Wat als je beide benaderingen zou kunnen combineren en het beste van beide werelden zou krijgen? De hybride doorbraak. Hybride zoeken is het beste van beide werelden. Het voort zowel zoekopdrachten op trefwoorden als vectorzoekopdrachten tegelijkertijd uit en combineert vervolgens de resultaten tot één gerangschikte lijst. In plaats van de ene benadering boven de andere te kiezen, gebruikt het systeem een methode genaamd Reciprocal Rank Fusion of RRF. Zo werkt het. RRF kijkt naar waar elk document staat in de trefwoordresultaten en waar het staat in de vectorresultaten.

Vervolgens geeft het een gecombineerde score. Als een document in beide goed scoort, krijgt het een boost. Het is alsof je twee deskundige adviezen neemt en daar het gemiddelde van berekend. Het uiteindelijke antwoord is betrouwbaarder dan elk afzonderlijk. Dit is belangrijk omdat zoeken op trefwoorden en vectorzoeken fundamenteel verschillende sterke punten hebben. Zoeken op trefwoorden blinkt uit in exacte overeenkomsten. Het is je eerste keuze voor productidees, contractnummers, specifieke namen en foutcodes. Het is precies en voorspelbaar. Vectorzoeken blinkt uit in semantische gelijkenis en vindt documenten die dezelfde betekenis delen als je zoekopdracht, zelfs als de exacte woorden niet voorkomen. Samen dekken ze elkaars blinde vlekken af. Het systeem vangt exacte overeenkomsten en conceptuele overeenkomsten in één zoekopdracht. Dat is de ware kracht. En dit is niet alleen theoretisch.

Onderzoek naar hybride enterprise zoeken toont aan dat het 70 tot 80 procent nauwkeurigheid bij het ophalen levert, afhankelijk van de dataset. Dat is ongeveer 15 tot 20 procentpunt hoger dan wat je krijgt met alleen vectorzoeken. Het verschil is aanzienlijk en het is zichtbaar in echte bedrijfsresultaten. Neem het boekhoud Platform Zero. Zij implement eerder hybride zoeken in hun klantenservice via een bedrijf genaamd Coveo. Binnen drie maanden zagen ze een stijging van 20 procent in zelfoplossing. Klanten vonden vaker zelf antwoorden zonder contact op te hoeven nemen met de ondersteuning. Andere klanten in hetzelfde onderzoek zagen een vermindering tot 40 procent in de tijd die nodig was om ondersteuningscases op te lossen. Dat betekent dat medewerkers sneller de juiste informatie vonden, klanten sneller antwoorden kregen en de ondersteuningskosten daalden. Dat is niet zomaar een leuke extra functie, het is een meetbare impact op het bedrijfsresultaat.

Dit is het belangrijkste punt. Hybride zoeken is niet zomaar een leuke upgrade of een vinkje op een lijst met functies, het is meetbaar beter. Het levert betere precisie, betere recall en betere resultaten voor gebruikers op. En deze combinatie van benaderingen is wat Azure Isearch zo krachtig maakt voor moderne applicaties. Maar er is nog een technologie die deze combinatie ontgrendelt en die momenteel veel aandacht krijgt. Het heet RAG, de RAG Connectie. Dus, laten we het over RAG hebben. RAG staat voor Retrieval Augmented Generation, terughalverrijkte generatie. Dat is een hele mond vol, maar hier is de eenvoudigste definitie. Het is een framework dat AI-assistenten toegang geeft tot informatie waar ze niet op getraind zijn. Grote taalmodellen zoals GPT weten veel over geschiedenis, wetenschap en programmeren, maar ze kennen niet de interne documenten, het beleid, de klantgeschiedenis of de specifieke procedures van je bedrijf.

De meeste mensen denken dat je al die interne kennis zomaar in het model zelf kunt dumpen. Dat werkt niet. Het is duur en moeilijk om bij te werken. RAG lost dit op een slimme manier op. In plaats van alles in het model te proppen, haal je de relevante informatie uit een kennisbank op het moment dat iemand een vraag stelt. Je neemt de query van de gebruiker, doorzoekt je interne gegevens, vindt de meest relevante documenten en voert die context samen met de oorspronkelijke vraag in het LLM in. Het LLM genereert vervolgens een antwoord dat is gebaseerd op jouw data. Dat is de magie ervan. Nu, Azure Isearch is de retrieval helft van die vergelijking. Het is de motor die de juiste documenten vindt, zodat het LLM nauwkeurig kan antwoorden. Zonder een solide retrieval laag is een RAG-systeem slechts zo goed als de documenten die het vindt. En dit is waar hybride zoeken echt uitblinkt, omdat RAG-queries vaak vragen in natuurlijke taal zijn en de antwoorden vaak in documenten staan die totaal andere terminologie gebruiken.

Laat me je wat cijfers geven die het verschil echt laten zien. Een onderzoek naar Enterprise-applicatie zoeken toonde aan dat een hybride RAG-framework de top-k-retrieval nauwkeurigheid 18 tot 25 keer verbeterde ten opzichte van alleen zoeken op trefwoorden. De nauwkeurigheid van het voltooien van workflow-taken verbeterde met 21 keer. Dat betekent dat gebruikers veel vaker in staat waren om complexe taken succesvol af te ronden wanneer ze werden ondersteund door een RAG-systeem met hybride zoeken. Over het algemeen kunnen goed geïmplementeerde RAG-systemen de zoeknauwkeurigheid met gemiddeld 85% verhogen, waarbij sommige gespecialiseerde domeinen de 99% nauwkeurigheid benaderen. En omdat het LLM-antwoorden genereert op basis van opgehaalde context in plaats van op eigen gissingen, liet de RAG-systemen een vermindering van ongeveer 40% in gefantaseerde antwoorden zien. Dit is waarom Azure Ice Arch centraal staat bij het bouwen van AI-agenten en co-pilots.

Het biedt de gefundeerde, feitelijke retrieval die LLM's betrouwbaar maakt in een zakelijke context. Als je een assistent bouwt die vragen nauwkeurig moet beantwoorden en bronnen moet vermelden, is hybride zoeken plus RAG de architectuur die je nodig hebt. Hybride zoeken en RAG vormen dus een krachtige combinatie. Maar hoe ziet dit er in de praktijk eigenlijk uit? De impact in de echte wereld. Waar zie je dit in de praktijk terug? Ik geef je een paar voorbeelden. E-commerce is waarschijnlijk het meest bekende voorbeeld. Een klant typt comfortabele hardloopschoenen in de zoekbalk. De productpagina spreekt misschien van gedempte sportschoenen, omdat het marketingteam andere woorden heeft gekozen. Zoeken op trefwoorden alleen zou de match volledig missen. Met Azure Ice Arch begrijpt het systeem dat comfortabel en gedempt in deze context ongeveer hetzelfde betekenen. Het toont het juiste product, zelfs als de woorden niet overeenkomen.

Dat is een klant die vindt wat hij zoekt, in plaats van gefrustreerd de site te verlaten. Klanten-service portals werken op dezelfde manier. Stel dat een klant typt, hoe zeg ik mijn abonnement op, het relevante beleid kan de titel, de eindiging van serviceovereenkomst, hebben. Hybride zoeken vindt dat document via trefwoordmatching op juridische termen, maar toont ook een gerelateerde FAQ over het vroegtijdig beëindigen van je plan via semantische gelijkenis. De klant krijgt een volledig antwoord in plaats van vijf verschillende artikelen door te spitten. Het ophalen van juridische documenten is er nog een. Advocaten moeten contracten doorzoeken op exacte clausules en sectieverwijzingen. Dat is puur terrein voor trefwoorden, maar ze moeten ook soortgelijke formuleringen in verschillende overeenkomsten vinden, zelfs als het woordgebruik verschilt. Hybride zoeken verwerkt beide in één zoekopdracht en in gereguleerde sectoren is het cruciaal voor compliance om precies te kunnen achterhalen waarom een resultaat verscheen.

Interne kennisbanken profiteren hier ook van. Een werknemer die zoekt naar vakantiebeleid krijgt het officiële ouder document, maar ook een relevante e-mail van de juridische afdeling over overdraagbare dagen en een recente update op het intranet. De zoekfunctie begrijpt dat al deze zaken met dezelfde vraag te maken hebben. Productie is een minder voor de hand liggend voorbeeld, maar wel een krachtige. Een technieke stiept oplossing voor oververhitting motor in de zoekinterface. Het systeem geeft de sectie voor probleemoplossing uit de handleiding, plus een gescand diagram met de relevante onderdelen. Ook al is het diagram een afbeelding, Azure Isearch kan de tekst erin extraheren en indexeren, zodat deze in de zoekresultaten verschijnt. De rode draad in al deze voorbeelden is ongestructureerde data. PDF's, Word documenten, e-mail, tickets for support, gescande afbeeldingen. Traditionele database queries en zoekopdrachten op trefwoorden waren nooit ontworpen voor dit soort data.

Azure Isearch is specifiek gebouwd voor deze wereld en hoe langer je ernaar kijkt, hoe duidelijker het wordt dat hybride zoeken niet zomaar een leuke extra is. Het is een fundamenteel onderdeel van hoe moderne applicaties worden gebouwd. Hoe de stukjes in elkaar passen, dus hoe werkt dit alles eigenlijk onder de motorkap? Azure Isearch heeft drie kerncomponenten, de gegevensbron, de indexeerfunctie en de zoekindex. De gegevensbron is de plek waar je informatie zich bevindt. Dit kan blobopslag zijn, een Azure SQL database, Cosmos DB of zelfs SharePoint. Het is het ruwe materiaal dat doorzoekbaar moet worden gemaakt. Zie het als de stapel documenten die wacht om georganiseerd te worden. De indexeerfunctie is de pijplijn die gegevens uit die bron leest, de inhoud extraheert, eventuele geconfigureerde AI-verrijkingen toepast en vervolgens de zoekindex opbouwt. Hier is een eenvoudige manier om het voor je te zien.

Stel je een bibliothecaris voor die een pakhuis vol boeken binnenloopt. Ze lezen elk boek, maken gedetailleerde aantekeningen, identificeren de belangrijkste thema's en entiteiten en organiseren alles in een kaartcatalogus. Dat lezen en aantekeningen maken is het indexeringsproces. De zoekindex is die kaartcatalogus. Het zijn niet de boeken zelf. Het is het gestructureerde, geoptimaliseerde systeem waarmee je in milliseconden precies vindt wat je nodig hebt. Wanneer je een zoekopdracht typt, gaat het systeem niet terug naar de originele documenten om ze te doorzoeken. In plaats daarvan raadpleegt het de index, die al precies weet waar alles zich bevindt. Deze voorbereidende organisatie wordt een geïnverteerde index genoemd. In plaats van documenten op te slaan met een lijst van de woorden die ze bevatten, sla je woorden op met een lijst van de documenten erin. Dat betekent dat wanneer je zoekt naar een term, je direct naar de juiste plek springt.

Niet bladeren door elke pagina. Het resultaat is een enorme snelheidswinst. In plaats van elk document te moeten scannen, wat langer duurt naarmate je data groeit, spring je direct naar de juiste locatie. Bij miljoenen documenten is dat het verschil tussen een zoekopdracht die seconden duurt en een milliseconde duurt. Dus, nu begrijp je wat Azure Eyes Arch is, hoe de kerncomponenten samenwerken en waarom hybride zoeken alles verandert. Laten we afsluiten met een paar dingen die je hiermee kunt doen. Ten eerste, begrijp je data. Als het al gestructureerd is, denk aan producttabellen in SQL, klantgegevens in een database, alles met nette rijen en kolommen, dan kun je dit direct opvragen met SQL. Azure Eyes Arch is gebouwd voor ongestructureerde tekst. Denk aan PDF's, e-mails, Word documenten en support tickets. Dat is waar het echte waarde toevoegt. Ten tweede, als je een RAG applicatie of AI-assistent bouwt, is Azure Eyes Arch met hybride zoeken de retrieval engine die je daarvoor wilt gebruiken.

Het geeft je exacte trefwoordovereenkomsten voor precisie en semantisch begrip voor context. Die combinatie levert betrouwbaardere en beter onderbouwde antwoorden op dan beide benaderingen afzonderlijk. Ten derde, maak de installatie niet te ingewikkeld. De Azure Portal heeft een wizard voor het importeren van gegevens. Koppel je blobopslag, configureer een paar instellingen en laat de indexerfunctie je eerste index bouwen. Je kunt je eerste zoekopdracht al binnen een uur uitvoeren. Dat is dus Azure Eyes Arch in begrijpelijke taal. Het neemt rommelige, ongestructureerde informatie en verandert die in doorzoekbare, AI-klare kennis. Bedankt voor het kijken, abonneer je en dan zie ik je in de volgende aflevering.