Motorul care avea șase poli — Mitul celor zece linii de cod

Investiga în șase părți despre motivele pentru care chatbot-ul documentar pe care ți l-au vândut continuă să inventeze — și despre direcția diferită pe care, la începutul anului 2026, cineva a început să o parcurgă.

Investigație în șase părți despre motivele pentru care chatbot-ul documentar pe care ți l-au vândut continuă să inventeze — și despre direcția diferită pe care, la începutul anului 2026, cineva a început să o parcurgă.

Introducere — Motorul care avea opt poli (dar avea șase)

Milano, martie 2026. Un manager deschide chatbot-ul intern de companie, unul dintre acelea montate „în două săptămâni” de la departamentul IT cu entuziasm mare și suspiciune mică. O întrebare foarte simplă: „Câți poli are motorul CMP40M?”. Chatbot-ul răspunde cu toată încrederea pe care modelele lingvistice mari le știu să o demonstreze: „Motorul CMP40M are opt poli.”

Greșit. Are șase. Răspunsul corect nu se afla în catalogul de 422 de pagini pe care cineva, cu luni în urmă, îl vărsase cu cea mai mare încredere într-o bază de date vectorială, convins că de acolo înainte sistemul "va ști tot". Acea informație nu exista deloc în catalog. Se afla într-un PDF atașat unui e-mail de la tehnicienii SEW, arhivat într-un folder pe care nimeni nu și-a făcut grija să-l indexeze.

Această scenă, cu variații de sector și de dialect, se repetă în sute de birouri italiene. Promisiunea era simplă și seducătoare: dați-i toate documentele companiei asistentului vostru AI și va putea răspunde la orice întrebare despre ele. Realitatea este mult mai prozaică: chatbot-ul citește, dar nu înțelege, caută, dar nu găsește și, atunci când nu găsește — în loc să spună asta — inventează. Inventează cu fluență, cu gramatică perfectă, cu numere plauzibile. Ceea ce este mult mai rău decât să nu răspundă.

Între sfârșitul anului 2024 și începutul anului 2026 am petrecut luni de zile făcând autopsia acestor eșecuri. Nu pentru a alimenta polemici, ci pentru a înțelege un lucru: de ce o idee atât de liniară — "dă-i documentele și apoi întreabă-l lucruri" — devine atât de dificilă atunci când iese de pe scena demo-ului și intră în camera serverelor reale.

Această investigație în șase capitole relatează ce am descoperit: bug-uri silențioase care ștergeau întregi cataloage, rerankeri cloud cu scoruri greșite, halucinații născute nu din model, ci din date contaminate cu ani în urmă, facturi care făceau fiecare interogare mai scumpă decât valoarea sa, și framework-uri "populare" care promit totul în zece linii de cod cu condiția să nu li se ceară prea mult. Și în ultimul capitol, direcția diferită pe care cineva a început să o urmeze în tăcere la începutul anului 2026 — o arhitectură în care strategia de căutare încetează să mai fie cod și devine un document pe care oricine din companie îl poate citi și modifica.

Fiecare capitol este autonom. Dacă vrei să începi cu povestea celor 342 de tabele dispărute, sau cu cea a rerankerului mincinos, ești liber să o faci. Dar povestea în ansamblu are o morală care emerge doar la sfârșit: RAG-ul corporativ — acronimul tehnic care înseamnă Retrieval-Augmented Generation, adică "generează răspunsuri bazându-te pe documente pe care le recuperezi mai întâi" — nu este încă un produs finit. Este o frontieră. Și ca toate frontierele, până acum a fost povestită mai ales de vânzători. Este timpul să ascultăm și pe cei care au trăit în interiorul ei.

Capitolul 1 — Mitul celor zece linii de cod

Slide-ul este identic la fiecare conferință despre AI din 2023 încoace: "Asistentul tău documentar corporativ în 10 rânduri de cod." Sub titlu, un bloc de Python în culori pastelate care arată o bibliotecă open source — de obicei una dintre acele celebre americane, al cărui nume evocă lanțuri de copaci sau lame tibetane — care încarcă PDF-uri, le fragmentează, le lipește într-o bază de date vectorială și le interoghează cu un model lingvistic. În cinci minute, ai un chatbot. În cinci minute, aplauze. În cinci minute, o companie italiană de dimensiuni medii este convinsă că problema este rezolvată și că departamentul său IT poate reuși în două săptămâni.

Problema — cea pe care slide-ul nu o spune — este că demo-ul este construit cu trei PDF-uri bine formate, o întrebare croită pe măsură pentru a se potrivi cu conținutul, o scenă fără latențe reale și un prezentator care a testat totul de douăzeci și șapte de ori înainte de a urca pe scenă. În realitate, documentele corporative sunt un dezastru geologic: scanări ale scanărilor, tabele care se suprapun peste text, note de subsol care se infiltrează în paragrafe, coduri alfanumerice de tip "RH1M" pe care fragmentatorul le taie în jumătate crezându-le cuvinte, imagini care conțin șaptezeci la sută din informațiile utile, dar pe care nimeni nu le extrage cu adevărat, și machete atât de creative încât necesită un arheolog mai degrabă decât un parser.

RAG — aceasta este ideea de sub capotă — este o idee excelentă. Ia întrebarea utilizatorului, caută în arhivă documentele cele mai relevante, treci-le modelului lingvistic și obține un răspuns bazat pe acele documente. În teorie, rezolvă elegant problema halucinațiilor: modelul nu mai trebuie să "știe" răspunsul, ci doar să-l "citească" din fragmentele pe care i le-ai furnizat. În practică, fiecare verigă din lanț — fragmentarea, încorporarea, recuperarea, reordonarea, generarea finală — are propriile modalități de a se defecta, iar defectarea se manifestă rareori ca o eroare vizibilă. Se manifestă ca un răspuns ușor greșit. Apoi ca un răspuns complet greșit. Apoi ca un manager care se întreabă de ce plătește pentru un sistem care știe mai puțin decât stagiarul.

Framework-urile open source care au popularizat RAG sunt făcute pentru a demonstra, nu pentru a produce. Sunt concatenări elegantissime de abstracții în care fiecare strat ascunde o presupunere netăcută: că PDF-urile tale au un OCR decent, că fotografiile tale au fost deja descrise, că tabelele tale respectă o convenție, că modelul de embedding vorbește cu adevărat limba ta (spoiler: multe vorbesc bine doar engleză), că arhiva ta a fost deja curățată de duplicate. Când una dintre aceste presupuneri cade — și cel puțin una cade întotdeauna, aproape întotdeauna trei — sistemul nu încetează să funcționeze. Mai rău: încetează să funcționeze bine, dar continuă să ofere răspunsuri. Răspunsuri fluide, sigure și adesea deconectate de adevăr.

Există o frază care circulă printre cei care construiesc aceste sisteme prin profesie, și pe care nu o veți găsi niciodată în tutoriale: "RAG este ușor de făcut, și dificil de făcut bine." Între prima demonstrație și serviciul în producție există o prăpastie care nu poate fi umplută adăugând GPU-uri sau schimbând modelul. Se umple înțelegând un lucru incomod: atunci când construiești un RAG corporativ, nu scrii cod. Proiectezi un mic, încăpățânat motor de căutare personalizat pentru documentele tale, cu toate alegerile editoriale pe care le implică acest lucru — ce este zgomot, ce este semnal, ce trebuie indexat de două ori, ce trebuie aruncat. Doar că în tutorialele de zece rânduri, aceste alegeri sunt făcute în locul tău, o singură dată, de cineva care nu a văzut niciodată documentele tale. Și sunt aproape întotdeauna greșite pentru cazul tău.