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

Stora språkmodeller finns överallt. Varje kundkonversation eller VC-pitch innefattar frågor om hur redo LLM-tekniken är och hur den kommer att driva framtida applikationer. Jag täckte några mönster för detta i min föregående inlägg. Här kommer jag att tala om några verkliga mönster för en applikation inom läkemedelsindustrin som Persistent Systems arbetade med.

Stora språkmodeller och kärnstyrkor

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

Ett annat mönster är att generera en fråga på strukturerad data genom att mata LLM med en datamodell som prompt och en specifik användarfråga. Detta mönster kan användas för att utveckla en avancerad “prata med din data”-gränssnitt för SQL-databaser som Snowflake, samt graf-databaser som Neo4j.

Använda LLM-mönster för verkliga insikter

Persistent Systems undersökte nyligen ett mönster för Blast Motion, ett företag inom sporttelemetri (svinganalys för baseball, golf etc.), där vi analyserade tids-seriedata av spelarsammanfattningar för att få rekommendationer.

För mer komplexa applikationer behöver vi ofta kedja LLM-förfrågningar med bearbetning mellan anrop. För ett läkemedelsföretag utvecklade vi en smart trails-app som filtrerar patienter för kliniska prövningar baserat på kriterier som extraherats från kliniska prövningsdokument. Här använde vi en LLM-kedjeansats. Först utvecklade vi en LLM som läser prövningsdokument och använder RAG-mönstret för att extrahera inklusions- och exklusionskriterier.

För detta använde vi en relativt enkel LLM som GPT-3.5-Turbo (ChatGPT). Sedan kombinerade vi dessa extraherade entiteter med datamodellen för patienternas SQL-databas i Snowflake, för att skapa en prompt. Denna prompt matades till en mer kraftfull LLM som GPT4, vilket gav oss en SQL-fråga för att filtrera patienter, som är redo att köras på Snowflake. Eftersom vi använder LLM-kedjor kan vi använda flera LLM för varje steg i kedjan, vilket möjliggör för oss att hantera kostnaden.

För tillfället har vi beslutat att hålla denna kedja deterministisk för bättre kontroll. Det vill säga, vi har beslutat att ha mer intelligens i kedjorna och hålla orkestreringen mycket enkel och förutsägbar. Varje element i kedjan är en komplex applikation i sig som skulle ta flera månader att utveckla i för-LLM-dagarna.

Att driva mer avancerade användningsfall

För ett mer avancerat fall kan vi använda agenter som ReAct för att prompta LLM att skapa steg-för-steg-instruktioner för att följa en specifik användarfråga. Detta skulle naturligtvis kräva en högkvalitativ 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 hjälp av skyddsräcken. Detta är en avvägning mellan att flytta intelligensen till kontrollerbara länkar i kedjan eller göra hela kedjan autonom.

Idag, allteftersom vi vänjer oss vid åldern av generativ AI för språk, börjar branschen att anta LLM-applikationer med förutsägbara kedjor. Allteftersom denna antagning 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 tid.