Bază de cunoștințe AI: cum pregătești documentele pentru RAG

Majoritatea proiectelor RAG care se împotmolesc nu se împotmolesc la model. Se împotmolesc la ce intră în model.

Ai ales modelul de embedding, ai ales baza vectorială, ai scris promptul. Apoi deschizi folderul cu documentația și găsești 400 de PDF-uri, jumătate scanate, un wiki pe care nimeni nu l-a atins din 2023 și un canal de chat unde stă, de fapt, răspunsul corect. Aceea e baza ta de cunoștințe. În starea asta, orice arhitectură de retrieval o să întoarcă gunoi cu încredere.

Articolul acoperă exact partea din față a sistemului: ce este o bază de cunoștințe pentru AI, cum inventariezi și triezi sursele, cum scoți text utilizabil din formate ostile, ce metadate atașezi, cum ții totul sincronizat și — cea mai grea decizie — ce alegi să nu indexezi.

Ce este o bază de cunoștințe pentru AI (și ce nu este)

Termenul e vechi și ușor înșelător. În customer support, „bază de cunoștințe” înseamnă o colecție de articole de help center. Pentru un sistem RAG înseamnă altceva: un corpus de text extras, normalizat, tăiat în bucăți, indexat vectorial și adnotat cu metadate, din care un retriever poate scoate în milisecunde pasajele relevante pentru o întrebare.

Diferența nu e cosmetică. Un help center e făcut ca să fie citit de un om care navighează, vede layoutul și înțelege că butonul „înapoi” duce la context. O bază de cunoștințe pentru AI e făcută ca să fie interogată de un sistem care nu navighează, nu vede layoutul și primește doar bucata de text pe care i-o dai.

Cele trei straturi

Orice bază de cunoștințe funcțională are trei straturi distincte, iar confuzia dintre ele produce jumătate din problemele de implementare:

1. Sursa — documentul original, în sistemul lui de origine: wiki, drive, repo, sistem de tichete, share de rețea.
2. Reprezentarea indexabilă — textul extras din sursă, curățat, tăiat în chunk-uri și transformat în vectori.
3. Metadatele — legătura dintre bucata indexată și realitate: din ce document vine, ce versiune, cine a scris-o, când, cine are voie s-o vadă, unde o găsești ca s-o verifici.

Al treilea strat e cel pe care echipele îl sar cel mai des, fiindcă nu e vizibil în demo. Și e singurul care face diferența între un răspuns pe care îl poți verifica și un răspuns pe care doar îl crezi — subiect tratat pe larg în grounding și citarea surselor.

Ce nu e o bază de cunoștințe

• Un folder shared. Nu are versionare controlată, nu are proprietar și nu are ștergere propagată.
• Un export unic. O bază de cunoștințe e un flux continuu, nu un snapshot făcut o dată, la lansare.
• „Tot ce avem”. Volumul nu e un obiectiv, e un cost — în bani, în latență și, mai ales, în calitatea răspunsurilor.

Dacă vrei recapitularea mecanicii complete — retrieval, augmentare, generare — pornește de la ce este RAG. Aici rămâi strict pe input. Restul clusterului stă în hubul Fundamentele RAG.

Inventarul și triajul surselor

Primul livrabil real al unui proiect RAG nu e cod. E o listă.

Harta surselor

Pentru fiecare sursă notează șase lucruri: unde stă, în ce format, cât de mare e, cât de des se schimbă, cine o deține și ce fel de întrebări ar putea răspunde. Categoriile care apar la aproape orice companie B2B:

• documentație de produs și tehnică — wiki, Markdown în repo, spații de colaborare;
• documente contractuale și de proces — PDF, DOCX, adesea scanate;
• conversații cu clienții — tichete, e-mail, transcrieri de apeluri;
• date operaționale — ERP, CRM, baze SQL;
• artefacte de inginerie — cod, README, decizii de arhitectură, runbooks;
• materiale de training — slide-uri, înregistrări, transcrieri.

Exercițiul durează două-trei zile și schimbă bugetul proiectului mai mult decât orice alegere de tooling.

Cine deține documentul

Un document fără proprietar e un document pe care nimeni nu-l corectează. Când sistemul dă un răspuns greșit pentru că sursa era greșită, întrebarea imediată e „cine repară documentul?”. Dacă răspunsul e „nu știu”, ai descoperit o problemă de organizație, nu una de retrieval.

Regula practică: dacă nu poți numi o persoană care răspunde de corectitudinea unui document, nu-l indexa încă. Îl pui în backlog, împreună cu numele echipei care ar trebui să-l adopte.

Triajul: valoare contra cost de curățare

Nu toate sursele merită efortul, și puține merită efortul acum. Triajul se face pe două axe: cât de mult valorează conținutul pentru întrebările reale ale utilizatorilor și cât costă să-l aduci într-o stare indexabilă.

Cadranele se citesc așa:

• Valoare mare, cost mic — primul val. Markdown din repo, wiki întreținut, FAQ-uri existente. De aici pornește pilotul.
• Valoare mare, cost mare — merită, dar planificat, cu buget separat și termen realist. Manuale tehnice cu tabele, contracte scanate, arhive vechi.
• Valoare mică, cost mic — tentant, fiindcă e ieftin. Rezistă tentației: conținutul irelevant nu e neutru, adaugă concurență în spațiul vectorial.
• Valoare mică, cost mare — nu.

Valoarea nu se estimează din burtă. Strânge 50–100 de întrebări pe care oamenii le pun deja — din tichete, din chat-ul intern, din e-mailurile către echipa de suport — și marchează, pentru fiecare sursă, câte dintre ele ar putea primi răspuns din ea. Lista aceea devine și setul de evaluare de mai târziu.

Extragerea din formate reale

Aici se pierde cel mai mult timp de implementare și tot aici se produce cel mai mult rău invizibil.

PDF-ul e formatul-problemă, și motivul e structural. Echipa Docling de la IBM Research o spune direct în raportul tehnic: conversia documentelor înapoi într-un format procesabil de mașină e o provocare veche de decenii, fiindcă formatele optimizate pentru tipar aruncă majoritatea trăsăturilor structurale și a metadatelor. Un PDF nu conține „un tabel”; conține instrucțiuni de desenat linii și de poziționat caractere.

PDF nativ contra PDF scanat

Sunt două căi complet diferite, iar tratarea lor la fel e greșeala clasică:

• Extragere directă de text — citește textul din structura internă a fișierului. Rapidă și exactă pentru documente create digital.
• OCR — randează pagina ca imagine și citește caracterele din pixeli. Mai lentă, dar obligatorie pentru scanări și pagini-imagine.

Detecția se face per pagină, nu per fișier. Documentele hibride sunt regula, nu excepția: un contract digital cu ultima pagină scanată pentru semnătură, un manual cu anexe fotografiate.

Semnalele de alarmă la extragere: pagini care ies „cu succes”, dar goale; coloane amestecate în ordinea de citire; caractere corupte pe scanări. Un parser care nu-ți spune cât de sigur e pe fiecare pagină îți trece gunoiul mai departe în tăcere, iar sistemul îl va cita ulterior ca sursă legitimă.

Tabelele sunt cazul greu

Recuperarea structurii unui tabel e o problemă de computer vision separată de recunoașterea textului. Docling, de exemplu, folosește modele dedicate pentru cele două sarcini: analiză de layout și recunoaștere de structură tabelară, tocmai pentru că un OCR bun pe text nu înseamnă un OCR bun pe tabele.

Regula practică: păstrează tabelul ca tabel — Markdown sau JSON — nu ca text liniarizat. Un tabel liniarizat pierde legătura dintre antet și celulă, iar modelul va citi „1.240” fără să știe că e coloana „preț fără TVA” și rândul „licență anuală”. Un tabel păstrat structurat rămâne inteligibil chiar și scos din context.

Wiki, spații de colaborare și tichete

Aici formatul nu e problema — structura e.

Exportă prin API, nu prin „Print to PDF”: pierzi ierarhia de pagini, atributele și istoricul de versiuni exact în momentul în care ai cea mai mare nevoie de ele. Păstrează ierarhia de headinguri: e cea mai ieftină sursă de context pe care o ai.

Pentru tichete, unitatea utilă e firul, nu mesajul. Un mesaj izolat („da, exact asta era”) nu înseamnă nimic fără întrebarea de deasupra și fără rezoluția de dedesubt. Indexează firul rezolvat, cu problema și soluția împreună, și marchează explicit statusul — un tichet închis ca „duplicat” nu e o sursă de adevăr.

Cum alegi parserul

Trei constrângeri decid alegerea, în ordinea asta: sensibilitatea datelor (self-hosted sau air-gapped contra serviciu managed), diversitatea formatelor din corpus și bugetul per pagină.

Nu presupune că un parser bun pe un tip de document e bun pe altul. OmniDocBench, benchmarkul de referință pentru parsarea documentelor, e construit tocmai în jurul acestei probleme: acoperă nouă tipuri de surse — de la articole academice până la note scrise de mână și ziare dens tipărite — cu 19 categorii de layout, și evaluează atât pipeline-urile modulare, cât și modelele vision-language end-to-end, arătându-le limitele pe diversitatea reală de documente.

Tradus operațional: testează pe corpusul tău, pe un eșantion din fiecare tip de document, nu pe demo-ul vendorului.

Poarta de calitate

Înainte să treacă mai departe, fiecare document primește un verdict: extras curat, extras cu rezerve, eșuat. Verdictul se stochează, nu se aruncă.

Verificări ieftine care prind aproape tot: raportul dintre caractere alfabetice și total, densitatea de text pe pagină, prezența unor secțiuni așteptate, lungimea neverosimil de mică față de numărul de pagini. Un procent de eșec pe care nu-l măsori acum devine, peste trei luni, un răspuns greșit pe care nu-l poți explica.

Metadatele fără de care retrieval-ul e orb

Un chunk fără metadate e o propoziție ruptă din context, aruncată într-o grămadă cu alte câteva sute de mii. Retrieverul o poate găsi, dar nu poate face nimic inteligent cu ea.

Schema minimă

Opt câmpuri. Sub ele, sistemul funcționează în demo și cedează în producție.

Schema de acces se proiectează aici, la ingestie, dar aplicarea ei la momentul interogării, redactarea datelor personale și dreptul la ștergere sunt un subiect separat, tratat în RAG și GDPR. Dacă nu ai access_scope pe o sursă, ea nu intră în index — nu „intră și filtrăm mai târziu”.

Metadate derivate

Peste cele stocate din sursă, merită extrase automat: titlul secțiunii din care vine chunk-ul, ierarhia de headinguri deasupra lui, tipul de document, limba și data menționată în conținut, nu doar data fișierului. Un document salvat ieri poate descrie o procedură din 2021.

Ghidul de calitate a retrieval-ului publicat de Databricks pune extragerea de entități, teme și categorii pentru filtrare precisă peste optimizarea obsesivă a dimensiunii chunk-ului, ca impact real asupra rezultatelor. E o ierarhie de priorități utilă: mulți ajustează la nesfârșit parametrii de tăiere, când câștigul mai mare stă într-un câmp de filtrare în plus.

Contextul intră în chunk, nu doar în filtru

Filtrele funcționează doar când întrebarea conține criteriul. „Care e procedura de retur?” nu spune nimic despre departament, versiune sau an — deci filtrul nu are ce filtra, iar potrivirea rămâne pur semantică.

De aici tehnica de a scrie contextul direct în textul indexat. Anthropic a documentat abordarea sub numele de contextual retrieval: fiecare chunk primește, înainte de indexare, un scurt prefix generat din documentul întreg, care îl situează („această secțiune vine din raportul X, capitolul Y”). În evaluarea publicată, doar contextual embeddings au redus rata de eșec la recuperarea top-20 cu 35%, de la 5,7% la 3,7%; combinate cu o variantă contextualizată de BM25 reducerea a ajuns la 49%, iar cu un pas de reranking la 67%.

Costul e real — un apel suplimentar de model pentru fiecare chunk, la ingestie — dar se plătește o singură dată per versiune de document, nu la fiecare interogare.

Unde tai efectiv documentul rămâne o decizie separată, cu parametrii ei: dimensiune, overlap, limite semantice. Sunt tratați în strategii de chunking pentru RAG. Cât de mult te ajută filtrele depinde și de motorul ales — pre-filtrarea, post-filtrarea și filtrarea în aceeași fază diferă între baze vectoriale, comparate în pgvector, Pinecone, Qdrant sau Weaviate.

Textul curat plus metadatele bune sunt materia primă din care se fac vectorii; ce se întâmplă cu ei mai departe e explicat în cum funcționează embeddings, iar de ce un filtru bun completează potrivirea semantică în loc s-o înlocuiască, în ce este semantic search.

Prospețimea: cum ții baza sincronizată

Similaritatea nu are dimensiune temporală

Un vector nu știe că e vechi. O procedură revocată acum șase luni are exact aceeași distanță față de întrebare ca varianta curentă care a înlocuit-o. Dacă amândouă sunt în index, retrieverul le scoate pe amândouă, iar modelul trebuie să aleagă între ele fără niciun semnal care să-l ajute.

Politica de precedență între surse contradictorii e o discuție separată, în grounding și citare. Partea care ține de ingestie e mai simplă și mai dură: versiunea veche nu ar trebui să fie acolo.

Indexare incrementală, nu reconstrucție periodică

Reconstruirea completă a indexului pare simplă și devine imposibilă odată ce ai câteva sute de mii de chunk-uri. Alternativa are trei invariante:

• Id-uri stabile — fiecare chunk are un id determinist derivat din documentul-sursă și poziția în el, ca actualizarea să înlocuiască exact elementul potrivit.
• Versionare — fiecare chunk poartă versiunea documentului, ca variantele vechi să poată fi purjate și ca să poți audita ce a văzut modelul la un moment dat.
• Tombstones — ștergerea la sursă produce un eveniment explicit de eliminare. E cazul cel mai periculos: conținutul retras care rămâne recuperabil apare în răspuns ca dovadă perfect legitimă.

Ce nu se embedează deloc

Datele operaționale curente nu au ce căuta într-un index vectorial: stocuri, statusuri de comandă, solduri, disponibilități. Un rând care se schimbă la fiecare câteva minute produce, prin embedding, o copie înghețată care începe să mintă imediat.

Recomandarea de arhitectură e explicită în ghidurile de RAG în timp real: interoghează live datele structurate, cu SQL sau printr-un tool dedicat, și lasă retrieval-ul semantic pentru documentele care chiar beneficiază de el. RAG nu e ruta potrivită pentru întrebări la care o bază de date răspunde determinist.

Ritmuri de refresh pe clase de documente

Nu tot conținutul se degradează la fel de repede. O clasificare simplă, cu un proprietar pe fiecare clasă:

Fără un nume în dreptul fiecărei clase, alerta de prospețime devine o notificare pe care n-o citește nimeni.

Secțiunea asta e rezumatul. Mecanica desfășurată — de ce un index expirat nu dă niciun semnal, cum detectezi schimbările și ștergerile de la sursă, ce înseamnă ștergerea reală dintr-un index vectorial și cât costă fiecare cadență — stă în articolul despre prospețime, ștergeri și reindexare.

Ce nu indexezi

Cea mai grea decizie din tot procesul, fiindcă instinctul e „bagă tot, retrieverul o să aleagă”. Nu alege.

Documentele „aproape corecte” sunt cele periculoase

Studiul lui Cuconasu și colegii, prezentat la SIGIR 2024, a analizat sistematic ce se întâmplă cu un sistem RAG în funcție de documentele care ajung în prompt. Concluzia solidă: documentele legate tematic de întrebare, dar care nu conțin răspunsul, degradează acuratețea mai mult decât documentele complet nelegate.

Aceeași lucrare raportează și un rezultat contraintuitiv — că documentele complet aleatorii ar putea chiar ajuta — dar o replicare publicată în 2026 arată că efectul dispare pentru mai multe modele instruction-tuned moderne și se atenuează substanțial la altele, deci nu e o proprietate generală pe care să construiești. Partea care rezistă și e acționabilă rămâne prima: aproape-relevantul costă mai mult decât irelevantul.

Asta schimbă complet triajul. O ciornă veche a aceleiași proceduri nu e „conținut în plus”. E un concurent aproape identic în spațiul vectorial, care va apărea lângă varianta corectă la fiecare interogare pe subiect.

Ce excluzi, concret

Modurile în care retrieval-ul cade în producție când corpusul e prost construit sunt inventariate separat, în de ce eșuează un sistem RAG în producție. Multe dintre ele au cauza aici, în decizia de ce a intrat în index.

Datoria de documentație: blocantul care oprește proiecte

Cel mai frecvent blocant real al unui proiect RAG nu e tehnic. E faptul că documentația care ar trebui indexată nu există, sau există doar în capul a trei oameni.

Semnele

• Răspunsul corect trăiește într-un fir de chat, nu într-un document.
• Documentația descrie sistemul de acum doi ani și nimeni nu-și asumă actualizarea.
• Fiecare echipă are „varianta ei” a aceleiași proceduri.
• Nimeni nu poate spune care e sursa oficială pentru o întrebare dată.

Niciunul dintre semnele astea nu se rezolvă cu un parser mai bun.

Ce faci concret

Nu rescrii toată documentația — ai eșua, și pe drept. Pornești invers, de la întrebări:

1. Strânge întrebările reale, din tichete și din conversațiile interne.
2. Grupează-le pe teme și ordonează-le după frecvență.
3. Pentru fiecare, verifică dacă există un document care chiar răspunde.
4. Golurile devin backlog de scris, prioritizat după frecvență, nu după cât de ușor e de scris.

Rezultatul e un corpus-sămânță, mic și corect, care acoperă cererea reală. E infinit mai util decât o arhivă completă și nedigerabilă.

Bugetul de curățare

Tratează curățarea ca linie separată de proiect, cu ore estimate și proprietar, nu ca pe ceva ce „se face pe parcurs”. Când e invizibilă în plan, se transformă în întârzierea pe care nimeni n-o poate justifica la jumătatea implementării.

Un corpus mic și curat bate un corpus mare și murdar la aproape orice metrică pe care ai să vrei s-o urmărești mai târziu.

Un proces repetabil, în șase pași

1. Inventariază — sursă, format, volum, ritm de schimbare, proprietar.
2. Triază — valoare, derivată din întrebări reale, contra cost de curățare.
3. Extrage — parser potrivit per tip de document, cu poartă de calitate per pagină.
4. Normalizează și adnotează — schema minimă de metadate, plus context scris în chunk.
5. Indexează incremental — id-uri stabile, versiuni, tombstones la ștergere.
6. Măsoară și taie — urmărește ce se recuperează efectiv și scoate din index ce nu ajunge niciodată în răspuns sau ajunge greșit.

Pasul șase e cel omis aproape peste tot. Un index care doar crește e un index care se degradează lent, apoi brusc.

Întrebări frecvente

Cum știu dacă documentația mea e pregătită pentru RAG?

Testul e simplu: ia 20 de întrebări reale și caută manual răspunsul în documentele existente. Dacă îl găsești pentru 15 din 20 într-un document identificabil, ai un corpus de pornire. Dacă îl găsești în cinci, problema e de documentație, nu de retrieval, și niciun tooling n-o rezolvă.

Cât de mare trebuie să fie o bază de cunoștințe ca să merite?

Nu există un prag de volum. Un corpus de 200 de documente bine întreținute, care acoperă întrebările frecvente, produce un sistem util. Zeci de mii de documente necurate produc un sistem în care nimeni n-are încredere după a treia utilizare. Criteriul e acoperirea cererii reale, nu numărul de fișiere.

Ce fac cu PDF-urile scanate vechi?

Le tratezi ca pe cadranul „valoare mare, cost mare”: numai dacă răspund la întrebări frecvente. Rulează OCR pe un eșantion de 20–30 de pagini reprezentative, măsoară rata de eroare și abia apoi decide dacă merită întregul lot. Pentru documentele cu tabele critice, verificarea manuală a extragerii rămâne, deocamdată, parte din proces.

Trebuie să indexez tot spațiul de colaborare intern?

Aproape sigur nu. Spațiile de wiki adună ciorne, pagini de proiect încheiate și duplicate — exact categoria de conținut aproape-relevant care face rău. Indexează spațiile cu proprietar activ și pagini revizuite; pe restul lasă-le pe loc, ca sursă de căutare clasică.

Cine ar trebui să dețină baza de cunoștințe în organizație?

Proprietatea se împarte pe două niveluri: fiecare document are un proprietar de conținut din echipa care îl produce, iar corpusul în ansamblu are un proprietar de proces, care răspunde de acoperire, prospețime și de decizia ce intră și ce iese din index. Al doilea rol e cel omis, și absența lui se vede în șase luni.

Pregătirea corpusului e partea care nu apare în demo-uri și decide, totuși, dacă sistemul e util sau doar impresionant o dată. Începe cu inventarul și cu 50 de întrebări reale — restul deciziilor se iau mult mai ușor după.

Dacă vrei un audit al surselor pe care le ai deja sau un plan de ingestie pentru un pilot, servicii AI și RAG e punctul de pornire.