RAG na lastnih dokumentih: kaj v praksi pomeni in kje odpove

Kaj RAG pomeni na lastnih dokumentih#

RAG je okrajšava za retrieval-augmented generation. Gre za pristop, pri katerem AI model pred oblikovanjem odgovora najprej poišče relevantne odlomke v vaši dokumentaciji, šele nato iz najdenega gradiva sestavi odgovor. Namesto da bi se model zanašal izključno na splošno znanje, pridobljeno med učenjem, odgovor opre na konkretne vire: pogodbe, navodila, interne postopke, poročila, tehnično dokumentacijo. Razlika je pomembna, ker določa, kaj sistem sploh lahko in česa ne more. RAG ne pomeni, da AI 'razume' vašo dokumentacijo v pomenu, kot to razumemo pri človeku - pomeni, da zna poiskati ustrezen del besedila in ga uporabiti kot podlago za odgovor.

V praksi to pomeni dve ločeni fazi. Prva je iskanje: sistem dokumente razčleni na manjše dele, jih indeksira in ob vprašanju poišče tiste, ki so vsebinsko najbližje. Druga faza je generiranje: AI model na podlagi najdenih delov sestavi berljiv odgovor v naravnem jeziku. Kakovost končnega odgovora je odvisna od obeh faz - še tako zmogljiv jezikovni model ne bo dal pravilnega odgovora, če mu je iskalni del predložil napačne ali nepopolne odlomke. Zato je RAG vedno sistem, ne le model, in ga je treba tako tudi načrtovati.

Za podjetja je zanimivost RAG v tem, da omogoča uporabo umetne inteligence nad podatki, ki jih splošni javni modeli ne poznajo - interno dokumentacijo, pogodbe, tehnične specifikacije, pretekle projekte. Namesto da bi zaposleni ročno brskali po mapah in sistemih, lahko vprašanje postavijo v naravnem jeziku in dobijo odgovor, oprt na dejanske vire. To je razlog, da se RAG pogosto pojavlja kot del širših projektov uporabe umetne inteligence nad internimi podatki, dokumentacijo in poslovnimi procesi, kakršen je pri nas projekt Kwizmo.

Kje se RAG v praksi uporablja#

RAG se najpogosteje uveljavi tam, kjer obstaja velika količina besedilnih virov, ki jih je treba hitro preiskati. To so lahko interna navodila in postopki, pogodbena dokumentacija, tehnične specifikacije, pretekla poročila ali baza vprašanj in odgovorov za podporo strankam. Skupna točka je, da odgovor ni enostaven izračun ali poizvedba v strukturirani bazi, temveč zahteva razumevanje besedila in povezovanje več virov. Prav to razumevanje nestrukturiranega gradiva je razlog, da RAG ni le iskalnik po ključnih besedah, temveč sistem, ki zna povzeti in pojasniti vsebino v kontekstu vprašanja.

Pri nas je tovrsten pristop del projekta Kwizmo, kjer razvijamo AI programsko rešitev za uporabo umetne inteligence nad internimi podatki, dokumentacijo in poslovnimi procesi naročnika. Projekt vključuje AI agente, RAG, obdelavo dokumentov, integracije in avtomatizacijo, torej ne gre za enkraten iskalnik, temveč za sistem, ki se povezuje z več viri podatkov in procesi hkrati. Tak obseg je značilen za enterprise AI projekte: RAG je le en gradnik med več, ki morajo delovati usklajeno.

Tipični primeri uporabe RAG nad lastnimi dokumenti v praksi vključujejo naslednje.

Skupno vsem tem primerom je, da RAG ne nadomesti obstoječih sistemov, temveč doda plast, ki zna po njih iskati in odgovore razložiti v naravnem jeziku. Zato RAG praviloma ni samostojen projekt, temveč del širše digitalizacije ali avtomatizacije poslovnih procesov, kjer se poveže z obstoječimi viri podatkov prek API-jev. Kje in kako se RAG najbolje obnese, je odvisno od tega, kako urejeni in dostopni so viri, iz katerih naj sistem črpa - to je tema naslednjega razdelka.

• iskanje po interni dokumentaciji in navodilih za zaposlene
• podpora pri odgovarjanju na vprašanja strank na podlagi tehnične dokumentacije
• pregled in povzemanje pogodb ter drugih pravnih dokumentov
• ekstrakcija podatkov iz obsežnih poročil in zapisnikov
• povezovanje odgovorov z več internimi viri hkrati

Kaj je treba pripraviti, preden RAG sploh deluje#

RAG ni sistem, ki ga je mogoče samo 'priklopiti' na mapo z dokumenti in pričakovati zanesljive odgovore. Preden sistem sploh začne delovati smiselno, je treba določiti, kateri dokumenti so vir resnice, kako so strukturirani, kako pogosto se spreminjajo in kdo ima dostop do njih. Če so viri neurejeni, protislovni ali zastareli, bo enako neurejen in nezanesljiv tudi odgovor sistema. Priprava podatkovne osnove zato pogosto zahteva več časa kot sama postavitev iskalnega in generativnega dela.

Pomembno je tudi vprašanje formata. Dokumenti v obliki skeniranih slik, zapletenih preglednic ali dokumentov z veliko tabelami zahtevajo dodatno obdelavo, preden jih je sploh mogoče smiselno razčleniti in indeksirati. Prav zato del enterprise AI projektov, kot je Kwizmo, vključuje tudi obdelavo dokumentov kot ločen gradnik - ne le iskanje in generiranje odgovorov, temveč pripravo gradiva v obliko, ki jo sistem lahko dejansko uporabi.

Pred uvedbo RAG sistema je smiselno razjasniti naslednja vprašanja.

Ta priprava ni enkraten korak, temveč del tekočega vzdrževanja sistema. Dokumentacija se spreminja, postopki se posodabljajo, novi viri se dodajajo. Če RAG sistem ni povezan s procesom posodabljanja virov, začne sčasoma odgovarjati na podlagi zastarelih podatkov, kar je eden najpogostejših razlogov, da tak sistem v praksi odpove - o tem podrobneje v naslednjem razdelku.

• kateri dokumenti so uradni vir resnice in kateri so zastareli ali podvojeni
• kdo v organizaciji sme videti katero vsebino
• kako pogosto se dokumenti spreminjajo in kdo skrbi za posodabljanje
• v kakšni obliki so dokumenti (besedilo, skenirane slike, preglednice, PDF)
• ali obstajajo protislovni viri za isto vprašanje
• kje bodo podatki dejansko shranjeni in obdelani

Kje RAG v praksi odpove#

Tudi dobro zastavljen RAG sistem ni nezmotljiv in ima jasne meje delovanja. Najpogostejša težava je, da sistem odgovori, tudi kadar v dokumentih dejansko ni odgovora na zastavljeno vprašanje - namesto da bi priznal, da informacije ne najde, lahko generira verjetno zveneč, a napačen odgovor. Ta pojav se pogosto imenuje halucinacija in je posledica tega, da generativni del modela vedno poskuša sestaviti smiseln stavek, ne glede na to, ali je iskalni del dejansko našel ustrezno podlago.

Druga pogosta težava so nasprotujoči si viri. Če v dokumentaciji obstajata dve različici istega postopka - stara in nova, ali dve interni navodili, ki si nasprotujeta - sistem nima samodejnega načina, da bi vedel, katera je veljavna. Brez jasno določenega vira resnice bo iskalni del včasih izbral zastarel odlomek, generativni del pa bo iz njega sestavil odgovor, ki zveni prepričljivo, a je vsebinsko napačen.

Med tipičnimi razlogi za odpoved RAG sistema v praksi so naslednji.

Zaradi teh omejitev je treba RAG sistem obravnavati kot programsko rešitev z lastnim življenjskim ciklom, ne kot enkraten vklop funkcije. Potrebuje testiranje, spremljanje kakovosti odgovorov in redno vzdrževanje virov, sicer se zanesljivost sistema sčasoma slabša, tudi če je bila ob uvedbi ustrezna. To je razlog, da testiranje in QA nista dodatek, temveč sestavni del vsakega RAG projekta.

• zastareli ali podvojeni dokumenti, ki niso bili umaknjeni iz vira
• nestrukturirano ali slabo pripravljeno gradivo (skenirane slike, zapletene tabele)
• vprašanja, na katera v dokumentih preprosto ni odgovora
• mešanje virov različnih ravni zaupnosti ali dostopnosti
• prevelika ali premajhna razdrobljenost dokumentov pri indeksiranju
• pomanjkanje testiranja na realnih vprašanjih uporabnikov pred uvedbo

Vprašanje dostopa in varnosti podatkov#

Ker RAG sistem po definiciji išče po internih dokumentih, je vprašanje, kdo do katere vsebine sploh sme dostopati, eno prvih, ki jih je treba rešiti. Če sistem uporabnikom omogoča iskanje po celotni dokumentaciji brez razlikovanja pravic dostopa, lahko pride do tega, da zaposleni prek AI odgovora vidi vsebino, do katere sicer nima dostopa. To ni tehnična podrobnost, temveč vprašanje, ki mora biti rešeno, preden sistem sploh pride v produkcijo.

Prav zato ločujemo razvojno, testno in produkcijsko okolje ter v testnem okolju ne uporabljamo pravih osebnih podatkov. Na ta način lahko sistem testiramo in razvijamo, ne da bi izpostavljali občutljivo vsebino zunaj nadzorovanega okolja. Pri projektih v javnem sektorju ali reguliranih panogah je nadzor nad dostopom in sledljivostjo dodatno pomemben, saj morajo biti odgovori sistema skladni z zahtevami glede varovanja podatkov.

Znotraj Epixa in naše specialistične partnerske mreže imamo dostop do kadra s področja upravljanja identitet in dostopov (IAM), utrjevanja infrastrukture ter varnostne arhitekture, kar je pri projektih, ki vključujejo dostop do občutljive interne dokumentacije, pogosto ključnega pomena. Standardi, kot sta ISO 27001 in ISO 27701, so del delivery strukture te mreže in se upoštevajo pri projektih, kjer je to relevantno.

Testiranje in merjenje kakovosti odgovorov#

Ker RAG sistem generira odgovore v naravnem jeziku, ni dovolj preveriti, ali koda deluje brez napak - preveriti je treba tudi, ali so odgovori vsebinsko pravilni. To zahteva drugačen pristop k testiranju kot pri klasični programski opremi: potrebni so testni scenariji z realnimi vprašanji, na katera je vnaprej znan pravilen odgovor, ob katerih se preverja, ali sistem odgovori pravilno, delno pravilno ali napačno.

V praksi to pomeni kombinacijo ročnega in avtomatiziranega testiranja, testiranje API-jev in regresijsko testiranje, ki preverja, ali sprememba v dokumentaciji ali v modelu ni poslabšala kakovosti prejšnjih odgovorov. Testiranje vključimo v CI/CD proces, tako da se preverjanje kakovosti izvede ob vsaki pomembnejši spremembi, ne le enkrat ob uvedbi. Pred prevzemom sistema izvedemo tudi prevzemno testiranje po vnaprej dogovorjenih merilih.

Pri zahtevnejših projektih je smiselno vključiti neodvisen QA, ločen od razvojne ekipe, ki sistem preverja s stališča uporabnika, ne razvijalca. To je še posebej pomembno pri RAG sistemih, kjer je 'pravilen' odgovor lahko subjektiven - enak vsebinski odgovor je lahko zapisan na več različnih, a vseeno ustreznih načinov, kar mora testni proces upoštevati. Zato testni scenariji poleg vsebinske pravilnosti preverjajo tudi, ali je odgovor razumljiv, ali navaja vir, iz katerega izhaja, in ali sistem jasno pove, kadar odgovora v dokumentih ne najde.

Povezovanje RAG sistema z obstoječimi sistemi#

RAG sistem redko deluje samostojno. V praksi mora dostopati do dokumentov, ki so shranjeni v več različnih sistemih hkrati - upravljanju dokumentov, poslovnih aplikacijah, portalih ali skupnih mapah. Zato je povezovanje prek API-jev sestavni del vsakega resnega RAG projekta, ne dodatek. Brez ustrezne integracije sistem vidi le del dokumentacije, kar neposredno omejuje kakovost in popolnost odgovorov, ki jih lahko ponudi.

Gradimo in povezujemo ERP, CRM, DMS in ECM sisteme ter jih integriramo prek API-jev, pri čemer imen posameznih proizvajalcev ne navajamo, dokler integracija ni potrjena na konkretnem projektu. Vsaka integracija zahteva razumevanje, kako je sistem naročnika strukturiran, kakšne so njegove omejitve in kako pogosto se podatki v njem spreminjajo, saj to neposredno vpliva na to, kako sveže je gradivo, ki ga RAG sistem uporablja.

Pri projektih, kjer prevzamemo obstoječ ali nedokončan sistem, najprej pregledamo izvorno kodo, arhitekturo, infrastrukturo in podatke, šele nato predlagamo, kako vanj vgraditi iskanje in generiranje odgovorov nad dokumenti. To velja tudi za RAG: preden dodamo novo plast, moramo razumeti, na čem gradimo, sicer tvegamo, da nova funkcionalnost ne bo skladna z obstoječo arhitekturo ali podatkovnim modelom.

Vzdrževanje in nadaljnji razvoj po uvedbi#

RAG sistem po uvedbi ni dokončan projekt, temveč sistem, ki potrebuje tekoče vzdrževanje. Dokumenti se spreminjajo, novi viri se dodajajo, stari se umikajo, uporabniki pa sčasoma postavljajo vprašanja, ki jih ob zasnovi nismo predvideli. Po uvedbi lahko prevzamemo nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj sistema, obseg pa se določi glede na posamezen projekt.

Prijave napak in zahtev razvrščamo po SLA razredih. Izpad pomeni, da sistem ali ključni del ne deluje in ima obravnava najvišjo prednost, dogovorjeno v pogodbi o podpori. Motnja pomeni, da sistem deluje, a posamezna funkcija ne, kar se obravnava po prednosti, prav tako dogovorjeni v pogodbi. Manjša napaka brez vpliva na poslovanje se uvrsti v naslednjo objavo, zahteva za spremembo ali nadgradnjo pa se oceni po obsegu in uskladi s terminom.

Univerzalnih odzivnih časov v urah ne objavljamo, saj so ti odvisni od kritičnosti posameznega sistema in dogovora z naročnikom. Pri sistemih, ki so vezani na dnevno poslovanje, so lahko pričakovanja glede odzivnosti bistveno drugačna kot pri internem orodju, ki ga uporablja manjša skupina zaposlenih - zato se raven podpore vedno določi po projektu, ne pavšalno.

Kako pristopimo k RAG projektu#

Projekt lahko prevzamemo v celoti, od analize dokumentacije do uvedbe in podpore, ali kot posamezen projektni sklop, na primer samo obdelavo dokumentov ali samo integracijo z obstoječim sistemom. Pri večjih projektih določimo projektnega vodjo, odgovornosti posameznih ekip, roke in način komunikacije ter poročanja, tako da naročnik ves čas ve, v kateri fazi je projekt in kaj sledi.

Kadar naročnik že ima delno razvit sistem ali obstoječo dokumentacijo, ki jo želi povezati z AI iskanjem, najprej pregledamo izvorno kodo, arhitekturo, infrastrukturo in podatke, šele nato predlagamo nadaljnje korake. Izvorna koda in podatki ostanejo last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku projekta ali posameznega sklopa. Tak pristop velja tudi, kadar RAG dodajamo v obstoječ sistem, ki ga je razvil kdo drug - pregled obstoječega stanja je vedno prvi korak, ne domneva o tem, kaj sistem že zna.

Znotraj naše delivery mreže lahko za RAG projekt sestavimo ekipo z naslednjimi profili.

Spremembe, ki jih izvedemo po uvedbi, gredo skozi pregled in testiranje pred objavo v produkcijo, enako kot pri prvotnem razvoju. To velja tudi za manjše popravke virov ali prilagoditve odgovorov - noben poseg ne gre mimo testnega okolja neposredno v sistem, ki ga naročnik dejansko uporablja. Tak red je še posebej pomemben pri RAG sistemih, kjer lahko že majhna sprememba v naboru dokumentov vpliva na to, kako sistem odgovarja na vprašanja, ki so bila prej pravilno obravnavana.

• solution architecti za zasnovo celotnega sistema
• AI/ML strokovnjaki za iskalni in generativni del
• backend razvijalci za integracije prek API-jev
• DevOps in cloud inženirji za infrastrukturo in razpoložljivost
• QA in test automation inženirji za preverjanje kakovosti odgovorov
• projektni vodje za usklajevanje rokov in komunikacije

Kaj določa obseg in ceno projekta#

Cen in cenovnih razponov na tem mestu ne navajamo, saj je vsak RAG projekt drugačen glede na količino in stanje dokumentacije, zahtevane integracije in raven varnosti. Namesto pavšalne številke je smiselnejše razumeti, kateri dejavniki obseg dela dejansko določajo, saj to naročniku pomaga že v fazi priprave zahtev oceniti, kako obsežen bo projekt.

Na obseg in s tem na ceno RAG projekta vpliva predvsem naslednje.

Cena se določi po pregledu zahtev, obsega in tehnične zahtevnosti projekta. Pred tem praviloma predlagamo krajšo analizo, ki obseg razčleni na posamezne sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno. Tak pristop naročniku omogoča, da se odloči, ali projekt izvede v celoti naenkrat ali po fazah, glede na to, kateri sklopi prinesejo največjo vrednost najprej.

• obseg in stanje dokumentacije, ki jo je treba pripraviti in indeksirati
• število sistemov, s katerimi je treba RAG sistem povezati, in njihovi API-ji
• ali gre za nov sistem ali nadgradnjo obstoječega
• zahteve glede varnosti, pravic dostopa in revizijske sledi
• obseg AI dela: kje so podatki, kakšna natančnost je pričakovana, katere akcije sme sistem izvesti
• obseg testiranja in ali je potreben neodvisen QA
• raven podpore po uvedbi in dogovorjeni odzivni časi