Strategia ca document — Al șaptelea capitol

Capitolul 6 — Strategia ca document, nu ca cod

Ajungem la intuiția care, mai mult decât orice altceva, în povestea celor care au construit RAG din 2023 încoace, revine ca "lucrul pe care aș fi vrut să-l înțeleg de la început".

Framework-urile tradiționale tratează strategia de căutare ca cod Python. Vrei, pentru cataloagele tehnice, să cauți mai întâi după codul produsului, apoi după cuvinte cheie, apoi după vectori semantici și doar în ultimă instanță să generezi răspunsul? Scrie o funcție. Vrei, pentru albumele foto, să sari peste căutarea semantică tradițională și să te bazezi pe un reranker specializat pentru imagini? Scrie o altă funcție. Vrei, pentru videoclipurile corporative, să separi audio de pista vizuală, să le transcrii separat, să le tratezi ca surse distincte și apoi să le recompui în răspunsul final? O altă funcție. Fiecare tip de conținut, fiecare domeniu, fiecare client ajunge să genereze o ramură de cod care diverge de celelalte, până în punctul în care modificarea unei strategii necesită o lansare software, o revizuire a codului, un ciclu de testare, un deploy. Timpul dintre "am o idee despre cum să îmbunătățesc căutarea în manualele tehnice" și "ideea este în producție" se măsoară în săptămâni. Pentru fiecare idee.

Intuiția alternativă este banală de spus și profundă în consecințe: strategia de căutare nu este cod. Este un document. Un JSON — un format de text structurat pe care orice editor, cu o jumătate de oră de instruire, îl poate citi — care spune: "mai întâi încearcă asta, apoi aia, dacă prima eșuează, treci la a treia, reordonează așa, răspunde cu acest model." Acest document trăiește într-o bază de date, nu într-un repository. Se modifică dintr-o interfață, nu printr-o pull request. Se versionază, se copiază, se specializează pe domeniu. O strategie pentru cataloage tehnice, una pentru albume foto, una pentru manuale de instalare, una pentru video, una pentru audio, una pentru contracte legale, una pentru bilanțuri. Toate coexistă în același sistem. Toate modificabile în timp real.

Cei care au lucrat cu această abordare — să o numim, fără prea multă imaginație, Meta-RAG — povestesc o schimbare de viteză care depășește ingineria. O cerere tipică a clientului "adaugă o căutare specifică pentru codurile de produs care conțin abrevieri de tip CMP40M sau RH1M" nu mai este un tichet de dezvoltare de două săptămâni. Este un nou pas adăugat unei proceduri JSON, testat rapid într-un mediu de staging, promovat în producție într-o după-amiază. Întrebarea "ce se schimbă dacă folosim un reranker diferit pentru fotografii, menținând cel actual pentru text?" se răspunde modificând o linie de configurare. Experimentul nu costă nimic, revenirea costă nimic (este suficient să restabiliți versiunea anterioară a documentului), iar cunoștințele acumulate — ce funcționează bine pentru un anumit tip de conținut — devin un patrimoniu versionat și transferabil, nu cunoștințele tacite ale celui care a scris acea ramură particulară de cod și astăzi este în concediu.

Există, de asemenea, un efect social interesant, care apare în organizațiile care adoptă această abordare. Cu strategiile ca document, granița dintre "dezvoltator" și "utilizator experimentat" se mută. Un bibliotecar digital, un arhivist corporativ, un expert în domeniu — șeful biroului tehnic, responsabila cu documentația, managerul de produs care cunoaște ca nimeni altul adevăratele întrebări ale clienților — poate citi o strategie, înțelege ce face, sugera modificări, uneori chiar să le scrie direct. Nu trebuie să treacă prin pâlnia tichetului de dezvoltare, nu trebuie să explice unui dezvoltator lucruri pe care dezvoltatorul nu le știe (pentru că nu este în meseria lui să le știe). RAG-ul încetează să mai fie un produs pe care îl consumi și devine un instrument pe care îl modelezi pe baza cunoștințelor tale organizaționale. Acest lucru, în experiența celor care l-au încercat, schimbă moralul proiectului înainte chiar de cifrele metricilor.

Nu este magie și are costurile sale. Este nevoie de un motor care să execute aceste strategii-ca-document în mod eficient și sigur. Este nevoie de un limbaj de descriere suficient de bogat pentru a acoperi cazurile reale și suficient de simplu pentru a nu deveni un alt Turing-complet deghizat. Sunt necesare instrumente de versionare, de testare, de rollback. Dar toate acestea sunt problemele celui care construiește motorul — o singură dată, și pentru toți utilizatorii. Clientul final individual vede doar un lucru: posibilitatea de a evolua propria strategie de căutare cu viteza gândului, în loc de viteza ciclului de lansare software. Și aceasta, pentru cei care sunt implicați, este o revoluție silențioasă care încă nu și-a găsit numele în revistele de specialitate.

Încheiere — Al șaptelea capitol, peste câteva luni

La începutul anului 2026, adunând lecțiile capitolelor anterioare — tabelele care se pierdeau, rerankerii mincinoși, halucinațiile moștenite, facturile cloud care creșteau mai repede decât valoarea, framework-urile promițătoare dar rigide — cineva, în Italia, a început să construiască un server RAG diferit. Scris în Python, gândit să ruleze pe hardware accesibil, capabil să comunice cu modele cloud când este convenabil și cu modele locale când confidențialitatea o impune sau costul nu se justifică. Un server în care strategiile de căutare sunt documente modificabile, reranker-ul este un proces local pe GPU, tabelele nu se pierd deoarece sunt tratate ca cetățeni de primă clasă, fotografiile nu moștenesc obiecte din arhive prăfuite ale altor epoci, iar costul per interogare — atât în bani, cât și în date filtrate către terțe părți — este cunoscut și controlabil până la ultimul cent.

Nu vom menționa numele proiectului. Acesta nu este articolul potrivit pentru a face acest lucru și nu dorim să transformăm o investigație într-o reclamă. Dar dacă capitolele anterioare v-au făcut să recunoașteți o situație pe care o trăiți – un chatbot corporativ care răspunde cu încredere la întrebări greșite, un proiect RAG care nu decolează de luni de zile, o factură cloud care crește mai repede decât utilitatea pe care o produce, o îndoială crescândă cu privire la faptul că documentele dvs. confidențiale călătoresc în locuri pe care nu le cunoașteți – atunci merită să știți că există o altă cale, care a fost parcursă de cineva în Italia și care în 2026 a început să ofere primele răspunsuri care erau așteptate în 2023.

Vestea bună este că AI-ul corporativ, în sfârșit, iese din faza demo. Vestea mai puțin bună este că iese purtând cu sine toate cicatricile călătoriei: cadre de lucru umflate, dependențe de furnizori, arhitecturi monolitice, date murdare, erori silențioase și o anumită tendință a industriei de a vinde soluții înainte chiar de a înțelege problema. Le-am povestit în șase capitole. Al șaptelea – povestea a ceea ce se întâmplă când cineva face în sfârșit lucrurile bine, cu răbdare, în italiană și în open source – îl vom scrie în curând, cu mai puțină prudență în ceea ce privește numele și mai multe cifre pe masă.

Între timp, dacă ai ajuns până aici, ai făcut deja mai multă analiză aprofundată decât 90% dintre factorii de decizie care în acest moment semnează un contract pentru un chatbot corporativ fără a pune niciuna dintre întrebările pe care le-ai pus citind aceste capitole. Este un punct de plecare mai bun decât cel de la care au pornit ei. Și în următoarele luni, diferența dintre cei care și-au pus aceste întrebări și cei care nu, va deveni foarte vizibilă pe facturi — și pe răspunsurile pe care AI-ul vostru le va oferi clienților voștri.

Această investigație a fost redactată în aprilie 2026, pe baza experienței de optsprezece luni de proiectare, construire și optimizare a sistemelor RAG corporative între sfârșitul anului 2024 și începutul anului 2026.