Većina AI projekata ne propada zato što je model slab. Propadaju zato što se od modela traži da djeluje u poslovanju koje nikada nije uistinu naučen razumjeti.

Sposoban model može sažeti ugovor, sastaviti odgovor podršci, napisati SQL upit ili usmjeriti zadatak. No ne zna automatski koji su uvjeti za kupce neprihvatljivi za pregovore, što „odobreno” znači u određenom radnom tijeku, gdje se nalazi jedini izvor istine ili kada mora stati i pitati čovjeka. Ti detalji čine poslovanje. Ako ostanu zarobljeni u glavama ljudi, raspršenim dokumentima i nedosljednim sustavima, AI agent će stvarati uglađena nagađanja.

Praktična prilika nije samo dodati sučelje za chat podacima tvrtke. Riječ je o osposobljavanju vaše baze koda, radnih tijekova i sustava znanja da izraze odluke koje iskusni ljudi već donose.

Poslovno znanje više je od dokumentacije

Timovi često započinju s bazom znanja i dohvaćanjem informacija: učitaju dokumente s pravilima, povežu indeks za pretraživanje, a zatim traže od modela da odgovara na pitanja. To može biti korisno, ali samo je jedan sloj poslovnog razumijevanja.

Stvarno operativno znanje ima najmanje četiri oblika:

• Činjenice: specifikacije proizvoda, podaci o računima, pravila određivanja cijena, tehničke operativne upute i aktualna pravila.
• Definicije: značenje pojmova specifično za tvrtku, kao što su kupac, obnova, incident, kvalificirani potencijalni kupac ili dovršena narudžba.
• Postupci: obvezni slijed radnji, odobrenja, provjera i primopredaja.
• Granice prosudbe: situacije u kojima automatizacija smije odlučiti, mora eskalirati ili mora odbiti djelovati.

Model može dohvatiti pravila povrata novca, a ipak pogrešno obraditi povrat ako pravila ne izražavaju uvjete prihvatljivosti, iznimke, granice ovlasti i sustav u kojem se konačna radnja mora evidentirati. Dobro uvođenje AI-ja čini ta pravila razumljivima i softveru i ljudima.

Počnite s odlukama, a ne s upitima

Najproduktivnije pitanje nije: „Što naš AI chatbot može učiniti?” Umjesto toga pitajte: „Koje se ponavljajuće odluke troše kvalificiranu pažnju i koje ih informacije i ograničenja oblikuju?”

Razmotrite agenta za podršku koji obrađuje zahtjev za pristup računu. Nejasna implementacija modelu bi mogla dati pristup člancima i zatražiti od njega da riješi prijavu. Korisna implementacija utvrđuje stvarni put odlučivanja: provjeriti identitet, pregledati status računa, odrediti je li poništavanje dopušteno, odabrati odobrenu radnju, ažurirati prijavu i eskalirati sumnjivu aktivnost.

Time se dvosmislen jezični zadatak pretvara u kontrolirani radni tijek. Model i dalje može pomoći pri tumačenju zahtjeva i sastavljanju jasnog odgovora, ali deterministički sustavi trebali bi upravljati provjerama identiteta, provjerama dozvola, promjenama računa i zapisima revizije.

Ta je podjela ključna. Jezični modeli snažni su u tumačenju nesavršenog unosa, izvlačenju strukturiranih informacija, uspoređivanju opcija i sastavljanju komunikacije. Nisu zamjena za poslovna pravila, kontrole pristupa, transakcijski integritet ili odgovorno odobrenje.

Mapirajte posao prije nego što ga automatizirate

Prije izrade agenta zapišite uski radni tijek jednostavnim jezikom. Utvrdite okidač, ulazne podatke, uključene sustave, dopuštene ishode, uvjete neuspjeha i vlasnika za iznimke. Ako tim ne može jasno objasniti radni tijek, model ga neće sam učiniti jasnijim.

1. Odaberite proces velikog opsega i jasnih granica, sa značajnim ali upravljivim troškom pogreške.
2. Prikupite reprezentativne primjere, uključujući nepotpune zahtjeve i nezgodne rubne slučajeve.
3. Definirajte izlaznu shemu i radnje koje sustav smije poduzeti.
4. Odvojite savjetodavno ponašanje od radnji koje mijenjaju zapise, troše novac, izlažu podatke ili kontaktiraju kupce.
5. Osmislite put eskalacije prije omogućavanja prve automatizirane radnje.

To je manje glamurozno od široke najave „AI transformacije”. Ali upravo tako sustavi postaju pouzdani.

Učinite znanje upotrebljivim za softver

AI sustavi najbolje funkcioniraju kada se važno znanje održava kao strukturiran, vlasnički određen materijal koji se može testirati, a ne kao arhiva proze. Dokument s pravilima može objasniti neko pravilo. Dobro osmišljen sustav može pravilo i kodirati u obliku koji aplikacije mogu provjeriti.

Primjerice, pravila dostave mogu navesti da ubrzana dostava nije dostupna za određena odredišta. Objašnjenje za kupce pripada dokumentaciji, no odluka o prihvatljivosti idealno bi trebala dolaziti iz usluge ili skupa pravila koji prihvaća narudžbu i vraća jasan rezultat. AI može pozvati tu mogućnost, objasniti rezultat i predložiti alternative. Ne bi trebao zaključivati o pravilu iz odlomka i nadati se da je taj odlomak ažuran.

{
  "destination": "example-region",
  "shipping_method": "expedited",
  "eligible": false,
  "reason_code": "METHOD_UNAVAILABLE_FOR_DESTINATION"
}

Strukturirani odgovori smanjuju dvosmislenost. Također olakšavaju testiranje ponašanja, lokalizaciju objašnjenja, praćenje neuobičajenih ishoda i promjenu pravila bez prepisivanja upita.

To ne znači da svaka poslovna odluka treba složen mehanizam pravila. To znači da implementacija treba odgovarati riziku. Pomoćnik za izradu nacrta niskog rizika može se uvelike oslanjati na dohvaćeni kontekst i ljudski pregled. Sustav koji mijenja status ugovora treba snažniju provjeru, izričitu ovlast i zapis koji se može revidirati o tome što se dogodilo.

Gradite agente s ograničenim ovlastima i jasnim ugovorima

Agent postaje koristan kada može učiniti više od generiranja teksta. Može pretraživati interno znanje, pregledati zapis, izraditi nacrt, ažurirati prijavu ili pokrenuti radni tijek. Svaki novi alat dodaje mogućnost, ali također proširuje površinu za pogreške.

Svaki alat tretirajte kao API ugovor. Definirajte njegove ulazne podatke, provjeravajte ih na poslužiteljskoj strani, ograničite njegove dozvole i vraćajte rezultate čitljive stroju. Nemojte se oslanjati na uputu modelu poput „upotrebljavaj ovo samo pažljivo” kao primarnu zaštitu. Sustav primatelj mora provoditi zaštitu.

• Agentu dodijelite najmanje potrebne ovlasti za njegov trenutačni zadatak.
• Za radnje s posljedicama zahtijevajte potvrdu ili ljudsko odobrenje.
• Upotrebljavajte idempotentne operacije kada bi ponovni pokušaji inače mogli stvoriti dvostruke promjene.
• Zabilježite radnju, ulazne podatke, rezultat i relevantan kontekst odobrenja.
• Vraćajte pogreške koje omogućuju djelovanje kako bi se agent mogao oporaviti ili prikladno eskalirati.

Posebno je koristan obrazac automatizacije koja najprije izrađuje nacrt. Neka sustav pripremi odgovor kupcu, zahtjev za promjenu, klasifikaciju ili predloženo ažuriranje zapisa. Osoba ga pregledava dok kvaliteta i kontrole rizika ne opravdaju daljnju automatizaciju. Time se stvara stvarna operativna vrijednost, a tim istodobno uči gdje bi granice trebale biti.

Procjenjujte poslovni proces, a ne samo odgovor

Procjene modela često se usredotočuju na to zvuči li odgovor ispravno. Kvaliteta u produkciji šira je od toga. Je li sustav dohvatio pravi zapis? Je li izbjegao izlaganje neovlaštenih informacija? Je li odabrao ispravan alat? Je li se suzdržao od djelovanja kada su nedostajali dokazi? Je li ostavio temeljni sustav u valjanom stanju?

Izradite slučajeve za procjenu na temelju stvarnih obrazaca radnog tijeka, a zatim uključite protivničke i nezgodne varijacije: proturječne upute, nedostajuća polja, zastarjelu dokumentaciju, nepodržane zahtjeve, dvosmislene identitete i kvarove nizvodnih usluga. Sustav koji uspijeva samo na urednim primjerima nije testiran; samo je demonstriran.

Pregledavajte neuspjehe po kategorijama. Je li problem nedostatak poslovnog znanja, slabo dohvaćanje, nejasno pravilo, nesiguran ugovor alata ili loš dizajn eskalacije? Ta je dijagnoza važna jer promjene upita same po sebi rijetko rješavaju problem radnog tijeka ukorijenjen u nejasnom vlasništvu ili nepouzdanim izvornim podacima.

Podučavajte organizaciju dok podučavate AI

Trajna vrijednost rada s AI-jem često je disciplina koju nameće. Timovi otkrivaju nedokumentirane iznimke, preklapajuća pravila, krhke primopredaje i pojmove koje različiti odjeli različito upotrebljavaju. To nisu odvraćanja od AI projekta. To je posao koji automatizaciju čini pouzdanom.

Osposobite svoj kod da poslovno znanje izlaže kroz jasne modele podataka, izričita pravila, dobro ograničene alate i vidljive radne tijekove. Osposobite svoje ljude da preuzmu vlasništvo nad tim znanjem i ažuriraju ga kako se poslovanje mijenja. Tada model postaje ono što bi trebao biti: fleksibilno sučelje između ljudske namjere i pouzdanih sustava.

Cilj nije AI koji zvuči kao da poznaje poslovanje. Cilj je sustav koji može dokazati, kroz svoje izbore i ograničenja, da je naučen kako poslovanje doista funkcionira.