Asistent AI intern peste documentele companiei (RAG): cum reduci timpul pierdut cu căutarea informației

Problema: informația există, dar nimeni nu o găsește la timp

Într-o companie de 80 de oameni, cunoașterea nu lipsește. Există proceduri, contracte, oferte vechi, manuale de produs, decizii pe email, fișiere pe SharePoint și un Confluence pe care nimeni nu l-a mai actualizat din 2023. Problema nu e că informația nu există. Problema e că nimeni nu o găsește în cele 3 minute în care i-ar fi utilă.

Cifrele pe care le vedem la clienți sunt remarcabil de constante:

• 20-30% din timpul unui angajat de birou se duce pe căutat, verificat sau reconstruit informație care există deja undeva
• 4-6 ore/săptămână per om de suport sau operațiuni petrecute răspunzând la aceleași întrebări interne
• Un răspuns "știe cineva unde e procedura pentru retur pe UE?" pe Slack costă, în medie, între 15 și 40 de minute din timpul a 2-3 oameni

La o companie cu 50 de angajați de birou și un cost mediu încărcat de 18 EUR/oră, 20% timp pierdut pe căutare înseamnă aproximativ 300.000 EUR/an de productivitate evaporată. Nu într-o pierdere spectaculoasă, ci în mii de întreruperi mici.

În 2026, cel mai concret mod de a recupera o parte din acești bani nu este "încă un wiki". Este un asistent AI care caută în documentele voastre și răspunde cu surse.

Ce este de fapt un asistent RAG (fără hype)

RAG înseamnă *Retrieval-Augmented Generation*. În limba oamenilor: un model AI care, înainte să răspundă, caută în documentele tale și formulează răspunsul bazându-se pe ce a găsit, cu citări.

Diferența față de un ChatGPT generic e fundamentală:

• Un LLM generic răspunde din ce a "învățat" la antrenare — nu știe nimic despre contractul tău cu furnizorul X
• Un asistent RAG caută întâi în baza ta de documente, apoi răspunde doar pe baza a ce a găsit acolo, cu link către sursă

Fluxul, tehnic, în 4 pași:

1. Ingestie — documentele (PDF, Word, pagini de wiki, tichete, email-uri) sunt sparte în bucăți ("chunks") și transformate în vectori numerici

2. Indexare — vectorii se stochează într-o bază de date vectorială (pgvector, Qdrant, Weaviate)

3. Retrieval — la o întrebare, sistemul găsește cele mai relevante 5-10 bucăți

4. Generare — LLM-ul primește întrebarea + bucățile relevante și scrie răspunsul, cu citări

Partea contraintuitivă: valoarea nu stă în model, stă în retrieval. Un GPT excelent cu retrieval prost dă răspunsuri sigure pe sine și greșite. Un model mediu cu retrieval bun și surse curate e de nădejde.

De ce nu e suficient un wiki (și de ce nu e suficient nici ChatGPT)

Wiki-ul clasic are două probleme: cineva trebuie să-l scrie și cineva trebuie să știe *ce termen* să caute. Asistentul RAG rezolvă a doua parte — înțelege întrebarea în limbaj natural, chiar dacă formularea nu conține cuvintele exacte din document.

ChatGPT sau Copilot "de raft" rezolvă limbajul natural, dar nu văd documentele tale interne — sau, dacă le vezi printr-un conector generic, nu ai control pe ce indexează, unde ajung datele și cine are voie să vadă ce. Pentru o companie din UE, guvernanța datelor nu e opțională: un contract cu clauze de confidențialitate nu are ce căuta trecut printr-un serviciu fără acord de procesare a datelor.

Studiu de caz: firmă de servicii cu 120 de angajați

Un client cu care am lucrat la NEXVA SYSTEM — o firmă de servicii B2B cu 120 de oameni — avea situația clasică:

• ~14.000 de documente în SharePoint, Google Drive și un Confluence parțial abandonat
• Echipa de suport primea zilnic 30-40 de întrebări interne repetitive ("care e SLA-ul pentru clientul X?", "unde e template-ul de contract pe servicii recurente?")
• Onboarding-ul unui angajat nou dura 6-8 săptămâni până devenea autonom pe proceduri

Ce am construit:

• Pipeline de ingestie care sincronizează zilnic documentele din cele 3 surse, cu respectarea permisiunilor existente (un om nu poate "întreba" ce nu are voie să vadă)
• Bază vectorială pe PostgreSQL + pgvector (fără infrastructură nouă exotică)
• Retrieval hibrid: căutare semantică + căutare pe cuvinte-cheie, ca să prindă și numele de coduri, și sensul
• Asistent accesibil direct din Slack și dintr-un panou web intern, cu citări obligatorii spre sursă
• Un "prag de refuz": dacă sistemul nu găsește surse suficient de relevante, spune "nu am găsit asta în documente", în loc să inventeze

Rezultate după 4 luni:

• Întrebări interne repetitive către echipa de suport: -62%
• Timp mediu de găsire a unei proceduri: de la 8-12 min → sub 40 de secunde
• Onboarding până la autonomie: de la 6-8 săptămâni → ~4 săptămâni
• ROI investiție: 7 luni

Detaliul care contează: adoptarea reală a venit abia după ce am adăugat citările clicabile. Oamenii nu au încredere într-un răspuns AI fără să vadă documentul-sursă. Fără citări, folosirea era 15%. Cu citări, a urcat la peste 70% în două luni.

Datele de care ai nevoie și cum le pregătești

Vestea bună: nu ai nevoie de un data lake. Ai nevoie de:

• Acces la sursele unde stă deja informația (SharePoint, Drive, Confluence, un folder de PDF-uri)
• Un model clar de permisiuni — cine are voie să vadă ce
• Un pic de igienă: să elimini din index versiunile vechi și duplicatele evidente

Cea mai frecventă greșeală e să indexezi "tot", inclusiv 5 versiuni ale aceluiași contract. Asistentul va cita, inevitabil, versiunea greșită. Curățenia surselor bate orice reglaj de model.

Unde dă greș un asistent RAG

Fii onest când evaluezi tehnologia:

Documente contradictorii

Dacă ai două proceduri care spun lucruri diferite, AI-ul le va cita pe amândouă și va deruta omul. Soluția nu e tehnică, e organizațională: o singură sursă de adevăr per subiect.

Întrebări care cer calcul, nu regăsire

"Care e marja pe comanda 4471?" nu e o întrebare de RAG, e o interogare în ERP. RAG-ul e pentru cunoaștere textuală, nu pentru cifre live din baze de date tranzacționale.

Tabele și PDF-uri scanate prost

Un PDF scanat strâmb sau un tabel complex se extrag prost. Aici e nevoie de OCR bun în etapa de ingestie, altfel retrieval-ul e pe date corupte.

Așteptarea de "0 greșeli"

Un asistent RAG bun ajunge la 85-92% răspunsuri corecte și utile pe întrebări acoperite de documente. Restul trebuie să eșueze *elegant* ("nu am găsit"), nu să inventeze. Un sistem care nu știe să spună "nu știu" e mai periculos decât util.

Costul real al implementării

Pentru o companie cu 50-200 de angajați și 5.000-30.000 de documente:

| Componentă | Cost |

|-----------|------|

| Audit surse + model de permisiuni | 3.000-6.000 EUR |

| Pipeline ingestie + bază vectorială | 6.000-11.000 EUR |

| Retrieval hibrid + reglaj + prag de refuz | 5.000-9.000 EUR |

| Integrare Slack/Teams + panou web + citări | 4.000-7.000 EUR |

| Total inițial | 18.000-33.000 EUR |

| Infrastructură + apeluri LLM lunar | 200-600 EUR |

| Re-indexare și mentenanță | 400-800 EUR/lună |

Costul apelurilor către LLM sperie mulți decidenți degeaba: pentru un volum de 2.000-4.000 de întrebări/lună, factura de inferență e sub 300 EUR. Retrieval-ul filtrează contextul, deci nu trimiți documente întregi la fiecare întrebare.

Cum începi practic

1. Alege un singur departament — de obicei suport sau operațiuni, unde întrebările repetitive sunt cele mai dese

2. Măsoară acum — câte întrebări interne circulă pe Slack/email pe zi și cât timp fură

3. Indexează o sursă, nu toate — începe cu folderul de proceduri, nu cu tot Drive-ul

4. Pilot de 6 săptămâni — 10-15 utilizatori, cu citări obligatorii și feedback pe fiecare răspuns

5. Extinde după validare — adaugă surse și departamente doar după ce primul grup îl folosește zilnic

Cea mai mare greșeală e "hai să indexăm toată compania deodată". Începe îngust, câștigă încrederea cu citări, apoi extinde.

Concluzie

Un asistent AI intern nu e un proiect de cercetare și nici un gadget. Pentru orice companie cu peste 40 de angajați de birou și cunoaștere împrăștiată pe mai multe sisteme, e azi una dintre cele mai concrete moduri de a recupera timp — cu ROI vizibil sub un an.

Cheia nu e modelul, e disciplina din jurul lui: surse curate, permisiuni respectate, citări obligatorii și un sistem care știe să spună "nu știu". Restul e inginerie previzibilă.

Vrei să estimăm împreună cât timp pierde echipa ta pe căutarea informației și ce parte se poate automatiza? Programează o consultanță gratuită.