Tim može umjetnom inteligencijom podržanom asistentu dati pomno oblikovan upit, a ipak ga sljedeći tjedan gledati kako ponovno griješi na istom zahtjevu za podršku. Odgovor je možda bio koristan, ljudski ispravak možda je bio precizan, a razgovor je možda čak negdje i pohranjen. Ništa od toga ne jamči da će se softver sljedeći put ponašati drukčije.

Ta je praznina arhitekturni problem. Aplikacija ne uči samo zato što model odgovara ili baza podataka čuva zapis razgovora. Uči kada korisne informacije mogu promijeniti buduće ponašanje kroz osmišljen postupak koji se može provjeriti. Za razvojne programere koji ugrađuju umjetnu inteligenciju u proizvode i radne procese, taj postupak zaslužuje jednaku pozornost kao i upit.

Odlučite što „učiti” znači u vašem sustavu

Učenje se može odvijati na više razina, a svaka nosi drukčije troškove i rizike. Sustav za dohvat informacija može modelu učiniti dostupnim novo odobreni dokument bez promjene samog modela. Aplikacija može zapamtiti korisničku preferenciju i uključiti je u kasnije zahtjeve. Tim nakon analize pogrešaka može izmijeniti upute, alate ili pravila usmjeravanja. U nekim slučajevima može upotrijebiti odabrane primjere za dodatno podešavanje modela.

Ti mehanizmi nisu međusobno zamjenjivi. Dodavanje ispravljenog pravila u bazu znanja može riješiti problem zastarjelog odgovora, ali neće nužno naučiti agenta da prije poduzimanja radnje zatraži informacije koje nedostaju. Dodatno podešavanje može utjecati na obrasce odgovaranja, ali ne jamči da model poznaje najnovija pravila ni da ih slijedi u svakom slučaju.

Započnite tako da odredite ponašanje koje želite promijeniti. „Pri odgovaranju korisnicima primijeni aktualna pravila povrata novca” upućuje na potrebu za mjerodavnim izvorom koji se može ažurirati. „Ne izdaji povrat novca ako se račun ne može provjeriti” zahtijeva kontrolu u radnom procesu. „Piši sažetke u obliku koji korisnik preferira” može zahtijevati pohranjenu preferenciju. Prikladan mehanizam učenja proizlazi iz vrste pogreške.

Izgradite put od povratne informacije do ponašanja

Zamislite asistenta koji izrađuje nacrte odgovora za tim korisničke podrške. Djelatnik uređuje nacrt jer je asistent naveo stari rok za otkazivanje. Ako izmjena ostane unutar zatvorenog zahtjeva, sljedeći nacrt može ponoviti istu pogrešku. Koristan postupak obrade povratnih informacija bilježi ispravak, utvrđuje izvor problema i osigurava da se odobreno ažuriranje unese u materijal koji asistent može dohvatiti.

Za taj su postupak potrebne jasno određene odgovornosti. Stručnjak za proizvod mogao bi provjeriti pravila, dok inženjer provjerava preuzima li sustav za dohvat izmijenjeni dokument. Prije objave tim može postaviti reprezentativna pitanja ažuriranom sustavu te provjeriti i odgovor i izvore na kojima se temelji.

Zapise povratnih informacija oblikujte tako da sačuvaju kontekst, a da pritom prema zadanim postavkama ne prikupljaju sve podatke. Ovisno o zadatku, korisna polja mogu uključivati izvorni zahtjev, nacrt, ljudski ispravak, razlog ispravka, relevantnu verziju izvora i podatak o tome je li ispravak odobren. Uklonite ili ograničite osjetljive informacije ondje gdje nisu potrebne za poboljšanje.

Povratna informacija služi kao dokaz, ali nije automatski istinita. Korisnik može preferirati kraći odgovor, pogrešno razumjeti pravila ili namjerno pokušati manipulirati sustavom. Razlikujte preferenciju, predloženi činjenični ispravak i odobrenu promjenu pravila. Svaka od tih stavki može zahtijevati drukčiji postupak provjere i pohrane.

Učinite memoriju određenom i provjerljivom

Memorija je privlačna jer ostavlja dojam da se asistent manje ponavlja. No u njoj se može zadržati i mala pogreška. Ako asistent iz jednog užurbanog razgovora zaključi da korisnik uvijek želi sažete odgovore, ta pretpostavka može neprimjetno narušiti kvalitetu budućeg rada.

Odredite svrhu i opseg pohranjenih informacija. Odobrene konvencije tima za pisanje koda pripadaju zajedničkim projektnim smjernicama; oblik odgovora koji pojedinac preferira pripada njegovim osobnim postavkama. Privremeni detalj o incidentu može biti koristan za jedan zadatak, a mjesec dana kasnije navoditi na pogrešan zaključak.

Za svaku vrstu zapamćene informacije odlučite tko je može stvoriti, tko je može promijeniti, kada istječe te kako se može pregledati ili izbrisati. Kada zapamćena informacija utječe na odgovor ili radnju, sačuvajte dovoljno podataka o njezinu podrijetlu kako biste je mogli povezati s izvorom. Tako je moguće ispraviti pogrešan zapis bez nagađanja iz kojeg razgovora potječe.

Okružite model alatima i pravilima

Model može predložiti radnju; okolni softver treba odrediti je li ona dopuštena. Primjerice, u postupku obrade troškova asistent može izdvojiti podatke s računa i pripremiti zahtjev za nadoknadu troškova. Aplikacija može provjeriti obvezna polja i ovlasti podnositelja zahtjeva te prije isplate zahtijevati odgovarajuće odobrenje.

To je razdvajanje važno za učenje. Ispravljeni primjer može poboljšati izdvajanje podataka, a ažurirane smjernice mogu pomoći asistentu da obradi neuobičajen račun. Ni jedno ni drugo ne bi trebalo biti jedina zaštita od neovlaštene isplate. Ograničenja za radnje sa značajnim posljedicama postavite u sustave koji ih provode, uz jasne poruke o pogreškama koje asistent može upotrijebiti za oporavak ili traženje pomoći.

Za radne procese agenata odredite što se događa kada alat zakaže, vrati nepotpune podatke ili proizvede nejasan rezultat. Ponovni pokušaj može biti opravdan kod privremenog neuspjeha čitanja podataka. Naslijepo ponovljeno slanje uplate ili poruke može dovesti do dvostrukog izvršavanja, osim ako je operacija osmišljena tako da sigurno obrađuje ponovljene zahtjeve. Kada ishod nije siguran, radni proces trebao bi provjeriti status ili proslijediti problem na višu razinu umjesto da pretpostavi uspjeh.

Procjenjujte cijeli ciklus, a ne samo odgovor

Uvjerljiv odgovor nije dokaz da se sustav poboljšao. Održavajte malen skup slučajeva temeljenih na stvarnim obrascima pogrešaka, uz primjereno postupanje s osjetljivim podacima. Uključite uobičajene i dvosmislene zahtjeve, zastarjele informacije, proturječne izvore te pokušaje pokretanja radnji bez potrebnih ovlasti.

Za svaki slučaj procijenite ponašanje koje je važno. Je li asistent dohvatio aktualna pravila? Je li upozorio na informacije koje nedostaju? Je li aplikacija blokirala neovlaštenu radnju? Je li ispravak poboljšao ciljani slučaj bez pogoršanja drugdje? Ljudska je provjera i dalje vrijedna za značajke koje je teško obuhvatiti jednostavnom provjerom, poput jasnoće odgovora i primjerenog izražavanja ograničenja i nesigurnosti.

Gdje je to izvedivo, vodite evidenciju verzija elemenata koji utječu na ponašanje: upita, relevantne konfiguracije, alata, slučajeva za evaluaciju i izvora znanja. Značajne promjene uvodite kontrolirano, pratite njihove učinke i osigurajte mogućnost njihova poništavanja. Sustav koji može prihvatiti povratnu informaciju, ali ne može objasniti ni poništiti štetnu promjenu, ima ciklus poboljšavanja kojem nedostaje kočnica.

Omogućite softveru da postane mudriji

Najkorisniji sustavi umjetne inteligencije ne ovise o savršenoj uputi napisanoj prvog dana. Oni omogućuju ispravke, usmjeravaju ih na pravo mjesto i provjeravaju dovode li do boljeg ishoda. Ponekad je rezultat bolji upit. Jednako je često to ispravljen dokument, jasnije određena granica ovlasti ili radni proces koji zna kada treba stati.

Razmišljajte dalje od onoga što model može reći u jednoj interakciji. Izgradite postupke kojima ljudi mogu uočiti pogreške, odobriti promjene i provjeriti sljedeći rezultat. Tako softver stječe sposobnost poboljšavanja.