AI integrācija — RAG risinājums uz uzņēmuma dokumentiem: ko tas var un ko nevar

RAG var atrast uzņēmuma dokumentu fragmentus un sagatavot ar avotiem saistītas atbildes, taču tas nav modeļa apmācība, patiesības mašīna vai piekļuves kontroles aizstājējs.

Pirmdienas rītā personāla vadītāja jautā iekšējam asistentam, cik ilgi glabājami kandidātu dati, un saņem pārliecinošu atbildi ar saiti uz uzņēmuma politiku; vienīgā problēma — atrastā redakcija zaudēja spēku pirms astoņiem mēnešiem. Šāds RAG risinājums uz uzņēmuma dokumentiem tehniski var būt izdarījis visu, ko tam lūdza: atradis semantiski līdzīgu fragmentu, ielicis to modeļa kontekstā un uzrakstījis gludu atbildi; tas tomēr nav pārbaudījis, vai fails ir jaunākā apstiprinātā versija, ja versijas statuss indeksā nav ticami norādīts.

RAG saīsinājums apzīmē retrieval-augmented generation jeb ģenerēšanu, kurai atbildes brīdī pievieno izgūtu ārēju kontekstu; tā nav uzņēmuma dokumentu iemācīšana modeļa svaros un nav atsevišķs “gudrības slānis”, kas automātiski zina, kurš dokuments ir patiess; drīzāk tā ir bibliotēka ar ļoti ātru bibliotekāru un talantīgu redaktoru, kur bibliotekārs var atnest nepareizo sējumu, bet redaktors tik un tā uzrakstīs pārliecinošu rindkopu. Sākotnējais RAG darbs tieši nošķir modeļa parametrisko atmiņu no ārēji izgūta, neparametriska avota.

Praktiskais ieguvums ir būtisks, ja robežas ir godīgi nosauktas: sistēma var sameklēt atbilstošus fragmentus pārvaldītā dokumentu kopā, salikt tos jautājumam piemērotā kontekstā un sagatavot melnrakstu ar pārbaudāmu norādi uz avotu. Atbildības robežai jābūt redzamai arī lietotājam: interfeiss nedrīkst radīt iespaidu, ka avota esamība ir juridisks apstiprinājums, bet kļūdu un neskaidrību ziņošanai jābūt tikpat vienkāršai kā jautājuma uzdošanai. Tā nevar salabot nekvalitatīvu dokumentāciju, garantēt faktisku pareizību, pati ieviest piekļuves tiesības vai aizstāt determinētu darbplūsmu un cilvēka apstiprinājumu gadījumos, kuros kļūda rada juridisku, finansiālu, drošības vai cilvēku tiesību risku; šī robeža nosaka gan arhitektūru, gan to, ko jēgpilni mērīt pilotā.

Kāpēc veca politika var tikt izgūta kā pašreizējā

Vecās politikas incidents sākas nevis valodas modelī, bet dokumentu pārvaldībā: koplietotajā diskā atrodas “Personas_dati_final.docx”, “Personas_dati_final2.docx” un apstiprināts PDF, bet nevienam failam nav vienotas spēkā stāšanās dienas, statusa vai aizstātās versijas identifikatora. Indekss redz trīs saturiski līdzīgus kandidātus, un semantiskā meklēšana var augstu novērtēt veco dokumentu, jo tā formulējums precīzāk sakrīt ar jautājumu. Modelis neredz organizācijas sapulces lēmumu, ja šis lēmums nav datos, un faila nosaukums “final” nav pārvaldības mehānisms.

Sekas ir viltīgas, jo atbilde var izskatīties labāka par parastu meklēšanas rezultātu: tā ir īsa, gramatiski pareiza, atsaucas uz īstu dokumentu un tādēļ rada sajūtu, ka pārbaude jau veikta. Avota saite pierāda tikai to, ka konkrēts fails ir parādīts vai piesaistīts atbildei; tā vēl nepierāda, ka katrs apgalvojums izriet no citētā fragmenta, ka fragments nav izrauts no izņēmuma sadaļas vai ka dokumentam ir tiesības būt autoritatīvam; NIST GenAI profils šādu uzticamu izskatu neuzskata par pietiekamu riska kontroli un uzsver pārvaldību visā sistēmas dzīves ciklā.

Labojums ir publicēšanas statuss, versiju ķēde un prioritātes noteikumi, nevis garāka uzvedne: indeksā katram dokumentam vajadzīgs īpašnieks, spēkā stāšanās un beigu datums, statuss, aizstātais dokuments, nodaļa, konfidencialitātes klase un pārskatīšanas termiņš; izgūšanas filtram pēc noklusējuma jāizslēdz melnraksti un zaudējušas spēku redakcijas; ja avoti konfliktē, sistēmai jārāda konflikts un jāatturas no vienas drošas atbildes tēlošanas, bet atbildīgajam īpašniekam jāsaņem uzdevums dokumentu kopu sakārtot. RAG var izgaismot haosu, taču tas nevar haosu pārvērst politikā.

Atbildes interfeisam šādā situācijā jāparāda ne tikai dokumenta nosaukums, bet arī redakcija, spēkā esamības statuss, fragments un brīdinājums par konfliktu; žurnālā jāsaglabā, kuri kandidāti tika atrasti un kāpēc viens izvēlēts, lai kļūdu varētu atkārtot pēc indeksa maiņas. Ja sistēma vēlāk sāk dot citu atbildi, komandai jāspēj noteikt, vai mainījās dokuments, fragmentēšana, meklēšanas konfigurācija vai modelis; bez šādas izsekojamības kvalitātes incidents pārvēršas minējumā par “AI uzvedību”, nevis labojamā sistēmas defektā.

Kā darbojas RAG risinājums uz uzņēmuma dokumentiem?

RAG cauruļvads sākas ar datu uzņemšanu, nevis ar tērzēšanas logu: faili tiek paņemti no noteiktām krātuvēm, izvilkts teksts, tabulas un pieejamā struktūra, bet skenētiem dokumentiem vajadzīga optiskā rakstzīmju atpazīšana jeb OCR; tālāk saturs tiek sadalīts jēgpilnos fragmentos, katram saglabājot saiti uz dokumentu, lapu, sadaļu un pārvaldības metadatiem. Microsoft vadlīnijas fragmentēšanu apraksta kā izvēli, kas ietekmē meklēšanas lietderību: pārāk mazs fragments pazaudē domu, pārāk liels atnes daudz trokšņa, bet akla dalīšana noteiktā zīmju skaitā var pārgriezt tabulu vai izņēmuma nosacījumu.

Indeksēšanas posmā fragmentiem izveido meklēšanai piemērotu attēlojumu, parasti apvienojot atslēgvārdu meklēšanu ar semantisku salīdzinājumu pēc skaitliskiem vektoriem; kad lietotājs uzdod jautājumu, sistēma to var pārveidot vairākos meklēšanas vaicājumos, piemērot nodaļas, datuma un piekļuves filtrus, izgūt kandidātus un tos pārrindot; tikai tad atlasītie fragmenti nonāk modeļa konteksta logā kopā ar uzdevumu: atbildēt no pieejamajiem pierādījumiem, norādīt avotus un pateikt, ja pierādījumu nepietiek. Šajā brīdī nekas netiek “iemācīts uz visiem laikiem”; konteksts attiecas uz konkrēto pieprasījumu.

Pēdējais posms ir ģenerēšana, kur iepriekš apmācīts valodas modelis pārvērš fragmentus saprotamā atbildē, tādēļ tas var arī pārfrāzēt neveikli, savienot nesavienojamus avotus vai pievienot ticamu detaļu no savām vispārīgajām zināšanām; rezultātam jāsaglabā fragmenta un apgalvojuma saite, ne tikai dekoratīvs avotu saraksts atbildes beigās; ja jautājums prasa darbību — piemēram, mainīt cenu CRM — modelim nevajag dot brīvu izpildi: strukturētu rīka pieprasījumu pārbauda lietojumprogrammas kods, tiesības un apstiprināšanas solis. Izgūšana palīdz atrast pamatojumu; tā nav atļauja rīkoties.

Praksē labi darbojas hibrīda izgūšana, kur precīzs produkta kods vai politikas numurs tiek meklēts kā atslēgvārds, bet jautājuma nozīme — semantiski; pēc tam pārrindošana izvēlas fragmentus, kas vislabāk atbild uz visu jautājumu. Šī secība jāpārbauda ar īstiem saīsinājumiem, kļūdaini uzrakstītiem kodiem, locījumiem un daudzvalodu dokumentiem, jo demonstrācijas jautājums parasti ir pārāk tīrs. Ja vajadzīgais fragments kandidātos neparādās, ģenerējošais modelis to nevar atgūt ar daiļrunību, tāpēc meklēšanas kļūda jālabo pirms uzvednes pārfrāzēšanas.

Kuriem dokumentu lietojumiem RAG ir piemērots

Vislabākie kandidāti ir jautājumi, kuru atbilde jau dzīvo daudzos pārvaldītos dokumentos, bet cilvēkam tās atrašana prasa pārāk ilgu meklēšanu: iekšējās procedūras, produktu rokasgrāmatas, tehniskās instrukcijas, kvalitātes dokumentācija, līgumu veidņu skaidrojumi un klientu atbalsta zināšanu bāze. Šeit RAG uzdevums nav izgudrot jaunu lēmumu, bet atrast attiecīgo nodaļu, apvienot dažus savstarpēji saderīgus fragmentus un sagatavot melnrakstu. Labs jautājums ir “kurā instrukcijā aprakstīta šī kļūda un kādi pārbaudes soļi tajā norādīti?”, nevis “kā uzņēmumam rīkoties jebkurā ārkārtas situācijā?”. Noderīgs ir arī dokumentu izpētes slānis pirms cilvēka darba: projektu vadītājs var atrast līgumos piegādes nosacījumus, iepirkumu speciālists — prasību pieminējumus, bet servisa darbinieks — agrākus risinājumus līdzīgai iekārtai. Atbildei šādos gadījumos jāatver avota vieta, lai lietotājs varētu pārbaudīt kontekstu, un sistēmai jāsaglabā vaicājuma, atrasto fragmentu un izmantotās versijas žurnāls. Tas padara RAG par navigācijas un melnraksta rīku, nevis anonīmu spriedumu izdevēju, kuram vēlāk nevar atjaunot lēmuma ceļu.

Slikti kandidāti ir uzdevumi, kuros nav stabila dokumentāla pamata, nepieciešama precīza aritmētika vai noteikumu izpilde, vai arī viena kļūda automātiski rada neatgriezenisku darbību. Algas aprēķinu, piekļuves piešķiršanu, maksājuma izpildi un juridiska termiņa kontroli nosaka kods un pārbaudāmi biznesa noteikumi; RAG var sameklēt procedūras skaidrojumu, bet nevar aizstāt aprēķina dzinēju vai pilnvarojuma ķēdi. Ja īstais mērķis ir savienot sistēmas un paredzami pārvietot datus, jāvērtē biznesa procesu automatizācija, nevis ģeneratīva atbilde jāpadara par procesa centrālo slēdzi.

Piemērotību nosaka arī atbildības īpašnieks: katrai dokumentu kopai vajag cilvēku, kurš apstiprina avotus, risina konfliktus un pieņem lēmumu par izņemšanu no indeksa, bet katram lietojumam — komandu, kura pārskata kļūdas un maina testu kopu; ja neviens neuzņemas šo darbu, pilots pēc dažiem mēnešiem kļūst par vecu dokumentu spoguli, lai gan pats modelis nav mainījies; tehniski vienkāršs, bet pārvaldīts atbalsta ceļvedis tādēļ ir labāks pirmais projekts nekā visa uzņēmuma diska pieslēgšana vienā vakarā.

Ko RAG var izdarīt uzņēmuma dokumentu ikdienā

RAG var samazināt laiku, ko darbinieks pavada, minot pareizo mapi un atslēgvārdus, jo semantiska meklēšana spēj atrast fragmentu arī tad, ja jautājuma vārdi nesakrīt ar dokumenta terminoloģiju. Tas var atbildē apvienot vairākus saderīgus avotus, paskaidrot sarežģītu instrukciju vienkāršākā valodā, sagatavot e-pasta vai atskaites melnrakstu un parādīt, no kurām lapām katrs būtiskais apgalvojums nācis. OpenAI failu meklēšana un Microsoft meklēšanas arhitektūra ir konkrēti rīku piemēri, taču produkta izvēle neatceļ vajadzību definēt savu dokumentu statusu, filtrus un kvalitātes pārbaudes. Sistēma var arī atklāt dokumentācijas problēmas, kuras parasta mapju pārlūkošana slēpj: vienam jautājumam tiek atrastas divas pretrunīgas instrukcijas, bieži jautājumi paliek bez avota, vai viena nodaļa dominē rezultātos, jo tās faili ir labāk strukturēti. Šie gadījumi ir vērtīgi tikai tad, ja tos nepaslēpj aiz vienas gludas atbildes; neatrasts avots un konflikts jāpārvērš izmērāmā notikumā, ko redz dokumenta īpašnieks. Tad RAG kvalitātes žurnāls kļūst arī par zināšanu pārvaldības darba sarakstu, nevis tikai par modeļa veiktspējas grafiku.

Vēl viena reāla iespēja ir lomu un konteksta pielāgošana: tehniķis saņem detalizētu instrukciju ar kodiem, bet klientu konsultants — īsāku skaidrojumu, ja abiem ir tiesības redzēt tos pašus avotus. Atšķiras prezentācija, nevis patiesība, un katrai lomai jāsaglabā vienāds avota statuss un aizliegums izdomāt trūkstošo. Mūsu AI risinājumu izstrādes darbs sākas ar šāda lietojuma un riska robežu, nevis ar modeļa demonstrāciju, jo labs prototips pierāda konkrētu darba ieguvumu uz Jūsu dokumentiem un vienlaikus parāda, kuros jautājumos sistēmai jāsaka “nezinu”.

Ikdienas darbā lielākais ieguvums rodas tad, ja cilvēks redz, ko sistēma paveikusi viņa vietā un kas vēl jāpārbauda. Atbildes melnrakstā var izcelt apgalvojumus ar nepilnīgu pamatojumu, piedāvāt saistītos dokumentus un ļaut ar vienu darbību ziņot par nepareizu versiju; šāda atgriezeniskā saite ir vērtīgāka par vienkāršu īkšķa ikonu. Labojums jāpiesaista jautājumam, fragmentam un kļūdas veidam, lai komanda varētu atšķirt neatrastu avotu no neveiklas valodas vai nepareiza biznesa noteikuma un izvēlēties atbilstošu labojumu.

Ko RAG nevar izdarīt, lai cik pārliecinoša būtu atbilde

RAG nevar garantēt patiesumu, jo kļūda var rasties pirms ģenerēšanas, tās laikā vai pēc tās: avotā var būt nepareizs fakts, izgūšana var izvēlēties neatbilstošu fragmentu, konteksts var pazaudēt izņēmumu, bet modelis var nepareizi savienot pareizas rindkopas. Citāts samazina aklas uzticēšanās risku tikai tad, ja lietotājs var atvērt precīzu vietu un pārbaudīt, vai apgalvojums tiešām no tās izriet, bet saite uz īstu PDF nav kvalitātes zīmogs, tāpat kā bibliogrāfija kļūdainā atskaitē pati nepadara secinājumu pareizu.

Tas nevar pats ieviest piekļuves kontroli: ja meklēšanas slānis pirms izgūšanas nefiltrē dokumentus pēc pārbaudītas lietotāja identitātes un dokumenta atļaujām, modelim var nonākt fragments, kuru lietotājs nedrīkst redzēt, un vēlāk uzvednē ierakstīts “neatklāj slepenu informāciju” šo arhitektūras kļūdu neizlabo. Microsoft dokumentu līmeņa piekļuves vadlīnijas paredz atļauju datus un drošības filtrus pašā meklēšanas ceļā; lietotāja saskarnes paslēpta poga nav aizsardzība, ja vaicājumu var izsaukt citādi.

RAG arī nepadara neuzticamu saturu drošu: dokumentā, tīmekļa lapā vai e-pastā var būt instrukcija, kas mēģina pārrakstīt sistēmas uzvedību — promptu injekcija —, un OWASP to izceļ kā atsevišķu risku, kuru pilnībā neatrisina vienkāršs aizliegums sistēmas uzvednē; tāpēc ārējs saturs jāuztver kā dati, nevis komandas, rīku izsaukumiem jābūt šauri atļautiem un validētiem, bet augsta riska darbībai jāpaliek determinētam noteikumam un cilvēka apstiprinājumam. Modelis drīkst ierosināt; pilnvaras piešķir sistēma.

Robežu sarakstā jāiekļauj arī pieejamība un darbības nepārtrauktība: ja meklēšanas indekss nav sasniedzams, droša sistēma neizliekas, ka tai joprojām ir uzņēmuma avoti, bet skaidri pārslēdzas uz kļūdas stāvokli vai ierobežotu režīmu; pretējā gadījumā lietotājs nevar atšķirt avotos balstītu atbildi no modeļa brīvas improvizācijas. Tāpat jāparedz izmaksu un pieprasījumu limiti, avārijas apturēšana un iepriekšējās konfigurācijas atjaunošana; RAG produkts ir vairāku servisu ķēde, un katra klusā atteice var izmainīt atbildes nozīmi, pat ja tērzēšanas logs turpina darboties.

Dokumentu gatavība: OCR, metadati un versiju pārvaldība

Dokumentu mapes apjoms nav gatavības rādītājs: skenēts līgums ar šķību lapu, tabula bez nolasāmas galvenes, PDF ar nepareizu teksta secību vai foto ar zemu kontrastu var izskatīties saprotams cilvēkam, bet OCR izvilkumā zaudēt ciparu, kolonnu saistību vai rindkopas robežu; Microsoft OCR ierobežojumu apraksts skaidri saista rezultātu ar skenējuma kvalitāti, izšķirtspēju, kontrastu, apgaismojumu, pagriezienu un teksta īpašībām. Tāpēc reprezentatīvi dokumenti jāpārbauda pēc izvilkšanas, salīdzinot tekstu, tabulas, lapu atsauces un būtiskos laukus ar oriģinālu, nevis jāuzticas tam, ka fails “veiksmīgi apstrādāts”.

Metadati piešķir fragmentam organizācijas kontekstu: dokumenta tips, struktūrvienība, produkts, valoda, īpašnieks, apstiprinātājs, konfidencialitāte, spēkā stāšanās laiks un versijas statuss ļauj vaicājumu sašaurināt pirms semantiskas līdzības vērtēšanas. Bez tiem meklētājs salīdzina teikumus, bet nezina, ka noliktavas instrukcija attiecas tikai uz Lietuvu vai ka līguma pielikums aizstāts ar jaunāku. Svarīgākie lauki jāiegūst no uzticamas sistēmas vai jāpārbauda cilvēkam; ģenerēts minējums par dokumenta statusu nedrīkst kļūt par filtru, kas nosaka nākamo atbildi.

Arī atjaunināšana ir daļa no produkta, nevis vienreizējs importa darbs: jāzina, cik ātri apstiprināta izmaiņa nonāk indeksā, kā tiek dzēsts atsaukts fragments, kas notiek ar mainītu faila adresi un vai kļūmes gadījumā sistēma turpina rādīt veco versiju. Microsoft indeksa vadlīnijas nošķir papildinošus atjauninājumus no pārindeksēšanas, tāpēc katram avotam vajadzīga dokumentēta sinhronizācijas un kļūdu kontroles metode; pirms RAG projekta ir vērts sakārtot vienu autoritatīvu dokumentu plūsmu; citādi ātra izgūšana tikai paātrina neskaidras pārvaldības sekas.

Pirms pirmās indeksēšanas noder dokumentu gatavības izlase: izvēlas dažādus failu tipus, vecumu, valodas, tabulas, skenējumus un piekļuves klases, pēc tam katram pārbauda izvilkto tekstu, fragmentu robežas, metadatus un avota saiti. Kļūdu īpatsvars nav jāpārvērš vienā vidējā skaitlī, jo viena pazaudēta komata cena instrukcijā un viena pazaudēta summa līgumā atšķiras. Izlase dod pamatu izlemt, kurus formātus pieņemt automātiski, kuriem vajag cilvēka pārbaudi un kurus pagaidām neindeksēt; šis darbs bieži dod lielāku kvalitātes pieaugumu nekā cita valodas modeļa izvēle.

Piekļuves tiesības, privātums un izvietošanas izvēle

Droša arhitektūra sākas ar identitāti: kurš jautā, kurai organizācijai un nodaļai viņš pieder, kādas dokumentu klases drīkst redzēt un vai šīs tiesības tiek pārbaudītas katrā izgūšanas pieprasījumā. Atļauju filtram jādarbojas pirms fragmenti nonāk modeļa kontekstā, bet žurnālos jāizvairās no nevajadzīgas pilnu jautājumu, atbilžu un sensitīvu fragmentu kopēšanas; jātestē arī robežgadījumi — darbinieks maina lomu, dokuments kļūst ierobežots, piekļuve tiek atsaukta vai viens klients mēģina atrast otra klienta saturu; “čats prasa ielogoties” nav pietiekams akceptēšanas kritērijs.

Jautājumam “vai mani dati nonāks modeļa apmācībā?” nav godīgas universālas atbildes bez piegādātāja, produkta, konta un iestatījumu nosaukšanas. OpenAI biznesa un API materiāli paredz, ka attiecīgo biznesa produktu dati pēc noklusējuma netiek izmantoti modeļu apmācībai, savukārt API datu kontroles dokumentācija atsevišķi apraksta glabāšanu, ļaunprātīgas izmantošanas uzraudzību un galapunktu izņēmumus; Anthropic arī nošķir komerciālo produktu apstrādi, apzinātu piekrišanu uzlabošanai un glabāšanas nosacījumus. Tādēļ līgumā un tehniskajā projektā pārbauda konkrēto pakalpojumu, nevis paļaujas uz frāzi “biznesa API”.

Izvietošana ES reģionā vai savā infrastruktūrā var palīdzēt izpildīt noteiktas datu atrašanās, kontroles vai integrācijas prasības, taču tā pati par sevi nepierāda VDAR atbilstību vai drošību. Joprojām jānosaka apstrādes nolūks un tiesiskais pamats, datu minimizēšana, glabāšanas termiņi, apakšapstrādātāji, dzēšana, incidentu process un piekļuves audits; VDAR principi attiecas uz visu ķēdi, ne tikai modeļa servera valsti. Dažkārt pareizais lēmums ir noteiktu dokumentu RAG vispār neiekļaut vai pirms indeksēšanas noņemt laukus, kas atbildei nav vajadzīgi.

Draudu modelī jāpārbauda ne tikai ziņkārīgs darbinieks, bet arī kļūdaina grupu sinhronizācija, koplietota saite, administratora loma, saglabāts kešs un dokuments ar ļaunprātīgu instrukciju; testa lietotājiem jāaptver katra loma un aizliegta lomu kombinācija, mēģinot jautāt tieši, ar sinonīmiem un netiešu apkopošanas lūgumu; rezultātā nedrīkst parādīties ne fragments, ne dokumenta nosaukums, ne atbildē izsecināma slepena detaļa; pēc tiesību maiņas testu atkārto, jo vakardienas drošais filtrs var palikt kešā. Šīs pārbaudes ir akceptēšanas kritēriji, nevis vēlāka drošības audita dekorācija.

Kā mērīt izgūšanu, balstījumu avotos un pareizību

Viena “precizitāte” RAG sistēmai ir līdzīga vienam vidējam vērtējumam slimnīcai: skaitlis var izskatīties labs, kamēr kritiska kļūdu klase paliek neredzama. Vispirms atsevišķi mēra izgūšanu — vai nepieciešamais fragments parādījās noteiktā augstāko rezultātu skaitā un vai nevajadzīgi fragmenti to neizspieda. Tad mēra konteksta atbilstību jautājumam, atbildes balstījumu dotajos fragmentos, faktisko pareizību pret apstiprinātu etalonu, katras avota norādes atbilstību konkrētajam apgalvojumam un sistēmas spēju atturēties no atbildes, kad avota nav vai avoti konfliktē.

Microsoft RAG vērtētāju dokumentācija šīs dimensijas sadala, un ARES pētnieciskais darbs līdzīgi nošķir konteksta atbilstību, atbildes balstījumu un atbildes atbilstību. Praktiskajā testu kopā katram reālam jautājumam tāpēc vajag ne tikai “pareizo atbildi”, bet arī obligāto avotu, pieļaujamos formulējumus, aizliegtus apgalvojumus, lomu, dokumenta versiju un gaidīto rīcību situācijā bez pietiekamiem pierādījumiem. Daļu piemēru veido no biežiem jautājumiem, daļu — no dārgiem izņēmumiem un apzinātiem slazdiem.

Akceptēšanas slieksnis jānosaka katrai dimensijai un riska klasei pirms rezultātu redzēšanas, citādi komanda pēc demonstrācijas izvēlēsies to rādītāju, kurš izskatās vislabāk. Pilota mērījumiem jāsaglabā arī kļūdu sadalījums pa dokumentu tipiem, nodaļām, valodām un jautājuma veidiem, jo kopējais vidējais var paslēpt, ka rokasgrāmatas strādā labi, bet līgumu tabulas — slikti. Automātisks modeļa vērtētājs palīdz mērogot pārbaudi, taču izlase jāpārskata cilvēkam un kritiskās atbildes jāsalīdzina ar autoritatīvu avotu, nevis ar otra modeļa pārliecību.

Pēc palaišanas jāmēra tās pašas dimensijas, taču ar kontrolētu produkcijas izlasi un privātumu saudzējošiem žurnāliem, savukārt izmaiņa dokumentu korpusā, fragmentēšanas algoritmā, vektoru modelī, pārrindošanā vai ģenerējošā modelī var uzlabot vienu jautājumu grupu un pasliktināt citu, tāpēc katrai versijai vajag regresijas testu un salīdzināmu bāzes līniju ar nemainītiem vērtēšanas noteikumiem visai testa kopai. Brīdinājums jāizraisa ne tikai kopējā rādītāja kritumam, bet arī kritiskas kļūdas parādīšanās gadījumam, piemēram, neatļautam fragmentam vai izdomātai atbildei tur, kur sagaidīta atturēšanās.

RAG, meklēšana, garš konteksts, modeļa pielāgošana un aģenti

Parasta pilnteksta meklēšana ir labāka, ja lietotājs zina precīzu nosaukumu, kodu vai frāzi un viņam vajag dokumentu, nevis sastādītu atbildi; tā ir lētāka, paredzamāka un vieglāk auditējama. Semantiska meklēšana palīdz ar sinonīmiem un neskaidriem jautājumiem, bet ģenerēšanu var pievienot tikai tur, kur kopsavilkums dod reālu vērtību; RAG nav obligāts katram uzņēmuma meklētājam: dažkārt pareizais produkts ir laba meklēšanas lapa ar filtriem, fragmenta priekšskatījumu un versijas statusu, jo lietotājs pats pieņem secinājumu no pilna dokumenta.

Visa dokumenta ievietošana garā konteksta logā var būt vienkārša nelielam, stabilam materiālam, taču lielā korpusā palielinās izmaksas, troksnis un risks, ka būtiska rindkopa pazūd starp mazsvarīgu saturu. Modeļa papildu pielāgošana jeb fine-tuning savukārt var nostiprināt formātu, stilu vai konkrētu uzdevuma uzvedību, bet nav ērts veids bieži maināmu cenu, politiku un instrukciju glabāšanai, jo avota atjaunināšana un citēšana kļūst mazāk caurskatāma. RAG ļauj mainīt dokumentu kopu neatkarīgi no modeļa svaru apmācības, tomēr par šo elastību jāmaksā ar indeksa, versiju un izgūšanas kvalitātes pārvaldību.

Automatizācija izpilda iepriekš definētus soļus, bet AI aģents var izvēlēties rīku un nākamo soli, tādēļ tā brīvība prasa stingrākas pilnvaru, validācijas un apturēšanas robežas; RAG var dot aģentam informāciju, bet ne tiesības: ja modelis atrod atvaļinājumu politiku, tas vēl nedrīkst pats apstiprināt prombūtni vai mainīt algu sistēmu; strukturēts funkcijas izsaukums ir tikai priekšlikums lietojumprogrammai, kura pārbauda shēmu, identitāti, atļauto darbību, summas vai citus limitus un vajadzīgo cilvēka apstiprinājumu. Tehnoloģiju salīdzinājums sākas ar procesa risku, nevis ar vēlmi lietot modernāko nosaukumu.

Izvēli var formulēt kā vienkāršu pārbaudi: ja vajadzīgs atrast un atvērt failu, sāk ar meklēšanu; ja jāapkopo daži mainīgi avoti ar norādēm, vērtē RAG; ja jāievēro stabils formāts vai klasifikācijas uzvedība, iespējama modeļa pielāgošana; ja jāizpilda paredzama darbību secība, būvē automatizāciju; aģentu pievieno tikai tad, ja nākamā soļa izvēli nevar droši ieprogrammēt un ieguvums atsver papildu risku. Šīs pieejas var kombinēt, tomēr katram slānim jābūt savam uzdevumam, mērījumam un apturēšanas robežai, citādi kļūdas cēlonis pazūd aiz vārda “AI”.

Kā izveidot ierobežotu pilotu ar īstiem jautājumiem

Pilots sākas ar vienu dokumentu kopu, vienu lietotāju grupu un vienu lēmuma robežu, piemēram, tehniskā atbalsta rokasgrāmatām, kur sistēma tikai atrod avotus un sagatavo atbildes melnrakstu. Pirms izstrādes komanda savāc reālus jautājumus no meklēšanas žurnāliem, e-pastiem un darbinieku intervijām, pievieno pareizos avotus un apzināti iekļauj neatbildamus, novecojušus, pretrunīgus un neatļautus gadījumus. Katram gadījumam nosaka, kas skaitās pieņemams: nepieciešamais fragments ir atrasts, apgalvojums ir balstīts avotā, citāts ved uz pareizo vietu, atbilde ir faktiski pareiza un sistēma droši neizdomā trūkstošo.

Sliekšņus fiksē pirms demonstrācijas un sadala pēc riska: biežam informatīvam jautājumam var pieļaut labojamu melnrakstu, bet personas datu, līguma, drošības vai maksājuma jautājumam vajadzīga stingrāka pārbaude un cilvēka apstiprinājums. Pilotā mēra arī atbildes laiku, izmaksas uz pieprasījumu, piekļuves filtru darbību, indeksa atjaunināšanas aizkavi un to, cik bieži darbinieks atver avotu vai labo atbildi. Ja sistēma uzlabo tikai demonstrācijas piemērus, bet netur iepriekš noslēptu testa kopu, nav pierādīts produkta rezultāts; ir pierādīts, ka komanda prot sagatavot demonstrāciju.

Mūsu AI risinājumu izstrāde ir sākot no €3 500 un parasti aizņem 3–8 nedēļas, savukārt strādājošu pilotu uz Jūsu pašu datiem var piegādāt 2–3 nedēļās; šie skaitļi apraksta pakalpojuma sākuma cenu un vispārējo grafiku, nevis nezināma tvēruma fiksētu piedāvājumu. Pilota beigās jābūt ne tikai čata logam, bet versētam dokumentu korpusam, testa jautājumiem, atsevišķiem kvalitātes mērījumiem, kļūdu žurnālam, piekļuves pārbaudēm un lēmumam, ko risinājums nedrīkst darīt. Vēlākas integrācijas prasības ir vērts fiksēt tikpat skaidri kā citā digitālā projektā, ievērojot rakstā par 10 kļūdām mājaslapas izstrādes pasūtīšanā aprakstīto principu: akceptēšanas kritēriji un īpašnieki jānosaka pirms pilnas ieviešanas, nevis pēc pirmā iespaidīgā ekrāna.

Pilotu turpina tikai tad, ja tas sasniedz iepriekš noteiktos sliekšņus uz neredzētas testa daļas, droši apstrādā neatļautus un neatbildamus jautājumus un dod izmērāmu ieguvumu cilvēka darbā. Ja izgūšana sistemātiski neatrod pareizo avotu, vispirms labo dokumentus, metadatus un indeksu; ja avots ir pareizs, bet ģenerēšana to sagroza, maina kontekstu, uzvedni vai modeli; ja kļūda rodas tikai augsta riska lēmumos, šos lēmumus atstāj determinētai sistēmai un cilvēkam. Apturēts pilots nav neveiksme — tas ir lētā veidā iegūts pierādījums, ka konkrētajam procesam RAG robežas ir svarīgākas par tā demonstrācijas efektu.