Hoe dit project tot stand kwam

Wij zijn een softwarebedrijf met klanten in verschillende sectoren en van verschillende omvang. Sommige daarvan zijn vrij klein. Voor sommigen zou een chatbot op hun website hen aanzienlijke bedragen besparen, terwijl ze zichzelf presenteren als omarmers van state-of-the-art oplossingen. Maar wat hen ervan weerhoudt om verder te gaan, zijn de onbetaalbare kosten.

In dit artikel laat ik degenen die geïnteresseerd zijn in een dergelijk onderwerp vanuit een zakelijk perspectief of vanuit een technisch oogpunt zien hoe we een chatbotoplossing hebben ontworpen die niet de bank breekt en daarom haalbaar is voor kleine en middelgrote ondernemingen, of MKB's.

Ik zal onze aanpak van het project delen, de componenten die we hebben geïdentificeerd, hoe we hun levensvatbaarheid hebben getest en hoe de oplossingen die we hebben gebruikt om de kosten laag te houden. Onderweg zal ik beschrijvingen en visualisaties geven, waarin onze worstelingen en ons uiteindelijke succes worden getoond. En tot slot zal ik wat gedachten delen over het gebruik van de overvloed aan GenAI-oplossingen die er zijn om de kosten verder te verlagen, welke GenAI's te gebruiken en welke te vermijden. Nog één ding voordat we erin duiken. Deze applicatie is framework-agnostisch, ontworpen om onafhankelijk te zijn van de moederapplicatie. Het is niet nodig dat de applicatie Django-gebaseerd is. De frontend-oplossing kan worden geëxporteerd naar vanilla javascript, zodat deze eenvoudig aan elke webapplicatie kan worden gekoppeld. Of binnen elk framework kan worden geïmplementeerd als een zelfstandige react-applicatie.

We zullen deze oplossing binnenkort uitrollen naar onze klanten. Als u op welke manier dan ook geïnteresseerd bent in deze oplossing, of het nu als ondernemer is, vanuit een technisch standpunt of gewoon in het algemeen, laat het ons weten.

Onze aanpak

We zijn dit project gestart als reactie op een vraag van een van onze klanten, een van de kleinere klanten. De klant was enthousiast over het vooruitgaan met AI en het implementeren van een chatbot op hun hoofdwebsite was de meest praktische en potentieel tijdbesparende oplossing. En we waren het er helemaal mee eens, maar we wisten dat de meeste chatbots werden gebouwd en geïmplementeerd voor veel grotere organisaties.

Dus hoe dit idee financieel te laten werken. Eerder had ik artikelen geschreven over chatbots, die hier te vinden zijn: https://www.linkedin.com/pulse/chatbot-proof-concept-how-convince-your-colleagues-dekkers--sggte/ en hier: https://www.linkedin.com/pulse/how-make-enterprise-level-ai-tools-financial-sense-dekkers--wwmme

Deze artikelen laten zien hoe we – misschien naïef – probeerden een chatbot te maken die in de portemonnee van kleine klanten zou passen. Er waren een aantal dingen mis met de technische realisatie van deze ideeën waar ik nu niet op in zal gaan.

Maar wat de artikelen wel goed deden is één ding: onze MKB-klant kan de kosten van het raken van een Gen AI bij elke interactie niet betalen. Want dat zou neer kunnen komen op operationele kosten die gemakkelijk duizenden euro's per maand kunnen bedragen.

Hoe ontwerp je een systeem dat zowel voor eindgebruikers als voor het budget van de MKB-klant werkt?

Maar toch moesten we een oplossing vinden die een bevredigende gebruikerservaring voor natuurbehoud zou bieden en tegelijkertijd de kosten onder controle zou houden. Kostenbesparingen hier zijn vooral het verlagen van de operationele kosten. Door de GenAI bij elke interactie te raken, zouden de kosten dramatisch kunnen stijgen en zou de kans op onjuiste antwoorden toenemen, wat allerlei problemen zou kunnen veroorzaken. Maar hoe doen we dat, aangezien gebruikers inmiddels allemaal zouden weten hoe een chatbot zich zou moeten voelen, aangezien ze waarschijnlijk al vrij vaak chatbots hebben gebruikt die miljoenen kosten.

We probeerden een aanpak die niet als een echte chatbot voelde

Aanvankelijk waren we het eens over een basisaanpak waarbij we Generative AI gebruikten, maar op zo'n manier dat we de controle hielden over zowel de kosten als de inhoud. We hebben deze aanpak geïmplementeerd en getest.

Ik zal hieronder meer uitleggen, maar het volstaat om te zeggen dat het goed genoeg werkte, maar we misten de conversatie-interactie die iedereen die niet onder een steen leeft, zal waarderen bij het gebruik van een chatbot. Het zag eruit als een chatbot, het bewoog als een chatbot, maar het voelde niet als een chatbot. Het was duidelijk dat we iets meer nodig hadden, en daarvoor moesten we realtime-interactie introduceren met een GenAI.

We besloten een tweeledige aanpak te volgen: ten eerste zouden we een engine ontwerpen die veelgestelde vragen zou creëren uit de inhoud van de website van onze klanten. De FAQ zou worden gegenereerd door een GenAI. Het maakt niet uit welke, maar destijds was ChatGPT nog steeds een ding (ja, ja, het IS nog steeds een ding, maar er is een nieuwkomer in de blok, zoals iedereen waarschijnlijk al weet), dus dat is wat we gebruikten.

We zouden de FAQ toegankelijk maken vanuit de chatbot en, om ervoor te zorgen dat ChatGPT geen onzin (of erger) zou genereren, zorgden we ervoor dat een mens de vraag-antwoordparen kon valideren. Daarnaast bouwden we een wegingssysteem, zodat de mens kon beslissen welk antwoord boven anderen zou prevaleren.

En nu voor het tweede punt van onze hooivork: als er niets voor de vraag in de FAQ werd gevonden, zouden we een tweede GenAI introduceren, maar deze zou in realtime werken. Deze GenAI zou ook toegang hebben tot de volledige set content en zou deze content doorzoeken wanneer er een vraag wordt gesteld. Wanneer er een match wordt gevonden, zou de context van de match worden gebruikt om de vraag te beantwoorden, nu in een meer conversatievorm.

Het blijkt dat deze mix in de praktijk behoorlijk goed werkt. Zodra de gebruiker begint te denken dat de bot alleen maar ingeblikte (ingeblikte) antwoorden spuwt, komt de GenAI in actie met een doordacht antwoord. Er is inderdaad een echt gesprek gaande, of zo lijkt het. En als het antwoord van de GenAI komt, is het nog steeds allemaal binnen de context van de verstrekte content. Plus, extra bonus, de chatbot kan in elke taal antwoorden, maar nog steeds de context als bron gebruiken.

Het plan zoals het er nu uitziet na veel strijd

Hieronder ziet u een diagram van de chatbotarchitectuur. Het doel is om een ​​gebruikerservaring te creëren die enigszins lijkt op een interactie tussen mensen, maar met enkele beperkingen. Ik heb dit hierboven al genoemd, maar ik zal ze hier voor de duidelijkheid opsommen:

1. We moeten niet de hele tijd met de GenAI praten. Dit is vooral om hoge kosten te voorkomen, maar ook omdat we op onze hoede zijn voor verkeerde en/of ongepaste antwoorden.
2. We moeten mensen die bekwaam zijn in het kennisdomein de antwoorden laten verifiëren. Om deze reden bouwen we een FAQ en geven we in eerste instantie de vooraf gegenereerde antwoorden door aan de chatbot "zoals ze zijn".
3. Alleen als de FAQ tekortschiet, interacteren we in realtime met de GenAI. Maar als we dat doen, is de prompt die aan de GenAI wordt gegeven zodanig dat deze alleen de inhoud van de website als context mag gebruiken. Als het antwoord niet in de context kan worden gevonden, krijgt de GenAI de opdracht om te zeggen "Het spijt me zo, maar ik weet het niet."

De groene flow: vertrouwde, geverifieerde FAQ

Laten we wat dieper ingaan op het diagram. Eerst de flow in het groen, de FAQ-flow.

• Website-inhoud: we hebben een scraper gebouwd die de pagina's van de website van de klant kan identificeren en de opgeschoonde content in een Django-databasemodel kan invoegen. Deze opgeschoonde tekst is klaar voor gebruik door onze workflow.
• GenAI maakt FAQ: een GenAI wordt aangeroepen met een prompt die hem instrueert om vragen en hun respectievelijke antwoorden te maken van de opgeslagen webpagina's.
• FAQ-engine: de aanroeper van de GenAI, en zorgt ervoor dat de FAQ in een Django-databasemodel wordt geladen. De vraag-antwoord moet worden geverifieerd door een menselijke contentmanager, daarnaast kunnen ze ze bewerken of verwijderen.
• FAQ-opslag: het Django-model dat de geverifieerde gegevens vasthoudt voor later ophalen.

Zoals hierboven vermeld, is de FAQ Engine toegankelijk voor een menselijke contentmanager. Zij moeten de data verifiëren, ze kunnen de vragen en antwoorden bewerken en ze kunnen ze een gewicht geven. Hoe hoger het gewicht, hoe sneller ze worden doorgegeven aan de chatbot-frontend, als alle andere dingen gelijk zijn.

Niet expliciet getoond hier is de Django FAQ-weergave die zorgt voor de interactie tussen de frontend waar de chatbot zich bevindt en de dataopslag. Wanneer de gebruiker een vraag stelt, wordt het verzoek eerst doorgestuurd naar de FAQ-weergave, waar de logica zich bevindt. Het is deze logica die controleert of trefwoorden binnen de vraag voldoende overeenkomen met de vragen in de FAQ. Als dat zo is, wordt het antwoord op de overeenkomende vraag doorgegeven aan de frontend.

Let op dat de logica die de FAQ levert, simpele, ouderwetse, deterministische software is. GenAI speelt geen enkele rol in de interactie met de gebruiker van de chatbot. Het heeft zijn werk gedaan: de resultaten zijn geverifieerd door mensen.

Wanneer de FAQ echter niet het juiste antwoord kan vinden, start de GenAI-flow. Maar we willen niet zomaar een antwoord van de GenAI. Om de GenAI te helpen zich te concentreren op de inhoud van de website (en niet antwoorden te geven op basis van de gegevens waarop ze zijn getraind, d.w.z. het internet in het algemeen), hebben we een zogenaamd RAG-proces geïmplementeerd.

RAG, Vector Stores en hoe de GenAI in de gewenste richting te sturen

RAG staat voor Retrieval-Augmented Generation, wat wil zeggen dat het de GenAI kennisbronnen geeft buiten het domein waarop ze zijn getraind. Voorbeelden hiervan zijn interne documenten die organisaties geheim houden; in feite weerspiegelt veel van de terminologie binnen RAG dit gebruiksvoorbeeld.

Maar we vallen een beetje buiten dit specifieke gebruiksvoorbeeld, omdat onze gegevens al op internet staan. Het is waarschijnlijk al onderdeel van de trainingsgegevens van de GenAI. Het probleem is dat het is vermengd met alle andere gegevens uit vergelijkbare kennisdomeinen. Dat is niet wat we willen, want zoals eerder gezegd, willen we prioriteit geven aan de inhoud van de website van onze klant. Met behulp van RAG kunnen we definiëren dat de GenAI zich ALLEEN aan de inhoud van de website moet houden, of anders zeggen: "Ik weet het niet".

Laten we dus opsommen wat er nodig is om dit te realiseren.

• Website-inhoud: Geen wijziging nodig, we hergebruiken de opgeschoonde inhoud die is geleverd door de scraper-software die we hierboven hebben beschreven.
• Embed Engine: We hebben een embedder geïmplementeerd om de tekst om te zetten in vectoren. Het verandert tekst (maar ook afbeeldingen en andere media) in een vectorformaat dat het voor software gemakkelijk maakt om het ene object met het andere te vergelijken. In ons voorbeeld is het om een ​​tekstblok met een ander tekstblok te vergelijken. Dit proces omvat een Embed Model, wat een Large Language Model (LLM) is dat gespecialiseerd is in het maken van embeddings.
• Vectoropslag: Wanneer we het embeddingproces hebben doorlopen, slaan we de resultaten op. We willen het embeddingproces niet in realtime uitvoeren, het is kostbaar en enigszins kwetsbaar, omdat het veel gebruikmaakt van verzoeken aan de embed-LLM's.

In het geval dat de aanvraag voor een FAQ-match NEE oplevert, wordt de vraag doorgestuurd naar de logica die een match voor de vraag in de Vector Store zoekt.

In de eerste stap wordt de vraag getransformeerd naar hetzelfde formaat als de vectoren waarmee we matchen. Dit gebeurt met hetzelfde Embed Model als dat werd gebruikt voor de oorspronkelijke transformatie.

In de volgende stap, nu het in hetzelfde formaat is, kan de vraag worden gematcht met de vectorrepresentatie van de volledige tekst.

Onthoud dat we hier geen tekst aan tekst matchen, we matchen de vectorrepresentatie van de vraag met de vectorrepresentatie van de website-inhoud die is verwerkt en verrijkt door het Embed Model. Het embed-proces is ontworpen om de oorspronkelijke betekenis van de tekst te behouden, ongeacht de daadwerkelijk gebruikte woorden. Het Embed Model kan herkennen dat "kopen" en "aanschaffen" vergelijkbare betekenissen hebben, ook al zijn het verschillende woorden. Embed Models zijn zeer effectief in het vastleggen van de algehele betekenis en context van tekst.

Als er nu een match wordt gevonden, wordt deze teruggestuurd naar een chat GenAI om een ​​antwoord mee te compileren. Met andere woorden, de betekenis van de website-inhoud wordt teruggestuurd naar de chat GenAI als context, samen met de betekenis van de vraag. Dus zowel de context als de betekenis van de vraag komen samen in de chat GenAI, zodat er een antwoord kan worden geproduceerd. Het antwoord bestaat daarom niet uit woorden en zinnen die in de originele website-inhoud voorkomen, maar is een compleet nieuwe zin die de essentie van de originele inhoud en de originele vraag vastlegt, maar mogelijk geen enkel woord bevat dat in de originelen voorkomt.

Samenwerking tussen FAQ en GenAI levert een kosteneffectieve chatbotoplossing op

Het matchen van vraagtrefwoorden met een geverifieerde FAQ en het gebruiken van een GenAI als fallback levert een interessante combinatie op die zorgt voor een conversatie-ervaring, terwijl de operationele kosten zo laag mogelijk blijven. Veel vragen zullen nooit een oproep naar een GenAI activeren, maar als de gebruiker op een minder conventionele manier vragen stelt, of een antwoord opvolgt met een kort antwoord, wat beide kan resulteren in een "niets gevonden" in de FAQ-database, dan pas wordt de vraag doorgestuurd naar de GenAI.

Het lijkt erop dat het goed genoeg zal werken voor de websites van onze kleinere klanten, die doorgaans minder verkeer hebben.

Maar laten we eens naar wat cijfers kijken. In een van mijn eerdere artikelen over dit onderwerp gaf ik de kosten van oproepen naar een GenAI op basis van enkele aannames. Dat was toen, dit is nu, 2025, en het landschap is veranderd. Laten we de cijfers nog eens bekijken. Ten eerste, wat zijn de kosten van het gebruik van een GenAI?

En natuurlijk hebben we het aan een GenAI gevraagd. Nee. Geen enkele. We vroegen ChatGPT, DeepSeek, Gemini en Mistral.

De invoer van een vraag wordt verondersteld ongeveer 1250 woorden te zijn, wat de vraag en de context bij elkaar opgeteld is. De uitvoer wordt verondersteld ongeveer een derde daarvan te zijn. GenAI wordt berekend in tokens, en een token is ongeveer 0,75 van een woord.

(Laten we onze aannames even snel controleren, wat is het gemiddelde aantal tokens dat wordt uitgewisseld in een chatbotinteractie. ChatGPT zegt 2500, Gemini zegt 200, DeepSeek R1 zegt 500, Mistral zegt 300. Hmm. Laten we even bij onze getallen blijven.)

Dus dan komen we op 1700 tokens invoer, 500 tokens uitvoer.

Hier zijn hun antwoorden. En ja, ik heb een aantal van hen gecontroleerd op feiten. En hun sommen gecontroleerd. Graag gedaan!

voor elk van openai (chatgpt o1), gemini, deepseek en mistralai chat-mistral, geef een benadering van de kosten voor invoercontext 1700 tokens, uitvoer 500 tokens. Ik wil de kosten van de volledige interactie, niet de kosten per token

Goed. De conclusie zou zijn dat, als alle andere dingen gelijk zijn, DeepSeek NIET de meest kosteneffectieve GenAI is om te gebruiken, dat zou Gemini zijn.

Dus, hoe gaat dit werken in de context van onze chatapplicatie.

Dit was de kostenvoorspelling zoals berekend in oktober vorig jaar:

Het ziet er een stuk beter uit, maar ik weet zeker dat onze klanten de prijzen nog verder willen verlagen.

En daar komt onze oplossing om de hoek kijken. Door de FAQ te genereren als buffer kunnen de kosten omlaag. In de FAQ-sectie, waar een aantal vragen, bij voorkeur een groot aantal, door de FAQ Engine wordt vastgelegd, kunnen ze de vragen en antwoorden goedkeuren en bewerken om nauwkeurig aan te sluiten bij de vragen die hun gebruikers stellen. We loggen alle gesprekken, zodat klanten eenvoudig kunnen zien hoe vragen worden geformuleerd en dienovereenkomstig kunnen aanpassen.

Maar hoeveel besparingen zullen er zijn ten opzichte van de basislijn? Daar hebben we nog geen cijfers over. We zullen er meer over leren als we onze oplossing uitrollen naar onze klanten. Maar hoe hoog de besparingen zullen zijn, hangt af van hoe ijverig klanten hun FAQ verfijnen. Of ze vragen ons om het te doen.

Kosten beperken zal zijn het gebruik van FAQ, dan GenAI en Throttling als laatste maatregel

Ik wil hier alleen de laatste maatregel noemen, omdat ik daar nog niet op in ben gegaan. Als allerlaatste maatregel zullen we beleefd weigeren om gebruikersvragen door te sturen naar de GenAI. Ze kunnen de FAQ-database zo vaak gebruiken als ze willen, maar niet de GenAI, die kosten maakt op basis van gebruik.

Alles bij elkaar

We hebben het tot nu toe over backend gehad, maar natuurlijk hebben we ook frontend nodig! Maar dit is eigenlijk het makkelijke gedeelte. Er zijn een aantal bibliotheken die interfaces voor onze chatbot bieden. Omdat we React-mensen en Django-mensen zijn, vonden we snel een geschikte oplossing die min of meer als een plugin kon worden geïmplementeerd. Maar zoals gezegd in de introductie, zullen we een opnieuw gecompileerde oplossing aanbieden voor degenen die een platte HTML- en vanilla JavaScript-oplossing gebruiken, of voor degenen die jQuery gebruiken.

En natuurlijk is de interface volledig aanpasbaar, zodat deze past bij de bestaande interface. Klanten krijgen een contentmanagementsysteem om hun FAQ en andere instellingen goed te keuren en te bewerken, maar ook om hun eigen branding aan te passen. En natuurlijk zijn wij als bedrijf beschikbaar om te helpen.

Tot slot

Ik wed dat sommigen van jullie graag willen weten wat dit allemaal zou kosten (als je het als potentiële klant zou vragen). Het antwoord is dit: "Het spijt me, ik heb geen antwoord op die vraag". Of misschien nog beter: "Het hangt ervan af". Omdat het ervan afhangt, echt waar.

Wat kunnen we dan wel zeggen?

• Implementatiekosten: Er zal een bedrag worden overeengekomen voor de implementatie. Dat houdt in dat we beginnen met het verzamelen van gegevens, de juiste inhoud selecteren en pagina's verwijderen die er niet toe doen. Iemand moet het doen. Dat zou jij kunnen zijn.
• Fluctuerende vergoeding, maandelijks gefactureerd: Wij regelen alle administratieve zaken voor onze klanten. In principe de kosten van de GenAI en alle andere kosten.
• Abonnementskosten: Binnen die abonnementskosten zit een bedrag voor onderhoud en ondersteuning en voor de ontwikkeling van het product

Nu sluiten we echt af...

We denken dat we een ontwerp hebben voor een chatbotoplossing die de balans heeft gevonden tussen betaalbaarheid en functionaliteit. We verwachten dat gebruikers de informatie vinden die ze nodig hebben en geholpen worden als ze niet goed weten hoe ze hun vragen moeten formuleren. We doen dat door een combinatie van vooraf gegenereerde FAQ's en GenAI-reacties te leveren, alleen als dat nodig is.

Als u een bedrijfseigenaar, een techneut of gewoon geïnteresseerd bent, hoop ik dat u hier iets aan hebt gehad. Bedankt dat u al die tijd bij me bent gebleven.