Većina timova ne mora trenirati AI model. Moraju izgraditi sustav koji model uči što je važno u trenutku kada korisnik postavi upit.

Ta razlika mijenja inženjerski razgovor. Treniranje se odnosi na mijenjanje težina modela velikim skupovima podataka, specijaliziranom infrastrukturom, radom na evaluaciji i trajnom obvezom osvježavanja rezultata. Učitelj je aplikacijski sloj: dohvaća relevantne činjenice, primjenjuje poslovna pravila, daje modelu jasne upute, provjerava njegov izlaz i ostavlja revizijski trag.

Za mnoge pozadinske proizvode upravo se tu nalazi trajna vrijednost.

Model nije vaša aplikacija

Model opće namjene može stvarati koristan jezik, izdvajati strukturu, sažimati tekst i zaključivati unutar ograničenih zadataka. No on ne zna automatski vaše trenutačno stanje zaliha, korisnikova dopuštenja, najnoviji dokument s pravilima ni koja je polja baze podataka sigurno izložiti.

Pokušaj rješavanja tih nedostataka preranim treniranjem često problem dizajna softvera pretvara u skup problem s podacima. Temeljna potreba može biti mnogo uobičajenija:

• Pronaći točne informacije za ovaj zahtjev.
• Objasniti kako se te informacije trebaju upotrijebiti.
• Dati modelu samo ovlasti koje su mu potrebne.
• Provjeriti je li predloženi odgovor ili radnja prihvatljiv.

To su poznate odgovornosti pozadinskog sustava. Zaslužuju jednaku pažnju kao autentifikacija, dizajn sheme, provjera zahtjeva i granice transakcija.

Što AI učitelj zapravo radi

Promatrajte učitelja kao kontrolirani sloj konteksta i alata između korisnika, vaših sustava i modela. Njegov posao nije produžavati upite. Njegov je posao sastaviti najmanji pouzdani paket uputa, dokaza i mogućnosti za određeni zadatak.

Dohvaća dokaze, a ne samo tekst

Dohvaćanje se često opisuje kao „pretraživanje dokumenata”, ali korisno dohvaćanje počinje vlasništvom nad podacima. Pomoćnik za podršku možda treba odobrene članke pomoći, konfiguraciju proizvoda i status specifičan za račun. Pomoćnik za programiranje možda treba konvencije repozitorija i uzak skup relevantnih datoteka. Financijski tijek rada može zahtijevati zapise iz izvornog sustava, a ne zastarjeli izvezeni dokument.

Svaka dohvaćena stavka trebala bi sadržavati metapodatke kao što su zakupac, opseg pristupa, izvor, revizija i vremenska oznaka. Modelu je potreban sadržaj; vašoj aplikaciji potreban je dovoljan kontekst kako bi odlučila je li se taj sadržaj smio prikazati.

Kodira operativna pravila

Upute trebaju objasniti zadatak, granice, preferirani format odgovora i postupanje s neizvjesnošću. Ne bi trebale se pretvarati da je rečenica u upitu sigurnosna granica.

Ako korisnik, primjerice, može zatražiti povrat novca, model može prikupiti nedostajuće pojedinosti i predložiti sljedeći korak. Aplikacija bi trebala odlučiti je li korisnik ovlašten, ispunjava li narudžba uvjete i smije li se radnja izvršiti. Deterministička pravila smjestite u kod ili konfiguraciju gdje se mogu testirati i pregledati.

Pruža usko definirane alate

Alat bi trebao predstavljati određenu mogućnost, poput pretraživanja narudžbe ili izrade nacrta zahtjeva. Izbjegavajte izlaganje generičke krajnje točke za upite bazi podataka ili neograničenog internog HTTP klijenta. Usko definirani alati smanjuju slučajnu štetu, pojednostavljuju autorizaciju i olakšavaju dijagnosticiranje neuspjeha.

final class OrderLookup
{
    public function findForCustomer(string $orderId, int $customerId): array
    {
        // Enforce tenant and customer scope in the query itself.
        // Return only fields needed for the assistant's task.
        return [];
    }
}

Važan detalj nije naziv klase. Važno je da kontrolu pristupa provodi pozadinska usluga, umjesto da se prepusti modelovu tumačenju upita.

Izgradite ciklus podučavanja kao i svaki drugi produkcijski tijek rada

Pouzdana AI značajka ima koristi od eksplicitnog cjevovoda. Točne komponente variraju, ali slijed bi trebao biti dovoljno razumljiv za testiranje i rad.

1. Autentificirajte zahtjev i utvrdite zakupca, korisnika i ulogu.
2. Klasificirajte zatraženi zadatak i odaberite dopušteni tijek rada.
3. Dohvatite ograničene dokaze iz autoritativnih izvora.
4. Izgradite upute i strukturirane ulaze za taj tijek rada.
5. Pozovite model s vremenskim ograničenjima, ograničenjima ponovnih pokušaja i jasnom zamjenskom opcijom.
6. Provjerite vraćenu strukturu i provedite pravila prije nuspojava.
7. Zabilježite relevantne ulaze, pozive alata, izlaze i odluke radi pregleda.

Ponovni pokušaji zahtijevaju suzdržanost. Ponovni pokušaj neuspješnog zahtjeva za generiranje teksta može biti razuman kada je operacija idempotentna. Ponovni pokušaj radnje koja stvara zahtjev, šalje e-poštu ili mijenja zapis može stvoriti dvostruke nuspojave. Upotrebljavajte ključeve idempotentnosti i neka aplikacija, a ne model, upravlja konačnim zapisom.

Isto tako, odvojite konverzacijski nacrt od potvrđene operacije. Model može preporučiti ažuriranje korisničkog profila; ažuriranje bi trebao izvršiti provjereni obrađivač naredbi.

Neka baza podataka bude dio dizajna

AI značajke mogu stvoriti iznenađujući pritisak na podatke. Dnevnici razgovora, dohvaćeni isječci, tragovi alata, slučajevi evaluacije i događaji povratnih informacija imaju različite zahtjeve za zadržavanje i pristup. Nemojte ih sve baciti u jednu neograničenu tablicu samo zato što su svi „AI podaci”.

Dizajnirajte za pitanja koja će operateri kasnije postaviti: Koji je izvor informirao ovaj odgovor? Koji je alat proizveo ovu vrijednost? Koja je verzija upita korištena? Je li zahtjev propao zato što dohvaćanje nije pronašlo ništa, zato što je alatu isteklo vrijeme ili zato što je provjera izlaza odbila odgovor?

Gdje je moguće, pohranjujte stabilne identifikatore i reference. Ustrajavanje svakog sirovog korisnog tereta može povećati troškove i proširiti površinu privatnosti. Pravila zadržavanja trebala bi odražavati osjetljivost podataka i stvarnu operativnu svrhu.

Evaluirajte učitelja, a ne samo prozu

Odgovor može zvučati uvjerljivo, a ipak biti operativno pogrešan. Evaluacija bi zato trebala obuhvatiti cijeli sustav: relevantnost dohvaćanja, ponašanje autorizacije, odabir alata, usklađenost sa shemom izlaza i konačni poslovni ishod.

Započnite s malim, reprezentativnim skupom slučajeva: uobičajenim zahtjevima, dvosmislenim zahtjevima, nedostajućim podacima, zabranjenim pristupom, zastarjelim dokumentima i neuspjelim ovisnostima. Za svaki slučaj definirajte što se mora dogoditi i što se nikada ne smije dogoditi. Time se stvara regresijski paket koji se može pokrenuti kada se promijene upiti, logika dohvaćanja, sheme ili modeli.

Ljudski pregled i dalje je vrijedan, osobito za nijansirano pisanje. No recenzenti bi trebali pregledati dokaze i trag tijeka rada, a ne samo ocjenjivati tečnost odgovora.

Kada treniranje može biti pravi izbor

Treniranje nije pogreška; ono je drukčije ulaganje. Može biti prikladno kada imate stabilan, visokokvalitetan skup podataka i ponašanje koje se ponavlja, a koje se ne može primjereno izraziti primjerima, dohvaćanjem ili aplikacijskom logikom. Čak ni tada treniranje ne uklanja potrebu za autorizacijom, svježim podacima, nadzorom i provjerom izlaza.

Praktična je zadana opcija jednostavnija: najprije izgradite snažnog učitelja oko postojećeg modela. Naučite gdje sustav ne uspijeva. Poboljšajte granice podataka, tijekove rada i evaluacije. Tek tada možete utvrditi odnosi li se preostali problem doista na ponašanje modela.

Trajna prednost jest prosudba kodirana u softveru

Modeli će se mijenjati. S njima će se mijenjati pružatelji usluga, cijene i mogućnosti. Trajni dio AI proizvoda jest sloj koji zna koje su činjenice aktualne, koje su radnje dopuštene, kako se postupa s neizvjesnošću i kako se mjeri ispravnost.

Dobro izgradite taj sloj i model postaje zamjenjiva komponenta pouzdanog sustava. To je korisnija ambicija od podučavanja modela svemu: izgradite učitelja koji mu pomaže donijeti ispravnu odluku kada je to važno.