Grote taalmodellen (LLM) verplaatsen naar real-world zakelijke toepassingen

Grote taalmodellen zijn overal. Elk klantgesprek of VC-pitch bevat vragen over hoe gereed LLM-technologie is en hoe dit toekomstige toepassingen zal stimuleren. Ik heb enkele patronen hierop behandeld mijn vorige post. Hier zal ik het hebben over enkele real-world patronen voor een toepassing in de farmaceutische industrie waaraan Persistent Systems heeft gewerkt.

Grote taalmodellen en sterke punten

LLM's zijn goed in het begrijpen van taal, dat is hun sterkste punt. Het meest voorkomende patroon dat we zien bij applicaties is retrieval augmented generation (RAG), waarbij kennis extern wordt verzameld uit gegevensbronnen en in context wordt aangeboden als een prompt voor de LLM om een ​​reactie te parafraseren. In dit geval dienen supersnelle zoekmechanismen zoals vectordatabases en op Elasticsearch gebaseerde zoekmachines als eerste zoekregel. Vervolgens worden de zoekresultaten gecompileerd tot een prompt en meestal als een API-aanroep naar de LLM gestuurd.

Een ander patroon is het genereren van een query op gestructureerde gegevens door de LLM een gegevensmodel als prompt en een specifieke gebruikersquery te geven. Dit patroon zou kunnen worden gebruikt om een ​​geavanceerde "praat met uw gegevens" -interface te ontwikkelen voor SQL-databases zoals Snowflake, evenals grafische databases zoals Neo4j.

Gebruikmaken van LLM-patronen voor real-world inzichten

Persistent Systems heeft onlangs gekeken naar een patroon voor Ontploffingsbeweging, een bedrijf voor sporttelemetrie (swinganalyse voor honkbal, golf, enz.), waar we tijdreeksgegevens van spelersoverzichten hebben geanalyseerd om aanbevelingen te krijgen.

Voor complexere toepassingen moeten we de LLM-aanvragen vaak koppelen met verwerking tussen de oproepen door. Voor een farmaceutisch bedrijf hebben we een smart trails-app ontwikkeld die patiënten filtert voor klinische onderzoeken op basis van criteria die zijn geëxtraheerd uit het document over klinische onderzoeken. Hier hebben we een LLM-ketenbenadering gebruikt. Eerst ontwikkelden we een LLM om proef pdf-document te lezen en RAG-patroon te gebruiken om in- en uitsluitingscriteria te extraheren.

Hiervoor werd een relatief eenvoudiger LLM zoals GPT-3.5-Turbo (ChatGPT) gebruikt. Vervolgens hebben we deze geëxtraheerde entiteiten gecombineerd met het gegevensmodel van de SQL-database van patiënten in Snowflake, om een ​​prompt te maken. Deze prompt wordt doorgestuurd naar een krachtigere LLM zoals GPT4 en geeft ons een SQL-query om patiënten te filteren, die klaar is om op Snowflake te worden uitgevoerd. Omdat we LLM-ketening gebruiken, kunnen we meerdere LLM's gebruiken voor elke stap van de keten, waardoor we de kosten kunnen beheersen.

Momenteel hebben we besloten om deze keten deterministisch te houden voor een betere controle. Dat wil zeggen, we hebben besloten om meer intelligentie in de ketens te hebben en de orkestratie heel eenvoudig en voorspelbaar te houden. Elk element van de keten is op zichzelf al een complexe toepassing die in de pre-LLM-dagen enkele maanden nodig zou hebben om zich te ontwikkelen.

Aansturen van meer geavanceerde use-cases

Voor een geavanceerder geval kunnen we agenten zoals gebruiken Reageer om de LLM te vragen om stapsgewijze instructies te maken die moeten worden gevolgd voor een bepaalde gebruikersquery. Hiervoor is natuurlijk een high-end LLM nodig, zoals GPT4 of Cohere of Claude 2. Het risico bestaat echter dat het model een verkeerde stap zet die moet worden geverifieerd met behulp van vangrails. Dit is een afweging tussen het verplaatsen van intelligentie in bestuurbare schakels van de keten of het autonoom maken van de hele keten.

Nu we gewend raken aan het tijdperk van generatieve AI voor taal, begint de industrie LLM-toepassingen met voorspelbare ketens te gebruiken. Naarmate deze adoptie groeit, gaan we binnenkort experimenteren met meer autonomie voor deze ketens via agenten. Dat is waar het debat over AGI over gaat en we zijn benieuwd hoe dit zich in de loop van de tijd ontwikkelt.