Suuret kielimallit pystyvät käsittelemään kerralla vain rajallisen määrän tekstiä eli yhden konteksti-ikkunan verran. Tämä toimii pienissä tehtävissä, mutta ei enää silloin, kun tietämyskanta käsittää tuhansia sivuja. Vaikka konteksti-ikkuna olisi riittävä, suorituskyky voi silti heikentyä ”neula heinäsuovassa” -ongelman vuoksi.
RAG (”hakutehostettu generointi”) on yleistynyt toimintamalli, jossa ylläpidetään tietämyskantaa (asiakirjoja, wikejä, käytäntöjä, litterointeja jne.), etsitään käyttäjän kyselyyn semanttisesti osuvimmat katkelmat upotusten avulla ja syötetään ne kysymyksen mukana suurelle kielimallille. Tämä rajaa mallin kontekstia ja voi oikein toteutettuna parantaa vastausten laatua ja vähentää hallusinaatioita.
pgai on avoimen lähdekoodin Postgres-laajennus oheistyökaluineen. Sen avulla voi rakentaa ”tekoälyhakuun” perustuvia työnkulkuja luotettavan avoimen lähdekoodin PostgreSQL-tietokannan päälle.
Perusajatuksena on siirtää suurempi osa tavanomaisesta RAG-putkesta tietokantakerrokseen (syöttö → pilkkominen → upotusten luonti → upotusten pitäminen ajan tasalla) sen sijaan, että tietokantaa käytettäisiin upotusten ”pelkkänä tallennustilana”.
Ensivaikutelman perusteella ratkaisu on lupaava, mutta se ei sovellu edes hieman monimutkaisempiin RAG-putkiin, etenkään jos pilkkomistavat ovat mutkikkaita. Aiomme silti seurata hanketta tarkasti.
RAG voidaan toteuttaa monin tavoin. Eri lähestymistapoja käsitellään tarkemmin artikkelissa Käytännön esimerkkejä mukautetuista RAG-ratkaisuista. Laatuvaatimusten kasvaessa vaihtoehtoja on yllättävän paljon, mutta yleinen ”oletusratkaisu” näyttää yleensä tältä:
Kerää joukko asiakirjoja.
Pilko ne osiin. Tähän on monia menetelmiä, kuten pilkkominen kappaleiden tai semanttisten ryhmien mukaan.
Muunna kukin osa upotukseksi.
Tallenna upotukset vektoritietokantaan (Pinecone, Milvus jne.) tai pgvectorin avulla Postgres-tietokantaan.
Hae kyselyvaiheessa lähimmät osat `ja välitä ne suurelle kielimallille (tämänkin voi tehdä monella tavalla).
Monissa teknologiapinoissa vaiheet 1–3 suoritetaan tietokannan ulkopuolella sovelluskoodissa tai dataputkessa, ja tietokantaa käytetään lähinnä seuraaviin:
upotusten tallentaminen
upotusten hakeminen
pgai on Postgres-laajennus (avointa lähdekoodia, Timescalen kehittämä), joka pyrkii hämärtämään tätä rajaa.
Sen sijaan, että sovellus hallinnoisi upotuksia manuaalisesti, pgai tekee niistä tietokannan ominaisuuden:
Määrität, mitkä taulut tai asiakirjat muunnetaan upotuksiksi.
Määrität upotusmallin ja pilkkomisstrategian.
pgai huolehtii muusta, kuten upotusten päivittämisestä lähdetietojen muuttuessa.
Lupaus on houkutteleva:
Vähemmän ylläpidettävää, räätälöityä liimauskoodia.
Upotukset pitäisi olla helpompi pitää ajan tasalla lähdeasiakirjojen muuttuessa.
Postgres/pgai huolehtii uudelleenyrityksistä, nopeusrajoituksista, epäonnistuneista töistä ja muusta vastaavasta.
Huomautus lukijalle: pgai sisältää pgvectorin, joka on toinen erittäin suosittu Postgres-laajennus RAG-ratkaisuihin. pgvector lisää Postgres-tietokantaan vektorien tallennuksen ja samankaltaisuushaun. pgai puolestaan automatisoi sen pohjalta RAG-putken vaiheita, kuten pilkkomista, upotusten luontia ja niiden pitämistä ajan tasalla.
1) Käyttöönotto on vaivatonta.
Perustapaus on melko yksinkertainen:
Lataa Timescalen Docker-levykuvat (tietokanta ja työprosessi).
Anna upotuspalvelun tarjoajan API-avain.
Määritä vektorointitoiminto muutamalla SQL-komennolla: mitä muunnetaan upotuksiksi, miten sisältö pilkotaan ja mitä mallia käytetään.
Tämän jälkeen pgai suorittaa vektoroinnin erillisenä työprosessina ja luo upotukset asynkronisesti esimerkiksi viiden minuutin välein tai muulla halutulla aikataululla.
2) Koko putki on kätevää suorittaa tietokannan ”lähellä”.
pgai voi lukea sisältöä tauluista tai ladata asiakirjoja esimerkiksi S3:sta ja sitten jäsentää, pilkkoa ja muuntaa ne upotuksiksi. Se tukee myös erilaisia tekstiasiakirjamuotoja, kuten PDF:ää ja Markdownia.
1) Menetät paljon hallintamahdollisuuksia, vaikka RAG toisinaan edellyttää niitä.
Vastausten laadulla mitattuna tehokkaat RAG-järjestelmät vaativat usein räätälöityjä putkia, kuten:
mukautettuja pilkkomissääntöjä (otsikoiden, sivujen, puhujanvaihdosten jne. mukaan)
metatiedot huomioivaa pilkkomista (osioiden otsikoiden, aikaleimojen, tekijöiden ja asiakirjatyypin säilyttäminen)
eri upotusstrategioita eri asiakirjatyypeille
pgai tarjoaa edellä mainittuihin vähemmän joustavuutta.
Tällä hetkellä tarjolla on kaksi päästrategiaa: merkkipohjainen tekstin pilkkominen ja rekursiivinen merkkipohjainen tekstin pilkkominen. Lisäksi pilkkomisen voi jättää tekemättä. Tämä voi riittää joihinkin käyttötapauksiin, mutta monet tuotantokäytössä olevat RAG-järjestelmät vaativat enemmän mukauttamista.
Olisi hienoa, jos Timescale voisi lisätä joitakin kehittyneempiä pilkkomisstrategioita, joita on esimerkiksi Chonkien kaltaisissa kirjastoissa, ja tukea samalla Anthropicin kontekstuaalisen haun kaltaisia edistyneitä ratkaisuja.
2) Teksti edellä, ei multimodaalisesti.
Monet kiinnostavat RAG-ongelmat eivät enää koske pelkkää tekstiä:
kaavioita sisältävät PDF-tiedostot
näyttökuvat ja kuvat
äänitallenteet
videoleikkeet
Vaikka näistä lähteistä voisi ”poimia tekstin”, se ei vastaa aidosti multimodaalista upotusputkea.
Olisi erittäin kiinnostavaa, jos pgai tukisi tulevaisuudessa multimodaalisia malleja alusta loppuun: S3:een tallennettujen suurten kuvien, ääni- ja videotiedostojen lataamista, pilkkomista ja muuntamista upotuksiksi sekä luotettavaa synkronointia. Nykyisin se on kuitenkin tekstien upotustyönkulku.
3) Jos tarvitset vain upotuksia, et ehkä tarvitse pgai:ta.
Jos tietojen syöttöputkesi on jo mukautettu tai sen täytyy olla sellainen, tekstiosien muuntaminen upotuksiksi ei ole RAG:n vaikein vaihe. Tällöin pgai ratkaisee ongelman helpoimman osan.
Jos tietämyskantasi päivittyy harvoin, upotusten automaattisesta synkronoinnista saatava hyöty on myös vähäisempi.
Yksi erityisen hyvä pgai:n käyttötapa olisi teksti-SQL-käyttöliittymän ottaminen käyttöön tietokantojen päällä. Tämä onnistuu melko helposti pgai:n tarjoamalla semantic_catalog-moduulilla. Tee määritykset näin:
Bash
Anna sitten semanttisen luettelon käydä läpi tietohakemistosi komennolla pgai semantic-catalog create. Tämä luo tietovarastostasi kontekstin, joka näyttää suunnilleen tältä:
Plain Text
Tämä konteksti on nyt pgai:n käytettävissä monin tavoin:
Semanttisen haun kautta:
Tämä kysely palauttaa taulut, funktiot ja muut objektit, jotka saattavat liittyä luonnollisella kielellä tehtyyn kyselyysi:
Bash
Raakakontekstin hakeminen:
Tämä muodostaa luonnollisella kielellä tehtyyn kyselyysi liittyvän YAML-raakakontekstin:
Bash
SQL:n luominen:
Voit myös luoda suoraan kyselyysi vastaamiseen tarvittavan SQL-raakakoodin. Edellisen vaiheen konteksti lähetetään suurelle kielimallille, joka luo vastauksen:
Bash
Jos rakennat melko yksinkertaista RAG-järjestelmää, pgai:ta kannattaa kokeilla, jos haluat:
käyttää Postgresia ensisijaisena tietolähteenä,
minimoida liimauskoodin määrän,
pitää upotukset automaattisesti ajan tasalla,
ottaa teksti-SQL-ratkaisun nopeasti käyttöön tietokannoissasi,
kokeilla uusia RAG-työkaluja ja Postgres-laajennuksia.
pgai:n käyttöönottoa kannattaa todennäköisesti lykätä, jos RAG-putkesi tarvitsee jotakin seuraavista:
paljon mukautettua tietojen syöttö- tai pilkkomislogiikkaa
runsaasti eri asiakirjatyyppejä, joilla on erilaiset jäsentämisvaatimukset
multimodaalisia upotuksia
Vaikka pgvector on selvästi saanut vahvan käyttäjäkunnan, on vielä epäselvää, herättääkö pgai yhtä paljon kiinnostusta ja saako se siksi yhtä paljon tukea. Tosin se on ollut saatavilla vasta noin 18 kuukautta.
pgai on kiinnostava RAG-lähestymistapa, jossa tietokanta hoitaa aiempaa enemmän tavanomaisia ylläpitotöitä ja sovelluskoodi voi pysyä yksinkertaisempana.
Tällä hetkellä se on:
käyttökelpoinen ja aidosti miellyttävä yksinkertaisissa RAG-toteutuksissa
liian joustamaton räätälöityihin putkiin, etenkin multimodaalisiin
Ratkaisu on lupaava, ja sen kehitystä kannattaa ehdottomasti seurata.