Suurten kielimallien (LLM) siirtäminen reaalimaailman liiketoimintasovelluksiin

Suuria kielimalleja on kaikkialla. Jokainen asiakaskeskustelu tai VC-puhe sisältää kysymyksiä siitä, kuinka valmis LLM-tekniikka on ja miten se ohjaa tulevia sovelluksia. Käsittelin joitain kuvioita tästä edellinen viestini. Tässä puhun joistakin todellisista malleista lääketeollisuuden sovelluksille, joita Persistent Systems työskenteli.

Suuret kielimallit ja ydinvahvuudet

LLM:t ovat hyviä ymmärtämään kieltä, se on heidän vahvuutensa. Yleisin sovelluksissa näkemämme malli on haku lisätty sukupolvi (RAG), jossa tieto kootaan ulkoisesti tietolähteistä ja tarjotaan kontekstissa kehotteena LLM:lle muotoilla vastaus. Tässä tapauksessa huippunopeat hakumekanismit, kuten vektoritietokannat ja Elasticsearch-pohjaiset moottorit, toimivat hakujen ensimmäisenä rivinä. Sitten hakutulokset kootaan kehotteeseen ja lähetetään LLM:lle enimmäkseen API-kutsuna.

Toinen malli on kyselyn luominen strukturoidusta tiedosta syöttämällä LLM:lle tietomalli kehotteena ja tietyn käyttäjän kyselynä. Tätä mallia voitaisiin käyttää kehittyneen "talk to your data" -rajapinnan kehittämiseen SQL-tietokantoihin, kuten Snowflake, sekä graafitietokantoihin, kuten Neo4j.

Hyödynnä LLM-malleja todellisen maailman oivalluksiin

Persistent Systems tarkasteli äskettäin mallia Blast Motion, urheilun telemetriayritys (swing-analyysi pesäpallolle, golfille jne.), jossa analysoimme pelaajayhteenvetojen aikasarjatietoja saadaksemme suosituksia.

Monimutkaisemmissa sovelluksissa meidän on usein ketjutettava LLM-pyynnöt käsittelyyn puheluiden välillä. Lääkeyritykselle kehitimme älykäs polut -sovelluksen, joka suodattaa potilaat kliinisiin kokeisiin kliinisestä tutkimusasiakirjasta poimittujen kriteerien perusteella. Tässä käytimme LLM-ketjun lähestymistapaa. Ensin kehitimme LLM:n, jolla voit lukea pdf-kokeiluasiakirjan ja käyttää RAG-kuviota sisällyttämis- ja poissulkemiskriteerien poimimiseen.

Tätä varten käytettiin suhteellisen yksinkertaisempaa LLM:ää, kuten GPT-3.5-Turboa (ChatGPT). Sitten yhdistimme nämä poimitut entiteetit potilaiden SQL-tietokannan tietomalliin Snowflakessa luodaksemme kehotteen. Tämä kehote, joka syötetään tehokkaampaan LLM:ään, kuten GPT4, antaa meille SQL-kyselyn potilaiden suodattamiseksi, joka on valmis suoritettavaksi Snowflakessa. Koska käytämme LLM-ketjutusta, voisimme käyttää useita LLM:itä jokaisessa ketjun vaiheessa, jolloin voimme hallita kustannuksia.

Tällä hetkellä päätimme pitää tämän ketjun deterministisenä hallinnan parantamiseksi. Toisin sanoen päätimme käyttää enemmän älykkyyttä ketjuissa ja pitää orkestroinnin hyvin yksinkertaisena ja ennustettavana. Jokainen ketjun elementti on itsessään monimutkainen sovellus, jonka kehittäminen kestäisi muutaman kuukauden ennen LLM:ää.

Tehosta edistyneemmille käyttötapauksille

Edistyneemmässä tapauksessa voisimme käyttää agentteja kuten suhtautua kehottaa LLM:ää luomaan vaiheittaiset ohjeet, joita noudatetaan tietylle käyttäjäkyselylle. Tämä vaatisi tietysti huippuluokan LLM:n, kuten GPT4 tai Cohere tai Claude 2. Tällöin on kuitenkin olemassa riski, että malli ottaa väärän askeleen, joka on tarkistettava suojakaiteiden avulla. Tämä on kompromissi sen välillä, että älykkyyttä siirretään ketjun ohjattaviin lenkkeihin tai tehdään koko ketjusta itsenäinen.

Nykyään, kun olemme tottuneet kielten generatiivisen tekoälyn aikakauteen, ala alkaa ottamaan käyttöön LLM-sovelluksia ennakoitavilla ketjuilla. Kun tämä käyttöönotto kasvaa, alamme pian kokeilla näiden ketjujen autonomiaa agenttien kautta. Siitä AGI-keskustelussa on kyse, ja olemme kiinnostuneita näkemään, kuinka tämä kaikki kehittyy ajan myötä.