În multe companii, cele mai valoroase informații se află într-un PDF uitat într-un folder partajat. Proceduri, rapoarte, contracte, specificații tehnice sau documente de conformitate conțin răspunsuri importante, însă accesul la ele depinde adesea de structura arhivelor interne, de denumiri de fișiere, de versiuni păstrate în paralel și de memoria oamenilor care știu "unde trebuie căutat". Informația există, dar nu este întotdeauna pregătită pentru a fi folosită în mod sistematic.
Timp de mulți ani, sistemele de Business Intelligence au fost asociate în principal cu rapoarte, indicatori și dashboarduri construite peste baze de date structurate. Ele rămân esențiale atunci când vrem să analizăm vânzări, costuri, performanță operațională sau alți indicatori măsurabili. În practică, însă, multe întrebări relevante pentru o organizație nu sunt strict numerice. Uneori vrem să aflăm ce prevede o procedură, ce s-a schimbat între două versiuni ale unui document, unde apare o anumită cerință sau dacă două documente oferă răspunsuri diferite la aceeași problemă.
Folosirea documentelor nestructurate ca surse de informație utilizabilă și verificabilă deschide o direcție importantă pentru evoluția Business Intelligence. Tehnologii precum recunoașterea optică a caracterelor (Optical Character Recognition, OCR), căutarea semantică, reprezentările vectoriale ale textului, cunoscute ca embeddings și generarea augmentată prin regăsirea informației (Retrieval-Augmented Generation, RAG) pot contribui la această transformare. Totuși, între o demonstrație convingătoare și un sistem de producție există o distanță importantă. Calitatea extragerii textului, păstrarea structurii documentului, fragmentarea corectă, tratarea duplicatelor și verificabilitatea răspunsurilor decid dacă sistemul devine util în practică sau rămâne doar o interfață interesantă.
Un dashboard răspunde bine la întrebări care au deja o structură numerică. Cât s-a vândut? Care este trendul? Unde apare abaterea? Pentru astfel de întrebări, modelul clasic de Business Intelligence este foarte potrivit: datele sunt pregătite, agregate și afișate într-o formă ușor de urmărit.
Există însă o altă categorie de întrebări, la fel de importantă în activitatea unei organizații. Putem aplica această procedură într-un anumit caz? Ce spune ultima versiune a documentului? Pe baza cărei cerințe se ia o decizie? De ce două echipe folosesc instrucțiuni diferite pentru același proces?
Aceste întrebări nu sunt neapărat complexe pentru un expert care cunoaște bine organizația. Dificultatea apare atunci când informația este împărțită între zeci sau sute de fișiere, păstrate în foldere diferite, redactate în formate diferite și actualizate în momente diferite. În astfel de situații, accesul la informație depinde adesea de oamenii care știu contextul, de convenții interne de denumire și de timpul petrecut căutând manual.
Din această perspectivă, documentele devin o sursă de date în sine. Diferența este că această sursă nu are o structură simplă și stabilă. În loc de câmpuri clare, avem paragrafe, tabele, anexe, imagini, semnături, anteturi, note de subsol și versiuni succesive ale aceluiași conținut.
Căutarea după cuvinte-cheie poate fi un punct de plecare, dar presupune ca întrebarea utilizatorului și formularea din document să folosească aceiași termeni. În practică, aceeași idee poate fi exprimată diferit de la un document la altul. O procedură poate vorbi despre "cerințe regulatorii", în timp ce utilizatorul caută "riscuri de conformitate". Fără o înțelegere semantică a textului, căutarea poate omite pasajul relevant.
Această limită mută atenția de la vizualizarea indicatorilor la folosirea cunoașterii operaționale. Pentru a ajunge acolo, documentele trebuie pregătite într-o formă care permite regăsirea informației, trasabilitatea surselor și verificarea răspunsurilor.
Figura 1. Două tipuri de întrebări în Business Intelligence
Un PDF este creat, în primul rând, pentru a arăta la fel peste tot. Această calitate l-a făcut util pentru contracte, proceduri, rapoarte și documente oficiale. Pentru un cititor uman, pagina poate părea clară: avem titluri, secțiuni, tabele, note și semnături. Pentru un sistem software, aceeași pagină poate fi doar o colecție de caractere poziționate pe coordonate, fără garanția că ordinea lor reflectă ordinea logică a textului.
Diferența devine importantă atunci când vrem să folosim documentele în procese automate. Un paragraf împărțit pe două coloane poate fi citit în ordinea greșită. Un tabel poate fi extras ca text liniar, pierzând relația dintre celule. Un antet repetat pe fiecare pagină poate ajunge să fie tratat ca informație relevantă. În cazul documentelor scanate, calitatea rezultatului depinde și de OCR, care poate introduce erori greu de observat la prima vedere.
De aceea, simpla extragere a textului este rareori suficientă. Pentru a transforma un document într-o sursă utilă de informație, trebuie păstrate cât mai multe elemente de context: secțiunea din care provine un pasaj, pagina, titlul apropiat, poziția într-un tabel sau relația cu alte fragmente din același document. Fără acest context, un sistem poate găsi un text aparent relevant, dar îl poate interpreta greșit.
Aici începe partea tehnică a problemei. Documentul trebuie transformat dintr-un fișier destinat citirii umane într-o reprezentare pe care sistemele de căutare și modelele lingvistice o pot folosi. Această transformare implică extragere de text, identificarea structurii, fragmentare, metadate și, în multe cazuri, reprezentări vectoriale ale textului. Fiecare pas poate îmbunătăți calitatea răspunsului final sau o poate degrada.
Figura 2. Flux de indexare: de la document PDF la index vectorial
După ce textul a fost extras din document, apare o altă problemă: cum găsim pasajul relevant? Căutarea după cuvinte-cheie funcționează bine atunci când utilizatorul știe ce termen apare în document și când documentele folosesc o terminologie consecventă. Aceste condiții nu sunt întotdeauna îndeplinite.
Aceeași idee poate fi formulată diferit în funcție de autor, departament sau perioada în care documentul a fost redactat. Un utilizator poate căuta "riscuri de conformitate", în timp ce documentul vorbește despre "cerințe regulatorii nerespectate". Într-un alt caz, o procedură poate folosi o denumire internă pe care utilizatorul nu o cunoaște. O căutare bazată strict pe potrivirea termenilor poate omite pasajul relevant, chiar dacă răspunsul există în document.
Căutarea semantică încearcă să rezolve această limitare. În loc să compare doar cuvinte, sistemul transformă fragmentele de text în reprezentări vectoriale. Aceste reprezentări capturează, într-o formă numerică, apropierea de sens dintre texte. Astfel, două formulări diferite pot fi considerate apropiate dacă exprimă aceeași idee sau aparțin aceluiași context.
Totuși, căutarea semantică nu garantează singură că răspunsul este complet sau corect. Dacă documentul a fost împărțit greșit, dacă metadatele lipsesc sau dacă versiunile vechi nu sunt diferențiate de cele actuale, sistemul poate recupera un pasaj util, dar insuficient pentru decizia utilizatorului. Căutarea semantică este puternică, dar are nevoie de un fundament bun.
Căutarea semantică ajută la găsirea fragmentelor relevante, dar utilizatorul nu vrea întotdeauna o listă de pasaje. De multe ori, caută un răspuns formulat clar, împreună cu sursa din care poate verifica informația. Aici intervine RAG, adică generarea augmentată prin regăsirea informației.
Într-un sistem RAG, modelul lingvistic nu răspunde doar pe baza informațiilor învățate în timpul antrenării. Înainte de generarea răspunsului, sistemul caută în documentele disponibile și selectează fragmentele considerate relevante pentru întrebare. Aceste fragmente sunt apoi oferite modelului ca sursă de context. Într-o implementare bună, răspunsul final rămâne legat de documentele folosite.
În sisteme mai mature, fragmentele recuperate pot fi reordonate înainte de a ajunge la modelul lingvistic. Acest pas, cunoscut ca reranking, ajută la selectarea pasajelor care răspund cel mai bine la întrebare, nu doar a celor apropiate semantic. Diferența contează mai ales atunci când mai multe documente folosesc termeni similari, dar doar unele conțin contextul necesar.
RAG nu rezolvă automat problema încrederii. Dacă fragmentele selectate sunt incomplete, răspunsul va fi construit pe o bază slabă. Dacă sistemul folosește o versiune veche a documentului, concluzia poate fi greșită. Dacă două surse se contrazic, modelul poate produce un răspuns fluent fără să evidențieze tensiunea dintre ele. În astfel de cazuri, problema nu este neapărat modelul lingvistic, ci contextul pe care îl primește.
O întrebare centrală pentru sistemele de acest tip este: ce informație ajunge la model? Alegerea fragmentelor, păstrarea metadatelor, ordinea surselor și filtrarea documentelor vechi influențează direct calitatea răspunsului. Un model foarte performant nu poate compensa complet un proces slab de regăsire a informației.
Pentru Business Intelligence, valoarea apare atunci când răspunsul poate fi urmărit înapoi până la documentul care îl susține. În acel moment, sistemul devine un strat de acces la cunoașterea internă a organizației, nu o simplă interfață conversațională peste un set de fișiere.
Figura 3. Flux de regăsire și generare: de la întrebarea utilizatorului la răspuns cu surse
O diagramă a unui sistem bazat pe RAG poate părea liniară: extragem textul, îl împărțim în fragmente, generăm reprezentări vectoriale și căutăm pasajele relevante. În practică, calitatea rezultatului final depinde de multe decizii mici, luate înainte ca întrebarea utilizatorului să ajungă la modelul lingvistic.
Prima zonă sensibilă este extragerea informației din document. Dacă ordinea textului este greșită, dacă un tabel este transformat într-o listă greu de interpretat sau dacă un antet repetat ajunge în fiecare fragment, sistemul va indexa informație degradată. În acel moment, problema nu mai poate fi rezolvată complet printr-un model mai bun. Modelul va lucra cu ceea ce primește.
Fragmentarea documentului este la fel de importantă. Dacă fragmentele sunt prea mici, se pierde contextul necesar pentru înțelegerea pasajului. Dacă sunt prea mari, căutarea devine mai puțin precisă și contextul trimis modelului se umple cu informație secundară. O procedură poate avea o excepție importantă la câteva paragrafe distanță de regula principală. Dacă cele două ajung în fragmente separate, sistemul poate oferi un răspuns incomplet, deși ambele informații există în document.
Metadatele fac diferența între un prototip și un sistem util. Un fragment de text trebuie să păstreze legătura cu documentul sursă, pagina, secțiunea și versiunea din care provine. Fără aceste informații, răspunsul devine greu de verificat. În mediul organizațional, utilizatorul nu are nevoie doar de o formulare plauzibilă, ci de posibilitatea de a ajunge rapid la sursa care susține acea formulare.
O dificultate frecventă apare și din existența documentelor similare. Companiile păstrează versiuni vechi, copii locale, documente exportate din alte sisteme sau fișiere care au fost modificate manual. Două documente pot conține aproape același text, dar o diferență mică poate schimba interpretarea. În astfel de cazuri, deduplicarea și versionarea nu sunt detalii administrative, ci pași necesari pentru a evita răspunsuri bazate pe informații depășite.
Soluțiile care lucrează cu documente trebuie gândite ca infrastructură de date. Modelul lingvistic este partea cea mai vizibilă, dar răspunsul final este influențat de întregul traseu al informației: de la documentul original până la fragmentele care ajung în contextul modelului. Când acest traseu este bine controlat, documentele încep să devină surse reale de cunoaștere pentru organizație.
Figura 4. Diferența între un demo și un sistem enterprise în lucrul cu documentele
Valoarea apare atunci când documentele pot susține direct drumul de la întrebare la răspuns verificabil. În loc ca utilizatorul să caute manual prin foldere, versiuni și documente similare, sistemul aduce în față pasajele relevante și sursa lor. Răspunsul rămâne ancorat în document, iar utilizatorul poate verifica rapid dacă interpretarea este corectă.
Pentru Business Intelligence, acest lucru extinde tipul de întrebări la care o organizație poate răspunde sistematic. Indicatorii arată ce s-a întâmplat într-un proces. Documentele explică, de multe ori, cum ar trebui să funcționeze procesul, ce reguli îl guvernează și ce decizii au fost luate în jurul lui. Fără această dimensiune, analiza poate rămâne incompletă, mai ales în organizațiile în care activitatea depinde de proceduri, standarde interne sau cerințe de conformitate.
Un exemplu simplu este analiza unei abateri operaționale. Un dashboard poate arăta că un indicator a ieșit din intervalul așteptat. Pentru a înțelege situația, utilizatorul are nevoie să consulte procedura aplicabilă, excepțiile acceptate și eventualele modificări recente ale procesului. Dacă aceste informații se află în documente separate, munca de analiză devine lentă și dependentă de experiența oamenilor care cunosc deja contextul.
În acest punct, documentele devin parte din infrastructura de decizie. Ele pot susține audituri, verificări interne, analiză de risc, suport operațional sau onboarding. Nu prin înlocuirea experților, ci prin reducerea timpului necesar pentru a ajunge la sursele relevante. Expertul rămâne cel care interpretează situația, dar nu mai pornește de la o căutare manuală printr-o arhivă greu de controlat.
Un sistem care lucrează cu documente interne trebuie evaluat diferit față de o simplă căutare. Dacă returnează un document irelevant, utilizatorul poate observa relativ ușor problema. Dacă generează un răspuns fluent, dar bazat pe o sursă greșită, eroarea devine mai greu de detectat. Tocmai de aceea, încrederea nu trebuie construită în jurul tonului convingător al modelului, ci în jurul trasabilității.
Fiecare răspuns important ar trebui să poată fi urmărit până la documentul sursă. Utilizatorul trebuie să vadă pasajele folosite, versiunea documentului și contextul din care a fost extrasă informația. Fără această legătură, sistemul poate accelera accesul la informație, dar nu oferă suficient control pentru procese unde contează auditul, conformitatea sau responsabilitatea deciziei.
O altă limită apare atunci când documentele conțin informații contradictorii. Un sistem bine proiectat nu ar trebui să ascundă această situație printr-un răspuns sintetic prea sigur. În anumite cazuri, cel mai valoros răspuns este să evidențieze conflictul: două surse spun lucruri diferite, una pare mai recentă, iar decizia finală trebuie validată de un expert.
Astfel de soluții funcționează cel mai bine ca suport pentru oameni, nu ca autoritate finală. Ele pot reduce timpul de căutare, pot scoate la suprafață pasaje relevante și pot ajuta la navigarea unor arhive greu de folosit manual. Interpretarea rămâne însă responsabilitatea utilizatorului, mai ales atunci când răspunsul influențează decizii operaționale, juridice sau de conformitate.
Business Intelligence a fost asociat mult timp cu rapoarte, indicatori și dashboarduri. Aceste instrumente rămân importante, dar nu acoperă întreaga cunoaștere pe care o organizație o folosește în activitatea de zi cu zi. Procedurile, contractele, specificațiile tehnice, rapoartele de audit sau documentele de conformitate conțin informații care influențează decizii reale, chiar dacă nu sunt stocate într-o bază de date relațională.
Transformarea acestor documente în surse de informație utilizabilă presupune mai mult decât extragerea textului dintr-un PDF. Contează structura documentului, calitatea fragmentării, metadatele păstrate, versiunile folosite și modul în care pasajele relevante ajung în contextul modelului lingvistic. Într-un sistem bazat pe RAG, calitatea răspunsului depinde de întregul traseu al informației.
Pentru companii, direcția este valoroasă tocmai pentru că pornește de la cunoașterea deja existentă. Multe organizații nu duc lipsă de documente, ci de o modalitate mai bună de a le folosi. Atunci când informația poate fi regăsită rapid, verificată la sursă și pusă în context, documentele devin parte din infrastructura prin care organizația înțelege și îmbunătățește propriile procese.
Datele structurate ne arată ce se întâmplă. Documentele pot explica regulile, excepțiile și deciziile din spatele proceselor. Împreună, ele oferă o imagine mai completă asupra organizației.
de Mihai Matei
de Bogdan Maier
