Siirtäminen suurten kielimallien (LLM) käyttöön liiketoiminnan sovelluksissa

Suuret kielimalleita on joka paikassa. Jokainen asiakkaan keskustelu tai VC-esitys sisältää kysymyksiä siitä, miten valmiit LLM-tekniikat ovat ja miten ne ohjaavat tulevia sovelluksia. Käsitin joitakin malleja tästä aiemmassa kirjoituksessani. Tässä keskustelen joistakin todellisista sovellusmallista lääketeollisuudessa, jossa Persistent Systems on työskennellyt.

Suuret kielimalleit ja ydinvoimavarat

LLM:t ovat hyviä kielen ymmärtämisessä, se on heidän vahvuutensa. Yleisin malli, jota näemme sovelluksissa, on hakujen täydentäminen (RAG), jossa tieto kerätään ulkoisista tietolähteistä ja esitetään kontekstina kehotuksena LLM:lle muotoilla vastaus. Tässä tapauksessa erittäin nopeat hakumekanismit, kuten vektortietokannat ja Elasticsearch-pohjaiset moottorit, toimivat ensimmäisenä hakulinjana. Sitten hakutulokset koostetaan kehotukseksi ja lähetetään LLM:lle pääasiassa API-kutsuna.
Toinen malli on kyselyn luominen rakenteellisista tiedoista syöttämällä LLM:lle tietomalli kehotuksena ja tietyn käyttäjän kyselyn. Tätä mallia voidaan käyttää kehittämään edistynyttä “puhu tietoihisi” -liittymää SQL-tietokantoja varten, kuten Snowflake, sekä graafitietokantoja, kuten Neo4j.

Hyödyntäminen LLM-malleja todellisen maailman näkymien saamiseksi

Persistent Systems tarkasteli äskettäin mallia Blast Motion:lle, urheilutelemetriayritykselle (lyöntianalyysi baseballiin, golfiin jne.), jossa analysoimme aikasarjatietoja pelaajien yhteenvetoja saadaksemme suosituksia.
Monimutkaisempien sovellusten kohdalla meidän usein on ketjutettava LLM-pyynnöt prosessoinnilla väliin. Lääkeyritykselle kehittimme älykkään sovelluksen, joka suodattaa potilaita kliinisiin kokeisiin kriteerejä, jotka on poimittu kliinisen koehenkilöasiakirjasta. Tässä käytimme LLM-ketjumallia. Ensinnäkin kehittimme LLM:n lukemaan koehenkilöasiakirjan ja käyttämään RAG-mallia poimimaan sisään- ja poislukukriteerejä.
Tässä käytimme suhteellisen yksinkertaista LLM:ä, kuten GPT-3.5-Turbo (ChatGPT). Sitten yhdistimme nämä poimittujen entiteetit potilaiden tietomallin SQL-tietokannassa Snowflakessa luomaan kehotuksen. Tämä kehotus syötettiin voimakkaampaan LLM:ään, kuten GPT4, josta saimme SQL-kyselyn, joka on valmis suoritettavaksi Snowflakessa. Koska käytimme LLM-ketjua, voimme käyttää useita LLM:ä kunkin ketjun vaiheessa, mikä mahdollistaa kustannusten hallinnan.
Päätimme pitää tämän ketjun deterministisenä paremman hallinnan vuoksi. Siis päätimme lisätä älykkyyttä ketjuun ja pitää orkestraation yksinkertaisena ja ennustettavana. Kunkin ketjun osa on monimutkainen sovellus itsessään, joka vaatisi useita kuukausia kehittämiseen ennen LLM-aikaa.

Voimakkaampien käyttötapausten mahdollistaminen

Monimutkaisemman tapauksen kohdalla voimme käyttää agenteja, kuten ReAct, kehotuksena LLM:lle luomaan vaiheittaiset ohjeet seurattaviksi tietyn käyttäjän kyselyn kohdalla. Tämä vaatisi korkean pään LLM:n, kuten GPT4 tai Cohere tai Claude 2. Mutta sitten on riski, että malli tekee virheellisen askelen, joka vaatii vartiointia. Tämä on kompromissi älyn siirtämisestä hallittaviin ketjun osiin tai tekemällä koko ketjusta autonomista.
Tänään, kun totumme generatiivisen älykkään ikään kielelle, teollisuus on aloittamassa LLM-sovellusten omaksumisen ennustettavilla ketjuilla. Kun tämä omaksuminen kasvaa, aloitamme pian kokeilemisen autonomian ketjujen kanssa agenteja käyttämällä. Se on se, mitä AGI-keskustelu on kaikki, ja olemme kiinnostuneita nähdä, miten kaikki tämä kehittyy ajan myötä.