clossers/didi-lot2-backend
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
didi-lot2-backend/backend/docs/05_Ghid_Utilizare_Lot2.md
EVOTECH IT SRL 8ecc78e729 livrare lot 2
2026-07-10 03:39:53 -07:00

14 KiB
Raw Blame History

% Ghid de utilizare — DiDi Lot 2 (Backend) % Platformă digitală inteligentă pentru prevenirea și combaterea dezinformării % PNRR DIGI150 · contract 11.1.i3.c9

1. Scop și context

Prezentul ghid prezintă utilizarea Dashboard-ului administrativ al Lotului 2 — interfața prin care operatorul configurează, rulează, monitorizează și moderează platforma DiDi de detecție a dezinformării. Capturile de ecran provin din platforma reală, în funcțiune (https://<HOST_IP>:3001/admin).

Fiecare secțiune este corelată cu modulul corespondent din Propunerea Tehnică Lot 2 și cu cerințele caietului de sarcini, astfel încât ghidul servește simultan ca manual de operare și ca dovadă de conformitate funcțională.

Zonă interfață Modul ofertă Rol
Autentificare Modulul 7 Login OIDC/Keycloak, roluri RBAC
Service Monitor Modulele 6.8, 8 Sănătatea serviciilor + observabilitate
Framework Modulele 1.3, 6.5 Parametrizarea completă a detecției
LLM Components / Providers Modulele 1.7, 2.5 Modele LLM, chain-uri, chei API
Pipelines Modulele 1.2, 6.3, 6.4 Definire, versionare, dry-run, rulare
Cozi Modulele 3, 6.4 Broker de mesaje, procesare async
Istoric analize Modulele 2.6, 6.7 Rezultate, verdicte, trasabilitate
Moderare Modulul 6 Coadă HIL, triaj, revizuire umană
Utilizatori Modulele 6.6, 5.3 Conturi, roluri, abonamente, credite

2. Autentificare (Modulul 7)

Accesul la dashboard se face prin Keycloak (OIDC/OAuth2 + PKCE), realm didi-admins. Autentificarea emite un token JWT RS256 care este verificat atât la gateway (Kong), cât și în backend. Rolul din token (admin, moderator, senior_moderator) determină ce operații sunt permise.

Ecran de autentificare Keycloak (realm didi-admins){width=6in}

3. Monitorizarea serviciilor — Service Monitor (Modulele 6.8, 8)

Ecranul principal grupează toate serviciile platformei pe straturi (Data Layer, Gateway & Auth, Orchestration, Monitoring) și afișează starea fiecăruia în timp real. Starea serviciilor locale este derivată din starea containerelor Docker, nu dintr-un simplu ping — deci reflectă sănătatea reală (healthy / unhealthy). Butonul Open UI deschide consola nativă a serviciului (MinIO, RabbitMQ etc.).

Service Monitor — stratul de date (PostgreSQL, Redis, RabbitMQ, MinIO), toate HEALTHY{width=6.5in}

Service Monitor — stratul de orchestrare și gateway/autentificare{width=6.5in}

Service Monitor — stratul de observabilitate (Prometheus, Grafana, Loki, Jaeger, Alertmanager){width=6.5in}

4. Framework — parametrizarea detecției (Modulele 1.3, 6.5)

Principiul central al platformei este separarea configurării de execuție: toți parametrii de analiză sunt gestionați declarativ din acest ecran, stocați în PostgreSQL și sincronizați în Redis prin butonul Sync to Redis. Motorul de analiză citește configurarea din Redis la fiecare rulare — comportamentul se modifică fără redeploy de cod.

Pagina afișează sumarul (8 dimensiuni, 166 tehnici, 7 verdicte, 6 niveluri de risc, 12 tipuri de sursă, 11 platforme) și grupează parametrii pe categorii, prin tab-uri. Butoanele Analysis Flow, Run Test Pipeline și Sync to Redis permit vizualizarea fluxului, testarea și publicarea configurării.

DIDI Framework — vedere de ansamblu: dimensiunile de analiză (D1–D8) cu ponderi editabile{width=6.5in}

4.1 Tehnici de manipulare (dimensiuni → subdimensiuni → tehnici → indicatori)

Ierarhia de 166 de tehnici organizate pe 8 dimensiuni. Fiecare tehnică are indicatori, reguli de validare, ponderi și o alocare de model LLM per etapă.

Catalogul tehnicilor de manipulare{width=6.5in}

Parametrii unei tehnici de manipulare{width=6.5in}

Indicatorii asociați tehnicilor de manipulare{width=6.5in}

Regulile de validare pentru tehnici{width=6.5in}

Alocarea modelelor LLM pe etapele componentei Techniques (screening → deep){width=6.5in}

4.2 Conținut generat de AI (AI-Tampered)

Parametrii componentei care detectează conținut generat/modificat de AI (text, imagine, video) și alocarea modelelor pe etape.

Parametrii componentei AI-Tampered{width=6.5in}

Alocarea modelelor LLM pentru AI-Tampered{width=6.5in}

4.3 Afirmații verificabile (Claims)

Extragerea și verificarea afirmațiilor prin căutare web, tipurile de claim și nivelurile de încredere.

Parametrii componentei Claims{width=6.5in}

Tipuri de claim configurabile{width=6.5in}

Taxonomia tipurilor de claim{width=6.5in}

Niveluri de încredere pentru claims{width=6.5in}

Alocarea modelelor LLM pentru Claims{width=6.5in}

4.4 Evaluarea sursei (Source Assessment)

Credibilitatea sursei/domeniului: clasificarea și credibilitatea autorului, vechimea domeniului, modificatorii de platformă și alocarea modelelor.

Parametrii componentei Source Assessment{width=6.5in}

Credibilitatea sursei{width=6.5in}

Disponibilitatea / evaluarea sursei{width=6.5in}

Influența vechimii domeniului asupra scorului{width=6.5in}

Clasificarea autorului{width=6.5in}

Credibilitatea autorului{width=6.5in}

Modificatori de scor per platformă{width=6.5in}

Alocarea modelelor LLM pentru Source Assessment{width=6.5in}

4.5 Analiza domeniului

Scorul de risc al domeniului și semnalele de alarmă (red flags) — corespondentul frontend al integrării cu serviciul domain-check (T4): WHOIS, DNS, SSL, blacklist.

Scorul de risc al domeniului{width=6.5in}

Semnale de alarmă (red flags) pentru domeniu{width=6.5in}

4.6 Verdicte, scoruri și interpretări

Categoriile de verdict, nivelurile de risc, pragurile de severitate, maparea scorului și regulile de interpretare care transformă scorurile componentelor într-un verdict final.

Categorii de verdict{width=6.5in}

Categoriile de verdict (detaliu){width=6.5in}

Niveluri de risc ale verdictului{width=6.5in}

Evaluarea severității{width=6.5in}

Severitatea verdictului{width=6.5in}

Nivelurile de încredere ale verdictului{width=6.5in}

Reguli de interpretare{width=6.5in}

Maparea scorului de risc{width=6.5in}

Suprascrieri și sinergii între componente (overrides & synergy){width=6.5in}

4.7 Ponderi și profiluri de pipeline

Ponderile componentelor, multiplicatorii, scenariile de ponderare și profilurile de verdict per tip de conținut (text, URL, imagine, audio, video).

Ponderile componentelor în verdictul final{width=6.5in}

Ponderile verdictului{width=6.5in}

Multiplicatori de scor{width=6.5in}

Multiplicatorii verdictului{width=6.5in}

Scenarii de ponderare{width=6.5in}

Profiluri de verdict per tip de input{width=6.5in}

5. Modele LLM și provideri (Modulele 1.7, 2.5)

Platforma folosește lanțuri de modele (primar + fallback-uri) per componentă și etapă. Providerii (local Qwen 3.5, OpenRouter etc.) și cheile API se gestionează din acest ecran, iar modelul primar folosit este cel local, servit de Lotul 1 (fără costuri per-token pe calea principală).

Providerii LLM configurați{width=6.5in}

Managementul providerilor (1){width=6.5in}

Managementul providerilor (2) — modele și costuri{width=6.5in}

6. Pipelines — definire, versionare, rulare (Modulele 1.2, 6.3, 6.4)

Fluxul de analiză este modelat ca workflow cu dependențe explicite. Fiecare tip de conținut are un profil de pipeline propriu. Editorul permite definirea nodurilor și dependențelor, versionarea, iar consola de rulare permite testarea și dry-run (rezolvarea întregului plan — noduri, cozi, lanțuri de modele — fără a consuma resurse).

Editor de pipeline (1){width=6.5in}

Editor de pipeline (2){width=6.5in}

Editor de pipeline (3){width=6.5in}

Pipeline pentru analiza de text{width=6.5in}

7. Cozi de procesare — Broker de mesaje (Modulele 3, 6.4)

Analizele asincrone sunt dispecerizate pe cozi RabbitMQ (componente × planuri de prioritate + media-preprocess + results + DLQ). Ecranul afișează starea cozilor, adâncimea și workerii activi.

Starea cozilor de procesare (1){width=6.5in}

Starea cozilor de procesare (2){width=6.5in}

Starea cozilor de procesare (3){width=6.5in}

8. Istoric analize și citirea unui verdict (Modulele 2.6, 6.7)

Toate analizele sunt persistate și consultabile. Ecranul de detaliu al unei analize arată: verdictul final cu scor (0–100) și categorie, rezultatul fiecărei componente, afirmațiile verificate cu sursele care le confirmă/contrazic, căutările web efectuate și modelele folosite — trasabilitate completă.

Istoric analize — listă{width=6.5in}

Detaliu analiză — verdict DISINFORMATION (risc 100), afirmații verificate + surse care contrazic{width=6.5in}

Detaliu analiză (2){width=6.5in}

Detaliu analiză (3){width=6.5in}

Detaliu analiză (4){width=6.5in}

Detaliu analiză (6){width=6.5in}

Detaliu analiză (7){width=6.5in}

9. Moderare umană (HIL) (Modulul 6)

Sesiunile care îndeplinesc criteriile de triaj (prag de încredere, zonă gri de risc, subiecte sensibile) intră într-o coadă de moderare umană. Operatorii cu rol moderator / senior_moderator revizuiesc și corectează verdictele. Setările de triaj și clientul de brain (cache de fact-checking) se configurează din Moderation Settings și se sincronizează în Redis.

Setări de moderare — reguli de triaj + client brain{width=6.5in}

Coada de moderare — revizuirea sesiunilor{width=6.5in}

10. Utilizatori și abonamente (Modulele 6.6, 5.3)

Managementul conturilor (sincronizate cu Keycloak), al rolurilor, al abonamentelor și al creditelor. Planurile de abonament determină prioritatea în cozi și lanțul de modele (free / premium).

Management utilizatori — conturi și roluri{width=6.5in}

Planuri de abonament și credite{width=6.5in}

11. Rezumatul conformității funcționale

Ghidul de față demonstrează, pe capturi din platforma reală, acoperirea funcțională a modulelor din Propunerea Tehnică Lot 2:

Modul ofertă Funcționalitate demonstrată Secțiune
M1 — Orchestrator Parametrizare, pipelines, dry-run, catalog AI §4, §5, §6
M2 — Analiză Executori (techniques, ai-tampered, claims, source, domain), agregare verdict §4, §8
M3 — Broker mesaje Cozi de procesare async, priorități §7
M4 — API Gateway Autentificare la gateway, RBAC §2
M5 — Baze de date Persistare, scheme (rezultate, config, useri, abonamente) §8, §10
M6 — Dashboard Toată interfața administrativă (config, run, monitor, moderare, useri) §3–§10
M7 — Autentificare Login OIDC/Keycloak, roluri §2
M8 — Observabilitate Stratul de monitorizare în Service Monitor §3
M9 — Containerizare/CI-CD Servicii containerizate vizibile în Service Monitor §3

Documentul se completează cu: 01_Arhitectura_Lot2 (arhitectură), 02_Ghid_Instalare_Operare (instalare/operare), 03_Raport_Testare_API (test API), 04_Raport_Testare_Integrare_Lot1-Lot2 (test integrare) și specificațiile OpenAPI ale celor două servicii.