RAG-otsing ja keelemudelite valik — mida me kolmest mudelist õppisime

Eelmises artiklis kirjutasime, kuidas RAG-otsing töötab ja miks see on ettevõttele kasulik. Jagame oma kogemust kolme embedding mudeli testimisest, miks eesti keel nõuab erilist tähelepanu ja kuidas vaikne viga võib otsingu sisuliselt kasututuks muuta.

Mis on RAG? RAG (Retrieval-Augmented Generation) on lähenemine, kus AI ei vasta ainult oma treeningmälu põhjal, vaid otsib enne vastamist üles asjakohased dokumendid teie ettevõtte andmetest. Mõtle sellele nagu kolleegile, kes enne vastamist vaatab alati arhiivist järele, mitte ei ürita peast meenutada.

See on meie enda läbiproovitud teekond, kus kolm erinevat mudelit andsid kolm väga erinevat tulemust.

RAG-otsingu südameks on embedding mudel, tehisintellekti komponent, mis muudab teksti matemaatiliseks vektoriks. Kui kaks teksti räägivad samast asjast, peaksid nende vektorid olema sarnased. Just see sarnasus on aluseks, mille järgi otsing leiab tulemusi.
Iga mudel ei mõista iga keelt ühtmoodi hästi. Mudel, mis on treenitud peamiselt inglisekeelsel tekstil ei pruugi aru saada, et “printeri probleem” ja “printer ei tööta” räägivad samast asjast. Eesti keel on maailma mastaabis väike keel ja AI mudelite treenimisel moodustab eestikeelne tekst marginaalse osa kogu treeningandmestikust.
See tähendab, et mudelivalik ei ole tehniline pisiasi, vaid on otsus, mis määrab, kas otsing tegelikult töötab või mitte.

Esimeseks valikuks oli üks populaarsemaid mitmekeelseid embedding mudeleid. See on kompaktne (384 dimensiooni), kiire ja toetab üle 50 keele, sealhulgas eesti keelt. Arenduskeskkonnas andis häid tulemusi.
Serverisse paigaldamisel ilmnes aga probleem. Mudel vajab PyTorch’i teeki. Serveris oli installitud PyTorch’i GPU-versioon (CUDA), aga serveris endas GPU-d polnud. Puuduvate NVIDIA teekide tõttu ei suutnud PyTorch käivituda ja süsteem lülitus märkamatult üle tagavaramudelile.
Mida me sellest õppisime? Arenduskeskkonnas testimisest ainult ei piisa. Tootmisserver on teine keskkond ja seal võivad sõltuvused käituda ootamatult. Eriti oluline on kontrollida, et just see mudel, mida plaanisid kasutada, tegelikult ka serveris töötab.

See mudel ei olnud meie valik, see oli süsteemi automaatne tagavara, mis aktiveerus, kui esmane mudel ei käivitunud. Siin peitubki meie kõige olulisem õppetund.
ONNX MiniLM-L6-V2 on poole väiksem mudel (6 kihti 12 asemel) ja ainult inglisekeelne. See tähendab, et eestikeelsed tekstid muudeti küll vektoriteks, aga need vektorid ei kandnud eestikeelset tähendust.

Praktikas töötasid inglisekeelsed terminid kenasti. Otsing “Outlook setup” leidis piletid, kus oli juttu Outlooki seadistamisest. Aga eestikeelsed päringud nagu näiteks “printeri probleem”, “kaugühenduse viga”, “arvete koostamine” jms andsid juhuslikke tulemusi. Mitte päris tühja vastust, vaid lihtsalt valesid viiteid. See muutis probleemi tuvastamise eriti keeruliseks.
Lahendus oli üllatavalt lihtne, vahetasime PyTorch’i GPU-versiooni CPU-versioonile.

Mida me sellest õppisime? Ohtlik ei ole see, kui AI ei tööta. Ohtlik on see, kui AI näib töötavat. Süsteem, mis jookseb kokku, saab kiiresti parandatud. Süsteem, mis töötab valesti ilma sellest märku andmata, võib nii jääda nädalateks. Seetõttu on oluline, et RAG-lahenduse monitoorimine kontrollib mitte ainult seda, kas otsing vastab, vaid ka seda, millist mudelit otsing tegelikult kasutab.

Pärast tagavaramudeli probleemi lahendamist töötas esmane mudel (MiniLM-L12-v2) korralikult, aga me ei jäänud sinna pidama. Testisime järgmist mudelit: multilingual-e5-base ja tulemused olid märgatavalt paremad.

Mis seda mudelit eristab? Kaks peamist erinevust:

Esiteks see on suurem mudel: 768 dimensiooni 384 asemel. Suurem vektorruum tähendab, et mudel suudab teksti tähendust peenema detailsusega tabada. Kaks sarnast, aga mitte identset mõistet saavad erinevad, kuid lähestikku paiknevad vektorid — mitte ühte ja sama umbkaudset positsiooni.
Teiseks kasutab E5 instruktsiooni-põhist lähenemist. Otsingupäringutel lisatakse “query:” prefiks, indekseeritud tekstidele “passage:” prefiks. See tähendab, et mudel mõistab, et otsija ja otsitav tekst on erineva rolliga ja arvestab seda sarnasuse arvutamisel. Tavamudel kohtleb mõlemat poolt ühtmoodi, mis võib anda kehvemaid tulemusi, kui päring ja dokument on väga erineva pikkuse või stiiliga.

Praktikas tähendas see, et eestikeelsed sünonüümid ja seotud mõisted hakkasid oluliselt paremini tööle. “Kaugühendus” leidis nüüd viiteteid, kus oli kirjas “VPN seadistamine” või “remote desktop ühendus”. “Arvete probleem” leidis “faktuuri veateate” ja “arve ei lähe välja”.

Eesti keele tugi on ebaühtlane. “Mitmekeelne” mudelite puhul ei tähenda, et iga keel on võrdselt hästi kaetud. Eesti keel on treeninguandmetes vähemusena esindatud ja see mõjutab tulemuste kvaliteeti. Mudelivalikul tasub testida just eestikeelsete päringutega, mitte ainult inglisekeelsetega.

Vaikne tagavaraloogika on ohtlik. Paljud raamistikud kasutavad automaatseid tagavaramehhanisme (fallback), mis aktiveeruvad siis, kui esmane komponent ei käivitu. See on kasulik ainult siis, kui tagavara annab samaväärset tulemust. Meie juhul andis tagavaramudel kvalitatiivselt hoopis teistsugust tulemust ja seda ilma igasuguse hoiatuseta. Monitoorimine peab katma mitte ainult “kas töötab”, vaid “kas töötab õige konfiguratsiooniga”.

Mudeli suurus ei ole ainus kriteerium. Väiksem mudel on kiirem ja odavam, aga kui tulemuste kvaliteet kannatab, siis pole kiirusest kasu. Meie puhul oli suurema mudeli lisandunud mälukulu (~250 MB) ebaoluline võrreldes sellega, kui palju paremaid tulemusi see andis. Jõudluse optimeerimine tasub jätta hetkeks, kui kvaliteet on tagatud.

Indekseerimine on pidev protsess. Esialgne ülesehitamine võtab aega (meie puhul ~40 minutit 3200 kliendipöördumise jaoks), aga igapäevane täiendamine on kiire. Mudeli vahetuse korral tuleb kogu indeks uuesti üles ehitada, sest uue mudeli vektorid ei ühildu vanaga. Sellega tuleb arvestada juba alguses, et mudeli vahetust peab saama teha ilma andmekaota.

RAG-otsingu kvaliteet sõltub suuresti sellest, milline embedding mudel teksti vektoriteks muudab. Meie kogemus kolme mudeliga näitas, et erinevus hea ja halva valiku vahel ei ole nüanss, vaid see on vahe töötava ja mittetöötava lahenduse vahel.
Eriti eesti keeles, kus mudelite tugi on ebaühtlane, tasub mudelivalikule pühendada rohkem aega, kui esialgu tundub vajalik. Kõige olulisem on kontrollida, et tootmisserveris jookseb see mudel, mille sa valisid. Mitte see, mille süsteem vaikselt asemele vahetab.

Kui mõtled, kas RAG-otsing sobiks teie ettevõtte andmete jaoks, siis võta meiega ühendust. Hindame, millised andmed sul on olemas, millises formaadis ja kas semantiline otsing annaks võrreldes praeguse lahendusega mõõdetavat parandust.