Značajke AI-ja rijetko zakazuju zato što model ne može generirati tekst. Zakazuju zato što okolni pozadinski sustav ne razumije poslovanje dovoljno dobro da bi modelu dao pravi kontekst, ograničio njegove radnje i provjerio njegov izlaz.

To je stvarni arhitektonski izazov: pretvoriti raspršeno operativno znanje u pouzdane sustave. AI asistent koji može odgovoriti na pitanje korisnika koristan je. Asistent koji može sigurno objasniti kašnjenje narudžbe, predložiti sljedeći korak radnog procesa i predati iznimku uz dokaze ima duboko razumijevanje poslovanja. Razlika je u dizajnu pozadinskog sustava.

Započnite s poslovnim činjenicama, a ne s upitima

Upit je sučelje, a ne izvor istine. Ako poslovno znanje živi u slobodno oblikovanom tekstu upita, svaka nova značajka postaje krhka: terminologija se mijenja, pravila se dupliciraju i nitko ne može objasniti zašto je sustav došao do određenog zaključka.

Umjesto toga, identificirajte trajne činjenice koje stoje iza odluke. Za asistenta za podršku pri narudžbama to može uključivati stanje narudžbe, status plaćanja, događaje isporuke, pravo na povrat, ovlasti korisnika i operativna pravila. Te činjenice zadržite u sustavima osmišljenima da njima upravljaju.

Praktična granica često izgleda ovako:

• Transakcijska baza podataka upravlja trenutačnim operativnim stanjem.
• Spremište dokumenata ili indeks za pretraživanje služi odobrenom znanju koje se može pretraživati.
• Usluga pravila procjenjuje eksplicitna pravila i ovlaštenja.
• Sloj orkestracije AI-ja dohvaća kontekst i koordinira alate.
• Model predlaže formulacije, klasifikacije ili strukturirane sljedeće radnje.

Ovo razdvajanje sprječava čestu pogrešku: traženje od modela da zaključi činjenice na koje pozadinski sustav može točno odgovoriti. “Može li ovaj korisnik otkazati narudžbu?” treba biti API poziv koji uzima u obzir pravila, a ne nagađanje na temelju odlomka povijesti računa.

Ugradite poslovni rječnik u API

API-ji pozadinskog sustava trebali bi govoriti konceptima domene, a ne apstrakcijama oblikovanima prema bazi podataka. Generički krajnji pristup poput GET /records?id=123 pruža malo pomoći AI radnom procesu ili ljudskom održavatelju. Krajnji pristup orijentiran na mogućnosti poput GET /orders/123/support-context može pružiti promišljen, revidiran prikaz onoga što podrška smije znati.

Taj prikaz trebao bi biti sažet, tipiziran i namjenski specifičan. Izbjegavajte izlaganje cijelog retka korisnika samo zato što je to praktično. Najbolji teret konteksta nije najveći teret; to je najmanji koji omogućuje ispravno donošenje sljedeće odluke.

final class OrderSupportContext
{
    public function __construct(
        public readonly string $orderId,
        public readonly string $status,
        public readonly bool $cancellationAllowed,
        public readonly array $shipmentEvents,
        public readonly array $applicablePolicies,
    ) {}
}

U PHP-u eksplicitni objekti za prijenos podataka pomažu učiniti ovu granicu vidljivom. Također čine testove jasnijima. Test može navesti da narudžba u stanju otpreme ima cancellationAllowed postavljeno na false, bez ikakvog uključivanja modela.

Dohvaćajte kontekst s namjerom i podrijetlom

Dohvaćanje se često opisuje kao problem pretraživanja. U produkciji je također problem autorizacije, svježine i sljedivosti. Svaki dio konteksta trebao bi odgovoriti na tri pitanja: je li relevantan, je li dopušten i odakle je došao?

Uz dokumente znanja pohranite metapodatke: zakupac, područje proizvoda, verzija pravila, datumi stupanja na snagu, razina osjetljivosti i identifikator izvora. Filtrirajte prema tim metapodacima prije rangiranja rezultata. Vrlo relevantan dokument drugog zakupca ili isteklo pravilo nisu koristan kontekst.

Ne dopustite modelu da izravno upituje produkcijske baze podataka. Postavite alate iza usko definiranih usluga s provjerenim ulazima, provjerama autorizacije, ograničenjima brzine, vremenskim ograničenjima i zapisivanjem revizije. Model može zatražiti getReturnEligibility; pozadinski sustav odlučuje je li taj zahtjev valjan i vraća strukturirani rezultat.

Za odgovore visokog rizika zadržite identifikatore izvora korištene tijekom odgovora. To podržava pregled, otklanjanje poteškoća i siguran razvoj kada se pravilo promijeni. Podrijetlo nije samo značajka usklađenosti; ono je način na koji inženjerski timovi dijagnosticiraju zašto je odgovor djelovao uvjerljivo, ali je bio pogrešan.

Neka model bude sudionik, a ne donositelj odluka

Modeli su snažni u tumačenju jezika i sastavljanju objašnjenja. Manje su prikladni kao konačni autoritet za pravila, prijenos novca, kontrolu pristupa ili nepovratne promjene radnog procesa.

Robustan radni proces odvaja prijedlog od izvršenja:

1. Aplikacija utvrđuje namjeru korisnika i prikuplja autorizirani kontekst.
2. Model vraća strukturirani izlaz, poput tražene radnje i objašnjenja.
3. Pozadinski sustav provjerava taj izlaz prema shemi i poslovnim pravilima.
4. Deterministička usluga izvršava dopuštenu radnju ili traži ljudski pregled.
5. Sustav bilježi odluku, ulaze, rezultat i relevantne verzije izvora.

Strukturirani izlaz i dalje treba tretirati kao nepouzdan ulaz. Provjeravajte enume, identifikatore, numeričke raspone i obavezna polja. Ako odgovor ne prođe provjeru, pokušajte ponovno samo kada ponovni pokušaj može razumno pomoći. Ponavljanje istog nevaljanog zahtjeva bez promjene konteksta gubi vrijeme i može prikriti sustavni problem.

Dizajnirajte za neuspjeh prije skaliranja

Pozadinski putevi ovisni o AI-ju uvode nove načine neuspjeha: spor pružatelj usluge, nedostupan indeks za dohvaćanje, neispravno oblikovan izlaz modela, zastarjeli podaci i dvosmislena namjera korisnika. To su normalni radni uvjeti, a ne rubni slučajevi.

Koristite vremenska ograničenja i ograničene ponovne pokušaje oko mrežnih poziva. Operacije pisanja učinite idempotentnima prihvaćanjem klijentski generiranog ključa idempotentnosti ili bilježenjem stabilnog identifikatora operacije. Ako se radnja potpomognuta AI-jem ne može sigurno dovršiti, sačuvajte korisnikov zahtjev i usmjerite ga na jasnu rezervnu opciju umjesto da izmišljate uspjeh.

Na primjer, zahtjev za promjenu narudžbe može se predstaviti kao trajna naredba prije početka bilo kakvog naknadnog rada. Radnik ga može obogatiti AI klasifikacijom, ali procesor naredbi mora neovisno potvrditi stanje narudžbe prije bilo kakve promjene. Time se sprječava da odgođeni radnik primijeni radnju na temelju zastarjelog konteksta.

Docker pomaže učiniti ove granice ponovljivima. Pokrenite PHP aplikaciju, radnika reda čekanja, bazu podataka i lokalne ovisnosti kao zasebno konfigurirane usluge. Konfiguraciju držite u varijablama okruženja, ali pri pokretanju provjerite potrebne vrijednosti. Spremnik koji se uspješno pokrene s nedostajućim vjerodajnicama ili nevaljanim nazivom reda čekanja zapravo nije zdrav.

Mjerite sustav, a ne samo model

Latencija i upotreba tokena važni su, ali nepotpuni pokazatelji. Mjerite kvalitetu dohvaćanja, neuspjehe alata, neuspjehe provjere sheme, učestalost rezervnih rješenja, starost reda čekanja i postotak zahtjeva koji zahtijevaju ljudski pregled. Te mjere segmentirajte prema radnom procesu, zakupcu gdje je prikladno i verziji pravila.

Zapisnici bi trebali omogućiti rekonstrukciju zahtjeva bez pohranjivanja nepotrebnog osjetljivog sadržaja. Identifikatori korelacije kroz HTTP zahtjeve, zadatke, pozive alata i zapise u bazu podataka ključni su. Kada se odgovor ospori, tim bi trebao moći utvrditi je li uzrok bio nedostajući kontekst, loše dohvaćanje, nedostupna usluga, nedostatak pravila ili loše ponašanje modela.

Trajna prednost je čitljiv pozadinski sustav

Duboko razumijevanje poslovanja ne proizlazi iz duljeg upita. Nastaje kada su poslovno stanje, pravila, znanje i radnje predstavljeni dovoljno jasno da i softver i ljudi mogu o njima rasuđivati.

Stoga najsposobniji AI pozadinski sustav nije onaj koji modelu daje najviše slobode. To je onaj koji mu daje prave dokaze, uske i korisne alate, čvrste zaštitne ograde i elegantne načine za neuspjeh. Izgradite taj temelj i AI postaje prilagodljivo sučelje prema poslovanju, a ne nepredvidiv sloj postavljen povrh njega.