Kaip vertinti DI agentus: testų rinkiniai, vertintojai ir regresijos patikros

Už kiekvieno puikaus DI produkto slypi patikimas DI agento vertinimo procesas, vadinamas evals, kuris anksti aptinka klaidas ir užtikrina tinkamą agento veikimą. Vertinimai ypač svarbūs DI agentams, kurie kieno nors vardu atlieka didelės rizikos veiksmus, pavyzdžiui, grąžina pinigus.

Tokiam procesui sukurti reikia tam tikrų techninių žinių ir duomenų analizės įgūdžių. Tačiau tai toli gražu nėra taip baisu ar sudėtinga, kaip gali pasirodyti. Kad būtų lengviau pradėti, aprašėme šešis praktinius DI agentų vertinimo žingsnius ir dažniausius klaidingus įsitikinimus, kurie sugriauna šį procesą.

Ką reiškia įvertinti DI agentą?

Įvertinti DI agentą reiškia nustatyti, kaip tinkamai jis atlieka užduotis ir ar jo sprendimai atitinka organizacijos reikalavimus. Praktiškai DI agentų vertinimai, arba evals, yra konkretūs rodikliai, padedantys organizacijoms nustatyti, ar agentas veikia pakankamai patikimai, kad atliktų jam numatytą vaidmenį.

Įsivaizduokite DI pirkimų agentą gamykloje, kuris tikrina atsarginių dalių atsargas ir rengia papildymo užklausas. Jei patvirtintos dalies nėra arba tiekėjo informacija pasenusi, ar agentas praneš apie problemą, ar pasiūlys nepatvirtintą pakaitalą?

O jei pakeisite jo sistemos raginimą, kad išspręstumėte šią problemą, kaip žinosite, kad nesukūrėte kitos?

Neturėdami vertinimo, produktų vadovai iš esmės gali tik spėlioti. Todėl vertinimai suteikia grįžtamojo ryšio signalą, leidžiantį matuoti veikimą, pastebėti pasikartojančias problemas ir su didesniu pasitikėjimu testuoti pakeitimus.

Vis dėlto agento vertinimas gali apimti kelis vykdymo aspektus:

• Galutinio rezultato kokybė
• Informacija, kurią naudojo agentas
• Įrankiai, kuriuos jis iškvietė
• Ar jis laikėsi taisyklių, reglamentuojančių jo elgseną

Dažniausi DI agentų vertinimo rodikliai

Vertinimai remiasi kokybiniais ir kiekybiniais duomenimis. Kokybinis vertinimas padeda suprasti, kas vyksta ir kodėl, įskaitant rankinę agento sprendimų peržiūrą. Kiekybinis vertinimas šiuos pastebėjimus paverčia išmatuojamais signalais, pavyzdžiui, skaičiuojant, kaip dažnai pasitaiko konkretūs klaidų tipai, arba apskaičiuojant užduočių sėkmės rodiklius.

Štai pagrindinių DI agentų vertinimo rodiklių sąrašas:

• Užduoties sėkmė parodo, ar agentas pasiekė numatytą rezultatą; paprastai matuojama kaip vykdymų, kurių rezultatai tinkami, procentinė dalis.
• Veiksmų teisingumas parodo, ar agentas tinkamai naudojo įrankius, pasirinko tinkamus argumentus ir laikėsi leidimų.
• Atsakymo kokybė įvertina, ar galutinis rezultatas tikslus, išsamus ir naudingas. Ji gali apimti faktinį teisingumą, instrukcijų laikymąsi ir tai, ar agentas pagrindžia savo sprendimus turima informacija.
• Patikimumas parodo nuoseklumą atliekant pakartotinius bandymus, esant skirtingiems įvesties duomenims ir kraštutiniais atvejais.
• Kaina ir delsa parodo, kiek išteklių reikia sėkmingam rezultatui pasiekti, įskaitant vykdymo laiką, žetonų sąnaudas ir įrankių iškvietimus.

Priklausomai nuo to, ką matuojate, vertinimais galima tikrinti visą agento veikimą nuo pradžios iki pabaigos, jo vykdymo trajektoriją arba atskirus komponentus, pavyzdžiui, įrankių iškvietimus ir informacijos paieškos žingsnius.

1 žingsnis: nuspręskite, kaip atrodo sėkmingas agento vykdymas

Pirmiausia aiškiai aprašykite, ką agentas turi atlikti, – t. y. produkto reikalavimus. Skamba savaime suprantamai, tačiau tai gali būti stebėtinai sunku. Šis reiškinys netgi turi pavadinimą: specifikacijos spraga.

Štai kaip rekomenduoja tai daryti mūsų vyresnysis duomenų mokslininkas Andrey Khomutov:

„Pradėkite nuo dviejų klausimų: „Kas būtų laikoma darbo atlikimu?“ ir „Dėl ko iš pažiūros sėkmingas vykdymas taptų nepriimtinas?“

Agentų atveju techniniu požiūriu tai reiškia, kad reikia tikrinti ir rezultatą, ir tai, kaip agentai jį pasiekė.“

Agentas gali pateikti teisingą atsakymą pasinaudojęs nutekėjusiu atsakymų raktu arba atlikdamas užduotį imtis neleistinų veiksmų. Khomutov pabrėžia, kad atsakymų nutekėjimas ir nesaugūs veiksmai vertinimų metu yra konkrečios priežastys nevertinti vien galutinio atsakymo.

„Tikiuosi, kad trajektorijos patikra taps standartine agentų vertinimo rinkinių dalimi, o ne tuo, ką darome tik tada, kai rezultatas atrodo įtartinas“, – priduria jis.

Tada pasitelkite srities ekspertą, kad jis patvirtintų jūsų sėkmės kriterijus. Žmonės, turintys praktinių šios srities žinių, gali pasakyti, ar sąlygos, kurias nustatėme DI agentui, atspindi sėkmingą rezultatą.

2 žingsnis. Sudarykite testų rinkinį iš realių užduočių ir klaidų

Išnagrinėkite tikrąjį agento elgesį, kad suprastumėte, kaip atrodo geras ir prastas veikimas. Atsispirkite pagundai pradėti nuo dešimčių testų, sukurtų vien remiantis tuo, kas, jūsų manymu, gali nepavykti.

Hamel Husain, Parlance Lab mašininio mokymosi inžinierius, ir Shreya Shankar, mašininio mokymosi sistemų ir taikomojo DI vertinimų tyrėja, rekomenduoja pradėti nuo klaidų analizės – metodo, perimto iš mašininio mokymosi ir duomenų mokslo. Procesas prasideda kokybine agento vykdymo pėdsakų analize – tai įrašai, kuriuose matyti naudotojo įvestis, įrankių iškvietimai, gauta informacija ir agento atsakymas.

1. Peržiūrėkite atskirus pėdsakus ir anotuokite klaidas (atvirasis kodavimas). Paprašykite srities eksperto peržiūrėti agento vykdymus ir trumpai aprašyti, kas nepavyko. Sutelkite dėmesį į pirmąją reikšmingą klaidą.
2. Sugrupuokite pastebėjimus pagal klaidų tipus (ašinis kodavimas). Kai turėsite pakankamai užrašų, pasitelkite LLM, kad šis pasiūlytų panašių klaidų kategorijas. Tai gali būti nesuderinamų dalių rekomendacijos, netiksli atsargų informacijos paieška ir nepavykę perdavimai žmogui.
3. Suskaičiuokite atvejus. Priskirkite kiekvieną pastebėjimą kategorijai, tada naudodami skaičiuoklę arba suvestinę lentelę apskaičiuokite, kaip dažnai pasitaiko kiekvienas klaidų tipas.
4. Nustatykite, ką spręsti pirmiausia, atsižvelgdami ir į dažnumą, ir į rimtumą.
5. Svarbias klaidas paverskite testavimo atvejais. Išsaugokite atitinkamą įvestį, pradines sąlygas, laukiamą rezultatą ir vertinimo kriterijus, kad agentą būtų galima vėl išbandyti pagal tą patį scenarijų.

Kiek pėdsakų reikėtų išnagrinėti? Maždaug 100, tačiau stebuklingo skaičiaus nėra. Sustokite anksčiau, kai pasieksite teorinį prisotinimą – tašką, kai papildomų pėdsakų peržiūra nebeatskleidžia reikšmingų naujų klaidų modelių.

Dar nepaleidote programos? Pradiniam testų rinkiniui sudaryti gali padėti sintetiniai pavyzdžiai, tačiau vos tik atsiras realių naudotojų duomenų, jais reikėtų remtis.

Lyginamųjų testų naudojimas vertinant DI agentus

Be to, kad kuriate savo testavimo atvejus, agentų gebėjimams įvertinti galite naudoti esamus standartizuotų vertinimo užduočių rinkinius, vadinamus lyginamaisiais testais.

Tačiau lyginamieji testai nėra neklystantys. SWE-bench auditai, Epoch AI lyginamųjų testų apžvalgos ir TheoPhysEval teste iš pradžių atmesti teisingi atsakymai rodo, kaip ydingos užduotys ar laukiami atsakymai gali iškreipti vertinimo rezultatus.

Kaip pataria Khomutov, rinkitės naujausius, jūsų sričiai aktualius lyginamuosius testus ir išsiaiškinkite netikėtų sėkmių ar nesėkmių priežastis prieš laikydami rezultatus patikimu agento veikimo įrodymu.

3 žingsnis. Vykdykite agentą atkartojamoje testavimo aplinkoje

Atkartojama testavimo aplinka – tai kontroliuojama sąranka, kurioje galite vykdyti DI agentą su tais pačiais testavimo atvejais tomis pačiomis pradinėmis sąlygomis ir palyginti rezultatus. Ją gali sudaryti testavimo atvejų aplankas, agentą paleidžiantis Python scenarijus arba rezultatus vertinančių patikrų rinkinys.

Galite pradėti nuo to, kad reprezentatyvias įvestis išsaugotumėte kaip JSON failus, o Python scenarijumi vykdytumėte agento darbo eigą ir tikrintumėte jo išvestis patikros teiginiais. Mūsų gamyklos atsargų agento atkartojama testavimo aplinka galėtų atrodyti taip:

Padidinti

Norėdami sukurti atkartojamą testavimo aplinką, atlikite šiuos veiksmus:

1. Išsaugokite reprezentatyvias įvestis. Saugokite tikrus įvykius arba testavimo atvejus ta pačia struktūra, kurią jūsų programa gauna gamybinėje aplinkoje. Mūsų scenarijuje kaip JSON failą išsaugotumėte techninės priežiūros užklausą su įrenginio ID, reikalinga atsargine dalimi ir priežiūros data, kartu su atsargų ir patvirtintų dalių duomenų momentine kopija.
2. Vykdykite darbo eigą. Kiekvieną įvestį perleiskite per agentą, įskaitant jo informacijos paieškos žingsnius, įrankių iškvietimus ir atsakymo generavimą.
3. Įrašykite rezultatą ir pėdsaką. Užfiksuokite galutinę išvestį ir svarbius tarpinius veiksmus (pavyzdžiui, atsargų paieškas), kad matytumėte ne tik tai, ar agentui nepavyko, bet ir kur.
4. Kartokite atvejus atsižvelgdami į klaidos rimtumą, dažnumą ir problemos ištaisymo sudėtingumą. LLM programos yra nedeterministinės (iš identiškų įvesčių jos gali pateikti skirtingus rezultatus), todėl vienas sėkmingas vykdymas negarantuoja, kad kitas taip pat bus sėkmingas. Nurodykite sėkmingų bandymų dalį ir išnagrinėkite nesėkmes.

Tam Khomutov pataria matuoti pass@1 (kaip dažnai agentui pavyksta iš pirmo bandymo) ir pass@k (tikimybę, kad per nurodytą bandymų skaičių agentui pavyks bent kartą). Jei pateikiate pass@k, nurodykite bandymų skaičių, nes vienas teisingas atsakymas iš kelių dar nereiškia, kad agentas žino, kurį pasirinkti.

Augant jūsų programai, testams tvarkyti ir vykdyti naudokite testavimo karkasą, pavyzdžiui, pytest, o didelius testų duomenų rinkinius ir rezultatus apsvarstykite galimybę saugoti duomenų bazėje.

4 žingsnis. Kiekvienai patikrai pasirinkite tinkamą vertintoją

Vertintojas (dar dažnai vadinamas vertinimo įrankiu) – tai mechanizmas, kuris gali būti kodo fragmentas, vertinimo rubrika vadovaujamas LLM arba žmogus peržiūrėtojas, tikrinantis agento išvestį ar veiksmą pagal apibrėžtą kriterijų. Vertintojas pateikia sprendimą „tinka / netinka“ ir paaiškinimą, kuriame nurodomi svarbūs įrodymai.

Informacija: Vertinimo rubrika – tai kriterijų ir instrukcijų rinkinys, apibrėžiantis, kas laikoma teisingu ar priimtinu rezultatu.

Tinkamas vertintojo tipas priklauso nuo to, ką siekiate patikrinti. Štai kaip skiriasi šie trys metodai:

Kartais skirtingiems to paties vykdymo aspektams gali prireikti skirtingų vertinimo metodų, todėl vertintojus gali tekti derinti.

Kaip derinti vertintojus?

Paklauskite savęs: „Ar rezultatą galima patikrinti pagal žinomą taisyklę ar laukiamą reikšmę, ar reikia į žmogaus panašaus sprendimo?“

• Jei rezultatą galite patikrinti tiksliai, pradėkite nuo kodu pagrįsto vertintojo. Kodu pagrįsti vertintojai taip pat gali tikrinti struktūrizuotas išvestis, laukų reikšmių tinkamumą, įrankių argumentus arba galutinę duomenų bazės būseną.
• Jei patikrai reikia interpretuoti kontekstą, naudokite LLM kaip teisėją.
• Specifinių srities žinių reikalaujantiems arba ginčytiniems sprendimams pasitelkite žmones peržiūrėtojus.

Svarbu! LLM vertintojas gali klaidingai interpretuoti įrodymus arba neteisingai taikyti rubriką. Todėl jam reikia papildomo vertinimo žingsnio – kalibravimo pagal žmonių sprendimus.

Kalibruokite LLM vertintoją pagal žmonių sprendimus.

Iš esmės kalibruojant srities ekspertas turi įvertinti tikrus agento vykdymus. Tada ekspertas palygina savo sprendimus su LLM sprendimais ir, atsižvelgdamas į nesutapimus, patobulina vertinimo rubriką.

Štai penkių žingsnių vertintojo kalibravimo procesas:

1. Surinkite agento įvesčių, išvesčių ir susijusių pėdsakų pavyzdžių.
2. Paprašykite srities eksperto savarankiškai įvertinti, ar kiekvienas pavyzdys atitinka vertinimo kriterijų.
3. Paleiskite LLM vertintoją su šiais pavyzdžiais.
4. Palyginkite žmogaus ir modelio sprendimus.
5. Išsiaiškinkite nesutapimų priežastis ir patobulinkite vertintojo rubriką prieš išbandydami jį su naujais pavyzdžiais.

Khomutov taip pat pabrėžia, kaip svarbu atskirai patikrinti LLM vertintojo nuoseklumą:

„Kelis kartus pateikite jam lygiai tą patį išsaugotą vykdymą ir failus, iš naujo nepaleisdami agento. Taip galėsite atskirti agento darbo svyravimus nuo vertinimo svyravimų.“

Jei tas pats rezultatas gauna skirtingus verdiktus, nemanykite, kad kiekvienas balo pokytis kyla dėl agento. Verčiau išnagrinėkite painiavos matricą, kuri parodo, kada vertintojas teisingai nustatė klaidas, kada jas praleido ir kada klaidingai pažymėjo priimtinus rezultatus.

Žmogaus atliekama peržiūra išlieka būtina nustatant etaloninius sprendimus, sprendžiant ginčytinus atvejus ir aptinkant naujus klaidų tipus, kuriems aptikti esami vertintojai nebuvo sukurti.

5 žingsnis. Palyginkite versijas ir atlikite regresines patikras

Tarkime, klaidų analizė atskleidžia, kad jūsų atsargų agentas dažnai rekomenduoja nepatvirtintas pakaitines dalis. Pakeičiate jo sistemos raginimą, kad būtų privaloma aiški suderinamumo patikra. Anksčiau nepavykęs atvejis dabar sėkmingai praeina. Bet kaip žinoti, kad pakeitimas nepaveikė kitų užduočių?

Čia praverčia regresinis testavimas.

Regresinis testavimas – tai anksčiau sėkmingų testavimo atvejų pakartotinis vykdymas pakeitus agento raginimą, modelį ar darbo eigą, siekiant užtikrinti, kad pakeitimas nesukėlė naujų klaidų.

1. Atkurkite pradinę klaidą naudodami išsaugotą įvestį iš testų rinkinio.
2. Atlikite tikslinį pakeitimą raginime, modelyje ar darbo eigoje.
3. Pakartotinai paleiskite nepavykusį testą, kad patikrintumėte, ar problema išspręsta.
4. Paleiskite kitus testus, kad įsitikintumėte, jog pakeitimas nesutrikdė to, kas anksčiau veikė sėkmingai.
5. Peržiūrėkite rezultatus ir ištirkite visas naujas nesėkmes.

Kad rezultatai būtų tikslūs, bazinį ir atnaujintą agentą palyginkite naudodami tuos pačius testavimo atvejus ir vertinimo kriterijus.

6 žingsnis: stebėkite DI agento veikimą gamybinėje aplinkoje

Agento vertinimas nesibaigia įdiegus programą. Kaip aiškina Husain ir Shankar, tuos pačius vertintojus, kuriuos naudojate kūrimo metu, galite taikyti ir realiems gamybinės aplinkos duomenims, kad išmatuotumėte, kaip jūsų agentas veikia laikui bėgant.

Tai vadinama tiesioginiu vertinimu ir yra viena platesnio gamybinės aplinkos stebėsenos proceso, padedančio atskleisti pasikartojančias ir anksčiau nežinomas nesėkmes, dalių.

Šis procesas yra iteratyvus ir apima keturias viena kitą papildančias veiklas:

• Taikykite sukalibruotus LLM teisėjus gamybinės aplinkos pėdsakams. Atrinkite realių agento sąveikų pavyzdžius ir pritaikykite vertintojus, kuriuos jau patikrinote pagal žmonių vertinimus.
• Stebėkite nesėkmių dažnį laikui bėgant. Pasitelkite klaidų analizės metu nustatytas nesėkmių kategorijas, kad kiekybiškai įvertintumėte pasikartojančias problemas.
• Toliau peržiūrėkite pėdsakus rankiniu būdu. Automatiniai vertintojai aptinka tik tas problemas, kurioms nustatyti jie sukurti. Rankiniu būdu peržiūrėkite realių agento sąveikų pavyzdžius, kad atskleistumėte naujas klaidas ar neįprastas naudotojų užklausas.
• Verslo rezultatams matuoti naudokite A/B testavimą (tik tada, kai tai tikslinga). Palyginkite skirtingus raginimus, modelius ar darbo eigas pagal tokias metrikas kaip užduočių atlikimas, naudotojų pasitenkinimas ir problemos išsprendimo laikas. Šis procesas padeda nustatyti, ar pakeitimas iš tiesų pagerina produkto patirtį, o ne tik leidžia išlaikyti atskirus testus.

Viena svarbi pastaba: vertinimai neturi būti nušlifuoti iki tobulumo. Jie tiesiog turi būti pakankamai geri, kad padėtų tobulinti jūsų produktą.

Dažni klaidingi įsitikinimai vertinant DI agentus

• Vertinimai – tai tiesiog vienetų testai. Taip nėra: vienetų testai yra nedideli automatizuoti patikrinimai, sudarantys tik vieną vertinimo dalį. Vertinimai taip pat apima kokybinę klaidų analizę, žmonių atliekamą vertinimą, gamybinės aplinkos stebėseną ir eksperimentus, skirtus programos kokybei matuoti.
• Vertinimo platforma gali viską padaryti už jus. Paruošti naudoti įrankiai gali automatizuoti kai kuriuos patikrinimus, tačiau jie negali nustatyti, kurie nesėkmių tipai (klaidų rūšys ar nepageidaujamas agento elgesys) yra svarbūs jūsų produktui.
• Galite leisti LLM įvertinti viską. Tai didelis klaidingas įsitikinimas. Žmonių atliekama klaidų analizė ir vertintojų kalibravimas išlieka būtini, nes LLM trūksta verslo konteksto, reikalingo kiekvienai problemai aptikti.
• A/B testavimas ar tiesiog agento naudojimas pakeičia vertinimus. Neteisinga. A/B testai gali parodyti, kuri versija geriau veikia pagal pasirinktas metrikas, tačiau patys savaime negali paaiškinti slypinčių problemų.

DUK apie DI agentų vertinimą

1. Kuo skiriasi DI agentų vertinimas nuo LLM vertinimo?

LLM vertinimas matuoja, kaip gerai kalbos modelis atlieka tam tikrą užduotį, pavyzdžiui, atsako į klausimą, apibendrina dokumentą ar išgauna informaciją. DI agentų vertinimu įvertinama sistema, kuri užduočiai įvykdyti savarankiškai atlieka kelis veiksmus.

Kitaip nei įprastas LLM vertinimas, agento vertinimas nagrinėja ir galutinį rezultatą, ir veiksmų seką, kuria jis pasiektas, įskaitant įrankių iškvietimus, sprendimus ir iš anksto nustatytų taisyklių laikymąsi.

2. Pagrindinės DI agentų vertinimo metrikos

DI agentų vertinimo metrikos skirstomos į dvi plačias kategorijas:

• Techninio veikimo metrikos: užduočių sėkmės rodiklis, veiksmų teisingumas, atsakymų kokybė, patikimumas (pass@1 ir pass@k), delsa, žetonų naudojimas ir vienos sėkmingos užduoties kaina.
• Verslo ir naudotojų patirties metrikos: klientų pasitenkinimas (CSAT), problemų išsprendimo rodiklis, eskalavimo rodiklis, konversijos rodiklis, užduoties atlikimo laikas ir kiti su agento vaidmeniu susiję rezultatai.

Pavyzdžiui, klientų aptarnavimo agentas gali būti vertinamas pagal sėkmingai išspręstas problemas ir klientų pasitenkinimą, o DI pirkimų agentas – pagal papildymo užklausų tikslumą, patvirtinimo rodiklius ir pirkimo ciklo trukmę.

Tinkamos metrikos turėtų atspindėti ir tai, kaip patikimai veikia agentas, ir tai, ar jo darbas gerina verslo rezultatus.

3. Kokie yra geriausi įrankiai DI agentams vertinti?

Dažniausiai naudojami variantai:

• Testavimo karkasai: Python tvirtinimai (assertions) ir pytest naudingi vykdant pakartojamus testavimo atvejus ir tikrinant tikslias sąlygas, pavyzdžiui, ar agentas pasirinko tinkamą įrankį, ar grąžino galiojantį dalies ID.
• DI agentų vertinimo karkasai: DeepEval ir „Google“ agent-eval įrankių rinkinys leidžia atlikti sudėtingesnius vertinimus, įskaitant vykdymo pėdsakus, LLM pagrįstus vertintojus ir automatizuotą regresijos testavimą.
• Vertinimo ir stebimumo platformos: LangSmith, Arize Phoenix ir MLflow padeda komandoms tirti agentų elgseną, valdyti vertinimo duomenų rinkinius, lyginti agentų versijas ir stebėti veikimą gamybinėje aplinkoje.

4. Kaip automatizuoti DI agentų vertinimus?

DI agentų vertinimus galite automatizuoti kurdami pakartojamus testus, taikydami automatinius vertintojus ir integruodami šiuos patikrinimus į kūrimo ir gamybinės aplinkos darbo eigas:

1. Sukurkite vertinimo duomenų rinkinį: surinkite reprezentatyvias naudotojų užduotis, laukiamus rezultatus, žinomas nesėkmes ir agento vykdymo pėdsakus. Įtraukite kraštutinius atvejus, pavyzdžiui, nepavykusius įrankių iškvietimus, trūkstamą informaciją ir neleistinus veiksmus.
2. Automatizuokite testų vykdymą ir vertinimą: naudokite tokius karkasus kaip pytest ar DeepEval, kad paleistumėte testavimo atvejus ir pritaikytumėte kodu pagrįstus patikrinimus arba LLM vertintojus. Prieš pasikliaudami LLM vertintojų balais, patikrinkite juos pagal žmonių vertinimus.
3. Integruokite vertinimus į CI/CD: automatiškai iš naujo paleiskite regresijos testus, kai kūrėjai atnaujina agento raginimus, modelius, įrankius ar darbo eigą. Palyginkite rezultatus su baziniu lygiu ir nustatykite kokybės slenksčius, kurie neleistų išleisti naujų versijų, jei nepavyksta kritinių patikrinimų.
4. Taikykite sukalibruotus vertintojus atrinktiems gamybinės aplinkos pėdsakams, stebėkite nesėkmių dažnį ir kitas veikimo metrikas, o naujas klaidas tirkite atlikdami rankinę peržiūrą.