Flytta stora språkmodeller (LLM) till verkliga affärsapplikationer

Stora språkmodeller finns överallt. Varje kundsamtal eller VC-pitch involverar frågor om hur redo LLM-tekniken är och hur den kommer att driva framtida applikationer. Jag täckte in några mönster om detta mitt tidigare inlägg. Här kommer jag att prata om några verkliga mönster för en applikation inom läkemedelsindustrin som Persistent Systems arbetat med.

Stora språkmodeller och kärnstyrkor

LLM är bra på att förstå språk, det är deras styrka. Det vanligaste mönstret vi ser med applikationer är retrieval augmented generation (RAG), där kunskap sammanställs externt från datakällor och tillhandahålls i ett sammanhang som en uppmaning för LLM att parafrasera ett svar. I det här fallet fungerar supersnabba sökmekanismer som vektordatabaser och Elasticsearch-baserade motorer som en första söklinje. Sedan sammanställs sökresultaten till en prompt och skickas till LLM mestadels som ett API-anrop.

Ett annat mönster är att generera en fråga på strukturerad data genom att mata LLM en datamodell som uppmaning och en specifik användarfråga. Det här mönstret kan användas för att utveckla ett avancerat "tala med dina data"-gränssnitt för SQL-databaser som Snowflake, såväl som grafdatabaser som Neo4j.

Utnyttja LLM-mönster för verkliga insikter

Persistent Systems tittade nyligen på ett mönster för Blast Motion, ett sporttelemetriföretag (svinganalys för baseboll, golf, etc.), där vi analyserade tidsseriedata för spelarsammanfattningar för att få rekommendationer.

För mer komplexa applikationer behöver vi ofta kedja LLM-förfrågningar med bearbetning mellan samtalen. För ett läkemedelsföretag har vi utvecklat en smart trails-app som filtrerar patienter för kliniska prövningar baserat på kriterier utvunna från kliniska prövningsdokument. Här använde vi en LLM-kedja. Först utvecklade vi en LLM för att läsa testdokument i pdf och använda RAG-mönster för att extrahera inklusions- och exkluderingskriterier.

För detta användes en relativt enklare LLM som GPT-3.5-Turbo (ChatGPT). Sedan kombinerade vi dessa extraherade enheter med datamodell av patientens SQL-databas i Snowflake, för att skapa en prompt. Denna prompt matas till en mer kraftfull LLM som GPT4 ger oss en SQL-fråga för att filtrera patienter, som är redo att köras på Snowflake. Eftersom vi använder LLM-kedja kan vi använda flera LLM:er för varje steg i kedjan, vilket gör det möjligt för oss att hantera kostnader.

För närvarande beslutade vi att hålla denna kedja deterministisk för bättre kontroll. Det vill säga, vi bestämde oss för att ha mer intelligens i kedjorna och hålla orkestreringen väldigt enkel och förutsägbar. Varje del av kedjan är en komplex applikation i sig som skulle ta några månader att utveckla under dagarna före LLM.

Drivs av mer avancerade användningsfall

För ett mer avancerat fall kan vi använda agenter som Reagera för att uppmana LLM att skapa steg för steg instruktioner att följa för en viss användarfråga. Detta skulle naturligtvis behöva en avancerad LLM som GPT4 eller Cohere eller Claude 2. Men då finns det en risk att modellen tar ett felaktigt steg som måste verifieras med skyddsräcken. Detta är en avvägning mellan att flytta intelligens i kontrollerbara länkar i kedjan eller att göra hela kedjan autonom.

Idag, när vi vänjer oss vid åldern av Generativ AI för språk, börjar branschen att ta till sig LLM-applikationer med förutsägbara kedjor. När denna adoption växer kommer vi snart att börja experimentera med mer autonomi för dessa kedjor via agenter. Det är vad debatten om AGI handlar om och vi är intresserade av att se hur allt detta utvecklas över tiden.