Viimeisimmät julkaisut
Konenäöllä eroon datan palastelusta RAG-toteutuksissa
Useimpien nykyaikaisten GenAI-ratkaisujen ytimessä on niin kutsuttu RAG (Retrieval Augmented Generation) -toteutus, eli haulla tehostettu generointi. Sovelletun tekoälyn parissa työskentelevien ohjelmistoinsinöörien voikin usein kuulla puhuvan “rägistä”. RAGin avulla kielimalli pystyy vastaamaan kysymyksiin esimerkiksi yrityksen omien salaisten tietojen pohjalta.
Kirjainyhdistelmän ensimmäinen kirjain R eli retrieval ("nouto") viittaa tiedonhakuun. Kun käyttäjä kysyy GenAI-botilta kysymyksen, konepellin alla olevan haun pitäisi löytää täsmällisesti käyttäjän kysymykseen liittyvä materiaali muodostaakseen täydellisen hallusinoinneista vapaan vastauksen. Termit A ja G viittaavat puolestaan tiedon syöttämiseen kielimallille ja itse vastauksen generointiin.
Tämä kirjoitus keskittyy pääosin tiedonhakuun, sillä se on kriittisin, työläin ja vaikein osuus RAG-arkkitehtuurin toteutuksessa. Käymme ensin läpi tiedonhakua yleisellä tasolla, jonka jälkeen esittelemme perinteisen tekstinpalasiin pohjautuvan RAG-toteutuksen tiedonhaun mekaniikan. Kirjoituksen loppuosa keskittyy uuteen RAG-menetelmään, jonka haku ja generointivaihe perustuvat kuvamuodossa olevaan dataan.
Tiedonhaun lyhyt historia
Google sekä moni muu iso hakukoneyritys ovat yrittäneet ratkaista tiedonhakua vuosikymmeniä. Paino sanalla yrittäneet. Tiedonhaku ei ole vieläkään niin helppoa kuin sen pitäisi olla. Osasyynä tähän on se, että ihmiset käsittelevät tietoa eri tavalla kuin koneet. Luonnollisen kielen muuntaminen järkeväksi hauksi sekalaiseen tietomassaan ei ole helppoa. Googlen tehokäyttäjät tietävät varmasti kaikki mahdolliset kikat, joilla haun saa taipumaan omaan tahtoon, mutta silti haun tekeminen on työläs prosessi ja hakutulokset voivat olla varsin heikkoja.
Kielimallien kehittymisen myötä tiedonhakuun on yhtäkkiä saatu luonnollisen kielen käyttöliittymä. Kielimallit itsessään ovat surkeita kertomaan faktapohjaista tietoa, sillä niiden koulutusdata on mallin koulutushetken näkymä maailmaan. Tämän lisäksi tieto pakkaantuu mallin sisällä, ja kaikille tuttu hallusinointiongelma on taattu. Kielimallit eivät muutenkaan ole hakukoneita, vaan päättelykoneita.
Kielimallien hyvä puoli on se, että niille voi antaa esimerkkejä datasta, ohjeistuksen ja pyytää vastaamaan näiden pohjalta. Tämä on tyypillinen tapa käyttää ChatGPT:tä ja vastaavia keskustelupohjaisia tekoälykäyttöliittymiä. Mutta ihmiset ovat laiskoja, ja samalla vaivalla olisit tehnyt saman homman jo itse. Siksi tarvitsemme RAGin, jotta voimme antaa pelkän kysymyksen sovelletun tekoälyn ratkaisulle ja saada täydellisen oikeaan tietoon pohjautuvan vastauksen. Näin siis oletetussa täydellisen haun maailmassa.
Miten tiedonhaku toimii perinteisessä RAGissä?
RAGin hakumenetelmiä on yhtä monta kuin toteutettuja RAGeja. Haku on aina optimointiongelma, eikä kaikille sopivaa geneeristä toteutusta ole olemassa: tekoälyarkkitehtuuri on aina räätälöitävä kuhunkin ratkaisuun sopivaksi, niin haun kuin muidenkin ominaisuuksien osalta.
Tyyppillinen pohjaratkaisu on tästä huolimatta niin kutsuttu tiedon palastelutekniikka (chunking). Tässä menetelmässä tietovarastossa sijaitseva tieto, usein dokumentit, paloitellaan pieniksi, noin kappaleen mittaisiksi pätkiksi. Tämän jälkeen jokaisesti palasesta lasketaan upotusvektori kielimalleihin liittyvien upotusmallien avulla. Lopputuloksena oleva numeerinen vektori tallennetaan erilliseen vektoreiden tallentamiseen erikoistuneeseen tietovarastoon eli vektoritietokantaan.
Naiivi hakutoteutus vektoritietokannan päällä toimii tämän jälkeen seuraavasti:
Käyttäjä kysyy kysymyksen
Kysymyksestä lasketaan upotusvektori
Vektoritietokantaan tehdään niin kutsuttu semanttinen haku
Semanttisessa haussa kysymyksen ja tietokannan upotusvektorien läheisyyttä toisiinsa mitataan matemaattisesti eli haku huomioi tekstinpalojen kontekstin sekä merkityksen
Vektorihaku palauttaa esimerkiksi 10 parhaiten hakuun täsmäävää tekstinpalasta
Palautuneet tekstinpalaset laitetaan kielimallin kontekstiin (promptiin) ja pyydetään tuottamaan vastaus alkuperäiseen kysymykseen. Nämä kaksi viimeistä vaihetta haun jälkeen ovat siis RAG:n A ja G -vaihe.
Tiedon palastelutekniikka ja muu esikäsittely ennen indeksointia vaikuttaa merkittävästi haun laatuun. Tähän esivalmisteluun on olemassa kymmeniä erilaisia menetelmiä, ja tämän lisäksi tietoa voidaan järjestää tai karsia vielä haun jälkeenkin (ns. reranking). Vektorihaun ohella voidaan käyttää lisäksi perinteistä avainsanahakua tai mitä tahansa muuta ohjelmallista rajapintaa, josta saadaan haettua rakenteellista tietoa. Näihin tekniikoihin liittyvät esimerkiksi termit kuten text-to-sql ja text-to-api, joissa käyttäjän kysymyksestä muodostetaan uusi sql- tai api-kysely. Ei-rakenteellisen datan tapauksessa palastelu ja vektorihaku ovat kuitenkin datan hakemisessa yleisesti käytetty tekniikka.
Palastelu ei ole ongelmatonta. Eri tiedosto- ja dataformaattien huomiointi on työlästä, ja jokaiselle formaatille on koodattava erikseen oma palastelijakoodinsa. Tähän on valmiita ohjelmistokirjastoja, mutta ne eivät ole täydellisiä. Palasten koko ja päällekkäisyys on otettava huomioon. Seuraavana esteeksi muodostuvat kuvat, kuvaajat, taulukot ja muu data, jossa visuaalisen informaation ja ympäröivän kontekstin ymmärtäminen on erittäin oleellista. Tähän liittyvät oleellisesti otsikot, fonttikoot ja muut pienet visuaaliset vihjeet, jotka kadotetaan palastelutekniikassa kokonaan.
Mitä jos tätä palastelua ei tarvittaisi ollenkaan, ja haku toimisi ikään kuin ihminen silmäilisi läpi kokonaisia sivuja dokumenteista?
Kuvat säilyttävät visuaalisen informaation
Kuviin pohjautuvien hakumenetelmien toteutus on tullut mahdolliseksi kehittyneiden multimodaalisten mallien myötä. Yleisesti kuvadataan pohjautuvien tekoälyratkaisujen parhaana esimerkkinä voitaneen pitää Teslaa, jonka autonomisen ajon ratkaisu pohjautuu pelkästään kameroihin. Ajatus tämän lähestymistavan takana on siinä, että myös ihminen havainnoi ympäristöään pääasiallisesti näön avulla.
Samaa ajatusta voidaan soveltaa RAG-toteutuksissa. Palastelun sijasta indeksoidaan kokonaisia sivuja suoraan kuvina eli samassa muodossa, jossa ihminen sivut näkee. Käytännössä siis esimeriksi PDF-dokumentin jokainen sivu syötetään kuvamuodossa erikoistuneelle tekoälymallille (ColPali), joka luo siitä visuaaliseen sisältöön sekä tekstiin perustuvan vektorikuvauksen. Nämä vektorit lisätään vektoritietokantaan. Voimme kutsua tätä uutta RAG-arkkitehtuuria nimellä Vision Retrieval-Augmented Generation, lyhyemmin V-RAG.
Lähestymistavan etuna on todennäköisesti parempi osumatarkkuus kuin perinteisessä haussa, sillä tekstisisällön lisäksi multimodaalimallin tuottama datan vektoriesitys huomioi myös sisällön visuaaliset elementit. Tällöin hakutulokset ovat kokonaisia sivuja dokumenteista, jonka jälkeen kuvat syötetään edelleen kuvina kyvykkäälle multimodaalimallille, kuten GPT4o:lle. Lähdekuvia tulkkaava malli voi tällöin viitata suoraan jonkin taulukon tai kuvaajan tietoon.
V-RAG toimii ilman että kuvaajia, taulukkoa tai vastaavaa monimutkaista rakennetta purettaisiin ensin tekstiksi, rakenteistettaisiin teksti uuteen muotoon, laitettaisiin vektorikantaan, haettaisiin sieltä, järjesteltäisiin uudelleen promptiin ja saataisin viimein vastaus. Tästä on suuri etu etenkin vanhojen käyttöohjeiden, taulukkopainotteisten dokumenttien ja lähtökohtaisesti kaikkien ihmisille suunniteltujen dokumenttiformaattien kanssa, joissa sisältö koostuu suurelta osin muusta datasta kuin puhtaasta leipätekstistä. Indeksointi on myös huomattavasti nopeampaa kuin perinteisissä menetelmissä, joissa esimerkiksi dokumentin elementtien asettelu tunnistetaan ja teksti irroitetaan OCR-menetelmällä.
Tekstin irroittaminen dokumenteista saattaa tuoda edelleen lisäarvoa ja auttaa haussa kuvien rinnalla. Tästä huolimatta tiedon palastelu tekniikkana jäänee pian vain yhdeksi tavaksi toteuttaa AI-hakujärjestelmiä.
Vision-RAGin toteutus käytännössä: Paligemma, ColPali ja vektoritietokanta
V-RAGin toteutus vaatii vielä tällä hetkellä pääsyn erikoistuneisiin malleihin sekä GPU-laskentatehoa toisin kuin perinteinen tekstipohjainen RAG, jota voi ajaa pääosin pilvestä helposti saatavilla olevilla isoilla perusmalleilla. Paras tapa toteuttaa V-RAG on hyödyntää tällä hetkellä tähän käyttötarkoitukseen kehitettyä mallia, joka on nimeltään ColPali.
ColPali perustuu ColBERT-mallissa esiteltyyn monivektorihakuun sekä Googlen multimodaaliseen Paligemma-kielimalliin. ColPali on multimodaalinen hakumalli, eli se ymmärtää tekstisisällön lisäksi myös dokumenttien visuaaliset elementit. Käytännössä ColPalin kehittäjät laajensivat ColBERTin tekstipohjaisen hakumetelmän kattamaan myös visuaalisen avaruuden Paligemma-mallia hyödyntämällä.
Upotuksia luodessaan ColPali jakaa jokaisen kuvan 32 x 32 kokoiseen ruudukkoon, eli kokonaisuudessaan jokaisessa kuvassa on noin 1024 palaa tai “patchia”, ja jokaista niistä kuvaa 128-ulotteinen vektori (todellisuudessa palasia on yhteensä 1030, sillä jokaiseen kuvaan lisätään myös tämän käskyn tokenit: “Describe the image.”).
Käyttäjän tekstimuotoinen kysymys muunnetaan samaan upotusavaruuteen, jotta hakuvaiheessa paloja sekä kysymyksen osia voidaan verrata toisiinsa. Itse hakuvaihe perustuu niin kutsuttuun MaxSim-menetelmään, joka on avattu hyvin tässä kirjoituksessa. Tämä hakumenetelmä on valmiiksi toteuttuna monissa monivektoreita tukevissa vektoritietokannoissa.
Vision is All You Need - V-RAG-demo & koodi
Toteutimme V-RAG demon, jonka koodi on saatavilla Softlandian GitHubissa vision-is-all-you-need -repossa. Tilimme alta löytyy myös muita sovelletun tekoälyn demoja!
ColPalin ajo vaatii näytönohjaimen, jossa on paljon muistia. Siksi sen ajo on helpointa pilvessä alustalla, joka mahdollistaa grafiikkalaskentatehon käyttämisen. Tähän valikoitui mainio Modal-alusta, jossa GPU-kapasiteetin käyttö palvelittomasti on helppoa ja kustannustehokasta.
Useimmista vastaavista internetissä saatavilla olevista akateemisista Jupyter Notebook -pohjaisista demoista poiketen voit kloonata repon ja ajaa demoa itse ilmaiseksi Modalissa GPU:lla, ohjeet löytyvät readmesta. Tämä vie sinulta aikaa muutaman minuutin. Vision is All You Need on siis konaisvaltainen sovelletun tekoälyn esimerkkitoteutus.
Tässä demossa käytimme lisäksi Qdrantin in-memory versiota. Jos ajat demoa, niin huomioi, että indeksoitu data häviää kun alla oleva kontti lakkaa olemasta. Qdrant on tukenut monivektorihakua versiosta 1.10.0 lähtien. Demo tukee ainoastaan PDF-tiedostoja, joiden sivut muunnetaan kuviksi kätevellä pypdfium2-kirjastolla. Näiden lisäksi käytössä on transformers-kirjaston sekä ColPalin kehittäjien oma colpali-engine itse ColPali-mallin ajamiseen. Lisäksi apuna on muitakin kirjastoja, kuten opencv-python-headless, joka on allekirjoittaneen kädenjälkeä.
Demon tarjoaa ideksointia ja kysymysten kysymistä varten HTTP-rajapinnan. Rajapinnan päälle toteutimme yksinkertaisen käyttöliittymän Reactilla. Käyttöliittymällä voi myös visualisoida jokaisen kyselyn tokenin niin kutsutun lämpökartan, joka kuvaa sitä, mitkä palaset malli tulkitsi oleellisiksi kuvassa.
Onko konenäkö sittenkään ainoa asia, jota tarvitset?
Demon otsikosta huolimatta hakumallit, kuten demon ColPali, eivät ole vielä riittävän hyviä etenkään monikielisen datan kanssa. Mallit on myös tyypillisesti opetettu rajallisella määrällä esimerkkejä, jotka ovat lähes aina tietynlaisia PDF-tiedostoja. Siksi demokin tukee vain PDF-tiedostoja.
Toinen ongelma on kuvadatan ja siitä laskettavien upotuksien koko. Ne vievät huiomattavan määrän tilaa, ja haku suureen datamassaan vie merkittävästi laskentatehoa. Tämän ongelman voi ratkaista osittain kvantisoimalla upotuksia pienemmiksi aina binäärimuotoon saakka. Tällöin osa tiedosta häviää, ja haun tarkkuus kärsii aavistuksen verran. Demossamme tätä ei ole toteutettu, sillä optimointi ei ole demon kannalta oleellista. Lisäksi on syytä huomioida, että Qdrant ei tue binäärivektoreita sellaisenaan, mutta voit ottaa kvantisoinnin käyttöön Qdrantissa, jolloin Qdrant optimoi vektorit sisäisesti (hamming-pohjainen MaxSim ei ole tuettu).
Edelle mainituista syistä johtuen ColPalin rinnalla on hyvä ajaa esimerkiksi perinteistä avainsanapohjaista hakua, joka tekee ensimmäisen karsintakierroksen, ja sen jälkeen ColPalilla haetaan karsituista tuloksista lopulliset kielimallin kontekstiin päätyvät sivut.
Multimodaaliset hakumallit kehittynevät jatkossa aivan kuin perinteiset tekstiupotuksia tuottavat upotusmallit. Pidän erittäin todennäköisenä, että OpenAI tai vastaava toimija julkaisee lähitulevaisuudessa ColPalin kaltaisen upotusmallin, jolloin haun tarkkuudet saadaan nostettua avain uudelle tasolle. Tämä tosin kääntäisi päälaelleen kaikki nykyiset järjestelmät, jotka riippuvat tekstiupotusten päälle rakennetuista palastelu- ja hakumenetelmistä.
Ilman hyvää tekoälyarkkitehtuuria jäät kehityksessä jälkeen
Kielimalleja, hakumenetelmiä ja muita innovaatioita julkaistaan AI-maailmassa kiihtyvään tahtiin. Itse innovaatioita tärkeämmäksi tekijäksi nousee kyky hyödyntää niitä nopeaan tahtiin, jolloin saavutetaan merkittävää kilpailuetua hitaampiin toimijoihin nähden.
Tämän vuoksi ohjelmiston tekoälyarkkitehtuuri, mukaan lukien haku, täytyy rakentaa joustavaksi ja skaalautuvaksi, jotta se voi mukautua nopeasti uusimpiin teknologisiin innovaatioihin. Kehitysvauhdin kiihtyessä on tärkeää, että järjestelmän ytimenä oleva arkkitehtuuri ei ole sidottu yhteen ratkaisuun, vaan sen on kyettävä tukemaan monipuolisia hakumenetelmiä – oli kyseessä sitten perinteinen tekstipohjainen haku, multimodaalinen kuvahaku tai jopa täysin uusien hakumallien käyttö.
ColPali on vain esimakua tulevasta. Tulevaisuuden RAG-ratkaisut tulevat yhdistämään useita eri datalähteitä ja hakutekniikoita, ja vain ketterä ja muokattavissa oleva arkkitehtuuri mahdollistaa näiden saumattoman integroinnin.
Tämän ongelman ratkaisemiseksi tarjoamme muun muassa seuraavia palveluja:
Tekoälyarkkitehtuurin nykytilan arviointi
Sparraamme teknistä johtajaanne sekä tekijöitä AI:n saloihin - aina kooditasolle saakka
Tarkastelemme esimerkiksi hakumenetelmiä, skaalatuvuutta, arkkitehtuurin joustavuutta, turvallisuutta ja onko (Gen)AI:ta yleisesti käytetty parhaiden käytäntöjen mukaan
Teemme parannusehdotuksia, sekä listaamme konkreettisesti seuraavia vaiheita kehitykselle
AI-ominaisuuksien tai AI-alustanne toteutus osana omaa tiimiänne
Dedikoidut sovelletun tekoälyn insinöörit pitävät huolen siitä, että AI-projektit eivät jää muun kehityksen varjoon
Tekoälytuotteen kehitys ulkoistettuna tuotekehitysyksikkönä
Toimitamme tekoälypohjaisen kokonaisratkaisun alusta loppuun saakka
Autamme asiakkaitamme saavuttamaan merkittävää kilpailuetua nopeuttamalla AIn käyttöönottoa ja varmistamalla sen saumattoman integraation. Jos olet kiinnostunut kuulemaan lisää, ota yhteyttä ja keskustellaan, kuinka voimme auttaa yritystäsi pysymään AI-kehityksen kärjessä.