RAG pentru IT și operațiuni: runbook-uri și incidente

Ora 03:10. Alerta a plecat acum patru minute, iar tu ești persoana de gardă. Un serviciu de plăți întoarce erori pe jumătate din trafic. Ai un canal de incident în care intră deja șase oameni și senzația clară că undeva există un runbook exact pentru situația asta, scris de cineva care nu mai lucrează aici.

Întrebarea ta nu e „ce spune documentația despre serviciul de plăți”. E „ce apăs acum, în ordinea asta, ca să nu stric mai mult decât s-a stricat deja”.

Toate celelalte cazuri de utilizare din serie au o constrângere dominantă: corectitudinea, permisiunea, trasabilitatea. Aici constrângerea dominantă e timpul. Un răspuns corect livrat în patru minute nu e un răspuns bun mai lent — e un răspuns inutil, pentru că între timp incidentul s-a schimbat, iar tu ai luat deja decizia fără el.

Un sistem RAG pentru IT și operațiuni schimbă arhitectura în patru locuri: ce indexezi dintr-un corpus care se scrie singur, unde tragi linia între document și starea live a sistemului, cum formatezi un răspuns pentru cineva cu sarcină cognitivă maximă și cum tratezi ceasurile de raportare care pornesc în paralel cu incidentul. Dacă mecanica de bază nu e clară, ce este RAG și când îl folosești acoperă fundamentele.

Ce se schimbă când constrângerea dominantă e timpul

Răspunsul are o fereastră de valabilitate

Într-un asistent de documentație, un răspuns rămâne valabil săptămâni. Într-un incident activ, valabilitatea se măsoară în minute și scade singură, chiar dacă nimeni nu atinge nimic. La minutul doi, întrebarea e „ce e serviciul ăsta și de cine depinde”. La minutul opt, după ce cineva a repornit un pod, întrebarea e alta, iar răspunsul dinainte a devenit context istoric. Un sistem care returnează în opt secunde un răspuns de 70% e strict mai util decât unul care returnează în două minute un răspuns de 95%.

Consecința de arhitectură: aici bugetul de latență e o cerință funcțională, nu o optimizare de la final. Un lanț cu reranking greu, două runde de multi-hop și un model mare de sinteză poate fi cel mai bun sistem din companie și complet nefolosibil la 03:10.

Nu e helpdesk-ul intern și nu e service-ul pe teren

Cele două cazuri vecine din serie par să acopere deja subiectul. Nu îl acoperă.

La helpdesk-ul intern, scopul e deflectarea tichetului de nivel unu și adopția: utilizatorul are timp și poate reformula. Aici e deja în execuție, iar sistemul intră în lanțul de decizie, nu înaintea lui.

La mentenanța și service-ul pe teren presiunea de timp există, dar corpusul e al producătorului, se versionează lent și filtrul dur e identitatea utilajului. Aici sistemul e al tău, corpusul e scris în cea mai mare parte de sistemele monitorizate, iar filtrul dur e prospețimea.

Iar când urgența e fizică — incendiu, evacuare, oameni de scos din clădire — constrângerile se schimbă din nou: la RAG pe procedurile de urgență, infrastructura nu mai e obiectul intervenției, ci ceva ce procedura însăși cere să oprești la pasul trei.

Corpusul se scrie singur și îmbătrânește în aceeași zi

Într-un proiect de documentație internă, corpusul e scris de oameni, ca să fie citit. În operațiuni, o parte majoră din el e produsă automat, de sistemele despre care pune întrebări.

Patru straturi, doi autori

Runbook-uri și proceduri. Scrise de oameni, cu intenție. Stratul cu cea mai mare valoare per cuvânt și cel mai expus la degradare tăcută.

Postmortem-uri și analize de incident. Scrise de oameni, după fapt. Conțin exact ce nu scrie nicăieri altundeva: ce părea evident și era greșit.

Alerte, log-uri și evenimente. Scrise de mașini, în volum uriaș, fără narativ. Nu sunt corpus de retrieval în sensul obișnuit — sunt telemetrie.

Thread-uri de incident din chat. Hibrid: oameni care scriu în timp real despre ce fac mașinile. Cea mai bogată și cea mai murdară sursă din companie.

Diferența față de orice alt corpus intern e ritmul. Un document de politică internă rezistă doi ani. Un runbook care descrie o infrastructură care se redeployează de mai multe ori pe zi poate deveni fals într-o după-amiază, fără ca nimeni să-l fi editat. Mecanica generală de actualizare e tratată în prospețime, ștergeri și reindexare; ce se schimbă aici e că fereastra e de ore, nu de luni.

Există și un motiv structural pentru care volumul crește. Raportul DORA 2025 publicat de Google Cloud, construit pe răspunsurile a aproape 5.000 de profesioniști din tehnologie, descrie inteligența artificială ca amplificator: adopția crește debitul de livrare, dar crește și instabilitatea, iar fără sisteme de control solide — testare automată, versionare matură, bucle rapide de feedback — volumul mai mare de schimbări se traduce în instabilitate. Mai multe schimbări înseamnă mai multe runbook-uri care rămân în urmă.

Runbook-ul mort e mai periculos decât absența lui

Un runbook lipsă produce o căutare. Un runbook greșit produce o acțiune.

Pentru retrieval, cele două arată identic: același format, aceleași cuvinte, aceeași structură de comenzi. Diferența nu e recuperabilă din text, deci trebuie să vină din metadate. Trei semnale ieftine, în ordinea utilității:

• Ultima execuție confirmată, nu ultima editare. Un runbook editat acum o lună, dar executat cu succes ieri, e viu. Unul editat ieri și neexecutat de un an e o ipoteză.
• Existența resurselor pe care le numește. Dacă procedura referă un serviciu, o coadă sau un job care nu mai există în inventar, marcheaz-o automat ca suspectă.
• Un owner care mai e de gardă. Nu autorul, ci echipa care primește azi paginile pentru serviciul respectiv.

Practic: nu șterge runbook-urile vechi, degradează-le. Marcajul „neexecutat din februarie, referă un serviciu redenumit” face rezultatul util. Același text, prezentat curat, e o capcană.

Postmortemul: cea mai bună sursă, scrisă pentru cine era acolo

Postmortem-urile sunt cel mai dens strat de cunoaștere operațională dintr-o companie. Au și două defecte care le fac greu de folosit direct.

Primul e de registru. Cartea de Site Reliability Engineering a Google descrie postmortemul blameless drept un document care identifică cauzele contribuitoare ale unui incident fără să incrimineze o persoană sau o echipă, presupunând că toți cei implicați au acționat corect cu informația pe care o aveau atunci. Consecința: textul e scris pentru cineva care cunoaște deja sistemul. Un chunk extras din el poate fi perfect relevant și complet neinterpretabil singur.

Al doilea e temporal. Un postmortem descrie un sistem care, la momentul citirii, s-a schimbat deja: acțiunile de remediere au fost, în cel mai bun caz, executate, deci descrierea defectului nu mai e valabilă.

Ce funcționează: indexează postmortemul cu perioada la care se referă și cu statusul acțiunilor de remediere, iar răspunsul spune explicit că sursa e un incident din trecut, nu o procedură curentă. Un postmortem citat ca instrucțiune e o eroare de categorie.

Pregătirea generică a surselor e în cum construiești o bază de cunoștințe AI. Ce se adaugă aici: fiecare chunk are nevoie de o dată de referință și de un marcaj de strat, altfel se amestecă în același răspuns.

Ce indexezi și ce întrebi live

Cea mai frecventă greșeală de proiectare în operațiuni e să tratezi starea sistemului ca pe un document.

Starea sistemului nu e retrieval

„Câte instanțe rulează acum în cluster” nu are răspuns în niciun corpus. Are răspuns într-un API. Dacă lași sistemul să răspundă din documentație, primești numărul din exemplul de configurare scris acum opt luni, livrat cu citare, în mijlocul unui incident.

Pragurile generale sunt în când NU folosești RAG; ce contează e cum le operaționalizezi: un pas de clasificare înaintea retrievalului, care trimite întrebarea fie spre corpus, fie spre un apel de stare.

Când o întrebare are nevoie de ambele — „procedura de failover și dacă replica secundară e sănătoasă acum” — intri în teritoriul descris în agentic RAG și multi-hop: un pas de interogare a stării, un pas de retrieval, o singură sinteză. Cu o precizare de buget: fiecare hop adaugă secunde, iar secundele au preț.

Pragul dintre document și telemetrie

Log-urile nu se indexează ca text: sunt prea multe, se repetă și nu conțin narativ. Ce merită indexat din stratul generat de mașini e mult mai mic:

• Definițiile alertelor, cu pragul, serviciul și runbook-ul asociat.
• Rezumatele de incident produse la închidere, nu fluxul brut.
• Schimbările de configurare cu autor, dată și scop — cel mai bun predictor al cauzei, într-o formă compactă.

Când întrebarea trece de la „ce s-a schimbat” la „de ce a fost scris așa”, corpusul nu mai e cel operațional, ci codul și istoricul lui de commituri — caz tratat separat în RAG peste codul sursă.

Restul rămâne în instrumentele de observabilitate, interogat la cerere. Un sistem care indexează log-uri ajunge scump, lent și mai slab decât un grep bine formulat.

Formatul e o cerință de corectitudine, nu de stil

Regulile generale de sinteză sunt în cum arată un răspuns bun de RAG. În incident, formatul devine parte din corectitudine: un răspuns corect livrat ca trei paragrafe de proză va fi citit pe diagonală și aplicat parțial.

Pași numerotați, precondiții înaintea comenzii

Un om cu sarcină cognitivă maximă citește un pas, execută, revine. Deci: un pas pe rând, verbul la început, precondiția înaintea comenzii. „Verifică întâi că traficul e mutat pe regiunea secundară; dacă nu e, oprește-te” apare înainte de comanda de restart, nu ca notă de subsol — ordinea în care apare informația într-un răspuns e ordinea în care va fi executată.

Comanda distructivă cere alt tratament

Aici e diferența de fond față de orice alt caz de utilizare din serie. O eroare într-un asistent de documentație produce confuzie. O eroare aici produce o acțiune ireversibilă, executată cu încredere, pe un sistem de producție — un drop, un scale-to-zero, un rollback pe versiunea greșită.

Trei reguli care se plătesc singure:

1. Comenzile care distrug stare se marchează explicit în răspuns, cu ce anume devine irecuperabil.
2. Sistemul nu execută, decât dacă ai construit deliberat un flux cu confirmare, identitate propagată și jurnal — iar atunci intri în discuția din controlul accesului în RAG, pentru că „cine are voie să vadă procedura” și „cine are voie să o ruleze” sunt două întrebări diferite.
3. Citarea e obligatorie și verificabilă: document, dată, ultima execuție confirmată. Un inginer experimentat verifică sursa înainte să apese, dacă i-o dai la îndemână. Mecanica e în cum reduce RAG halucinațiile.

Refuzul rapid bate răspunsul complet

„Nu am o procedură pentru serviciul ăsta; ultimele trei incidente similare sunt aici, iar owner-ul de gardă e echipa X” e un răspuns excelent la 03:10. Se livrează în două secunde și mută decizia mai departe.

Un răspuns plauzibil construit din fragmente vecine e mai rău decât tăcerea, pentru că se consumă atenție ca să fie infirmat — exact resursa care lipsește.

Ceasul de raportare: 24 de ore, 72 de ore, o lună — și de la ce moment

În paralel cu incidentul tehnic pornește un al doilea cronometru, iar acesta are consecințe juridice. Aici sistemul de retrieval are un rol clar: nu decide dacă raportezi, dar livrează în secunde textul aplicabil și termenul, ca decizia să fie luată de om, în cunoștință de cauză.

NIS2 în România: lanțul normativ real

Directiva (UE) 2022/2555 nu te obligă direct — actul național o face. În România, transpunerea s-a făcut prin OUG nr. 155/2024, aprobată cu modificări și completări prin Legea nr. 124/2025, cu Directoratul Național de Securitate Cibernetică drept autoritate competentă. Operaționalizarea a venit prin ordinele DNSC nr. 1/2025 și nr. 2/2025, intrate în vigoare pe 20 august 2025, care reglementează notificarea în vederea înregistrării și metodologia de evaluare a nivelului de risc.

Textul ordonanței stabilește o raportare în trepte către echipa națională de răspuns la incidente: o avertizare timpurie fără întârzieri nejustificate, dar nu mai târziu de 24 de ore de la luarea la cunoștință despre incidentul semnificativ; o raportare a incidentului în cel mult 72 de ore, care actualizează avertizarea și prezintă o evaluare inițială a gravității, a impactului și a indicatorilor de compromitere; un raport intermediar la cererea echipei naționale; și un raport final în cel mult o lună de la transmiterea notificării incidentului.

Detaliul care se pierde cel mai des: ultimul termen curge de la notificare, nu de la detecție și nici de la închiderea incidentului.

DORA pornește alt ceas

Pentru entitățile financiare, regulamentul privind reziliența operațională digitală adaugă un al doilea regim, aplicabil din 17 ianuarie 2025. Structura seamănă, ancorele nu: notificarea inițială se transmite cât mai devreme posibil, în 4 ore de la clasificarea incidentului ca major și în cel mult 24 de ore de la luarea la cunoștință; raportul intermediar în 72 de ore de la notificarea inițială; raportul final în cel mult o lună de la ultimul raport intermediar. Clasificarea ca „major” se face pe criteriile din regulamentul delegat (UE) 2024/1772.

Diferența practică e brutală: sub DORA, ceasul principal pornește la clasificare, iar clasificarea e ea însăși o decizie care trebuie luată repede. Un sistem care îți dă criteriile în zece secunde e mai util decât unul care îți dă istoricul complet în două minute.

Trei ancore, un singur incident

Adaugă obligația din articolul 33 GDPR — notificare către autoritatea de supraveghere în 72 de ore de la luarea la cunoștință, când sunt implicate date cu caracter personal — și ai trei cronometre pornite simultan, din momente diferite, către destinatari diferiți.

De aceea răspunsul corect al sistemului nu e un număr. E numărul plus ancora lui: „24 de ore de la momentul în care ați luat cunoștință” e utilizabil, „24 de ore” nu e.

Partea de date personale, temei legal și redactare a informațiilor sensibile din jurnale e tratată separat în RAG și GDPR, iar legătura dintre obligație și artefactul care o dovedește, în RAG pentru conformitate și audit intern — acolo miza e pista de audit construită după fapt, aici e decizia luată în timpul faptei.

Acronimul care se ciocnește în propriul tău corpus

Un test bun pentru un corpus de operațiuni: întreabă-l ce înseamnă DORA.

Sunt două lucruri diferite și amândouă apar legitim în documentația unei echipe de platformă: regulamentul european de reziliență operațională digitală și programul de cercetare DevOps Research and Assessment, ale cărui metrici sunt vocabular standard pentru livrare software. Un sistem care nu dezambiguizează va amesteca, într-un singur răspuns, termene de raportare și metrici de deployment.

Problema are și o variantă temporală: metrica de recuperare din setul DORA a fost redenumită, în raportul din 2023, din „time to restore” în „failed deployment recovery time”. Corpusul tău conține aproape sigur ambele forme, scrise în ani diferiți, despre același lucru. Un dicționar de echivalențe cu marcaj de perioadă nu e o rafinare — e condiția ca răspunsul să fie interpretabil.

Ce măsori când răspunsul are termen de valabilitate

Instrumentarul general — recall la retrieval, faithfulness la generare, set de referință din întrebări reale — e în cum evaluezi un sistem RAG. Ce se schimbă aici e că apar metrici pe care celelalte cazuri nu le au.

Latența la percentila 95, nu media

Media ascunde exact cazurile care contează: un sistem cu 1,2 secunde în medie și 14 secunde la percentila 95 va fi abandonat, pentru că oamenii își amintesc așteptările lungi, nu pe cele scurte. Măsoară timpul până la primul token util, nu până la răspunsul complet, și tratează-l ca buget — dacă un pas de reranking costă trei secunde, trebuie să demonstreze pe întrebări reale de incident că le merită.

Rata de abținere și acuratețea comenzii

Două metrici specifice, ambele mai importante decât recall-ul general:

• Abținerea corectă. Din întrebările fără acoperire reală în corpus, în câte a spus sistemul că nu știe, în loc să producă o procedură plauzibilă. Într-un context cu acțiuni ireversibile, abținerea e funcționalitate.
• Acuratețea comenzii. Din răspunsurile care conțin comenzi sau pași de execuție, în câte comanda era corectă pentru mediul, versiunea și serviciul din întrebare. Un răspuns cu procedura potrivită și parametrul greșit se numără ca eșec, nu ca succes parțial.

Setul de test conține deliberat capcane: servicii redenumite, proceduri retrase, incidente rezolvate prin acțiuni care între timp au fost interzise. Un set curat nu măsoară riscul real.

Ce nu citezi: procentele de reducere a MTTR

Spațiul „AIOps reduce timpul mediu de rezolvare cu X%” e saturat de cifre fără numitor. Nu apar aici din trei motive: metodologia lipsește aproape întotdeauna; definiția diferă între surse — timp până la mitigare sau până la rezolvare completă, cu sau fără incidentele minore; iar sursa e, de regulă, materialul comercial al celui care vinde soluția.

Alternativa e mai puțin spectaculoasă și mult mai utilă: măsoară-ți propriul punct de plecare. Timpul median de la alertă până la prima acțiune de mitigare, procentul de incidente în care s-a găsit un runbook aplicabil, numărul de escaladări către un al doilea om. Trei cifre, culese trei săptămâni, valorează mai mult decât orice procent citat.

De unde pornești: reia zece incidente reale

Nu porni de la corpus. Pornește de la incidente încheiate, unde știi deja răspunsul corect.

Ia ultimele zece-douăzeci de incidente semnificative și extrage întrebările care s-au pus efectiv în canal, în ordinea în care s-au pus. Obții un set de evaluare care nu se putea inventa la birou și, în paralel, harta golurilor de documentație.

Apoi rulează sistemul peste ele, ca replay: pentru fiecare întrebare notează dacă răspunsul ar fi fost corect la momentul acela, cu informația disponibilă atunci, nu cu ce știi acum. Diferența e lista ta de lucru, iar mărimea ei îți spune în două săptămâni dacă merită să continui.

Un semnal de oprire: dacă majoritatea întrebărilor din replay sunt despre starea live a sistemelor, nu ai o problemă de retrieval, ci una de observabilitate. Motivele generale pentru care astfel de proiecte eșuează sunt inventariate în de ce eșuează un sistem RAG în producție.

Întrebări frecvente

Cât de repede trebuie să răspundă un asistent de incident?

Suficient de repede cât să nu schimbe comportamentul persoanei de gardă: în practică, primul conținut util sub trei secunde și răspunsul complet sub zece. Peste prag, oamenii revin la căutarea manuală, iar sistemul devine un instrument pe care îl deschide cineva a doua zi, la scrierea postmortemului.

Poate sistemul să execute singur comenzile de remediere?

Tehnic, da. Ca decizie de produs, nu la prima versiune. Începe cu sugestie plus citare, măsoară acuratețea comenzii câteva luni și abia apoi automatizează selectiv doar acțiunile reversibile, cu identitate propagată, confirmare și jurnal. Un sistem care execută înainte să fi demonstrat acuratețe transformă o eroare de retrieval într-un incident propriu.

Cum împiedic sistemul să dea o procedură dintr-un mediu greșit?

Prin filtrare pe metadate înainte de căutarea semantică — mediu, regiune, versiune — nu prin instrucțiuni în prompt. Producția și staging-ul au proceduri care arată aproape identic, iar diferența dintre ele e exact ce nu trebuie ratat. Dacă mediul nu poate fi determinat din întrebare, sistemul întreabă scurt, cu două opțiuni, în loc să aleagă.

Ajută la scrierea raportării către autoritate?

La primul draft, da, și e o utilizare rezonabilă: sistemul are cronologia din canal, textul obligației aplicabile și termenul. Ce nu poate face e să decidă dacă incidentul e semnificativ sau major — clasificarea rămâne la om, cu juridicul, iar sistemul îi livrează criteriile și ancora ceasului, nu concluzia.

Un asistent de incident care funcționează nu e un proiect de model. E un proiect de prospețime a corpusului, de buget de latență și de format al răspunsului — în ordinea asta. Restul cazurilor din serie stau în cazuri de utilizare enterprise, sursele de tip technical documentation au propriul hub, iar imaginea completă a unui sistem livrat cap-coadă e în soluții AI și RAG. Începe cu replay-ul pe ultimele zece incidente: e singurul test care spune adevărul înainte să coste ceva.