Uzticamas MI darbplūsmas ar cilvēka pārbaudi
Parastais gadījums rada pārliecinošu demonstrāciju: pienāk skaidrs jautājums, tiek atrasta vajadzīgā informācija un sagatavota atbilde. Ikdienā ir arī trūkstoši dati, novecojuši dokumenti, atkārtotas ziņas un rīki, kas uz laiku nav pieejami.
Uzticamai mākslīgā intelekta (MI) darbplūsmai vajag paredzētu rīcību arī šajos gadījumos. Šajā rakstā klienta pieprasījuma piemērs palīdz izskaidrot pārbaudes, apstiprināšanas noteikumus un uzturēšanas kārtību, par ko vienoties pirms ieviešanas. Piemēri ir ilustratīvi, nevis klientu rezultātu apgalvojumi.
Vispirms definējiet, kad darbs ir pabeigts
“Modelis izveidoja atbildi” ir starpposms. Pabeigts pieprasījums var nozīmēt, ka cilvēks atbildi apstiprināja, klients to saņēma un rezultāts saglabāts klienta ierakstā.
Ja ziņa nosūtīta, bet ieraksta atjaunošana neizdodas, sistēmai jāparāda daļēja izpilde. Atkārtojot visu darbplūsmu, klients var saņemt ziņu vēlreiz. Nošķiriet droši atkārtojamus soļus no darbībām, kuru iepriekšējais rezultāts vispirms jāpārbauda.
Pierakstiet komandai saprotamus statusus: saņemts, gaida informāciju, gatavs pārbaudei, apstiprināts, pabeigts un nepieciešama rīcība. Lietojiet jūsu procesam atbilstošus nosaukumus. Katram statusam, kurā darbs var iestrēgt, vajag atbildīgo un nākamo darbību.
Nosakiet automātisko darbību robežas
Vienojieties par atļaujām katrai darbībai atsevišķi. Uzņēmums var ļaut automātiski piešķirt iekšēju kategoriju, bet prasīt apstiprinājumu klienta atbildei vai nosacījumu maiņai.
| Situācija | Rīcības noteikuma piemērs |
|---|---|
| Jautājums atbilst zināmam pakalpojumam un aktuālam avotam | Sagatavot melnrakstu pārbaudei |
| Klientu nevar viennozīmīgi identificēt | Precizēt datus vai nodot atbildīgajam |
| Divos avotos norādīta atšķirīga cena | Apturēt melnrakstu un parādīt pretrunu |
| Klients prasa izņēmumu | Nodot cilvēkam, kurš drīkst pieņemt lēmumu |
| Pieslēgtais rīks nav pieejams | Saglabāt gaidīšanas statusu un pēc norunātā mēģinājumu limita ziņot atbildīgajam |
| Ziņa, iespējams, jau nosūtīta | Pirms atkārtošanas pārbaudīt nosūtīšanas ierakstu |
Tie ir piemēri, nevis universāli noteikumi. Robežām jābūt redzamām un tehniski izpildāmām. Nepaļaujieties tikai uz instrukciju modelim rīkoties uzmanīgi.
Dodiet pārbaudītājam vajadzīgo pamatojumu
Pārbaudes vietā jāredz ierosinātā darbība, izmantotie avoti, attiecīgais klients vai ieraksts, kā arī trūkstošie vai pretrunīgie dati. Skaidri parādiet, kas notiks pēc apstiprināšanas.
Ja apstiprinājums attiecas gan uz atbildi, gan uz CRM ieraksta maiņu, parādiet abus. Ja cenas piedāvājums mainījies, kamēr melnraksts gaida rindā, pirms izpildes to pārbaudiet vēlreiz. Citādi cilvēks var apstiprināt pareizu izskatu, bet sistēma rīkoties pēc novecojušas informācijas.
Vienojieties, kur nonāk nepārbaudīts darbs. Tas var palikt sākotnējā e-pasta kastē, kopīgā rindā vai tikt nodots aizvietotājam. Izvēlieties vietu, kuru komanda patiešām uzrauga.
Apzināti pārbaudiet sarežģītos gadījumus
Veidojiet testu kopu no raksturīgiem piemēriem, noņemot personas datus vai atbilstoši ierobežojot piekļuvi. Katram gadījumam paredzamo rīcību aprakstiet pirms rezultāta apskates. Saglabājiet kļūmju piemērus kopā ar parastajiem.
OpenAI vērtēšanas vadlīnijas iesaka uzdevumam specifiskas pārbaudes, reprezentatīvus datus un atkārtotu testēšanu, lietotnei mainoties. Šie principi noder neatkarīgi no modeļa piegādātāja. Vērtēšanas vadlīnijas.
Pieprasījumu darbplūsmai iekļaujiet:
- Parastu jautājumu ar aktuālu un atbilstošu avotu.
- Jautājumu, uz kuru apstiprinātajos avotos nav atbildes.
- Vecu dokumentu, kas ir pretrunā aktuālajam.
- Divus klientus ar līdzīgiem nosaukumiem.
- Pielikumu, kurā trūkst turpināšanai vajadzīgo datu.
- Vienu un to pašu notikumu, kas piegādāts divreiz.
- Rīka kļūmi pēc tam, kad cita darbība jau izdevusies.
- Ienākošu tekstu, kas mēģina likt sistēmai ignorēt noteikumus.
Klientu ziņas un atrastie dokumenti ir ievade, nevis instrukcijas, kas drīkst piešķirt jaunas tiesības. Atļautās darbības un piekļuves pārbaudes jānodrošina lietotnei. Pārbaudiet modeļa rezultātu, īpaši pirms ar to kaut ko mainīt citā rīkā.
Vērtējiet darbplūsmas rīcību
Vienojieties par konsekventi pārbaudāmiem kritērijiem: pareizs klients, ar avotiem pamatota informācija, neizdomāta pieejamība, pareizi novirzīts izņēmums un neatkārtota ārēja darbība.
Mēriet arī cilvēka ieguldījumu. Tehniski precīzs melnraksts, kas jāpārraksta gandrīz pilnībā, var darbu neuzlabot. Salīdziniet pieņemtos melnrakstus, būtiskos labojumus, neatrisinātos izņēmumus un apstrādes laiku ar sākotnējo situāciju.
Neapvienojiet visu vienā “precizitātes” rādītājā. Ja parastie pieprasījumi izdodas, bet novecojušie piedāvājumi regulāri izraisa kļūdas, vidējais rezultāts var paslēpt tieši problemātisko robežu. Skatiet rezultātus pa scenārijiem; atļauju pārkāpumus un atkārtotas darbības uzskaitiet atsevišķi.
Info
Cilvēka pārbaude neaizstāj testēšanu. Pārbaudītājam vajag pārskatāmu rindu un pietiekamu kontekstu. Mēriet, kā pārbaude darbojas praksē, nevis pieņemiet, ka cilvēks pamanīs katru kļūdu.
Ieviesiet pakāpeniski, saglabājot atpakaļceļu
Testējiet bez ziņu nosūtīšanas un reālu klientu ierakstu maiņas. Izvērtējiet kļūdainās atbildes un pārbaudiet, vai neveiksmīgie gadījumi nonāk paredzētajā statusā.
Ļaujiet komandai salīdzināt melnrakstus ar ierasto rezultātu. Atbildībai par reālo uzdevumu jābūt skaidrai, lai tas netiktu izdarīts divreiz vai palaists garām.
Izmantojiet norunātos pieprasījumu veidus, avotus un atļaujas. Saglabājiet praktisku apturēšanas iespēju un manuālu darba turpinājumu, ja pieslēgtais pakalpojums nedarbojas.
Atkārtojiet attiecīgos testus, mainoties instrukcijām, modelim, avotu struktūrai, atļaujām vai integrācijām. Paplašiniet tvērumu tad, kad atbildīgais saprot rezultātus un spēj uzturēt papildu darbu.
Vienojieties par atbildību pēc ieviešanas
Pierakstiet, kas uztur avotus, izmeklē kļūmes un drīkst mainīt apstiprināšanas noteikumus. Saglabājiet pietiekamu darbību vēsturi rezultāta izskaidrošanai, ierobežojot piekļuvi un neveidojot nevajadzīgas sensitīvu datu kopijas.
Nosakiet, kuras kļūmes izraisa paziņojumu un kurš to saņem. Kļūdu žurnāls, kuru neviens nelasa, komandai nepalīdz atjaunot darbu. Vienojieties arī, kad darbplūsma jāaptur un kā nepabeigtie uzdevumi atgriežas pie cilvēkiem.
Šie lēmumi ir daļa no piegādes tvēruma. Lindevo pieeja sistēmas izstrādei un uzturēšanai sākas ar darbu, tā robežām un atbildīgajiem. Ja vēl izvēlaties uzdevumu, izmantojiet pirmās automatizācijas ceļvedi.
Šajā lapā