Grote taalmodellen (LLM) inzetten in real-world bedrijfsapplicaties

Grote taalmodellen zijn overal. Elk gesprek met een klant of een VC-pitch gaat over hoe klaar LLM-technologie is en hoe het toekomstige applicaties zal aandrijven. Ik heb enkele patronen op dit gebied behandeld in mijn vorige post. Hier zal ik het hebben over enkele real-world patronen voor een applicatie in de farmaceutische industrie waar Persistent Systems aan heeft gewerkt.

Grote taalmodellen en kernsterktes

LLM’s zijn goed in het begrijpen van taal, dat is hun sterke punt. Het meest voorkomende patroon dat we zien bij applicaties is retrieval augmented generation (RAG), waarbij kennis extern wordt samengesteld uit gegevensbronnen en in context wordt verstrekt als een prompt voor de LLM om een antwoord te parafraseren. In dit geval dienen super-snelle zoekmechanismen zoals vector databases en Elasticsearch-gebaseerde engines als eerste zoeklijn. Vervolgens worden de zoekresultaten samengesteld in een prompt en naar de LLM gestuurd, meestal als een API-aanroep.

Een ander patroon is het genereren van een query op gestructureerde gegevens door de LLM een gegevensmodel als prompt te geven en een specifieke gebruikersquery. Dit patroon kan worden gebruikt om een geavanceerd “praat met uw gegevens”-interface te ontwikkelen voor SQL-databases zoals Snowflake, evenals voor graph-databases zoals Neo4j.

LLM-patronen inzetten voor real-world inzichten

Persistent Systems heeft onlangs naar een patroon gekeken voor Blast Motion, een sporttelemetriebedrijf (swinganalyse voor honkbal, golf, etc.), waarbij we tijdreeksgegevens van spelerssamenvattingen hebben geanalyseerd om aanbevelingen te krijgen.

Voor meer complexe applicaties moeten we de LLM-aanvragen vaak ketenen met verwerking tussen aanroepen. Voor een farmaceutisch bedrijf hebben we een slimme trails-app ontwikkeld die patiënten filtert voor klinische trials op basis van criteria die zijn geëxtraheerd uit klinische proefdocumenten. Hier hebben we een LLM-ketenbenadering gebruikt. Eerst hebben we een LLM ontwikkeld om proef-PDF-documenten te lezen en de RAG-patroon te gebruiken om inclusie- en exclusiecriteria te extraheren.

Hiervoor is een relatief eenvoudige LLM zoals GPT-3.5-Turbo (ChatGPT) gebruikt. Vervolgens hebben we deze geëxtraheerde entiteiten gecombineerd met het gegevensmodel van de patiënten-SQL-database in Snowflake om een prompt te creëren. Deze prompt is vervolgens naar een krachtigere LLM zoals GPT4 gestuurd, waardoor we een SQL-query krijgen om patiënten te filteren die klaar is om te worden uitgevoerd op Snowflake. Aangezien we LLM-kettingen gebruiken, kunnen we meerdere LLM’s voor elke stap in de keten gebruiken, waardoor we de kosten kunnen beheren.

Momenteel hebben we besloten om deze keten deterministisch te houden voor betere controle. Dat wil zeggen dat we hebben besloten om meer intelligentie in de keten te hebben en de orkestratie heel eenvoudig en voorspelbaar te houden. Elk onderdeel van de keten is een complexe applicatie op zich die enkele maanden zou duren om te ontwikkelen in de pre-LLM-dagen.

Geavanceerdere use cases mogelijk maken

Voor een meer geavanceerd geval kunnen we agents zoals ReAct gebruiken om de LLM te laten zien hoe stap-voor-stap instructies te volgen voor een bepaalde gebruikersquery. Dit zou natuurlijk een high-end LLM zoals GPT4 of Cohere of Claude 2 vereisen. Echter, dan is er een risico dat het model een onjuiste stap neemt die moet worden geverifieerd met behulp van guardrails. Dit is een afweging tussen het verplaatsen van intelligentie naar controleerbare schakels in de keten of het maken van de hele keten autonoom.

Vandaag, nu we wennen aan de tijd van generatieve AI voor taal, begint de industrie LLM-toepassingen met voorspelbare ketens te adopteren. Naarmate deze adoptie groeit, zullen we binnenkort beginnen met experimenteren met meer autonomie voor deze ketens via agents. Dat is waar het debat over AGI over gaat en we zijn geïnteresseerd om te zien hoe al dit zich in de loop van de tijd ontwikkelt.