Observabilitate LLM: 6 lecții de la CTO-ul Datadog

Lecția 1: AI a stricat vechiul mod de a face code review

Să începem cu presiunea care declanșează tot restul: există mai mult cod decât poate citi oricine.

Lê-Quôc spune direct că vechiul model, un om care citește un pull request linie cu linie, nu supraviețuiește în contact cu dezvoltarea asistată de AI. Îngrijorarea pe care o aude în industrie este că review-urile devin imposibile, fiindcă se întâmplă prea multe lucruri ca să le urmărești citind PR-uri.

Răspunsul lui nu este să le ceri oamenilor să citească mai repede, ci să muți review-ul în altă parte.

Acea ultimă propoziție e ușor de trecut cu vederea. Odată ce orchestrezi un agent să planifice, altul să scrie și altul să testeze, trebuie și să oprești „scriitorul” să păcălească testele automatizate în loc să rezolve problema.

El merge dincolo de teste. Datadog adaugă acum demonstrații semi-formale și formale că o specificație face ceea ce trebuie, ceva prea solicitant pentru a fi încercat pe scară largă înainte ca agenții să preia greul. Funcționează cel mai bine pe sisteme de backend și de coordonare, unde comportamentul e suficient de matematic pentru a putea fi analizat cu precizie.

Lecția 2: Producția este singurul test care contează

Să treci toate testele în CI e necesar și departe de a fi suficient. Eșecurile care contează apar mai târziu.

Fiecare release se sprijină pe presupuneri pe care nu le poți verifica pe deplin în prealabil, despre forma datelor și comportamentul utilizatorilor. Dacă expui acele presupuneri la suficient trafic real, cazurile rare încetează să mai fie rare; devin întârzierile și erorile zilnice ale derivelor de date și de model.

LLM-urile fac asta mai greu: cu cod obișnuit, măcar poți raționa toate ramurile, dar nimeni nu poate explica mecanic de ce un model returnează ce returnează, deci același input nu e niciodată garantat să dea același output. Rezultatul ocazional ciudat nu poate fi eliminat prin inginerie.

Așa că încetezi să mai încerci să dovedești că un sistem e corect înainte să-l livrezi. În schimb,

• Scrii evaluări pentru comportamentul dorit
• Îl monitorizezi în producție
• Păstrezi un control de oprire pentru un rollout care o ia razna.

Întrebarea nu mai este dacă a trecut, ci dacă o problemă e un caz izolat sau începutul unei tendințe.

Acest semnal live nu este doar un dashboard pentru oameni. Conectat în sistemul de deployment, îi permite unui agent să ruleze un rollout așa cum ar face un inginer prudent: la un procent din utilizatori, apoi la cinci, judecând pe baza datelor reale dacă schimbarea face ce s-a intenționat.

Lecția 3: Lasă agenții să preia munca obositoare

Argumentul lui Lê-Quôc pentru agenți nu este că îi înlocuiesc pe ingineri, ci că preiau părțile din job care uzează oamenii.

Depanarea unui incident înseamnă să arunci ipoteze asupra unui simptom, iar în incidente lungi, adesea cea mai neverosimilă se dovedește adevărată. Agentul Bits AI al Datadog le verifică pe toate în paralel, înaintea inginerului, în timp ce omul îl ghidează spre intuiția pe care un dashboard n-ar scoate-o niciodată la iveală.

Punctul mai profund este oboseala. Un rollout on-call înseamnă alertă bruscă urmată de ore de nimic, repetat până ți se tocește judecata.

Un agent nu are nicio problemă și nu se înrăutățește după patru ore de privit cifre. Stresul și oboseala degradează performanța umană, motiv pentru care echipele își rotesc oamenii în turele on-call.

Dă mașinii supravegherea neobosită, iar oamenii revin odihniți pentru deciziile care au nevoie de ei. Aceeași logică se aplică și la trierea de securitate, unde analiștii ajung să se epuizeze separând alarmele false de amenințările reale.

Lecția 4: Împarte munca în două bucle

Lê-Quôc își organizează munca cu agenți la Datadog în jurul a două bucle.

Bucla de dezvoltare

Majoritatea inginerilor vor recunoaște prima buclă:

1. Scrie cod
2. Livrează-l
3. Vezi dacă funcționează
4. Repară
5. Repetă

Abordarea Datadog este că o problemă care își are originea în cod are, de obicei, și soluția în cod, așa că platforma încearcă să îți ofere acea soluție, informată de ce știe despre aplicație: ownership-ul, schimbările recente și erorile aruncate.

El indică optimizarea interogărilor de bază de date ca exemplu. Orice model poate rescrie o interogare lentă; partea mai grea este să demonstrezi că rescrierea e mai rapidă și sigură înainte să ajungă în producție, așa că Datadog o testează mai întâi pe o copie realistă a datelor de producție și îți oferă un pull request cu dovezile atașate.

Bucla de operațiuni și securitate

Cealaltă buclă rulează în paralel, fie de aceiași oameni, fie de o echipă diferită:

1. Detectează
2. Investighează
3. Repară
4. Repetă

Aici, AI Guard de la Datadog triază evenimentele de securitate și blochează atacurile mai repede decât un analist care le parcurge manual. Agenții pot gestiona și sarcini operaționale de rutină pe care inginerii le fac zilnic, fără prea mult entuziasm, cum ar fi redimensionarea acelui pod Kubernetes.

În ambele bucle, Lê-Quôc este ferm în privința ordinii operațiunilor. Datadog nu pornește de la „iată AI, ce problemă poate rezolva?” Ci de la o problemă de care clienții se plâng deja, de obicei vreo variantă de „nu vreau să mai fac chestia asta repetitivă”, și înapoi la dacă un agent poate fi de încredere cu ea.

Lecția 5: Ține sub control cheltuielile cu AI

Costul este constrângerea care stă lângă siguranță, iar menținerea sub control a prețului pentru operaționalizarea modelelor de limbaj mari devine o disciplină în sine. Răspunsul lui Lê-Quôc la DASH este Agent Console de la Datadog.

Întreabă un dezvoltator de ce model are nevoie și, adesea, va numi cel mai puternic (și scump). Uneori e alegerea corectă, dar multă muncă e boilerplate pe care un model mai ieftin și mai rapid o rezolvă la fel de bine. Să le deosebești înseamnă să citești traiectoriile agenților unei organizații, ce unelte apelează și cât de des reușesc, până apar tipare.

Aceste tipare devin euristici, nu reguli: un model de frontieră precum cel mai nou Claude Opus sau modelele GPT pentru planificare, ceva ieftin precum Claude Haiku pentru generarea de teste.

Principiul de bază ține de cine deține decizia. Dacă urci costul într-o singură cifră, obții ce Lê-Quôc numește „foarte puțină acționabilitate”: fie toți opresc cheltuielile, ceea ce omoară munca utilă, fie toți continuă să cheltuiască, lucru nesustenabil pentru business. El preferă să pună datele în fața dezvoltatorilor și SRE-ilor care aleg modelele.

Lecția 6: Învață să înveți

Întrebat ce ar trebui să studieze noii ingineri, Lê-Quôc dă un răspuns care sună vechi, dar nu este.

Modelele sunt cei mai răbdători tutori inventați vreodată, capabili să explice orice, în orice ritm, un nivel de acces rezervat cândva regalității cu profesori particulari. Dar un tutor e util doar dacă îl chestionezi. Abilitatea e să știi ce să întrebi și cum să verifici răspunsul.

El recomandă să înțelegi calculatoarele strat cu strat, nu să le tratezi ca pe magie. Ia un scheduler, un load balancer, un sandbox și cere unui model să explice cum funcționează, apoi împinge mai departe:

• Ce înseamnă acest termen?
• Cum îl măsori?
• Care e matematica din spatele lui?
• Cum știi că funcționează bine?

A studia clasicele în felul acesta e intenționat lent. El o compară cu învățarea unui instrument; poți asculta muzică toată ziua, dar ca să cânți la pian, trebuie să-ți pui mâinile pe clape.

La fel și pentru codul scris de AI. Vibe coding e în regulă, spune el, atât timp cât te întorci și întrebi de ce a funcționat: de ce a fost construit așa, există abordări mai bune, pe ce a fost modelat. Scopul nu este să scrii mai puțin cod cu AI. Este să înțelegi codul pe care acum produci mult mai mult.

Gânduri finale

Mesajul central al lui Lê-Quôc este că bucla nu s-a schimbat, dar ritmul da. Diferența este că niciun om nu poate urmări îndeaproape la viteza cu care se mișcă acum AI, așa că observarea și o parte tot mai mare din construcție trec la agenți care nu obosesc și nu intră în panică.

El susține tratarea observabilității ca plan de control, nu ca un set de grafice. Dacă agenții vor scrie, testa, livra și opera software, au nevoie de aceeași ancorare în date reale din producție pe care se bazează inginerii buni, plus o persoană care păstrează deciziile de judecată și butonul de oprire. Datadog poziționează observabilitatea drept stratul care face schimbul acesta sigur.

Abilitatea pe care această perspectivă o cere inginerilor e clară: citește sistemele prin felul în care se comportă în producție, nu doar prin sursa lor. Dacă vrei să-ți formezi acest obicei, track-ul nostru Machine Learning in Production este un loc bun de început.