Većina inicijativa umjetne inteligencije ne propada zato što je model slab. Propadaju zato što je poslovanje za njega nevidljivo.

Model opće namjene može napisati sažetak, sastaviti e-poruku ili objasniti isječak koda. No ne može pouzdano odlučiti kako vaša tvrtka postupa s osporenim računom, koje iznimke za korisnike zahtijevaju odobrenje ili zašto je jedan put implementacije siguran, a drugi nije. Ta se pravila često nalaze u raspršenim tiketima, sjećanjima iskusnih zaposlenika, zastarjelim dokumentima i ponašanju softvera.

Ako želite da umjetna inteligencija obavlja koristan posao unutar poslovanja, nemojte početi tako da od nje tražite da „nauči sve”. Osmislite softver, informacije i radne tijekove tako da važan kontekst bude izričit, dohvatljiv, provjerljiv i teško zaobići.

Učinite poslovno znanje operativnim

Dokumentacija je važna, ali sama proza rijetko je dovoljna. Pravilo zapisano u wikiju može objasniti namjeru procesa, no agentu treba više: trenutačno stanje slučaja, dopuštene radnje, osoba odgovorna za iznimke i način provjere rezultata.

Cilj nije svaku odluku pretvoriti u krutu automatizaciju. Cilj je razlikovati stabilna pravila od odluka koje zahtijevaju prosudbu te svako prikazati na odgovarajući način.

• Stabilna pravila pripadaju u provjereni kod, konfiguraciju, tablice odluka ili provjere pravila.
• Referentni materijal koji se mijenja pripada u održavan izvor znanja s jasnim vlasništvom i mogućnošću dohvaćanja.
• Ljudska prosudba treba biti predstavljena kao put eskalacije, uključujući informacije potrebne za brzu odluku.
• Povijesni dokazi trebaju ostati dostupni kao zapisi, a ne prešutno se tretirati kao trenutačna pravila.

Takvo razdvajanje čini sustav umjetne inteligencije pouzdanijim. Može koristiti jezik za tumačenje zahtjeva i sastavljanje konteksta, dok deterministički sustavi provode ograničenja ondje gdje je preciznost važna.

Oblikujte sučelja za agente, a ne samo za ljude

Aplikacije prilagođene ljudima često se oslanjaju na vizualne naznake, podrazumijevane korake i institucionalno znanje. Agentu umjetne inteligencije potrebno je sučelje s izričitim ulazima, izlazima, ovlastima i stanjima neuspjeha.

Razmotrite radni tijek podrške. Osoba može otvoriti nekoliko zaslona, pregledati bilješke o računu, usporediti status narudžbe i odlučiti treba li izdati zamjenu. Agent ne bi trebao oponašati svaki klik. Dajte mu usko definirane mogućnosti kao što su get_customer_context, get_order_status, create_replacement_request i escalate_case.

Svaka mogućnost treba imati jasan ugovor. Definirajte što prihvaća, što vraća, koje nuspojave stvara, tko je smije pozvati i što se događa kada je ne može dovršiti. To je uobičajen dizajn API-ja, ali disciplina postaje važnija kada pozivatelj može pogrešno razumjeti dvosmislen jezik.

Dajte prednost ograničenim radnjama

Alat koji prihvaća „učini što god je potrebno” prisiljava model da izmisli operativni plan. Alat koji stvara zahtjev za zamjenu unutar dokumentiranih pravila prihvatljivosti daje modelu siguran prostor za djelovanje.

Dobri alati za agente mali su, sastavljivi i vidljivi. Trebali bi vraćati strukturirane rezultate umjesto da se oslanjaju samo na narativni tekst. Također bi trebali izlagati smislene pogreške: „narudžba nije prihvatljiva”, „potrebno je odobrenje” i „zapis o korisniku nije dostupan” korisniji su od generičkog neuspjeha.

Izgradite sloj konteksta s vlasništvom

Dohvaćanje može pomoći agentu da pronađe relevantna pravila, pojedinosti o proizvodu i prethodne odluke. No dohvaćanje nije zamjena za upravljanje znanjem. Ako se temeljni materijali međusobno proturječe, nemaju datume ili nemaju vlasnika, model će iznijeti taj nered umjesto da ga riješi.

Namjerno stvorite sloj konteksta. Utvrdite mjerodavne izvore, dodijelite vlasnike, označite zamijenjeni materijal i koristite metapodatke koji odgovaraju stvarnom radu: linija proizvoda, regija, razina korisnika, status pravila, datum stupanja na snagu i razina pristupa.

Zatim dohvaćajte usko. Upit pretrpan svakim povezanim dokumentom skup je, težak za pregled i sklon proturječjima. Bolji radni tijek počinje činjenicama slučaja, dohvaća mali skup relevantnih trenutačnih izvora i navodi kada su dokazi nepotpuni.

Za radnje s velikim utjecajem sustav bi trebao sačuvati koji su izvori utjecali na preporuku. Taj zapis podržava pregled, otklanjanje pogrešaka i poboljšanje pravila bez pretvaranja da je sam model izvor istine.

Držite model izvan upravljačke ravnine

Jezični modeli korisni su planeri, tumači i generatori nacrta. Nisu idealni autoriteti za autorizaciju, računovodstvo, sigurnosne granice ili nepovratne promjene.

Dobar dizajn omogućuje modelu da predloži radnju, dok konvencionalni softver provjerava je li dopuštena. Model može reći: „Čini se da ovaj povrat ispunjava uvjete na temelju narudžbe i pravila.” Usluga transakcija trebala bi odlučiti može li se povrat doista izraditi.

Ovaj obrazac također poboljšava otpornost. Ako je odgovor modela nepravilno oblikovan, nedostupan ili nesiguran, okolni sustav može sigurno ponovno pokušati, zatražiti pojašnjenje, spremiti nacrt ili usmjeriti posao čovjeku. Ne mora nagađati je li došlo do djelomično dovršene radnje.

Zahtjev korisnika
  -> model tumači namjeru
  -> sustav dohvaća odobreni kontekst
  -> model predlaže sljedeću radnju
  -> provjere pravila i dozvola potvrđuju je
  -> alat izvršava dopuštenu radnju
  -> zapis revizije bilježi ishod

Važna je granica jednostavna: neka modeli upravljaju dvosmislenošću; neka sustavi provode obveze.

Procjenjujte radni tijek, a ne demonstraciju

Uglađena demonstracija obično sadrži čiste ulaze i idealne putanje. Produkcijski rad sadrži nepotpune zapise, proturječne upute, odgođene ovisnosti, neuobičajene dozvole i ljude koji zahtjeve formuliraju nepredvidljivo.

Procijenite cijeli radni tijek s realističnim slučajevima. Uključite uobičajene zahtjeve, granične slučajeve, podatke koji nedostaju, zastarjele dokumente, vremenska ograničenja alata, odbijene dozvole i pokušaje da se sustav pogura izvan njegova opsega.

Mjerite ishode važne za proces: je li došlo do ispravne eskalacije, je li nacrt sačuvao potrebne pojedinosti, je li radnja slijedila pravila i može li recenzent razumjeti zašto je sustav djelovao. Točnost pojedinačnog odgovora može biti korisna, ali rijetko je cijelo operativno pitanje.

Oblikujte za dostojanstvenu neizvjesnost

Agentu treba biti dopušteno reći da nema dovoljno dokaza. To nije slabost kada je alternativa samouvjerena, ali nepotkrijepljena radnja.

Dajte sustavu izričite mogućnosti: postaviti ciljano pitanje, navesti zapis koji nedostaje, stvoriti zadatak za pregled ili stati prije nuspojave. Ti putovi pretvaraju neizvjesnost u upravljiv posao umjesto skrivenog rizika.

Započnite s jednim radnim tijekom koji vrijedi poboljšati

Najbolji prvi projekti ograničeni su, česti i podložni pregledu. Pomislite na sažimanje povijesti računa prije predaje podršci, izradu nacrta zahtjeva za promjenu iz predloška, klasificiranje dolaznih dokumenata ili sastavljanje bilješki o izdanju iz odobrenih zapisa.

Odaberite radni tijek u kojem je trenutačni proces dovoljno dobro shvaćen da se može definirati koristan ishod. Mapirajte ulaze, odluke, alate, putanje neuspjeha i prijenose ljudima prije dodavanja modela. Ako je tu mapu nemoguće nacrtati, sam proces možda najprije zahtijeva pozornost.

Umjetna inteligencija postaje vrijedna kada je utkana u softver koji poslovnu stvarnost čini razumljivom. Jasna sučelja, znanje s dodijeljenim vlasnicima, ograničene radnje i vidljivi putovi pregleda čine više od samog povećanja sigurnosti agenta. Oni također olakšavaju ljudima upravljanje poslovanjem.

To je dublja prilika. Nemojte tek dodati asistenta umjetne inteligencije zbunjujućoj organizaciji. Izgradite sustave koji izražavaju način na koji organizacija funkcionira, a zatim umjetnoj inteligenciji dajte pažljivo osmišljeno mjesto unutar njih.