Značajka umjetne inteligencije rijetko zakaže zato što je upit bio prekratak. Zakaže zato što okolni backend inteligenciju tretira kao jedan udaljeni poziv umjesto kao produkcijsku sposobnost s ulazima, pravilima, stanjem, vidljivošću i obradom pogrešaka.

Korisni mentalni model jednostavan je: model je ovisnost. Jezgra AI inteligencije vašeg backenda sustav je koji tu ovisnost čini sigurnom, ponovljivom i vrijednom.

Neka aplikacija upravlja tijekom rada

Jezični model ne bi trebao odlučivati koje podatke o korisnicima može čitati, je li radnja dopuštena ili kako se poslovni zapis mijenja. To su odgovornosti backenda. Model može klasificirati, sažimati, izdvajati, izrađivati nacrte ili preporučivati; aplikacijski kôd provjerava i primjenjuje rezultat.

Započnite definiranjem jedne usko ograničene sposobnosti. Primjerice, interni alat za podršku mogao bi pretvoriti tiket u strukturiranu preporuku za trijažu:

• kategorija
• hitnost
• predloženi sljedeći korak
• napomena o pouzdanosti ili nesigurnosti

Važan je ugovor, a ne tekst upita. Predvidljiv izlaz ostatku sustava daje nešto što može provjeriti, pohraniti, prikazati i revidirati.

Postavite AI granicu iza sučelja

Nemojte raspršiti HTTP pozive prema pružatelju modela kroz kontrolere, obrađivače redova i domenske servise. Umjesto toga izradite malo sučelje okrenuto aplikaciji. Ono drži pojedinosti pružatelja, autentifikaciju, pravila ponavljanja i raščlanjivanje odgovora na jednome mjestu.

interface TicketTriageService
{
    public function analyze(Ticket $ticket): TicketTriage;
}

Implementacija danas može pozivati hostirani model, a sutra samostalno hostiranu uslugu. Pozivatelji ne bi trebali mariti za to. Oni šalju tiket i primaju provjereni domenski objekt ili jasnu pogrešku.

Ta granica također sprječava čest problem održivosti: upiti postaju nevidljiva poslovna logika. Predloške upita držite verzioniranima uz kôd koji koristi njihov izlaz. Svakom predlošku dodijelite stabilan identifikator, poput ticket-triage-v3, i zabilježite taj identifikator uz svaki rezultat.

Provjerite svaki odgovor modela

Čak i kada tražite JSON, odgovor tretirajte kao nepouzdan ulaz. Raščlanite ga, provjerite obavezna polja, ograničite vrijednosti na poznate enume, ograničite duljinu teksta i odbacite sve što ne zadovoljava ugovor. Model koji proizvodi uvjerljiv tekst nije isto što i model koji proizvodi valjane aplikacijske podatke.

$data = json_decode($responseBody, true, 512, JSON_THROW_ON_ERROR);

$category = TicketCategory::tryFrom($data['category'] ?? '');
$urgency = TicketUrgency::tryFrom($data['urgency'] ?? '');

if ($category === null || $urgency === null) {
    throw new InvalidAiResponse('Unsupported triage values.');
}

return new TicketTriage(
    category: $category,
    urgency: $urgency,
    suggestedNextStep: mb_substr((string) ($data['next_step'] ?? ''), 0, 500),
);

Provjera je također mjesto kojem pripadaju deterministička poslovna pravila. Ako tiket sadržava izraz povezan sa sigurnošću, vaš sustav može zahtijevati ljudsku provjeru bez obzira na vraćenu hitnost. To bi pravilo trebalo biti običan backend kôd, a ne instrukcija puna nade skrivena u upitu.

Dizajnirajte za asinkroni rad i nesavršene ovisnosti

Interaktivni zahtjevi imaju proračun latencije. Ako korisnik odgovor treba odmah, poziv modela može biti prikladan — ali samo uz stroga vremenska ograničenja i prihvatljivu zamjensku opciju. Za sažimanje, obogaćivanje, indeksiranje, generiranje izvješća i skupnu obradu red je obično bolje rješenje.

Tipičan tijek je:

1. Trajno pohranite izvorni zahtjev korisnika ili domenski događaj.
2. Izradite zapis AI zadatka sa statusom na čekanju.
3. Pošaljite idempotentan pozadinski zadatak.
4. Pozovite AI uslugu uz ograničeno vremensko ograničenje.
5. Provjerite i trajno pohranite rezultat atomarno.
6. Izložite status klijentu ili obavijestite sljedeći korak tijeka rada.

Idempotentnost je važna zato što radnici ponavljaju pokušaje. Operaciji dodijelite stabilan ključ izveden iz izvornog zapisa i verzije zadatka. Prije primjene dovršenog rezultata provjerite je li taj ključ već uspješno obrađen. Time se sprječavaju dvostruki troškovi i sukobljena ažuriranja kada dođe do isteka vremena nakon što je pružatelj prihvatio zahtjev.

Ponavljanje pokušaja treba biti selektivno. Ponovite prolazne pogreške veze, ograničenja brzine i neke pogreške poslužitelja uz ograničeni eksponencijalni povratni odmak. Nemojte više puta ponavljati neispravne zahtjeve, nevaljane odgovore ili odbijanja zbog pravila. Te pogreške zahtijevaju promjene u kôdu, upitu ili podacima — ne ustrajnost.

Pohranite dovoljno stanja za objašnjenje sustava

Tablica ai_runs često je korisnija od ugrađivanja bloba generiranog teksta u poslovnu tablicu. Može povezati izvorni entitet, vrstu zadatka, verziju upita, otisak zahtjeva, status životnog ciklusa, vremenske oznake, identifikator zahtjeva pružatelja kada je dostupan, sanitiziranu vrstu pogreške i sadržaj rezultata.

Pažljivo odredite zadržavanje podataka. Neobrađeni upiti i odgovori mogu sadržavati osjetljiv sadržaj korisnika, tajne kopirane u tikete ili regulirane podatke. Pohranite samo ono što podržava proizvod i operacije. Redigirajte poznata osjetljiva polja prije zapisivanja u dnevnik, prema potrebi šifrirajte zaštićene podatke u mirovanju i definirajte pravila zadržavanja prije nego što tablica neprimjetno postane trajna arhiva.

Vidljivost treba odgovarati na operativna pitanja bez izlaganja sadržaja: Koliko pokretanja ne prolazi provjeru? Koji je zadatak spor? Rastu li ponovni pokušaji? Koliki udio zahtjeva treba ljudsku provjeru? Mjerite trajanje, ishod, broj ponovnih pokušaja i vrijednosti upotrebe povezane s troškom samo kada ih vaš pružatelj doista vraća.

Koristite dohvaćanje kao podatkovni proizvod, a ne kao trik s upitom

Kada asistent mora odgovarati na temelju interne dokumentacije, središnji problem nije „produžite upit”. Riječ je o odabiru pouzdanog konteksta. Izgradite proces unosa koji izdvaja tekst, dijeli dokumente na dijelove sa stabilnim identifikatorima, bilježi verzije dokumenata i opseg pristupa te indeksira dijelove za dohvaćanje.

Pri upitu filtrirajte prije dohvaćanja. Korisnik nikada ne smije primiti kontekst iz dokumenta za čitanje kojeg nije ovlašten. Dohvatite mali skup relevantnih dijelova, uključite njihove izvorne metapodatke u zahtjev modelu i vratite citate ili poveznice koje aplikacija može provjeriti.

Svježina zahtijeva izričito rukovanje. Ako se dokument promijeni, poništite ili zamijenite njegove stare dijelove. Ako dohvaćanje ne može pronaći prikladan kontekst, ispravno ponašanje može biti reći da baza znanja ne sadržava odgovor. Izmišljanje sigurnosti gore je od vraćanja praznog rezultata.

Objavite uz zaštitne ograde i mogućnost povratka

Zastavice značajki posebno su vrijedne za AI mogućnosti. Timovima omogućuju uključivanje tijeka rada za ograničenu publiku, usporedbu verzija upita i isključivanje integracije koja ne radi bez ponovne implementacije. Zadržite zamjensku opciju bez AI-ja za svaki tijek rada koji utječe na korisnika ili blokira ključni rad.

Prije šire objave testirajte više od sretnih putanja. Upotrijebite pažljivo odabran skup reprezentativnih ulaza: kratke zahtjeve, dvosmislen jezik, nedostajuća polja, neprijateljske instrukcije ugrađene u korisnički sadržaj, prevelike sadržaje i očekivane pogreške pružatelja. Tvrdnje bi se trebale usredotočiti na vaš ugovor i naknadno ponašanje, a ne na točnu formulaciju probabilističkog sustava.

Trajna prednost nije pametan upit. To je arhitektura koja AI izlaz tretira kao koristan, ali pogrešiv: ograničen ugovorima, zaštićen autorizacijom, oporavljiv putem redova i vidljiv kroz operativne podatke. Dobro izgradite tu jezgru i modeli se mogu razvijati bez pretvaranja vašeg backenda u zbirku skupih nagađanja.