Većina neuspjeha u programiranju uz pomoć AI-ja ne počinje slabim upitom. Počinju aplikacijom koja ima skrivena pravila, nejasno vlasništvo i poslovne odluke raspršene po kontrolerima, upitima baze podataka, uvjetima korisničkog sučelja i nečijem pamćenju.

Jezični model može generirati kôd, klasificirati zahtjeve, sažimati dokumente ili upravljati alatima. No ne može pouzdano djelovati prema poslovnoj logici koja nikada nije izričito definirana. Ako agent mora odlučiti treba li odobriti povrat novca, usmjeriti slučaj podrške, odobriti trošak ili ažurirati zapis kupca, potrebno mu je više od upita koji opisuje namjere tvrtke. Potrebne su mu softverske granice koje te namjere čine izvršivima, testabilnima i vidljivima.

Praktična je promjena jednostavna: prestanite tretirati upite kao primarno mjesto za poslovnu logiku. Tretirajte ih kao sučelje sustava čija pravila žive u kôdu, podacima i kontroliranim radnim tijekovima.

Upiti nisu trajni mehanizam za pravila

Upiti su korisni za izražavanje ciljeva, konteksta, tona i uputa specifičnih za zadatak. Nisu idealni za provedbu pravila koja moraju biti precizna i ponovljiva.

Razmotrite AI agenta za podršku kojemu je zadatak obraditi zahtjeve za otkazivanje. U upitu može stajati da kupci mogu dobiti povrat novca u roku od 30 dana, osim ako su iskoristili premium uslugu ili je njihov račun na provjeri. To zvuči jasno dok agent ne mora odgovoriti na praktična pitanja: Koja vremenska oznaka određuje datum kupnje? Što se računa kao korištenje? Tko stavlja račun na provjeru? Može li voditelj poništiti rezultat?

To su pitanja pravila, ali ne bi se trebala iznova rješavati u izlazu modela. Pripadaju sloju domene s imenovanim konceptima, strukturiranim ulazima i determinističkim ishodima.

type RefundDecision =
  | { eligible: true; reason: "within_window" }
  | { eligible: false; reason: "outside_window" | "service_consumed" | "account_review" };

function assessRefund(order: Order, account: Account, now: Date): RefundDecision {
  if (account.isUnderReview) {
    return { eligible: false, reason: "account_review" };
  }

  if (order.premiumServiceConsumed) {
    return { eligible: false, reason: "service_consumed" };
  }

  const ageInDays = (now.getTime() - order.paidAt.getTime()) / 86_400_000;

  return ageInDays <= 30
    ? { eligible: true, reason: "within_window" }
    : { eligible: false, reason: "outside_window" };
}

Model može prikupiti informacije koje nedostaju, objasniti odluku jednostavnim jezikom i pokrenuti odobreni radni tijek. Aplikacija bi trebala utvrditi ispunjava li korisnik uvjete.

Dizajnirajte AI kao klijenta svoje domene

Korisno arhitektonsko pravilo jest AI agentu dati isto poštovanje i ograničenja kao bilo kojem drugom vanjskom klijentu. Ne bi trebao izravno pristupati produkcijskim tablicama, zaključivati o ovlaštenjima na temelju proze niti sastavljati proizvoljne operacije pisanja.

Umjesto toga, izložite pažljivo dizajnirane mogućnosti. Mogućnost bi trebala predstavljati poslovnu radnju, a ne operaciju baze podataka niske razine. Dajte prednost createRefundRequest u odnosu na updateOrderStatus. Dajte prednost assignCaseToQueue u odnosu na setOwnerId.

Ta je razlika važna jer poslovna radnja može provjeriti ovlaštenje, provesti prijelaze stanja, stvoriti zapis revizije i vratiti smislen rezultat. Sirovo ažuriranje ne može samo po sebi izraziti te zaštitne mjere.

Učinite ugovore alata uskim i izričitima

Svaki alat dostupan agentu operativno je obećanje. Neka njegova ulazna shema bude mala, provjerite je na poslužitelju i vratite strukturirane ishode koje model može koristiti bez nagađanja.

{
  "caseId": "CS-1042",
  "targetQueue": "billing",
  "reason": "refund_question"
}

Alat bi trebao odbiti nevaljani red, slučaj kojemu pozivatelj ne može pristupiti ili prijelaz koji krši pravila radnog tijeka. Pogreška bi trebala biti djelotvorna, poput „slučaj je već zatvoren”, a ne nejasan kvar poslužitelja. To agentu omogućuje oporavak objašnjavanjem ograničenja ili traženjem ljudske intervencije.

Ne oslanjajte se na uputu u upitu poput „pozovi ovaj alat samo za ovlaštene korisnike”. Provedite ovlaštenje unutar alata. Smjernice u upitu oblikuju ponašanje; kontrole aplikacije uspostavljaju jamstva.

Pretvorite prešutno znanje u izvršivu politiku

AI inicijative često otkrivaju korisnu nelagodu: timovi znaju da je njihova poslovna logika stvarna, ali ne mogu pokazati gdje se nalazi. Pravilo može biti podijeljeno između prodajnog priručnika, makronaredbe podrške, proračunske tablice i uvjeta skrivenog u staroj usluzi.

Prije povezivanja agenta s radnjama koje imaju posljedice, odredite na koje će odluke utjecati. Za svaku definirajte:

• ulaze potrebne za donošenje odluke;
• mjerodavni izvor za svaki ulaz;
• dopuštene ishode i prijelaze stanja;
• osobu ili sustav odgovoran za iznimke;
• podatke revizije potrebne za kasnije objašnjenje onoga što se dogodilo.

Ovaj rad nije birokracija oko AI-ja. To je inženjerski rad potreban kako bi automatizacija bila pouzdana. Ako se politika ne može dovoljno jasno predstaviti da bi se testirala, previše je nejasna da bi se sigurno delegirala modelu.

Odvojite prosudbu od izvršavanja

Modeli su vrijedni kada su jezik, dvosmislenost i nepotpune informacije ključni za zadatak. Mogu izvući namjeru iz e-pošte, sažeti dugu povijest slučaja, otkriti da zahtjev treba eskalaciju ili sastaviti odgovor prilagođen pitanju kupca.

Te prednosti ne zahtijevaju davanje modelu konačne kontrole nad nepovratnim radnjama. Robustan radni tijek odvaja tumačenje od izvršavanja:

1. Model tumači zahtjev i predlaže strukturiranu radnju.
2. Aplikacija provjerava radnju prema poslovnim pravilima i ovlaštenjima.
3. Radni tijek radnju izvršava, traži odobrenje ili vraća jasno ograničenje.
4. Model korisniku priopćava provjereni rezultat.

Na primjer, agent može prepoznati da se račun čini dupliciranim. Može prikupiti identifikatore računa i pripremiti preporuku. Služba za naplatu trebala bi odlučiti je li uvjet dupliciranja ispunjen i može li se izdati odobrenje. Za slučajeve s velikim utjecajem služba može stvoriti zadatak za odobrenje umjesto automatske primjene odobrenja.

Ovaj obrazac također poboljšava korisničko iskustvo. Umjesto da izmišlja sigurnost, agent može reći što je pronašao, koje je pravilo primijenjeno i što će se dogoditi sljedeće.

Gradite za ponovne pokušaje, neuspjeh i pregled

Stvarni sustavi nisu demonstracije s jednim potezom. Mreže otkazuju, korisnici mijenjaju mišljenje, alatima istječe vrijeme, a model može ponoviti zahtjev nakon što primi nejasan odgovor. Dizajnirajte poslovne operacije tako da podnose tu stvarnost.

Koristite idempotentnost za radnje pisanja kako ponovljeni zahtjev ne bi stvorio dva povrata novca ili dva tiketa podrške. Zabilježite identitet zahtjeva, aktera, ulaze, rezultat provjere i rezultirajuće stanje. Kada je potrebno, dugotrajni rad učinite asinkronim, vraćajući status koji agent može provjeriti umjesto da se pretvara da je završetak trenutan.

Ljudski pregled trebao bi biti prvoklasan ishod, a ne neugodan rezervni izlaz. Dobra eskalacija uključuje relevantan kontekst, predloženu radnju, pravilo koje je blokiralo automatizaciju i točnu odluku koju recenzent mora donijeti. To smanjuje trenje pri predaji uz očuvanje odgovornosti.

Testirajte sustav, a ne samo upit

Testovi upita i dalje su važni, osobito za izdvajanje namjere i kvalitetu odgovora. No testovi veće vrijednosti provjeravaju ponašanje domene oko modela. Testirajte nevaljane argumente alata, neovlaštene zahtjeve, zastarjele zapise, duplikate prijava, djelomične neuspjehe i sukobljena stanja pravila.

Izlaz modela držite ograničenim gdje je to moguće. Tražite strukturirana polja, provjerite ih i nepravilno oblikovan izlaz tretirajte kao ulaznu pogrešku od koje se može oporaviti. Model može biti probabilistički; okolni sustav ne bi smio biti nemaran.

Trajna je pouka da AI postaje korisniji kako vaš softver postaje izričitiji o tome u što vjeruje, što dopušta i što bilježi. Upiti mogu učiniti da agent zvuči sposobno. Dobro arhitektonski osmišljena poslovna logika čini ga pouzdanim. Kada je model povezan s jasnim mogućnostima domene umjesto s nejasnim uputama i širokim pristupom, dobivate nešto vrjednije od impresivne demonstracije: automatizaciju koja zaslužuje mjesto u stvarnom radu.