Semantisch zoeken is handig wanneer een klant een probleem beschrijft met andere woorden dan in de documentatie worden gebruikt. Het kan minder effectief zijn wanneer het belangrijkste onderdeel van de vraag een exacte productcode, een korte foutmelding of een modelnummer is.
Een ondersteuningssysteem heeft beide soorten bewijs nodig. Ik vind PostgreSQL een goed uitgangspunt, omdat de relationele gegevens van de applicatie en de metadata voor het ophalen van gegevens dicht bij elkaar kunnen blijven, terwijl het ontwerp voor het ophalen van gegevens nog in ontwikkeling is.
Laat verschillende zoekpaden kandidaten aanleveren
Bij een ‘dense vector search’ wordt onderzocht welke passages in de embeddingruimte dicht bij elkaar liggen. Bij een lexicale zoekopdracht wordt onderzocht welke passages overeenkomen met de termen uit de zoekopdracht volgens de geldende regels voor tekstverwerking. Geen van beide vragen is hetzelfde als “welke passage bewijst het antwoord?”.
Bij een zoekopdracht met een bekende SKU zou ik ook een speciaal pad voor exacte overeenkomsten overwegen. Bij het tokeniseren van tekstzoekopdrachten kunnen identificatiecodes worden opgesplitst of genormaliseerd, dus het exact opzoeken van producten zou niet volledig afhankelijk moeten zijn van een zoekconfiguratie op basis van natuurlijke taal.
In de documentatie van pgvector wordt beschreven hoe het opzoeken van vectoren kan worden gecombineerd met de full-text-zoekfunctie van PostgreSQL, en wordt ‘rank fusion’ of een ‘cross-encoder’ aanbevolen om de resultaten te combineren. Ik gebruik deze technieken als mogelijke opties om te evalueren, in plaats van ervan uit te gaan dat het toevoegen van meer stappen het resultaat automatisch moet verbeteren.
Pas beperkingen met betrekking tot eigendom en beschikbaarheid in een vroeg stadium toe
De tenant, de zichtbaarheid van documenten, de publicatiestatus en de relevante markt moeten worden meegenomen bij de selectie van kandidaten. Het doorzoeken van alle tenants en het vervolgens filteren is zowel een autorisatieprobleem als een rangschikkingsprobleem.
Hetzelfde probleem doet zich voor bij benaderende vectorindexen. Als restrictieve filters te weinig geschikte resultaten opleveren, onderzoek ik het queryplan en het opvraaggedrag voor de geïnstalleerde versie van de uitbreiding. Het verhogen van het totale aantal kandidaten is geen vervanging voor het meten van de gefilterde werklast.
Ik hanteer een referentiepunt voor exacte zoekopdrachten op een overzichtelijke evaluatiedataset. Dit helpt om onderscheid te maken tussen verliezen die het gevolg zijn van benaderende indexering en fouten die worden veroorzaakt door embeddings, chunking of het corpus zelf.
Ranglijsten combineren zonder te doen alsof de scores gelijkwaardig zijn
Een lexicale relevantiescore en een vector-gelijkenisscore hebben doorgaans verschillende betekenissen en verdelingen. Door hun ruwe waarden met willekeurige wegingen bij elkaar op te tellen, kan het resultaat gevoelig worden voor veranderingen in één van de componenten.
Op rang gebaseerde fusie biedt een nuttig alternatief. De volgende pseudocode illustreert het idee; het is geen geoptimaliseerde productieconfiguratie:
for each ranked result list:
for each candidate at rank r, starting at 1:
score[candidate.id] += 1 / (rank_constant + r)
return candidates ordered by combined scoreDe rangconstante bepaalt in hoeverre de bovenste posities de overhand hebben. Ik stel deze vast op basis van evaluatie, samen met de omvang van de kandidatenpool en eventuele latere herrangschikkingsfasen. Deze parameters moeten samen met de zoekconfiguratie in een versie worden vastgelegd.
De identiteit van de bron behouden gedurende het hele verwerkingsproces
Een fragment moet zijn document-ID, versie, sectie, taal en metagegevens over de toegang behouden. Na het samenvoegen en opnieuw rangschikken moet de generator nog steeds weten waar het bewijsmateriaal vandaan komt en welke bronversie het vertegenwoordigt.
Ik beperk ook het herhalen van passages uit één document wanneer deze nuttige alternatieven verdringen. Dat is een afweging ten gunste van diversiteit, waarbij er voor- en nadelen tegenover elkaar staan: voor sommige vragen zijn meerdere aangrenzende passages echt nodig. Een strikte regel van één passage kan noodzakelijke context wegnemen.
In het overzicht van de full-text-zoekfunctie van PostgreSQL wordt uitgelegd hoe documenten en zoekopdrachten worden genormaliseerd om overeenkomsten te vinden. Bij een meertalig corpus is het belangrijk om aandacht te besteden aan de taalconfiguratie, vooral wanneer productcodes intact moeten blijven.
Maak de werkwijze niet ingewikkelder dan het bewijsmateriaal rechtvaardigt
Ik vergelijk lexicale retrieval, dense retrieval, een combinatie daarvan en eventuele herrangschikkingsfasen aan de hand van dezelfde vragen. Het overzicht omvat beantwoordbare gevallen, vragen waarvoor geen ondersteuning bestaat, exacte identificatiegegevens en verschillende talen.
Een hybride ontwerp rechtvaardigt de extra vertraging en onderhoudskosten wanneer het op betrouwbare wijze bewijsmateriaal oplevert dat door eenvoudigere alternatieven over het hoofd wordt gezien. Het nuttige resultaat is een beter onderbouwd antwoord, niet een uitgebreider opzoekingsschema.
Bijgewerkt op 25 september 2026.