Versionează prompturile, modelele și logica fluxului ca o singură versiune AI

O versiune AI de producție este întregul ansamblu care determină comportamentul serviciului, nu doar promptul sau endpointul modelului. Dacă echipa revine la modelul anterior, dar lasă active noua schemă de instrument, politica de permisiuni ori logica de retry, nu a restaurat comportamentul testat. Fără o identitate comună pentru acest ansamblu, devine dificil de stabilit ce candidat a fost evaluat, ce configurație a servit o cerere problematică și ce pachet compatibil trebuie să primească din nou traficul.

Ce trebuie să însemne o versiune AI completă?

O versiune AI completă trebuie să cuprindă fiecare dependență care poate modifica rezultatul servit, autoritatea sistemului, riscul, costul, latența sau observabilitatea. Limita exactă diferă de la un serviciu la altul, însă modelul este doar o piesă. Atât NIST, prin perspectiva sa asupra activităților interdependente, cât și arhitecturile MLOps descriu sisteme formate din componente, configurații, verificări, infrastructură și monitorizare care funcționează împreună.

• Promptul, instantaneul rezolvat al modelului și parametrii efectivi de inferență.
• Schemele instrumentelor, permisiunile, aprobările, politicile și restricțiile aplicate.
• Configurația de retrieval sau context, codul fluxului, rutarea, schemele de intrare și ieșire.
• Dependențele de rulare și legăturile de mediu care pot schimba procesarea unei cereri.
• Dependențele proprii sau terțe numai dacă pot influența material serviciul ori decizia de promovare.

Seturile de evaluare, evaluatorii, rubricile și pragurile au un rol diferit: de regulă nu rulează în traseul care deservește utilizatorul, dar schimbă dovezile pe baza cărora candidatul este autorizat. De aceea primesc și ele versiuni și sunt legate de dosarul release-ului. Orice schimbare a unei componente de rulare care poate altera comportamentul produce un candidat nou; schimbarea unei porți de evaluare cere cel puțin un nou set identificabil de dovezi și o decizie reînregistrată.

Cum legi întregul comportament într-un manifest de versiune?

Leagă întregul comportament printr-un manifest înghețat, căruia îi atribui un ID unic de release. Manifestul trebuie să spună cine l-a creat, pentru ce serviciu, în ce stare se află, cine răspunde de rollback și care este versiunea anterioară cunoscută ca funcțională. Dacă se schimbă o componentă care influențează comportamentul, manifestul existent nu se rescrie: se creează un candidat cu identitate nouă.

• Pentru fiecare componentă: versiune rezolvată, commit, digest de artefact, hash de conținut sau altă referință stabilă, plus setările efective.
• Pentru mediu: serviciul țintă, cheia feature flag-ului, constrângerile de rutare, conexiunile aprobate și referința la date ori retrieval, fără copierea secretelor.
• Pentru compatibilitate: scheme, migrări, contracte de instrumente, câmpuri noi și condiții care pot bloca revenirea.
• Pentru control: condiții de oprire, proprietari, ținta de rollback și legături către evaluări, aprobări și planul de promovare.

În exemplul unui asistent intern de suport, candidatul support-assistant-r18 leagă promptul p-42, instantaneul m-2026-07, temperatura 0,2 și limita efectivă de ieșire, schema CRM t-9, politica policy-12, commitul wf-a71, schema reply-6 și blocarea dependențelor de rulare. Pachetul de release leagă separat suita eval-23 și versiunile evaluatorilor. Astfel, comparația cu support-assistant-r17 privește o configurație precisă, nu o colecție de aliasuri reconstruite după incident.

Un alias precum production sau latest rămâne util pentru operare, însă este un pointer modificabil, nu identitatea candidatului. Documentația MLflow ilustrează de ce: o versiune de prompt poate fi nemodificabilă, în timp ce aliasurile și unele configurații asociate rămân schimbabile. Alocarea traficului și momentele implementării apar în evenimente de promovare legate de manifest; ele nu îl mută. O modificare de rutare care schimbă contextul, autoritatea sau comportamentul per cerere creează însă un candidat nou.

Dacă poate schimba comportamentul servit sau dovezile care îl autorizează, are nevoie de o identitate rezolvată în dosarul release-ului.

Ce dovezi decid promovarea candidatului?

Promovarea trebuie decisă din dovezi produse de candidatul complet, comparat cu versiunea curentă, nu din scorul general al modelului. Notele de release pornesc de la intenția comportamentală și enumeră dependențele schimbate, scenariile și interfețele afectate, permisiunile, observabilitatea, rezultatele evaluării, limitările cunoscute, riscul rezidual, proprietarii și ținta compatibilă de rollback. În acest fel, aprobatorul vede atât schimbarea urmărită, cât și costul operațional al unei erori.

Porțile trebuie să includă exemple reale ale fluxului, segmente importante și cazuri rare, dar costisitoare. Un rezultat mediu bun nu compensează un contract rupt, o acțiune neautorizată sau o regresie materială într-un segment critic. Setul de date, evaluatorii, rubricile și pragurile sunt versionate împreună cu rezultatele, deoarece modificarea unei porți poate schimba interpretarea aceluiași candidat. Fiecare verificare se încheie cu promovare, menținere sau respingere și cu un proprietar nominalizat.

Pentru schimbări cu risc mai ridicat, persoana care a pregătit candidatul poate fi separată de cea care autorizează promovarea. Mecanismele de protecție ale mediului pot impune recenzori și verificări externe, dar instrumentul nu înlocuiește responsabilitatea. O echipă mică poate cumula roluri dacă păstrează clar cine a decis, pe baza căror dovezi și cu ce excepții. Nicio poartă nu trebuie prezentată drept dovadă completă de siguranță.

Cum promovezi același candidat în producție?

Promovează același candidat rezolvat printr-o scară măsurată, de la replay neacționabil până la trafic complet. Unde este posibil, începe cu cereri reprezentative în shadow, având instrumentele de scriere dezactivate sau izolate într-un sandbox. Repetarea oarbă a acțiunilor de producție poate crea efecte reale și nu este un test sigur. Urmează expunerea internă, o cohortă de producție persistentă, extinderea controlată și, abia apoi, traficul integral.

1. Rulează shadow sau replay neacționabil și compară traseul complet cu versiunea curentă.
2. Expune candidatul unui grup intern, păstrând aprobările pentru acțiunile cu efect extern.
3. Folosește o cohortă canary persistentă și compară semnalele de sarcină, siguranță, instrumente, fiabilitate, latență și cost.
4. Extinde numai după îndeplinirea condițiilor de observație și a cerințelor de eșantionare stabilite pentru serviciu.
5. Treci la trafic complet și continuă monitorizarea etichetată cu ID-ul release-ului.

Regulile cohortei, alocarea traficului, intervalul de observație și decizia fiecărei etape sunt evenimente asociate candidatului, nu modificări ale manifestului. O creștere preaprobată a expunerii poate folosi aceeași identitate; o schimbare a promptului, modelului, permisiunii, retrieval-ului, schemei sau legăturii de mediu nu poate. Procentele, mărimea eșantionului și durata se aleg după risc, volum, întârzierea detectării și capacitatea echipei. Shadow și canary reduc incertitudinea, dar pot rata condiții rare sau trafic nereprezentat.

Când oprești lansarea și ce trebuie să restaureze rollback-ul?

Oprește lansarea imediat când apare o condiție fermă declarată anticipat: încălcare de siguranță sau politică, utilizare neautorizată a unui instrument, contract de interfață rupt ori defecțiune severă de fiabilitate. Pentru regresiile de calitate, latență sau cost se folosesc limite aprobate pentru serviciul respectiv, nu praguri copiate. Un semnal ambiguu poate justifica pauza și investigația în locul rollback-ului automat, însă proprietarul și dispoziția trebuie consemnate explicit.

Rollback-ul trebuie să restaureze traficul către întregul pachet compatibil cunoscut ca funcțional. Înainte de lansare, echipa verifică dacă versiunea anterioară mai poate rula cu schemele, starea, furnizorii, contractele de instrumente, rutarea și migrările actuale și repetă procedura de restaurare. În exemplul asistentului, support-assistant-r17 poate fi ținta doar după confirmarea modului în care tratează câmpurile opționale pentru termen și escaladare introduse de candidatul r18.

• Înregistrează declanșatorul, primul moment observat, versiunea, cohorta și traseele afectate.
• Validează ținta cunoscută ca funcțională și restaurează traficul, apoi verifică funcționarea serviciului.
• Identifică din urme cererile și ID-urile acțiunilor externe care ar putea necesita intervenție.
• Rulează separat procedura autorizată de izolare, reconciliere, corectare, notificare sau acțiune compensatorie.
• Păstrează dispoziția finală, proprietarul măsurilor și actualizările necesare pentru evaluare și monitorizare.

Revenirea configurației controlează cererile viitoare; nu șterge mesaje, nu inversează scrieri de date, nu anulează aprobări și nu desființează automat sarcini deja create în sisteme externe. Aceste efecte cer un traseu separat, cu autoritatea potrivită și verificări proprii. Urmele etichetate cu release-ul ajută echipa să găsească cererile și identificatorii acțiunilor, dar răspunsul corect depinde de sistemul afectat și de procedurile organizației.

Ce înregistrare permite reconstruirea ulterioară a versiunii?

O înregistrare reconstructibilă leagă manifestul nemodificabil, dovezile de evaluare, aprobările, evenimentele de implementare și observațiile din producție. Ea păstrează identificatorii și parametrii rezolvați, legăturile de mediu, constatările de compatibilitate, versiunile activelor de evaluare, rezultatele, alocările de trafic, constatările, rollback-urile și dispoziția finală. ID-ul release-ului trebuie atașat urmelor, astfel încât generările, instrumentele, transferurile, restricțiile, timpii și rezultatele să poată fi atribuite configurației care le-a servit.

Unde sunt disponibili, identificatorul cererii furnizorului și identificatorul urmei aplicației permit corelarea depanării peste granițele sistemului. Totuși, un dosar complet nu înseamnă păstrarea fiecărui prompt, input de instrument, răspuns sau payload al clientului. Urmele pot exclude conținut sensibil și pot reține identificatori, rezultate și eșantioane guvernate. Selecția datelor și durata păstrării urmează politica organizației, nu dorința abstractă de a colecta totul.

Rezultatul este reproductibilitatea configurației și a deciziei, nu promisiunea unui răspuns identic byte cu byte. Un model stochastic, un serviciu găzduit sau infrastructura furnizorului pot introduce variații chiar când identificatorii și setările au fost arhivate. Pachetul minim util este cel care identifică fără ambiguitate candidatul, dovezile care l-au autorizat, etapele prin care a trecut și ținta compatibilă de rollback, fără să transforme dosarul într-o arhivă indiscriminată de date sensibile.

Când schimbarea atinge date sensibile, permisiuni cu consecințe, procese reglementate, obligații de păstrare sau remedierea unor acțiuni externe, modelul operațional nu decide singur cerințele aplicabile. Echipa trebuie să implice specialiștii calificați ai organizației în securitate, confidențialitate, juridic, evidențe, risc sau domeniul relevant. Manifestul și porțile fac decizia verificabilă; nu înlocuiesc judecata profesională cerută de context.