RAG enterprise în România: ghid de arhitectură pentru date corporative

Un sistem RAG (retrieval-augmented generation) e ușor de demonstrat și greu de construit bine în producție. Articolul ăsta tratează partea grea: cum proiectezi un sistem RAG peste date corporative reale, cu permisiuni respectate, surse multiple, evaluare continuă, și latențe sub o secundă pentru cazul mediu.

Conținutul combină pattern-uri stabilite în comunitatea Anthropic cu ce construim la Ran·AI: sisteme multi-agent cu memorii distribuite integrate cu diverse MCP-uri, memorie Obsidian la nivel de companie, MCP servers care dau Claude control complet de aplicații, și soluții custom de analiză automată a transcrierilor. Pattern-urile RAG enterprise de mai jos sunt cele pe care le folosim ca punct de plecare în proiectele de tip asistent intern peste date corporative.

Ce e RAG și când are sens

RAG e un pattern simplu. Când utilizatorul pune o întrebare, sistemul caută în datele tale relevante (retrieval), apoi trimite întrebarea împreună cu pasajele găsite la un model Claude, care formulează răspunsul (generation). Fără retrieval, modelul răspunde din memorie generală sau spune că nu știe. Cu retrieval, răspunde din datele tale și citează sursele.

RAG e potrivit când: datele tale se schimbă des, vrei citări verificabile, sunt prea multe documente pentru a încăpea într-un singur context, sau datele sunt confidențiale și nu vrei să le pui în fine-tuning. Pentru aproape orice asistent intern care răspunde din baza voastră de cunoștințe, RAG e răspunsul potrivit în 2026.

RAG nu e potrivit când: vrei să schimbi stilul de scriere al modelului (asta cere fine-tuning), datele sunt foarte mici și încap în context (atunci doar le pui în prompt), sau ai nevoie de raționament peste tot corpus simultan (cazul rar al sumarizării globale).

Sursele reale ale datelor enterprise

Într-o organizație de câteva sute până la câteva mii de oameni, datele de care un asistent are nevoie sunt răspândite în:

• SharePoint sau Confluence pentru documentație, politici interne, wiki tehnic. Acces via Microsoft Graph sau Confluence REST API.
• SAP pentru date tranzacționale și master data (clienți, materiale, ordine). Acces via OData sau RFC.
• File shares pe rețea (SMB sau NFS) cu PDF-uri, Word, Excel acumulate de ani. Cel mai dezordonat colț.
• Outlook sau Teams pentru istoric de email și conversații. Microsoft Graph din nou.
• Sisteme proprietare: ticketing intern, ERP secundar, intranet vechi. Câteva sute de linii de adapter per sursă.
• Baze de date relaționale când vrei să răspunzi întrebări structurate ("câte ordine deschise sunt în clusterul București?").

Greșeala frecventă în implementări: se presupune că există o singură sursă. În realitate, răspunsul corect la o întrebare ca "ce politică e pentru concediul medical?" trece prin SharePoint (politica oficială), Outlook (clarificări de la HR), și sistemul intern de ticketing (cazuri rezolvate). Toate trebuie indexate, toate trebuie să respecte permisiunile cui întreabă.

Indexarea: chunking, embeddings, hybrid

Pasul de indexare decide dacă sistemul tău găsește răspunsul corect. Trei decizii contează aici.

Chunking. Documentele lungi se sparg în bucăți (chunks) de aproximativ 400 până la 800 tokens. Bucăți mai mici pierd context. Mai mari diluează relevanța. Pentru documente structurate (markdown, HTML), chunkuiește pe headers. Pentru PDF-uri scanate care au ieșit din OCR, chunkuiește pe paragrafe sau paragrafe cu overlap.

Pentru fiecare chunk, păstrează metadate: sursă, titlu document, URL canonic, autor, dată, permisiuni (cine are voie să-l citească). Aceste metadate sunt critice pentru filtrarea de mai târziu.

Embeddings. Folosește un model de embeddings multilingual (Voyage AI, OpenAI text-embedding-3-large, sau Cohere). Pentru română, Voyage și Cohere au performanță bună conform benchmark-urilor publice. Embedding-urile sunt vectori care reprezintă sensul chunkului.

Hybrid retrieval. Aici e diferența cea mai mare între demo și producție. Sistemele RAG bune combină două căutări:

• Căutare semantică (vector): găsește chunkuri al căror sens e similar cu întrebarea, chiar dacă nu folosesc aceleași cuvinte. Bună pentru parafrazări și sinonime.
• Căutare lexicală (BM25): găsește chunkuri care conțin cuvinte cheie din întrebare. Bună pentru termeni specifici (cod produs, abrevieri, nume de funcții).

Combinarea celor două (de exemplu prin Reciprocal Rank Fusion) crește acuratețea, conform publicațiilor Anthropic și ale furnizorilor de baze vectoriale. Costul de implementare e mic dacă folosești o bază de date care suportă ambele (Elasticsearch, Qdrant cu Tantivy, Vespa, Weaviate).

Reranking: ultimul filtru înainte de Claude

După hybrid retrieval ai 20 până la 50 de chunkuri candidate. Trimite-le pe toate la Claude și răspunsul devine confuz din prea mult context. Rerankerul aranjează aceste candidate după relevanță folosind un model specializat.

Cohere Rerank și Voyage Rerank sunt opțiunile mature în 2026. Trimit întrebarea plus candidatele, primesc înapoi un scor de relevanță pentru fiecare. Păstrezi top 5 până la 10. Costul e mic comparat cu apelul către Claude, iar îmbunătățirea răspunsului final e vizibilă pe golden set.

ACL: respectarea permisiunilor enterprise

Asta e zona unde demo-urile RAG se prăbușesc față de realitatea enterprise. În organizația ta, oamenii din vânzări nu au voie să vadă salariile colegilor din contabilitate. Sistemul tău RAG nu poate să le furnizeze acel conținut chiar dacă tehnologic ar putea.

Modelul corect e ACL-aware retrieval:

1. La indexare, fiecare chunk primește un set de identificatori (user IDs sau group IDs) care au voie să-l vadă.
2. La query, sistemul știe cine pune întrebarea (autentificare prin Azure AD sau echivalent).
3. Căutarea filtrează rezultatele după permisiuni înainte de reranking, nu după.
4. Rezultatele invizibile nu apar în răspuns și nu sunt nici măcar menționate ca existând.

Pentru SharePoint și Confluence, exportă permisiunile per item. Pentru SAP, replică rolurile relevante. Pentru file shares, ACL-urile NTFS sau POSIX. E muncă plictisitoare dar non-negociabilă.

Capcana fatală: implementări care încep cu un cont admin care vede tot pentru demo, apoi descoperă că trebuie să adauge ACL la final. Refactorul costă luni. Pune ACL în indexare de la primul chunk.

Citation hydration

Răspunsurile fără citări sunt inutile în enterprise. Utilizatorul trebuie să poată verifica de unde vine fiecare afirmație. Citation hydration e procesul prin care, după ce Claude generează răspunsul cu referiri la chunkurile pe care le-a primit, sistemul transformă acele referiri în linkuri către documentele originale.

Workflow-ul standard: în prompt, fiecare chunk e numerotat ([1], [2],[3]). Claude e instruit să citeze sursele între paranteze pătrate. La afișare, paranteza devine link către documentul din care vine chunkul, deschis la secțiunea corectă. Pentru SharePoint, asta înseamnă URL canonic plus anchor. Pentru PDF, link cu#page=N.

Citările schimbă mult adopția. Utilizatorii încep să folosească sistemul ca pe un index inteligent peste documentația lor, nu ca pe un oracol. Asta e o relație mult mai sănătoasă cu AI-ul.

Promptul de generare

Promptul sistem pentru un RAG bun are 4 blocuri:

1. Persona și ton. "Ești asistent pentru angajații Companiei X. Răspunzi concis, în română, cu citări obligatorii."
2. Reguli pentru citări. "Citează orice afirmație din pasajele furnizate cu [N]. Nu inventa surse. Dacă pasajele nu conțin răspunsul, spune că nu ai informația și sugerează unde poate fi găsită."
3. Reguli pentru lipsa de informație. "Dacă întrebarea iese din scopul tău (politici de companie, proceduri interne), spune politicos că nu te ocupi de asta."
4. Format de output. Markdown cu titluri scurte, paragrafe scurte, numerotate când e cazul.

Pasajele găsite la retrieval se atașează ca mesaje user separate, nu în promptul sistem. Asta permite prompt caching pe promptul sistem (care nu se schimbă) și reduce costul pentru sesiuni lungi.

Evaluare: golden set, regresii, drift

Fără evaluare nu poți îmbunătăți sistemul, nu poți schimba modelul, și nu poți răspunde la întrebarea "merge mai bine după update?". Două lucruri trebuie configurate de la început.

Golden set. Câteva zeci până la câteva sute de întrebări reale cu răspunsuri așteptate (sau cel puțin chunkuri așteptate). Întrebările vin din log-urile reale ale utilizatorilor. Fără asta, evaluezi pe sentimentul tău.

Metrici automate.

• Recall@k pe retrieval: din top-k chunkuri returnate, câte conțin răspunsul corect?
• Faithfulness pe generation: răspunsul citează doar lucruri care sunt în chunkurile furnizate? Evaluată cu un model judge (alt Claude sau echivalent).
• Answer relevance: răspunsul răspunde la întrebare? Tot cu model judge.

Rulează evaluarea după fiecare schimbare (chunking nou, prompt nou, model nou). Pe CI dacă merită. Drift-ul (calitatea care scade lent fără să schimbi nimic) e real și apare când sursele cresc și retrieval-ul pierde precizie.

Ordine de mărime pentru cost

Pentru un sistem RAG enterprise tipic, plaja realistă a costurilor operaționale e împărțită pe câteva linii:

• Embeddings: indexare inițială și update-uri delta. Cost mic comparat cu alte linii.
• Bază vectorială managed (Qdrant Cloud, Weaviate Cloud, sau echivalent): de obicei câteva sute de EUR pe lună pentru volume enterprise medii.
• Reranker: proporțional cu volumul de cereri, dar marginal.
• API Claude: linia principală. Cu Sonnet și caching activat, ordinea de mărime depinde direct de volumul zilnic și lungimea contextului.
• Observabilitate, hosting, monitoring: cost relativ mic în 2026.

Pentru un calcul exact, ia volumul tău estimat de cereri pe zi, multiplică-l cu lungimea medie de prompt și output, și consultă pagina actuală de prețuri Anthropic. Plus infrastructura din jurul lui.

Greșelile costisitoare

1. Indexarea unei singure surse la lansare. Echipe care indexează doar SharePoint și lansează descoperă că răspunsurile pentru o parte din întrebări sunt în emailuri vechi sau în Confluence. Indexează măcar trei surse de la început.

2. Chunkuri prea mari pentru PDF-uri. Un PDF de 100 pagini chunkuit în bucăți de 2.000 tokens înseamnă câteva chunkuri foarte diluate. Mergi la 600 tokens cu overlap de 100.

3. Lipsa rerankerului. Sare peste reranker și acuratețea răspunsurilor scade vizibil. Costul rerankerului e mic, valoarea e mare.

4. Ignorarea ACL. Cum am spus mai sus. Implementează ACL de la prima versiune. Refactorul pentru ACL post-launch costă luni.

5. Niciun mecanism de feedback. Butoane "util / inutil" sub fiecare răspuns plus un câmp de comentariu. După câteva săptămâni ai cazuri reale unde a greșit, le poți folosi pentru a îmbunătăți retrieval-ul și promptul.

6. Indexare statică. Documentele se schimbă zilnic. Construiește un job delta care reindexează doar documentele modificate. Webhook-uri din SharePoint, polling din Confluence, file system watcher pentru file shares.

Cum se conectează la sistemele multi-agent pe care le construim la Ran·AI

Pentru contextul ăsta merită o paranteză practică. Sistemele pe care le-am construit folosesc un pattern apropiat de RAG dar extins: în loc de un singur retrieval per cerere, fiecare agent are mai multe "memory lanes" (un memory lane e o sursă cu reguli proprii de retrieval și prioritizare), iar coordonatorul decide care lane e relevantă pentru un anumit pas. Memoria Obsidian la nivel de companie e o astfel de lane, alături de alte surse care intră prin MCP-uri.

Practic, dacă te apropii de un sistem RAG cu o singură sursă și o singură strategie de retrieval, vei descoperi în câteva luni că ai nevoie de mai multe. E mai ieftin să proiectezi de la început pentru multi-source și multi-strategy.

Cum arată o implementare bună

1. Alege câteva zeci de întrebări reale, construiește indexare pentru o singură sursă, evaluează cu modul naiv (doar vector). Vezi cât de departe e baseline-ul.
2. Adaugă BM25, hybrid retrieval, reranker. Măsoară îmbunătățirea pe golden set.
3. Implementează ACL, citation hydration, golden set extins. Lansează la un grup beta restrâns.
4. Adaugă a doua și a treia sursă. Reindexare delta. Mecanism de feedback. Extinde la mai mulți utilizatori.
5. Tuning pe baza feedback-ului real. Optimizări de cost. Lansare la tot personalul țintit.

Dacă ai date enterprise reale și vrei să discutăm un sistem concret, scrie-ne la contact@ranresults.com. Răspundem cu o opinie cinstită despre fezabilitate, un parcurs propus și o estimare de cost.