Pozadinski sustav čini više od obrade zahtjeva. Svakog programera koji na njemu radi uči što sustav vrednuje: jesu li pogreške sigurne za poduzimanje radnji, jesu li granice stvarne, imaju li podaci pouzdano značenje te je li promjena rutinska ili zastrašujuća.

To je još važnije u proizvodima s mogućnostima umjetne inteligencije. Značajka umjetne inteligencije često započinje kao mali zahtjev — poslati upit, pohraniti odgovor, prikazati odgovor — ali unosi neizvjesnost, asinkroni rad, skupe ovisnosti i nova pitanja privatnosti. Pozadinski sustav koji to tretira kao „samo još jedan API poziv” sklon je širiti složenost posvuda. Pozadinski sustav s jasnom arhitekturom uči tim kako postupati s neizvjesnošću bez normaliziranja kaosa.

Neka arhitektura govori sama za sebe

Dobra arhitektura nije dijagram sačuvan u zaboravljenoj mapi. Ona je skup odluka koje ostaju vidljive u kodu, sučeljima, ograničenjima baze podataka, zapisnicima i konfiguraciji implementacije.

Započnite razdvajanjem onoga što sustav radi od načina na koji to rade vanjske usluge. Kontroler bi trebao prevesti HTTP zahtjev u radnju aplikacije. Aplikacijski sloj trebao bi koordinirati pravila i trajnu pohranu. Integracijski sloj trebao bi komunicirati s pružateljem AI usluga, redom čekanja, uslugom e-pošte ili spremištem objekata. To razdvajanje nije formalnost; sprječava da pojedinosti specifične za pružatelja postanu jezik cijele aplikacije.

final class GenerateSummaryController
{
    public function __invoke(Request $request, GenerateSummary $action): JsonResponse
    {
        $result = $action->handle(
            documentId: $request->input('document_id'),
            requestedBy: $request->user()->id,
        );

        return response()->json($result, 202);
    }
}

Kontroler ne odlučuje koji model pozvati, koliko je ponovnih pokušaja prihvatljivo ni kamo rezultat pripada. Te se odluke nalaze iza radnje na razini aplikacije. To putanju zahtjeva čini čitljivom: sažetak je zatražen, zahtjev je prihvaćen, a rad će se nastaviti drugdje.

Dizajnirajte API-je koji otkrivaju stvarni tijek rada

Rad umjetne inteligencije često je spor, podložan pogreškama i promjenjivog trajanja. Pretvaranje da nije takav stvara krhke API-je zahtjev-odgovor i loša očekivanja korisnika. Ako generiranje može trajati dulje od uobičajenog web zahtjeva, modelirajte ga kao zadatak.

Praktičan tijek je jednostavan:

1. Validirajte zahtjev i autorizirajte pristup izvornom materijalu.
2. Izradite zapis u bazi podataka sa statusom poput pending.
3. Stavite posao generiranja u red čekanja.
4. Vratite 202 Accepted s identifikatorom i krajnjom točkom za status.
5. Ažurirajte zapis na completed ili failed.

Ovaj dizajn korisnike API-ja uči da je dovršenost vidljivo stanje, a ne pretpostavka. Operativnim timovima također daje nešto konkretno za provjeru kada ovisnost zakaže.

interface TextGenerator
{
    public function summarize(string $source): GeneratedText;
}

Sučelje zadržite usmjerenim na sposobnost koja je vašoj aplikaciji potrebna. Izbjegavajte propuštanje objekta zahtjeva pružatelja, naziva modela ili strukture odgovora u kontrolere i domenski kod. Prilagodnik pružatelja može prevesti te pojedinosti na rubu sustava. Ako se model promijeni, opseg utjecaja trebao bi biti malen i očit.

Idempotentnost zaslužuje isti pristup. Ponovni pokušaj klijenta, ponovni pokušaj reda čekanja i ponovljena reprodukcija webhooka uobičajeni su događaji. Tamo gdje bi duplikat bio štetan, prihvatite ključ idempotentnosti ili upotrijebite trajno pravilo jedinstvenosti. „Vjerojatno neće biti poslano dvaput” nije svojstvo sustava.

Neka baza podataka nosi dio istine

Baze podataka često se tretiraju kao pasivna pohrana. U trajnom pozadinskom sustavu one provode važne činjenice. Strani ključevi, ograničenja jedinstvenosti, stupci koji ne dopuštaju null vrijednosti, transakcije i pažljivo odabrani indeksi otežavaju stvaranje nevaljanih stanja.

Za generirani sadržaj zadržite dovoljno konteksta za kasnije razumijevanje rezultata: verziju izvora ili identifikator izvora, zatraženu radnju, status, vremenske oznake i referencu na izlaz. Nemojte olako pohranjivati svaki sirovi upit, odgovor ili podatak koji sadrži vjerodajnice. Zadržavanje podataka arhitektonska je odluka, a ne pogodnost za zapisivanje.

Prijelaze statusa koristite namjerno. Zapis ne bi smio neprimjetno prijeći iz pending u completed ako radnik nikada nije primio zadatak. Možda mu je potrebno međustanje processing, razlog neuspjeha siguran za klijenta i operativne pojedinosti pohranjene zasebno. Cilj nije velik stroj stanja; cilj je istinit.

Obuzdajte nepouzdane ovisnosti

Vanjske AI usluge mogu prekoračiti vremensko ograničenje, odbiti zahtjeve, vratiti neispravno oblikovan izlaz ili privremeno postati nedostupne. Aplikacija bi trebala razlikovati zahtjev koji se može ponovno pokušati od onoga koji se ne može.

Postavite izričita vremenska ograničenja za povezivanje i ukupno trajanje. Ponovno pokušavajte samo neuspjehe koji su vjerojatno privremeni te ograničite broj pokušaja. Politika ponovnih pokušaja bez ograničenja pretvara incident pružatelja u zaostatak reda čekanja. Vremensko ograničenje bez puta oporavka pretvara prolazni problem u zagonetku za korisnika.

Validirajte generirani izlaz prije njegova objavljivanja nizvodnim sustavima. Ako integracija očekuje strukturirane podatke, validirajte strukturu i obavezna polja. Generirani tekst tretirajte kao nepouzdan ulaz dok ne prođe iste provjere autorizacije, izbjegavanja posebnih znakova i poslovnih pravila koje primjenjujete na svaki drugi vanjski ulaz.

Najkorisnija granica u AI pozadinskom sustavu često je ona koja sprječava da neizvjesnost neprimjetno postane podatak.

Upotrijebite Docker kako bi pretpostavke o izvođenju bile vidljive

Spremnici su vrijedni kada lokalni razvoj, testove i implementaciju čine dosljednijima. Manje su korisni kada samo skrivaju složeno okruženje za izvođenje iza jedne naredbe.

Spremnik PHP usluge trebao bi jasno deklarirati svoje potrebe za izvođenjem: verziju PHP-a, potrebna proširenja, instalaciju ovisnosti, korisnika koji nije root za izvođenje gdje je to prikladno te naredbu koja pokreće proces. Odvojite aplikacijske usluge od pomoćnih usluga kao što su baza podataka, predmemorija ili radnik reda čekanja. Web-proces i radnik reda čekanja mogu dijeliti istu sliku, ali obično imaju različite naredbe i načine otkazivanja.

Konfiguracija bi trebala ulaziti putem postavki specifičnih za okruženje, dok se validacija odvija pri pokretanju. Nedostajuća obavezna konfiguracija trebala bi jasno prekinuti rad umjesto stvoriti djelomičnu uslugu koja zakaže pri prvom stvarnom zahtjevu. Tajne držite izvan slika, kontrole izvornog koda i uobičajenih zapisnika aplikacije.

Mjerite ponašanje, a ne samo dostupnost

HTTP odgovor 200 nije dokaz da je pozadinski sustav zdrav. Za asinkrone AI tijekove rada korisni signali uključuju dubinu reda čekanja, starost zadataka, stopu dovršenosti, kategorije neuspjeha, latenciju pružatelja i broj ponovnih pokušaja. Zapisnici bi trebali sadržavati stabilne identifikatore poput ID-jeva zahtjeva, ID-jeva zadataka i ID-jeva resursa kako bi se incident mogao pratiti kroz usluge.

Budite oprezni s podacima za nadziranje. Zapisivanje potpunih upita ili generiranih izlaza može otkriti informacije o korisnicima. Bilježite metapodatke potrebne za dijagnostiku, redigirajte osjetljiva polja i namjerno dodjeljujte pristup detaljnim zapisnicima.

Gradite sustave koje ljudi mogu sigurno mijenjati

Održivost se ne postiže odabirom modernog okvira ili crtanjem više slojeva. Dolazi od toga da sljedeća promjena ne bude iznenađujuća. Programer bi trebao moći odgovoriti: gdje ovaj zahtjev ulazi, koje pravilo upravlja ovom odlukom, koji se podaci mijenjaju, što se događa ako ovisnost zakaže i kako ćemo to znati?

Tako izgleda pozadinski sustav koji podučava. Njegova sučelja komuniciraju namjeru. Njegova baza podataka štiti invarijante. Njegovi zadaci priznaju stvarnost. Njegovi spremnici otkrivaju pretpostavke. Njegovi neuspjesi ostavljaju koristan trag. Kada sustav to čini dosljedno, ne podržava samo AI značajku — pomaže cijelom timu da sljedeću izgradi s boljom prosudbom.