Een klassieke database ordent rijen en kolommen: klanten, bestellingen, datums. Ze vindt informatie terug wanneer u een exact criterium geeft. Een vectordatabase ordent iets anders: embeddings, reeksen getallen die de betekenis van tekstpassages voorstellen. Ze vindt de passages waarvan de betekenis het dichtst bij een vraag ligt, ook als de woorden verschillen.
Waarvoor een vectordatabase dient
In een AI-assistent die passages op betekenis zoekt, speelt de vectordatabase de rol van index. De werking verloopt in drie stappen:
- Het laden: elk document van de kennisbank wordt in passages geknipt, elke passage krijgt haar embedding, en het geheel wordt in de vectordatabase opgeslagen met een verwijzing naar het oorspronkelijke document
- Het zoeken: de vraag van de bezoeker krijgt op haar beurt een embedding, en de database stuurt de passages terug waarvan de vectoren het dichtst liggen
- Het antwoord: die passages gaan naar het taalmodel, dat het antwoord schrijft en het oorspronkelijke document kan citeren
Die drie stappen vormen het hart van RAG, retrieval-augmented generation. De vectordatabase maakt de tweede stap snel, ook met honderdduizenden passages.
Hoe ze dichtbije passages vindt
Een vraag één voor één met elke passage vergelijken, wordt traag bij een groot volume. Vectordatabases gebruiken indexen voor benaderend zoeken naar de dichtstbijzijnde buur, die de vectoren zo ordenen dat de dichtstbijzijnde zeer snel gevonden worden zonder alles te doorlopen. Het resultaat is niet altijd het absoluut dichtstbijzijnde, maar ligt er dicht genoeg bij voor het gebruik, met een grote tijdwinst.
De nabijheid wordt meestal gemeten met cosinusgelijkenis, die de richting van twee vectoren vergelijkt. Twee passages over hetzelfde onderwerp wijzen in gelijkaardige richtingen, ongeacht hun lengte.
Bestaande oplossingen
Er zijn twee grote families van tools:
- Gespecialiseerde databases, alleen voor vectoren ontworpen, zoals Pinecone, Weaviate, Qdrant of Milvus
- Uitbreidingen van klassieke databases, zoals pgvector voor PostgreSQL, die vectorzoeken toevoegen aan een database die al voor de rest van de toepassing gebruikt wordt
Voor een toepassing van redelijke omvang volstaat de uitbreiding van een bestaande database vaak, en vermijdt ze extra systemen om te onderhouden. Gespecialiseerde databases zijn zinvol bij zeer grote volumes of geavanceerde zoekbehoeften.
Wat een vectordatabase niet doet
- Ze controleert geen feiten. Ze vindt passages met een gelijkaardige betekenis; ze weet niet of een ervan de vraag correct beantwoordt of actueel is
- Ze vervangt het sorteren van documenten niet. Een oude prijslijst in de database wordt even makkelijk teruggevonden als de nieuwe
- Ze behandelt exacte termen niet alleen. Een bestelnummer, een productreferentie of een postcode vindt u beter met klassiek zoeken. Veel systemen combineren beide, wat hybride zoeken heet
- Ze is geen gespreksgeheugen. Ze indexeert documenten, niet wat bezoekers zeiden, tenzij men er uitdrukkelijk voor kiest dat erin op te slaan
Vectordatabase en persoonsgegevens
Uit een embedding valt de oorspronkelijke tekst niet makkelijk terug te lezen, maar hij is ervan afgeleid en blijft er in de database aan gekoppeld. Bevat een document persoonsgegevens, dan bevatten zijn passages en vectoren die onrechtstreeks ook. De regels van de AVG zijn dus van toepassing: een document verwijderen moet zijn passages en vectoren verwijderen, en de hosting van de database hoort bij de verwerkingsketen die gedocumenteerd moet worden.
Heeft een kmo-assistent een vectordatabase nodig?
Niet noodzakelijk. Een vectordatabase wordt nuttig wanneer de documentatie te omvangrijk is om bij elke vraag volledig gelezen te worden. Met de grote contextvensters van de huidige modellen kan een kmo waarvan de kennisbank uit enkele tientallen documenten bestaat, ze vaak volledig aan het model geven. Die aanpak vermijdt passages die het zoeken mist of die van hun context afgesneden zijn, ten koste van meer tokens per vraag.
KernChat koos daarvoor: de bronnen van de kennisruimtes gaan volledig in de context van het model, in prioriteitsvolgorde, en een rangschikking op gemeenschappelijke woorden met de vraag beslist tussen de bronnen wanneer ze niet allemaal passen. Voor een organisatie waarvan de documentatie sterk zou groeien, blijft zoeken op betekenis met een vectordatabase een mogelijke evolutie.