Većina integracija umjetne inteligencije ne uspijeva iz iznenađujuće uobičajenog razloga: model dobije zadatak, ali ne i logiku koja taj zadatak čini smislenim.

Model može sažeti tiket, sastaviti e-poruku, klasificirati dokument ili pozvati alat. Ono što ne može pouzdano zaključiti jest nepisani sustav ograničenja iza tih radnji: koja su stanja korisnika važna, što znači „odobreno”, kamo pripadaju iznimke, tko može poništiti odluku i koje je operacije sigurno automatizirati.

Korisna promjena je prestati tretirati umjetnu inteligenciju kao pametan tekstualni okvir i početi je tretirati kao sudionika u sustavu. Kao i svakom sudioniku, potrebni su joj jasna uloga, ograničeno sučelje, relevantan kontekst i povratna informacija kada pogriješi.

Logika je integracijski sloj

Poslovna logika često je raspoređena među poljima baze podataka, kodom usluga, dijagramima radnih tokova, priručnicima za podršku i akumuliranim znanjem ljudi koji znaju gdje su zamke. Značajka umjetne inteligencije postaje pouzdana kada je ta logika dovoljno eksplicitna da je model može koristiti.

Razmotrite pomoćnika za podršku koji sastavlja odgovore za neuspjela plaćanja. Općeniti upit mogao bi od njega zatražiti da „pomogne korisniku riješiti problem s plaćanjem”. To zvuči razumno, ali ostavlja ključna pitanja bez odgovora. Je li plaćanje odbijeno ili još uvijek na čekanju? Je li korisnik već pokušao ponovno? Je li račun zaključan? Nameće li regija drukčiji postupak povrata? Treba li pomoćnik ponuditi ponovni pokušaj, zatražiti provjeru ili eskalirati?

Modelu ne treba svaki red iz svake tablice. Potreban mu je sažet, pouzdan prikaz činjenica i pravila relevantnih za odluku.

{
  "payment_status": "declined",
  "retry_count": 1,
  "account_locked": false,
  "eligible_actions": ["retry_payment", "update_payment_method"],
  "prohibited_actions": ["issue_refund"],
  "escalation_required": false
}

Ta struktura čini dvije stvari. Modelu daje potreban kontekst i ograničava iskušenje da izmisli radnju koju bi okolni sustav odbio.

Odvojite prosudbu od ovlasti

Umjetna inteligencija korisna je za tumačenje: izdvajanje namjere, uočavanje obrazaca, predlaganje sljedećeg koraka i pretvaranje strukturiranih činjenica u jasan jezik. Mnogo je manje prikladna kao konačni autoritet za pravila koja moraju biti precizna, provjerljiva ili dosljedno provedena.

Dobar dizajn prepušta konvencionalnom softveru determinističke odluke. Vaša aplikacija trebala bi izračunavati dozvole, podobnost, cijene, stanja, provjere pravila i stanje radnog toka. Model zatim može objasniti rezultat, zatražiti informacije koje nedostaju, rangirati opcije ili pripremiti nacrt radnje.

To nije ograničenje zbog kojeg se treba ispričavati. To je arhitektura koja umjetnu inteligenciju čini sigurnijom i lakšom za poboljšavanje. Ako se pravilo promijeni, ažurirajte ga na jednom mjestu. Nemojte se nadati da će se revidirani odlomak u upitu dosljedno primjenjivati na svakom putu.

Koristite alate kao uske ugovore

Kada agent može djelovati na sustavu, svaki bi se alat trebao ponašati kao pažljivo dizajniran API, a ne kao mogućnost bez otvorenih granica. Dajte alatima specifična imena, ograničene ulaze, jasne povratne vrijednosti i provjere autorizacije koje se provode izvan modela.

Na primjer, create_refund_request sigurniji je od širokog alata manage_payment. Prvi može zahtijevati identifikator narudžbe i razlog, provjeriti podobnost na poslužitelju i vratiti identifikator zahtjeva ili strukturirano odbijanje. Model može odlučiti zatražiti radnju; ne bi trebao moći zaobići uvjete za njezino izvršavanje.

• Izložite samo radnje koje agentu doista trebaju.
• Provjerite svaki ulaz alata na poslužitelju.
• Gdje je moguće, vratite strojno čitljive razloge neuspjeha.
• Učinite radnje sa značajnim posljedicama podložnima pregledu, poništavanju ili obome.
• Zabilježite ulaze, pozive alata, rezultate i konačni ishod vidljiv korisniku.

Podučavajte pravila kontekstom, a ne željenim upitima

Upiti su vrijedni, ali „budite točni” nije dizajn sustava. Snažne upute utvrđuju ulogu, prioritete, zabranjeno ponašanje, format izlaza i pravila eskalacije. Najbolje funkcioniraju kada su uparene s aktualnim kontekstom dohvaćenim iz mjerodavnih izvora.

Pretpostavimo da interni pomoćnik za operacije pomaže raspoređivati terenski rad. Njegove upute mogu navoditi da sigurnosna ograničenja imaju prednost pred ciljevima isporuke i da mora eskalirati kada su podaci o dodjeli u sukobu. Tijekom izvođenja aplikacija pruža certifikate tehničara, potrebne kvalifikacije radnog naloga, ograničenja putovanja i trenutačnu politiku raspoređivanja.

Ključna je razlika između stabilnih smjernica i promjenjivih činjenica. Stabilne smjernice pripadaju uputama i definicijama pravila pod kontrolom verzija. Promjenjive činjenice trebale bi stizati putem pouzdanog dohvaćanja ili konteksta koji pruža aplikacija. Miješanje obaju u golem upit stvara zastarjele informacije, otežava otklanjanje pogrešaka i povećava mogućnost da nerelevantan materijal omete model.

Dizajnirajte za neizvjesnost i neuspjeh

Modeli mogu pogrešno razumjeti dvosmislen zahtjev, proizvesti nevažeći argument alata ili odabrati opciju koja izgleda uvjerljivo, ali je u sukobu sa skrivenim ograničenjem. Mrežni pozivi mogu isteći. Naknadna usluga može odbiti zahtjev nakon što agent objasni što namjerava učiniti.

Produkcijski radni tok treba eksplicitno ponašanje za te slučajeve. Agent bi trebao znati kada postaviti pitanje za pojašnjenje, kada ponovno pokušati sigurnu operaciju čitanja i kada posao predati osobi. Nikada ne bi smio implicirati da je radnja uspjela dok mjerodavni sustav ne potvrdi uspjeh.

Za operaciju pisanja slijed je obično jednostavan: provjerite zahtjev, izvršite radnju putem aplikacije, pregledajte vraćeni status i tek tada priopćite rezultat. Ako radnja ne uspije, odgovor bi trebao opisati sljedeći koristan korak bez otkrivanja internih pojedinosti implementacije ili pretvaranja da se neuspjeh nije dogodio.

Procijenite cijeli put

Timovi često testiraju daje li model ugodan odgovor. To je potrebno, ali nije dovoljno. Testirajte radni tok kao lanac: dohvaćanje konteksta, zaključivanje modela, odabir alata, provjera ulaza, odgovor alata, ponašanje pri ponovnom pokušaju i konačna komunikacija.

Izradite reprezentativne slučajeve prije širokog uvođenja. Uključite uobičajene zahtjeve, podatke koji nedostaju, sukobljene upute, neuspjehe dozvola, zastarjele zapise, nesigurne zahtjeve i dvosmislen jezik. Za svaki slučaj definirajte kako izgleda dobar ishod. Ponekad ispravan ishod nije dovršetak; to je pravodobno odbijanje, pitanje za pojašnjenje ili eskalacija.

Evaluacija bi se trebala nastaviti nakon objave. Pregledavajte obrasce neuspjeha, a ne samo prosječan uspjeh. Ako se ista iznimka pojavljuje opetovano, poboljšajte temeljni radni tok ili izvorne podatke umjesto da beskonačno dodajete upute u upit.

Započnite s ograničenim radnim tokom

Najjače rane značajke umjetne inteligencije rijetko su najteatralnije. Odaberite rad koji ima jasan ulaz, koristan izlaz, dostupne izvorne podatke i ljudsku ili determinističku kontrolnu točku za važne posljedice. Sastavljanje strukturiranog sažetka incidenta, razvrstavanje dolaznih zahtjeva ili priprema kontrolnog popisa za pregled promjena mogu pružiti vrijednost uz otkrivanje stvarnih integracijskih izazova.

Započnite usko, promatrajte kako ga ljudi koriste i proširujte samo kada sustav može objasniti zašto je dao preporuku i što je zatim učinio. To gradi povjerenje u proizvod i uči tim koji su dijelovi vlastite logike prethodno bili implicitni.

Umjetna inteligencija postaje korisna kada postane odgovorna

Trajna prilika nije zamijeniti softversku logiku modelom. Ona je povezati model sa softverskom logikom na način koji složene sustave čini lakšima za korištenje.

Poučite umjetnu inteligenciju stanju koje joj je potrebno. Postavite pravila tamo gdje se mogu provoditi. Dajte joj uske, pouzdane alate. Očekujte neuspjehe i mjerite cijeli radni tok. Kada sustav umjetne inteligencije može zaključivati unutar stvarnih ograničenja i pokazati svoj rad kroz pouzdane ishode, prestaje biti sučelje noviteta i postaje sposoban dio proizvoda.