Flytning af store sprogmodeller (LLM) til virkelige forretningsapplikationer

Store sprogmodeller er overalt. Hver kunde-samtale eller VC-præsentation indebærer spørgsmål om, hvor parat LLM-teknologi er, og hvordan den vil drive fremtidige applikationer. Jeg dækkede nogle mønstre for dette i min forrige post. Her vil jeg tale om nogle virkelige mønstre for en applikation i lægemiddelindustrien, som Persistent Systems har arbejdet på.

Store Sprogmodeller og Kernekompetencer

LLM’er er gode til at forstå sprog, det er deres styrke. Det mest almindelige mønster, vi ser med applikationer, er retrieval-augmenteret generering (RAG), hvor viden er eksternt samlet fra datakilder og præsenteres i kontekst som en prompt til LLM’er til at omskrive en respons. I dette tilfælde fungerer super-hurtige søgemekanismer som vektor-databaser og Elasticsearch-baserede motorer som en første linje af søgning. Søgeresultaterne samles herefter i en prompt og sendes til LLM’er som en API-opkald.

Et andet mønster er generering af en forespørgsel på strukturerede data ved at give LLM’er en datamodel som prompt og en bestemt brugerforespørgsel. Dette mønster kan bruges til at udvikle en avanceret “tal til dine data”-grænseflade for SQL-databaser som Snowflake samt graf-databaser som Neo4j.

Udnyttelse af LLM-Mønstre for Virkelige Indsighter

Persistent Systems har nylig set på et mønster for Blast Motion, et sports-telemetri-firma (sving-analyse for baseball, golf osv.), hvor vi analyserede tids-serie-data af spillersammendrag for at få anbefalinger.

For mere komplekse applikationer har vi ofte brug for at kæde LLM-anmodninger med behandling imellem opkald. For et lægemiddelfirma udviklede vi en smart trails-applikation, der filtrerer patienter for kliniske forsøg baseret på kriterier, der er ekstraheret fra kliniske forsøgsdokumenter. Her brugte vi en LLM-kæde-tilgang. Først udviklede vi en LLM til at læse forsøgsdokumenter i PDF-format og bruge RAG-mønsteret til at ekstrahere inklusions- og eksklusionskriterier.

Til dette formål blev en relativt enkel LLM som GPT-3.5-Turbo (ChatGPT) brugt. Herefter kombinerede vi disse ekstraherede enheder med en datamodel af patienters SQL-database i Snowflake for at oprette en prompt. Denne prompt blev herefter givet til en mere avanceret LLM som GPT4, hvilket gav os en SQL-forespørgsel til at filtrere patienter, der er klar til at køre på Snowflake. Da vi bruger LLM-kæder, kan vi bruge multiple LLM’er til hvert trin i kæden, hvilket ermöglicer os at styre omkostningerne.

For tiden har vi besluttet at holde denne kæde deterministisk for bedre kontrol. Det vil sige, at vi har besluttet at have mere intelligens i kæderne og holde orkestreringen meget enkel og forudsigelig. Hvert element i kæden er en kompleks applikation i sig selv, som ville tage flere måneder at udvikle i for-LLM-dage.

Drivende mere Avancerede Brugs Tilfælde

For et mere avanceret tilfælde kan vi bruge agenter som ReAct til at prompte LLM’er til at oprette trin-for-trin-instruktioner til at følge for en bestemt brugerforespørgsel. Dette ville naturligvis kræve en høj-end LLM som GPT4 eller Cohere eller Claude 2. Men derefter er der en risiko for, at modellen tager et forkert trin, som skal verificeres ved hjælp af guardrails. Dette er en afvejning mellem at flytte intelligens i kontrollerbare led i kæden eller gøre hele kæden autonom.

I dag, da vi vænner os til alderen af Generativ AI for sprog, begynder industrien at adoptere LLM-applikationer med forudsigelige kæder. Da denne adoption vokser, vil vi snart begynde at eksperimentere med mere autonomi for disse kæder via agenter. Det er, hvad debatten om AGI handler om, og vi er interesseret i at se, hvordan alt dette udvikler sig over tid.