RAG pentru helpdesk intern: IT, HR și self-service

Ai un wiki intern cu câteva mii de pagini. O parte sunt scrise acum trei ani, o parte au un owner care a plecat din firmă, iar câteva se contrazic între ele. În paralel, echipa de IT răspunde a douăzecea oară la aceeași întrebare despre VPN, iar HR-ul explică fiecărui al doilea angajat cum se cere concediu fără plată.

Ăsta e momentul în care cineva propune: hai să punem un RAG peste wiki. Ideea e corectă. Execuția eșuează din patru motive care nu apar aproape deloc într-un proiect de support extern.

Utilizatorul e angajat, deci întrebarea „ce am voie să văd” devine centrală. Corpusul e scris pentru uz intern, adică prost structurat și plin de acronime pe care nu le știe nimeni din afară. Câștigul se măsoară în ore de IT și HR recuperate, nu în tichete de client evitate. Iar adopția — nu acuratețea — e problema care omoară cele mai multe proiecte interne.

Articolul de față tratează exact aceste patru fronturi. Dacă vrei întâi mecanica de bază, ce este RAG și când îl folosești acoperă fundamentele.

Ce se schimbă când utilizatorul e angajat, nu client

Un asistent de support extern și unul intern arată identic în diagramă: întrebare, retrieval, generare, răspuns cu citări. Diferențele stau în constrângeri, iar constrângerile decid arhitectura.

Trei profiluri de risc, nu unul singur

Merită separate clar, pentru că fiecare cere alt tip de investiție.

Agent-assist. Sistemul sugerează, un om verifică înainte să trimită. E configurația cu cel mai mic risc: fiecare răspuns trece printr-un filtru uman care cunoaște contextul.

Client final, direct. Un răspuns greșit ajunge nefiltrat la cineva din afară. Costul e reputațional și, în anumite domenii, contractual. Fluxul complet pentru acest caz e detaliat în RAG pentru customer support.

Angajat. Aici se inversează logica. Cel mai rău lucru care se poate întâmpla nu e un răspuns greșit, ci un răspuns corect livrat persoanei greșite. Grila de salarizare a departamentului vecin. Nota de evaluare a unui coleg. Procedura de disciplinare deschisă pe cineva anume. Sistemul nu a halucinat nimic — a citat fidel un document real, către cineva care nu avea dreptul să-l vadă.

Consecința practică: într-un sistem extern, primul buget de calitate merge în grounding și în citarea corectă a surselor. Intern, primul buget merge în filtrarea la retrieval. Restul vine după.

Corpusul e scris pentru uz intern, nu pentru consum

Documentația publică trece prin cineva. Are owner, are review, are un ton. Baza de cunoștințe internă nu trece prin nimeni. Cineva a scris o pagină ca să nu mai explice a treia oară același lucru, a lipit două screenshot-uri și a plecat mai departe.

Rezultatul e un corpus cu proprietăți neplăcute pentru retrieval: pagini fără titlu descriptiv, decizii îngropate în comentarii, proceduri care presupun context pe care doar autorul îl avea. Un chunk extras din așa ceva poate fi perfect relevant semantic și complet inutilizabil ca răspuns.

Metrica se schimbă: ore recuperate, nu tichete evitate

La support extern, unitatea de măsură e tichetul: câte n-au mai ajuns la un agent. Intern, tichetul e o măsură slabă, pentru că cea mai mare parte a costului nu e în tichet. E în cele patruzeci de minute în care angajatul a căutat singur, a întrebat pe Slack, a primit un răspuns parțial și abia apoi a deschis tichetul.

Benchmark-ul global de experiență IT publicat de HappySignals pentru 2026, construit pe aproape două milioane de răspunsuri din peste 130 de țări, arată că angajații raportează în medie 3 ore și 18 minute de timp productiv pierdut per incident IT — o cifră care a urcat lent față de acum cinci ani, în ciuda investițiilor în automatizare. Costul real stă acolo, nu în minutele petrecute de agentul de service desk.

Corpusul intern: de ce e mai greu decât pare

Pregătirea documentelor pentru retrieval e un subiect în sine — cum construiești o bază de cunoștințe AI acoperă partea generică. Aici contează ce e specific unui corpus intern.

Wiki-ul mort

Într-un spațiu Confluence sau Notion de companie, o proporție mare din pagini sunt inactive: procedura veche lăsată acolo „pentru istoric”, varianta de test a unui template, pagina de onboarding pentru un rol care nu mai există.

Problema nu e că ocupă spațiu. E că arată exact ca o pagină validă pentru un sistem de retrieval. Aceleași cuvinte, aceeași structură, aceeași încredere aparentă. Un angajat care primește o procedură expirată, citată frumos cu link, o va aplica.

Trei filtre care ajută înainte de indexare:

• Data ultimei modificări, folosită ca semnal de degradare — nu ca excludere brutală. O politică de concediu neschimbată de doi ani e probabil în vigoare; un runbook de deployment neschimbat de doi ani e aproape sigur mort.
• Semnalele de trafic din wiki: paginile cu zero vizualizări în ultimele douăsprezece luni sunt candidate serioase la excludere.
• Un owner viu. Dacă autorul și ultimul editor nu mai sunt în firmă și nimeni nu a preluat pagina, documentul intră în corpus cu prioritate redusă sau deloc.

Ștergerile și actualizările nu sunt un eveniment unic, ci un proces continuu — prospețimea și reindexarea într-un sistem RAG tratează mecanica.

Jargonul și acronimele de firmă

Fiecare companie își construiește o limbă proprie. Sistemul intern de pontaj se numește altfel decât produsul pe care rulează. Procesul de aprobare a cheltuielilor are un acronim din trei litere pe care nimeni nu-l scrie desfășurat. Departamentul se numește oficial într-un fel și, în vorbire, altfel.

Pentru retrieval, asta e o problemă de vocabular, nu de semantică. Un embedding model antrenat pe text general nu are cum să știe că „CFT” înseamnă în firma ta „cerere de finanțare tehnică”. Documentul care explică procedura folosește forma desfășurată; angajatul întreabă cu acronimul. Similaritatea semantică nu le apropie, pentru că nu există nimic în date care să le lege.

Tichetele rezolvate: sursa cea mai bună și cea mai periculoasă

Istoricul de tichete IT și HR e cel mai util corpus din companie. Conține întrebarea reală, în limbajul real al angajatului, împreună cu rezolvarea care a funcționat. Nicio pagină de wiki nu are asta.

Are însă și trei defecte care trebuie tratate explicit:

1. Conține date personale. Nume, adrese, numere de telefon, ocazional date de sănătate sau financiare. Trebuie curățate înainte de indexare — RAG și GDPR acoperă redactarea PII și temeiul legal.
2. Conține rezolvări greșite. Un tichet închis nu e un tichet rezolvat corect. Fără un filtru pe rezoluție confirmată, indexezi și soluțiile care au funcționat accidental.
3. Conține soluții expirate. „Restartează serviciul X” a fost valid până la migrarea de anul trecut.

Practic: indexează doar tichete cu rezoluție confirmată, mai noi de o fereastră pe care o alegi conștient, curățate de PII, și marchează-le în metadate ca sursă de tip „istoric”, ca răspunsul să poată spune de unde vine.

Modul în care tai documentele contează la fel de mult ca ce alegi să indexezi — vezi strategiile de chunking pentru compromisurile concrete.

Dicționarul de acronime: cum faci retrievalul să înțeleagă limba firmei

Soluția la problema de vocabular nu e un model mai bun. E un dicționar de sinonime, construit manual la început și extins din date după.

De unde extragi vocabularul

Patru surse, în ordinea rentabilității:

• Log-urile de căutare din wiki. Interogările fără rezultat sunt lista ta de acronime necunoscute, gata sortată după frecvență.
• Titlurile de tichete. Formele scurte apar acolo natural, pentru că oamenii scriu repede.
• Glosarul de onboarding, dacă există. De obicei e incomplet și vechi, dar e un punct de plecare gratuit.
• Douăzeci de minute cu un om din IT și unul din HR. Vor produce, din memorie, majoritatea termenilor care contează.

Nu ai nevoie de exhaustivitate. Ai nevoie de primii cincizeci-o sută de termeni, care acoperă de obicei majoritatea traficului.

Query expansion sau normalizare la indexare

Ai două locuri în care poți aplica dicționarul, cu compromisuri diferite.

La interogare (query expansion). Înainte de retrieval, extinzi întrebarea cu formele echivalente: „CFT” devine „CFT cerere de finanțare tehnică”. Avantaj: nu reindexezi nimic când adaugi un termen nou. Dezavantaj: interogarea se lungește, iar componenta lexicală a căutării poate zgomotoși dacă exagerezi.

La indexare (normalizare). Îmbogățești chunk-urile cu formele alternative în momentul procesării. Avantaj: retrievalul rămâne curat și rapid. Dezavantaj: fiecare adăugire în dicționar cere reindexare parțială.

În practică, combinația funcționează cel mai bine cu hybrid search și reranking: componenta lexicală prinde acronimul exact, componenta semantică prinde reformularea, iar reranker-ul decide ordinea. Un dicționar de sinonime aplicat doar pe partea semantică ratează exact cazul pentru care a fost construit.

Cum ții dicționarul viu

Un dicționar de acronime îmbătrânește la fel de repede ca wiki-ul. Leagă-l de un proces: interogările fără rezultat bun se adună într-o coadă săptămânală, cineva le parcurge în zece minute și adaugă termenii noi. Fără bucla asta, dicționarul devine în șase luni încă o pagină moartă din wiki.

„Câte zile de concediu mai am?” — întrebarea care nu e RAG

Asta e întrebarea care apare în primele zece minute de la lansare, la fiecare implementare internă. Și e întrebarea la care un sistem de retrieval nu are cum să răspundă corect.

Retrieval răspunde la „ce scrie”, nu la „cât am eu”

RAG caută în documente. Documentul de politică de concediu spune câte zile se acordă pe an, cum se calculează pentru part-time și care e termenul de notificare. Nu spune câte zile a consumat un anume angajat până în iulie. Informația aia stă în HRIS, într-un rând de bază de date, și se schimbă la fiecare aprobare.

Dacă lași sistemul să răspundă din documente la o astfel de întrebare, primești un răspuns care sună autoritar și e greșit pentru persoana care întreabă — cel mai prost tip de eroare posibil într-un context HR. Delimitarea generală e tratată în când NU folosești RAG; aici contează cum o operaționalizezi.

Routerul de intenție: trei căi, nu una

Soluția e un pas de clasificare înaintea retrievalului, care trimite întrebarea pe una din trei rute.

Ruta a doua și a treia nu sunt retrieval, sunt tool-calling: sistemul cheamă o funcție cu identitatea angajatului, primește un răspuns structurat și îl formulează în limbaj natural. Când o întrebare are nevoie de ambele — „câte zile mai am și până când trebuie să le consum” — intri în teritoriul descris în agentic RAG și multi-hop: un pas de interogare, un pas de retrieval, o singură sinteză.

Ce faci când nu ai integrarea

De cele mai multe ori, la lansare, nu ai încă acces la API-ul de HRIS. Nu e un motiv să amâni proiectul, dar e un motiv să fii explicit.

Comportamentul corect: sistemul recunoaște întrebarea ca fiind despre starea personală, spune clar că nu are acces la datele individuale, explică regula generală din politică și oferă calea directă — linkul către portalul unde angajatul își vede soldul. Un refuz util e mai valoros decât un răspuns plauzibil. Cum arată concret un astfel de răspuns e detaliat în ce înseamnă un răspuns bun de RAG.

Permisiuni: specificul datelor de personal

Mecanica generală a controlului accesului — filtrare pe metadate, propagarea identității, verificarea la retrieval — e acoperită în controlul accesului în RAG. Ce urmează e specific unui corpus de HR.

Filtrarea se face la retrieval, nu la generare

Merită repetat, pentru că e greșeala care apare cel mai des în implementările interne rapide: nu poți instrui modelul să „nu menționeze salariile”. Dacă documentul a intrat în context, a fost deja citit de un sistem la care angajatul nu ar fi avut acces. Filtrarea se aplică înainte, ca predicat pe interogare, nu după, ca instrucțiune în prompt.

Trei categorii de documente HR

Corpusul de HR nu e omogen. Tratat ca un bloc, ori blochează prea mult, ori expune prea mult.

Public intern. Politici generale, regulament intern, beneficii disponibile tuturor, proceduri de solicitare. Vizibile pentru orice angajat autentificat. Aici stă majoritatea volumului de întrebări.

Segmentat. Politici pe departament, grile de salarizare pe bandă, proceduri de bonusare, beneficii negociate local. Vizibile după apartenență — și e important ca apartenența să vină din sursa autoritară de identitate, nu dintr-un câmp copiat manual într-un CMS.

Personal. Contracte individuale, evaluări, sesizări, dosare disciplinare, date medicale. În marea majoritate a cazurilor, decizia corectă e să nu intre deloc în corpusul asistentului. Beneficiul marginal e mic, iar riscul e disproporționat.

Ce loghezi și ce nu

Ai nevoie de audit trail: cine a întrebat, ce documente au fost returnate, ce a răspuns sistemul. Fără el nu poți investiga un incident și nu poți demonstra conformitatea.

Ai nevoie și de reținere: log-urile unui asistent HR conțin, prin natura lor, întrebări sensibile despre situații personale. Stabilește o perioadă de păstrare scurtă, restricționează accesul la log-uri la fel de strict ca la documentele-sursă și nu trimite conținutul întrebărilor în instrumente de analytics generice.

Adopția: sistemul bun pe care nu-l folosește nimeni

Ăsta e modul de eșec dominant al proiectelor interne. Nu acuratețea, nu latența, nu costul — pur și simplu nefolosirea.

Datele susțin diagnosticul. Indicatorul Gallup pe adopția AI la locul de muncă arată, pentru februarie 2026, că 41% dintre angajații americani spun că organizația lor a integrat instrumente AI, dar doar 28% folosesc AI cel puțin de câteva ori pe săptămână. Gallup numește diferența „decalajul dintre integrare și adopție”: implementarea nu garantează utilizarea.

Pune-l unde lucrează oamenii

Un portal nou e un obstacol. Angajatul trebuie să-și amintească de existența lui, să-l găsească, să se autentifice — pentru o întrebare de treizeci de secunde. Va întreba pe Slack sau pe Teams, ca până acum.

Asistentul intern trebuie să trăiască acolo unde deja se pune întrebarea: în clientul de chat al companiei, în canalul de IT, în bara de căutare din wiki. Aceeași identitate, aceeași sesiune, zero pași în plus. E singura decizie de produs care schimbă vizibil curba de adopție.

Managerii decid adopția, nu comunicarea internă

Tot din datele Gallup: angajații care sunt complet de acord că managerul lor susține activ folosirea AI în echipă au de 1,7 ori mai multe șanse să folosească AI cel puțin de câteva ori pe săptămână. Doar 21% dintre angajați se află în acea categorie.

Concluzia practică e neplăcută pentru cine planifică un lansament: un email de la conducere și o pagină de anunț nu produc adopție. Un manager care folosește asistentul într-o ședință de echipă și arată răspunsul produce adopție.

Bucla de feedback care ține corpusul viu

Un asistent intern e singurul sistem din companie care știe, zilnic, ce nu găsesc oamenii. Interogările fără răspuns bun sunt o listă de priorități de documentare, gratuită și actualizată automat.

Fă din ea un artefact: un raport săptămânal cu întrebările nerezolvate, grupate pe temă, trimis către ownerii de conținut din IT și HR. Bucla asta transformă asistentul din consumator de documentație în motor de îmbunătățire a documentației — și e argumentul care ține proiectul finanțat după primele trei luni. Pentru partea de măsurare riguroasă a calității retrievalului, metricile de evaluare RAG dau instrumentarul.

Cum măsori ROI-ul în ore recuperate

De ce „rata de deflection” nu spune nimic singură

Cifrele publicate pentru rata de deflection variază enorm — de la sub 10% la peste 70% — și nu pentru că unele sisteme sunt de zece ori mai bune. Variază pentru că definiția diferă la fiecare sursă.

Unele numără orice sesiune care se închide fără click pe „escaladează”. Asta include și angajatul care a renunțat frustrat și a scris un email două ore mai târziu. Altele numără doar cazurile în care nu s-a deschis niciun tichet pe aceeași temă într-o fereastră de câteva zile. Între cele două definiții e o diferență de zeci de puncte procentuale pe exact același sistem.

Concret: nu compara procentul tău cu unul din materialele de vânzări ale unui furnizor. Definește-ți propria regulă, scrie-o și măsoară consecvent față de ea. Un 22% măsurat strict e mai util decât un 60% măsurat permisiv.

Cele două părți ale ecuației

Câștigul real are două componente, și de obicei se raportează doar una.

Ore recuperate de echipa de suport. Numărul de tichete de nivel unu care nu mai ajung la un om, înmulțit cu timpul mediu de tratare. E partea ușor de măsurat și, de regulă, cea mai mică.

Ore recuperate de angajați. Diferența dintre timpul de la întrebare la răspuns înainte și după. Aici stă masa câștigului, pentru că se înmulțește cu tot efectivul, nu cu echipa de suport. Cifra HappySignals de 3 ore și 18 minute pierdute per incident IT indică ordinul de mărime; a ta se măsoară, nu se presupune.

Aceeași sursă adaugă o observație contraintuitivă, utilă la prioritizare: doar 6,6% din feedbackul pozitiv al angajaților se referă la rezolvarea tehnică în sine. Restul e despre comunicare, viteză și ușurința de a obține ajutor. Un asistent care răspunde în cinci secunde „nu știu, dar uite cui să scrii” mută experiența mai mult decât te-ai aștepta.

Baseline-ul pe care nu-l ai

Problema cu formula de mai sus e că are nevoie de un „înainte”, iar cele mai multe companii nu-l au. Nimeni nu măsoară cât durează, azi, de la întrebare la răspuns pentru o procedură internă.

Se rezolvă în două săptămâni, înainte de orice linie de cod: o întrebare atașată la formularul de închidere a tichetului („cât timp ai pierdut din cauza asta?”) și un eșantion de treizeci de întrebări reale cronometrate manual. Fără baseline, orice cifră de după lansare e o afirmație, nu o măsurătoare. Pentru contextul de costuri de construcție și operare, cât costă un sistem RAG dă structura de cheltuieli.

Un plan de 90 de zile

Zilele 1–30: un singur domeniu

Alege domeniul cu cel mai mare volum de întrebări repetitive și cel mai mic risc de confidențialitate. De obicei e IT: parole, VPN, echipamente, acces la aplicații. Indexează runbook-urile și tichetele rezolvate din ultimul an. Construiește dicționarul de acronime. Măsoară baseline-ul în paralel.

Nu porni cu HR. Corpusul e mai sensibil, permisiunile sunt mai complicate, iar o eroare acolo costă încrederea de care ai nevoie mai târziu.

Zilele 31–60: pilot pe un departament

Un departament, între treizeci și o sută de oameni, cu un manager care vrea să fie implicat. Asistentul trăiește în chat, nu în portal. Escaladarea către om e la un click, vizibilă, nu ascunsă.

Urmărește trei lucruri: procentul de întrebări fără răspuns bun, distribuția pe categorii de întrebări și lista de goluri de documentație. Primele două spun dacă sistemul funcționează. A treia e livrabilul care justifică extinderea.

Zilele 61–90: HR și guvernanță

Adaugă domeniul HR cu segmentarea pe trei categorii descrisă mai sus, pornind doar de la stratul public intern. Adaugă routerul de intenție și prima integrare de tip tool-calling, dacă API-ul de HRIS e disponibil.

În paralel, fixează procesul: cine deține corpusul, cine parcurge coada de întrebări nerezolvate, la ce interval se reindexează, cine aprobă adăugarea unei surse noi. Un helpdesk intern fără owner de proces se degradează în șase luni până la nivelul wiki-ului pe care trebuia să-l înlocuiască.

Întrebări frecvente

Cât durează până se vede un rezultat măsurabil?

Pentru un domeniu restrâns și un corpus deja digitalizat, primele semnale apar în patru-șase săptămâni de la lansarea pilotului. Termenul realist pentru o cifră pe care o poți duce într-o discuție de buget e un trimestru, pentru că ai nevoie de baseline, de o perioadă de acomodare și de suficient volum ca datele să nu fie zgomot.

Pot folosi același sistem pentru IT și pentru HR?

Da, dar cu corpusuri și permisiuni separate, sub aceeași interfață. Angajatul nu trebuie să știe unde se duce întrebarea lui — asta e treaba routerului. Ce trebuie separat strict e stratul de acces: un chunk din HR nu are ce căuta într-un răspuns despre VPN, iar filtrele se aplică independent pe fiecare sursă.

Ce fac cu documentele care există doar în engleză, deși oamenii întreabă în română?

E cazul obișnuit în companiile cu documentație tehnică moștenită. Modelele de embedding multilingve descurcă rezonabil situația, dar nu magic: acoperă traducerea conceptelor, nu și acronimele interne. Adaugă în dicționarul de sinonime perechile română-engleză pentru termenii cu volum mare și testează explicit acest scenariu în setul de evaluare, nu doar întrebări monolingve.

Cum împiedic sistemul să inventeze proceduri care nu există?

Prin grounding strict și prin refuz explicit: răspunsul se construiește doar din chunk-urile returnate, cu citări verificabile, iar când retrievalul nu întoarce nimic relevant, sistemul spune că nu știe și oferă calea către un om. Mecanica e detaliată în cum reduce RAG halucinațiile.

Ce se întâmplă cu întrebările despre alți angajați?

Se tratează ca o categorie separată în router, nu ca un caz limită de retrieval. „Cine e responsabil de aprobarea cheltuielilor pe marketing” e o întrebare legitimă de organigramă. „Ce evaluare a primit colegul meu” nu e o întrebare la care sistemul trebuie să încerce să răspundă, indiferent ce documente ar găsi.

E nevoie de un proiect separat dacă avem deja un asistent pentru clienți?

Componentele se reutilizează — pipeline de ingestie, vector store, stratul de generare. Ce nu se reutilizează sunt corpusul, modelul de permisiuni, routerul de intenție și metrica de succes. În practică, e mai aproape de un al doilea produs pe aceeași infrastructură decât de o extindere a celui existent. Un al treilea profil, cel al documentelor contractuale, are propriile constrângeri — descrise în RAG pe contracte și documente juridice.

Un helpdesk intern care funcționează nu e un proiect de model, e un proiect de corpus, de permisiuni și de adopție — în ordinea asta. Modelul e partea rezolvată.

Restul cazurilor enterprise documentate stau în cazuri de utilizare enterprise, iar imaginea completă a ce înseamnă un sistem RAG livrat end-to-end e în hub-ul de soluții AI și RAG. Dacă pornești mâine, începe cu baseline-ul: e singura parte care nu se mai poate măsura retroactiv.