Zoeken in de ontologie wint het van zoeken in documenten

Opgeruimde grijze archiefkasten met gelabelde ordners in een moderne archiefruimte, één ordner met een blauwe tab half uitgetrokken en een hand die ernaar reikt, geringe scherptediepte

Een bedrijf koppelt een taalmodel aan zijn documentopslag: contracten, procedures, beleidsstukken, vergadernotities, jaren aan materiaal. Dit heet retrieval-augmented generation, meestal afgekort tot RAG: als iemand een vraag stelt, zoekt het systeem de passages die er het meest op lijken en geeft die aan het model om het antwoord op te baseren.

Een medewerker van de klantenservice vraagt welke leveringsvoorwaarden een bepaalde klant heeft. Het systeem vindt drie versies van het contract met die klant, een conceptbijlage die nooit is ondertekend en een e-mail waarin iemand andere voorwaarden voorstelde. Het model smeedt ze samen tot een vloeiend, zelfverzekerd antwoord dat met geen van alle overeenkomt. Op een andere dag vindt het juist de algemene voorwaarden van het bedrijf in plaats van de klantspecifieke bijlage die daarvoor in de plaats komt.

De oorzaak is de manier waarop zoeken in documenten werkt. Het vindt tekst waarvan de betekenis op de vraag lijkt. Het weet niet welke versie van kracht is, welk document een concept is, op welke klant een clausule van toepassing is, of dat een bijlage voorgaat op de algemene voorwaarden. Dat zijn geen eigenschappen van tekst. Het zijn statussen en relaties, en precies die vastleggen is de taak van een model van het bedrijf: een ontologie.

Waar zoeken in documenten misgaat

Versies. Een vervangen contract lijkt net zo veel op de vraag als het huidige, dus wordt het net zo makkelijk gevonden. Gelijkenis kent het begrip „van kracht” niet.

Relaties die bij het knippen verloren gaan. Documenten worden vóór het indexeren in stukken gesneden. Een clausule over leveringsvoorwaarden komt in het ene stuk terecht, de pagina met de naam van de klant in een ander, en het verband tussen beide is weg.

Vragen die eigenlijk tellingen zijn. „Hoeveel openstaande klachten heeft deze klant?” staat in geen enkel document. Het is een telling over records, en geen enkele mate van tekstgelijkenis levert die betrouwbaar op.

Rechten die te laat worden toegepast. Als de index documenten bevat die de vragensteller niet mag zien, is het achteraf wegfilteren ervan kwetsbaar, en één fout toont vertrouwelijke tekst aan de verkeerde persoon.

Actualiteit. De index is zo actueel als de laatste keer dat hij is opgebouwd. Het contract dat vanochtend is getekend, staat er nog niet in.

Bronvermeldingen die niets beslechten. Het antwoord citeert een passage, maar niets vertelt de lezer of die passage uit het document komt dat op dit moment van kracht is.

Eerst zoeken in het model, dan in documenten

Begin bij het object. De vraag noemt een klant. Koppel die aan het klantobject in de ontologie en volg dan de relaties: de contracten die van kracht zijn, hun bijlagen, openstaande orders, openstaande klachten. Het model van het bedrijf doet de afbakening die gelijkenis niet kan doen.

Doorzoek documenten die aan records hangen. Het huidige contract is het document dat hoort bij het contractrecord met de status „van kracht”. Zoeken in tekst gebeurt vervolgens binnen dat document, niet in alles wat het bedrijf ooit heeft geschreven.

Beantwoord gestructureerde vragen met query’s. Tellingen, sommen, datums en statussen komen uit de records, berekend, niet uit passages die ze toevallig noemen.

Pas rechten toe vóór het zoeken. De rechten van de persoon bepalen welke objecten überhaupt zichtbaar zijn. Het model krijgt de rest nooit te zien, en kan die dus ook niet lekken.

Verwijs naar het record en de versie. Het antwoord linkt naar het contractrecord, de versie en de clausule, zodat de persoon het met één klik kan controleren.

Zoeken in documenten blijft nuttig voor kennis die werkelijk in lopende tekst leeft: procedures, handleidingen, opgebouwde vakkennis. Ook daar werkt het beter wanneer elk document gekoppeld is aan de objecten die het beschrijft, zodat het zoeken op de juiste plek kan beginnen.

Zo is Hurukan ontworpen. Elk document hangt aan zijn record, met revisies en beoordelingen, zoals beschreven bij Projecten en documenten. De laag Ontologie bevat de objecten, relaties en statussen, en de laag Superintelligentie is ontworpen om haar modellen eerst in die structuur te verankeren, met de rechten al toegepast. Dit is in ontwikkeling. Waar zo’n model in de eerste plaats vandaan komt, is het onderwerp van uw bedrijf heeft al een ontologie.

Een test die u vandaag kunt doen

Verzamel tien vragen die uw medewerkers deze maand echt hebben gesteld over klanten, orders, leveranciers of contracten. Schrijf bij elke vraag op waar het juiste antwoord werkelijk staat:

  • in één document,
  • in meerdere documenten die gecombineerd moeten worden,
  • in een record,
  • of in een telling of som over veel records.

Leg dezelfde tien vragen vervolgens voor aan uw huidige systeem voor zoeken in documenten, als u er een hebt, en controleer elk antwoord aan de hand van de echte bron.

Noteer waar de verkeerde versie, de verkeerde klant of een verzonnen telling opduikt. Als de fouten zich voordoen in elke categorie behalve „één document”, hebt u de grens van zoeken in documenten gevonden, en dat is een grens van het ontwerp, niet van het model. De bredere vraag waar taalmodellen wel en niet helpen, komt aan bod in waar taalmodellen hun geld waard zijn.