RAG sistēmas kvalitāti nevar godīgi izteikt ar vienu “pareizo atbilžu procentu”. Jāmēra vismaz trīs atsevišķi posmi: vai sistēma atrada vajadzīgo informāciju, vai norādītie avoti patiešām pamato apgalvojumus un vai gala atbilde ir pareiza, pilnīga un atbilstoši piesardzīga. Ražošanas vidē tiem jāpievieno piekļuves kontrole, latentums, izmaksas un lietotāja uzdevuma izpilde.
Šāds dalījums nav tikai analītiķu ērtībai. Ja pareizais dokuments netika atrasts, modeļa vai sistēmas uzvednes maiņa problēmu neatrisinās. Ja vajadzīgais fragments bija kontekstā, bet atbilde to sagrozīja, jāstrādā ar ģenerēšanas posmu. Savukārt tekoša atbilde ar nepareizu citātu ir atsevišķa kļūda, pat ja secinājums nejauši izrādījies pareizs.
Ko tieši vērtē RAG sistēmā
RAG jeb retrieval-augmented generation savieno valodas modeli ar ārēju zināšanu avotu. Pirms atbildes sistēma atrod vaicājumam atbilstošus dokumentus vai to fragmentus, ievieto atlasīto kontekstu modeļa pieprasījumā un ģenerē atbildi. Šī pieeja ļauj izmantot aktualizējamu ārēju atmiņu un saglabāt informācijas izcelsmi — tie bija arī vieni no sākotnējās RAG pieejas motīviem.
Praksē kvalitātes ķēdē ir vairāk par diviem tehniskiem moduļiem:
dokumentu uzņemšana, sadalīšana fragmentos un metadatu saglabāšana;
vaicājuma apstrāde, meklēšana un rezultātu pārkārtošana;
konteksta komplektēšana modeļa logā;
atbildes ģenerēšana;
apgalvojumu sasaistīšana ar citātiem;
piekļuves noteikumu, drošības un lietotāja darba rezultāta pārbaude.
RAGAS pētnieki arī uzsver, ka jānodala izguves spēja atrast fokusētu kontekstu, modeļa spēja to izmantot uzticami un pašas ģenerētās atbildes kvalitāte. Tieši šis princips palīdz izvairīties no situācijas, kur vidējais vērtējums izskatās labs, bet nav zināms, kur sistēma kļūdās.
Sāciet ar reprezentatīvu etalona datu kopu
Bez etalona jautājumiem RAG kvalitāti var vērtēt tikai pēc sajūtām. Labs sākums ir ekspertu pārbaudīta kopa, kurā katram gadījumam ir vismaz:
lietotāja jautājums tādā valodā un formā, kādā tas rodas darbā;
pieņemama atbilde vai galvenie fakti, kuri atbildē jāiekļauj;
nepieciešamie dokumenti un, vēlams, konkrēti fragmenti;
avoti, kurus izmantot nedrīkst, piemēram, novecojusi politikas versija;
pazīme, vai uz jautājumu vispār iespējams atbildēt no zināšanu bāzes;
lietotāja loma un piekļuves līmenis;
riska kategorija un atbildes kļūdas iespējamās sekas.
Kopā jābūt ne tikai biežākajiem “laimīgā ceļa” jautājumiem. Iekļaujiet retus terminus, saīsinājumus, drukas kļūdas, pārfrāzējumus, vairākus nodomus vienā pieprasījumā, jautājumus, kuriem vajadzīgi vairāki avoti, pretrunīgus dokumentus un gadījumus bez atbildes. Daudzvalodu sistēmai viens un tas pats nodoms jāpārbauda latviešu, angļu un citās reāli lietotajās valodās.
Atsevišķi nepieciešami drošības gadījumi: neatļauta dokumenta pieprasīšana, personas datu mēģinājumi, ļaunprātīgas instrukcijas dokumentos un jautājumi, kuros modelim jānodod lieta cilvēkam. OpenAI eval vadlīnijas iesaka testu kopā apvienot tipiskus gadījumus, robežgadījumus un uzbrukuma scenārijus, izmantot ekspertu marķējumu un laika gaitā papildināt kopu ar ražošanā atrastām kļūdām.
Etalona kopa nav vienreiz sagatavots eksāmens. Tā ir produkta kvalitātes specifikācija. Ja sistēma sāk apstrādāt jaunu dokumentu avotu, lietotāju grupu vai procesu, kopai jāpievieno šo izmaiņu riski.
Dokumentu atrašanas kvalitāte
Izguves vērtēšanas pamatjautājums ir vienkāršs: vai modeļa rīcībā nonāca pierādījumi, kas vajadzīgi pareizai atbildei? To vajag mērīt dokumenta un fragmenta līmenī. Pareizs fails ar nepareizu nodaļu var būt nederīgs konteksts.
Precision@k: cik tīri ir pirmie rezultāti
Precision@k rāda, kāda daļa no pirmajiem k atrastajiem fragmentiem ir atbilstoša jautājumam. Ja no pirmajiem pieciem fragmentiem tikai divi palīdz atbildēt, Precision@5 ir 0,4.
Zema precizitāte nozīmē, ka modelis saņem troksni. Tas palielina izmaksas, aizņem konteksta logu un rada iespēju, ka atbildē uzvarēs līdzīgs, bet nepareizs fragments. Ragas konteksta precizitātes apraksts papildus vērtē arī secību: noderīgajiem fragmentiem jāatrodas augstāk par nederīgajiem.
Recall@k: vai nav pazaudēts nepieciešamais
Recall@k jeb izguves pilnīgums rāda, cik daudz no visiem etalonā atzīmētajiem nepieciešamajiem fragmentiem nonāca pirmajos k rezultātos. Ja atbildei vajadzīga pamatpolitika un izņēmumu tabula, bet sistēma atrod tikai politiku, precizitāte var šķist laba, taču pilnīgums būs nepietiekams. Ragas konteksta pilnīguma metrika tieši pārbauda, cik no atsauces atbildes apgalvojumiem var pamatot ar izgūto kontekstu.
MRR un nDCG: vai labākais avots ir pietiekami augstu
MRR jeb mean reciprocal rank ir noderīgs, ja jautājumam parasti vajadzīgs viens galvenais avots. Tas augstu novērtē sistēmu, kur pirmais atbilstošais rezultāts parādās jau pirmajā pozīcijā, un strauji samazina vērtējumu, ja tas atrodas zemāk.
nDCG ir piemērotāks, ja fragmentiem ir dažāda nozīmīguma pakāpe. Aktuālā procedūra var būt pilnībā atbilstoša, skaidrojoša prezentācija — daļēji atbilstoša, bet veca procedūras versija — maldinoša. Metrika ņem vērā gan šo gradāciju, gan vietu rezultātu sarakstā.
Neviena no šīm metrikām viena pati nepasaka, vai sistēma spēs atbildēt. Vērtējiet tās pa jautājumu tipiem, avotu sistēmām, valodām un lietotāju lomām. Vidējais Recall@k var noslēpt, ka finanšu politika tiek atrasta gandrīz vienmēr, bet latviešu valodas personāla jautājumi — reti.
Avotu un citātu precizitāte
Atrasts avots vēl nav pareizi izmantots avots. Citātu kvalitātei vajag vismaz četras atsevišķas pārbaudes.
Apgalvojuma atbalsts. Vai citētais fragments tiešām apstiprina tieši blakus esošo apgalvojumu? Atslēgvārdu sakritība nav pietiekama. Fragmentā jābūt vajadzīgajam nosacījumam, skaitlim, izņēmumam vai secinājumam.
Citātu pilnīgums. Kāda daļa no pārbaudāmajiem atbildes apgalvojumiem ir pamatota ar avotu? Viena atsauce rindkopas beigās nedrīkst radīt iespaidu, ka tā sedz piecus dažādus faktus, ja avots pamato tikai vienu.
Avota autoritāte un aktualitāte. Vai izmantota apstiprinātā procedūras versija, nevis vecs pielikums, prezentācija vai dublikāts? Jāsaglabā dokumenta īpašnieks, versija, spēkā stāšanās datums un statuss. Ja avoti konfliktē, sistēmai vajag skaidru prioritātes noteikumu vai jāatzīst neskaidrība.
Piekļuves korektums. Pareiza atbilde no dokumenta, kuru konkrētais lietotājs nedrīkstēja saņemt, ir nopietna neveiksme. Tādēļ drošības testā jāpārbauda ne tikai parādītais citāts, bet arī visi izguves rezultāti un starpposmu konteksts. Dokumenta atļaujām jāsaglabājas visā ķēdē.
Praktiska citātu precizitātes pārbaude notiek apgalvojumu līmenī. Atbildi sadala pārbaudāmos apgalvojumos, katram atrod norādīto fragmentu un marķē: “pilnībā atbalsta”, “atbalsta daļēji”, “neatbalsta” vai “avots nav pieejams”. Augsta riska jomās daļa izlases jāpārbauda nozares ekspertam, nevis tikai citam modelim.
Atbildes uzticamība nav tas pats, kas pamatotība
Atbilde var būt pilnībā balstīta kontekstā un tomēr nepareiza, ja konteksts ir novecojis. Tā var būt faktoloģiski pareiza, bet nepamatota, ja modelis izmanto savas iepriekšējās zināšanas, nevis uzņēmuma avotus. Tāpēc gala atbildei nepieciešama vairāku kritēriju kartīte:
pareizība — vai secinājumi sakrīt ar etalonu un domēna noteikumiem;
pamatotība — vai katru faktisko apgalvojumu var izsecināt no atļautā konteksta;
pilnīgums — vai nav izlaists lēmumam svarīgs nosacījums vai izņēmums;
atbilstība — vai atbilde tieši risina lietotāja jautājumu bez lieka satura;
instrukciju ievērošana — vai ievērots formāts, tonis, darbības robežas un eskalācijas noteikumi;
kalibrēta atteikšanās — vai sistēma pasaka “informācijas nepietiek”, kad pierādījumu nav, un neatkāpjas no atbildes, kad tie ir pietiekami.
Microsoft savā RAG vērtētāju dokumentācijā līdzīgi nošķir procesa vērtēšanu — izguvi un dokumentu izguvi — no sistēmas vērtēšanas, kur mēra pamatotību, atbilstību un atbildes pilnīgumu. Tas ir labs modelis arī tad, ja netiek izmantots konkrētais Microsoft rīks.
Īpaši svarīgi ir nošķirt atbildamus un neatbildamus jautājumus. Atbildamiem gadījumiem mēra pareizību un pilnīgumu. Neatbildamiem — cik bieži sistēma droši atturas no minējuma. Kļūdaini pārliecinoša atbilde par neesošu politiku biznesam parasti ir bīstamāka nekā korekts atteikums.
Automatizēts vērtētājs nav galīgā patiesība
Daļu pārbaužu var aprēķināt deterministiski: dokumentu identifikatoru sakritību, versiju, atļauju filtru, latentumu, izmaksas un precīzu lauku vērtības. Sarežģītākām valodas īpašībām var izmantot LLM kā vērtētāju, taču tam vajag konkrētu rubriku un piemērus katram vērtējuma līmenim.
LLM vērtētājiem ir savi aizspriedumi. Tie var dot priekšroku garākai atbildei, citam formulējumam vai vienai atbilžu secībai. Tāpēc vispirms izveidojiet cilvēku marķētu kontroles izlasi un izmēriet vērtētāja sakritību ar ekspertiem. OpenAI vadlīnijas iesaka salīdzināšanu pa pāriem vai skaidru “iztur/neiztur” kritēriju, detalizētu rubriku un automatizētā vērtētāja kalibrēšanu pret cilvēku vērtējumiem.
Labs sadalījums parasti ir šāds: liela apjoma regresijas testus veic automātiski, robežgadījumus un augsta riska kļūdas pārskata cilvēks, bet nesakritības starp abiem kļūst par jauniem testa gadījumiem.
No bezsaistes testa līdz ražošanas uzraudzībai
Pirms palaišanas veiciet bezsaistes testu ar fiksētu datu kopu un saglabājiet bāzes rezultātu katram ķēdes posmam. To atkārto pēc izmaiņām dokumentu sadalīšanā, iegultņu modelī, meklēšanas filtros, rerankerī, uzvednē, valodas modelī vai piekļuves loģikā. Salīdziniet ne tikai kopējo vidējo, bet arī sliktākos segmentus un kritiskos gadījumus.
Ražošanā etalona atbildes nav pieejamas katram pieprasījumam, tādēļ izmanto signālu kopumu:
bezatbildes un atteikšanās īpatsvaru;
atkārtotus pārfrāzētus jautājumus vienas sesijas laikā;
lietotāja labojumus un nodošanu cilvēkam;
problemātisku citātu atvēršanu vai ziņošanu;
uzdevuma pabeigšanu, ne tikai atbildes saņemšanu;
izguves, modeļa un kopējo latentumu;
izmaksas uz veiksmīgi pabeigtu uzdevumu;
neatļautas izguves mēģinājumus un drošības incidentus.
“Patīk” vērtējums nav patiesības marķējums. Lietotājam var patikt ātra un pārliecinoša, bet nepareiza atbilde. Savukārt precīzs brīdinājums var saņemt zemu vērtējumu, jo tas neapstiprina vēlamo rezultātu. Produkta signāli jāsaista ar ekspertu auditētu izlasi.
NIST ģeneratīvā MI riska profilā vērtēšana tiek skatīta kā daļa no uzticamības pārvaldības visā MI dzīves ciklā. RAG gadījumā tas nozīmē nepārtrauktu uzraudzību, jo mainās ne tikai modelis, bet arī dokumenti, to versijas, piekļuves un lietotāju jautājumi.
Kļūdu matrica: ko labot pēc slikta rezultāta
| Novērojums | Iespējamā problēmas vieta | Pirmais pārbaudes solis |
|---|---|---|
| Pareizā informācija nav zināšanu bāzē | Datu uzņemšana vai pārvaldība | Pārbaudīt avota pārklājumu, statusu un indeksēšanas žurnālu |
| Avots ir bāzē, bet netiek atrasts | Vaicājums, iegultņi, filtri vai sadalījums fragmentos | Palaist izguvi bez ģenerēšanas un apskatīt pirmos rezultātus |
| Vajadzīgais fragments atrasts, bet neiekļūst kontekstā | Rerankeris, dublikāti vai konteksta limits | Saglabāt faktisko modelim nosūtīto kontekstu |
| Konteksts ir pareizs, atbilde kļūdaina | Uzvedne, modelis vai ģenerēšanas noteikumi | Vērtēt apgalvojumus pret iesaldētu kontekstu |
| Atbilde pareiza, citāts nepareizs | Citātu kartēšana vai pēcapstrāde | Pārbaudīt apgalvojuma un fragmenta identifikatoru saiti |
| Atbilde pareiza, bet avots neatļauts | Piekļuves kontrole | Testēt lietotāja lomu pirms izguves un pēc tās |
Šī matrica pasargā no dārgas, bet neefektīvas rīcības. Modeļa nomaiņa neizlabos trūkstošus dokumentus, bet jauna vektoru datubāze nepalīdzēs, ja modelis ignorē jau atrasto izņēmumu.
Praktisks piemērs
Pieņemsim, ka iekšējais asistents saņem jautājumu: “Vai pārdošanas vadītājs drīkst apstiprināt pats savus 850 eiro komandējuma izdevumus?” Pareizai atbildei var būt vajadzīga aktuālā izdevumu politika, apstiprināšanas matrica un pašapstiprināšanas aizlieguma punkts.
Izguves tests pārbauda, vai visi nepieciešamie fragmenti ir pirmajos rezultātos un vai vecā politikas versija nav novietota augstāk. Citātu tests pārbauda, vai katrs secinājums sasaistīts ar pareizo punktu. Atbildes tests vērtē, vai sistēma dod pareizo secinājumu, norāda nepieciešamo apstiprinātāju un nemin neesošu izņēmumu. Drošības tests atkārto jautājumu ar lietotāju, kuram nav pieejas apstiprināšanas matricai; šajā gadījumā sistēmai jāievēro piekļuve, nevis jādod “pareiza” konfidenciāla atbilde.
Viens jautājums tādējādi rada vairākus neatkarīgus testus. Tieši tas ļauj redzēt, vai uzlabojums vienā slānī nav sabojājis citu.
Kā noteikt palaišanas slieksni
Universāls RAG kvalitātes slieksnis neeksistē. Iekšējam dokumentu meklētājam un asistentam, kas iesaka rīcību finanšu vai personāla procesā, kļūdas cena atšķiras. Definējiet sliekšņus pa riska kategorijām, nevis vienu vidējo visai sistēmai.
Pirms palaišanas vajadzīgs vismaz:
atsevišķs minimālais slieksnis izguves pilnīgumam, citātu atbalstam un atbildes pareizībai;
nulles tolerance pret zināmiem piekļuves pārkāpumiem;
obligāta pareiza atteikšanās kritiskajos neatbildamajos gadījumos;
regresijas aizliegums augsta riska testa segmentos;
pieņemams latentums un izmaksas pie paredzamās slodzes;
īpašnieks incidentiem, dokumentu aktualitātei un testa kopas uzturēšanai.
Sākumā nevajag tūkstošiem gadījumu. Daži desmiti rūpīgi izvēlētu jautājumu katram svarīgajam procesam dos vairāk informācijas nekā liela sintētiska kopa bez ekspertu pārbaudes. Pēc tam testu kopu audzē no reāliem incidentiem, lietotāju pārfrāzējumiem un jaunām dokumentu versijām.
Secinājums
Uzticama RAG sistēma nav tā, kas vienkārši raksta pārliecinoši. Tā atrod vajadzīgos pierādījumus, neielaiž kontekstā neatļautus vai novecojušus avotus, sasaista apgalvojumus ar pareizajiem fragmentiem un prot atteikties, ja atbilde nav pamatota.
Tāpēc kvalitātes programmai jāatbild uz trim jautājumiem atsevišķi: ko sistēma atrada, ko avoti patiešām pierāda un ko atbilde apgalvo. Kad šie slāņi tiek mērīti ar reprezentatīvu etalona kopu, regresijas testiem un ražošanas uzraudzību, RAG kļūst no iespaidīgas demonstrācijas par kontrolējamu biznesa procesu. Tas ir īpaši svarīgi, ja MI asistents ir daļa no uzņēmuma procesu automatizācijas un tā atbilde ietekmē reālu lēmumu.