Promptiranje je korisno sučelje, ali je loše mjesto za skrivanje pravila koja osiguravaju ispravnost poslovanja. Prompt može objasniti pravilo; ne može pouzdano postati to pravilo. Kada značajka umjetne inteligencije dotiče određivanje cijena, dozvole, zalihe, podatke o kupcima ili vanjski API, sustav treba više od uvjerljivih uputa. Potrebna mu je poslovna logika ugrađena u jezgru aplikacije.

To jezične modele ne čini manje vrijednima. Daje im sigurniju i korisniju ulogu: tumačenje jezika, predlaganje radnji i pomoć korisnicima unutar granica koje backend može provesti.

Promptovi opisuju namjeru; softver je provodi

Prompt može reći: „Nikada nemoj ponuditi popust veći od 15 % i samo kupcima koji ispunjavaju uvjete.” To zvuči jasno dok kupac ne zatraži iznimku, model pogrešno ne protumači kontekst računa ili naknadna izmjena prompta ne promijeni formulaciju. Poslovno je pravilo tada raspršeno kroz prirodni jezik i teško ga je pouzdano testirati.

Umjesto toga, neka AI zatraži jasno definiranu operaciju, a neka običan aplikacijski kôd odluči je li dopuštena. Model može prepoznati da kupac traži popust. Ne bi trebao biti konačni autoritet za ispunjavanje uvjeta za popust.

final class DiscountPolicy
{
    public function maximumFor(Customer $customer): int
    {
        if (! $customer->isEligibleForDiscount()) {
            return 0;
        }

        return $customer->isPremium() ? 15 : 5;
    }

    public function allows(Customer $customer, int $percentage): bool
    {
        return $percentage >= 0
            && $percentage <= $this->maximumFor($customer);
    }
}

Model može proizvesti predloženi postotak. Vaš API ga validira, učitava kupca iz baze podataka, poziva pravilo, bilježi odluku i tek tada mijenja narudžbu. To razdvajanje nije ceremonijalna arhitektura. Ono omogućuje da se pravilo ispita, testira i dosljedno primjenjuje u pomoćniku za razgovor, administratorskoj ploči, zakazanom zadatku i mobilnoj aplikaciji.

Dajte modelu mogućnosti, a ne pristup bazi podataka

Čest je prečac omogućiti AI integraciji da sastavlja SQL, poziva široke interne krajnje točke ili radi s računom usluge koji može učiniti sve. Zbog toga demonstracije djeluju brzo, a produkcijski incidenti neizbježno.

Dizajnirajte uske alate oko poslovnih radnji. Pomoćniku za podršku možda trebaju findOrder, getShipmentStatus i requestRefundReview. Vjerojatno mu ne trebaju krajnja točka za upite opće namjene ni dozvola za označavanje bilo koje uplate kao refundirane.

Svaka mogućnost trebala bi imati dosadno izričit ugovor:

• Ulazi imaju tipove, obavezna polja i ograničene vrijednosti.
• Backend izvodi osjetljivi kontekst, poput autentificiranog korisnika i stanara, umjesto da vjeruje identifikatorima koje je pružio model.
• Autorizacija se odvija u implementaciji alata, a ne u tekstu prompta.
• Nuspojave su namjerne, prema potrebi idempotentne i podložne reviziji.
• Odgovori otkrivaju samo podatke potrebne za sljedeću odluku.

Ovaj pristup također poboljšava dizajn API-ja. Ako je teško definirati mali, siguran alat za neku operaciju, temeljni poslovni tijek rada možda je već previše zapetljan. AI integracije imaju naviku otkrivati nejasne granice koje su tradicionalni zasloni uspijevali sakriti.

Čuvajte istinu u bazi podataka, a pravila u domeni

Jezični modeli dobri su u radu s dvosmislenim tekstom. Nisu zamjena za transakcijsko stanje. Trenutačno stanje, raspoložive zalihe, status pretplate i povijest odobrenja pripadaju sustavima osmišljenima za očuvanje istine pri istodobnim promjenama.

Pouzdan tijek rada čita autoritativno stanje neposredno prije značajne radnje. Nemojte od modela tražiti da zapamti da je artikl ranije u razgovoru bio na zalihi. Provjerite zalihe pri stvaranju rezervacije. Nemojte pretpostaviti da račun i dalje ispunjava uvjete zato što je prethodni odgovor alata to naveo. Ponovno procijenite ispunjavanje uvjeta pri podnošenju zahtjeva.

Za operacije koje utječu na više zapisa upotrijebite transakcijske mogućnosti svoje baze podataka i okvira. Primjerice, rezervacija može zaključati ili na drugi način sigurno ažurirati zalihe, stvoriti zapis o rezervaciji i emitirati događaj tek nakon što transakcija uspije. AI sloj trebao bi primiti rezultat, a ne orkestrirati djelomično dovršena pisanja kroz niz nagađanja.

Ovdje postoji važna razlika: model može pomoći odlučiti koji tijek rada korisnik namjerava; domenski sloj odlučuje može li se taj tijek rada ostvariti.

Neka neuspjesi budu dio dizajna proizvoda

Značajke umjetne inteligencije ne uspijevaju na uobičajene backend načine, kao i na načine specifične za modele. Poziv alata može sadržavati nevaljane argumente. Nizvodna usluga može prekoračiti vremensko ograničenje. Ponovni pokušaj može duplicirati nuspojavu. Model može zatražiti radnju koju trenutačni korisnik ne može izvršiti.

Izgradite podršku za te putanje prije dodavanja uglađivanja. Validirajte ulaze alata na granici. Vratite strukturirane kategorije pogrešaka koje AI sloj može pretvoriti u koristan jezik. Upotrijebite ključeve idempotentnosti za izvana vidljive operacije pisanja kada klijent ili radnik može ponoviti pokušaj. Bilježite identitet zahtjeva, naziv alata, rezultat autorizacije i ishod bez neselektivnog bilježenja osjetljivog sadržaja.

Ne bi svaka pogreška trebala pokrenuti još jedan pokušaj modela. Ponovni pokušaj nedostupne usluge čitanja može biti razuman unutar kontroliranog pravila. Ponovni pokušaj terećenja, povrata novca ili izmjene računa bez strategije idempotentnosti nije. Deterministička pravila ponavljanja pripadaju aplikacijskom kôdu, gdje se mogu pregledati ograničenja vremenskog prekoračenja i ponašanje pri neuspjehu.

Upotrebljavajte promptove za usmjeravanje, a ne za upravljanje

Promptovi su i dalje važni. Definiraju ton, objašnjavaju dostupne mogućnosti, pomažu modelu zatražiti nedostajuće pojedinosti i govore mu kako predstaviti uspješan ishod. Također mogu smanjiti nepotrebne pozive alata opisivanjem očekivanog tijeka rada.

No promptove tretirajte kao prilagodljivi sloj. Razvijat će se kako korisnici otkrivaju nove formulacije, rubne slučajeve i očekivanja. Osnovna poslovna logika treba drugačiji standard: verzionirani kôd, automatizirane testove, jasno vlasništvo i postupak implementacije koji se može vratiti.

Praktičan je test jednostavan: kada bi se prompt uklonio ili pogrešno razumio, bi li sustav i dalje štitio kupca i poslovanje? Ako je odgovor ne, pravilo pripada ispod prompta.

Pouzdan AI sustav uglavnom je pouzdan inženjering

Najjači AI proizvodi ne traže od modela da odjednom postane baza podataka, sigurnosna granica, mehanizam pravila i operativni tim. Oni spajaju fleksibilno jezično sučelje s konvencionalnom inženjerskom disciplinom: malim API-jima, izričitom autorizacijom, transakcijskim rukovanjem podacima, uočljivim neuspjesima i testovima oko odluka koje su važne.

Takav dizajn možda djeluje manje čarobno od golemog prompta povezanog sa svakim internim sustavom. Također ga je lakše održavati kada se zahtjevi promijene, lakše objasniti tijekom incidenta i sigurnije mu je povjeriti stvarni rad. Neka AI upravlja neizvjesnošću u jeziku. Neka vaša jezgra upravlja izvjesnošću u poslovanju.