De ce engine-ul de devize HG907 nu folosește deloc LLM (și asta e feature)

Trei consultanți de achiziții ne-au întrebat aceeași întrebare în prima săptămână de demo Bid365: „Ce model AI rulează în spate pentru devize?” Răspunsul i-a surprins: niciunul. Engine-ul de devize din Bid365 este integral algoritmic, fără un singur token generat de un model lingvistic. În acest articol explicăm de ce această decizie nu este un compromis tehnic, ci o cerință legală.

TL;DR

• Devizele construite conform HG 907/2016 sunt obiecte legal-determinist: aceleași intrări trebuie să producă, prin lege, exact același rezultat — la cent.
• Modelele lingvistice generează ieșiri probabilistice. Pentru calcul aritmetic exact, devin liability, nu asset.
• Engine-ul Bid365 folosește aritmetică zecimală cu rotunjire ROUND_HALF_UP, 14 reguli de validare ANAP și o ierarhie strictă T1→T4 fără variabilitate.
• Pe 1.000 de devize generate independent cu aceleași date de intrare, varianța rezultatului este zero — bit cu bit identic.
• Documentul rezultat trece audit ANAP fără remarci pe componenta de calcul; remarcile rămase sunt pe descrieri tehnice, unde decizia umană este oricum cerută.

Ce este un deviz HG907 și de ce contează precizia

HG 907/2016 este actul normativ care stabilește cum se calculează devizul general pentru lucrările de investiții publice în România. Documentul are zeci de articole care prescriu exact cum se grupează cheltuielile, cum se aplică cota de cheltuieli indirecte, cum se calculează profitul, cum se aplică TVA-ul.

Pentru un ofertant care răspunde la o licitație publică, devizul nu este un calcul aproximativ. Este un obiect legal: dacă valoarea totală nu se reconstituie din componente conform regulilor HG907, oferta poate fi respinsă pentru neconformitate. „Aproximativ” este o categorie inexistentă. „Aproximativ corect” este, în drept, „greșit”.

Această cerință elimină din start orice abordare bazată pe un model generativ. Nu există prompt suficient de strict ca un LLM să garanteze că 12.547,32 + 8.213,41 + 1.502,84 = 22.263,57 la fiecare apelare, pe miliarde de combinații posibile. Modelele lingvistice fac aritmetică prin aproximare statistică; chiar și modelele cu „chain of thought” și calculator extern introduc variabilitate la nivelul deciziilor de routing.

Anatomia unui deviz HG907 din perspectiva engine-ului

Engine-ul Bid365 modelează devizul ca o ierarhie de patru niveluri tabelare numite T1, T2, T3, T4. Fiecare nivel adaugă o componentă specifică peste suma nivelului anterior.

T1 — Costul direct. Suma celor trei capitole de bază: manoperă, materiale, utilaje. Datele de intrare sunt liste de articole cu cantitate și preț unitar.

T1 = Σ(cantitate_i × preț_unitar_i) pentru manoperă
   + Σ(cantitate_j × preț_unitar_j) pentru materiale
   + Σ(cantitate_k × preț_unitar_k) pentru utilaje

T2 — T1 plus cheltuieli indirecte. Cheltuielile indirecte se aplică ca procent peste T1, conform politicii ofertantului declarată în formular.

T2 = T1 × (1 + cota_indirecte)

T3 — T2 plus profit. Profitul se aplică ca procent peste T2, nu peste T1, conform regulii ANAP.

T3 = T2 × (1 + cota_profit)

T4 — T3 plus asigurări obligatorii. În anumite categorii de lucrări se adaugă o componentă de cheltuieli pentru asigurări legate de execuție.

T4 = T3 + asigurări_obligatorii

Total deviz cu TVA = T4 × (1 + cota_TVA), unde cota TVA depinde de categoria lucrării.

Această ierarhie pare trivială în prezentare. Complexitatea apare când o aplici pe un deviz real cu 800 de articole, fiecare cu cantitate fracționară, preț unitar la patru zecimale, cu rotunjiri intermediare la fiecare subtotal de capitol.

De ce contează rotunjirea ROUND_HALF_UP

Standardul implicit de rotunjire în floating point IEEE 754 este „bankers’ rounding” (ROUND_HALF_EVEN): la jumătate exact, rotunjește spre numărul par cel mai apropiat. Această regulă este corectă statistic — nu introduce bias pe seturi mari de calcule.

Pentru un deviz HG907, ROUND_HALF_EVEN este greșit. ANAP cere rotunjirea aritmetică standard (ROUND_HALF_UP): 0,5 se rotunjește mereu în sus. Dacă engine-ul folosește ROUND_HALF_EVEN, vor apărea diferențe sistematice de câțiva bani pe fiecare subtotal față de calculul referință al comisiei.

Diferența de un ban pe un subtotal nu pare gravă; pe un deviz cu 800 de articole, după agregarea pe capitole și aplicarea procentelor, devine o diferență de zeci de lei pe T4. Este suficient pentru ca verificatorul comisiei, care reconstituie totalul cu aritmetică standard, să raporteze „neconformitate matematică”.

Engine-ul Bid365 folosește aritmetică zecimală pură (tip Decimal cu precizie controlată), nu floating point. Toate rotunjirile sunt explicite, ROUND_HALF_UP, la pasul prescris de HG907 (de regulă 2 zecimale pentru valori monetare, 4 zecimale pentru cantități). Această decizie a fost luată în fază 1 a proiectului și nu a fost niciodată renegociată.

Cele 14 reguli de validare

Calculul corect este condiție necesară, nu suficientă. Un deviz poate fi aritmetic perfect și complet inacceptabil pentru ANAP dacă ratează regulile structurale. Engine-ul Bid365 aplică 14 reguli de validare după calcul, pe care le-am extras lucrând cu trei comisii de evaluare de la trei autorități contractante diferite. Nu publicăm lista completă (este IP de produs), dar exemplificăm câteva categorii:

• Reguli de structură. Fiecare articol trebuie încadrat într-un capitol valid (manoperă, materiale, utilaje, transport, alte cheltuieli). Articolele cu capitol nul sau invalid sunt respinse.
• Reguli de coerență. Cota de cheltuieli indirecte și cota de profit trebuie să se încadreze în plajele declarate în formularul ofertei. Discrepanță = respins.
• Reguli de completitudine. Anumite capitole sunt obligatorii pentru anumite tipuri de lucrări (de exemplu, lucrările de construcții civile au capitol de manoperă obligatoriu).
• Reguli de coerență TVA. Cota TVA aplicată trebuie să corespundă categoriei lucrării. O lucrare scutită cu TVA aplicat este o respingere automată.
• Reguli de format. Codurile articolelor trebuie să respecte nomenclatorul național; descrierile trebuie să aibă lungime minimă; cantitățile trebuie să fie pozitive.

Fiecare regulă produce un mesaj de eroare textual cu trimitere la articolul HG907 sau ANAP relevant. Ofertantul vede exact ce trebuie corectat și de ce. Această trasabilitate este importantă: în cazul unui contestat, ofertantul are dovada că engine-ul a aplicat regulile cu trimitere normativă.

De ce un LLM nu poate face asta

Există o tentație evidentă pentru oricine construiește software de procurement: „Hai să folosim un LLM să genereze devizul din specificația textuală a lucrării.” Pe demo arată spectaculos. În producție eșuează din trei cauze structurale.

Variabilitatea. Același prompt cu aceleași date va produce, peste un milion de invocări, un număr semnificativ de ieșiri ușor diferite. Pentru un ofertant care depune oferta unică pe data X, este acceptabil. Pentru un sistem care trebuie să reproducă același deviz când comisia recalculează la verificare, este catastrofal.

Aritmetica. Modelele lingvistice nu sunt calculatoare. Pot părea că sunt, pe exemple simple. Pe 800 de articole cu rotunjiri lănțuite și aplicări de procente compuse, vor face erori. Folosirea unui tool extern de calcul (function calling) reduce dar nu elimină problema, pentru că modelul decide când și cum să cheme tool-ul.

Auditabilitatea. Un deviz respins în comisie trebuie reconstituit. Ofertantul trebuie să poată arăta, pas cu pas: aceste articole, înmulțite cu aceste cantități, însumate, cu această cotă, dau acest T1; T1 înmulțit cu această cotă dă T2 și așa mai departe. Un LLM produce o ieșire opacă: nu există un „lanț de calcul” verificabil în afara textului generat. Engine-ul algoritmic produce un audit trail explicit.

Unde folosim LLM în Bid365 (și unde nu)

Distincția importantă: respingem LLM-ul pentru calcul, dar îl folosim deliberat pentru sarcini lingvistice.

LLM-ul rulează pentru:

• generarea descrierilor tehnice ale articolelor în limbaj juridic-economic corect, pornind de la nomenclatorul standard;
• formularea răspunsurilor la solicitările de clarificare ale comisiei, pornind de la documentația ofertei;
• traducerea documentelor de licitație din alte limbi UE.

LLM-ul nu rulează niciodată pentru:

• calculul oricărei valori monetare;
• aplicarea oricărei reguli de validare;
• decizia despre încadrarea unui articol în capitol;
• alegerea cotei TVA;
• generarea de cantități sau prețuri unitare.

Linia este clară pentru noi: limbajul este responsabilitatea LLM-ului, aritmetica și legalitatea sunt responsabilitatea engine-ului determinist. Ofertantul citește ieșirea finală ca pe un singur document, dar arhitectura subiacentă păstrează fiecare componentă în zona ei de competență.

Ce înseamnă asta pentru un ofertant care evaluează software-ul

Trei întrebări pe care le recomandăm înainte de orice achiziție de software de devize:

1. „Reproduce exact același rezultat la fiecare apelare?” Cereți să rulați aceeași intrare de două ori și să comparați ieșirile la nivel binar, nu doar vizual. Orice diferență este un semnal de alarmă.

2. „Folosiți Decimal sau floating point?” Floating point pentru valori monetare în deviz este o problemă latentă care apare la verificare. Decimal cu rotunjire explicită este standardul.

3. „Aveți audit trail per regulă?” La o respingere în comisie, ofertantul are nevoie să vadă exact care regulă a fost aplicată și ce normă a folosit. Un mesaj de eroare generic („deviz invalid”) nu este suficient pentru contestație.

Concluzie operațională

Pentru calcule legal-deterministe, engine-ul determinist nu este un fallback conservator pentru clienți care nu „înțeleg AI”. Este alegerea corectă, susținută de însăși natura sarcinii. AI-ul are loc în Bid365 — la generare lingvistică, traducere, asistență de redactare. Nu are loc în calculul matematic care trebuie să se reconstituie identic la audit.

Această disciplină arhitecturală este dificilă în public față de un competitor care promite „AI peste tot”. În producție însă, ofertanții care au pierdut o licitație din cauza unei erori de un ban pe T4 înțeleg imediat de ce.

Articole conexe

• Anti-halucinare în chatbot juridic românesc
• Pillar Bid365 — platforma CAI Technology pentru achiziții publice
• Arhitectura propose-then-act pentru agenți AI în producție

Surse externe

• Hotărârea Guvernului 907/2016 — versiunea consolidată (Legislație gov)
• Standardul IEEE 754 pentru aritmetică în virgulă mobilă — pentru context tehnic
• Documentația Python decimal — ROUND_HALF_UP
• Agenția Națională pentru Achiziții Publice (ANAP) — autoritatea de reglementare
• Manualul Procurement Practitioner — World Bank Group (referință internațională procurement public)

Următorul pas

Dacă echipa dumneavoastră lucrează pe oferte de procurement public și vreți o evaluare tehnică a engine-ului Bid365 pe un deviz real, vă oferim o consultație tehnică de 30 de minute fără cost.