Tabelele care nu existau

Capitolul 2 — Tabelele care nu existau

Un tehnician de la o firmă mecanică din Nord-Est ne-a povestit-o în fața unui espresso, cu calmul venetian care prevestește un dezastru: "Chatbot-ul nostru știa totul despre motor. Cu excepția datelor motorului." Apoi a explicat. Asistentul lor AI intern știa să descrie gamele de produse, contextul de utilizare, istoria mărcii, avantajele competitive. O minune, din punct de vedere narativ. Dar când un client întreba cuplul nominal al modelului CMP50L — adică datele tehnice pentru care oamenii deschid catalogul, numărul pentru care se cumpără un motor — chatbot-ul răspundea vag, uneori plauzibil, alteori nu. Cinci luni de dezvoltare, directorul operațional din ce în ce mai perplex, și nimeni nu știa să spună de ce.

Diagnosticul a venit din întâmplare, aproape din plictiseală, inspectând manual baza de date după o nouă ședință fără rezultat. Catalogul PDF conținea 342 de tabele tehnice. În baza de date ajunseseră zero. Nu câteva: zero. Niciuna. Codul care extrăgea tabelele din PDF salva datele în câmpuri numite columns și data, în timp ce codul care le indexa ulterior se aștepta la câmpuri numite headers și rows. Un "sinonim" nerespectat. O convenție internă care sărise în timpul unui refactoring uitat. Rezultatul, timp de cinci luni silențioase: întreaga inteligență numerică a catalogului — perechi, puteri, diametre, greutăți, coduri de comandă, tensiuni de alimentare — ieșise din robinet fără a fi vreodată turnată în pahar. Trei sute patruzeci și două de tabele, pierdute una câte una în tăcere liturgică.

Acesta este tipul de bug care nu țipă. Nu ridică excepții, nu face nimic să se blocheze, nu apare în niciun log. Pur și simplu, o parte din lume încetează să existe pentru sistemul tău, și nimeni nu își dă seama până când un utilizator — de obicei un utilizator supărat — nu pune suficient de multe întrebări insistente pentru a arăta prăpastia. Și este emblematic pentru o problemă mult mai mare decât numele câmpurilor: framework-urile RAG generice sunt optimizate pentru textul curent — articole, pagini web, paragrafe de proză — și tratează tabelele ca cetățeni de mâna a doua, atunci când le tratează. Dar documentele de afaceri italiene *sunt* adesea tabele. Cataloage tehnice, liste de prețuri, specificații de produs, fișe de securitate, buletine de comandă: partea valoroasă, pentru cei care consultă aceste documente, este cea tabelară. Cea care se strică prima și de care nimeni nu își dă seama.

Lecția nu este "ai grijă la numele câmpurilor". Este mai complicată: într-un RAG serios, fiecare tip de conținut — tabele, imagini, coduri alfanumerice, titluri de paragraf, note de subsol — are nevoie de un tratament dedicat, proiectat, testat. Și testul de funcționare nu este "chatbot-ul răspunde la întrebări banale" — la acestea răspund și sistemele defecte, deoarece există suficiente date fluctuante pentru a construi ceva plauzibil. Testul adevărat este "chatbot-ul răspunde la întrebări care îl obligă să atingă fiecare piesă a pipeline-ului". Întrebări specifice, numerice, verificabile. Întrebări pentru care există un răspuns corect și unul singur, și dacă sistemul greșește, știi imediat.

Dacă nu faci acest test, nu știi dacă RAG-ul tău funcționează. Știi doar că nu se plânge. Și "nu se plânge" este un criteriu de calitate foarte scăzut pentru un sistem pe care oamenii îl vor folosi pentru a lua decizii.