Belangrijkste Takeaways

• RAG groundt AI via Retrieval, Augmentation en Generation: Standaard LLM's voorspellen woorden op basis van waarschijnlijkheid, wat leidt tot hallucinaties. RAG lost dit op door in interne documenten te zoeken via similarity scoring, relevante context in strikte prompts te injecteren, en antwoorden te genereren die uitsluitend zijn verankerd in verifieerbare data.
• Datapreparatie bepaalt de AI-kwaliteit: Slechte data leidt tot slechte retrieval. High-performing RAG-systemen vereisen schone, gestandaardiseerde formaten (zoals Markdown), gestructureerde chunking verrijkt met metadata, en een hybrid search-strategie die vector similarity combineert met exacte metadatafilters.
• Multi-Tiered Guardrails voorkomen speculatie: Wanneer interne documenten geen antwoord bevatten, stoppen similarity thresholds direct de uitvoering om onnodige LLM API-calls te voorkomen. Strikte prompts dwingen "Ik weet het niet"-regels af, terwijl het loggen van low-confidence triggers hiaten in de documentatie signaleert voor menselijke beoordeling.
• Auditeerbaarheid vereist granulaire verificatie: Enterprise-beslissingen vereisen bewijs. Betrouwbare RAG-implementaties maken gebruik van bronvermeldingen op paragraafniveau, output confidence scoring en optionele secundaire "faithfulness check"-modellen om te verifiëren of de outputs direct overeenkomen met de bronclaims.
• Verborgen frictie komt door onderhoud, niet door infrastructuur: Hoewel API-tokens en vector database hosting voorspelbare kosten zijn, vormen doorlopende documentupdates, rommelige datapreparatie en re-embeddingkosten de werkelijke frictiepunten op de lange termijn bij de adoptie van enterprise AI.

In onze vorige blog, Retrieval-Augmented Generation (RAG): Een Executive Gids voor AI-nauwkeurigheid, hebben we verschillende aspecten behandeld, van wat RAG is tot waarom traditionele modellen last hebben van hallucinaties en waarom hallucinaties er uiteindelijk niet meer toe doen.

In deze blog bespreken we hoe Lizard Global dit integreert, waarbij we ons nieuwste project ZENO gebruiken om het in detail uit te leggen. We spraken met onze in-house expert, Chathuri Senanayake, Head of Engineering, voor de volledige breakdown.

Laten we beginnen.

In begrijpelijke taal: hoe voorkomt RAG nu echt dat AI dingen verzint?

Standaard LLM's genereren een antwoord door het statistisch meest waarschijnlijke volgende woord te voorspellen, gebaseerd op de patronen die ze tijdens de training hebben geleerd. Als het model het niet weet, zal het nog steeds een zelfverzekerd klinkend antwoord produceren; dit noemen we hallucinaties.

RAG elimineert hallucinaties niet volledig, maar vermindert ze door het antwoord van het model te grounden in echte informatie via retrieving, augmenting en generating.

Retrieve: Voordat er een antwoord wordt geproduceerd, zoekt het systeem in de beschikbare interne documenten en haalt het content op die binnen een vooraf gedefinieerde similarity score valt. (We kunnen deze score experimenteel aanpassen tot we het gewenste resultaat bereiken.)

Augment: De opgehaalde content wordt samen met een strikte set instructies en regels in een prompt geplaatst en naar een LLM gestuurd. We voorzien het model nu van vakspecifieke informatie. Dit versterkt de geloofwaardigheid van het antwoord. Afhankelijk van het project kunnen we expliciet een regel instellen die het LLM opdraagt te antwoorden met "Ik weet het niet" wanneer het antwoord niet beschikbaar is in de geleverde context.

Generation: Het LLM produceert nu een menselijk leesbaar antwoord waarbij de opgehaalde context en de instructies als primaire bron worden gebruikt, in plaats van uitsluitend te vertrouwen op de trainingsdata.

Hoewel RAG hallucinaties niet volledig wegneemt, vermindert het ze door het antwoord te baseren op verifieerbare informatie in plaats van de beste gok van een model. Het is belangrijk om te weten dat het systeem slechts zo goed is als de informatie die het ophaalt en het gekozen AI-model: een zwakke of irrelevante retrieval zal nog steeds leiden tot een slecht of gehallucineerd antwoord, zelfs met perfecte prompting downstream.

Hoe bereiden we onze interne enterprise data voor zodat het RAG-systeem daadwerkelijk de juiste informatie kan vinden?

Deze stap is de belangrijkste in een RAG-systeem. Een geweldig AI-model met een geweldige set instructies zal nog steeds falen als het zoekt in slecht voorbereide data. We nemen de volgende stappen in overweging bij het voorbereiden van de data via een robuust data and architecture design.

1. Schone en gestandaardiseerde data

Het verwijderen van ruis (redundante, herhalende informatie) en het converteren naar machine-readable formaten (Markdown waar mogelijk) is een belangrijke stap in het voorbereiden van de data.

2. De data chunken

We overhandigen documenten niet in hun geheel aan de AI. We breken ze op in kleinere, behapbare stukjes genaamd chunks. Hoe we data chunken hangt af van het type project en het soort informatie waaruit het project bestaat.

Veelvoorkomende chunking-methoden zijn fixed-size chunking, semantic chunking en hierarchical chunking. We verrijken chunks ook vaak met metadata (datums, titel, categorie) om de retrieval te optimaliseren. Geciteerde bron

3. Zoekstrategie

De traditionele zoekstrategie voor het RAG-model is semantic search. Dit betekent dat een chunk aan informatie wordt omgezet in een vector, wat in feite een lijst met getallen is die de betekenis van de tekst vertegenwoordigen. Woorden of concepten met een vergelijkbare betekenis krijgen getallen die dicht bij elkaar liggen (bijvoorbeeld "factuur", "rekening" en "bon" clusteren dicht bij elkaar). Dit wordt vervolgens opgeslagen in een vector database.

Wanneer een gebruikersvraag het systeem binnenkomt, wordt deze op dezelfde manier omgezet in een vector, vergeleken met alles in de database, en worden de beste overeenkomsten geretourneerd op basis van een similarity score. De similarity score kan worden getuned en zal verschillen op basis van het project en de inhoud.

Hoewel semantic search krachtig is, is het ook verstandig om data eerst te filteren op basis van metadata. Deze hybrid search combineert conceptueel begrip met exact match-precisie.

Samenvattend benadrukt Chathuri dat zelfs de sterkste AI-modellen tekortschieten zonder goed voorbereide data. Het effectief voorbereiden van interne enterprise-kennis komt neer op het standaardiseren van ruwe content naar schone, machine-readable formaten, het opbreken van tekst in gestructureerde chunks verrijkt met metadata, en het combineren van semantische vector similarity met exacte metadatafiltering voor een uiterst nauwkeurige hybrid search.

Wat gebeurt er als iemand een vraag stelt die niet wordt beantwoord in onze bedrijfsdocumenten?

Dit is waar guardrails zoals thresholds, instructies en confidence checks in het spel komen. Het is goed om te weten dat er twee failure modes kunnen optreden:

1) De semantic search (Retrieval-fase) vindt niets relevants op basis van de ingestelde similarity threshold. We stoppen hier vaak al voordat de generatie plaatsvindt en sturen een fallback-reactie terug. Dit voorkomt ook een onnodige call naar het LLM. We kunnen dit nog steeds doorsturen naar een verantwoordelijke om te melden dat een vraag onbeantwoord is gebleven, en of er een informatie-update nodig is.

3) De semantic search vindt iets dat gerelateerd lijkt, maar geen feiten bevat over wat er daadwerkelijk wordt gevraagd. Dit is waar een zwakker AI-model en/of een minder strikte set instructies er nog steeds toe kan leiden dat de AI een zwak antwoord genereert. Daarom is het kiezen van het juiste model en het aanscherpen van instructies en regels essentieel. Daarnaast kan een confidence score een extra signaal zijn om de betrouwbaarheid van het antwoord te bepalen.

Het is belangrijk om dergelijke low-confidence antwoorden en onbeantwoorde vragen te monitoren en te loggen, zodat het RAG-model verder kan worden versterkt.

Kortom, bij het afhandelen van onvoorziene vragen voorkomen guardrails zoals similarity thresholds en confidence scores slechte outputs in twee failure modes: het retourneren van een fallback voordat het LLM wordt aangeroepen als de retrieval faalt, en het gebruiken van strikte prompt-instructies om zwakke antwoorden te vermijden wanneer de opgehaalde tekst geen exacte feiten bevat. Chathuri merkte op dat het loggen van zowel fallbacks als low-confidence situaties essentieel is om hiaten in de kennis te signaleren voor menselijke beoordeling en om de RAG-pipeline te verfijnen.

Hoe verifiëren of auditen we waar de AI zijn antwoord vandaan heeft gehaald voordat we een zakelijke beslissing nemen?

Er zijn een paar manieren waarop we het AI-antwoord kunnen verifiëren en auditen. Deze moeten worden ingezet wanneer dat nodig is en zijn niet in steen gebeiteld.

1. Bronvermelding

Elk antwoord wordt geleverd met een bronvermelding naar het document waaruit de informatie is opgehaald, idealiter zo specifiek mogelijk (tot op het niveau van een paragraaf of chunk, en niet alleen het volledige document).

2. Confidence Score

Het LLM bepaalt een confidence score voor het antwoord op basis van hoe goed het antwoord wordt ondersteund door de bronnen.

3. Faithfulness Check

Voor projecten met grotere belangen voegen we een derde laag toe. De vraag, de opgehaalde chunks en het antwoord gaan door een tweede AI-model dat controleert of de bron de claim daadwerkelijk ondersteunt. Dit brengt extra kosten en latency met zich mee, dus dit is gereserveerd voor projecten en beslissingen met hoge belangen.

Zoals hierboven vermeld, kunnen wij als developers geen 100% nauwkeurigheid van het antwoord garanderen; daarom is een menselijke beoordeling nog steeds aanbevolen voor beslissingen met grote belangen.

Chathuri schetste een flexibele, gelaagde aanpak voor het auditen van AI-antwoorden, beginnend met granulaire citaten die terugverwijzen naar specifieke paragrafen of chunks in plaats van hele documenten. Ze merkte op dat confidence scores een directe indicatie van ondersteuning bieden, terwijl beslissingen met grote belangen een extra faithfulness check kunnen triggeren waarbij een tweede AI-model de claim verifieert tegen de bron, ondanks de extra kosten en latency. Tot slot benadrukte ze dat, omdat geautomatiseerde absolute nauwkeurigheid niet kan worden gegarandeerd, menselijke beoordeling essentieel blijft voor kritieke zakelijke keuzes.

Wat zijn de grootste verborgen kosten of frictiepunten bij het implementeren van RAG in een enterprise-omgeving?

De voor de hand liggende kosten zijn de model-tokens, embedding-kosten en vector database hosting.

Het voorbereiden en standaardiseren van data voordat deze wordt gevectoriseerd kan aanzienlijke menselijke arbeid kosten, afhankelijk van hoe omvangrijk en rommelig de broncontent al is. En meestal blijft die data niet statisch. Het up-to-date houden van brondocumenten is geen eenmalige taak. In plaats daarvan is er een eigenaar en een doorlopend proces voor nodig.

Dat is naar mijn mening het grootste frictiepunt (of faalpunt). Ongestructureerde data en verouderde documentatie worden beide gemakkelijk onderschat, omdat ze niet als een aparte post op de factuur verschijnen zoals infrastructuurkosten dat wel doen.

Als de content continu moet worden bijgewerkt, brengt dit ook indirecte kosten met zich mee, aangezien elke wijziging een re-embed vereist. Als dit niet wordt beheerd, kunnen deze kosten snel oplopen naarmate de documentenset groeit. We kunnen dit echter binnen de perken houden door incrementele re-embedding te bouwen, waarbij alleen de gewijzigde content opnieuw wordt verwerkt.

We onderzoeken deze architecturale balansen regelmatig bij het leveren van custom software development en het uitvoeren van voorafgaande discovery workshops om klanten te helpen verborgen infrastructuur-creep te voorkomen. Je leest er meer over in onze gedetailleerde analyse over AI-integratiekosten voor middelgrote bedrijven.

Een nieuwere aanpak: PageIndex wordt voor bepaalde projecten gebruikt in plaats van traditionele RAG-modellen.

In plaats van documenten te chunken en te embedden in een vector database, bouwt PageIndex een hiërarchische boomstructuur van een document (vergelijkbaar met een inhoudsopgave). De AI redeneert zich vervolgens een weg door die boomstructuur om de juiste sectie te vinden, net zoals een menselijke expert naar het juiste hoofdstuk, de juiste sectie en vervolgens de juiste pagina zou bladeren, in plaats van te zoeken naar tekst die er simpelweg vergelijkbaar uitziet. Het slaat chunking en vector databases volledig over.

Het is bijzonder sterk bij lange, goed gestructureerde documenten (zoals financiële rapporten of juridische contracten) waar precisie belangrijker is dan snelheid. Het ruilt echter de vrijwel onmiddellijke lookup van vector search in voor een tragere, op redenering gebaseerde retrieval-stap, en het biedt weinig voordeel bij korte, ongestructureerde content zoals chatlogs of e-mails.

Ready to transform your scattered enterprise data into an accurate, audit-ready AI system?

Bij Lizard Global bouwen we grounded, enterprise-grade RAG-architecturen met behulp van custom software development, ontworpen om hallucinaties te elimineren, strikte privacy te waarborgen en meetbare ROI te leveren via ons impactvolle werk. Laat slechte data je digitale transformatie niet in de weg staan.

👉Spreek vandaag nog met onze AI Engineering Experts