Značajke umjetne inteligencije rijetko stižu kao čist projekt na zelenoj livadi. Pojavljuju se kao zahtjev za sažimanjem korisničkih prijava podršci, semantičkim pretraživanjem dokumentacije proizvoda, klasificiranjem pristiglih zapisa ili pomoći operateru pri sastavljanju odgovora. Model je možda vidljivi dio, ali baza podataka određuje hoće li ta značajka postati pouzdan softver ili skupa demonstracija.

Pragmatično dizajniranje baze podataka za umjetnu inteligenciju ne znači preoblikovati svaku tablicu oko vektora ili predviđati svaki budući model. Riječ je o očuvanju pouzdanih operativnih podataka uz stvaranje jasnih mjesta za izvedene, probabilističke i izmjenjive rezultate umjetne inteligencije.

Odvojite činjenice od tumačenja

Baza podataka trebala bi razlikovati ono što se dogodilo od onoga što je sustav zaključio o tome. Ukupan iznos narudžbe, adresa koju je odabrao kupac i događaj revizijskog traga činjenice su. Predložena kategorija, izdvojeni sentiment, generirani sažetak ili ocjena pouzdanosti tumačenje su.

Miješanje tih koncepata u jedan red brzo stvara probleme. Vrijednost koju je proizvela umjetna inteligencija možda će trebati ponovno generirati nakon promjene upita, nadogradnje modela, ispravka podataka ili izmjene poslovnog pravila. Činjenična vrijednost obično ima drukčiji životni ciklus i drukčiji standard točnosti.

Prednost dajte izvornoj tablici i tablici izvedenih rezultata. Na primjer, dokument može ostati mjerodavan zapis, dok se klasifikacije pohranjuju zasebno:

CREATE TABLE documents (
    id BIGINT PRIMARY KEY,
    body TEXT NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

CREATE TABLE document_classifications (
    id BIGINT PRIMARY KEY,
    document_id BIGINT NOT NULL,
    label VARCHAR(100) NOT NULL,
    confidence DECIMAL(5,4),
    model_identifier VARCHAR(255) NOT NULL,
    prompt_version VARCHAR(100) NOT NULL,
    source_updated_at TIMESTAMP NOT NULL,
    created_at TIMESTAMP NOT NULL,
    FOREIGN KEY (document_id) REFERENCES documents(id)
);

Ova struktura olakšava odgovor na važno pitanje: „Koju je verziju dokumenta opisivao ovaj rezultat?” Također omogućuje istodobno postojanje više klasifikacija dok tim procjenjuje novi pristup.

Dizajnirajte za sljedivost, a ne samo za izlaz

Kada korisnik ospori automatizirani rezultat, koristan odgovor nije samo sam rezultat. To je kontekst oko njega: koji su izvorni podaci upotrijebljeni, kada je obrada provedena, koji ga je model ili tijek rada proizveo i je li čovjek promijenio ishod.

Pohranite dovoljno podataka o sljedivosti za istraživanje ponašanja, bez zadržavanja nepotrebnog osjetljivog sadržaja. Odgovarajući detalji ovise o sustavu, ali obično uključuju:

• identifikator izvornog zapisa te izvornu reviziju ili vremensku oznaku;
• identifikator modela i konfiguraciju relevantnu za rezultat;
• identifikator verzije upita ili tijeka rada;
• status obrade, vremenske oznake i podatke o pogreškama;
• stanje ljudske provjere i svako konačno poništenje.

Identifikator verzije često je praktičniji od kopiranja velikog upita u svaki red. Definiciju upita držite u verzionirano kontroliranoj konfiguraciji aplikacije ili namjenskoj tablici tijeka rada, a zatim zabilježite nepromjenjivu verziju upotrijebljenu za svako pokretanje. Rezultat ostaje objašnjiv bez nepotrebnog opterećivanja uobičajenih upita.

Rad umjetne inteligencije tretirajte kao asinkroni rad

Većina obrade umjetne inteligencije ne pripada unutar sinkronog web zahtjeva. PHP kontroler koji sprema dokument, a zatim čeka izdvajanje, generiranje ugradnji ili odgovor udaljenog modela, s vremenom će stvoriti spore zahtjeve, nezgodno ponašanje pri ponovnim pokušajima i dupliciranu obradu.

Umjesto toga, najprije potvrdite poslovnu transakciju, a zatim stavite u red zadatak koji upućuje na potvrđeni zapis. Radnik dohvaća trenutačno stanje izvora, obavlja posao i zapisuje izvedeni rezultat. Polje statusa kao što su pending, processing, completed ili failed aplikaciji i operaterima daje vidljiv životni ciklus.

Idempotentnost je ovdje važna. Zadaci mogu biti isporučeni više puta; radnici se mogu zaustaviti nakon udaljenog poziva, ali prije spremanja rezultata. Učinite pisanja sigurnima za ponavljanje primjenom stabilnog pravila jedinstvenosti, primjerice jednog rezultata po dokumentu, izvornoj reviziji, vrsti zadatka i verziji tijeka rada. U PHP-u to obično znači oslanjanje na ograničenje baze podataka i namjerno rukovanje sukobom, umjesto pretpostavke da red nikada neće ponoviti pokušaj.

Upotrijebite outbox kada je dosljednost važna

Ako spremanje zapisa i objavljivanje njegova zadatka obrade moraju ostati usklađeni, vrijedi razmotriti obrazac outboxa. Zapišite outbox događaj u istoj transakciji baze podataka kao i izvornu promjenu. Zasebni objavljivač šalje neposlane događaje u red i bilježi uspješnu objavu. Time se izbjegava klasičan razmak u kojem potvrda baze podataka uspije, ali proces zakaže prije slanja poruke u red.

Obrazac dodaje pokretne dijelove, stoga nije obavezan za svaku značajku. Vrijedan je kada bi propuštanje naknadne radnje bilo skupo ili teško uočljivo.

Arhitekturu dohvaćanja odaberite prema pitanju

Pretraživanje uz pomoć umjetne inteligencije često se uvodi kao „dodajte ugradnje”, ali dizajn dohvaćanja počinje jednostavnijim pitanjem: što bi korisnici trebali moći pronaći?

Točni identifikatori, vlasništvo nad računom, rasponi datuma, dozvole i filtri statusa i dalje su uobičajeni posao baze podataka. Semantička sličnost korisna je kada korisnici izražavaju ideju različitim jezikom i trebaju konceptualno povezan sadržaj. Mnoge produkcijske pretrage trebaju oboje.

Strukturirane filtre držite eksplicitnima i provedite autorizaciju prije predaje sadržaja bilo kojem tijeku rada vođenom modelom. Zatim, gdje je moguće, primijenite semantičko dohvaćanje unutar dopuštenog skupa kandidata. To je lakše razumjeti nego tretirati ocjenu vektorske sličnosti kao zamjenu za pravila aplikacije.

Za dokumente birajte dijelove na temelju značenja i potreba dohvaćanja, a ne samo proizvoljne fiksne veličine. Pohranite ID nadređenog dokumenta svakog dijela, redoslijed, izvornu reviziju i metapodatke potrebne za filtriranje. Ako se dokument promijeni, označite prethodne dijelove zastarjelima i ponovno ih generirajte kroz isti asinkroni proces.

Promjene sheme učinite reverzibilnima i vidljivima

Integracija umjetne inteligencije brzo se razvija jer se brzo razvijaju zahtjevi proizvoda. Migracija koja trajno zamjenjuje polje koje su uredili ljudi generiranim tekstom stvara nepotreban rizik. Dodavne promjene obično su sigurnije: nove tablice, stupci koji dopuštaju NULL tijekom prijelaza te razdoblja dvostrukog čitanja ili dvostrukog pisanja kada su potrebna.

Operativna vidljivost jednako je važna. Pratite dubinu reda, starost zadataka, broj neuspjeha, trajanje obrade te broj zastarjelih ili nedostajućih izvedenih zapisa. Za izlaze koji utječu na korisnike mjerite i ponašanje pri provjeri i poništavanju. Ti signali otkrivaju je li sustav koristan, a ne samo radi li.

Budite oprezni sa sirovim ulazima i izlazima u zapisnicima. Tijekovi rada umjetne inteligencije mogu obraditi sadržaj kupaca, interne dokumente ili vjerodajnice slučajno uključene u tekst. Definirajte pravila zadržavanja, ograničite pristup i prema zadanim postavkama bilježite identifikatore i dijagnostičke metapodatke, a ne cijele terete podataka.

Izgradite stabilnu jezgru oko prilagodljivog ruba

Trajni dio aplikacije obično je njezin model domene: korisnici, dozvole, transakcije, zalihe, dokumenti i pravila koja njima upravljaju. Umjetna inteligencija pripada prilagodljivom rubu tog sustava, gdje proizvodi prijedloge, obogaćenja i sučelja nad dobro upravljanim podacima.

Takvo uokvirivanje vodi smirenijim arhitektonskim odlukama. Očuvajte kanonske zapise. Verzionarajte izvedeno ponašanje. Obrađujte rad asinkrono. Bilježite sljedivost. Učinite ponovne pokušaje sigurnima. Upotrebljavajte tradicionalne upite tamo gdje su najjači, a semantičko dohvaćanje tamo gdje doista poboljšava otkrivanje.

Cilj nije učiniti bazu podataka „izvornom za umjetnu inteligenciju”. Cilj je učiniti je otpornom kada se umjetna inteligencija promijeni — a promijenit će se — dok poslovanje i dalje treba da njegovi podaci budu točni, objašnjivi i dostupni.