RAG pentru lecțiile învățate: nimeni nu caută înainte

Proiectul a pornit acum trei săptămâni. Estimarea pentru migrarea datelor e de zece zile. În arhiva companiei există un raport de închidere, scris acum un an și jumătate, care spune că aceeași migrare, la un client cu același ERP și cu aceeași structură de date istorice, a durat treizeci și patru de zile — și explică exact de ce.

Nimeni nu-l va deschide. Nu fiindcă e greu de găsit, ci fiindcă nimeni nu-l caută. Omul care face estimarea nu știe că documentul există, deci nu are ce întrebare să pună.

Ăsta e primul caz din cluster în care nu există interogare. Până acum, tiparul a fost mereu același: cineva formulează o întrebare, sistemul aduce documentul care o acoperă. Aici lipsește chiar prima parte. Mecanismul rămâne același RAG, dar tot ce se construiește deasupra lui se schimbă — de la ce declanșează căutarea până la ce înseamnă că sistemul a funcționat.

Primul caz din cluster fără întrebare

Declanșatorul e contextul, nu query-ul

Un sistem clasic de retrieval așteaptă. Stă pe loc până când cineva scrie ceva în casetă. Modelul e pull: utilizatorul trage informația când o vrea.

Pentru lecțiile învățate, modelul ăsta garantează eșecul. Documentul util e chiar cel despre care omul nu știe că există. Dacă retrievalul depinde de o întrebare, iar întrebarea depinde de a ști ce cauți, sistemul e util doar pentru cine nu are nevoie de el.

Alternativa e push: căutarea se declanșează din contextul de lucru. S-a deschis un proiect nou cu un anumit tip de client, o anumită tehnologie, un anumit tip de livrabil — asta e interogarea. Nu o propoziție, ci o stare.

De ce nu e același lucru cu inversarea de la calitate

Cazul cel mai apropiat din cluster e RAG pentru calitate și neconformități, unde interogarea nu e nici acolo o întrebare, ci o înregistrare de incident. Granița merită trasată, fiindcă par identice și nu sunt.

Acolo există un act deliberat: inginerul deschide un caz și vrea să știe dacă s-a mai întâmplat. Procesul îl obligă să caute, iar acțiunea corectivă nu se închide fără analiza precedentelor. Bucla e formalizată și cineva o apasă.

Aici nu apasă nimeni. Nu există proces care să forțeze consultarea, nu există câmp obligatoriu, nu există auditor care să întrebe ce lecții ai revizuit înainte de estimare. Diferența nu e de format al interogării, ci de existența ei.

Ce se schimbă arhitectural

Trei lucruri, și fiecare mută munca în altă parte decât te-ai aștepta.

Sistemul se leagă de evenimente, nu de o interfață. Un proiect creat, o estimare salvată, un document de ofertă generat — fiecare devine un declanșator, cu payload-ul lui de metadate.

Pragul de afișare devine o decizie de produs, nu una de ranking. Într-un chat, un rezultat slab costă o secundă. Într-un push, costă credibilitatea: două sugestii irelevante la rând și oamenii încetează să se mai uite.

Iar evaluarea nu mai are query-uri pe care să le noteze. Revin la asta la final, fiindcă e partea cel mai des rezolvată greșit.

Corpusul scris de oameni care nu-l vor mai citi

Trei patologii ale înregistrării de lecție

Un registru de lecții învățate se scrie la închiderea proiectului, sub presiune, de oameni care deja lucrează la altceva. Se vede în text.

Lecția vagă. „Comunicarea cu clientul putea fi mai bună.” E adevărată despre orice proiect din istorie și nu schimbă nicio decizie viitoare.

Lecția diplomatică. Fraza care descrie o problemă reală, dar ocolește cauza fiindcă în ședință era prezent cine a produs-o. Rămâne un simptom fără mecanism.

Lecția fără condiții de aplicabilitate. „Nu folosi bibliotecă X pentru rapoarte.” Corect — dar în ce context, la ce volum, cu ce constrângere? Fără condițiile în care e adevărată, e o interdicție pe care al doilea cititor o va ignora justificat.

Degradarea tăcută, fără feedback loop

Într-o bază de cunoștințe folosită zilnic, un document greșit se corectează pentru că cineva se lovește de el. Corpusul de lecții nu are mecanismul ăsta: nimeni nu îl citește, deci nimeni nu semnalează nimic.

Consecința e că nu poți evalua calitatea corpusului din utilizare, așa cum faci oriunde altundeva. Trebuie s-o evaluezi la ingestie sau nu o evaluezi deloc.

Practic, asta înseamnă un pas de calificare în momentul scrierii: un formular cu câmpuri separate în loc de o casetă de text liber, plus o verificare automată care respinge înregistrările care nu conțin nici o condiție de declanșare, nici o consecință măsurabilă.

Ce câmpuri fac o lecție regăsibilă

Textul liber singur nu e suficient, iar limita agregării peste text liber e aceeași pe care o descrie sinteza feedbackului clienților. Minimul care schimbă lucrurile:

• Condiția de declanșare — tipul de proiect, industria, tehnologia, dimensiunea echipei, tipul de contract.
• Faza în care problema a apărut și faza în care ar fi trebuit prevenită. Rareori aceeași.
• Consecința, exprimată în ceva numărabil: zile, refacturări, iterații suplimentare.
• Ce decizie ar fi trebuit luată altfel, formulată ca instrucțiune, nu ca observație.
• Data și valabilitatea — o lecție despre un furnizor sau o versiune de produs expiră; mecanica de expirare e cea din prospețime, ștergeri și reindexare.

Ultimul câmp face diferența între un corpus care ajută și unul care sabotează. O lecție despre un instrument care s-a schimbat între timp e mai periculoasă decât absența ei.

Ce spun datele publice, cu numitor

Cel mai solid set de date public pe subiect e vechi și merită citit ca atare. Într-un studiu comandat de Project Management Institute, Terry Williams a chestionat manageri de proiect și a obținut 522 de răspunsuri utilizabile; autorul declară explicit limitele — 96% dintre respondenți erau membri PMI, iar eșantionul e înclinat spre oameni deja interesați de subiect.

Cifrele relevante: 62,4% dintre organizații aveau proceduri formale de lecții învățate, dar doar 11,7% dintre acestea spuneau că procedurile chiar se respectau. La transfer, 47,8% considerau că lecțiile ajung de la individ la echipa de proiect, 35,6% că ajung la alte echipe și doar 22,2% că ajung în altă parte a organizației. Iar la întrebarea despre obstacole, 20,9% au bifat că depozitul de date e prea greu de căutat — mult sub lipsa de timp (67%) și lipsa de susținere managerială (62,5%).

Ultima cifră e cea de reținut. Problema declarată nu e că motorul de căutare e slab. E că nimeni nu ajunge până acolo.

Ce cer standardele și ce lasă nespus

Captarea e cerută explicit

Ediția a opta a PMBOK Guide, publicată de PMI în 2025, e standardul curent, iar versiunea actualizată a examenului PMP intră în vigoare pe 9 iulie 2026. ISO 21502:2020 e ghidul internațional în vigoare pentru managementul proiectelor — a înlocuit partea de proiect din ISO 21500:2012, iar ISO 21500:2021 a rămas documentul-umbrelă de vocabular și context. PRINCE2 7, publicat de PeopleCert în 2023, are „învață din experiență” ca principiu de sine stătător, unul dintre cele șapte.

Toate trei cer, în forme diferite, ca experiența proiectelor anterioare să fie captată și luată în considerare.

Golul e la partea de regăsire

Niciunul nu descrie momentul consultării. Standardele spun ce trebuie să existe și cine răspunde de existența lui. Nu spun în ce secundă a planificării cineva e obligat să se uite în registru, nici ce se întâmplă dacă nu o face.

Asta nu e o critică a standardelor — sunt documente de guvernanță, nu specificații de produs. E însă exact spațiul în care trăiește un sistem tehnic: obligația de a capta creează corpusul, iar absența unei obligații de a citi creează problema pe care o rezolvi.

Verifică ediția înainte să codifici ceva. Standardele de management de proiect se revizuiesc, iar o referință îngropată în conținutul indexat devine falsă tăcut. Ține versiunea ca metadată, nu ca frază în corpul documentului.

Când răspunsul corect nu e un sistem

Dacă organizația livrează cinci proiecte pe an, cu aceiași opt oameni, lecțiile circulă prin conversație și nu ai ce automatiza. Dacă echipele se schimbă între proiecte, dacă oamenii pleacă, dacă livrarea e distribuită pe mai multe fusuri — atunci memoria organizațională chiar e un artefact, nu o proprietate a grupului. Pragurile de decizie sunt în când nu folosești RAG.

Valoarea unei lecții e invers proporțională cu frecvența ei

Relevanța optimizează exact semnalul greșit

Un sistem de retrieval bine calibrat scoate în față ce e cel mai apropiat de interogare și, implicit, ce e bine reprezentat în corpus. Formulările frecvente câștigă. Tiparele repetate câștigă.

La lecții învățate, asta e fix invers față de valoare. O observație care apare în patruzeci de rapoarte de închidere e deja parte din cultura echipei; nimeni nu are nevoie să i se spună a patruzeci și una oară că estimările optimiste dor. Lecția care schimbă o decizie e cea scrisă o singură dată, de un singur om, despre o situație care s-a întâmplat o singură dată — și care e pe cale să se întâmple a doua oară.

Ce faci concret

Trei ajustări, în ordinea efectului.

Deduplicare semantică înainte de ordonare. Grupezi lecțiile care spun același lucru și le tratezi ca pe una singură, cu un contor. Contorul e util ca semnal de sistem — patruzeci de apariții înseamnă un proces defect, nu o lecție — dar nu ocupă patruzeci de locuri în rezultate.

Reordonare pe consecință declarată, nu pe similaritate. Dacă ai câmpul de consecință din secțiunea anterioară, ai cu ce reordona. O lecție care a costat treizeci de zile bate una care a costat o jumătate de zi, chiar dacă a doua seamănă mai bine cu contextul curent.

Diversitate impusă în setul final. Nu trei variante ale aceleiași observații, ci trei lecții din familii diferite. E o constrângere de selecție, nu de scor, și se implementează după pasul de reranking.

Riscul opus

Împins prea departe, mecanismul devine un generator de excepții. Dacă premiezi raritatea, sistemul va scoate mereu cazul bizar, cel care s-a întâmplat o dată din motive care nu se mai repetă.

Corecția e condiția de declanșare, nu scorul: o lecție rară intră în rezultate doar dacă contextul proiectului curent chiar se potrivește cu contextul în care a apărut. Raritatea o ridică în ordine; potrivirea o califică. Fără a doua, prima e zgomot.

Momentele de injecție: unde intră lecția în fluxul de lucru

Cinci ferestre, nu un canal permanent

Un sistem push care vorbește tot timpul devine o notificare pe care oamenii o închid. Alege puține momente, alege-le pe cele în care se ia o decizie reversibilă.

Pasul de retrieval declanșat automat de o stare a fluxului, nu de un om, e același tipar descris în agentic RAG și multi-hop — cu diferența că aici nu urmărește un obiectiv, ci reacționează la un eveniment.

Bugetul de atenție e mic și se cheltuie o dată

Maximum două-trei lecții per moment. Fiecare cu o singură propoziție de ce apare acum: „proiect similar, același ERP, a depășit estimarea de migrare cu 24 de zile”. Fără rezumat generat care să sune convingător peste o sursă subțire — regulile de sinteză și de citare sunt în cum arată un răspuns bun de RAG.

Și un buton de respingere care întreabă de ce. Ăsta e singurul semnal de calitate pe care îl vei primi vreodată de la utilizatori, fiindcă nimeni nu vine spontan să se plângă de un sistem pe care nu l-a cerut.

Nu e un chatbot, dar are nevoie și de unul

Interfața principală e integrarea în uneltele existente. Caseta de întrebări rămâne totuși utilă pentru minoritatea care știe ce caută — de obicei oameni cu vechime, care își amintesc vag un proiect și vor să-l regăsească.

Corpusul se suprapune, de altfel, cu memoria tehnică internă din RAG pentru cercetare și dezvoltare și cu materialul de ramp-up pentru oamenii noi, unde aceleași rapoarte de închidere explică de ce lucrurile stau cum stau. Tratează-le ca profile diferite peste un index comun, nu ca trei produse.

Diferența față de helpdeskul intern rămâne cea de adopție: acolo omul are o nevoie și caută singur soluția, deci sistemul se folosește din prima zi. Aici adopția nu vine de la sine niciodată — vine din integrare sau nu vine deloc.

Măsurarea fără interogări: decizii schimbate, nu clickuri

De ce metricile clasice nu se transferă

Metricile de retrieval presupun perechi întrebare-document și un adevăr de referință construit pe ele. Fără întrebare, nu ai perechea. Nu poți calcula relevanță per query când nu există query, iar rata de rezolvare fără operator uman nu înseamnă nimic aici — nu exista nici un tichet.

Cadrul general rămâne cel din cum evaluezi un sistem RAG; ce se schimbă e unitatea măsurată. Nu răspunsul, ci decizia.

Patru indicatori care spun ceva

Rata de acceptare la injecție. Din lecțiile afișate, câte au fost deschise sau marcate ca utile. E metrica de suprafață, nu de fond, dar dacă scade sub un prag, restul nu mai contează — sistemul e ignorat.

Decizii documentate ca schimbate. Câte estimări, alegeri tehnice sau clauze s-au modificat după ce sistemul a arătat o lecție. Presupune un câmp de justificare acolo unde se ia decizia, iar câmpul ăla e cea mai valoroasă piesă de instrumentare din tot proiectul.

Recidiva. Câte lecții din retrospectivele de anul acesta repetă, în alte cuvinte, o lecție deja existentă în registru la momentul în care proiectul a început. E metrica de fond și singura care măsoară scopul real.

Acoperirea condițiilor de declanșare. Ce procent din lecțiile din corpus au metadate suficiente ca să poată fi vreodată declanșate. O lecție fără condiție nu va apărea niciodată, indiferent cât de bine e scrisă.

Setul de evaluare se construiește retroactiv

Adevărul de referință există deja, doar că e în trecut. Iei zece proiecte închise, identifici trei-cinci decizii proaste documentate în retrospectivele lor, apoi verifici două lucruri: exista în registru, la data deciziei, o lecție care ar fi prevenit-o? Și dacă da, ar fi scos-o sistemul în față, cu contextul de atunci?

Perechea de răspunsuri e mai utilă decât orice scor. Dacă lecția nu exista, ai o problemă de captare. Dacă exista și sistemul n-ar fi adus-o, ai o problemă de metadate sau de ordonare. Dacă exista, ar fi fost adusă, dar oricum n-ar fi fost citită, problema e momentul de injecție.

Ce cifre am omis deliberat

Spațiul „reutilizarea lecțiilor învățate crește rata de succes cu X%” e plin de procente fără numitor, republicate din listă în listă, cu atribuire la organizații care nu au măsurat nimic. Nu am inclus niciuna: în cazurile verificate, lanțul de citare se rupea după doi pași, fără eșantion, fără metodologie, fără an de referință.

Ce a rezistat verificării e studiul din 2006 citat mai sus — cu tot cu limitele pe care le declară autorul. Faptul că cel mai bun set de date public pe subiect are douăzeci de ani spune ceva despre cât de puțin s-a măsurat serios de atunci.

Pilotul: un tip de proiect, doi ani de arhivă

Alege o singură familie de proiecte cu istoric comparabil. Importă rapoartele de închidere din ultimii doi ani, normalizează condițiile de declanșare, apoi rulează sistemul retroactiv pe proiecte deja terminate.

Livrabilul primelor șase săptămâni nu e o interfață. E răspunsul la o singură întrebare: din greșelile documentate anul trecut, pe câte le-ar fi semnalat sistemul înainte să se producă? Dacă răspunsul e aproape de zero, problema e la calitatea corpusului, nu la retrieval, iar următoarele șase săptămâni se investesc în formularul de captare.

Întrebări frecvente

Cum conving oamenii să scrie lecții mai bune, dacă tot nu le citesc?

Nu prin instruire, ci prin formular. Câmpuri separate pentru condiție, consecință și decizie alternativă produc înregistrări utilizabile chiar și de la cineva grăbit. Iar când sistemul începe să arate lecții scrise de colegi, cu numele lor, calitatea scrierii crește singură — e primul feedback loop pe care corpusul l-a avut vreodată.

Ce fac cu lecțiile care conțin nume de clienți sau detalii de contract?

Le separi la ingestie: contextul tehnic rămâne căutabil, identificarea clientului devine un câmp cu permisiuni. Un sistem push e mai expus decât unul pull, fiindcă afișează fără ca cineva să fi cerut — deci filtrarea se face la retrieval, înainte ca modelul să vadă ceva, nu în textul răspunsului.

Cât istoric îmi trebuie ca să merite?

Contează repetabilitatea, nu volumul. Cincizeci de proiecte comparabile, cu rapoarte de închidere decente, dau rezultate utile. Cinci sute de proiecte complet diferite între ele, mult mai puțin — nu ai cu ce potrivi contextul.

Pot genera automat lecțiile din documentele proiectului?

Poți propune candidați: din procese-verbale, din tichete redeschise, din cereri de modificare. Nu poți stabili automat cauza, iar o lecție cu cauză greșită se propagă mai departe decât una lipsă. Tratează generarea ca pe o coadă de propuneri validate de omul care a condus proiectul.

Cum evit ca sistemul să blocheze decizii cu lecții depășite?

Prin data vizibilă și prin valabilitate declarată. O lecție de acum patru ani despre o versiune de produs care nu mai există trebuie să iasă din index sau să apară marcată explicit, nu să fie afișată la egalitate cu una de anul trecut.

Începe cu ultimele zece proiecte închise. Pentru fiecare greșeală consemnată în retrospectivă, verifică dacă lecția exista deja în registru când proiectul a pornit. Cifra care iese e valoarea sistemului, măsurată pe datele tale, înainte de a indexa ceva.

Dacă vrei să discuți cum ar arăta momentele de injecție în fluxul tău de livrare, trimite un mesaj. Restul cazurilor pe corpusuri de companie sunt în hubul Cazuri de utilizare enterprise, iar imaginea completă a serviciului în AI & RAG.