RAG pe desene tehnice și BIM: documentul care nu e text

Un inginer de proiectare întreabă asistentul intern: „ce diametru are alezajul de prindere pe suportul SB-140?”. Sistemul RAG a indexat arhiva de desene prin OCR, găsește planșa corectă și răspunde prompt: „12 mm”. Pe desen scrie Ø12 H7 — iar lotul comandat pe baza răspunsului vine de la prelucrare cu alezaje care nu țin rulmentul. Nicio halucinație, nicio planșă greșită: cifra chiar există pe desen. S-a pierdut doar tot ce o făcea o instrucțiune.

Toate corpusurile de până acum din serie — contracte, tickete, cod sursă, catalog — erau, în esență, text: uneori structurat, alteori murdar, dar text. Desenul tehnic, schema electrică și modelul BIM sunt primul corpus în care documentul nu e text. Informația stă în geometrie și în legăturile dintre adnotări și elementele desenate, iar extracția de text — pasul zero al oricărui pipeline obișnuit de RAG — distruge exact aceste legături. Mecanica generală rămâne valabilă; ce se schimbă e că pasul de pregătire care funcționa rezonabil peste tot devine, aici, sursa principală de eroare.

Desenul e o proiecție, nu o pagină

Un desen tehnic nu e o pagină cu text și câteva figuri. E o proiecție a unui obiect tridimensional, cu un aparat de adnotare construit în jurul geometriei — și cu sensul distribuit în legăturile dintre ele.

Anatomia planșei: geometrie, adnotări, cartuș

Trei straturi trăiesc pe aceeași planșă. Geometria: vederi, secțiuni, detalii — reprezentări convenționale ale aceluiași obiect, legate între ele prin reguli de proiecție; secțiunea A-A nu se înțelege fără vederea care o marchează. Adnotările: cote, toleranțe, rugozități, note tehnologice — fiecare arată, printr-o linie de indicație, spre un element anume din geometrie. Și cartușul: blocul din colț cu numărul desenului, revizia, scara, materialul, semnăturile — singura zonă care chiar seamănă cu metadatele unui document obișnuit.

Sensul stă în legături. „Ø12 H7” nu plutește liber pe pagină: aparține unui alezaj anume, dintr-o vedere anume. Aceeași valoare, mutată la alt element, ar fi o altă instrucțiune — iar pe o planșă aglomerată, zeci de cote stau la câțiva milimetri unele de altele.

Ce distruge extracția de text

OCR-ul și parserele de PDF citesc pagina ca pe o secvență de caractere. Rezultatul, pe un desen, e o listă de numere și fragmente — „12”, „H7”, „0,8”, „M6”, „A-A” — fără elementele spre care arătau. Legătura cotă–element, adică exact purtătorul de sens, nu supraviețuiește extracției, pentru că nu era text: era o relație spațială.

Există și o pierdere mai subtilă decât cotele: nota din cartuș. „Toleranțe generale conform ISO 2768-mK, dacă nu se specifică altfel” e o singură frază care schimbă sensul fiecărei cote fără toleranță explicită de pe planșă. Extrasă din context și ruptă de desen, nota devine un fragment oarecare; rămasă neregăsită, fiecare cotă „simplă” din răspuns e de fapt incompletă. Documentul funcționează ca un întreg cu reguli implicite — proprietate pe care segmentarea în chunk-uri o ignoră prin construcție. Iar nota trimite mai departe, la un standard care nu e pe planșă: textul care se aplică prin trimitere are propriile lui reguli de indexare, de ediție și de licență.

Consecința la retrieval e perfidă tocmai fiindcă nimic nu pare stricat. Fragmentele extrase se regăsesc fără probleme: întrebarea despre diametru aduce chunk-ul cu „12” în context, generatorul construiește o frază fluentă în jurul lui, iar răspunsul citează onest desenul corect. Tot lanțul funcționează — și livrează cifra fără instrucțiunea din jurul ei. Regăsirea direct pe imaginea paginii, fără extracție de text, există ca abordare și e discutată la service-ul pe teren, unde corpusul e dominat de scheme și desene explodate; ea aduce planșa potrivită, nu valoarea de pe ea — distincția revine mai jos, la arhitectură.

Cota e o instrucțiune cu toleranță, nu un număr

Continuarea directă a lecției de la catalogul de produse: acolo, atributul era o valoare cu unitate, care se interoghează exact, nu se embedează. Cota de pe desen urcă încă o treaptă — e o valoare cu unitate, toleranță și metodă de verificare.

Ce spune de fapt „Ø12 H7”

Nu „doisprezece”. Sistemul ISO de toleranțe și ajustaje traduce clasa H7, la un diametru nominal de 12 mm, într-un interval de acceptare: alezajul e conform dacă măsoară între 12,000 și 12,018 mm. Litera codifică poziția câmpului de toleranță față de nominal, cifra lățimea lui; împreună cu clasa arborelui pereche, combinația decide dacă ajustajul iese liber, intermediar sau presat — adică dacă rulmentul intră cu mâna, cu presa sau deloc. „Ø12 H7” e simultan o instrucțiune către prelucrare și o condiție de acceptare la control. „12” e doar un răspuns la o întrebare care nu s-a pus.

Vecinătatea semantică minte pe toleranțe

Pentru un embedding, „Ø12 H7” și „Ø12 H6” sunt aproape identice — diferă un caracter. Ca instrucțiuni, sunt clase de precizie diferite, cu procese și costuri de prelucrare diferite. E aceeași conversie tăcută semnalată la catalog, cu miza ridicată o treaptă: acolo unitatea se pierdea într-o conversie neverificată; aici toleranța dispare din răspuns fără nicio urmă, iar cifra rămasă arată complet. Un răspuns care redă cota fără câmpul ei de toleranță nu e un rezumat al cotei — e altă cotă.

Simbolurile de toleranțe geometrice nu au echivalent textual

Dincolo de dimensiuni, desenele de precizie poartă toleranțe geometrice — planeitate, perpendicularitate, poziție, coaxialitate — scrise în casete standardizate, cu referințe la baze de cotare marcate pe geometrie. Simbolurile nu sunt caractere de text: OCR-ul le transformă în semne aleatorii sau le ignoră complet. Pierderea nu e marginală — pe un reper de precizie, caseta de toleranță geometrică e adesea cerința cea mai scumpă de îndeplinit din tot desenul. Un corpus construit din text extras pur și simplu nu conține aceste cerințe, iar sistemul nu are cum să semnaleze absența a ceva ce nu a văzut niciodată. Absența tăcută e mai rea decât eroarea vizibilă: nimeni nu verifică ce nu apare.

Revizia e regimul de adevăr

A doua proprietate care desparte desenul de un document obișnuit: versiunea înlocuită nu devine greșită.

Desenul înlocuit rămâne adevărul lotului lui

Rev B a fost înlocuită de Rev C — dar toate reperele fabricate cât timp Rev B era în vigoare sunt conforme față de Rev B, nu față de desenul curent. O reclamație despre lotul livrat în martie se judecă pe revizia în vigoare în martie; o piesă de schimb pentru un echipament vechi se execută după desenul epocii lui, nu după cel de azi. E aceeași logică a versiunii-în-vigoare ca anul nomenclaturii la clasificarea tarifară: întrebarea poartă o dată, iar documentul potrivit e cel valabil la data aceea, nu cel mai recent.

Retrieval-ul fixează revizia înainte de similaritate

Practic: fiecare planșă intră în index cu numărul desenului, revizia, data intrării în vigoare și statusul — în vigoare, înlocuită, anulată — luate din registrul de desene sau din sistemul PDM, nu deduse din text. Iar filtrul pe revizie se aplică înainte de căutare, ca predicat pe metadate, nu ca preferință de ranking — tiparul de filtru dur care revine în tot clusterul, aplicat aici pe axa timpului. Fără el, două revizii ale aceleiași planșe concurează pe similaritate — adică aleatoriu, din perspectiva ta — iar sistemul răspunde despre lotul din martie cu cota din iulie, citând senin un document perfect valid.

Ordinul de modificare leagă reviziile

Ce s-a schimbat între Rev B și Rev C nu scrie pe niciuna dintre ele. Trăiește în ordinul de modificare — ECO, în jargonul ingineresc — care a produs trecerea: motivul schimbării, elementele afectate, data efectivă, uneori dispoziția pentru stocul existent și pentru comenzile în curs. Pentru retrieval, ECO-ul e documentul-punte ideal: text obișnuit, indexabil normal, legat prin metadate de ambele revizii. Întrebarea „de ce s-a mărit alezajul?” nu are răspuns pe desen — are răspuns în ECO. Un corpus de planșe fără ECO-urile lor e o arhivă de stări fără istorie: vezi fiecare fotografie, dar nu și filmul.

Iar revizia nu trăiește izolat: desenul de ansamblu referă zeci de repere, fiecare cu revizia lui, prin lista de componente. O întrebare despre ansamblu e implicit o întrebare despre o combinație de revizii — configurația validă la o dată anume — nu despre un singur document. Lista de componente cu reviziile ei e, la rândul ei, o dată structurată din PDM sau ERP, nu un text: încă un motiv pentru care stratul de metadate se construiește din sisteme, nu se extrage din pagini.

Modelul BIM e o bază de date deghizată în fișier

La construcții și instalații, echivalentul desenului s-a mutat deja într-o formă care recunoaște deschis ce este: modelul BIM nu mai pretinde că e un document.

IFC: entități, proprietăți, relații

Formatul deschis de schimb e IFC — Industry Foundation Classes. Potrivit buildingSMART, organizația care întreține standardul, versiunea oficială curentă e IFC4.3 ADD2, devenită standardul internațional ISO 16739-1:2024, cu extinderea domeniului la infrastructură — căi ferate, drumuri, poduri, porturi; schema e publicată liber, iar versiunile următoare (IFC4.4, IFC5) sunt în lucru. IFC nu e un format de fișier în sensul PDF: e un model de date. Un perete e o entitate IfcWall, cu proprietăți — grosime, rezistență la foc, straturi — și cu relații: aparține unui nivel, mărginește două spații, găzduiește o ușă. Fișierul e doar serializarea; conținutul e o bază de date de obiecte.

Entitățile se interoghează, nu se embedează

„Câte uși cu rezistență la foc EI60 sunt pe nivelul 3?” nu e o întrebare de retrieval. E o interogare structurată: filtrezi entitățile de tip ușă după proprietatea de rezistență la foc și după relația de apartenență la etaj, apoi numeri. Aceeași regulă ca la stratul de atribute al catalogului: structura care există deja la sursă nu se topește înapoi într-un text de embedat. Un model IFC transformat în proză produce exact amestecul pe care structura lui îl interzicea — proprietăți rupte de entități, relații pierdute, numărători imposibile.

Ce rămâne pentru retrieval e textul din jurul modelului, și nu e puțin: cerințele temei de proiectare, notele de calcul, rapoartele de coordonare și de coliziuni, procesele-verbale, corespondența de șantier. Documente obișnuite, cu regulile obișnuite de pregătire a corpusului — doar că fiecare trebuie legat prin metadate de elementele și de versiunea de model la care se referă. Un raport de coliziuni care spune „conducta C-114 intersectează grinda de pe axul 5” e text perfect indexabil, dar valoarea lui operațională stă în identificatorii pe care îi conține: fără legătura către elementele din model, e o observație plutitoare; cu ea, e o intrare interogabilă în istoricul unei probleme concrete. Identificatorul de element joacă aici rolul pe care numărul de reper îl joacă pe desene.

ISO 19650 și nivelul de informație: cine cere ce, când

Managementul informației în jurul modelului are propriile standarde, și merită citite pentru ce impun efectiv. Seria ISO 19650 nu definește un format de fișier: definește procesul — cerințe de informații formulate explicit de beneficiar, un mediu comun de date (CDE) prin care circulă toate livrabilele și stări explicite ale fiecărui container de informație, de la lucru-în-curs la partajat și publicat. Pentru un sistem de retrieval, starea din CDE e metadata cea mai valoroasă din tot ecosistemul: spune negru pe alb ce versiune are ce regim de adevăr — exact distincția care la desenele clasice trebuia reconstruită din registru.

Nivelul de detaliu cerut are și el standardul lui, iar aici merită verificată sursa, nu broșurile: conceptul de „level of information need” — ce informație, pentru ce scop, la ce moment, livrată de cine, ca geometrie, date alfanumerice sau documentație — a fost standardizat european prin EN 17412-1 în 2020, standard între timp retras și înlocuit de ISO 7817-1:2024, cu conținut aliniat seriei ISO 19650. Consecința practică pentru corpus: cerințele de informație sunt o hartă a ce trebuie să existe la fiecare etapă. Folosită ca schemă de metadate, harta transformă întrebarea „lipsește ceva?” dintr-o căutare negativă imposibilă într-o verificare de completitudine pe listă.

Arhitectura unui RAG pe desene: interoghezi, afișezi, regăsești

Corpusul s-a despărțit în trei populații cu regimuri diferite: date structurate (registrul de desene, modelul IFC), artefacte vizuale (planșele) și text obișnuit (ECO-uri, caiete de sarcini, rapoarte). Arhitectura urmează împărțirea, iar routerul care alege mecanismul e mai valoros decât orice îmbunătățire de embedding.

Tabelul de decizie

Patru din șase rânduri nu ating indexul vectorial — la fel ca la orice corpus cu structură reală.

Numărul de desen se potrivește exact sau deloc

„4471-D” nu are vecini semantici utili — la fel ca tag-ul unui instrument dintr-o schemă sau codul unei planșe de arhitectură. Componenta lexicală a căutării e obligatorie, iar hybrid search cu reranking e configurația minimă pe un corpus tehnic, nu o optimizare târzie. Un sistem în care identificatorii se caută doar semantic ratează sistematic exact interogările cu răspuns cert — cele pe care utilizatorii le testează primele.

Răspunsul arată planșa, nu o parafrazează

Pentru orice întrebare a cărei valoare stă pe desen, forma corectă de răspuns e desenul: pagina sau vederea relevantă, afișată ca imagine, cu numărul, revizia și data lângă ea — și cu omul citind cota în contextul ei vizual. Sinteza în limbaj natural rămâne pentru textul din jur: ECO-uri, cerințe, rapoarte. Iar când legătura cotă–element nu poate fi garantată, abținerea explicită bate parafraza — regulile generale de format se aplică integral, cu un prag de refuz mai agresiv pe orice valoare numerică. Desenul ca ieșire a procesului de dezvoltare — cu brevetele și literatura din amonte — e alt corpus, cu altă calibrare: acolo obiectivul e conexiunea neașteptată, aici documentul e închis și normativ, iar improvizația e defect, nu virtute.

Ce măsori și de unde începi

Avantajul acestui corpus la evaluare seamănă cu cel al catalogului: adevărul de referință există — în registru, în model, pe planșă. Ce lipsește e doar disciplina de a-l folosi.

Trei metrici specifice

Acuratețea reviziei. Din întrebările care poartă o dată sau un lot, câte răspunsuri au folosit revizia în vigoare la momentul respectiv, nu cea curentă. Se măsoară pe perechi construite din registru: aceeași întrebare, două date, două răspunsuri corecte diferite — dacă sistemul dă același răspuns la ambele, filtrul temporal nu funcționează.

Abținerea pe valori numerice. Câte întrebări despre cote au primit planșa afișată sau un refuz explicit, față de o cifră parafrazată din text extras. Ținta pentru parafrazare e zero: fiecare caz e o toleranță pierdută în tăcere, adică exact eroarea din primul paragraf al articolului.

Acoperirea legăturilor. Ce procent din planșele active au ECO-urile, reperele și elementele de model asociate prin metadate. Sub un prag, întrebările de tip „de ce” și „ce s-a schimbat” nu au pe ce rula — nu e o problemă de model, e un gol de date.

Cadrul general — set de referință, praguri, disciplina măsurării — e în cum evaluezi un sistem RAG.

Pilotul care nu începe cu OCR

Tentația e să pornești cu digitalizarea arhivei. Începe invers: un singur proiect sau o singură familie de repere active, cu registrul de desene ca fundație — numere, revizii, stări, date — planșele servite ca imagini, ECO-urile și documentele text indexate normal. Fără OCR pe cote, fără extracție de geometrie. Livrabilul, după șase săptămâni: la întrebările reale din ultimul an — din tichete, e-mailuri, rapoarte de neconformitate — câte primesc planșa corectă, în revizia corectă, cu textul-punte lângă ea. Dacă rezultatul e sub jumătate, problema e registrul, nu retrieval-ul — și ai aflat asta înainte să scanezi ceva. Delimitarea generală a cazurilor în care nu ai nevoie de niciun sistem e trasă separat.

Întrebări frecvente

Poate un model multimodal să citească direct cotele de pe desen?

Pentru regăsirea planșei potrivite, indexarea pe imagine e o cale validă. Pentru extragerea unei cote cu toleranță ca adevăr operațional, nu: eroarea e tăcută, iar costul ei e un lot neconform. Valoarea se citește de om, pe planșa afișată, sau se ia din modelul CAD ori din PDM, unde există deja ca dată structurată.

Merită să convertesc DWG-urile în PDF pentru indexare?

Conversia aruncă exact partea prelucrabilă: layerele, blocurile cu atribute, cartușul ca date structurate. Extrage metadatele direct din fișierele native sau din PDM și folosește PDF-ul doar ca format de afișare. Un PDF generat din DWG e o fotografie a unei baze de date.

Ce fac cu arhiva de desene scanate de pe hârtie?

Registrul înainte de pixeli: inventar, numere, revizii și stări pentru planșele încă active, cu OCR limitat la cartuș, unde chiar funcționează. Restul arhivei se digitalizează pe măsură ce e cerută, nu preventiv. Un scan fără metadate de revizie e mai periculos în index decât în sertar.

Modelul BIM înlocuiește desenele?

Contractual, de multe ori încă nu — planșele extrase din model rămân documentul de referință, iar care versiune guvernează e o decizie de proiect, nu una tehnică. Sistemul trebuie să reflecte decizia: starea de publicat din CDE și registrul de desene spun împreună ce document are autoritate în fiecare moment.

Schemele electrice și P&ID-urile intră în același tipar?

Da, cu aceeași consecință: relația e informația. Tag-urile de instrumente și conexiunile dintre ele se extrag ca date și se potrivesc exact; textul din jur — memorii tehnice, liste de cabluri, proceduri — se indexează normal. O schemă embedată ca text pierde exact topologia pentru care există.

Un RAG peste desene tehnice și modele BIM nu e un OCR cu un chat deasupra. E un registru de identități și revizii interogat exact, un model IFC întrebat structurat, planșe afișate ca planșe — și retrieval semantic doar acolo unde documentul chiar e text. Când planșa ajunge într-un dosar și un expert numit de instanță se pronunță asupra ei, regimul se schimbă încă o dată: constatarea lui are autoritate, dar poate fi înlăturată motivat — cazul e tratat în RAG pe expertize judiciare. Pentru o discuție despre cum ar arăta asta pe arhiva ta de proiectare, trimite un mesaj. Restul corpusurilor din serie sunt în hubul Cazuri de utilizare enterprise, firul documentației tehnice în hubul de tag, iar imaginea completă a serviciului în AI și RAG.