158 de agenți AI pe o singură ofertă SEAP: anatomia unui pipeline procurement
O ofertă SEAP nu se rezolvă cu un prompt mare la GPT. În Bid365 sunt 158+ agenți specializați pe 6 sisteme cu QA dual-pass și 11 puncte HITL. Iată arhitectura și de ce contează.
158 de agenți AI pe o singură ofertă SEAP: anatomia unui pipeline procurement
Întrebarea pe care o primim cel mai des de la directori IT din firme mari: “De ce vă trebuie 158 de agenți AI? GPT-5 nu poate să citească documentația și să scrie oferta?”
Răspunsul tehnic onest este: GPT-5 sau Claude Opus 4.7 poate să scrie ceva. Dar acel “ceva” nu va trece de evaluatorul juridic al unei autorități contractante din SEAP. Nu va respecta art. 210 din Legea 98/2016. Nu va lega cantitatea de echipă cu graficul de execuție. Și, când evaluatorul cere o contestație tehnică pe scoringul matematic, prompt-ul mare cade — pentru că nu are urmărirea cerinței la răspuns.
Bid365 este platforma noastră de automatizare a achizițiilor publice românești. Acest articol explică de ce arhitectura noastră are 158+ agenți specializați pe 6 sisteme, cum se coordonează între ele, și ce trade-off-uri am acceptat conștient.
TL;DR
- O ofertă SEAP completă are trei plicuri (administrativ, tehnic, financiar) cu zeci de cerințe interdependente. Un singur LLM nu poate menține consistența cross-document.
- 158+ agenți specializați în Bid365, grupați pe 6 sisteme: OF2 (oferte), CS (caiete sarcini), SF (studii fezabilitate), PT (proiecte tehnice), CK (checker integritate), Devize HG907.
- QA dual-pass: deterministic + semantic. 11+ HITL gates obligatorii (un om aprobă fiecare decizie ireversibilă).
- Trade-off acceptat: latență mai mare (10-30 min per ofertă completă) în schimbul unei calități verificabile și a unei audibilități complete.
De ce un singur LLM nu e suficient
O ofertă SEAP pentru o lucrare de construcție mediu-complexă (300.000 EUR) conține tipic:
- 60-90 de cerințe în Caietul de Sarcini, fiecare cu propria condiție de admisibilitate.
- 12-25 de cerințe legale (art. 164 Legea 98/2016, declarații DUAE, certificate ANAF, etc.).
- Propunere financiară cu deviz HG 907/2016 + Anexa 8 (43 capitole, ~150 articole de deviz).
- Echipă cu 8-15 experți, fiecare cu CV-uri verificate.
- Grafic de execuție Gantt pe 6-18 luni.
- Aproximativ 100-200 de pagini de documente, plus anexe.
Dacă scrii toate astea într-un singur prompt și ceri unui LLM să rezolve, primești ce se cheamă output plauzibil. Adică un text care arată bine, dar la verificare punctuală cade — de pildă cantitatea totală din devizul F3 nu se potrivește cu graficul fizic-valoric F6, sau experții propuși nu acoperă toate cerințele de personal cheie.
Problema nu e capacitatea LLM-ului, ci faptul că orice ofertă serioasă conține constrângeri interdependente care nu pot fi rezolvate într-o singură trecere. Schimbi o cantitate, trebuie să schimbi recap-ul, fluxul de numerar, graficul fizic-valoric, și uneori echipa. Un orchestrator multi-agent gestionează acele interdependențe explicit, prin grafuri de dependență; un prompt monolit le ignoră.
Cele șase sisteme
Bid365 operează șase sisteme de agenți, fiecare independent dar orchestrat dintr-un nivel de coordonare central.
OF2 — Generator oferte (31 agenți, 9 layere)
Este sistemul flagship. Generează automat oferte complete în structura SEAP cu trei plicuri.
L0 — Orchestrator master
L1 — Input și analiza
OF2-02 Intake avansat (extragere cerințe CS)
OF2-03 Agentic RAG (consultă 9 colecții vectoriale)
OF2-04 Project reconstructor
L2 — Evaluare și intelligence
OF2-05 Gap analysis ────► HITL gate (GO / NO-GO)
OF2-06 Scoring reverse engine
OF2-07 Competition simulator (3 profiluri ofertanți)
OF2-30 Expert legislație fiscal-financiară
OF2-31 Expert legislație achiziții publice
L3 — Strategie
OF2-08 Strategy & win maximization ────► HITL gate
OF2-09 Compliance pre-check (ANAF)
L4 — Costuri
OF2-10 Cost engine real
OF2-11 Market price validator
OF2-12 Margin strategy optimizer
L5 — Generare conținut (paralel)
OF2-13 Propunere tehnică
OF2-14 Propunere financiară
OF2-15 Echipă și profile experți
OF2-16 Grafic și metodologie
OF2-17 Documente și declarații
L6 — Scoring
OF2-18 Mathematical scoring engine
OF2-19 Scoring optimizer (iterativ)
L7 — Evaluare simulată (paralel)
OF2-20 Eval committee orchestrator
OF2-21 Evaluator tehnic strict
OF2-22 Evaluator financiar
OF2-23 Evaluator juridic
OF2-24 Evaluator sceptic (adversarial)
L8 — QA și asamblare
OF2-25 Meta supervisor (consistență cross-agent)
OF2-26 QA global enhanced (10 dimensiuni)
OF2-27 Stress test & Monte Carlo
OF2-28 Compilare ofertă (3 plicuri SEAP)
OF2-29 Critic & self-optimization ────► HITL gate
└─ loop max 3 iterații dacă scor < 85%Observați designul: layers L1-L4 fac analiza și strategia, L5 generează în paralel pe cinci dimensiuni distincte, L6-L7 fac scoring și auto-evaluare adversarială, L8 face asamblarea finală. La trei puncte (gap analysis, strategy, critic final) un om validează și autorizează continuarea.
CK — Checker integritate (20 agenți, 9 layere)
Stă deasupra tuturor celorlalte sisteme. Funcționează în trei moduri: contestație (atunci când ofertă pierde și clientul vrea să conteste), apărare (când clientul e contestat), audit complet (verificare procedură la solicitarea autorității contractante).
CK-04 Document Normalizer construiește un Unified Document Model. CK-05 Requirement Graph Builder transformă CS-ul într-un graf orientat de cerințe. CK-06 Traceability verifică, prin similaritate semantică, că fiecare cerință CS are un răspuns explicit în ofertă. CK-10 Collusion Detector caută zece indicatori de coluziune (oferte cu pattern-uri identice, tarifare anormală, beneficiari finali corelați). CK-18 CNSC/Court Outcome Simulator rulează 500 de scenarii Monte Carlo pentru a estima probabilitatea de admitere a contestației.
CS, SF, PT — Generatoare de documentație tehnică
CS (Caiete de Sarcini) — 20 de agenți pe șapte layere. Generează caiete de sarcini valide quad-dimensional (tehnic, juridic, piață, istoric).
SF (Studii de Fezabilitate) — 17 agenți pe cinci layere. Generează SF/DALI cu ACB complet conform HG 907/2016.
PT (Proiecte Tehnice) — 15 agenți pe cinci layere. Generează proiecte tehnice IT și construcții.
Devize HG907 — engine pur computațional
Acesta este intenționat fără LLM — engine pur computațional cu Decimal ROUND_HALF_UP la două zecimale. Generează devize 100% conform HG 907/2016 + Anexa 8 + Codul Fiscal art. 220¹. Produce DOCX, XLSX cu formule live, PDF.
De ce fără LLM? Pentru că o eroare de leu pe un deviz de 300.000 EUR poate descalifica oferta. Aritmetica financiară nu poate fi încredințată unui model probabilistic. EligibilityRouter decide dacă licitația cere HG907 (lucrări) sau e suficient un centralizator simplu (servere, software). LegalValidator are 14 reguli de validare (hg907.*, math.*, fiscal.*, anexa8.*).
Verificat E2E pe oferte reale: pipeline-ul reproduce la leu exact recap-ul F3 — T1 = 13.750,84 → T4 = 16.530,76 → Total cu TVA 316.762,97. Toate 14 reguli PASS.
Coordonare prin niveluri
Toate cele șase sisteme se coordonează printr-o ierarhie de patru niveluri:
Nivel 1 — Coordinator. Orchestratorul master OF2-01 (sau echivalent în alte sisteme) gestionează graful de dependențe între agenți. Decide ce rulează când, ce input intră în ce agent, când dă mâna la un HITL gate.
Nivel 2 — Generator. Agenții care produc conținut efectiv: propuneri tehnice, financiare, declarații, grafice. Fiecare specializat pe o singură dimensiune.
Nivel 3 — Validator. Agenții care verifică ce a produs nivelul 2. Validatori juridici, tehnici, financiari, sceptici (adversarial — caută activ probleme). Pe Bid365 avem 40+ agenți QA dedicați.
Nivel 4 — HITL gate. Punctul în care decizia se ridică la un operator uman. Cele 11 gate-uri sunt: GO/NO-GO post-gap-analysis, validare strategie, validare cost, alegere variantă echipă, aprobare grafic execuție, validare prețuri piață, decizie iterare critic, semnătura propunere tehnică, semnătura propunere financiară, semnătura DUAE, depunere finală.
Nimeni la noi nu crede că un AI poate semna o ofertă SEAP în numele unei firme. Operatorul își păstrează responsabilitatea juridică; AI-ul îi reduce timpul de lucru de la zile la minute, păstrând trasabilitatea fiecărei decizii.
RAG-AGI+ v2.0 — straturile de cunoaștere
Toți agenții consumă cunoaștere prin pipeline-ul nostru hybrid RAG. Stack open-source modern: vector database, embedding multilingv 1024-dimensional, retrieval hybrid dense + sparse cu RRF (Reciprocal Rank Fusion), CRAG (corrective RAG), HyDE (Hypothetical Document Embeddings), reranker pe rezultate.
Volumul cunoștințelor:
- 300.000+ vectori indexați pe opt colecții.
- 2.8M+ documente juridice (legislație + Monitor Oficial + ICCJ + CNSC).
- 32.097 licitații monitorizate (PNRR 19.807 + Fonduri UE 1.167 + SEAP 11.047 + TED 76).
- 8.000+ beneficiari publici cu enrichment automat din ONRC + ANAF.
Pipeline-ul rulează cron zilnic: 04:00 fetch PNRR, 04:30 FUE, 02:30 SEAP delta 30 zile, 03:30 TED România, 05:00 lifecycle manager, 06:00 atribuire + firmă câștigătoare, 07:00 ingestion documente noi în vector DB.
Trade-off-urile pe care le-am acceptat
Latență mai mare. O ofertă completă rulează 10-30 minute end-to-end (depinde de dimensiunea CS-ului). Un prompt mare la GPT poate produce un draft în 2-3 minute. Trade-off-ul valorează: timpul economisit la verificare manuală a unei oferte cu 158 de agenți < timpul economisit la verificare manuală a unei oferte cu un LLM monolit, deoarece la noi verificarea finală e directă (HITL gates au verificat deja punctele cheie).
Cost compute mai mare. 158 de agenți × ~100K tokens medie = ~15M tokens per ofertă. La modele open-source rulate local (stack-ul nostru folosește modele LLM open-source rulate pe infrastructura noastră EU-resident), cost per token e mult sub piața externă. La GPT-4 / Claude pe API, ar fi prohibitiv.
Complexitate de mentenanță. 158 de agenți înseamnă 158 de prompt-uri de actualizat când o lege se schimbă. Avem un sistem de versionare a prompt-urilor cu testare regresivă pe oferte istorice. Schimbarea Legii 98/2016 prin OUG 19/2024 a necesitat update la 23 de prompt-uri; testele regresive au prins 4 incompatibilități în primul rulou.
Dependență de HITL operatori formați. Un operator care apasă “approve” la toate HITL gate-urile fără să citească = un sistem mai prost decât un LLM monolit. Investim în formarea operatorilor: instruire de două zile pe arhitectura pipeline-ului, ce să verifice la fiecare gate, ce e flag roșu.
Pattern multi-agent vs prompt monolitic
Pe scurt, când să folosiți multi-agent vs un singur LLM mare?
Folosiți multi-agent când:
- Output-ul are constrângeri interdependente verificabile mecanic (deviz, scoring, conformitate juridică).
- Există puncte unde un om trebuie să decidă (GO/NO-GO, alegere variantă).
- Aveți nevoie de audibilitate completă (cine ce a decis, când, cu ce input).
- Calitatea contează mai mult decât viteza de prim-draft.
Folosiți prompt monolitic când:
- Output-ul e descriptiv sau creativ (un email, un articol, un rezumat).
- Verificarea finală e oricum manuală pe text liber.
- Nu există constrângeri matematice sau juridice care să creeze incompatibilități între părți ale output-ului.
Bid365 e clar în prima categorie. Un articol de blog (cum e acesta) e clar în a doua.
Articole conexe
- Engine deviz HG907 fără LLM: precizie determinist-legală
- Propose-then-act: arhitectura unui agent AI pentru ops production
- Citation grounding: implementare pipeline cu 4 porți
- Cost-aware LLM routing: cum reduci 70% factura păstrând calitatea
- Pillar Bid365 — automatizare achiziții publice
Pași următori
Dacă firma dvs. lucrează cu SEAP, PNRR sau Fonduri UE și vreți să evaluați automatizarea pipeline-ului de ofertare — pe pagina Bid365 găsiți specificațiile complete, demo live, și plan de pilot 30 de zile. Sau scrieți la contact pentru o discuție tehnică.
Articole adiționale: Hardening pre-producție (cum testăm intern platformele înainte de producție) · Pagina Bid365 · Pagina Iris (orchestratorul AI care coordonează agenții).