De Benchmark Answer Set Samenstellen
Een van de fundamentele elementen van ons project was het opzetten van een robuuste Benchmark Answer Set. We dachten aanvankelijk dat toegang tot een grote Q&A database deze taak zou vereenvoudigen. Al snel realiseerden we ons echter dat het kiezen van vragen die het volledige scala aan benodigde nuances vatten allesbehalve eenvoudig was. Bovendien bleek het nauwkeurig identificeren en koppelen van de juiste bronnen, vooral wanneer verschillende bronnen vergelijkbare onderwerpen bespreken, complex te zijn. Om deze uitdaging te overwinnen, kozen we voor een iteratieve aanpak waarbij verbeteringen geleidelijk werden doorgevoerd, samen met domeinexperts en hun feedback. Op deze manier hoefden we niet te wachten tot de Benchmark Answer Set klaar was; we konden de oplossing al beginnen te optimaliseren met de beperkte content die we tot onze beschikking hadden.
Het Evaluatieframework Bouwen
Het opzetten van een evaluatieframework zelf is relatief eenvoudig. Toch vergde het fine-tunen van de metrics om ervoor te zorgen dat ze onze doelen nauwkeurig weerspiegelden behoorlijk wat inspanning en aandacht. Metrics zoals recall lijken op het eerste gezicht misschien simpel, maar de duivel zit in de details. Het is makkelijk om een fout te maken. We moesten onze methoden voortdurend opnieuw beoordelen om ervoor te zorgen dat ze afgestemd bleven. Hoewel onze focus meer lag op trends in een bepaalde richting dan op absolute cijfers, maakten nauwkeurige metingen de inzichten ongetwijfeld veel impactvoller. De belangrijkste metrics die we gebruikten om de prestaties te meten waren Recall, Precision/Mean Reciprocal Rank (MRR) en een LLM-gebaseerde correctheidsmetric, die samen een compleet beeld schetsten van de effectiviteit van ons framework.
Systeemcomponenten: Van Prototype naar Beta
De overgang van een prototype naar een beta versie omvat de integratie en verfijning van meerdere systeemcomponenten. Als je een prototype hebt, heb je waarschijnlijk de volgende componenten al opgezet:
- Een basis pipeline voor het cleanen, chunken en embedden
- Een retrieval systeem dat gebruikmaakt van similarity searches
- Een mechanisme voor het genereren van antwoorden
Naarmate we vorderden naar de beta fase, evolueerde het systeem en omvatte het meer geavanceerde lagen:
- Een geavanceerde pipeline voor verbeterde technieken voor dataverwerking
- Een classificatielaag voor slimmere routing van queries
- Een query expansion laag om vragen te ontleden en de scope te verbreden
- Een reranker om resultaten samen te brengen en te prioriteren
- Een guardrails laag om antwoorden en bronnen te valideren
Projecthouding: Detailgericht en Hands-On
Gedurende het project hing ons succes minder af van de metrics zelf en meer van ons vermogen om elk aspect van de pipeline te onderzoeken. Dit vereiste een diepe duik in de details: het onderzoeken van onbeantwoorde vragen, over het hoofd geziene bronnen en het voortdurend testen en bijschaven van kleine onderdelen van de oplossing. Het gaat niet alleen om het hebben van domeinexpertise; het gaat om het actief bezig zijn met de data, het herkennen van patronen en het maken van geinformeerde aanpassingen aan de vele componenten die geoptimaliseerd kunnen worden.
De Semantic Match Verbeteren
De meest cruciale taak is het verbeteren van de semantic match tussen een vraag en de bijbehorende content waaruit het antwoord kan worden gehaald. In ons project plotten we de embeddings in 2D en konden we duidelijk het verschil onderscheiden tussen de belangrijkste content (blauw) en vragen (rood). Gelukkig voor ons was er al content aanwezig die fungeerde als brug tussen de vragen en de hoofdcontent. Maar als je niet zo gelukkig bent en die brug niet hebt, kun je strategieen overwegen zoals HyDE of het genereren van synthetische content om de kloof te overbruggen.
De 2D-projectie van onze content (blauw) en query (rood) embeddings.
Met query expansion kun je je richten op verschillende elementen van de vraag (bijvoorbeeld een specifiek element van je bedrijf) om meerdere soorten content in je database aan te raken. Het probleem met deze aanpak is dat je de resultaten van verschillende queries moet samenbrengen, samenvoegen en ontdubbelen. Aangezien je nu waarschijnlijk veel meer resultaten krijgt, wordt een reranker laag belangrijk.
Een reranker is een langzamer maar krachtiger model (vergeleken met een embedding model) dat de gelijkenis tussen de vraag en de content meet. In ons geval bleek reranking erg lastig te zijn, omdat commerciele aanbiedingen zoals Cohere en Jina niet voor ons werkten, waardoor we waren aangewezen op grotere en langzamere modellen. De reden hiervoor was het zeer specifieke domein waarin we opereerden en Nederlands als de belangrijkste taal. Voor meer algemene toepassingen zouden rerankers waarschijnlijk heel goed hebben gewerkt.
Dit deel van het project laat zien dat je niet 'zomaar' een best practice kunt toepassen en geweldige resultaten kunt verwachten; je moet echt testen en uitzoeken wat werkt voor jouw specifieke geval. We verwachtten bijvoorbeeld dat het implementeren van reranking relatief triviaal zou zijn en uiteindelijk ging de meeste ontwikkeltijd in deze laag zitten, zonder een perfect resultaat.
En soms heb je wat geluk nodig
Onze reis kreeg een aanzienlijke boost door de tijdige release van OpenAI's nieuwe embedding modellen, die de similarity matching verbeterden en onze recall met 10%-15% verhoogden. We zagen een sprong van 10%-15% in prestaties door simpelweg over te stappen van text-embedding-ada-002 naar text-embedding-003-large. We hebben ook een embeddings model fine-tuned dat specifiek was voor ons domein, maar helaas waren de resultaten verre van perfect, waarschijnlijk vanwege de taal.
Houd de volgende post in de gaten waarin ik dieper inga op het tweede deel van dit project van 2 maanden, het opzetten van guardrails, het fine-tunen van prompts en de voorbereiding op een succesvolle beta launch.
