Većina timova uči da domišljat prompt nije dizajn sustava. Može stvoriti impresivan demo, sažeti tiket ili izraditi upit. No čim značajka umjetne inteligencije mora donijeti važnu odluku unutar stvarnog proizvoda, susreće se s onime što promptovi ne mogu u potpunosti opisati: stvarnošću.

Stvarnost je trenutačni korisnik, njegova dopuštenja, stanje narudžbe, verzija API ugovora, transakcija baze podataka koja još nije potvrđena i operativna ograničenja usluge koja obrađuje zahtjev. Poučavanje umjetne inteligencije o toj stvarnosti problem je backend inženjerstva.

Produktivno pitanje nije: „Kako napisati bolji prompt?” Ono glasi: „Koji provjereni kontekst i sigurne radnje ovaj sustav može pružiti u ovom točnom trenutku?”

Kontekst je proizvod vaše arhitekture

Model umjetne inteligencije nema urođeno znanje o aktivnom stanju vaše aplikacije. Čak i kada ima široko tehničko znanje, ne zna je li određeni račun dospio na naplatu, je li zastavica značajke omogućena ili osoba koja pita smije li pregledati zapis kupca.

To znanje trebalo bi dolaziti s istih mjesta kojima vjeruje ostatak aplikacije: autentificiranih API-ja, domenskih usluga, baza podataka i pažljivo definiranih modela za čitanje. Model bi trebao primiti mali, relevantan prikaz stanja, a ne ispis svih podataka koje je prikladno serijalizirati.

Razmotrite asistenta za podršku kojem je postavljeno pitanje: „Zašto ovaj kupac ne može izvesti svoje izvješće?” Neodređeni prompt mogao bi uključiti e-adresu korisnika i tražiti od modela da dijagnosticira problem. Utemeljeni sustav može umjesto toga razriješiti autentificiranog aktera, dohvatiti mogućnosti pretplate ciljanog računa, provjeriti status zadatka izvješća i modelu pružiti izričite činjenice:

{
  "account_id": "acct_123",
  "plan": "standard",
  "export_feature_enabled": false,
  "report_status": "ready",
  "actor_can_manage_billing": true
}

Model sada može objasniti stvarno ograničenje bez nagađanja. Još važnije, temeljna usluga može provesti isto pravilo ako razgovor dovede do zahtjeva za nadogradnju ili promjene konfiguracije.

Dajte modelu mogućnosti, a ne pristup bazi podataka

Česta arhitektonska pogreška jest tretiranje integracije umjetne inteligencije kao prečaca oko granice aplikacije. Izravan pristup bazi podataka djeluje moćno jer čini dostupnim više informacija. Također zaobilazi provjeru valjanosti, autorizaciju, reviziju i poslovna pravila koja su se gradila godinama.

Umjesto toga, izložite uske operacije koje otkrivaju namjeru. Model bi trebao pozvati nešto poput getReportExportEligibility(accountId), a ne sastavljati proizvoljni SQL. Trebao bi zatražiti createRefundDraft(orderId, reason), a ne ažurirati tablicu plaćanja.

Dobri alati okrenuti umjetnoj inteligenciji nalikuju dobro dizajniranim internim API-jima. Imaju jasna imena, stroge ulazne sheme, ograničen izlaz i predvidljive načine neuspjeha. Također bi trebali razlikovati čitanje činjenica od unošenja promjena.

• Operacije čitanja trebale bi vraćati autoritativne, minimalne podatke.
• Operacije pisanja trebale bi provjeravati ulaze u domenskom sloju, bez obzira na to što je model dostavio.
• Nepovratne radnje ili radnje velikog utjecaja trebale bi zahtijevati izričit korak ljudske potvrde.
• Svaka radnja trebala bi se moći pripisati autentificiranom korisniku i zabilježiti u revizijskom tragu.

To nije trenje radi trenja. Tako značajka umjetne inteligencije postaje pouzdan sudionik u sustavu, a ne neobično rječit povlašteni korisnik.

Dizajnirajte za zastarjelo stanje i neuspjele pozive

Aktivni kontekst nije automatski ispravan kontekst. Backend sustavi puni su vremenskih problema: predmemorije istječu, replike kasne, poruke stižu sa zakašnjenjem, a drugi zahtjev promijeni resurs usred razgovora.

Radni tokovi umjetne inteligencije trebaju isti obrambeni dizajn kao i svaki drugi distribuirani radni tok. Ako alat čita zalihe prije preporuke kupnje, put naplate i dalje mora provjeriti zalihe kada rezervira artikl. Ako model priprema promjenu računa, operacija pisanja mora ponovno provjeriti dopuštenja i trenutačno stanje u trenutku izvršavanja.

Ne tražite od modela da tehničke neuspjehe popravlja prozom. Vratite strukturirane pogreške iz alata i prepustite aplikaciji odluku o tome što se može ponovno pokušati. Primjerice, prolazni istek vremena usluga može ponovno pokušati prema ograničenoj politici; neuspjeh autorizacije treba predstaviti kao čvrsto ograničenje; pogreška provjere valjanosti može pozvati korisnika da pojasni unos.

try {
    $result = $billingService->createUpgradeDraft(
        accountId: $accountId,
        requestedPlan: $plan
    );
} catch (PlanNotAvailable $exception) {
    return ['status' => 'unavailable'];
} catch (TemporaryBillingFailure $exception) {
    return ['status' => 'retry_later'];
}

Važno je da model tumači kontrolirani rezultat. Ne postaje odgovoran za odlučivanje o tome je li iznimka bezopasna, može li se ponovno pokušati ili je dokaz da se poslovno pravilo promijenilo.

Neka domenski jezik obavi težak posao

Sustave je lakše povezati s umjetnom inteligencijom kada su njihovi domenski koncepti već izričiti. „Narudžba”, „pošiljka”, „otkazivanje na čekanju” i „ispunjavanje uvjeta za povrat” korisni su koncepti. Zbirku generičkih CRUD krajnjih točaka i preopterećenih polja statusa mnogo je teže sigurno koristiti.

Tu se podudara održivost i spremnost za umjetnu inteligenciju. Granica usluge koja izražava poslovnu namjeru programerima daje stabilno mjesto za pravila, testove, vidljivost i alate okrenute modelu. Također sprječava da tekst prompta postane sjenovita implementacija logike vašeg proizvoda.

Zadržite pravila izvan razgovora

Promptovi mogu objasniti pravila, ali ne bi trebali biti konačni autoritet za njih. Ako samo administratori smiju brisati API ključeve, provedite to pravilo u krajnjoj točki. Ako se račun može stornirati samo prije namire, provedite to u domeni naplate. Ako podaci kupca moraju biti maskirani za ulogu podrške, oblikujte odgovor prije nego što stigne do modela.

Korisno je pravilo jednostavno: ako bi kršenje pravila bilo greška kada bi čovjek kliknuo gumb, ono je također greška kada umjetna inteligencija pozove alat.

Promatrajte cijeli put odluke

Otklanjanje pogrešaka značajke umjetne inteligencije zahtijeva više od pohranjivanja konačnog odgovora. Potrebna vam je dovoljna vidljivost da biste razumjeli koji je kontekst odabran, koji su alati pozvani, što su vratili i je li radnja uspjela. Pažljivo pristupite redakciji: zapisnici bi trebali biti korisni, a da ne postanu drugo neupravljano spremište podataka kupaca.

I testovi su ovdje važni. Jedinično testirajte domenske operacije. Ugovorno testirajte sheme alata. Dodajte testove scenarija za granice dopuštenja, nedostajuće zapise, konfliktno stanje i nedostupne ovisnosti. Formulacija modela može varirati; invarijante sustava ne mogu.

Trajna prednost je pouzdan kontekst

Promptovi će se nastaviti mijenjati. Modeli će se poboljšavati. Ni jedno ni drugo ne uklanja potrebu za jasnim modeliranjem istine vašeg sustava.

Timovi koji grade trajne značajke umjetne inteligencije neće biti oni s najdužim uputama. Bit će to oni koji povezuju modele s autoritativnim stanjem, nude ograničene mogućnosti, ponovno provjeravaju svaku značajnu radnju i čuvaju arhitektonske granice koje softver čine pouzdanim. Poučite umjetnu inteligenciju stvarnosti svojeg sustava i ona u njemu može postati istinski korisna.