Suuret kielen mallit (LLM) siirrettynä todellisen maailman liiketoimintasovelluksiin

Suuria kielen malleja on joka puolella. Jokainen asiakkaan keskustelu tai VC-pitch sisältää kysymyksiä siitä, kuinka valmiit LLM-tekniikat ovat ja miten ne ohjaavat tulevia sovelluksia. Kävin läpi joitakin malleja tästä aiheesta edellisessä kirjoituksessani. Tässä keskustelen joistakin todellisen maailman sovellusmalleista, joita Persistent Systems on työstänyt lääketeollisuuden sovelluksessa.

Suuret kielen mallit ja ydinvoimavarat

LLM:t ovat hyviä kielen ymmärtämisessä, se on heidän vahvuutensa. Yleisin malli, jota näemme sovelluksissa, on hakujen avustama generointi (RAG), jossa tieto kerätään ulkoisista tietolähteistä ja annetaan kontekstina LLM:lle, jotta se voi paraphrasoida vastauksen. Tässä tapauksessa erittäin nopeat hakumekanismit, kuten vektortietokannat ja Elasticsearch-pohjaiset moottorit, toimivat ensisijaisena hakuväylänä. Sitten hakutulokset koostetaan LLM:lle annettavaksi kehotteeksi, usein API-kutsuna.

Toinen malli on kysyntägenerointi rakenteellisista tiedoista syöttämällä LLM:lle tietomalli kehotteena ja tietyn käyttäjän kysymys. Tätä mallia voidaan käyttää kehittämään edistyneitä “puhu tietoihisi” -liittymiä SQL-tietokantoja, kuten Snowflake, sekä graafiset tietokannat, kuten Neo4j, varten.

Hyödyntäminen LLM-malleja todellisen maailman oivalluksille

Persistent Systems tarkasteli äskettäin mallia Blast Motion:lle, urheilutelemetriayritykselle (lyöntianalyysi baseballiin, golfiin jne.), jossa analysoimme aikasarjatietoja pelaajien yhteenvetoja saadaksemme suosituksia.

Monimutkaisemmissa sovelluksissa meidän usein on yhdistettävä LLM-pyynnöt prosessoinnilla pyyntöjen välillä. Lääketeollisuusyhtiölle kehittimme älykkään trails-sovelluksen, joka suodattaa potilaita kliinisiin kokeisiin kriteerejä, jotka on poimittu kliinisen kokeen asiakirjasta. Tässä käytimme LLM-ketju lähestymistapaa. Ensinnäkin kehittimme LLM:n lukemaan kokeen PDF-dokumentin ja käyttämään RAG-mallia poimimaan mukaan ottamis- ja poissulkemiskriteerit.

Tässä käytimme suhteellisen yksinkertaista LLM:ä, kuten GPT-3.5-Turboa (ChatGPT). Sitten yhdistimme nämä poimittujen entiteetit potilaiden tietomallin SQL-tietokannassa Snowflakessa luodaksemme kehotteen. Tämä kehote annettiin voimakkaammalle LLM:lle, kuten GPT4:lle, joka antoi meille valmiin SQL-kyselyn suodattaa potilaita, joka on valmis suoritettavaksi Snowflakessa. Koska käytimme LLM-ketjua, voimme käyttää useita LLM:ä kunkin ketjun vaiheessa, mikä mahdollisti kustannusten hallinnan.

Päätimme pitää tämän ketjun deterministisenä paremman hallinnan vuoksi. Siis, päätimme lisätä enemmän älykkyyttä ketjuun ja pitää orkestraation hyvin yksinkertaisena ja ennustettavana. Kunkin ketjun osa on itsessään monimutkainen sovellus, joka vaatisi useita kuukausia kehittämistä ennen LLM-aikakautta.

Voimakkaampien käyttötapauksien mahdollistaminen

Monimutkaisemmassa tapauksessa voimme käyttää agenteja, kuten ReAct:ia, kehottamaan LLM:ää luomaan vaiheittaiset ohjeet tietyn käyttäjän kysymyksen seuraamiseksi. Tämä vaatisi kuitenkin korkean tason LLM:n, kuten GPT4:n tai Cohere:n tai Claude 2:n. Mutta silloin on riski, että malli tekee virheisen askelen, joka vaatii vartioaitojen varmistamista. Tämä on kompromissi älyn siirtämisestä hallittaviin ketjun osiin tai tekemällä koko ketjusta autonomisen.

Tänään, kun totumme generaattorisen AI:n aikakauteen kielen osalta, teollisuus on alkamassa omaksua LLM-sovelluksia ennustettavilla ketjuilla. Kun tämä omaksuminen kasvaa, aloitamme pian kokeilemisen näiden ketjujen autonomian kanssa agenteja käyttäen. Se on se, mitä AGI-keskustelu on kaikki, ja olemme kiinnostuneita nähdä, miten kaikki tämä kehittyy ajan myötä.