Flytting av store språkmodeller (LLM) til virkelige forretningsapplikasjoner

Store språkmodeller er overalt. Hver kundesamtale eller VC-pitch inneholder spørsmål om hvordan LLM-teknologi er klar og hvordan den vil drive fremtidige applikasjoner. Jeg dekket noen mønster på dette i min forrige post. Her vil jeg snakke om noen virkelige mønster for en applikasjon i legemiddelindustrien som Persistent Systems arbeidet med.

Store språkmodeller og kjernekompetanse

LLM-er er gode til å forstå språk, det er deres spesialitet. Det vanligste mønsteret vi ser med applikasjoner er retrieval augmented generation (RAG), hvor kunnskap er eksternt samlet fra datakilder og gitt i kontekst som en prompt for LLM å parafrasere et svar. I dette tilfelle tjener super-raske søkemekanismer som vektor-databaser og Elasticsearch-baserte motorer som en første linje for søk. Deretter samles søkeresultatene inn i en prompt og sendes til LLM mest som en API-kall.
Et annet mønster er å generere en spørring på strukturert data ved å mata LLM en datamodell som prompt og en bestemt brukerspørring. Dette mønsteret kunne brukes til å utvikle en avansert “snakk til dine data”-grensesnitt for SQL-databaser som Snowflake, samt graf-databaser som Neo4j.

Utnyttelse av LLM-mønster for virkelige innsikter

Persistent Systems har nylig sett på et mønster for Blast Motion, et selskap for idretts-telemetri (sving-analyse for baseball, golf osv.), hvor vi analyserte tidsserie-data av spillersammendrag for å få anbefalinger.
For mer komplekse applikasjoner, må vi ofte kjede LLM-forespørsler med prosessering imellom kall. For et legemiddelselskap utviklet vi en smart trails-applikasjon som filtrerer pasienter for kliniske prøver basert på kriterier ekstrahert fra kliniske prøvedokumenter. Her brukte vi en LLM-kjede-tilnærming. Først utviklet vi en LLM for å lese prøvedokumenter og bruke RAG-mønster til å ekstrahere inklusjons- og eksklusjonskriterier.
For dette, ble en relativt enklere LLM som GPT-3.5-Turbo (ChatGPT) brukt. Deretter kombinerte vi disse ekstraherte enhetene med en datamodell av pasientens SQL-database i Snowflake, for å opprette en prompt. Denne prompten ble matet til en mer kraftfull LLM som GPT4, som ga oss en SQL-spørring for å filtrere pasienter, som er klar til å kjøre på Snowflake. Ettersom vi bruker LLM-kjeding, kunne vi bruke flere LLM-er for hvert trinn i kjeden, og dermed kunne vi håndtere kostnadene.
For øyeblikket har vi besluttet å holde denne kjeden deterministisk for bedre kontroll. Det vil si at vi har bestemt å ha mer intelligens i kjedene og holde orkestreringen meget enkel og forutsigbar. Hvert element i kjeden er en kompleks applikasjon i seg selv som ville tatt noen måneder å utvikle i pre-LLM-dager.

Drivende mer avanserte brukstilfeller

For et mer avansert tilfelle, kunne vi bruke agenter som ReAct for å prompte LLM til å opprette trinn-for-trinn-instruksjoner for å følge for en bestemt brukerspørring. Dette ville naturligvis kreve en høy-end LLM som GPT4 eller Cohere eller Claude 2. Men deretter er det en risiko for at modellen tar et feil trinn som må verifiseres ved hjelp av guardrails. Dette er en avveining mellom å flytte intelligensen i kontrollerbare lenker i kjeden eller å gjøre hele kjeden autonom.
I dag, mens vi blir vant til alderen av generativ AI for språk, begynner industrien å adoptere LLM-applikasjoner med forutsigbare kjeder. Ettersom denne adopsjonen vokser, vil vi snart begynne å eksperimentere med mer autonomi for disse kjedene via agenter. Det er det debatten om AGI handler om, og vi er interessert i å se hvordan alt dette utvikler seg over tid.