Funkcionalnost koja se temelji na umjetnoj inteligenciji može u ponedjeljak dati izvrstan odgovor, a u petak napraviti istu pogrešku koju je moguće izbjeći. Razlika između uvjerljive demonstracije i sustava koji se poboljšava rijetko je samo u modelu. Ona je u načinu na koji je sustav oko modela osmišljen: što sustav prati, kako procjenjuje ishode i koje promjene smije unositi.

Ta je razlika važna jer riječ „učenje” ima više značenja. Model može učiti tijekom treniranja, ali se i aplikacija može poboljšavati ažuriranjem indeksa za dohvat, doradom upute, promjenom tijeka rada ili prosljeđivanjem složenih slučajeva osobi. Nijedna od tih promjena ne zahtijeva da model mijenja vlastite težine. Za svaku su ipak potrebni dokazi i nadzor.

Počnite od odluke, a ne od modela

Prije odabira arhitekture opišite odluku koju sustav treba podržati i cijenu pogreške. Alat koji predlaže oznake za interne dokumente ima drukčiji profil rizika od alata koji odobrava plaćanja. Kod prvoga mogu biti prihvatljive povremene pogreške koje korisnik može brzo ispraviti. Drugi zahtijeva stroge ovlasti, mogućnost revizije i neovisne provjere.

Razmotrite asistenta koji timu za podršku pomaže sastavljati odgovore. Njegova zadaća nije samo proizvesti uvjerljiv tekst. Mora upotrijebiti relevantne informacije o proizvodu, razlikovati pouzdan odgovor od nesigurnoga i djelatniku ponuditi nacrt vrijedan pregleda. Koristan dizajn polazi od tih očekivanja i određuje kako će tim prepoznati uspjeh.

To može uključivati provjeru poziva li se nacrt na odgovarajuće interne materijale, prihvaća li ga djelatnik bez znatnih ispravaka i rješava li konačni odgovor problem. Ti pokazatelji odgovaraju na različita pitanja. Nacrt može biti tečan, a ipak preporučiti pogrešnu radnju; prihvaćeni nacrt i dalje može ne riješiti problem korisnika.

Uspostavite povratnu petlju prije nego što je automatizirate

Petlja poboljšanja ima četiri dijela: zabilježiti ishod, protumačiti pokazatelj, predložiti promjenu i provjeriti je li promjena pomogla. Najteže je odlučiti što svaki pokazatelj znači.

Kod asistenta za podršku izmjena koju napravi djelatnik koristan je dokaz, ali nije automatski i cilj za treniranje. Djelatnik možda ispravlja činjeničnu pogrešku, prilagođava ton ili dodaje kontekst koji asistentu nije bio dostupan. Pohranite dovoljno konteksta da biste mogli razlikovati te slučajeve, u skladu s pravilima svoje organizacije o privatnosti i čuvanju podataka. Mali, pažljivo pregledan skup primjera može otkriti više od velike količine klikova na palac prema dolje bez objašnjenja.

Razlikujte moguće načine reagiranja na povratne informacije. Ako se odgovor oslanjao na zastarjelo pravilo, ažurirajte izvor i postupak njegova indeksiranja. Ako je odgovarajuće pravilo bilo dostupno, ali nije dohvaćeno, istražite dohvat. Ako su dokazi bili prisutni, ali ih je odgovor zanemario, ispitajte upute i ponašanje modela. Ako je sam zadatak dvosmislen, poboljšajte postupak predaje osobi. Dodatno podešavanje modela s vremenom može biti korisno za ponašanje koje se ponavlja, ali nije zamjena za utvrđivanje uzroka pogreške.

Osigurajte sustavu pouzdanu memoriju

Mnogim aplikacijama umjetne inteligencije potreban je pristup informacijama koje se mijenjaju češće nego što se model trenira. Dohvat može osigurati taj kontekst: pronaći relevantne dokumente, proslijediti odabrane izvatke modelu i zatražiti da odgovori unutar tih granica.

Kvaliteta tog postupka ovisi o uobičajenim inženjerskim pojedinostima. Dokumenti trebaju imati odgovorne osobe, kontrole pristupa i način povlačenja zastarjelih verzija. Dohvat mora poštovati ovlasti osobe koja podnosi zahtjev. Aplikacija bi također trebala izričito obraditi nedostajuće ili proturječne dokaze, umjesto da svaki dohvaćeni odlomak smatra mjerodavnim.

Razlikujte pojedine vrste memorije. Važeće pravilo pripada u održavani izvor znanja. Korisnička postavka može pripadati u profil koji se može uređivati. Povijest razgovora pomaže u trenutačnoj razmjeni, ali može sadržavati pogreške i osjetljive informacije. Odluka o tome što zadržati, koliko dugo te tko to može ispraviti ili izbrisati dio je arhitekture.

Procjenjujte promjene na stvarnim zadacima

Bez stabilnog skupa za evaluaciju lako je zamijeniti odgovor koji zvuči sigurnije s boljim odgovorom. Prikupite reprezentativne primjere iz tijeka rada, uključujući uobičajene zahtjeve, dvosmislena pitanja, nedostajuće informacije i slučajeve u kojima je ispravan odgovor odbiti zahtjev ili ga proslijediti na višu razinu. Pregledajte očekivane ishode s ljudima koji razumiju posao.

Upotrijebite taj skup za usporedbu predložene promjene s trenutačnim sustavom. Kombinirajte provjere koje se mogu automatizirati s ljudskim pregledom ondje gdje je potrebna procjena. Primjerice, automatizirana provjera može utvrditi sadrži li nacrt obaveznu obavijest, dok osoba koja ga pregledava procjenjuje je li preporuka primjerena. Nijedna od tih provjera sama po sebi ne utvrđuje je li cijeli odgovor točan.

Pratite i radne pokazatelje: vrijeme odaziva, pogreške, predaje zadataka i trud potreban za ispravljanje rezultata. Ako promjena poboljšava kvalitetu odgovora, ali djelatnici zbog čekanja odustaju od alata, sustav se nije poboljšao na način koji je timu potreban. Ponovno razmatrajte skup za evaluaciju kako se proizvod i načini na koje može zakazati mijenjaju, uz zadržavanje dosljednog skupa slučajeva za smislene usporedbe.

Neka autonomija bude kontrolirana odluka

Generiranje preporuke i poduzimanje radnje različite su odgovornosti. Agent koji može čitati korisnički zapis, izvršiti povrat novca i poslati poruku treba imati izričita ograničenja za svaku od tih mogućnosti. Dodijelite mu samo pristup potreban za njegov zadatak, provjeravajte ulazne i izlazne podatke na granicama sustava i zahtijevajte ljudsko odobrenje za radnje kod kojih su pogreške skupe ili ih je teško poništiti.

Scenarije pogrešaka osmislite jednako pažljivo kao i tijek u kojem sve prolazi prema planu. Poziv modelu može isteći; alat može vratiti nepotpune podatke; radnja može uspjeti čak i ako aplikacija ne primi potvrdu. Sustav bi trebao prijaviti nesigurnost, izbjeći naslijepo ponavljanje radnje koja je možda već izvršena i operateru pružiti dovoljno informacija za istragu. Zapisnici i revizijski zapisi trebali bi podržati taj rad bez zadržavanja nepotrebnog osjetljivog sadržaja.

Poboljšavanje je sposobnost proizvoda

Praktično uvođenje može započeti prijedlozima koje pregledavaju ljudi, nakon čega može uslijediti ograničena automatizacija tamo gdje je dokazi opravdavaju. Odredite odgovorne osobe za izvore znanja, skup za evaluaciju i sam tijek rada. Omogućite korisnicima jednostavno prijavljivanje pogrešaka i pobrinite se da te prijave budu vidljive ljudima koji mogu poduzeti potrebne mjere.

Nacrt sustava umjetne inteligencije koji doista uči stoga je manje zagonetan nego što zvuči. Izgradite sustav koji može pratiti svoj rad, pretvoriti povratne informacije u konkretne promjene i dokazati vrijednost tih promjena na smislenim primjerima. Model pruža snažnu sposobnost; dizajn sustava oko njega omogućuje da ta sposobnost s vremenom postane korisnija i pouzdanija.