AI će učiti iz mnogo više od dokumenata. Učit će iz softvera koji ljudi koriste za donošenje odluka, dovršavanje posla, rješavanje iznimaka i razumijevanje toga kako izgleda “dobro” u određenoj domeni.

To stvara neuobičajeno važnu priliku za produktne timove. Najtrajniji softver možda neće samo automatizirati tijek rada ili prikazivati informacije. Možda će postati okruženje koje bilježi stručnu prosudbu u obliku koji AI sustavi mogu koristiti: strukturirane odluke, ispravke, odobrenja, objašnjenja i ishode.

Cilj nije izgraditi okvir za razgovor uz svaku bazu podataka. Cilj je izgraditi proizvode koji stručnost čine razumljivom.

Korisni softver stvara visokokvalitetne signale

Svaki proizvod stvara podatke, ali ne uče svi podaci AI nečemu vrijednom. Niz klikova može pokazivati aktivnost. Rijetko objašnjava namjeru. Dovršeni zadatak može pokazivati ishod. Možda neće otkriti zašto je jedna opcija odabrana umjesto druge.

Najjači proizvodi stvaraju signale kao prirodnu posljedicu pomaganja ljudima u radu. Razmotrite alat za pregled zahtjeva za naknadu štete. Ako bilježi samo “odobreno” ili “odbijeno”, ima oskudan signal za treniranje. Ako stručnjaku omogućuje da klasificira razlog, navede relevantne dokaze, označi nesigurnost i pošalje slučaj na eskalaciju, proizvod sada bilježi sažeti zapis profesionalne prosudbe.

To je korisnije korisniku danas i korisnije budućoj AI pomoći sutra.

Pri procjeni značajke tehnički bi lideri trebali postaviti drukčiji skup pitanja:

• Koju odluku ova značajka pomaže osobi donijeti?
• Koje su dokaze razmotrili?
• Može li proizvod bilježiti ispravke bez dodavanja nepotrebnog posla?
• Možemo li razlikovati pouzdanost od sigurnosti?
• Hoće li nam konačni ishod reći je li odluka bila ispravna?

Ta pitanja vode do boljeg softvera čak i ako se godinama ne trenira nijedan model. Tjeraju tim da razumije korisnikov tijek rada umjesto da ga tretira kao slijed zaslona.

Osmislite povratnu petlju prije dodavanja inteligencije

Timovi često počinju sa sposobnošću modela: sažmi ove zapise, klasificiraj ove tikete, sastavi ovaj odgovor. To može stvoriti uvjerljivu demonstraciju, ali ne mora nužno stvoriti pouzdan proizvod.

Trajnija polazna točka jest povratna petlja. Definirajte predloženu radnju, točku ljudske provjere, mehanizam ispravka i mjerljivi ishod. Zatim odlučite gdje AI može smanjiti napor bez prikrivanja odgovornosti.

Učinite provjeru dijelom rada, a ne izlazom u nuždi

Dobro iskustvo provjere je konkretno. “Je li ovaj odgovor bio koristan?” lako je implementirati, ali je slaba povratna informacija. Od zauzete osobe traži da složenu prosudbu pretoči u neodređenu ocjenu.

Umjesto toga, ponudite ispravke koje odgovaraju poslu. Stručnjak za podršku mogao bi označiti predloženi odgovor kao netočan, nepotpun, previše samouvjeren ili pogrešnog tona. Sigurnosni analitičar mogao bi upozorenje označiti kao bezazleno, sumnjivo ili zahtijeva eskalaciju. Regruter bi mogao ispraviti predloženo podudaranje vještina i navesti dokaze koji su promijenili odluku.

Sučelje bi trebalo učiniti ispravan ispravak lakšim od počinjanja ispočetka. Ako ispravljanje AI rezultata traje dulje od ručnog obavljanja posla, ljudi će zaobići sustav. Proizvod gubi i prihvaćanje i signal potreban za poboljšanje.

Sačuvajte kontekst iza ispravka

Ispravak bez konteksta može biti obmanjujući. Pretpostavimo da korisnik promijeni predloženi datum isporuke. Je li izvorni prijedlog bio pogrešan zato što zalihe nisu bile dostupne, zato što je korisnik imao poseban dogovor ili zato što su izvorni zapisi bili zastarjeli?

Zabilježite najmanje korisno objašnjenje. To može biti kod razloga, povezan zapis, odabrano pravilo ili neobavezna kratka bilješka. Svrha nije iscrpan nadzor zaposlenika. Potrebno je dovoljno konteksta da pogreška bude razumljiva, provjerljiva i potencijalno sprječiva.

Ugradite granice vlasništva u proizvod

Kako softver postaje sposobniji, vlasništvo mora postati jasnije. AI prijedlog može biti vrijedan, a da nije ovlašten djelovati. Brkanje ta dva stanja neuspjeh je u dizajnu proizvoda, a ne samo pojedinost implementacije.

Koristite eksplicitna stanja za tijekove rada s važnim posljedicama: nacrt, predloženo, pregledano, odobreno, izvršeno i poništeno. Točni nazivi manje su važni od jasnoće. Korisnici bi trebali moći utvrditi što je sustav učinio, što je osoba odobrila i što još čeka.

To inženjerskim timovima također pruža praktičnu arhitekturu. Sadržaj koji je generirao AI može ostati prijedlog dok ne prijeđe granicu poslovnog pravila ili ljudskog odobrenja. Zapisi revizije mogu bilježiti opseg ulaza, dobivenu preporuku, radnju pregledavatelja i sve konačne izmjene.

nacrt -> predloženo -> pregledano -> odobreno -> izvršeno
                  |             |
                  v             v
              odbačeno       izmijenjeno

Ne treba svaka značajka ovu razinu formalnosti. Prijedlog pravopisa i odobravanje plaćanja nose različit rizik. Disciplina se sastoji u tome da granica bude proporcionalna posljedici.

Udaljenim timovima potrebna je zajednička produktna prosudba

Distribuirani timovi mogu graditi izvrsne proizvode s podrškom AI-ja, ali ne mogu se osloniti na pojašnjenje u hodniku kada se model ponaša neočekivano. Namjera proizvoda mora biti vidljiva u samom radu.

Sažeti zapis odluke često je vrijedniji od duge specifikacije. Za svaki smisleni AI tijek rada dokumentirajte korisnički cilj, dopuštene ulaze, neprihvatljive ishode, odgovornost za provjeru, ponašanje u slučaju rezerve i način na koji će se procjenjivati kvaliteta. Držite ga blizu implementacije i revidirajte ga kada se proizvod promijeni.

To pomaže inženjerima donositi ispravne lokalne odluke. Također održava produktne menadžere, dizajnere, timove za podršku i stručnjake za domenu usklađenima oko istog pitanja: što bi se trebalo dogoditi kada je sustav nesiguran?

Odgovor bi rijetko trebao biti “pogađaj s više samopouzdanja”. Ponekad je najbolje iskustvo pokazati dokaze, zatražiti pojašnjenje, usmjeriti rad stručnjaku ili odbiti poduzeti radnju.

Održiva isporuka nadmašuje AI predstavu

Postoji pritisak da se inteligencija brzo najavi. Taj pritisak može stvoriti krhke značajke izgrađene oko impresivnih rezultata, a ne pouzdanih ishoda. Održivi pristup objavljuje usko definirano, mjeri stvarnu upotrebu i poboljšava tijek rada oko modela jednako kao i sam model.

Počnite s ograničenim zadatkom koji ima jasnog vlasnika i poništivu radnju. Promatrajte gdje korisnici prihvaćaju, uređuju, odbijaju ili ignoriraju prijedloge. Istražite obrasce prije nego što proglasite uspjeh. Visoka stopa prihvaćanja može upućivati na kvalitetu, ali može također značiti da ljudi ne provjeravaju rezultat. Niska stopa prihvaćanja može otkriti loše sučelje, a ne slab model.

Tehnički lideri trebali bi zaštititi vrijeme za ovu petlju učenja. Bilježenje, slučajevi za evaluaciju, alati za provjeru i postupanje s neuspjesima dio su produktnog rada. Nisu završna dorada koja se dodaje nakon što se isporuči “AI značajka”.

Podučavajte sustav poštujući stručnjaka

Najbolji AI proizvodi ne predstavljaju stručnjake kao privremene prepreke na putu prema automatizaciji. Stručnu prosudbu tretiraju kao najvrjedniju imovinu proizvoda.

Gradite softver koji ljudima pomaže sada obavljati smislen posao. Učinite odluke vidljivima, ispravke lakima, vlasništvo eksplicitnim, a ishode sljedivima. S vremenom ti izbori stvaraju sustav koji može inteligentnije pomagati jer je učio iz stvarnog rada obavljenog pažljivo.

To je dublja prilika: ne softver koji zamjenjuje ljude koji poznaju posao, nego softver koji postaje dostojan učiti od njih.