Laatste Klantreferentie:
Croonwolter&dros bespaart meer dan 50% tijd met AI van Brainial
Ontwikkeling

Document-geïnformeerde grote taalmodellen: Blog posts vs echte toepassingen

4 min lezen
Gepubliceerd in
Ontwikkeling

Document-geïnformeerde grote taalmodellen: Blog posts vs echte toepassingen

Document-geïnformeerde grote taalmodellen: Blog posts vs echte toepassingen

Ik vind het altijd leuk om op verschillende blogs te lezen over de vooruitgang in AI, en de laatste tijd worden ze gedomineerd door de toepassing van grote taalmodellen zoals ChatGPT. De laatste tijd is er ongelooflijke vooruitgang geboekt op het gebied van grote taalmodellen, het uitvoeren van je eigen large language model (LLM) en het verankeren van grote taalmodellen in externe kennisbanken. Titels als 'How to fine-tune ChatGPT with your own data' en 'How to set up document question answering with LLMs in a couple of hours' doen het lijken alsof iedereen een of andere kant-en-klare ChatGPT plugin kan gebruiken, of een open-source LLM kan hosten, en vrij eenvoudig zijn eigen op kennis gebaseerde chatsysteem kan opzetten.

En ik heb geleerd dat dat zowel waar als ver van de waarheid is. Het is vrij eenvoudig geweest om een systeem op te zetten dat informatie doorgeeft aan ChatGPT (of een andere LLM) en mijn vragen beantwoordt op basis van de context die ik heb gegeven. Open source bibliotheken bieden veel functionaliteit, en als je het combineert met een vector store, kun je de codestructuur eenvoudig opzetten.

Maar wat die blogs nooit lijken te vermelden, is dat dit vrij eenvoudig te doen is voor kleine goed gestructureerde verzamelingen informatie (documenten van een paar pagina's), maar dat het steeds moeilijker wordt met grotere kennisbanken (honderden pagina's informatie om doorheen te filteren). Als we dit toepassen op ons product, waar we vragen moeten beantwoorden op basis van honderden pagina's aanbestedingsdocumenten, die vaak niet zo goed gestructureerd zijn als we zouden willen, vormt dit een behoorlijke uitdaging.

Er lijken een paar benaderingen te zijn:

- Alle informatie naar je LLM gooien

- Dichte opvraagmodellen gebruiken in een vectordatabase

Jouw LLM laten beslissen welke informatie je gebruikt

Om grote taalmodellen te baseren op externe kennis, moet die kennis worden opgenomen in de prompt. Als we niet precies weten welke informatie onze vraag zal beantwoorden, kunnen we dan niet gewoon alle informatie naar de LLM gooien en het zelf laten uitzoeken? Nou... Dit werkt wanneer we uitgaan van een relatief kleine kennisbank, zoals een document van 1 pagina, maar dit wordt fundamenteel beperkt door de contextgrootte van het model. Hoewel deze contextgroottes toenemen (32k tokens met GPT-4), komen ze bij lange na niet in de buurt van de schaal van een kennisbank die relevant is voor echte problemen.

Eén benadering is om meerdere aanroepen te doen naar de large language model, om deze samen te laten vatten of meer dichte representaties van de kennisbank te laten maken. Dit werkt, maar verhoogt het aantal aanroepen, het aantal verwerkte tokens, de rekenkosten en de benodigde tijd met een behoorlijke factor, en schaalt niet goed met de grootte van de kennisbank (document).

Dichte opvraagmodellen gebruiken in een vectordatabase

Dense retrieval modellen, en meer specifiek bi-encoders, die een tekst coderen in een n-dimensionale vector, en het mogelijk maken om eenvoudig de afstand tussen vectoren (embeddings) te berekenen. Deze afstand is een benadering van de gelijkenis tussen teksten en kan worden gebruikt voor 'semantisch zoeken'. Het is gebleken dat dit vrij goed werkt als een eerste stap om relevante teksten voor een gegeven zoekopdracht te krijgen. Veel blogs stellen voor om elke pagina te coderen en de overeenkomst tussen de pagina's en de zoekopdracht te berekenen om een resultaat te krijgen. Hoewel dit in theorie goede resultaten geeft op specifieke (in domein) benchmarks, is het vaak niet het volledige verhaal voor een echte wereldtoepassing.

Een paar uitdagingen zijn echter gemakkelijk te overzien.

- Voorgetrainde zinsinbeddingsmodellen zijn vaak getraind op korte tekstpassages en zijn niet in staat om hele pagina's te coderen. Ze werken beter op zinsniveau. Dit geldt vooral voor meertalige modellen.

- Veel voorgetrainde modellen worden getraind op een symmetrische similariteitstaak, om de similariteit tussen twee zinnen te berekenen. Dit werkt niet zo goed voor kortere zoekzinnen en langere referentieteksten (documentpagina's of paragrafen).

- Vooraf getrainde zinsinbeddingsmodellen zijn vaak getraind op teksten met een algemeen domein (zoals tweets of internetfora) en presteren ondermaats in domeinspecifieke teksten die vaak voorkomen in een professionele omgeving.

- Gegevens in documenten zijn vaak niet zo goed gestructureerd als de trainingsteksten. Er kan veel ruis zitten in automatisch geëxtraheerde documenten (kop- en voetteksten, slechte OCR en nog veel meer problemen).

Takeaways

Natuurlijk zijn er oplossingen voor al deze problemen, en het is zeker mogelijk om een goede informatie-ondersteunde chat-assistent te bouwen. Maar er is een grote kloof tussen de pakkende blogposts die een speelgoedprobleem demonstreren, en het toepassen van deze technologie op een echte use-case.

Bij Brainial werken we momenteel aan het oplossen van deze uitdagingen, om de kracht van grote taalmodellen te integreren in onze Tender Assist. We streven ernaar om functies te bieden voor het beantwoorden van vrije vragen en het (her)schrijven van voorstellen. Neem contact met ons op voor meer informatie .

Vergelijkbare berichten

Lees meer over de laatste ontwikkelingen van Brainial, tendering & de fascinerende wereld van AI.
Bekijk onze Tendering & AI Blog.

Leer hoe je sneller betere offertes kunt maken

We begeleiden je graag door onze AI-gestuurde Bid & Tender management oplossing
om het potentieel voor jou en jouw bedrijf te verkennen.
Ontdek onze waarde
Bekijk hoe we de grootste uitdagingen oplossen
Ervaar de waarde van AI voor Bid & Tender Management