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

Store språkmodeller er overalt. Hver kunde-samtale eller VC-pitch inneholder spørsmål om hvor klar LLM-teknologi er 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 kjernekompetanser

LLM-er er gode til å forstå språk, det er deres spesialitet. Det vanligste mønsteret vi ser med applikasjoner er retrieval-augmented generering (RAG), hvor kunnskap er eksternt samlet fra datakilder og gitt i kontekst som en prompt for LLM å parafrasere en respons. I dette tilfelle tjener super-rask søke-mekanismer som vektor-databaser og Elasticsearch-baserte motorer som en første linje av søk. Deretter samles søke-resultatene 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 å mate LLM en datamodell som prompt og en bestemt brukerspørring. Dette mønsteret kan brukes til å utvikle en avansert “snakk til dine data”-grensesnitt for SQL-databaser som Snowflake, samt graf-databaser som Neo4j.

Utnytting 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 tidsseriedata av spillersammendrag for å få anbefalinger.

For mer komplekse applikasjoner, må vi ofte kjede LLM-forespørsler med prosessering mellom kall. For et legemiddelselskap utviklet vi en smart trails-applikasjon som filtrerer pasienter for kliniske prøver basert på kriterier uttrukket 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ønsteret til å uttrekke inklusjons- og eksklusjonskriterier.

Til dette ble en relativt enkel LLM som GPT-3.5-Turbo (ChatGPT) brukt. Deretter kombinerte vi disse uttrukne enhetene med en datamodell av pasienter i SQL-databasen Snowflake, for å opprette en prompt. Denne prompten ble matet til en mer kraftfull LLM som GPT4, som ga oss en SQL-spørring til å filtrere pasienter, som er klar til å kjøres på Snowflake. Siden vi bruker LLM-kjeding, kan vi bruke flere LLM-er for hvert trinn i kjeden, og dermed kunne vi håndtere kostnadene.

For tiden har vi bestemt oss for å holde denne kjeden deterministisk for bedre kontroll. Det vil si at vi har bestemt oss for å ha mer intelligens i kjedene og holde orkestreringen veldig enkel og forutsigbar. Hvert element i kjeden er en kompleks applikasjon i seg selv som ville tatt noen måneder å utvikle i pre-LLM-dagene.

Utnytting av mer avanserte brukstilfeller

For et mer avansert tilfelle kunne vi bruke agenter som ReAct til å prompte LLM til å opprette trinn-for-trinn-instruksjoner for en bestemt brukerspørring. Dette ville naturligvis kreve en høyere LLM som GPT4 eller Cohere eller Claude 2. Men deretter er det en risiko for at modellen tar et feilaktig 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 å bruke generativ AI for språk, begynner industrien å adoptere LLM-applikasjoner med forutsigbare kjeder. Mens 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 interesserte i å se hvordan alt dette utvikler seg over tid.