RAG pentru licitații și achiziții publice: cerințe și dovezi

Anunțul a apărut vineri, la 17:40. Documentația de atribuire are o sută optzeci de pagini în unsprezece fișiere: fișa de date, caietul de sarcini, patru anexe tehnice, formularele, modelul de contract și două scanuri care par să fie planuri de amplasament. Termenul de depunere e peste treizeci și cinci de zile. Termenul până la care mai ai voie să întrebi ceva e mult mai devreme.

Până luni dimineață cineva trebuie să răspundă la o singură întrebare: merită să intrăm? Iar ca să răspundă, trebuie să știe ce cere documentația și cât din ce cere ea poate fi demonstrat cu ce ai deja în firmă. Ăsta e cazul de utilizare pentru un RAG pe licitații și achiziții publice.

E primul caz din cluster în care corpusul nu e al tău. La support extern, la helpdesk intern sau la enablement de vânzări, indexezi documente pe care le deții, le controlezi și le actualizezi. Aici indexezi documentul altcuiva, o singură dată, pentru o singură oportunitate, cu termen de expirare cunoscut dinainte. Mecanismul rămâne același RAG. Economia din jurul lui se inversează complet. Iar dacă întrebarea ta e despre celălalt capăt al fluxului de achiziții — ciclul continuu furnizor, comandă, livrare, recepție, unde specificația și documentul de recepție se contrazic — acolo se aplică RAG pentru achiziții și aprovizionare.

Ce e diferit la un RAG pentru licitații: corpusul nu e al tău

Patru lucruri, și fiecare atinge o decizie de arhitectură diferită.

Indexul are dată de expirare din prima zi

O bază de cunoștințe internă se construiește o dată și se întreține ani de zile: adaugi documente, ștergi ce a expirat, reindexezi ce s-a schimbat. Ciclul de viață e continuu și amortizezi costul de ingestie pe mii de interogări.

Documentația unei licitații nu se comportă așa. O ingerezi într-o după-amiază, o interoghezi intens două-trei săptămâni, apoi devine inutilă — sau, mai exact, își schimbă rolul: din corpus interogabil devine arhivă. Costul de ingestie se amortizează pe câteva zeci de interogări, nu pe mii.

Asta răstoarnă toate compromisurile pe care le faci la o bază de cunoștințe permanentă. Acolo îți permiți o pipeline de ingestie scumpă, cu curățare atentă și chunking calibrat, fiindcă o plătești o singură dată. Aici ingestia trebuie să fie ieftină și rapidă, fiindcă o plătești la fiecare oportunitate. Iar mecanica de prospețime, ștergeri și reindexare nu mai e un proces de mentenanță: e o dată calendaristică scrisă în metadate încă de la ingestie.

Întrebarea reală nu e „ce cere caietul de sarcini”

Asta e întrebarea aparentă. Un sistem care răspunde doar la ea produce un rezumat frumos și inutil, fiindcă rezumatul nu spune nimic despre tine.

Întrebarea care contează e: din ce cere documentația, ce pot demonstra cu ce am deja? Experiență similară în ultimii ani, certificări valabile, CV-uri de experți cu vechimea cerută, situații financiare peste prag, utilaje sau echipamente în proprietate ori disponibile prin angajament. Sistemul face un JOIN între o listă de cerințe externe și un corpus de dovezi interne.

E fix inversul mecanicii din RAG pentru conformitate și audit intern. Acolo pornești din regula ta internă și cauți dovada că a fost respectată — direcția e dinspre politică spre control spre dovadă. Aici pornești din regula altcuiva, pe care o vezi prima oară, și cauți dovada că o îndeplinești. Modelul de date seamănă; sensul săgeții e opus, și de asta se schimbă ce indexezi întâi.

Recall bate precizia, fiindcă o cerință ratată descalifică

În celelalte cazuri, un răspuns incomplet e un răspuns mai slab. Aici, o cerință de calificare ratată nu produce un scor mai mic: produce ofertă respinsă. Formalismul e eliminatoriu, iar costul celor două tipuri de eroare nu e nici pe departe simetric.

Consecința practică e că pragurile se calibrează invers față de un sistem de răspuns obișnuit. Extragi generos, cu top-k mare și fără prag agresiv de similaritate, și accepți că lista de cerințe va conține și zgomot. Un fals pozitiv costă trei minute de citit ale unui om. Un fals negativ costă licitația.

E singurul caz din cluster în care metricile de retrieval nu se echilibrează. Definițiile de recall și precizie și felul în care se măsoară sunt în cum evaluezi un sistem RAG; ce se schimbă aici e doar care dintre ele conduce.

Calendarul e o constrângere de produs

Latența într-un sistem de vânzări se măsoară în secunde, fiindcă omul e în apel. Aici se măsoară în ore și în zile, dar e la fel de dură — doar că ceasul e scris în lege, nu în răbdarea utilizatorului.

Restul cazurilor enterprise, cu compromisurile lor, sunt în secțiunea de cazuri de utilizare.

Ce indexezi dintr-o documentație de atribuire

Nu tot pachetul are aceeași greutate și nu tot pachetul se citește la fel.

Straturile pachetului

Fișa de date conține cerințele de calificare și criteriile de atribuire în formă structurată — e stratul cu cea mai mare densitate de obligații pe pagină și primul pe care îl procesezi. Caietul de sarcini conține cerințele tehnice, adesea în proză lungă, cu obligații ascunse în propoziții subordonate. Formularele definesc forma în care se demonstrează fiecare lucru. Modelul de contract conține obligații care se aplică după atribuire, dar care influențează prețul pe care îl poți oferi.

Anexele scanate sunt cazul urât: planuri, tabele fotografiate, documente semnate și scanate strâmb. Se tratează exact ca orice corpus care trece prin OCR înainte de chunking — mecanica e descrisă în RAG pe contracte și documente juridice și nu o reiau.

Clarificările și eratele modifică documentul de bază

Aici e diferența de care se împiedică majoritatea implementărilor. Documentația nu e statică nici măcar în cele trei săptămâni cât o folosești. Răspunsurile la solicitările de clarificări se publică pentru toți participanții și pot schimba interpretarea unei cerințe. Erata schimbă efectiv textul.

Un index care conține doar pachetul inițial devine, la prima clarificare relevantă, un index care minte cu încredere. Practic ai nevoie de un strat suplimentar în care fiecare clarificare intră cu data ei și cu o legătură explicită către cerința pe care o atinge, iar retrievalul returnează întotdeauna versiunea cea mai nouă a interpretării, nu prima.

Ce nu are ce căuta în index

Documentațiile altor licitații, oricât de asemănătoare. Tentația e mare, mai ales la autorități care refolosesc șabloane: pare că poți popula checklistul din memoria a douăzeci de proceduri anterioare. Dar cerințele se schimbă de la o procedură la alta exact în detaliile care contează — pragul de cifră de afaceri, numărul de ani de experiență similară, lista de certificări acceptate.

Un retrieval semantic pe un corpus de proceduri vechi va returna cerința cea mai asemănătoare, nu cerința din documentul ăsta. E aceeași eroare de identitate versus similaritate care apare la prețuri în enablement de vânzări, doar că aici te costă mai devreme.

Documentațiile anterioare sunt utile, dar în altă parte: ca sursă pentru corpusul de dovezi, nu pentru cel de cerințe.

Extragerea cerințelor: de la proză la checklist verificabil

Ieșirea utilă a primului pas nu e un rezumat. E o listă în care fiecare rând poate fi bifat sau nu de un om.

Anatomia unei cerințe

Un rând de checklist are cinci câmpuri, și fiecare vine din altă parte a documentului: enunțul cerinței, sursa exactă (fișier, secțiune, pagină), tipul, pragul sau valoarea, și forma de dovadă acceptată. Fără sursă, nimeni nu poate verifica extragerea. Fără prag, „experiență similară” nu înseamnă nimic. Fără forma de dovadă, nu știi dacă îți trebuie un certificat, o declarație sau un contract semnat.

Formatul de răspuns e mai important aici decât în alte cazuri, fiindcă output-ul e citit ca document de lucru, nu ca replică într-o conversație. Principiile generale sunt în cum arată un răspuns bun de RAG; particularitatea de aici e că fiecare afirmație trebuie să stea lângă dovada ei sau lângă absența ei.

Patru tipuri de cerințe, patru consecințe diferite

Cerințele eliminatorii se verifică primele: dacă una pică, restul analizei e timp pierdut. Cerințele de calificare și selecție se demonstrează cu documente și se pot acoperi, în anumite condiții, prin asociere sau prin susținerea unui terț. Factorii de evaluare nu se bifează, se optimizează — ei decid punctajul, nu admisibilitatea. Obligațiile contractuale nu afectează admiterea, dar intră în preț.

Un sistem care le amestecă produce un checklist cu două sute de rânduri egale între ele, ceea ce e aproape la fel de inutil ca documentul original. Clasificarea nu trebuie să fie perfectă, dar trebuie să existe.

De ce lista e deliberat prea lungă

Un checklist generat cu recall mare va conține rânduri care nu sunt cerințe reale: fraze descriptive, repetări între fișa de date și caietul de sarcini, obligații ale autorității citite ca obligații ale ofertantului. Asta e acceptabil, cu o condiție: interfața trebuie să aibă o stare explicită de „nu se aplică”, iar apăsarea ei să fie ieftină.

Un om care marchează treizeci de rânduri irelevante în zece minute e o afacere bună. Un om care descoperă în ziua depunerii că sistemul nu a extras cerința de la pagina 94 nu e.

JOIN-ul: cerințe externe, dovezi interne

Partea a doua e cea care produce valoare, și e singura care are nevoie de un corpus pe care chiar îl deții.

Corpusul de dovezi

Recomandări și procese-verbale de recepție de la contracte anterioare, fișe de proiect, certificate constatatoare, atestate și autorizații cu termenele lor de valabilitate, CV-uri de experți cu proiectele la care au lucrat, situații financiare pe ultimii ani, liste de utilaje și echipamente. Spre deosebire de documentația de atribuire, corpusul ăsta e permanent, se întreține continuu și merită toată atenția pe care o dai la ingestie.

Există un detaliu care surprinde la prima implementare: corpusul de dovezi nu e doar al tău. Documentul unic de achiziție european — DUAE, instituit prin Regulamentul (UE) 2016/7 și integrat direct în SEAP din aprilie 2019 — se completează separat de fiecare membru al unei asocieri, de fiecare terț susținător și de fiecare subcontractant declarat. Dacă intri în asociere, jumătate din dovezile care contează sunt în altă firmă, cu alt regim de acces.

Trei stări, și cea din mijloc e cea valoroasă

Fiecare cerință primește una din trei stări: acoperită, parțial acoperită, lipsă. Starea „acoperită” e liniștitoare și nu produce nicio acțiune. Starea „lipsă” produce o decizie mare și rară: te asociezi, subcontractezi sau nu depui.

Starea „parțial acoperită” e cea care merită tot efortul de inginerie, fiindcă e singura care produce acțiune imediată și utilă: o solicitare de clarificare. Ai experiență similară, dar contractul tău e pe o valoare puțin sub prag; ai certificarea, dar expiră între depunere și semnare; ai expertul, dar vechimea lui se calculează altfel decât pare că cere fișa de date. Toate astea sunt întrebări bune, iar fereastra în care le poți pune se închide devreme.

DUAE ca formă a răspunsului

Mecanica DUAE se potrivește neașteptat de bine peste arhitectura unui sistem de retrieval. DUAE e o declarație pe propria răspundere: afirmi că nu te afli în situațiile de excludere și că îndeplinești criteriile de calificare, iar documentele justificative se prezintă ulterior, la solicitarea autorității contractante — de regulă doar de ofertantul clasat pe primul loc.

Cu alte cuvinte, la depunere ai nevoie de două lucruri distincte: să poți declara adevărat, și să știi unde e dovada când ți se cere. Un sistem care produce doar prima parte e periculos. Un sistem care leagă fiecare declarație de documentul care o susține, cu locul lui exact, transformă o etapă stresantă de mai târziu într-o extragere de fișiere.

Ce rămâne obligatoriu la om

Interpretarea echivalenței. „Experiență similară” e o noțiune pe care documentația o definește parțial și pe care evaluatorul o aplică integral. Un sistem poate propune candidați și poate arăta de ce seamănă. Decizia că un contract de reabilitare se încadrează în cerința pentru construcție nouă nu e o decizie de retrieval, e o decizie de risc — și se ia de cineva care semnează.

Praguri, numitori și cifre care par stabile

Domeniul ăsta e plin de cifre care arată ca niște constante și nu sunt.

Prag european sau prag național

Pragurile peste care se aplică procedurile cu publicare în Jurnalul Oficial al Uniunii Europene sunt stabilite în euro la nivel european, revizuite periodic și exprimate în lei printr-o comunicare a Comisiei. Pentru perioada 2026–2027 au fost actualizate prin Regulamentul delegat (UE) 2025/2152, publicat în Jurnalul Oficial din 23 octombrie 2025, aplicabil procedurilor lansate începând cu 1 ianuarie 2026.

Pragurile pentru achiziția directă sunt însă naționale, stabilite în lei prin lege: sub 270.120 lei pentru produse sau servicii și sub 900.400 lei pentru lucrări. Nu se mișcă la doi ani odată cu regulamentele europene; se mișcă atunci când se modifică legea.

Distincția nu e academică. Un sistem care a memorat un prag european dintr-un ciclu anterior va încadra greșit o procedură, iar un om care se bazează pe el va căuta obligații care nu există sau va rata unele care există. Merită reținut și că unele praguri au scăzut față de perioada 2024–2025 — sensul modificării nu e mereu în sus.

Cifra din document nu e cifra din lege

A doua capcană e mai subtilă. Valoarea estimată apare în anunț; pragul apare în lege; procentele apar în fișa de date. Un sistem care le tratează pe toate ca „numere din context” le va confunda la prima întrebare care le pune împreună.

Regula practică e aceeași ca la orice corpus cu cifre normative: fiecare valoare extrasă păstrează sursa, unitatea, data la care era valabilă și rolul ei. Fără cele patru câmpuri, un număr e doar un număr care sună autoritar.

Trimiterile la norme care s-au schimbat

Documentațiile citează articole, hotărâri de guvern și regulamente. Unele au fost modificate de mai multe ori de la publicarea lor. Legislația achizițiilor din România a fost modificată repetat în ultimul deceniu, iar în paralel formularele europene s-au schimbat integral: formularele standard eForms, stabilite prin Regulamentul de punere în aplicare (UE) 2019/1780, au devenit obligatorii la nivelul TED în octombrie 2023, iar SEAP a trecut la ele în decembrie 2023.

Concluzia pentru sistem e simplă și incomodă: nu trata o trimitere legislativă din document ca pe un fapt verificat. Tratează-o ca pe un pointer, arată-l omului cu tot cu context și lasă verificarea formei în vigoare la el.

Calendarul ca cerință de produs

Termenele nu sunt un detaliu de proces. Ele decid ce arhitectură are voie să existe.

Fereastra de clarificări se închide mult înaintea depunerii

La licitație deschisă, perioada dintre transmiterea anunțului de participare spre publicare în Jurnalul Oficial al Uniunii Europene și termenul limită de depunere a ofertelor e de cel puțin 35 de zile, cu posibilitatea de reducere în situații de urgență demonstrate.

Dar termenul până la care poți întreba e stabilit de autoritate în anunț și cade mult mai devreme. Într-un anunț real de lucrări publicat în TED, autoritatea a fixat solicitările de clarificări cu 25 de zile înainte de termenul de depunere și răspunsul consolidat cu 12 zile înainte. Din cele 35 de zile, fereastra în care mai poți influența ceva ține aproximativ zece.

Asta răstoarnă ordinea de lucru. Extragerea cerințelor și JOIN-ul cu dovezile trebuie să se termine în primele zile, nu în ultimele. Ce se întâmplă după închiderea ferestrei e redactare, nu analiză — și niciun sistem nu recuperează o întrebare nepusă.

Erata resetează o parte din index

Când apare o erată sau un răspuns consolidat care schimbă o cerință, indexul trebuie să reflecte asta în ore, nu la următoarea rulare programată. Din fericire, corpusul e mic prin construcție: reingestia unui pachet de documentație nu e o operațiune de noapte, e o operațiune de câteva minute.

Merită păstrat însă istoricul: cerința veche nu se șterge, se marchează ca înlocuită. Altfel nimeni nu mai poate explica de ce estimarea de acum două săptămâni arăta altfel.

Ce latență contează de fapt

Nu timpul de răspuns la o interogare. Timpul de la publicarea anunțului până la primul checklist utilizabil. Dacă durează două zile, ai pierdut o cincime din fereastra utilă înainte să începi. Dacă durează două ore, ai timp să pui întrebările bune.

Granița față de un tool de bid management

Întrebarea corectă nu e „construiesc sau cumpăr”, ci „ce parte din problemă e de retrieval”.

Ce rămâne în tool-ul clasic

Biblioteca de conținut reutilizabil, fluxul de aprobare între tehnic, juridic și financiar, urmărirea termenelor, versionarea răspunsurilor, evidența a ce s-a depus și când. Astea sunt probleme de workflow și de colaborare, rezolvate bine de produse mature, și nu devin mai bune fiindcă adaugi un model peste ele.

Unde câștigă stratul de model

Două lucruri, și sunt exact cele două pe care un tool de workflow nu le face: extragerea cerințelor din documente urâte — scanuri, tabele rupte peste pagini, obligații ascunse în subordonate — și potrivirea semantică între cum descrie autoritatea o cerință și cum descrii tu aceeași realitate în fișele tale de proiect. „Experiență similară în implementarea de sisteme informatice integrate” și „migrare ERP la un distribuitor” sunt același lucru în două vocabulare, iar căutarea pe cuvinte nu le apropie.

Când nu merită deloc

Dacă depui trei oferte pe an, o citire atentă a documentației bate orice index. Costul de setup nu se amortizează, iar riscul de a rata o cerință e mai mic la un om care citește o dată pe trimestru decât la un sistem pe care nimeni nu-l întreține. Pragurile generale de decizie sunt în când nu folosești RAG, iar aici se aplică cu o nuanță în plus: volumul care justifică sistemul nu se măsoară în pagini, ci în număr de proceduri pe an.

Ce măsori — și de ce nu găsești aici o cifră de win rate

Metricile din celelalte cazuri nu se transferă, fiindcă rezultatul final nu depinde doar de tine.

Patru indicatori onești

Recall pe cerințe. Pe un set de proceduri deja depuse, câte dintre cerințele identificate manual apar în checklistul generat. E singura metrică pe care o poți construi retroactiv, fără să aștepți rezultate.

Timpul până la decizia de participare. De la publicarea anunțului până la momentul în care cineva poate spune motivat „intrăm” sau „nu intrăm”. E metrica pe care o simte echipa.

Numărul de clarificări utile trimise. Nu numărul total. Cele care au produs un răspuns care a schimbat ceva în oferta ta. Un sistem care nu generează niciodată o întrebare bună nu citește destul de atent.

Descalificările formale. Ofertele respinse pentru o cerință neîndeplinită sau nedemonstrată. Ținta e zero, iar fiecare caz merită urmărit până la rândul din checklist care a lipsit sau a fost marcat greșit.

De ce nu apare aici un procent de creștere a ratei de câștig

Pentru că spațiul e ocupat aproape integral de cifre care nu rezistă la o singură întrebare de metodologie.

Rata medie de câștig la licitații circulă în jurul a 45%, cu variații pe dimensiunea companiei, iar creșterile atribuite automatizării merg de la câteva puncte procentuale până la aproape 60%. Sursele sunt însă, aproape fără excepție, rapoarte publicate de furnizori de software de răspuns la licitații, construite pe sondaje în propria comunitate de clienți. Cine răspunde la un astfel de sondaj e deja utilizator de tool și deja are un proces formal — populația e selectată exact pe variabila măsurată.

A doua problemă e numitorul, aceeași ca peste tot unde apar rate: „câștigate din depuse” și „câștigate din oportunități identificate” produc numere care diferă de câteva ori, iar sursele rareori spun care e care.

A treia e cea mai interesantă, fiindcă e specifică domeniului. Aceleași rapoarte arată că principalul factor care separă echipele de top e disciplina de calificare: renunțarea la oportunitățile în care nu ai șanse. Dar renunțarea la o licitație scade numitorul fără să schimbe nimic în calitatea răspunsului. O echipă care depune la jumătate din proceduri și câștigă la fel de multe are, mecanic, o rată dublă. Atribuirea acestei creșteri software-ului confundă un efect de selecție cu unul de performanță.

Ce poți face în schimb: măsoară-ți propria linie de bază înainte, pe aceleași definiții, și compară cu tine.

Un pilot care demonstrează ceva în șase săptămâni

Ia zece proceduri deja depuse, pentru care ai checklistul făcut manual și rezultatul cunoscut. Rulează extragerea pe ele și măsoară recall-ul pe cerințe. Fără JOIN, fără integrare, fără interfață — doar întrebarea dacă sistemul găsește ce a găsit omul. Dacă răspunsul e da, adaugi corpusul de dovezi și treci pe o procedură live. Dacă nu, ai aflat ieftin că problema e la ingestie, nu la model.

Întrebări frecvente

Pot indexa toate licitațiile publicate, ca să găsesc oportunități?

Da, dar e alt sistem. Descoperirea oportunităților e o problemă de filtrare și clasificare pe fluxul de anunțuri, cu criteriile tale de calificare aplicate automat. Analiza documentației e o problemă de retrieval pe un corpus mic și dens. Se pot lega, dar nu se construiesc împreună la început — al doilea produce valoare imediată, primul are nevoie de volum ca să merite.

Cât de mult poate scrie sistemul din ofertă?

Propunerea tehnică, nu. Poate produce schelete: structura cerută de formulare, secțiunile obligatorii, trimiterile la dovezi. Conținutul care diferențiază — abordarea, metodologia, motivul pentru care tu duci proiectul la capăt — e exact partea pe care evaluatorii o punctează și pe care un text generic o pierde. Aceeași graniță ca la propuneri și obiecții comerciale, doar cu o comisie în loc de un client.

Ce fac cu documentele scanate prost?

Le tratezi ca pe orice corpus care trece prin OCR: extragi, verifici pe eșantion, marchezi paginile cu încredere scăzută și le trimiți explicit la citire umană. Ce nu faci e să lași un scan ilizibil să intre tăcut în index — o cerință pierdută acolo arată exact ca o cerință care nu există.

Merge același sistem și pentru licitații private?

Parțial, și de obicei mai ușor. Structura e mai liberă, termenele sunt negociabile și formalismul e mai puțin eliminatoriu, deci pragurile de recall se pot relaxa. Corpusul de dovezi e identic — el e investiția care se refolosește, indiferent de tipul procedurii.

Cine ar trebui să dețină sistemul în firmă?

Echipa care depune, nu IT-ul. Corpusul de dovezi se degradează în câteva luni dacă nimeni nu adaugă recepțiile noi și nu marchează certificările expirate, iar singurii care simt imediat consecința sunt oamenii care completează checklistul. Un sistem de tipul ăsta întreținut de altcineva decât utilizatorul lui devine, previzibil, o arhivă.

Un RAG pentru licitații nu e un rezumator de caiete de sarcini. E un index cu dată de expirare pus peste documentul altcuiva, legat de un index permanent cu dovezile tale, calibrat pe recall fiindcă o omisiune costă procedura, și livrat suficient de repede încât să mai prinzi fereastra de clarificări.

Dacă vrei să afli dacă volumul tău de proceduri justifică un astfel de sistem — sau doar unde se pierde acum timpul între publicare și depunere — scrie-ne. Restul arhitecturilor și al cazurilor de utilizare sunt în secțiunea despre AI și RAG.