Mis on RAG-lahendus? Ettevõtte dokumentidel põhineva AI võimalused ja piirid

RAG leiab ettevõtte dokumentidest asjakohaseid lõike ja koostab allikatele viitavaid vastuseid, kuid see ei treeni mudelit ega taga tõde või ligipääsukontrolli.

Esmaspäeva hommikul küsib personalijuht siseassistendilt, kui kaua tuleb kandidaatide andmeid säilitada, ja saab veenva vastuse koos lingiga ettevõtte poliitikale; on ainult üks probleem: leitud versioon kaotas kehtivuse kaheksa kuud tagasi. Selline RAG-lahendus võis tehniliselt teha kõik, mida temalt paluti — leida semantiliselt sarnase lõigu, lisada selle mudeli konteksti ja kirjutada ladusa vastuse. See ei kontrollinud siiski, kas fail on viimane kinnitatud versioon, kui versiooni olek pole indeksis usaldusväärselt märgitud.

Mis on RAG-lahendus? RAG tähendab retrieval-augmented generation'it ehk välistoelist genereerimist, mille puhul lisatakse vastamise ajal mudelile välisest allikast leitud kontekst. See ei õpeta ettevõtte dokumente mudeli kaaludesse ega ole eraldi „tarkusekiht”, mis teab automaatselt, milline dokument on õige; pigem meenutab see raamatukogu, kus väga kiire raamatukoguhoidja toob andeka toimetaja lauale köite. Hoidja võib valida vale köite, ent toimetaja kirjutab ikkagi veenva lõigu; algne RAG-i uurimus eristabki mudeli parameetrilist mälu välisest mitteparameetrilisest allikast.

Praktiline kasu on suur, kui piirid ausalt välja öelda; süsteem võib leida hallatud dokumendikogust sobivad lõigud, koondada need küsimuse jaoks konteksti ja koostada kontrollitava allikaviitega mustandi. Vastutuse piir peab olema nähtav ka kasutajale: liides ei tohi jätta muljet, et allikaviide tähendab õiguslikku kinnitust, ning veast või ebaselgusest teatamine peab olema sama lihtne kui küsimuse esitamine. RAG ei paranda halba dokumentatsiooni, taga faktilist õigsust, rakenda ise ligipääsuõigusi ega asenda kindlate reeglitega töövoogu ja inimese kinnitust olukorras, kus viga tekitab õigusliku, rahalise, turbe- või inimõiguste riski. See piir määrab nii arhitektuuri kui ka piloodis mõõdetava.

Miks võib vana poliitika ilmuda kehtiva dokumendina?

Vana poliitika probleem ei alga keelemudelist, vaid dokumendihaldusest; jagatud kettal on „Isikuandmed_final.docx”, „Isikuandmed_final2.docx” ja kinnitatud PDF, kuid ühelgi failil pole ühtset jõustumiskuupäeva, olekut ega asendatud versiooni tunnust. Indeks näeb kolme sisult sarnast kandidaati ja semantiline otsing võib vana dokumendi ettepoole tõsta, sest selle sõnastus langeb küsimusega paremini kokku. Mudel ei tea organisatsiooni koosolekul tehtud otsust, kui seda andmetes pole, ning failinimi „final” ei ole haldusmehhanism.

Tagajärg on petlik, sest vastus võib näida tavalisest otsingutulemusest parem: see on lühike, grammatiliselt korrektne ja viitab päris dokumendile. Seetõttu tekib tunne, et kontroll on juba tehtud; link tõendab vaid seda, et vastuse juures näidati või seostati konkreetset faili. See ei tõenda, et iga väide tuleneb viidatud lõigust, et lõik pole erandi juurest välja rebitud ega et dokumendil on õigus olla autoriteetne. NIST-i GenAI profiil ei käsitle usaldusväärset välimust piisava riskikontrollina ja rõhutab juhtimist kogu süsteemi elutsükli jooksul.

Lahendus on avaldamisolek, versiooniahel ja prioriteedireeglid, mitte pikem viip. Igal indeksis oleval dokumendil peab olema omanik, jõustumis- ja lõppkuupäev, olek, asendatud dokument, üksus, konfidentsiaalsusklass ning ülevaatamise tähtaeg; otsingufilter peab vaikimisi välistama mustandid ja kehtetud versioonid. Kui allikad lähevad vastuollu, peab süsteem konflikti näitama ja hoiduma ühe kindla vastuse teesklemisest; vastutav omanik peab saama ülesande dokumendikogu korrastada; RAG võib kaose nähtavaks teha, kuid ei muuda kaost poliitikaks.

Vastuse liides peaks sellises olukorras näitama lisaks dokumendi nimele ka versiooni, kehtivusolekut, lõiku ja konfliktihoiatust. Logis tuleb säilitada, millised kandidaadid leiti ja miks üks neist valiti, et viga saaks pärast indeksi muutmist korrata. Kui süsteem hakkab hiljem vastama teisiti, peab meeskond saama kindlaks teha, kas muutus dokument, tükeldamine, otsingu seadistus või mudel; ilma sellise jälgitavuseta muutub kvaliteedijuhtum oletuseks „AI käitumise” kohta, mitte parandatavaks süsteemiveaks.

Mis on RAG-lahendus ja kuidas see ettevõtte dokumentidega töötab?

RAG-i töötlusahel algab andmete sissevõtust, mitte vestlusaknast; failid võetakse kindlatest hoidlatest ning neist eraldatakse tekst, tabelid ja olemasolev struktuur; skannitud dokumentidele on vaja optilist tekstituvastust ehk OCR-i. Seejärel jagatakse sisu tähenduslikeks lõikudeks, säilitades iga lõigu juures viite dokumendile, lehele, jaotisele ja haldusmetaandmetele. Microsoft käsitleb tükeldamist otsingu kasulikkust mõjutava valikuna: liiga väike tükk kaotab mõtte, liiga suur toob kaasa müra ning pimesi kindla märgiarvu järgi lõikamine võib poolitada tabeli või erandi.

Indekseerimisel luuakse lõikudest otsinguks sobiv esitus, tavaliselt märksõnaotsingu ja arvulistel vektoritel põhineva semantilise võrdluse kombinatsioon. Kui kasutaja esitab küsimuse, võib süsteem muuta selle mitmeks otsingupäringuks, rakendada üksuse-, kuupäeva- ja ligipääsufiltreid, leida kandidaadid ning need ümber järjestada. Alles seejärel jõuavad valitud lõigud koos ülesandega mudeli kontekstiaknasse: vasta olemasolevate tõendite põhjal, näita allikaid ja ütle, kui tõendeid ei piisa; midagi ei „õpita jäädavalt”; kontekst kehtib selle konkreetse päringu kohta.

Viimane etapp on genereerimine; eelnevalt treenitud keelemudel muudab lõigud arusaadavaks vastuseks, kuid võib neid kohmakalt ümber sõnastada, ühendada kokkusobimatuid allikaid või lisada usutava detaili oma üldteadmistest. Tulemus peab säilitama seose lõigu ja väite vahel, mitte näitama vastuse lõpus üksnes dekoratiivset allikaloendit. Kui küsimus nõuab toimingut, näiteks CRM-is hinna muutmist, ei tohi mudelile anda vaba täitmisõigust. Struktureeritud tööriistakutse kontrollivad rakenduse kood, õigused ja kinnitusetapp; otsing aitab leida põhjenduse; see ei anna tegutsemisluba.

Praktikas töötab hästi hübriidotsing: täpset tootekoodi või poliitikanumbrit otsitakse märksõnana, küsimuse tähendust aga semantiliselt; seejärel valib ümberjärjestamine lõigud, mis vastavad kõige paremini kogu küsimusele. Jada tuleb testida päris lühendite, vigaselt kirjutatud koodide, käänete ja mitmekeelsete dokumentidega, sest demo küsimus on tavaliselt liiga puhas. Kui vajalik lõik kandidaatide hulka ei jõua, ei saa genereeriv mudel seda kõneosavusega taastada; otsinguviga tuleb parandada enne viiba ümberkirjutamist.

Millistele dokumendiülesannetele RAG sobib?

Parimad kasutusjuhud on küsimused, mille vastus on paljudes hallatud dokumentides juba olemas, kuid mille leidmine võtab inimesel liiga kaua: siseprotseduurid, tootejuhendid, tehnilised juhised, kvaliteedidokumentatsioon, lepingumallide selgitused ja klienditoe teadmusbaas. RAG-i ülesanne pole uut otsust leiutada, vaid leida õige jaotis, ühendada mõned kooskõlalised lõigud ja teha mustand. Hea küsimus on „millises juhendis seda viga kirjeldatakse ja millised kontrollsammud seal on?”, mitte „kuidas peaks ettevõte igas kriisis käituma?”; kasulik on ka dokumentide eeluuring: projektijuht leiab lepingutest tarnetingimused, hankespetsialist nõuete mainimised ja hooldustehnik varasemad lahendused sarnasele seadmele. Vastus peab avama allika täpse koha ning süsteem salvestama päringu, leitud lõigud ja kasutatud versiooni; nii on RAG navigeerimis- ja mustanditööriist, mitte anonüümne otsustaja, kelle otsustuskäiku ei saa hiljem taastada.

Halvad kandidaadid on ülesanded, millel pole stabiilset dokumentaalset alust, mis nõuavad täpset arvutust või reeglite täitmist või kus üks viga käivitab automaatselt pöördumatu toimingu. Palgaarvestust, ligipääsu andmist, makse tegemist ja õigusliku tähtaja kontrolli juhivad kood ning kontrollitavad ärireeglid; RAG võib leida protseduuri selgituse, kuid ei asenda arvutusmootorit ega volitusahelat. Kui tegelik eesmärk on süsteeme ühendada ja andmeid prognoositavalt liigutada, tuleb hinnata äriprotsesside automatiseerimist, mitte teha genereeritud vastusest protsessi keskset lülitit.

Sobivuse määrab ka vastutav omanik; iga dokumendikogu vajab inimest, kes kinnitab allikad, lahendab vastuolud ja otsustab, mida indeksist eemaldada. Iga kasutusjuht vajab meeskonda, kes vaatab vead üle ja täiendab testikomplekti. Kui keegi seda tööd ei võta, muutub piloot mõne kuuga vanade dokumentide peegliks isegi siis, kui mudel ise pole muutunud. Tehniliselt lihtne, kuid hallatud klienditoe juhend on seetõttu parem esimene projekt kui kogu ettevõtte ketta ühendamine ühe õhtuga.

Mida saab RAG ettevõtte dokumentidega igapäevaselt teha?

RAG võib vähendada aega, mida töötaja kulutab õige kausta ja märksõnade arvamisele, sest semantiline otsing leiab lõigu ka siis, kui küsimuse sõnad ei ühti dokumendi terminitega. See võib ühendada mitu kooskõlalist allikat, selgitada keerukat juhendit lihtsamalt, koostada e-kirja või aruande mustandi ning näidata, milliselt lehelt iga oluline väide pärineb. OpenAI file search ja Microsofti otsinguarhitektuur on konkreetsed tööriistanäited, kuid tootevalik ei kaota vajadust määrata dokumentide olek, filtrid ja kvaliteedikontrollid. Süsteem võib paljastada ka probleeme, mida kaustade sirvimine varjab: ühe küsimuse kohta leidub kaks vasturääkivat juhendit, sagedasel küsimusel puudub allikas või ühe osakonna dokumendid domineerivad, sest need on paremini struktureeritud. Need juhtumid on väärtuslikud vaid siis, kui neid ei peideta ühe ladusa vastuse taha. Puuduv allikas ja konflikt peavad muutuma mõõdetavaks sündmuseks, mida dokumendi omanik näeb; nii saab RAG-i kvaliteedilogist ka teadmusjuhtimise tööjärjekord, mitte pelgalt mudeli jõudluse graafik.

Teine reaalne võimalus on kohandada esitust rolli ja konteksti järgi; tehnik saab üksikasjaliku juhise koos koodidega, kliendinõustaja lühema selgituse, kui mõlemal on õigus samu allikaid näha. Muutub esitus, mitte tõde, ning kõigi rollide puhul peavad allika olek ja puuduva teabe väljamõtlemise keeld jääma samaks. Meie töö AI-lahendustega algab kasutusjuhu ja riskipiiri määramisest, mitte mudeli demost, sest hea prototüüp tõendab konkreetset töövõitu teie dokumentidel ning näitab samal ajal küsimusi, millele süsteem peab vastama „ma ei tea”.

Igapäevatöös tekib suurim kasu siis, kui inimene näeb, mida süsteem tema eest tegi ja mis vajab veel kontrolli. Vastuse mustandis saab esile tõsta puudulikult põhjendatud väited, pakkuda seotud dokumente ja lasta ühe toiminguga valest versioonist teatada; selline tagasiside on väärtuslikum kui lihtne pöidlaikoon. Parandus tuleb siduda küsimuse, lõigu ja vealiigiga, et meeskond eristaks leidmata allikat kohmakast sõnastusest või valest ärireeglist ning valiks sobiva paranduse.

Mida ei saa RAG teha, kui veenev vastus ka poleks?

RAG ei saa tagada tõde, sest viga võib tekkida enne genereerimist, selle ajal või pärast seda. Allikas võib sisaldada vale fakti, otsing valida sobimatu lõigu, kontekst kaotada erandi või mudel ühendada õiged lõigud valesti. Tsitaat vähendab pimeda usalduse riski ainult siis, kui kasutaja saab avada täpse koha ja kontrollida, kas väide sellest tõesti tuleneb. Link päris PDF-ile ei ole kvaliteedimärk, nagu ka vigase aruande bibliograafia ei muuda järeldust õigeks.

RAG ei rakenda ise ligipääsukontrolli; kui otsingukiht ei filtreeri enne otsingut dokumente kontrollitud kasutajaidentiteedi ja dokumendiõiguste alusel, võib mudeli konteksti jõuda lõik, mida kasutaja ei tohi näha. Hiljem viipa kirjutatud „ära avalda salajast teavet” ei paranda seda arhitektuuriviga; Microsofti dokumenditaseme ligipääsu juhised näevad ette õigusandmed ja turbefiltrid otsinguteel endal. Liideses peidetud nupp ei kaitse midagi, kui päringut saab teha muul viisil.

RAG ei muuda ka ebausaldusväärset sisu turvaliseks; dokumendis, veebilehel või e-kirjas võib olla juhis, mis püüab süsteemi käitumist ümber kirjutada — viibasüst. OWASP käsitleb seda eraldi riskina, mida ei lahenda täielikult üks keeld süsteemiviibas. Seetõttu tuleb välist sisu käsitleda andmete, mitte käskudena; tööriistakutsed peavad olema kitsalt lubatud ja valideeritud ning suure riskiga toiming jääma kindla reegli ja inimese kinnituse taha. Mudel võib ettepaneku teha, kuid volituse annab süsteem.

Piiride hulka kuuluvad ka käideldavus ja talitluspidevus; kui otsinguindeks pole kättesaadav, ei tohi turvaline süsteem teeselda, et ettevõtte allikad on endiselt olemas. See peab selgelt minema veaseisundisse või piiratud režiimi, muidu ei erista kasutaja allikapõhist vastust mudeli vabast improvisatsioonist; samuti on vaja kulu- ja päringupiire, hädaseiskamist ning eelmise seadistuse taastamist. RAG-toode on mitme teenuse ahel ja iga vaikne tõrge võib vastuse tähendust muuta ka siis, kui vestlusaken töötab edasi.

Dokumentide valmisolek: OCR, metaandmed ja versioonihaldus

Dokumendikausta maht ei näita valmisolekut. Viltuse lehega skannitud leping, loetamatu päisega tabel, vale tekstijärjekorraga PDF või väikese kontrastiga foto võib inimesele arusaadav olla, kuid OCR-i väljundis kaotada numbri, veergude seose või lõigupiiri. Microsofti OCR-i piirangud seovad tulemuse selgelt skanni kvaliteedi, eraldusvõime, kontrasti, valgustuse, pöörde ja teksti omadustega. Seetõttu tuleb esinduslikke dokumente pärast eraldamist kontrollida, võrreldes teksti, tabeleid, leheviiteid ja olulisi välju originaaliga, mitte uskuda teadet „fail töödeldi edukalt”.

Metaandmed annavad lõigule organisatsiooni konteksti; dokumendi tüüp, üksus, toode, keel, omanik, kinnitaja, konfidentsiaalsus, jõustumisaeg ja versiooni olek võimaldavad päringut piirata enne semantilise sarnasuse hindamist. Ilma nendeta võrdleb otsing lauseid, kuid ei tea, et laojuhend kehtib ainult Leedus või et lepingu lisa asendati uuemaga. Kõige olulisemad väljad tuleb võtta usaldusväärsest süsteemist või lasta inimesel kinnitada; genereeritud oletus dokumendi oleku kohta ei tohi muutuda filtriks, mis määrab järgmise vastuse.

Ka uuendamine on toote osa, mitte ühekordne import. Tuleb teada, kui kiiresti jõuab kinnitatud muudatus indeksisse, kuidas eemaldatakse tagasi võetud lõik, mis juhtub faili aadressi muutumisel ja kas tõrke korral näitab süsteem edasi vana versiooni. Microsofti indeksijuhised eristavad järkjärgulisi uuendusi täielikust ümberindekseerimisest; seega vajab iga allikas dokumenteeritud sünkroonimis- ja veakontrolli meetodit. Enne RAG-projekti tasub korrastada üks autoriteetne dokumendivoog, sest muidu kiirendab hea otsing ainult ebaselge halduse tagajärgi.

Enne esimest indekseerimist on kasulik teha dokumentide valmisoleku valim; valige erinevad failitüübid, vanused, keeled, tabelid, skannid ja ligipääsuklassid ning kontrollige igaühe puhul eraldatud teksti, tükipiire, metaandmeid ja allikalinki. Vigade osakaalu ei tohi sulatada üheks keskmiseks, sest kaotatud koma hind juhendis ja kaotatud summa hind lepingus pole sama. Valim aitab otsustada, milliseid vorminguid automaatselt vastu võtta, millised vajavad inimese kontrolli ja milliseid ei tasu praegu indekseerida; see töö annab sageli suurema kvaliteedivõidu kui teise keelemudeli valimine.

Ligipääsuõigused, privaatsus ja juurutusviis

Turvaline arhitektuur algab identiteedist: kes küsib, millisesse organisatsiooni ja üksusesse ta kuulub, milliseid dokumendiklasse tohib ta näha ning kas neid õigusi kontrollitakse igal otsingupäringul. Õigusfilter peab töötama enne, kui lõigud jõuavad mudeli konteksti; logides tuleb vältida tervete küsimuste, vastuste ja tundlike lõikude tarbetut kopeerimist. Testida tuleb ka piirjuhtumeid: töötaja vahetab rolli, dokument piiratakse, ligipääs tühistatakse või ühe kliendi kasutaja püüab leida teise kliendi sisu. „Vestlus nõuab sisselogimist” ei ole piisav vastuvõtukriteerium.

Küsimusele „kas minu andmed lähevad mudeli treenimiseks?” pole ausat universaalset vastust ilma teenusepakkuja, toote, konto ja seadistuste nimetamiseta. OpenAI äri- ja API-materjalide järgi ei kasutata asjaomaste äritoodete andmeid vaikimisi mudelite treenimiseks, samas kirjeldab API andmekontrolli dokumentatsioon eraldi säilitamist, väärkasutuse seiret ja lõpp-punktide erandeid. Anthropic eristab samuti äritoodete andmetöötlust, teadlikku nõusolekut mudeli parandamiseks ja säilitustingimusi; seetõttu kontrollitakse lepingus ja tehnilises projektis konkreetset teenust, mitte ei toetuta fraasile „äri-API”.

Lahenduse juurutamine EL-i piirkonda või oma taristusse võib aidata täita andmete asukoha-, kontrolli- või integratsiooninõudeid, kuid ei tõenda iseenesest IKÜM-i nõuetele vastavust ega turvalisust. Endiselt tuleb määrata töötlemise eesmärk ja õiguslik alus, minimaalsed andmed, säilitustähtajad, alamtöötlejad, kustutamine, intsidendiprotsess ja ligipääsuaudit; IKÜM-i põhimõtted kehtivad kogu ahelale, mitte ainult mudeliserveri riigile. Mõnikord on õige otsus jätta osa dokumente RAG-ist välja või eemaldada enne indekseerimist väljad, mida vastuseks vaja pole.

Ohumudel peab katma peale uudishimuliku töötaja ka vigase grupisünkroonimise, jagatud lingi, administraatorirolli, salvestatud vahemälu ja pahatahtliku juhisega dokumendi. Testkasutajad peavad esindama iga rolli ja keelatud rollikombinatsiooni ning küsima otse, sünonüümidega ja kaudse kokkuvõttepalvega; tulemus ei tohi paljastada lõiku, dokumendi nime ega vastusest tuletatavat salajast detaili. Pärast õiguste muutmist tuleb test korrata, sest eilne turvaline filter võib olla vahemällu jäänud; need on vastuvõtukriteeriumid, mitte hilisema turvaauditi kaunistus.

Kuidas mõõta otsingut, allikapõhisust ja õigsust?

Üks „täpsus” RAG-süsteemile on nagu üks keskmine hinne haiglale: arv võib olla hea, kuigi kriitiline vealiik jääb peitu. Kõigepealt mõõdetakse otsingut eraldi — kas vajalik lõik jõudis määratud arvu parimate tulemuste hulka ja kas tarbetud lõigud ei tõrjunud seda välja. Seejärel mõõdetakse konteksti vastavust küsimusele, vastuse põhinemist antud lõikudel, faktilist õigsust kinnitatud etaloni suhtes, iga allikaviite sobivust konkreetse väitega ning süsteemi oskust vastamata jätta, kui allikat pole või allikad on vastuolus.

Microsofti RAG-i hindajate dokumentatsioon eristab neid mõõtmeid ja ARES-i uurimus teeb sarnaselt vahet konteksti asjakohasusel, vastuse allikapõhisusel ja vastuse asjakohasusel. Praktilises testikomplektis vajab iga päris küsimus seetõttu peale „õige vastuse” ka kohustuslikku allikat, lubatud sõnastusi, keelatud väiteid, rolli, dokumendiversiooni ja oodatavat käitumist siis, kui tõendeid ei piisa. Osa näiteid tuleb sagedastest küsimustest, osa kulukatest eranditest ja teadlikest lõksudest.

Vastuvõtulävi tuleb määrata igale mõõtmele ja riskiklassile enne tulemuste nägemist; muidu valib meeskond pärast demot näitaja, mis kõige parem välja näeb. Piloodi mõõtmistes tuleb säilitada vigade jaotus dokumenditüübi, üksuse, keele ja küsimuseliigi kaupa, sest üldkeskmine võib peita, et juhendid töötavad hästi, lepingutabelid aga halvasti. Automaatne mudelhindaja aitab kontrolli skaleerida, kuid valimi vaatab üle inimene ning kriitilisi vastuseid võrreldakse autoriteetse allikaga, mitte teise mudeli enesekindlusega.

Pärast käivitamist mõõdetakse samu omadusi kontrollitud toodanguvalimi ja privaatsust hoidvate logidega; dokumendikogu, tükeldusalgoritmi, vektoresituse mudeli, ümberjärjestamise või genereeriva mudeli muutus võib parandada üht küsimuserühma ja halvendada teist. Iga versioon vajab seetõttu regressioonitesti ja võrreldavat lähtejoont, kus hindamisreeglid jäävad kogu testikomplektis samaks. Hoiatus ei tohi käivituda ainult koondnäitaja languse korral, vaid ka kriitilise vea ilmumisel, näiteks keelatud lõigu näitamisel või väljamõeldud vastusel seal, kus süsteem pidi vastamata jätma.

RAG, otsing, pikk kontekst, peenhäälestus ja agendid

Tavaline täistekstiotsing on parem, kui kasutaja teab täpset nime, koodi või fraasi ja vajab dokumenti, mitte koostatud vastust; see on odavam, prognoositavam ja lihtsamini auditeeritav. Semantiline otsing aitab sünonüümide ja ebaselgete küsimustega, kuid genereerimine tasub lisada ainult siis, kui kokkuvõte loob tegelikku väärtust. RAG pole kohustuslik iga ettevõtte otsingusüsteemi jaoks; mõnikord on õige toode hea filtrite, lõigueelvaate ja versiooni olekuga otsinguleht, sest kasutaja teeb järelduse ise täisdokumendist.

Terve dokumendi paigutamine pikka kontekstiaknasse võib olla lihtne väikese ja stabiilse materjali puhul, kuid suures korpuses kasvavad kulu, müra ja oht, et oluline lõik kaob ebaolulise sisu vahele. Mudeli täiendav kohandamine ehk fine-tuning võib kinnistada vormingut, stiili või kindlat ülesandekäitumist, kuid pole mugav viis sageli muutuvate hindade, poliitikate ja juhiste hoidmiseks, sest allika uuendamine ja viitamine muutuvad vähem läbipaistvaks. RAG lubab dokumendikogu muuta mudeli kaalude treenimisest sõltumatult, ent see paindlikkus nõuab indeksi, versioonide ja otsingukvaliteedi haldamist.

Automatiseerimine täidab ette määratud samme, AI-agent võib aga valida tööriista ja järgmise sammu; selline vabadus nõuab rangemaid volitus-, valideerimis- ja seiskamispiire. RAG võib anda agendile teavet, kuid mitte õigusi: puhkusepoliitika leidmine ei anna mudelile õigust puudumist kinnitada või palgasüsteemi muuta. Struktureeritud funktsioonikutse on vaid ettepanek rakendusele, mis kontrollib skeemi, identiteeti, lubatud toimingut, summasid või muid piire ja vajaliku inimese kinnitust. Tehnoloogiate võrdlus algab protsessi riskist, mitte soovist kasutada kõige uuemat nimetust.

Valiku saab sõnastada lihtsa kontrollina; kui vaja on fail leida ja avada, alustage otsingust. Kui tuleb koondada mõni muutuv allikas koos viidetega, hinnake RAG-i. Kui on vaja püsivat vormingut või klassifitseerimiskäitumist, võib sobida mudeli peenhäälestus; kui tuleb täita prognoositav toimingute jada, ehitage automatiseerimine. Agent lisage vaid siis, kui järgmist sammu ei saa turvaliselt programmeerida ja kasu kaalub lisariski üles. Neid lähenemisi võib kombineerida, kuid igal kihil peab olema oma ülesanne, mõõdik ja seiskamispiir, muidu kaob vea põhjus sõna „AI” taha.

Kuidas ehitada piiratud piloot päris küsimustega?

Piloot algab ühest dokumendikogust, ühest kasutajarühmast ja ühest otsustuspiirist, näiteks tehnilise toe käsiraamatutest, kus süsteem ainult leiab allikad ja koostab vastuse mustandi. Enne arendust kogub meeskond päris küsimusi otsingulogidest, e-kirjadest ja töötajate intervjuudest, lisab õiged allikad ning kaasab teadlikult vastamatuid, aegunud, vastuolulisi ja keelatud juhtumeid. Iga juhtumi puhul määratakse vastuvõetav tulemus: vajalik lõik leitakse, väide põhineb allikal, viide avab õige koha, vastus on faktiliselt õige ja süsteem ei mõtle puuduvat infot välja.

Läved fikseeritakse enne demot ja jagatakse riski järgi; sagedase infoküsimuse puhul võib sobida parandatav mustand, kuid isikuandmete, lepingu, turbe või maksega seotud küsimus nõuab rangemat kontrolli ja inimese kinnitust. Piloodis mõõdetakse ka vastamisaega, kulu päringu kohta, ligipääsufiltrite toimimist, indeksi uuendamise viivitust ning seda, kui tihti töötaja avab allika või parandab vastust. Kui süsteem parandab ainult demonäiteid, kuid ei läbi varem peidetud testikomplekti, ei ole toote tulemust tõendatud; tõendatud on vaid meeskonna oskus demo ette valmistada.

Meie AI-lahenduste arendus on alates 3 500 € ja kestab tavaliselt 3–8 nädalat; töötava piloodi teie enda andmetel saame tarnida 2–3 nädalaga. Need arvud kirjeldavad teenuse alghinda ja üldist ajakava, mitte tundmatu mahuga fikseeritud pakkumist. Piloodi lõpuks peab peale vestlusakna olemas olema versioonitud dokumendikogu, testküsimused, eraldi kvaliteedinäitajad, vealogi, ligipääsutestid ja otsus selle kohta, mida lahendus ei tohi teha. Hilisemad integratsiooninõuded tasub fikseerida sama selgelt nagu muus digiprojektis, järgides artiklis „10 viga, mida ettevõtjad veebilehe tellimisel teevad” kirjeldatud põhimõtet: vastuvõtukriteeriumid ja omanikud määratakse enne täismahus juurutust, mitte pärast esimest muljet avaldavat ekraani.

Pilooti jätkatakse ainult siis, kui see saavutab ette määratud läved varem nägemata testiosas, käsitleb keelatud ja vastamatuid küsimusi turvaliselt ning annab inimese töös mõõdetava kasu. Kui otsing ei leia järjepidevalt õiget allikat, parandatakse esmalt dokumente, metaandmeid ja indeksit; kui allikas on õige, kuid genereerimine moonutab seda, muudetakse konteksti, viipa või mudelit. Kui viga tekib ainult suure riskiga otsustes, jäetakse need kindlate reeglitega süsteemile ja inimesele. Peatatud piloot ei ole läbikukkumine, vaid odavalt saadud tõend, et selle protsessi puhul on RAG-i piirid olulisemad kui demoefekt.