RAG pentru onboarding și training: ramp-up mai scurt

E ziua a noua. Omul nou întreabă pe canalul echipei: „unde văd dacă un client are contract activ?” Nimeni nu răspunde imediat, fiindcă întrebarea, așa cum e pusă, nu are sens în modelul tău de date. Nu există „contract activ”. Există abonament în stare running, există cont cu plată suspendată și există comandă semnată dar neactivată — trei lucruri diferite, verificate în trei locuri diferite. Peste douăzeci de minute cineva îi explică. Peste patru zile, alt om nou din aceeași cohortă de onboarding întreabă același lucru, cu alte cuvinte greșite.

Ăsta e cazul de utilizare pentru un RAG de onboarding și training de produs. Seamănă cu helpdeskul intern — același angajat, aceeași companie, aceleași permisiuni — dar problema centrală e alta. La helpdesk, omul știe ce vrea și nu găsește unde scrie. La onboarding, omul nu știe încă ce nu știe: pune întrebarea greșită, cu termenii greșiți, despre lucrul potrivit.

Mecanismul rămâne același RAG. Ce se schimbă e unde investești: nu în ranking mai bun, ci în felul în care sistemul înțelege o întrebare prost formulată. Și în ce face cu ea după.

Ce e diferit la onboarding față de celelalte cazuri

Trei diferențe, și fiecare împinge arhitectura în altă direcție decât cea la care te-ai aștepta.

Utilizatorul nu știe încă ce nu știe

Un angajat cu doi ani vechime întreabă „care e SLA-ul pe tichetele P2?”. Un om în săptămâna a doua întreabă „cât de repede trebuie să răspund la ceva urgent?”. A doua întrebare nu conține niciun termen care apare în documentul care o rezolvă.

Retrievalul semantic ajută aici mai mult decât căutarea pe cuvinte cheie, fiindcă lucrează cu sensuri, nu cu forme — diferența dintre semantic search și full-text e exact asta. Dar nu e suficient. Embeddings-urile mapează bine parafrazele; nu mapează un termen intern inventat de companie, pe care omul nou nici nu-l cunoaște. Distanța dintre „ceva urgent” și „prioritate P2” nu e semantică, e de vocabular.

Consecința practică: bugetul tău de efort se duce în normalizarea întrebării, nu în reranking. La un sistem de onboarding bine făcut, straturile de query understanding fac mai mult pentru calitatea răspunsului decât orice tunning de similaritate.

Răspunsul optim e pedagogic, nu minim

La enablement de vânzări, formatul care funcționează e brutal de scurt: verdict, condiție, sursă, trei rânduri, gata. Omul vorbește cu clientul în timp ce citește și nu are bandă pentru mai mult.

Aici e exact invers. Un om în onboarding nu vrea doar răspunsul; vrea să nu mai pună întrebarea a doua oară. Un răspuns de trei rânduri care rezolvă tichetul curent și nu explică nimic îl lasă exact la fel de dependent luna viitoare. Răspunsul util conține definiția termenului, motivul pentru care lucrurile stau așa, un exemplu concret și indicația unde citește mai departe.

Contrastul e deliberat: același corpus, același stack, format opus. Principiile generale de sinteză sunt în cum arată un răspuns bun de RAG; onboardingul e cazul în care constrângerea de lungime se relaxează, nu se strânge.

Corpusul are o ordine, iar retrievalul o ignoră

Materialul de onboarding e secvențial prin construcție. Ce înveți în săptămâna 1 e prerechizit pentru ce înveți în săptămâna 6. Documentul despre arhitectura de facturare presupune că știi deja ce e un cont și ce e un abonament.

Un index vectorial nu are noțiunea asta. Îți întoarce cel mai similar chunk, indiferent dacă omul are sau nu contextul ca să-l înțeleagă. Rezultatul e un răspuns corect și inutilizabil: tehnic exact, complet opac pentru cine îl citește în ziua a treia.

Asta nu se rezolvă cu embeddings mai bune. Se rezolvă cu metadate de nivel și de prerechizit, plus o regulă de filtrare la retrieval. Revin la mecanică mai jos.

Cele patru cazuri împart infrastructura și diferă la aproape fiecare decizie de deasupra ei. Restul lor sunt în cazurile de utilizare enterprise din cluster.

Corpusul de învățare: ce indexezi și cum îl marchezi

Un corpus de onboarding arată dezordonat fiindcă e făcut din materiale scrise pentru alte scopuri: prezentări ținute o dată, înregistrări păstrate din inerție, documente de proces scrise pentru cine le știa deja.

Curriculum și materiale de curs

Sunt cea mai bună sursă din tot corpusul, fiindcă cineva le-a structurat deja pedagogic. Un modul de curs are ordine internă, are un scop declarat și de obicei are un proprietar viu.

Pregătirea e cea standard pentru o bază de cunoștințe destinată RAG, cu o precizare: tăierea nu trebuie să rupă lecția. Un chunk care conține concluzia fără premisa de deasupra e mai rău decât inutil, fiindcă pare complet. Aici merită să te uiți serios la strategiile de chunking care păstrează ierarhia secțiunii și contextul părintelui — la material didactic, diferența se vede imediat.

Înregistrări de training și transcrieri

Valoarea lor e că prind explicația pe care nimeni n-a scris-o: analogia pe care o folosește mereu cineva din echipă, întrebarea din sală care se repetă an de an, cazul particular pe care documentația îl trece cu vederea.

Costul lor e că sunt lungi, nestructurate și îmbătrânesc invizibil. O înregistrare din urmă cu doi ani arată la fel cu una de luna trecută. Minimul acceptabil: transcriere cu marcaj de timp, segmentare pe subiect și un câmp obligatoriu de dată și versiune de produs. Fără ultimul, o înregistrare veche e o mină.

Glosar de produs și dicționar de acronime

Piesa cu cel mai bun raport efort/valoare din tot proiectul. Fiecare companie are câteva zeci de termeni proprii, dintre care jumătate sunt cuvinte comune folosite cu alt sens.

Glosarul servește două funcții deodată: e sursă pentru răspuns și e material pentru normalizarea întrebării. Aceeași disciplină de dicționar apare și la helpdeskul intern, unde acronimele de HR și IT fac ravagii; la onboarding e mai importantă, fiindcă utilizatorul nu poate să-și dea seama singur că a folosit termenul greșit.

Ce nu intră în index

Trei categorii, din motive diferite.

Exercițiile cu răspunsuri și grilele de certificare. Dacă intră în index, sistemul devine o modalitate de a trece testul fără să înveți. Ai construit un instrument de învățare care produce certificări false.

Feedbackul managerilor și evaluările individuale. Sunt date despre performanța unei persoane, nu material didactic. Nu au ce căuta într-un index interogabil de colegi — problema e de permisiuni, iar mecanica e cea din helpdeskul intern, unde filtrarea se face la retrieval, înainte ca modelul să vadă ceva.

Materialul depășit pe care nimeni nu-l mai întreține. Tentația e să-l lași „că poate ajută”. La onboarding nu ajută niciodată. Un om nou nu are cum să discearnă. Vezi secțiunea despre fundația greșită.

Query understanding: problema centrală, nu ranking-ul

Dacă ai un singur buget de îmbunătățire, îl cheltui aici.

Dicționarul de sinonime, ca artefact viu

Construiește o mapare explicită între termenii pe care îi folosesc oamenii noi și termenii care apar în documentație. „Client” → cont, organizație, tenant. „Anulare” → reziliere, downgrade, suspendare. „Urgent” → P1, P2, incident major.

Maparea nu se ghicește. Se strânge din întrebările reale, iar sursa cea mai bogată sunt canalele de chat unde oamenii noi întreabă acum. Primele două sute de întrebări îți dau aproape tot vocabularul greșit pe care merită să-l acoperi.

Aplicarea e la interogare, nu la ingestie: întrebarea se extinde cu termenii canonici înainte de căutare, iar documentele rămân neatinse. Așa poți schimba dicționarul fără reindexare.

Expansiunea de query și retrievalul multiplu

O întrebare vagă merită mai multe interogări, nu una singură mai lungă. Un pas ieftin de reformulare — un model mic care produce două-trei variante ale întrebării, cu termenii canonici incluși — crește vizibil rata de acoperire pe întrebările de începător.

Câștigul e mai mare decât la un corpus tehnic obișnuit, tocmai pentru că distanța dintre formularea utilizatorului și formularea documentului e mai mare aici decât în orice alt caz de utilizare.

Când sistemul cere lămuriri

Există un prag sub care nicio expansiune nu salvează întrebarea. „Cum fac raportul?” — care raport, pentru cine, în ce sistem?

Regula practică: dacă primele rezultate vin din arii nelegate între ele, întrebarea e ambiguă, iar sistemul pune o singură întrebare de clarificare, cu două-trei opțiuni concrete. Nu un chestionar. O întrebare, opțiuni închise, apoi răspunsul.

Contraindicație: la un utilizator experimentat, clarificarea e enervantă. La unul nou, e utilă și, în plus, îl învață distincția pe care n-o știa — că există trei rapoarte diferite și că ele nu sunt interschimbabile.

De ce nu e o problemă de ranking

Rankingul rezolvă ordinea într-un set de candidați deja găsiți. Dacă întrebarea nu aduce în set documentul potrivit, poți rearanja cât vrei — nu apare din neant. Când reformulezi întrebarea, schimbi setul; când reranking-ul lucrează, schimbi doar ordinea.

Semnalul de diagnostic e simplu: uită-te la recall pe întrebările de începător, nu la precizia pe primele rezultate. Dacă documentul corect nu e în primele treizeci de candidați, ai o problemă de interogare, nu de ordonare.

Secvența: metadate de nivel și prerechizite

Aici e a doua investiție care contează, și e o problemă de metadate, nu de model.

Ce marchezi pe fiecare document

Minimul util: nivelul țintă (săptămâna 1, luna 1, luna 3, avansat), lista de concepte prerechizite, produsul și versiunea, proprietarul și data ultimei revizuiri. Nivelul nu trebuie să fie sofisticat — patru trepte acoperă majoritatea situațiilor.

Marcarea se face o dată, la ingestie, de către oamenii care dețin materialul. E muncă manuală și nu există scurtătură onestă: un model poate propune nivelul, dar cineva care cunoaște domeniul confirmă.

Filtrarea la retrieval, nu la generare

Nivelul utilizatorului vine din sistemul de HR sau din programul de onboarding: la ce zi e omul, ce module a parcurs. Retrievalul preferă materialul de la nivelul lui și de sub el, și depunctează — fără să elimine — ce e mult peste.

Depunctarea contează mai mult decât filtrarea dură. Un om în săptămâna a doua care întreabă ceva avansat merită un răspuns, nu un refuz. Merită însă un răspuns care începe cu contextul care îi lipsește.

Întrebările „din viitor”

Când cea mai bună potrivire e un material de nivel mult superior, răspunsul corect are două părți: explicația scurtă la nivelul lui, plus semnalul explicit că subiectul complet vine mai târziu în program și unde anume.

Efectul secundar e cel mai valoros: sistemul îi dă omului o hartă. Nu doar răspunde, ci îi arată unde se află întrebarea în ansamblu — lucrul pe care un retrieval plat nu-l poate face niciodată.

Riscul specific: informația greșită devine fundație

Toate cazurile de RAG au risc de eroare. Aici eroarea are o proprietate neplăcută: se compune.

Cum se produce

Un document de proces din urmă cu optsprezece luni rămâne în index. Un om în săptămâna a treia întreabă cum se escaladează un incident. Sistemul răspunde fidel din documentul acela, citând corect. Omul nu are cu ce compara, deci îl internalizează ca pe felul în care se fac lucrurile. Îl repetă în ședințe. Îl explică următorului om nou, peste patru luni.

Sistemul n-a halucinat. A citat un document real. Diferența față de un senior care primește același răspuns e că seniorul se oprește la „stai, nu așa se făcea anul trecut”. Omul nou n-are semnalul ăla, iar corecția, când vine, e o dezvățare, nu o actualizare.

Trei bariere, în ordinea eficacității

Prospețime agresivă pe corpusul de onboarding. Aici pragul e mai strict decât oriunde altundeva în sistem. Un material de onboarding fără revizuire în ultimele șase luni iese din index sau intră marcat, nu rămâne tăcut. Mecanica de reindexare și ștergere selectivă e în prospețime, ștergeri și reindexare; ce se schimbă la onboarding e pragul, nu tehnica.

Proprietar obligatoriu pe fiecare document. Un material fără nume atașat e un material pe care nimeni nu-l va corecta. Câmpul de proprietar nu e birocrație; e singura cale prin care o eroare semnalată ajunge la cineva care poate să o repare.

Canal de corecție într-un singur clic. Sub fiecare răspuns, un buton care spune „asta nu mai e valabil” și care deschide un tichet către proprietarul documentului, cu chunk-ul atașat. Fără el, oamenii noi observă erori și tac — sunt noi, presupun că greșesc ei.

Bucla de feedback: întrebările lor sunt un audit

Aici e partea care se plătește singură. Lista întrebărilor puse de oamenii noi, grupată pe subiecte, e cel mai bun raport de calitate a documentației pe care îl poți obține.

Un subiect care generează multe întrebări are documentația proastă sau inexistentă. Un termen care apare des în întrebări și rar în documente e o gaură de vocabular. O întrebare la care sistemul răspunde corect dar oamenii tot o repun înseamnă că răspunsul nu e găsibil în forma în care îl caută ei.

Rulează analiza lunar în primul an. E singurul caz de utilizare în care sistemul îți spune sistematic ce e stricat în organizație, nu doar ce nu găsește.

Tranziția onboarding → enablement și granița cu un LMS

Un sistem de onboarding are o problemă pe care celelalte nu o au: utilizatorul lui încetează, în câteva luni, să mai fie utilizatorul lui.

Semnalele că cineva a ieșit din onboarding

Nu e o dată din calendar. Sunt tipare de comportament: întrebările încep să conțină termenii interni corecți, se scurtează, devin punctuale în loc de conceptuale, iar rata de clarificare cerută de sistem scade.

Când tiparele astea apar, formatul pedagogic devine cost, nu beneficiu. Omul vrea răspunsul, nu lecția.

Ce schimbi, concret

Trei lucruri, în ordinea asta: formatul se scurtează la structura procedurală, filtrul de nivel se dezactivează (materialul avansat devine implicit disponibil), iar corpusul se lărgește spre materialul operațional curent.

Practic, același om trece din sistemul de onboarding în helpdeskul intern sau, dacă e în echipa comercială, în cel de enablement de vânzări. Indexul factual se refolosește; se schimbă formatul, filtrele și metrica de succes. Merită construit ca o comutare de profil, nu ca două produse separate.

De ce nu e același lucru cu un LMS

Un LMS livrează un curriculum: module în ordine, progres, evaluări, certificări. E push — sistemul decide ce vezi și când.

Un RAG de onboarding e pull: răspunde la ce întrebi, când întrebi, în contextul în care ești. Nu urmărește progresul, nu certifică și nu înlocuiește parcursul structurat.

Cele două sunt complementare și granița e curată: LMS-ul deține secvența și evaluarea, RAG-ul deține răspunsul la întrebarea nepusă în curs. Dacă construiești RAG-ul ca să înlocuiască LMS-ul, ajungi cu un curriculum fără ordine. Dacă îl construiești fără LMS deloc, ajungi cu oameni care știu să caute, dar nu au parcurs nimic.

Ce măsori și ce cifre din piață nu merită încrederea

Metrica de la support — deflection, adică tichete rezolvate fără om — nu se transferă aici, și e important de spus de ce. La support, o întrebare care nu ajunge la un agent e un câștig curat. La onboarding, o întrebare care nu ajunge la un coleg poate fi un câștig sau o pierdere: dacă omul nou încetează să mai vorbească cu echipa, ai automatizat izolarea, nu învățarea.

Patru indicatori care chiar spun ceva

Timpul până la prima contribuție independentă. Definește-l concret pentru rolul respectiv — primul commit în producție, primul tichet închis singur, primul apel condus fără supervizare — și măsoară-l pe cohorte. E singura metrică apropiată de scopul real.

Rata de întrebări repetate de aceeași persoană. Dacă același om pune aceeași întrebare la interval de două săptămâni, răspunsul a rezolvat momentul, nu înțelegerea. E semnalul direct că formatul e prea scurt.

Acoperirea vocabularului. Din întrebările puse, la câte a fost nevoie de clarificare sau au dat rezultate din arii nelegate. Scade pe măsură ce dicționarul de sinonime crește; dacă nu scade, dicționarul nu e alimentat din întrebări reale.

Corecțiile raportate pe răspunsuri. Câte răspunsuri au fost marcate ca depășite și cât a durat până s-a reparat documentul-sursă. E metrica de sănătate a corpusului, nu a modelului.

Setul de evaluare se construiește la fel ca oriunde altundeva, cu o particularitate: întrebările de test trebuie culese de la oameni noi, în formularea lor greșită, nu rescrise de un expert. Un set de evaluare formulat corect măsoară un sistem pe care nimeni nu-l folosește. Metricile de retrieval și de generare sunt în cum evaluezi un sistem RAG.

Ce rezistă la verificare

Puțin, dar suficient.

Ediția din 2026 a raportului State of Sales al firmei de consultanță The Bridge Group, a zecea ediție bienală, pe răspunsuri de la 158 de companii B2B, arată că timpul mediu de ramp-up al unui Account Executive a ajuns la 6,2 luni — cel mai ridicat nivel din istoria acestei cercetări. În aceeași ediție, 48% dintre reprezentanți și-au atins cota anuală, în scădere de la 51% în 2024, iar experiența medie cerută la angajare a urcat la 3,7 ani, de la 2,7 ani în 2022. Combinația e semnificativă: companiile angajează oameni mai experimentați și, cu toate astea, aceștia ajung mai greu la productivitate.

Pe partea de onboarding în general, Gallup raportează că doar 12% dintre angajați sunt total de acord că organizația lor face o treabă bună la integrarea oamenilor noi. Cifra e veche — articolul e din 2018 și e încă publicat pe site-ul Gallup — dar e o măsurătoare proprie, cu metodologie cunoscută, nu o statistică reciclată.

Ce am omis intenționat

Trei exemple, fiindcă mecanismul se repetă și merită să-l recunoști singur.

„Ramp-up mediu de 5,7 luni în 2026.” Apare în zeci de articole datate 2026. E cifra din raportul The Bridge Group din 2024, republicată ca și cum ar fi curentă. Cifra din 2026 e 6,2. Diferența nu e mare, dar sursa e greșită, iar un business case construit pe ea se sprijină pe date vechi de doi ani.

„Ramp-up-ul a crescut cu 32% din 2020.” Aceeași familie. E raportul 5,7 / 4,3 dintre cifra din 2024 și cea din 2020, calculat de altcineva și atribuit unei surse terțe care nu a măsurat nimic. Calculul e corect; problema e că circulă ca și cum ar fi o constatare, nu o operație aritmetică pe cifre de acum doi ani.

„50% dintre angajați pleacă în primele 18 luni.” Apare inclusiv în articolul Gallup citat mai sus, atribuit unei alte organizații — dar linkul de acolo duce la un articol de opinie, nu la un studiu cu metodologie. Când lanțul de citare se rupe după doi pași, cifra nu se folosește. Faptul că o găsești pe un site respectabil nu îi dă o metodologie.

Regula pe care merită s-o aplici la orice cifră de onboarding: caută forma originală, verifică anul și verifică numitorul. Ecosistemul de „statistici de onboarding” e aproape integral construit din liste care se citează una pe alta.

Ce arăți în primele șase săptămâni

Un pilot onest e restrâns: o singură funcție sau echipă, materialul de curriculum indexat și marcat pe niveluri, glosarul construit din primele două sute de întrebări reale, fără integrare cu LMS-ul la început. Măsori timpul până la prima contribuție independentă pe cohorta pilot față de cohorta anterioară și rata de întrebări repetate.

Dicționarul de sinonime și marcarea de nivel sunt cele două lucruri care produc diferența vizibilă. Restul — reranking, agenți, integrări — pot aștepta etapa a doua.

Întrebări frecvente

Cât de mare trebuie să fie echipa ca să merite?

Contează ritmul de angajare, nu mărimea. O echipă de treizeci de oameni care aduce cinci oameni noi pe trimestru are o problemă reală și repetitivă. Una de două sute care angajează doi oameni pe an nu are — acolo, un coleg dedicat costă mai puțin decât un sistem. Pragurile de decizie sunt în când nu folosești RAG.

Pot folosi înregistrările de training vechi de câțiva ani?

Da, dar numai cu dată și versiune de produs vizibile în răspuns, și numai dacă cineva confirmă că materialul e încă valabil. O înregistrare veche fără marcaj e cea mai eficientă modalitate de a instala o convingere greșită într-un om nou.

Cum împiedic sistemul să devină un mod de a trece testele?

Ține grilele de evaluare și răspunsurile la exerciții în afara indexului. Dacă un exercițiu poate fi rezolvat prin interogarea sistemului, exercițiul măsoară altceva decât credeai.

Ce fac dacă documentația internă e slabă sau lipsește?

Nu construi sistemul mai întâi. Un RAG peste un corpus subțire produce răspunsuri sigure pe sine din surse puține — ceea ce la onboarding e mai rău decât nimic. Folosește primele două luni ca să scrii ce lipsește, ghidat de întrebările reale ale ultimei cohorte.

Trebuie să fie separat de sistemul de helpdesk intern?

Nu neapărat ca infrastructură. Indexul factual se suprapune în bună măsură. Separat trebuie să fie profilul: formatul răspunsului, filtrul de nivel și metrica de succes. În practică, o comutare pe baza vechimii utilizatorului, nu un al doilea produs.

Un RAG de onboarding nu e un chatbot peste Drive-ul cu materiale de curs. E o decizie despre cum înțelege sistemul o întrebare pusă greșit și despre ce face ca răspunsul să nu devină fundație pentru o convingere falsă. Dicționar de sinonime construit din întrebări reale, metadate de nivel și prerechizite, format pedagogic, prospețime strictă pe un corpus pe care nimeni nu-l poate contesta din interior.

Dacă vrei să construiești unul pentru echipa ta — sau doar să afli dacă problema ta e de retrieval ori de documentație lipsă — scrie-ne. Restul cazurilor și al arhitecturilor sunt în secțiunea despre AI și RAG.