Cerințele C.4 punct cu punct
Fiecare punct și subpunct din descrierea tehnică C.4, în ordinea documentului: textul cerinței, starea, locul exact din platformă unde se găsește, rolul cu care se demonstrează și legătura la descrierea detaliată.
Legendă: funcțional implementat și demonstrabil azi · parțial implementat parțial sau cu limitări (explicate în fiecare punct) · în afara livrării componentă C.4 care nu face parte din livrarea noastră (CRM, billing, hardware, resurse de stocare); este listată pentru completitudine, fără afirmații despre ea.
Livrarea acoperă cele 5 sisteme software din C.4: Data Augmentation – Tagging, Human-Attention and Moderation Demand Fulfillment Marketplace, Training and Operating Model Factory, Core Stack Artificial Intelligence HUB și Librărie Algoritmi (inclusiv cele 2 aplicații practice). Conturile demo pentru fiecare rol se obțin de la administratorul platformei.
| Capitol C.4 | funcțional | parțial | în afara livrării |
|---|---|---|---|
| Ecosistemul HUB IA | 1 | – | – |
| Tipurile de utilizatori | 13 | – | – |
| Procesul de funcționare al HUB IA | 11 | 2 | – |
| Beneficiile principale | 4 | 1 | – |
| Aplicațiile / sistemele software ale HUB IA | 5 | – | 2 |
| Caracterul inovativ al platformei | 6 | 3 | – |
| Arhitectura logică și fizică | 1 | – | 3 |
| 1. Aplicația Data Augmentation – Tagging | 39 | 2 | – |
| 2. Aplicația Human-Attention and Moderation Demand Fulfillment Marketplace | 10 | – | – |
| 3. Aplicația Training and Operating Model Factory | 18 | – | – |
| 4. Sistemul informatic Core Stack Artificial Intelligence HUB | 6 | – | – |
| 5. Sistemul informatic Librărie Algoritmi | 27 | 4 | – |
| 6. Sistem CRM | – | – | 1 |
| 7. Aplicația software billing | – | – | 1 |
| Resursele de stocare | – | – | 1 |
| Cerințe de integrare | 3 | 1 | – |
| Total puncte și subpuncte | 144 | 13 | 8 |
- Ecosistemul HUB IA
- Tipurile de utilizatori
- Procesul de funcționare al HUB IA
- Beneficiile principale
- Aplicațiile / sistemele software ale HUB IA
- Caracterul inovativ al platformei
- Arhitectura logică și fizică
- 1. Aplicația Data Augmentation – Tagging
- 2. Aplicația Human-Attention and Moderation Demand Fulfillment Marketplace
- 3. Aplicația Training and Operating Model Factory
- 4. Sistemul informatic Core Stack Artificial Intelligence HUB
- 5. Sistemul informatic Librărie Algoritmi
- 6. Sistem CRM
- 7. Aplicația software billing
- Resursele de stocare
- Cerințe de integrare
Ecosistemul HUB IA
Scopul proiectului este crearea unui ecosistem digital dedicat atat Inteligentei Artificiale cat si interactiunii intre mai multe tipuri de utilizatori (prezentati mai jos). Acest ecosistem va functiona sub forma unui HUB ce va asigura interactiunea digitala, logica si comerciala a proceselor si utilizatorilor mecanismelor de Inteligenta artificiala.
Unde se află: onprem.ai-hub.cloud (portalul), plus instrumentele deschise din meniul Instrumente AI Hub: Data Studio, MLOps, MLflow, BI, analiză video, senzori, identificare biometrică, API.
Rol: oricare. Detalii: Prezentare generală, Arhitectură.
Tipurile de utilizatori
Utilizatorul de rezultat. Este de regula un operator economic ce are o solicitare concreta de aplicare a metodelor de estimare Machine Learning pentru unele din fluxurile sale de lucru. Exemplu: Un lant de magazine supermarket doreste sa identifice 3 tipuri de produse (legume, patiserie si lactate) in fluxurile de imagine video transmise de camerele video montate deasupra caselor de marcat. Pe langa identificarea acestor 3 tipuri de produse, Utilizatorul de rezultat mai poate primi si date statistice corelate precum: de cate ori a fost identificat tipul de produs pe un interval de timp, de cate ori au fost identificate unul sau mai multe din cele 3 tipuri de produse intr-o singura imagine, etc.
Unde se află: rolul Result User în portal: My projects → New Project, aprobări, Wallet. Pentru exemplu: detecția de obiecte cu parametri (produse, raft, sticle; numărul de obiecte pe clasă într-o imagine) și aplicația video (evenimente și numărări pe interval de timp, pe fișiere și camere).
Rol: Result User. Detalii: Fluxuri → Result User, Librărie → obiecte, Analiza video.
Augumentator de date. Este acel utilizator care identifica, marcheaza si eticheteaza pentru un caz pus la dispozitie, acele elemente care sunt cerute de catre Utilizatorul de rezultat. Exemplu: Pentru solicitarea exemplificata la punctul 1. De mai sus, Augumentatorul de date va identifica din setul de imagini primite cele 3 tipuri de produse (legume, patiserie si lactate). Pentru fiecare imagine in parte Augumentatorul de date va marca dupa reguli specifice impuse de interfata HUB IA, acea bucata de imagine care reprezinta unul din cele 3 tipuri de produse.
Unde se află: rolul Data Augmentator: contractele din Invited / My Projects, time log-ul, butonul AI Hub Data Studio; în Data Studio, interfețele de etichetare cu reguli impuse (ex. proiectul 203 „Rafturi și frigidere – produse și relații”).
Rol: Data Augmentator. Detalii: Data Augmentation → geometric-categoric, Fluxuri → Data Augmentator.
Augumentatorul de date va putea stabili un pret pentru ora de augumentare (identificare, marcare si etichetare).
Unde se află: Data Augmentator → profil → cardul „Tarif pe oră de augmentare” (USD/oră; demo: 12 USD/oră). Training Operator vede tariful când alege augmentatorul în formularul sesiunii; tariful pornește negocierea și intră în cotație.
Rol: Data Augmentator. Detalii: Fluxuri → Data Augmentator, Marketplace → negociere.
Furnizorul de date. In cazul in care Utilizatorul de rezultat nu detine baza de date proprie cu imagini care contin cele 3 tipuri de produse se poate apela la un Furnizor de date care detine un set de imagini corespunzator. Furnizorul de date ales, pune la dispozitia Augumentatorului de date setul de imagini pentru a fi utilizate pentru identificare, marcare si etichetare a tipurilor de produse.
Unde se află: rolul Data Supplier: Data Set Form, List of Data sets; seturile apar în Marketplace pentru Result User / Project Admin / Training Operator, care le sugerează și le închiriază pe proiect. Furnizorul are acces la proiectele de etichetare ale propriilor seturi.
Rol: Data Supplier. Detalii: Fluxuri → Data Supplier.
Sistemul HUB IA va permite furnizorilor de date sa asigure seturile de date astfel: fie pe serverele proprii ale acestora, HUB IA accesand setul de date printr-o extensie software instalata pe acesta;
Unde se află: extensia „AI Hub dataset server” (container instalat la furnizor): servește fișierele doar pe linkuri semnate HMAC, cu termen de 15 minute, și raportează traficul înapoi la AI Hub (cu coadă locală când AI Hub nu răspunde). Data Supplier → meniul Dataset Servers (înregistrare + Verifică) → Data Set Form, Storage Type „Personal”, serverul și calea fișierului. Demo: setul „Înregistrări audio stereo – găzduite la furnizor (extensia AI Hub)”, descărcat real (33,7 MB, raport complete:true).
Limitare: instanța demo supplier-demo.onprem.ai-hub.cloud simulează serverul unui furnizor (rulează ca un container separat pe serverul AI Hub); nu există reluare (Range) a descărcărilor întrerupte.
Rol: Data Supplier. Detalii: Data Augmentation → furnizori.
fie pe serverele HUB IA.
Unde se află: Storage Type: AI Hub Cloud Storage (încărcare arhivă), cu crearea automată a proiectului Data Studio; 5 seturi C.4 încărcate de Data Supplier.
Rol: Data Supplier. Detalii: Data Augmentation → flux.
Furnizorul de date va putea stabili un pret pentru traficul realizat in vederea preluarii setului de date pentru augumentare (identificare, marcare si etichetare).
Unde se află: Data Set Form → „Preț trafic (USD / GB)”. Fiecare descărcare prin linkul semnat este contorizată (octeți efectiv trimiși, de backend sau de extensia furnizorului); traficul și costul apar la furnizor („Traseul datelor”), pe proiect („Trafic de date măsurat pe proiect”) și în cotație. Exemplu real: 33,7 MB la 0,50 USD/GB = 0,0168 USD.
Limitare: prețurile sunt valori demo; descărcările prin alte căi decât linkul semnat (de ex. citirea din Data Studio) nu sunt contorizate.
Rol: Data Supplier. Detalii: Data Augmentation → furnizori.
Procesul de furnizare date va fi monitorizat pentru urmarirea traseului datelor utilizate si returnarea acestora catre proprietar.
Unde se află: pagina setului la Data Supplier → „Traseul datelor”: descărcări (cine, când, proiect, octeți), închirieri începute și încheiate, acces Data Studio acordat sau retras, trafic și cost pe proiect. La End Rent, AI Hub retrage accesul membrilor care nu mai primesc setul pe altă cale; arhivele nu mai sunt publice (doar linkuri semnate, contorizate).
Accesul în Data Studio este retras automat de sincronizarea platformei (în câteva minute de la încheierea închirierii); un membru care are acces și prin alt proiect sau altă închiriere îl păstrează.
Rol: Data Supplier, Result User. Detalii: Data Augmentation → furnizori.
Operatorul de Antrenare. Este utilizatorul care urmareste si gestioneaza procesul de alegere set de date, alegere Furnizor de date (daca este cazul), stabilirea criteriilor de impartire a setului de date pe numar de ore de augumentare, distribuirea catre Augumentatorii de date, stabilirea si alegerea Metodelor de estimare Machine Learning parametrizate pe nevoile Utilizatorului de rezultat, alegerea resurselor GPU necesare, urmarirea procesului de antrenare a metodelor de estimare Machine Learning pe setul de date marcat si etichetat, furnizarea Metodei de estimare catre Utilizatorul de rezultat.
Unde se află: rolul Training Operator: Datasets (alegere seturi și furnizori), Augmentation Sessions (împărțirea pe sesiuni cu buget și termen, invitarea augmentatorilor), Development Request (metoda ML), Request Resources (GPU), MLOps și MLflow (urmărirea antrenării), modelele aprobate de Result User.
Rol: Training Operator. Detalii: Fluxuri → Training Operator.
Operatorul de antrenare poate fi intern oferit de operatorul HUB IA sau extern functionand ca terta parte.
Unde se află: rolul este atribuit unui cont oarecare și invitat pe proiect (Invite Training Operator); nu presupune apartenența la operatorul platformei.
Rol: Result User, Project Admin.
Dezvoltatorul de Model de estimare Machine Learning. Modelul de estimare Machine Learning este acel model parametrizat care aplicat pe un set de date augumentat (marcat si etichetat), se antreneaza pentru a intoarce rezultatul dorit cu gradul de acuratete dorit. Exemplu: Modelul de estimare Machine Learning care se antreneaza pe un set de imagini in care a fost marcat si etichetat orice mar prezent. Odata antrenat Modelul de estimare va putea recunoaste un mar intr-o imagine cu o acuratete de 70%.
Unde se află: rolul ML Model Developer: cereri de dezvoltare, ML Model List, MLOps, MLflow. Exemplul cu mărul: detectorul de obiecte are clasa „Apple / măr”.
Rol: ML Model Developer. Detalii: Fluxuri → ML Model Developer, Librărie → obiecte.
Un dezvoltator de metode de estimare va putea folosi HUB IA pentru a isi antrena aceste metode iar odata obtinute rezultatele, fie sa publice Modelul in libraria HUB IA, fie sa il utilizeze in aplicatii proprii in afara HUB IA.
Unde se află: antrenare pe GPU prin ZenML; publicare în registrul MLflow și în ML Model List din portal; utilizare externă prin artefactele descărcabile (safetensors, ONNX, predict.py) și prin API-ul de inferență.
Rol: ML Model Developer. Detalii: Librărie → registru, Core Stack → API.
Daca acest utilizator publica Modelul de estimare in libraria HUB IA , va putea stabili un pret pentru utilizarea acestuia de catre alti utilizatori.
Unde se află: formularul de model ML, câmpul Initial Budget Request, afișat ca Price pe cardul modelului (ex. Whisper RO v2: 1.200; Gemma call-center: 900).
Rol: ML Model Developer. Detalii: Model Factory → model ML.
Procesul de funcționare al HUB IA
HUB IA poate rula simultan procese individuale pentru fiecare utilizator in parte.
Unde se află: proiecte independente cu echipe proprii (Whisper RO, Gemma extracție, Gemma call-center, Augmentare C.4, în paralel); rulări GPU simultane pe GPU-uri diferite.
Rol: oricare. Detalii: Fluxuri pe roluri.
Pas 1: Utilizatorul de rezultat acceseaza interfata HUB IA si furnizeaza rezultatele dorite, acuratetea necesara si setul de date detinut;
Unde se află: New Project: nume, descriere, livrabil, termen, buget, setul propriu și câmpul „Acuratețe necesară” (metrică, ≥ / ≤, valoare). Pe proiect, ținta se poate stabili sau modifica; cardul fiecărui model ML o compară cu metrica reală din MLflow: „Ținta proiectului este atinsă / nu este atinsă” (ex. proiectul de extracție: țintă F1 ≥ 95%, modelul are 94,9% → „nu este atinsă”).
Rol: Result User. Detalii: Fluxuri → Result User.
Pas 2: Operatorul de antrenare analizeaza informatiile furnizate de catre Utilizatorul de rezultat si face o estimare de numar de ore necesare pentru augumentare (identificare, marcare si etichetare);
Unde se află: formularul sesiunii de augmentare (Training Operator): câmpul „Ore de augmentare estimate” se completează automat din task-urile rămase în Data Studio × mediana timpului măsurat pe task, cu durata în săptămâni la disponibilitatea prognozată (aceeași logică ca BI, întrebarea 16).
Limitare: estimarea există doar pentru seturile cu task-uri în Data Studio și un ritm măsurat; ritmul provine în mare parte din adnotări demo făcute de agenți, deci este optimist.
Rol: Training Operator. Detalii: Marketplace → estimare.
Pas 3: Operatorul de antrenare alege, daca este cazul, seturi de date de la furnizori de date;
Unde se află: Datasets / Marketplace → sugerare pe proiect; Result User aprobă; setul apare la „Rented Datasets”.
Rol: Training Operator, Result User. Detalii: Fluxuri → Training Operator.
Pas 4: Operatorul de antrenare mediaza pretul pe ora cu Augumentatorii de date interesati prin intermediul interfetelor HUB IA;
Unde se află: panoul „Tarif orar de augmentare” pe pagina sesiunii (Training Operator) și pe contract (Data Augmentator): propunere → acceptare sau contraofertă → acceptare, cu notificări și istoric; tariful convenit rămâne pe contract. Exemplu real (sesiunea SWIR): propus 10,00 → contraofertă 11,50 → acceptat 11,50 USD/oră.
Rol: Training Operator, Data Augmentator. Detalii: Marketplace → negociere.
Pas 5: Operatorul de antrenare alege Modele de estimare Machine Learning si alege setul de parametrii necesari. Totodata stabileste numarul de ore de procesare GPU necesare;
Unde se află: Development Request către ML Model Developer; Request Resources (CPU, RAM, GPU, stocare, ofertă de preț, descriere cu orele GPU). Exemplu real: „6× NVIDIA A40 48 GB, ~20 rulări, ~30 ore GPU”, aprobată.
Rol: Training Operator, Project Admin. Detalii: Model Factory → proiecte și cereri.
Pas 6: Preia cotatia estimata de HUB IA, o verifica si o transmite Utilizatorului de rezultat. Cotatia va contine numarul de ore necesar pentru augumentare, traficul estimat pentru preluarea setului de date de la furnizorul de date (daca este cazul), tariful pentru model de estimare Machine Learning ce poate fi antrenat si numarul de modele disponibile, numarul de ore procesare GPU necesare pentru antrenare fiecare model de estimare Machine Learning;
Unde se află: proiect → panoul „Cotație” → Generează (Training Operator): AI Hub calculează din datele reale orele de augmentare × tariful convenit, traficul de date × prețul furnizorului, tarifele și numărul modelelor ML, orele GPU reale ale rulărilor MLflow ale proiectului × prețul orei GPU; Trimite către Result User; documentul /quotation/<id> se poate printa sau salva PDF. Exemplu real (Whisper): revizia 1, 2.869,26 USD.
Rol: Training Operator, Result User. Detalii: Marketplace → cotație.
Pas 7: Utilizatorul alege componentele din cotatia dorita si emite comanda prin interfata pusa la dispozitie de HUB IA. Totodata, va efectua plata serviciilor comandate;
Unde se află: Result User → documentul cotației → Acceptă (comandă) sau Respinge (cu motiv); acceptarea este comanda. Exemplu real: revizia 1 a cotației Whisper, acceptată.
Limitare: plata efectivă nu face parte din livrare (aplicația de billing, în afara livrării); cotația spune explicit acest lucru.
Rol: Result User. Detalii: Marketplace → cotație.
Pas 8: Se incepe antrenarea Modelelor de estimare Machine Learning ales de Utilizatorul de rezultat, in conformitate cu parametrii comenzii.
Unde se află: pipeline-urile ZenML pe GPU; fiecare rulare MLflow are tag-urile aihub_project_id / aihub_project_name (29 de rulări → proiectul Whisper, 13 → extracție, 7 → call-center).
Rol: Training Operator, ML Model Developer. Detalii: Model Factory → MLOps.
Pas 9: Daca pe parcursul antrenarii modelului de estimare Machine Learning se constat necesitatea suplimentarii orelor de procesare, augumentare sau setului de date, pentru a se obtine o acuratete mai buna a rezultatului, se completeaza cotatia existenta, se confrunta Utilizatorul de rezultat si se completeaza comanda acestuia.
Unde se află: după o cotație acceptată, o generare nouă creează revizia următoare, de tip „Suplimentare”, pe care Result User o aprobă; revizia anterioară devine „Înlocuită de o revizie nouă”, cu istoricul păstrat. Exemplu real (Whisper): revizia 2, +14,94 ore GPU, 3.317,46 USD, acceptată.
Rol: Training Operator, Result User. Detalii: Marketplace → cotație.
Pas 10: Odata antrenat se livreaza Modelul catre Utilizatorul de rezultat.
Unde se află: modelul ML propus („Send Suggestion”) și aprobat de Result User („Approved”), cu metricile reale; versiunea din registrul MLflow; servirea prin API; tichetul de suport real despre exportul on-prem al modelului Whisper; pachetul on-premise, cu care modelele livrate rulează pe serverul clientului.
Rol: ML Model Developer, Result User. Detalii: Fluxuri → model ML.
Pas 11: Sunt achitate tarifele catre Augumentatorul de date, Furnizorul de date si Dezvoltatorul de modele de estimare machine learning.
Unde se află: sumele datorate sunt evidențiate: la Data Augmentator (Balance, contracte cu tariful convenit), la ML Model Developer (Dashboard: venit, plată în așteptare), la furnizor (costul traficului în traseul datelor).
Limitare: achitarea efectivă a tarifelor ține de aplicația de billing, care nu face parte din livrare.
Rol: Data Augmentator, ML Model Developer, Data Supplier. Detalii: Fluxuri.
HUB-ul de Inteligenta Artificiala va fi o platforma care va permite interactiunea procedurizata si digitalizata pentru toate tipurile de utilizatori mentionate mai sus si va crea astfel ecosistemul necesar pentru accelerarea dezvoltarii inteligentei artificiale.
Unde se află: fluxurile de proiect cu 27 de pași urmăriți (stadiul proiectului în procente), notificări cu Accept/Reject, chat, tichete.
Rol: toate. Detalii: Fluxuri pe roluri.
Beneficiile principale
gestionarea eficienta si transparenta la nivel digital si comercial intre tipurile de utilizatori mentionate mai sus;
Unde se află: cererile și aprobările din portal, bugetele vizibile pe proiect și în Wallet, auditul automat (BI dashboard-ul 4), costul și energia per proiect (BI dashboard-ul 5).
Rol: Result User, Project Admin. Detalii: Marketplace → audit.
crearea mediului pentru asigurarea seturilor de date necesare pentru antrenarea modelelor de estimare Machine Learning;
Unde se află: Data Set Form, Marketplace, Data Studio (9 formate C.4, proiectele 203–211).
Rol: Data Supplier, Training Operator. Detalii: Data Augmentation.
Crearea mediului de lucru pentru dezvoltatorii de modele de estimare machine learning;
Unde se află: MLOps (ZenML), MLflow, GPU NVIDIA A40 prin cereri de resurse, API de inferență.
Rol: ML Model Developer. Detalii: Model Factory.
Crearea unei librarii de modele de estimare Machine Learning permanent antrenate. Modelele de estimare Machine Learning se vor antrena la fiecare solicitare ale unui utilizator si astfel se vor imbunatatii permanent. Exemplu: Doi Utilizatori de rezultat solicita identificarea unui tip de produs pe doua seturi de date diferite. Modelul de estimare Machine Learnig se va antrena pe ambele seturi de date si va furniza ambilor utilizatori o acuratete mai buna, cand al treilea Utilizator de rezultat va solicita antrenarea modelului de estimare pentru acelasi tip de produs, dar pe un set propriu de imagine, va beneficia din start de o acuratete mult imbunatatita;
Unde se află: serviciul de re-antrenare declanșată de evenimente urmărește backend-ul (sesiuni „Ready to use”, seturi închiriate, cereri de dezvoltare) și Data Studio (adnotări noi), pornește pipeline-ul proiectului pe GPU, înregistrează versiunea nouă în MLflow și o propune în portal, cu o poartă de calitate. Exemplu real: 26 de corecturi umane din Data Studio 163 → whisper-ro v4 (mai slab, WER 5,81 → 6,79, marcat „quality_gate: failed”, respins) → whisper-ro v5 (WER 5,81 → 5,62, aprobat de Result User). Jurnal: GET https://api.onprem.ai-hub.cloud/v1/retrain/events. Efectul cumulării seturilor: Whisper small pe CV / FLEURS / VoxPopuli separat are WER mediu 18,1 / 24,0 / 15,5%, pe toate trei 11,9%.
Limitare: câștigul re-antrenării din corecturi pe date disjuncte e mic (WER FLEURS 8,71 → 8,42); setul de corecturi este mic (26).
Rol: ML Model Developer, Result User. Detalii: Model Factory → re-antrenare.
Solutia HUB IA va asigura standardele de securitate si confidentialitate a informatiilor, de prelucrare a datelor cu caracter personal conform Regulamentului (UE) 2016/679 privind protectia persoanelor fizice in ceea ce priveste prelucrarea datelor cu caracter personal si privind libera circulatie a acestor date si de abrogare a Directivei 95/46/CE (Regulamentul general privind protectia datelor).
Unde se află: autentificare unică cu acces pe roluri, HTTPS, audit automat cu mascarea datelor sensibile, anonimizare automată la încărcare (fețe estompate, EXIF/GPS eliminat, CNP/IBAN/telefon/e-mail/IP/nume mascate), arhive de date accesibile doar prin linkuri semnate, contorizate, biometrie procesată pe dispozitiv cu dreptul la ștergere, video cu fețe estompate și retenție de 30 de zile.
Limitare: nu există o evaluare formală de conformitate GDPR; câteva înregistrări vechi din jurnalul de audit nu au fost mascate retroactiv; numerele de înmatriculare și vocile nu sunt anonimizate.
Rol: oricare. Detalii: Arhitectură → securitate și date.
Aplicațiile / sistemele software ale HUB IA
Aplicatie Data Augmentation – Tagging. Are ca scop principal realizarea proceselor automate necesare augumentarii seturilor de date.
Unde se află: Data Studio, adaptoarele de format, pre-adnotarea cu modele (proiectul 163). Detalii: Data Augmentation – Tagging.
Aplicatie Human-Attention and Moderation Demand Fulfillment Marketplace. Are ca scop principal realizarea unei platforme de tip Marketplace pentru realizarea intre tipurile de utilizatori si gestionarea proceselor dintre acestia.
Unde se află: sesiunile de augmentare din portal, auditul, rapoartele de atenție umană. Detalii: Marketplace.
Aplicatie Training and Operating Model Factory. Are ca scop principal realizarea unei platforme de tip Marketplace care sa permita antrenarea modelelor de estimare machine learning.
Unde se află: portalul, MLOps, MLflow. Detalii: Model Factory.
Sistems informatic Core Stack Artificial Intelligence HUB. Are ca scop principal realizarea unei infrastructuri software pentru operationalizarea si interconectarea modulelor software ale HUB IA;
Unde se află: SSO, API-ul de inferență, exemplele de integrare. Detalii: Core Stack.
Sistem informatic Librarie Algoritmi. Are ca scop principal realizarea unei librarii initiale de modele de estimare Machine Learning care va fi completata ulterior cu noi modele rezultate din cerintele Utilizatorilor de rezultat. Libraria creata in cadrul proiectului HUB IA, va contine 6 modele de estimare Machine Learning si 2 aplicatii practice a unora dintre acestea, care au fost antrenate.
Unde se află: registrul MLflow; cele 6 modele cerute plus modelele adăugate din cererile utilizatorilor de rezultat (Whisper RO, Gemma call-center); aplicațiile video și biometrie. Detalii: Librărie.
Sistem CRM. Are ca scop principal gestionarea interactiunii cu si dintre utilizatorii HUB IA, cat si documentarea datelor furnizate si generate de acestia
Aplicatie software billing. Are ca scop principal implementarea capabilitatii de facturare a produselor catre utilizatorii HUB IA.
Caracterul inovativ al platformei
gestionarea eficienta si transparenta la nivel digital si comercial intre tipurile de utilizatori ai HUB IA, asa cum au fost mentionati si definiti in prezentul document;
Unde se află: cele 7 roluri cu meniuri proprii, cereri și aprobări, Wallet / Balance, audit. Detalii: Model Factory → roluri.
crearea mediului pentru asigurarea seturilor de date suficiente necesare pentru antrenarea modelelor de estimare Machine Learning, prin posibilitatea cumularii unor seturi mai mici de date de la mai multi utilizatori. La ora actuala o problema majora in dezvoltarea Inteligentei Artificiale este indisponibilitatea seturilor de date suficient de mari pentru antrenarea modelelor de estimare machine learning.
Unde se află: un proiect închiriază seturi de la mai mulți furnizori (proiectul C.4: seturi de la Data Supplier și Training Operator). Efect măsurat: Whisper small pe cele trei seturi cumulate are WER mediu 11,9%, față de 15,5–24,0% pe fiecare set separat.
Rol: Training Operator. Detalii: Rezultate → Whisper.
Crearea mediului de lucru pentru dezvoltatorii de modele de estimare Machine Learning prin punerea la dispozitia acestora, intr-o singura platforma a resurselor de augumentare, seturilor de date, resurselor de procesare si a unei modalitati de obtinere de venituri din vanzarea acestora. De multe ori dezvoltatorii de modele de Machine Learning nu pot testa modelul creat pentru ca nu dispun de resurse de augumentare, seturi de date, resurse de procesare. HUB IA incurajeaza dezvoltarea pietei Inteligentei artificiale prin generarea posibilitatii aparitiei competitiei intre dezvoltatori mici de modele de estimare Machine Learning si marile corporatii IT;
Unde se află: sesiuni de augmentare, Marketplace de seturi, GPU prin cereri de resurse, prețul modelului și venitul afișat în dashboard-ul ML Model Developer.
Limitare: veniturile sunt doar evidențiate (Pending Payment); încasarea ține de billing, în afara livrării.
Rol: ML Model Developer. Detalii: Fluxuri → ML Model Developer.
Crearea unei librarii de modele de estimare Machine Learning permanent antrenate. Modelele de estimare Machine Learning se vor antrena la fiecare solicitare ale unui utilizator si astfel se vor imbunatatii permanent. Exemplu: Doi Utilizatori de rezultat solicita identificarea unui tip de produs pe doua seturi de date diferite. Modelul de estimare Machine Learnig se va antrena pe ambele seturi de date si va furniza ambilor utilizatori o acuratete mai buna, cand al treilea Utilizator de rezultat va solicita antrenarea modelului de estimare pentru acelasi tip de produs, dar pe un set propriu de imagine, va beneficia din start de o acuratete mult imbunatatita;
Unde se află: ca la B4: serviciul de re-antrenare declanșată de evenimente, cu om în buclă și poartă de calitate (whisper-ro v4 respins, v5 aprobat), plus versiunile succesive din registrul MLflow.
Limitare: setul de corecturi folosit este mic; câștigul pe date disjuncte este mic.
Detalii: Model Factory → re-antrenare.
Versatilitate si acoperire a aproape tuturor segmentelor de piata. Utilizatorul de rezultat poate fi orice operator economic din orice domeniu si segment de piata, orice tip de institutie sau autoritate de stat, orice tip de ONG sau alt tip de organizatie. Singura conditie este sa existe o nevoie;
Unde se află: modelele librăriei acoperă vorbire, text, documente, imagini, video, biometrie și senzori agricoli; tipurile de date ale modelelor din portal (Computer Vision, Audio / Speech, Text / NLP, Tabular / Sensors). Detalii: Rezultate.
Avand in vedere ca tipurile de utilizatori pot folosi HUB IA pentru orice model de estimare Machine Learning, nu exista limita de aplicabilitate pentru un anumit domeniu. Exemple: Se poate antrena un model de estimare pentru citirea unor radiografii pe care le detine un spital (furnizor de date) pentru a identifica anumite tipuri de patologii, se poate antrena un model de estimare pentru a detecta anomalii de valori citite de senzori si a prezice un anumit efect, se poate antrena un model care sa identifice mimica fetei si sa estimeze starea de spirit;
Unde se află: anomalii la senzori cu predicția efectului: sensor-*; mimica feței și starea de spirit: face-expression (7 expresii; pe fețe reale validat neutru vs fericit 93,3%) și blendshapes MediaPipe în demo-ul biometric; radiografii: doar proiecte de test din 2023, fără model.
Limitare: expresiile, altele decât neutru/fericit, sunt învățate doar de pe avatari sintetici (performanța pe oameni reali nu e măsurată); nu există model medical.
Detalii: Librărie → senzori, Librărie → expresii.
Seturile de date utilizate in aceasta platforma pot fi procesate in conformitate cu normele GDPR. Exemplu: Furnizorul de date (Spital) care pune la dispozitie imagini cu radiografii, nu va pune la dispozitie si date de asociere cu o persoana, Furnizorul de date prin senzori nu va asocia si locatia GPS a acestora, Furnizorul de imagini cu persoane carora li se identifica starea de spirit nu va furniza si nume si alte elemente de identificare, etc.
Unde se află: anonimizarea automată la încărcare și la import (cron la 10 minute pe seturile noi; pipeline ZenML gdpr_anonymization_pipeline): fețele din imagini și cadre video sunt estompate ireversibil, EXIF-ul (inclusiv GPS) e eliminat, iar în text se maschează CNP, IBAN, telefoane, e-mail, adrese IP și nume de persoane (NER), cu aceeași lungime ca adnotările să rămână valide. Rezultate: 11 fețe în proiectul 203, 26 în 205, 1.467 de detecții în 206, 48 de IP-uri în 211; BI întrebările 25–26. Modelele de senzori nu folosesc locația.
Limitare: numerele de înmatriculare și vocile nu sunt anonimizate; fețele foarte mici pot scăpa detecției.
Detalii: Data Augmentation → GDPR.
Solutia HUB IA va asigura si impune standardele de securitate si confidentialitate a informatiilor, de prelucrare a datelor cu caracter personal conform Regulamentului (UE) 2016/679 privind protectia persoanelor fizice in ceea ce priveste prelucrarea datelor cu caracter personal si privind libera circulatie a acestor date si de abrogare a Directivei 95/46/CE (Regulamentul general privind protectia datelor).
Unde se află: ca la B5. Limitare: fără evaluare formală de conformitate. Detalii: Arhitectură → securitate și date.
Resursele de procesare puse la dispozitia HUB IA vor putea fi usor upgradate odata cu evolutia tehnologica si va elimina pentru tipurile de utilizatori ai acestuia, necesitatea permanenta de achizitionare de echipamente hardware pentru antrenare modele de estimare machine learning. HUB IA poate permite utilizatorilor sa nu achizitioneze deloc resurse de procesare pentru antrenare modele de estimare Machine Learning.
Unde se află: utilizatorii cer GPU prin Request Resources și rulează pipeline-uri containerizate (imagini Docker în registry-ul AI Hub), fără hardware propriu.
Limitare: echipamentele hardware nu fac parte din livrarea noastră. Detalii: Arhitectură.
Arhitectura logică și fizică
Sistem hardware servere – 5 bucati. Infrastructura hardware de procesare si stocare va fi compusa din 5 echipamente cu urmatoarele specificatii minime fiecare: Sasiu (inaltime maxim in rack 4U; minim 3TB RAM la 2666 MHZ; minim 24 sloturi RAM; Controller RAID SSD 12 Gbps; minim doua interfete de retea 10 Gbps; minim 4 interfete PCIe NVMe; minim 4 surse de alimentare); Procesor (minim 2 procesoare, 2.3 Ghz, 18 Core-uri, RAM 2666 Mhz, virtualizare cu acces direct la I/O); Memorie RAM (minim 768 GB, DIMM 128 GB); Stocare (minim 2 SSD M.2 de 960GB; minim 8 disk-uri 12G SAS 10k RPM de 1.6TB); Procesor Grafic (minim 8 procesoare grafice: 15.7 TFLOPS, 125 TFLOPS Tensor, 32 GB la 900 GB/sec, maxim 300 W). Solutia va include licente software pentru sisteme de operare si virtualizare.
Sistem hardware de securitate – 1 bucata: prevenirea intruziunilor de tip inline; posibilitatea de creere de retele virtuale private; autentificare de tip two-factor; filtrarea web proxy-urilor; instalarea si configurarea in mod high-availability; filtrarea traficului in functie de sursa, destinatie, protocol, port; limitarea conexiunilor simultane; route-area pachetelor pe baza de reguli configurabile; normalizarea pachetelor; Virtual Private Network: IPSec, OpenVPN, PPTP, LT2P; Agregarea link-urilor si failover: failover, load balancing.
Componente software: Aplicatie Data Augmentation – Tagging – 1 bucata; Aplicatie Human-Attention and Moderation Demand Fulfillment Marketplace – 1 bucata; Aplicatie Training and Operating Model Factory – 1 bucata; Sistem informatic Core Stack Artificial Intelligence HUB – 1 bucata; Sistem informatic Librarie Algoritmi – 1 bucata; Sistem CRM – 1 bucata; Aplicatie software billing – 1 bucata
Unde se află: primele 5 componente: secțiunile 1–5 de mai jos și paginile din „Sisteme”. CRM și billing: în afara livrării.
Detalii: Arhitectură.
Arhitectura logica (infrastructura de stocare date). Resurse de stocare: Resurse de stocare – pe o perioada de 18 luni.
1. Aplicația Data Augmentation – Tagging
Aplicatia software ce realizeaza augumentare de date pe baza mecanismelor de machine – learning de tip user-facing pentru analiza imagine, interpretarea documentelor si translatarea imagine-inregistrare, cat si intelegerea naturala a limbajului. (+ video, audio, text).
Unde se află: Data Studio (imagine, multispectral, satelit, video, audio, text, loguri); augmentare asistată de model: transcrierile Whisper propuse spre revizuire (proiectul 163); lanțul poză de factură → OCR → JSON pentru documente.
Rol: Data Augmentator. Detalii: Data Augmentation.
Metoda de augmentare pentru mai multe tipuri de date de iesire:
Detalii: Data Augmentation → augmentare.
Geometric-Categorica (tipuri de obiecte si tipuri de relatii);
Unde se află: Data Studio, proiectul 203 „Rafturi și frigidere – produse și relații”: regiuni, atribute, relații (32 dreptunghiuri, 31 relații, 37 alegeri).
Rol: Data Augmentator. Detalii: Data Augmentation → geometric-categoric.
Geometric - Spectrala (identificarea fenomenelor manifestate in alte regiuni decat cele uman-vizibile ale spectrului electromagnetic; eg. SWIR, NIR);
Unde se află: proiectul 204 „Incendiu Evros 2023 – SWIR Sentinel-2” (poligoane pe compoziția SWIR); NIR în proiectul 207 (fals-color B8/B4/B3).
Rol: Data Augmentator. Detalii: Data Augmentation → geometric-spectral.
Suport pentru mai multe forme tensoriale si/sau relationale ale datelor, in urmatoarele formate standardizate:
Detalii: Data Augmentation → formate.
Static 2D Images in RGB (visible spectrum)
Unde se află: proiectul 205 „Imagini statice RGB – scene stradale” (JPEG, WebP, HEIC convertite). Rol: Data Augmentator.
Live 2D Photos in RGB (visible spectrum)
Unde se află: proiectul 206 „Fotografii live RGB – rover OPTIMISM (H.264)” (clip de 3 s + cadre extrase pe GPU). Rol: Data Augmentator.
Static 2D Image Multi-spectral
Unde se află: proiectul 207 „Multispectral static – Sentinel-2, 10 benzi” (GeoTIFF cu 11 benzi + 5 compoziții). Rol: Data Augmentator.
Live 2D Multi-spectral Image
Unde se află: proiectul 208 „Multispectral live – serie temporală Evros” (5 achiziții, SWIR + dNBR). Rol: Data Augmentator.
Stereo Audio Recordings
Unde se află: proiectul 209 „Înregistrări audio stereo – peisaje sonore” (segmente de eveniment și poziția stereo). Rol: Data Augmentator.
Limitare: adnotările demo s-au făcut pe spectrogramă, nu prin ascultare.
Satellite Imagery
Unde se află: proiectul 210 „Imagini satelitare – București, Sentinel-2 (JP2)”. Rol: Data Augmentator.
Excerpts of Journals, Logs, Ledgers and of Other Immutable Registers
Unde se află: proiectul 211 „Jurnale, loguri și registre imuabile” (loguri Apache/syslog + 12 blocuri Bitcoin). Rol: Data Augmentator.
Metoda pentru analiza costului vectorial (|K) corespunzator actiunilor asociatilor responsabili cu augmentarea/etichetarea datelor, incluzand o analiza diferentiala, per stagiu de augmentare si per individ/echipa, a:
Unde se află: BI → dashboard-ul 5 (întrebările 11, 12, 15) și dashboard-ul 6 (întrebările 17–21: efort uman din telemetrie, efort mașină, energie și căldură, per augmentator și proiect); întrebarea 20 completează coloanele care erau 0 în raportul din 2023. Defalcare per proiect (echipă), per etapă (sesiune) și per augmentator.
Rol: Project Admin, Training Operator. Detalii: Data Augmentation → cost |K.
Timpului de augmentare
Unde se află: întrebarea 11 (ore lucrate și aprobate din time log-uri) și întrebarea 12 (timp de adnotare măsurat de Data Studio). Proiectul C.4: 9,4 min time log, 9,1 min măsurat.
Numarul operatiilor umane actuatoare discrete, per tipuri
Unde se află: întrebarea 12: dreptunghiuri, poligoane, segmente, relații, texte editate (proiectul C.4: 199 de operații actuatoare).
Numarul operatiilor umane perceptuale discrete, per tipuri
Unde se află: întrebarea 12: decizii de clasificare și atribute (proiectul C.4: 81).
Efort-uman de augmentare (optic, mecanic)
Unde se află: telemetria interfeței Data Studio (contoare de clicuri, taste, trageri, zoom, timp activ, trimise de un script injectat de nginx, cu utilizatorul luat din SSO); efort mecanic = clicuri + taste + trageri, efort optic = timpul activ; BI întrebările 17–19 (per task, augmentator și proiect) și 20. Exemplu: 4.460 de acțiuni mecanice și 1.246 s efort optic pentru Data Augmentator.
Limitare: efortul este măsurat prin proxy-uri declarate (acțiuni, timp activ), nu fiziologic; telemetria există doar pentru adnotările făcute după introducerea telemetriei (pentru celelalte se reconstituie din rezultat).
Efort-masina pentru augmentare (numar operatii, per tip)
Unde se află: tabelul analytics.machine_ops (conversii de format, anonimizare, pre-adnotare cu model, import), atribuit augmentatorului proporțional cu task-urile lui; BI întrebarea 20: 290,9 operații mașină și 1.028 s CPU pentru Data Augmentator.
Energia consumata
Unde se află: BI întrebarea 20: partea mașină măsurată (NVML, netă de consumul în gol; ex. 1.932 J GPU), partea umană estimată după un model de putere declarat (stație de lucru 75 W × timp activ); total 95.314 J pentru Data Augmentator; detaliu per proiect în întrebarea 21.
Limitare: energia umană este o estimare, nu o măsurătoare; energia CPU nu se poate măsura (VM fără RAPL).
Caldura degajata
Unde se află: BI întrebarea 20: căldura = energia mașinii + energia stației de lucru + incrementul metabolic al muncii de birou (41 W); 146.360 J pentru Data Augmentator.
Limitare: componenta umană este estimată.
Metoda pentru inventarierea si raportarea perfomantei post-validare a actiunilor asociatilor responsabili cu augmentarea/etichetarea datelor, incluzand o analiza diferentiala a calitatii (|Q):
Unde se află: BI întrebarea 22 „Calitate post-validare |Q per augmentator, proiect și etichetă” (dashboard-ul 6), calculată cu quality.py față de date de validare independente (FLEURS, dNBR Sentinel-2, ESA WorldCover, formate structurate) sau revizia Training Operator; raportul din 2023 rămâne la întrebarea 2.
Limitare: pe proiectele 203, 205, 206 și 209 validarea este revizia Training Operator făcută de același agent, deci nu e independentă.
Rol: Project Admin, Training Operator. Detalii: Data Augmentation → calitate |Q.
Acuratete
Unde se află: întrebarea 22, „% Acuratețe” (ex. 90,4% la proiectul 163, 87,9% la 204).
Precizie
Unde se află: întrebarea 22, „% Precizie” (80,8% la 163, 82,7% la 204).
Specificitate
Unde se află: întrebarea 22, „% Specificitate” = TN / (TN + FP) (93,6% la 163, 94,3% la 204), plus EER (proxy) = 1 − (sensibilitate + specificitate) / 2.
Sensibilitate
Unde se află: întrebarea 22, „% Sensibilitate” (80,8% la 163, 71,1% la 204).
Grad acoperire categorica (simbol-signifiant)
Unde se află: întrebarea 22, „% Grad acoperire categorică” (etichetele gold folosite de augmentator / etichetele gold prezente).
Grad acoperire negentropic (semnal-signifiat)
Unde se află: întrebarea 22, „% Grad acoperire negentropic” (partea din semnalul gold acoperită: pixeli, caractere, secunde; la 163 = 1 − CER).
Adaptori tensoriali de format executati pe CPU (pentru compatibilitate retroactiva)
Unde se află: pipeline-ul ZenML format_adapters_pipeline, rularea MLflow 7c4677fd922842b980872738df992fc9; adaptorul din calea de import în Data Studio.
Rol: Training Operator. Detalii: Data Augmentation → adaptoare.
Audio-Video
Unde se află: H.264 și WebP, rândurile de mai jos.
H.264
Unde se află: libavcodec, 74,6 cadre/s (1080p → tensor RGB), p95 21 ms.
WebP
Unde se află: libwebp, 16 fire, 83,3 MP/s; conversia celor 6 WebP din proiectul 205.
Static
Unde se află: HEIC și JPEG-2000, rândurile de mai jos.
HEIC
Unde se află: libheif, 16 fire, 84,8 MP/s; conversia celor 2 HEIC din proiectul 205.
JPEG-2000
Unde se află: OpenJPEG, 8 procese, 7,8 MP/s pe benzi Sentinel-2.
Adaptori tensoriali de format executati pe GPU (pentru performanta sporita la volum mare)
Unde se află: același pipeline, drumurile CUDA (NVDEC pentru H.264, HEVC și VP8, nvJPEG2000, nvJPEG); importul în Data Studio pe GPU 3 (rularea de referință pentru WebP/HEIC pe GPU: 48649b052fa04ea49ad53ad5eb6bddf6).
Detalii: Data Augmentation → adaptoare.
Audio-Video
Unde se află: H.264 și WebP cu pierderi pe NVDEC (vezi mai jos).
Limitare: WebP pe GPU e mai lent decât pe CPU la fișierele mici de test, iar WebP fără pierderi rămâne pe CPU.
H.264
Unde se află: NVDEC: 116,2 cadre/s (1,56× față de CPU), p95 13 ms, 196 J; extragerea cadrelor pentru proiectul 206.
WebP
Unde se află: WebP cu pierderi (un cadru VP8) decodat pe NVDEC: 18 din 24 de mostre, diferență maximă 2 față de libwebp, 42,1 MP/s.
Limitare: pe aceste fișiere mici e mai lent decât CPU-ul pe 16 fire (0,55×, dar CPU-ul rămâne liber); WebP fără pierderi (VP8L) și imaginile peste 4096 px nu au decodor NVDEC și rămân pe CPU.
Static
Unde se află: HEIC pe NVDEC și JPEG-2000 pe nvJPEG2000 (vezi mai jos).
HEIC
Unde se află: HEIC decodat pe GPU: containerul HEIF și dalele HEVC citite de AI Hub, decodare NVDEC (PyNvVideoCodec), asamblarea grilei și conversia de culoare pe GPU; 95,9 MP/s față de 80,8 MP/s pe 16 fire CPU (1,19×), cu 1,8 în loc de 26,8 s CPU; rezultat identic cu libheif (PSNR ≥ 89 dB), inclusiv pe grile de dale de 512 px ca la iPhone.
JPEG-2000
Unde se află: nvJPEG2000: 58,8 MP/s (7,5×), în lot de 8: 213,3 MP/s (27,3×); ieșire identică bit cu bit cu CPU; importul proiectului 210.
2. Aplicația Human-Attention and Moderation Demand Fulfillment Marketplace
Aplicatie software ce permite realizarea unei interfete masina – operator uman, prin care un operator uman adauga unui set de date, informatii si tag-uri necesare pentru moderarea datelor realizata de modelele de estimare Machine Learning in procesul de antrenare.
Unde se află: sesiunile de augmentare din portal (contract, time log, aprobare) legate de proiectele Data Studio; revizuirea predicțiilor modelului (proiectul 163).
Rol: Training Operator, Data Augmentator. Detalii: Marketplace → sesiuni.
Acesta aplicatie contine o componenta de auditare automata.
Unde se află: tabelul request_logs, scris automat de backend; BI dashboard-ul 4 „C.4 – Audit automat al acțiunilor (API)”; Sonata Admin → Audit → Audit API (doar citire); traseul datelor pentru fiecare set.
Rol: Project Admin, Support Specialist. Detalii: Marketplace → audit.
Metode pentru inventarierea si raportarea disponibilului istoric de atentie umana, pe clase functionale de competenta, sortate calitativ in mod multicriterial.
Unde se află: BI dashboard-ul 3 „AI Hub User Stats” (cu explicația criteriilor și a sortării) și întrebarea 13 (ore pe rol și săptămână).
Rol: Project Admin, Support Specialist. Detalii: Marketplace → disponibil.
Metode pentru prognozarea disponibilului de atentie umana, cu consideratie pentru sezonalitate (pas calendaristic) si pentru programul convenit, in mod static sau dinamic, cu asociatii insarcinati cu etichetarea si augmentarea datelor.
Unde se află: Holt-Winters cu sezon de 52 de săptămâni plus programul convenit ca variabilă explicită (contractele în vigoare pe săptămână, β = 0,44 ore pe contract-săptămână); pipeline-ul ZenML attention_forecast_pipeline, rulat la cerere (static) și săptămânal (dinamic); BI întrebările 13–14. Rezultat: 13,7 h prognozate pe 12 săptămâni (3,4–3,5 h/săpt. cât sunt în vigoare cele 9 contracte), MAE la backtest 0,56 h/săpt. (față de 1,14 fără program).
Limitare: istoricul este rar și există doar pentru rolul Data Augmentator.
Rol: Training Operator, Project Admin. Detalii: Marketplace → prognoză.
Metode iterative si heuristice de alocare-in-avans (AoT, ahead-of-time) a disponibilului prognozat de atentie in vederea realizarii uneia dintre optimizari duale posibile:
Unde se află: pipeline-ul ZenML aot_allocation_pipeline (programare liniară, PuLP + CBC), cu intrări reale: task-urile rămase din contractele în vigoare, timpul măsurat pe task, capacitatea prognozată, EER și acoperirea din raportul |Q, energia; rezultatul în BI întrebările 23 (rezumat pe cele 4 moduri) și 24 (planul pe augmentator, proiect și săptămână), rularea MLflow a48aad8f2a424d8cb1d325890d3ebf11.
Limitare: doar contul Data Augmentator are măsurători de calitate și viteză; ceilalți augmentatori (conturi de test din 2023) primesc valori a priori, marcate ca atare.
Rol: Training Operator, Project Admin. Detalii: Marketplace → AoT.
Livrare in buget de timp setat: Minimizare Timp, Minimizare EER (equal-error-rate)
Unde se află: modul „buget de timp”: termenul fiecărei sesiuni ca restricție, minimizează timpul + λ·EER; plan real: 0,86 h, 1 săptămână, EER 14,3%, 114 task-uri alocate.
Livrare in buget de energie setat: Minimizare Energie Consumata/Caldura Degajata, Minimizare EER (equal-error-rate)
Unde se află: modul „buget de energie” (buget 61,3 Wh): minimizează energia/căldura + λ·EER; plan real: 61,3 Wh, 221 kJ, EER 14,9%, 2,3 task-uri nealocate (bugetul e strâns intenționat, ca să se vadă efectul).
Livrare cu protectii adversariale pentru maximizare robustete functoriala: Maximizare Acoperire Entropica (signifiata) si categorica (signifianta), Minimizare EER
Unde se află: modul „protecții adversariale”: 20% din task-uri adnotate de două ori, de persoane diferite, nimeni peste 60% dintr-un proiect; maximizează acoperirea entropică și categorică − λ·EER; plan real: EER efectiv 13,2%, acoperire 69,6%, 6 augmentatori.
Livrare cu protectii colaborative pentru minimizare: Maximizare Acoperire, Minimizare EER
Unde se află: modul „protecții colaborative”: fiecare task revizuit de alt augmentator; maximizează acoperirea − λ·EER; plan real: EER efectiv 2,1%, acoperire 75,1%, 1,12 h.
Estimarea duratei, costului financiar si costului energetic de livrare.
Unde se află: BI întrebarea 15 (ore de augmentare, bugete, ore GPU, kWh, MJ per proiect; ex. Whisper: 24 de rulări, 14,93 ore GPU, 4,17 kWh) și întrebarea 16 (durata estimată a augmentării rămase); estimarea orelor e precompletată și în formularul sesiunii din portal; planurile AoT dau durata, costul, energia și căldura pe fiecare mod; cotația adună costul financiar.
Limitare: timpul median pe task provine din adnotări non-umane (agent AI), deci durata e optimistă.
Rol: Project Admin, Training Operator. Detalii: Marketplace → estimare.
3. Aplicația Training and Operating Model Factory
Applicatie software ce realizeaza interactiunea intre diverse tipuri de utilizatori: utilizatori de rezultat, operator de augumentare, operator de antrenare, dezvoltatori de modele de estimare machine learning, furnizori de date. Va permite unui utilizator, in functie de rezultatul dorit sa aleaga si sa utilizeze mai multe tipuri de servici legate de functionarea inteligentei artificiale. Va functiona ca un portal pentru interfata cu orice tip de clienti.
Unde se află: onprem.ai-hub.cloud cu cele 7 roluri; serviciile: proiecte, seturi, sesiuni de augmentare, dezvoltare de modele, resurse GPU, plus meniul Instrumente (Data Studio, MLOps, MLflow, BI, video, senzori, biometrie, API).
Rol: toate. Detalii: Model Factory, Fluxuri.
a) Metoda pentru analiza costului vectorial (|K) corespunzator antrenarii/validarii/calibrarii modelelor, incluzand o analiza diferentiala, per epoca de antrenare, a:
Unde se află: MLflow, metricile ResourceMonitor în fiecare rulare de antrenare / evaluare (per fereastră de pași; per epocă la detecție și mască); pagina modelului din portal (rezumatul).
Rol: ML Model Developer, Training Operator. Detalii: Model Factory → cost |K.
Duratei drumului critic
Unde se află: critical_path_s, pipeline_wall_time_s, parallelism, step_<pas>_s și tag-ul critical_path (cel mai lung drum ponderat din DAG-ul ZenML), logate pentru toate cele 112 rulări ZenML; ex. whisper_ro-small-full-cost-v2: 686 s = loader 2 s > trainer 526 s > evaluator 158 s.
Duratei de ocupare a resurselor de calcul (CPU, GPU, volatile memory, persistent memory, bus/interface, I/O)
Unde se află: cpu_time, gpu_time, cpu, gpu, memory, gpu_memory plus memoria persistentă (persistent_mb, fs_used_gb), magistrala PCIe (pcie_rx_mb, pcie_tx_mb, din NVML), I/O de bloc (io_read_bytes, io_write_bytes, cgroup v2), timp de disc și rețea (net_recv_bytes, net_sent_bytes); ex. Whisper small cost-v2: PCIe host→GPU 25,9 GB, GPU→host 5,2 GB.
Limitare: I/O de bloc e 0 când datele vin din page cache.
Numarul operatiilor discrete, per tipuri
Unde se află: ops_<categorie> și flops_<categorie> (matmul, conv, attention, norm, activation, elementwise, reduction, memory), flops_total, flops_total_per_epoch_est, numărate pe un pas profilat per epocă (TorchDispatchMode; la Keras profilerul TF); ex. Whisper small: 5,26·10¹³ FLOP pe pas (matmul 3,90·10¹³, atenție 1,30·10¹³), ≈ 3,9·10¹⁵ FLOP pe epocă.
Consum de memorie RAM (bit)
Unde se află: memory (ex. RAM maxim 2,96 GiB la Whisper v2, afișat în portal).
Consum de memoriei VRAM (bit)
Unde se află: gpu_memory (ex. VRAM maxim 16,5 GiB la Whisper v2).
Efort-masina folosit pentru antrenare/validare/calibrare
Unde se află: utilizarea gpu / cpu și timpii gpu_time / cpu_time pe fiecare fază (antrenare, evaluare); timpul GPU pe cardul modelului.
Energia consumata (Joule)
Unde se află: energy_j, total_energy_j; epoch_energy_j la detecție; ex. Whisper v2: 0,413 kWh.
Caldura degajata (Joule)
Unde se află: total_heat_j (ex. 1,49 MJ la Whisper v2), egală cu energia electrică a GPU.
b) Metoda pentru inventarierea si raportarea performantei actiunilor asociatilor responsabili cu augmentarea/etichetarea datelor, incluzand o analiza diferentiala a calitatii (|Q):
Unde se află: același raport ca la 1.4 (BI întrebarea 22, cu specificitate și EER proxy). Detalii: Data Augmentation → calitate |Q.
Acuratete
Unde se află: întrebarea 22, „% Acuratețe”.
Precizie
Unde se află: întrebarea 22, „% Precizie”.
Specificitate
Unde se află: întrebarea 22, „% Specificitate”.
Sensibilitate
Unde se află: întrebarea 22, „% Sensibilitate”.
Grad acoperire categorica (simbol-signifiant)
Unde se află: întrebarea 22, „% Grad acoperire categorică”.
Grad acoperire negentropic (semnal-signifiant)
Unde se află: întrebarea 22, „% Grad acoperire negentropic”.
c) Metoda pentru expunerea rapoartelor comparative de performanta/cost al algoritmilor inregistrati, per tipuri de date si spete individuale.
Unde se află: MLflow → Compare și modul grafic (ex. 29 de rulări Whisper); portalul → Final ML Models List și ML Model List (tip de date + metrici + cost); BI întrebarea 15; pagina Rezultate.
Rol: ML Model Developer, Training Operator, Result User. Detalii: Model Factory → comparații.
4. Sistemul informatic Core Stack Artificial Intelligence HUB
Infrastructura software necesara pentru interconectare si operare integrata a modulelor software HUB IA. Va asigura ca pornire 8-12 exemple simple de integrare, care sa acopere 2-3 use case-uri frecvente in 3-4 limbaje de programare de circulatie (ReactJS, Java, Python, PHP)
Unde se află: SSO + API-ul de inferență api.onprem.ai-hub.cloud; 10 exemple, 3 cazuri de utilizare (sentiment, transcriere, extracție factură) plus streaming, în ReactJS, Java, Python, PHP și C++.
Rol: oricare (demo-urile din browser); dezvoltatori (exemplele server-side). Detalii: Core Stack → exemple.
Java Spring Boot - Implementarea demonstrativa server-side cu HTTP-over-TLS si websocket
Unde se află: exemplele 6–7, GitLab ai-hub-demo-javaspring: RestClient HTTPS, StandardWebSocketClient WSS, endpoint-uri server-side proprii. Detalii: Core Stack → Java.
Python - Implementarea demonstrativa deschisa server-side cu HTTP-over-TLS si websocket
Unde se află: exemplele 1–3, GitLab ai-hub-client-demo-python: client REST, client WebSocket, server relay aiohttp (HTTP + WS). Detalii: Core Stack → Python.
ReactJS - Implementarea demonstrativa deschisa client-side cu HTTP-over-TLS si websocket
Unde se află: exemplul 8, api.onprem.ai-hub.cloud/demo/react/. Rol: oricare. Detalii: Core Stack → React.
ReactJS - Implementarea demonstrativa deschisa client-side cu websocket si WebRTC
Unde se află: exemplul 9, api.onprem.ai-hub.cloud/demo/webrtc/: getUserMedia + RTCPeerConnection (Opus) + AudioWorklet → WebSocket → transcriere live.
Limitare: WebRTC e folosit pentru captură și o buclă locală, transportul spre AI Hub e WebSocket; testat automat cu microfonul fals al Chromium. Detalii: Core Stack → WebRTC.
C++ - Implementarea demonstrativa deschisa on-the-edge (client) cu transmiterea evenimentelor prin websocket
Unde se află: exemplul 10, GitLab ai-hub-demo-cplusplus: client IXWebSocket care trimite evenimentele dispozitivului și audio. Detalii: Core Stack → C++.
5. Sistemul informatic Librărie Algoritmi
Componenta software care functioneaza ca o biblioteca pentru modelele de estimare machine learning. Acesta va putea prezenta lista cu de modele (parametrii si functionalitati) si prezenta toate informatiile necesare, catre celelalte module atunci cand este solicitata utilizarea unuia dintre acestia.
Unde se află: registrul MLflow (Model registry); GET /v1/models și GET /v1/models/{nume} pe API (16 modele servite, 55 de intrări în registru); GET /api/v1/{rol}/ml-model/{id}/metrics în portal.
Rol: ML Model Developer; modulele platformei. Detalii: Librărie → registru.
Transformare imagine text in text editabil;
Unde se află: ocr-ro v1 (TrOCR-small fine-tunat pe documente românești + detecția textului docTR), servit prin API: POST /v1/ocr și POST /v1/ocr/invoice (fotografie de factură → OCR → JSON). CER 3,02% pe pagini scanate (68,2% zero-shot); factură fotografiată → JSON: F1 0,978.
Limitare: antrenat și testat pe documente sintetice randate; pe fotografii CER-ul e ~20% (tabelele desenate din caractere).
Rol: ML Model Developer, oricare prin API. Detalii: Librărie → OCR.
Recunoastere faciala;
Unde se află: face-recognition v1 (SFace) / v2 (ArcFace R100), 6 rulări pe LFW (acuratețe până la 99,67%, EER 0,32%); API /v1/face/embed, /v1/face/verify; demo-ul biometric. Detalii: Librărie → față.
Recunoasterea mimicii fetei (Face Mask);
Unde se află: face-mask v2 (acuratețe 98,74%, macro-F1 93,72%, față de 57,57% zero-shot) și face-expression v1/v2 (7 expresii; EfficientNet-B0: 97,98% pe avatari sintetici, 93,33% neutru/fericit pe fețe reale), butonul „Clasifică expresia” din demo-ul biometric; API /v1/face/mask; mimica live prin blendshapes MediaPipe.
Limitare: expresiile, altele decât neutru/fericit, sunt validate doar pe avatari sintetici. Detalii: Librărie → mască, Librărie → expresii.
Recunoasterea de obiecte solide intr-o imagine in functie de parametrii setati;
Unde se află: object-detection v1 (SSDlite MobileNetV3, mobil) și v2 (Faster R-CNN R50-FPN-v2, GPU), 14 clase de produse și obiecte; API POST /v1/detect cu parametrii classes (engleză sau română), score_threshold, iou_threshold, max_detections. mAP@0.5: 79,7% (v2) / 68,1% (v1), față de 56,5% / 45,2% zero-shot.
Limitare: imaginile sunt fotografii generale Open Images, nu rafturi de magazin. Rol: oricare prin API. Detalii: Librărie → obiecte.
Identificarea sensului unui text. Exemplu: identificare unei serii si numar aferent unei facturi din corpul unui mesaj trimis de un client;
Unde se află: gemma-ro-extraction (API /v1/extract, familia facturi): F1 0,949; factura demo: număr FCT-2026-008726, date, părți, 10 poziții, totaluri, 71/72 câmpuri corecte; sentiment-ro pentru tonul mesajului. Rol: oricare (demo React). Detalii: Librărie → text.
Identificarea anomaliilor din informatii primite de la senzori impreuna cu analiza predictiva ce poate estima incadrarea intr-un scenariu. Exemplu: un senzor dintr-un camp agricol detecteaza o scadere brusca a temperaturii iar altul cresterea presiunii atmosferice pentru o perioada definita de timp rezultand (analiza predictiva) posibilitatea ca recolta sa sufere aparitia unui anumit tip de ciuperca.
Unde se află: sensor-anomaly, sensor-forecast, sensor-scenario; sensors.onprem.ai-hub.cloud: Braunschweig 04.06.2026 – scădere bruscă de −6,4 °C în 60 min, apoi scenariul „făinarea viței de vie” (ciupercă Erysiphe necator).
Limitare: etichete de scenariu derivate din reguli agronomice, nu din observații în câmp; creșterile lente de presiune sunt prinse de clasificatorul de scenariu, nu de detectorul de anomalii; date din Germania. Rol: Result User. Detalii: Librărie → senzori.
Metode tehnologice luate in calcul pentru acest modul:
Detalii: Librărie → metode.
Retea neurala convolutiv-asociativa pentru segmentare semantica raster (imagini bi-dimensionale statice)
Unde se află: semantic-segmentation (acoperirea terenului din Sentinel-2, 11 clase ESA WorldCover, 12 plăci din România), pipeline-ul semantic_segmentation_pipeline, API POST /v1/segment/landcover cu variant=mobile|gpu.
Limitare: etichetele WorldCover sunt și ele produsul unui model (~77% acuratețe raportată de ESA).
Optimizat pentru consum mic de energie (mobile)
Unde se află: v1 LR-ASPP MobileNetV3 (3,2 M parametri): mIoU 72,4 pe 7 clase, 1,04 J/pătrat (batch 1), 105 ms pe CPU.
Optimizat pentru performanta maxima (data center GPU)
Unde se află: v2 DeepLabV3-ResNet101 (61 M parametri): mIoU 73,9, 3,71 J/pătrat, 1.090 ms pe CPU.
Retea neurala convolutiv-asociativa segmentare non-semantica (imagini bi-dimensionale statice)
Unde se află: instance-segmentation (segmentare agnostică la clasă cu prompt casetă/punct, familia SAM), pipeline-ul promptable_segmentation_pipeline, API POST /v1/segment/prompt (casetele pot veni din /v1/detect).
Limitare: modelele SAM sunt folosite zero-shot (fără fine-tuning), evaluate pe 500 de imagini COCO.
Optimizat pentru consum mic de energie (mobile)
Unde se află: v1 MobileSAM (10,1 M parametri): mIoU 79,6 (casetă), 17,8 J/imagine, 0,6 s pe CPU; la detecție SSDlite (1,74 J/imagine), la OCR TrOCR-small + DB-MobileNet.
Optimizat pentru performanta maxima (data center GPU)
Unde se află: v2 SAM ViT-H (641 M parametri): mIoU 81,8, 159 J/imagine, 14 s pe CPU; la detecție Faster R-CNN R50 (12,7 J/imagine, mAP@0.5 79,7).
Retea neurala convolutiva de urmarire (tracking) si flux optic (optical flow) (fluxuri video)
Unde se află: aplicația video: detecție CNN + rețeaua convolutivă de flux optic RAFT (torchvision) pe GPU, folosită de tracker pentru asocierea compensată de mișcare; tab-ul „Flux optic”; modelele optical-flow și video-tracker în registru. Pe MOT17 la 5 cadre/s: IDF1 46,1 → 49,1, schimbări de identitate −61%; pe Spring: EPE 0,66 px.
Limitare: la frecvența completă de cadre fluxul nu aduce câștig; evaluarea urmăririi folosește MOT17 (licență necomercială, doar evaluare).
Optimizat pentru performanta maxima (data center GPU)
Unde se află: RAFT small pe A40: 48 ms și 9,1 J pe pereche 720p, de 17,8× mai rapid decât pe CPU.
Retea neurala convolutiv-asociativa pentru compresie entropica in spatii latente sferice (pentru recunoastere de obiecte individuale). Aceasta clasa de retele neurale invata ce caracteristici observabile deosebesc indivizi despre care se cunoaste in cadrul antrenamentului ca sunt diferiti. Familia din care fac parte aceste re’ele mai este cunoscuta si sub numele de „salient feature extraction” sau “constrained variational auto-encoder” si se foloseste inclusiv pentru recunoastere faciala.
Unde se află: SFace și ArcFace (embedding L2-normalizat pe hipersferă, similaritate cosinus), face-recognition v1/v2; embedding-ul open_clip pentru re-identificare în video. Detalii: Librărie → față.
a) Analiza supraveghere video
Analiza supraveghere video. Permite orchestrarea hibrida cloud & edge supraveghere video, cu capacitatea de a urmari mai multe evenimente, obiecte si tipuri de persoane. Metodele descentralizate si jurnalizate folosite permit descarcam procesarea pana la limite minime. Algoritmul nostru ofera flexibilitatea in legarea procesarii datelor sensibile la un anumit dispozitiv si scop si ne permite sa urmarim doar utilizari legitime ale supravegherii, in conformitate cu cele nationale, europene si asteptari legale internationale in privinta protectiei vietii private si libertatilor cetatenesti.
Unde se află: video.onprem.ai-hub.cloud: serviciu cloud pe GPU + client edge pe CPU (doar evenimente și embedding-uri trimise în cloud); scopul prelucrării obligatoriu la pornirea unui flux; jurnalul acțiunilor cu utilizatorul; fețe estompate; retenție 30 de zile.
Rol: Result User, Project Admin, Training Operator, ML Model Developer. Detalii: Librărie → video.
Metode de gestionare a profilelor asociate persoanelor si obiectelor partial-recognoscibile.
Unde se află: tab-ul Profile: profil per traiectorie, marcaj „parțial”, re-identificare („legat de #…”); test cap-coadă: 705 profile, 111 parțiale, 9 legate. Rol: Project Admin.
Metoda pentru cautarea in evenimentele detectate istoric dupa descriere analitica.
Unde se află: tab-ul Evenimente & căutare → „Căutare în istoric după descriere” (/api/search/text, text multilingv). Rol: ML Model Developer.
Metode pentru compararea diferentiala a doua sau mai mult imagini al obiectelor
Unde se află: tab-ul Comparare (/api/compare): matrice de similaritate, culoare, atribute zero-shot, hartă de diferențe. Rol: ML Model Developer.
Metoda de cautare in timp real dupa imagini-specimen al unu obiect de interes
Unde se află: tab-ul Specimene (prag 0,8) + fluxul demo-cam-2: notificare „Potrivire specimen” (0,81 live, 0,899 pe fișier).
Limitare: slab pentru persoane mici (AUC 0,55 la ~69 px). Rol: ML Model Developer.
Metoda de analiza pentru fluxuri de date in timp real, inclusiv de la camere de supraveghere.
Unde se află: tab-ul Fluxuri live: RTSP rtsp://rtsp:8554/demo-cam și demo-cam-2, linie / zonă / staționare, fluxul optic al ultimelor cadre; camera web din browser.
Limitare: camera web testată doar scriptat; camerele demo redau videoclipuri licențiate. Rol: Training Operator.
Metoda de analiza pentru fisiere video si de imagine statice.
Unde se află: taburile Imagini și Fișiere video, pe GPU sau CPU, cu viteză și energie. Rol: Result User.
Metode de publicare automata a evenimentelor de recunoastere catre surse externe.
Unde se află: tab-ul Publicare: websocket /ws/events, webhook HMAC-SHA256, Mercure; la fel în dashboard-ul de senzori. Rol: Project Admin.
b) Identificare biometrică
Identificare Biometrica. Acopera diferenta dintre nevoia de securitate suplimentara oferita prin autentificare biometrica si multimodala si nevoia de confidentialitate a cetatenilor. Noi livram acest lucru prin utilizarea unui amestec de algoritmi criptografici si de invatare automata, care se asigura ca datele sunt procesate in mod fiabil si redundant pe dispozitivul clientului, iar confirmarea din cloud fiind exclusiv bazata pe dovezi criptografice de identitate si integritate.
Unde se află: bio.onprem.ai-hub.cloud: embedding calculat în browser; în modul „pe dispozitiv” serverul confirmă doar pe baza semnăturii ECDSA a cheii dispozitivului peste tokenul provocării + hash-ul șablonului; prezența fizică e verificată pe server din 5 cadre de evidență, procesate în memorie și nesalvate; atestări JWS ES256 verificabile public. Testul de API: 19/19.
Limitare: fluxurile cu camera din browser nu au fost testate cu o cameră reală (headless fără cameră și WebGL); partea de server e acoperită de testul de API. Rol: oricare. Detalii: Librărie → biometrie.
Aplicatie mobil iOS pentru recunoastere faciala on-device
Unde se află: aplicația React Native din 2023 (ai-hub-demo-react-native), configurată acum spre https://bio.onprem.ai-hub.cloud, cu clientul endpoint-urilor fluxului on-device; demo-ul web rulează în Safari pe iPhone cu același flux on-device.
Limitare: aplicația nativă nu a fost construită (Xcode/Android SDK indisponibile, Regula FaceSDK cu licență comercială); ecranele nu apelează încă API-ul (lipsesc login-ul SSO și cheia dispozitivului în Keychain).
Aplicatie mobil Android pentru recunoastere faciala on-device
Unde se află: aceeași aplicație React Native (Android); demo-ul web în Chrome pe Android.
Limitare: ca la iOS (Android Keystore în loc de Keychain).
Modul de validare a prezentei fizice a utilizatorului
Unde se află: liveness verificat pe server: provocare semnată (3 pași aleatori, 2 minute, o singură folosire); pe fiecare cadru serverul verifică acțiunea (MediaPipe pe server), o singură față, aceeași identitate, timpii și anti-spoofing-ul pasiv face-antispoofing (MiniFASNet; atacuri cu ecran 0% acceptate, oameni reali respinși 1,5%). Testul de API: cadru dintr-un atac cu ecran → scor 0,0002, respins.
Limitare: netestat cu o cameră reală; măștile (hârtie, 3D, silicon) trec de detectorul pasiv (APCER 90–100%); injectarea video nu e oprită fără atestarea aplicației; pragurile nu sunt calibrate pe camere reale.
Modul de transliterate documente de identitate
Unde se află: secțiunea „Document de identitate (MRZ)”: specimenele de pașaport Norvegia / Țările de Jos, cifre de control ICAO 9303, transliterare și forma originală (ex. „Østenbyen / Åsamund”). API /v1/face/mrz.
Posibilitatea de gestionare a unuia sau mai multi avatari de catre utilizator, pentru izolarea doar acelor date personale pe care utilizatorul vrea sa le indice, expuna sau certifice catre terti
Unde se află: secțiunea „Avatari și atestări”: atribute bifate, pseudonim diferit pe avatar, atestare semnată (după autentificare facială în ultimele 5 minute), verificare publică, revocare.
Limitare: emiterea cere o autentificare facială cu camera (vezi limitarea de mai sus).
6. Sistem CRM
Componenta software ce va permite gestionarea tipurilor de utilizatori/clienti si documentarea activitati acestora in relatia cu platforma inovativa HUB IA. Functionalitati principale ale sistemului CRM sunt: autentificare pe baza de username si parola; posibilitatea definirii si atribuirii de tipuri si roluri pentru un utilizator; posibilitatea de introducere date de identificare pentru un utilizator; posibilitatea inregistrarii de servicii si produse folosite de catre un utilizator; posibilitatea generarii de rapoarte per utilizator aferente serviciilor si produselor utilizate; posibilitatea integrarii prin API cu alte module software.
7. Aplicația software billing
Componenta software ce va permite emiterea facturilor fiscale catre utilizatorii platformei inovative HUB IA. Functionalitati principale ale aplicatiei software billing sunt: posibilitatea definirii unui utilizator; posibilitatea asocierii de date fiscale pentru un utilizator; posibilitatea emiterii unei facturi fiscale; posibilitatea marcarii statusului unei facturi (incasata/neincasata); posibilitatea elaborarii de rapoarte; posibilitate de comunicare prin API cu aplicatii terte.
Resursele de stocare
Resursele de stocare necesare in cadrul proiectului trebuie sa indeplineasca urmatoarele cerinte: Capacitate de stocare utila: minim 20TB; Accesul la resursele de stocare se va face printr-un mecanism securizat si va permite alocarea diferita a drepturilor de acces pentru utilizatori; Capacitatea de stocare va permite partitionarea; Disponibilitate: 24/7/365. Resursele de stocare vor fi asigurate va fi asigurate pentru o perioada de 18 luni intr-o infrastructura de cloud public sau extensie a unui cloud public certificat, scalabila, ce va permite oricand in baza solicitarii Beneficiarului, in limita acestui interval, cel putin dublarea cantitatilor.
Cerințe de integrare
Toate componentele HUB IA vor functiona integrat ca un sistem de sine statator;
Unde se află: autentificare unică pentru toate instrumentele, meniul Instrumente din portal, sincronizarea membrilor portal → Data Studio, metricile MLflow în portal, tag-urile de proiect pe rulări, API-ul de inferență legat de registru.
Rol: oricare. Detalii: Autentificare unică, Arhitectură.
Sistemul va prelua datele de la furnizorii de date si le va integra in baza de date HUB IA;
Unde se află: Data Set Form → backend (/api/v1/data-provider/dataset/create) → stocare + crearea automată a proiectului Data Studio (seturile C.4 203–211).
Rol: Data Supplier. Detalii: Data Augmentation → flux.
Sistemul va permite furnizarea modelelor de estimare Machine Learning antrenate in formate utilizabile de catre dezvoltatorii de aplicatii;
Unde se află: artefactele din MLflow (adaptoare LoRA, ONNX pentru față și mască, serving/predict.py pentru OCR, detecție și segmentare), modelele complete pe disc, API-ul HTTPS / WebSocket care servește 16 modele, cu exemple în 6 tehnologii.
Rol: ML Model Developer. Detalii: Core Stack, Librărie.
Sitemul HUB IA va functiona integrat pe nivelele hardware si software.
Unde se află: nivelul software rulează integrat pe serverul GPU al platformei (containere Docker, k3s, nginx, GPU-uri alocate pe servicii).
Limitare: nivelul hardware nu face parte din livrarea noastră.
Detalii: Arhitectură.