TL;DR: Construim agenți AI de producție la fel cum îi testăm — întâi cartografiem fluxul, conectăm fiecare tool în spatele unei bariere tipate și construim un set golden de cazuri reale înainte să reglăm ceva. Apoi punem fiecare schimbare în spatele evaluărilor din CI, ca un retuș de prompt, un schimb de model sau un tool nou să nu poată înrăutăți agentul în tăcere. Rezultatul e un agent pe care îl poți schimba fără frică, pentru că o regresie e prinsă înainte să ajungă live, nu după ce o găsesc utilizatorii tăi.
Un agent AI care arată bine într-un demo e ușor. Un agent care rămâne fiabil în fața utilizatorilor reali, a datelor reale și a banilor reali e partea grea — și acolo se destramă în tăcere majoritatea proiectelor.
Construim agenți de meserie, iar noi am venit din QA înainte să scriem o linie de produs. Așa că îl construim pe agent și lucrul care dovedește că funcționează în aceeași mișcare. Iată cum.
Pornește de la flux, nu de la prompt
Un singur prompt inteligent e un demo, nu un sistem. Munca reală are pași, ramificații și moduri de eșec. Începem prin a cartografia fluxul pe care agentul trebuie să-l dețină: ce decide, ce tool-uri apelează, ce nu trebuie să facă niciodată.
Harta aceea devine arhitectura — de obicei un planner care împarte munca în pași și un executor care îi duce la capăt, revenindu-și când un pas eșuează în loc să se prăbușească într-un răspuns greșit.
Conectează tool-urile cu bariere, nu cu speranțe
În clipa în care un agent poate apela tool-uri, poate face pagube. Așa că fiecare tool primește o interfață tipată și o barieră: ce argumente sunt valide, ce acțiuni au nevoie de confirmare, ce nu poate atinge niciodată. Un agent care poate muta bani sau șterge date e la fel de sigur pe cât sunt verificările din jurul acelor apeluri.
Construiește setul golden înainte să reglezi ceva
Aici e partea pe care echipele o sar. Înainte de a regla prompturi sau de a schimba modele, construim un set golden — inputuri reprezentative extrase din utilizarea reală, fiecare cu un comportament așteptat. Este adevărul de referință față de care se măsoară fiecare schimbare viitoare.
Fără el, „e mai bine?” e o chestiune de opinie. Cu el, e un număr.
Pune fiecare schimbare în spatele evaluărilor din CI
Setul golden se răscumpără doar când rulează automat. Integrăm evaluările în CI, ca fiecare retuș de prompt, upgrade de model sau schimbare de pipeline să fie punctat înainte să poată ajunge live:
- Comportament și halucinații — răspunsul e corect și ancorat, sau inventat?
- Siguranța apelurilor de tool-uri — a apelat tool-ul potrivit cu argumentele potrivite și le-a refuzat pe cele nesigure?
- Regresie — a stricat această schimbare, în tăcere, ceva ce funcționa?
Dacă o schimbare înrăutățește o metrică-cheie, merge-ul e blocat. Exact asta e ideea: agentul nu poate deveni mai rău fără ca cineva să decidă să-l lase.
Apoi încercăm să-l spargem
Construitul și evaluatul nu sunt de ajuns pentru ceva adversarial. Înainte ca un agent să ajungă live, îl atacăm așa cum ar face-o un adversar real — prompt injection prin inputul utilizatorului și prin documentele pe care le recuperează, jailbreak-uri împotriva barierelor sale, încercări de a-l face să abuzeze un tool sau să scurgă date. Ce găsim devine o constatare cu o reproducere și o remediere, apoi un test de regresie ca breșa să rămână închisă.
Rezultatul
Un agent pe care îl poți schimba fără frică. Prompt nou, model nou, tool nou — evaluările îți spun în câteva minute dacă a devenit mai bun sau mai rău, iar poarta oprește o regresie înainte s-o găsească utilizatorii tăi.
Aceasta e diferența dintre un agent care arată grozav într-un demo și unul care ajunge în producție. Construim ambele jumătăți, pentru că una fără cealaltă nu supraviețuiește în producție.
Construiești un agent sau ai unul care te tot surprinde în moduri greșite? Spune-ne ce construiești — îl analizăm împreună.