RAG-otsing on üks praktilisemaid viise, kuidas ettevõte saab tehisintellekti kohe tööle panna. Erinevalt tavalisest märksõnaotsingust mõistab RAG-otsing teksti tähendust ja see muudab otsingu käiku täielikult.
Selles artiklis selgitan, mis on RAG, millal see on sobiv lahendus ja mida me ise õppisime, kui ehitasime RAG-otsingu oma CRM-süsteemi piletite jaoks.
Mis on RAG ja miks see oluline on?
RAG (Retrieval-Augmented Generation) on lähenemine, kus tehisintellekt otsib enne vastamist üles asjakohased dokumendid teie ettevõtte andmetest ja kasutab neid vastuse koostamiseks. Lihtsamalt öeldes: RAG ühendab olemasolevad andmed AI võimekusega.
Tavaline otsing leiab ainult täpseid sõnu. Kui klient kirjutas pileti “printer ei tööta”, aga kasutaja otsib “printimise viga”, siis tavaline otsing seda ei leia. RAG-otsing leiab, sest ta mõistab, et need kaks fraasi räägivad samast asjast.
See on oluline erinevus, eriti ettevõtetes, kus ajaloolisi pileteid/kliendipöördumisi, dokumente ja märkmeid on tuhandeid. Infot on küll olemas, aga ilma semantilise otsinguta jääb see sageli peidetud andmebaasi sügavustesse.
Kuidas RAG praktikas töötab?
RAG-otsingu tööpõhimõte koosneb kolmest sammust:
Esimene samm on indekseerimine. Ettevõtte dokumendid, kas tugipiletid, lepingud, juhendid või e-kirjad töödeldakse tehisintellekti mudeliga, mis muudab iga teksti matemaatiliseks vektoriks. Need vektorid salvestatakse vektorandmebaasi. See on ühekordne tegevus, mida hiljem ainult täiendatakse.
Teine samm on otsing. Kui kasutaja sisestab päringu, muudetakse see vektoriks ja otsitakse vektorandmebaasist kõige sarnasemad dokumendid. Sarnasust mõõdetakse matemaatiliselt mitte sõnade kattumise, vaid tähenduse kattumise alusel.
Kolmas samm on vastuse genereerimine. Leitud dokumendid edastatakse keelemudelile, mis koostab nende põhjal vastuse. Nii saab AI anda kontekstipõhiseid vastuseid, mis tuginevad teie ettevõtte tegelikele andmetele mitte üldisele internetiteabele.
Meie enda praktiline kogemus ja mida sellest õppisime
Meie praktiline kogemus pärineb CRM-portaalist, kuhu ehitasime RAG-otsingu enam, kui 4000 tugipiletist koosneva baasi vastuste otsimiseks. Eesmärk oli lihtne: kui klienditoe töötaja saab uue pöördumise, siis peaks ta leidma varasemad sarnased juhtumid ning nende lahendused sekunditega.
Keel on kõige suurem väljakutse
Esimene ja kõige olulisem õppetund: eestikeelne sisu nõuab õiget mudelit. Me alustasime mitmekeelse mudeliga, mis töötas pealtnäha hästi. Inglisekeelsed terminid nagu “Outlook” ja “VPN” leidsid häid tulemusi, aga eestikeelsed päringud andsid sageli kehva kvaliteediga vastuseid. Probleem selgus alles siis, kui uurisime asja sügavamalt. Tehnilistel põhjustel oli süsteem vaikimisi üle läinud inglisekeelsele varumudelile. Otsing “töötas”, aga eestikeelsete päringute tulemused olid sisuliselt juhuslikud.
See on näide sellest, miks AI juurutamisel on testimine ja monitoorimine sama olulised kui arendamine ise. Süsteem, mis pealtnäha töötab ei pruugi tegelikult töötada nii hästi, kui arvad.
Mudeli valik mõjutab kõike
Pärast probleemi tuvastamist vahetasime embedding mudeli tugevama variandi vastu, mis on spetsiaalselt treenitud mitmekeelseks otsinguks. Tulemuste kvaliteet paranes märgatavalt. Nüüd leiab süsteem “printeri probleem” ka siis, kui piletis on kirjas “printer ei tööta” või “printimise viga”.
Hübriidlähenemine annab parima tulemuse
Kasutamisel sai kiiresti selgeks, et puhtalt semantiline otsing ei kata kõiki vajadusi. Mõnikord teab kasutaja täpselt pileti numbrit ja tahab seda otse leida. Mõnikord otsib ta aga ähmaselt “midagi sellist, mis oli seotud VPN-iga”.
Meie lahendus on hübriidotsing, mis tuvastab automaatselt, kas kasutaja sisestab konkreetse pileti numbri (täpne otsing) või vaba tekstiga päringu (semantiline otsing). See kombinatsioon katab üle 95% otsingujuhtumitest.
Jõudlus nõuab tähelepanu
Esimene otsing pärast süsteemi käivitamist võtab aega, sest mudel tuleb mällu laadida. Meie puhul oli see esialgu ligi 30 sekundit, hiljem mudeli vahetusega veidi rohkem. Kõik järgnevad otsingud töötavad aga alla sekundi.
See tähendab, et RAG-lahendust ei saa lihtsalt “sisse lülitada”, vaid tuleb mõelda ka mälumahtudele, mudeli laadimisstrateegiale ja kasutajakogemusele esimesel otsingul. Need on tehnilised detailid, mis mõjutavad otseselt seda, kas kasutajad hakkavad süsteemi kasutama või mitte.
Millal on RAG-otsing õige lahendus?
| RAG-otsing on hea valik, kui | RAG ei ole parim valik, kui |
| Sinu ettevõttel on palju tekstipõhiseid andmeid | Andmeid on vähe |
| Kasutajad ei tea alati õigeid märksõnu | Andmed muutuvad väga kiiresti ja vajavad reaalajas sünkroonimist |
| Info/ baas/ dokumendid on juba olemas, aga neid ei leita üles. | Ettevõtte andmed on laiali kümnes erinevas süsteemis ja formaadis |
RAG ja olemasolevad ärisüsteemid
Üks oluline eelis RAG-otsingul on see, et see töötab olemasolevate süsteemide peal. Pole vajadust CRM-i, ERP-i ega tugisüsteeme välja vahetada. RAG-moodul ühendub olemasolevate andmetega, indekseerib need ja pakub uut otsingukihti lisaks.
Meie lahenduses töötab RAG-otsing koos Infor CRM-iga, millest loeb piletite andmeid, ning Asana projektijuhtimissüsteemiga. Kasutaja ei pea teadma, millisest allikast andmed tulevad, tema sisestab päringu ja saab tulemused.
Seega parim AI-lahendus on see, mis ühendub sinu olemasolevate süsteemidega, mitte see, mis nõuab kõige väljavahetamist.
Andmed jäävad sinu serverisse
Üks levinumaid muresid AI juurutamisel on andmete turvalisus. Kas ettevõtte andmeid hoitakse nüüd pilves, ChatGPT-s või mõnes teises välises teenuses? RAG-otsingu puhul ei ole see nii. Meie lahenduses jooksevad nii embedding mudel kui ka vektorandmebaas täielikult ettevõtte enda serveris. Kui kasutaja teeb otsingu, töödeldakse päring kohapeal. Ükski tugipilet, kliendinimi ega lepingu sisu ei liigu välisesse teenusesse. See on oluline erinevus võrreldes lahendusega, kus andmed saadetakse välise AI teenuse API-sse töötlemiseks.
Praktikas tähendab see, et RAG-otsingu saab üles ehitada nii, et:
1. Andmed ei lahku ettevõtte serverist.
2. GDPR-i ja andmekaitse nõuded on kaetud juba arhitektuuri tasandil.
3. IT-osakond ja juhtkond saavad kindlad olla, et tundlik info jääb kontrollitud keskkonda.
Samas tasub teada, et AI-lahendus ei pea olema “kõik või mitte midagi”. Näiteks saab otsingu osa hoida täielikult lokaalsena, aga vastuste kokkuvõtmiseks kasutada välist keelemudelit. Sellisel juhul liigub välisesse teenusesse ainult konkreetne päring, mitte kogu andmebaas. Iga ettevõte saab ise otsustada, kus see piir jookseb, vastavalt oma andmete tundlikkusele ja regulatiivsetele nõuetele. Selline paindlikkus on üks RAG-arhitektuuri tugevusi.
Mida RAG-otsingu juurutamisel silmas pidada:
Kui teie ettevõttes on väärtuslikku infot, mida keegi ei leia üles, siis RAG-otsing võib olla õige lahendus. Parim viis alustada on AI auditist, kus kaardistame teie ettevõtte andmed ja süsteemid ning hindame, kas ja kus RAG-otsing (või mõni muu AI-lahendus) annaks kiireima tulemuse. Huvi korral broneeri tasuta AI-valmiduse konsultatsioon.
Loe lähemalt AI audit ettevõttele — mida see tähendab ja kuidas alustada?