Mis on vektorandmebaas?

Mis on vektorandmebaas

Vektorandmebaas hoiab andmeid arvujadadena ja otsib nende hulgast kõige lähemaid. Tavaline andmebaas vastab küsimusele „leia rida, kus väli võrdub selle väärtusega“. Vektorandmebaas vastab küsimusele „leia read, mille tähendus on sellele kõige sarnasem“.

Sarnasus tekib embeddimismudeli abil: tekstist tehakse sadu või tuhandeid numbreid pikk vektor, ja sarnase tähendusega tekstid paigutuvad ruumis lähestikku. Otsing leiab lähimad naabrid, kasutades mõõdikut, näiteks koosinuskaugust.

Kuidas see töötab

1. Tükeldamine

   Dokumendid lõigatakse lõikudeks, tavaliselt paarist lausest poole leheküljeni. Liiga pikk lõik toob vastusesse palju müra, liiga lühike kaotab konteksti.

2. Vektoriseerimine

   Iga lõik saab vektori ja vektor salvestatakse koos viitega algallikale, näiteks faili nimele ja leheküljele.

3. Otsing

   Kasutaja küsimus vektoriseeritakse sama mudeliga ja andmebaasist otsitakse lähimad lõigud. Kiirendamiseks kasutatakse indeksit; pgvector toetab HNSW- ja IVFFlat-indeksit.

4. Vastus

   Leitud lõigud lähevad keelemudeli konteksti, mis koostab vastuse. Ilma selle sammuta on tegu otsinguga, mitte vastusega.

Sama ahel on RAG ehk otsinguga täiendatud genereerimise sisu, ja vastuse kvaliteet sõltub sellest, kui hea on materjal, mitte sellest, kui suur on keelemudel. Pinecone'i dokumentatsioon kirjeldab sama arhitektuuri teenusena, mille infrastruktuuri eest hoolitseb pakkuja, pgvector sama asja PostgreSQL-i laiendusena, mis on paljude Eesti projektide jaoks mõistlikum algus, sest andmebaas on juba olemas.

Millal seda vaja on ja millal mitte

Vaja on siis, kui materjali on rohkem, kui konteksti mahub, ja vastused peavad tulema konkreetsetest dokumentidest. Tüüpiline maht: üle saja lehekülje teenuse kirjeldusi, juhendeid või lepinguid.

Ei ole vaja, kui materjal mahub korraga konteksti, kui otsitakse täpseid välju (registrikood, arve number) või kui andmed on tabelis ja küsimus on arvutus. Neis olukordades on tavaline SQL-päring kiirem, odavam ja täpsem.

Näide Eesti ettevõttest

Ehitusmaterjalide hulgimüüjal on 300 tootelehte, paigaldusjuhendid ja hinnakiri. Müügiesindaja vastab päevas korduvatele küsimustele konkreetsete toodete sobivuse kohta.

Pärast dokumentide tükeldamist ja vektoriseerimist leiab süsteem küsimusele kolm kõige sarnasemat lõiku, näiteks ühe tehnilise andmelehe ja kaks paigaldusjuhise osa. Müügiesindaja näeb nii vastust kui allikat ja saab enne kliendile saatmist kontrollida. See on ka põhjus, miks allikas tuleb vektoriga koos hoida, mitte ainult tekst.

Kogu ahela ülesehitust ja teadmistebaasi korrastamist kirjeldab artikkel teadmistebaas chatbotile.

Töömaht

Minu hinnang: kui andmebaas on olemas, on esimene versioon päeva kuni kolme töö: tükeldamine, vektoriseerimine ja otsingu liides. Suurem osa ajast kulub tükeldamise häälestamisele ja testküsimustele, sest just need näitavad, kas otsing leiab õige lõigu. Mõõdik on lihtne: mitmel protsendil testküsimustest on õige lõik kolme esimese hulgas.

Kolm asja tasub enne alustamist otsustada, sest hiljem maksavad need ümbertegemist. Esiteks tükeldamise suurus koos kerge kattumisega, et vastus ei jääks kahe lõigu piirile. Teiseks see, millist teksti üldse vektoriseeritakse: tabelid ja hinnakirjad otsivad halvemini kui jutustav tekst, mistõttu osa andmeid jääb paremaks tavaliseks SQL-päringuks. Kolmandaks uuendamise kord: kui hinnakiri muutub, peab vana vektor kaduma, muidu vastab süsteem kahe eri hinnaga ja mõlemal on allikas.

Kolmas punkt on see, mille tõttu projektid hiljem katki lähevad. Vektorandmebaas ei ole tõeallikas, vaid otsingukiht. Kui dokumentide uuendamine on käsitsi ja keegi ei vastuta, hakkab süsteem vastama eilsete andmetega ja teeb seda enesekindlalt. Kui otsustad, kas sellist otsingut üldse vaja on, aitab AI konsultatsioon.