Značajke umjetne inteligencije rijetko ne uspiju zato što model nije sposoban. Ne uspiju zato što okolni proizvod nije odredio što znači „korisno”.

Tim može povezati sposoban model, dizajnirati privlačno sučelje i ipak stvoriti nešto što djeluje nepouzdano, skupo ili neobično nerelevantno. Sastojak koji nedostaje jest produktno razmišljanje: disciplina pretvaranja ljudskog problema u jasan ishod, pouzdan tijek rada i sustav koji se s vremenom može poboljšavati.

Za programere to mijenja posao. Kod više nije samo implementacija zahtjeva. Postaje dio razgovora između korisnika, produktnih odluka, operativnih ograničenja i probabilističkih sustava. Vaš kod treba govoriti jezikom proizvoda.

Umjetna inteligencija je ponašanje proizvoda, a ne tehnički dodatak

Tradicionalni softver često se ponaša deterministički. Uz isti valjan unos i stanje, funkcija bi trebala proizvesti isti izlaz. Sustavi umjetne inteligencije uvode korisnu neizvjesnost. Model može tumačiti dvosmislen jezik, sažeti dugačak dokument ili predložiti sljedeću radnju, ali može i pogrešno razumjeti namjeru, izostaviti kontekst ili iskazati neopravdano samopouzdanje.

Ta neizvjesnost nije razlog za izbjegavanje umjetne inteligencije. To je razlog da se oko nje promišljeno dizajnira.

Razmotrite interni alat za podršku koji sastavlja odgovore na pitanja korisnika. Tehnički uska implementacija može poslati najnoviju poruku modelu i prikazati rezultat. Implementacija vođena produktnim razmišljanjem postavlja bolja pitanja:

• Je li cilj smanjiti vrijeme sastavljanja, poboljšati dosljednost ili riješiti probleme bez eskalacije?
• Koje politike tvrtke i pojedinosti računa moraju utjecati na odgovor?
• Kada bi sustav trebao sastaviti odgovor, zatražiti više informacija ili odbiti odgovoriti?
• Tko pregledava izlaz i što se događa kada je nacrt pogrešan?
• Koji dokazi pomažu agentu podrške da vjeruje prijedlogu ili ga ispravi?

Poziv modelu može biti mali dio značajke. Stvarni proizvod je tijek rada oko njega.

Počnite od odluke, a ne od uputa

Formuliranje uputa je važno, ali se upute često tretiraju kao zamjena za definiciju proizvoda. Nisu. Uputa ne može nadoknaditi nejasnu potrebu korisnika, nedostajuće izvorne podatke ili sučelje koje ljudima ne daje način da provjere izlaz.

Prije dizajniranja upute navedite odluku ili zadatak koji bi umjetna inteligencija trebala podržati. „Sažmi dokumente” zahtjev je oblikovan implementacijom. „Pomozi voditelju računa da se pripremi za obnovu ugovora s korisnikom za pet minuta” produktni je ishod.

Druga izjava daje inženjerstvu korisne granice. Sažetak bi trebao dati prednost rizicima obnove, neriješenim problemima podrške, promjenama u korištenju i radnjama. Možda će trebati poveznice ili citate na temeljne zapise. Trebao bi signalizirati neizvjesnost kada su podaci nepotpuni. Ne bi trebao neprimjetno izmišljati zaključak samo zato što uglađen odlomak izgleda korisno.

Takvo uokvirivanje također omogućuje evaluaciju. Tim može provjeriti pomaže li rezultat voditelju računa u pripremi, umjesto da raspravlja o tome zvuči li sažetak samo inteligentno.

Definirajte posao običnim jezikom

Kratak produktni sažetak može spriječiti tjedne nefokusirane implementacije. Trebao bi odgovoriti na sljedeće:

• Korisnik: Tko obavlja zadatak?
• Trenutak: Što pokreće potrebu?
• Ishod: Što bi trebalo biti brže, sigurnije, jasnije ili učinkovitije?
• Ulazi: Koje su informacije dostupne i dopuštene?
• Ograničenja: O čemu sustav nikada ne smije samostalno odlučivati ili što ne smije otkrivati?
• Rezervna opcija: Što bi se trebalo dogoditi kada su pouzdanost, kvaliteta podataka ili dostupnost nedovoljni?

To nije birokracija. To je sučelje između proizvoda, dizajna, inženjerstva, sigurnosti i operacija.

Gradite za provjeru i oporavak

Korisnicima ne treba predavanje o ponašanju modela, ali trebaju praktičnu kontrolu. Ako odgovor generiran umjetnom inteligencijom utječe na značajnu radnju, sustav bi trebao olakšati provjeru ulaza, izmjenu izlaza i oporavak od pogrešaka.

Korisni je obrazac odvojiti prijedlog od izvršenja. Asistent umjetne inteligencije može predložiti klasifikaciju, odgovor ili ažuriranje polja. Korisnik ga može prihvatiti, urediti ili odbiti prije nego što dođe do posljedične radnje. Za tijekove rada s većim rizikom zahtijevajte pregled od strane određene uloge ili primijenite determinističku provjeru prije izvršenja.

Dobro produktno razmišljanje također tretira neuspjeh kao dizajnirano stanje. Nedostupna usluga, dokument koji nedostaje ili dvosmislen zahtjev ne bi trebali proizvesti rezultat koji izgleda autoritativno. Sučelje može reći što nije bilo dostupno, sačuvati rad korisnika i ponuditi sljedeći smisleni korak.

Tehnički voditelji trebali bi učiniti te putove vidljivima u arhitekturi. Bilježenje samo latencije i stopa pogrešaka nije dovoljno. Gdje je prikladno, zabilježite ishod na razini proizvoda: je li korisnik prihvatio prijedlog, znatno ga uredio, napustio tijek ili eskalirao zadatak. Ti signali otkrivaju pomaže li značajka.

Dajte vlasništvu oblik

Značajke umjetne inteligencije brzo prelaze granice. Produktni menadžer može biti vlasnik problema korisnika, inženjeri mogu biti vlasnici implementacije, dizajneri obrazaca interakcije, a operativni ili pravni partneri mogu definirati ograničenja. Ako vlasništvo ostane nejasno, između tih odgovornosti nastaju praznine.

Održiv tim dogovara nekoliko izričitih praksi:

• Održavajte mali skup reprezentativnih testnih slučajeva, uključujući teške i nepotpune ulaze.
• Pregledavajte kvalitetu izlaza zajedno s pitanjima pouzdanosti, troška i sigurnosti.
• Verzionirajte upute, pravila dohvaćanja i kriterije evaluacije kako se ponašanje proizvoda mijenja.
• Uspostavite put eskalacije za štetne, obmanjujuće ili osjetljive izlaze.
• Dodijelite nekoga da prati značajku nakon lansiranja, a ne samo do implementacije.

To je posebno važno za udaljene timove. Pisane odluke smanjuju rizik da ključne pretpostavke postoje samo na sastancima. Kratak zapis odluke koji objašnjava cilj korisnika, poznata ograničenja i kriterije uvođenja daje distribuiranim suradnicima zajedničku referentnu točku. Također čini primopredaje manje krhkima kada se prioriteti promijene.

Isporučujte uže, učite brže

Iskušenje kod umjetne inteligencije jest obećati općeg asistenta koji može učiniti sve. Široke tvrdnje stvaraju široka očekivanja, dok su temeljni kontekst i zaštitne mjere često uski. Usmjerena mogućnost obično je vrijednija.

Umjesto „pitajte bilo što o svom poslovanju”, izgradite „pronađite relevantnu politiku i sastavite odgovor za ovaj zahtjev podrške”. Umjesto „automatizirajte prodaju”, izgradite „pretvorite prijepis poziva u izmjenjive zadatke za daljnje praćenje”. Opseg stvara bolji kontekst, jasniju evaluaciju i sigurnije načine neuspjeha.

Uvodite postupno kada proizvod to dopušta. Počnite s ograničenom skupinom, promatrajte stvarno dovršavanje zadataka, prikupite primjere loših izlaza i poboljšajte cijelo iskustvo. Nemojte uspješnu demonstraciju tumačiti kao validaciju proizvoda. Demonstracija dokazuje mogućnost; ponovljena upotreba dokazuje korisnost.

Kod nosi obećanje

Produktno razmišljanje o umjetnoj inteligenciji ne znači da svaki programer treba postati produktni menadžer. Znači prepoznati da tehnički izbori prenose obećanja. Skriveni izvor, nepovratna radnja, neobjašnjena preporuka ili tihi neuspjeh svi korisniku nešto govore.

Najjači proizvodi umjetne inteligencije daju vjerodostojnije obećanje: ovaj sustav razumije posao u kojem pomaže, poznaje svoja ograničenja i ljudima daje način da zadrže kontrolu. To se obećanje izražava u produktnim odlukama, detaljima sučelja, operativnim zaštitnim mjerama i kodu.

Kada inženjeri nauče čuti jezik korisnikova rada, njihov kod postaje više od veze s modelom. Postaje pouzdan dio proizvoda na koji se ljudi doista mogu osloniti.