În discuțiile despre produse AI, atenția se oprește frecvent la model: ce scor obține, cât de repede răspunde, cât context poate procesa și cât costă o interogare. Într-un domeniu sensibil, acestea sunt doar o parte a problemei. O valoare citită cu o zecimală greșită, un avertisment important formulat prea timid sau o ipoteză prezentată ca diagnostic pot conta mai mult decât o funcție spectaculoasă.
Documentele medicale combină mai multe dificultăți într-un singur flux: imagini imperfecte, date personale, formate neuniforme, terminologie specializată și context incomplet. Mai apare și o problemă de percepție. Utilizatorul poate citi o frază fluentă ca pe o certitudine, chiar dacă sistemul a lucrat cu informații parțiale.
Pentru utilizator, un serviciu de interpretare analize online poate părea un flux liniar: încarcă documentul, așteaptă și primește explicația. În KlarLab, traseul este intenționat fragmentat. Documentul trece prin verificarea calității, clasificare, extracție structurată, normalizare, generare pe etape și validări ulterioare. Fiecare etapă adaugă un punct în care documentul sau rezultatul poate fi verificat și, la nevoie, oprit.
1. Modelul este o componentă, nu centrul de comandă
Un prototip poate fi construit cu un prompt și un apel către un model. Un produs are nevoie de stări, contracte de date, căi de eroare, telemetrie și un comportament previzibil atunci când furnizorul nu răspunde sau răspunde neconform. Diferența devine vizibilă mai ales când intrarea nu este curată.
Documentele sunt rutate după familie și complexitate. Un set numeric de rutină nu urmează aceeași succesiune de pași ca un buletin dens, un raport narativ sau un document mixt, în care coexistă valori de laborator și constatări scrise.
Rutarea stabilește traseul de procesare și felul în care răspunsul este împărțit.
Pentru fiecare încercare sunt urmărite etapa, ruta, durata, motivul opririi, consumul și problemele de validare.
Trasabilitatea nu demonstrează că o explicație este corectă. Ajută însă la separarea unor cauze foarte diferite: un document slab, un răspuns neconform al modelului sau o problemă operațională. Fără această diferențiere, toate eșecurile arată la fel în interfață. În exploatare, aceleași date arată dacă o corecție rezolvă o clasă de erori sau doar un singur exemplu.
2. Prima barieră este calitatea documentului
Un sistem care explică impecabil o valoare extrasă greșit produce tot un rezultat greșit. Primul control este, așadar, vizual. Fiecare pagină este evaluată pentru blur, mișcare, reflexii, umbre, margini tăiate, perspectivă excesivă, dungi de scaner, contrast slab sau artefacte apărute când este fotografiat un monitor.
Regula nu este respingerea oricărei fotografii imperfecte. O pagină ușor înclinată poate fi lizibilă, iar o reflexie poate traversa o zonă fără informație utilă. Întrebarea practică este dacă se disting fără ghicit cele mai mici cifre, separatorii zecimali, semnele, unitățile și capetele intervalelor de referință. Dacă o valoare trebuie dedusă din context, pagina se oprește.
Controlul funcționează la nivel de pagină. Într-un PDF cu o pagină bună și una blurată, defectul nu este transferat automat întregului lot, iar informația slabă nu este completată din paginile vecine.
Când o cifră nu se vede clar, răspunsul corect este solicitarea unei fotografii noi, nu o explicație mai prudentă.
3. Extracția și explicația sunt două probleme diferite
După acceptarea documentului este construită o reprezentare structurată: denumirea analizei, valoarea, unitatea, intervalul, rezultatul calitativ și etichetele de orientare care pot fi stabilite din document. Pentru rapoartele narative sunt păstrate constatările scrise și localizarea relevantă. Abia această reprezentare intră în etapa explicativă.
Valorile extrase rămân separate de textul explicativ. Contractul către model îi interzice să modifice valorile, intervalele, unitățile sau rezultatele calitative, iar validatorii verifică respectarea regulii. Unitatea „mg/dL” nu poate fi schimbată pentru coerență stilistică, iar „Reactiv” rămâne exact rezultatul sursă înainte de a-i fi explicat sensul.
Utilizatorul vede o previzualizare a informației extrase înainte de a continua. Verificarea nu înlocuiește controalele automate și nu transferă întreaga responsabilitate către om. Este o ocazie suplimentară de a observa imediat o pagină lipsă sau o valoare care nu corespunde documentului original.
4. De ce un singur prompt este o arhitectură fragilă
O singură cerere care solicită rezumat, corelații, explicații pentru fiecare marker, pași practici și limite face dificilă localizarea erorilor. În pipeline-ul KlarLab, narațiunea este împărțită în trei etape:
• Sinteza construiește imaginea de ansamblu, corelațiile susținute de document și contextul markerilor.
• Explicațiile detaliază rezultatele relevante și păstrează valorile sau rezultatele calitative exact.
• Ghidajul formulează întrebări pentru discuția cu medicul, fără medicamente, suplimente, doze sau modificări de tratament.
Fiecare etapă are propria schemă JSON. Pentru anumite câmpuri, lista codurilor permise este construită din documentul curent. Dacă modelul introduce un marker absent, rezultatul este respins de schemă sau de validator. La documentele dense, explicațiile sunt împărțite în loturi, iar unele etape auxiliare pot rula în paralel după ce sinteza trece controlul.
Împărțirea nu elimină erorile modelului, dar arată mai clar unde au apărut. Dacă ghidajul eșuează, etapa poate fi marcată drept degradată și stratul auxiliar este omis. Un eșec critic al sintezei oprește generarea. Este mai sigur să lipsească o componentă secundară decât să fie umplută cu text generic.
5. După răspuns urmează validarea deterministă
Un model poate primi instrucțiuni bune și totuși să le încalce. Ieșirea nu este acceptată numai pentru că respectă o schemă sintactică. Validatorii deterministici inspectează conținutul și caută abateri care pot fi depistate prin reguli repetabile.
Verificările includ codurile așteptate, coduri necunoscute sau duplicate, păstrarea exactă a unităților și valorilor, existența rezultatului calitativ, coerența dintre etichetele interne și mesajul afișat, formulări care transformă o ipoteză în diagnostic cert și recomandări care depășesc scopul educațional.
Dacă apare o problemă blocantă, etapa nu trece. Lista erorilor devine context de corecție pentru o nouă încercare, pe o rută de fallback. Reîncercarea nu repetă orbește aceeași cerere: primește motivele concrete pentru care rezultatul anterior a fost respins. Dacă nici următoarea încercare nu livrează un rezultat valid în bugetul stabilit, etapa eșuează.
6. Corelația nu este sinonimă cu diagnosticul
Corelațiile sunt utile și, în același timp, ușor de exagerat. Faptul că doi markeri apar pe același buletin nu înseamnă că formează o relație clinică. O corelație propusă de sistem folosește numai markeri existenți și trebuie să descrie un mecanism plauzibil comun sau felul în care rezultatele se susțin ori se contrazic.
Un marker izolat nu primește automat o corelație doar pentru că poate fi legat narativ de alt rezultat. Markerii aflați în interval sunt incluși numai dacă ajută la explicarea unei abateri din același document. Dacă datele nu susțin legătura, lista poate rămâne goală.
În interfață, indicatorul „Susținere în document” arată cât de bine este sprijinită o direcție explicativă de valorile disponibile. Nu estimează probabilitatea unui diagnostic. Istoricul complet, examenul clinic și investigațiile lipsă pot schimba concluzia; explicația acestui indicator apare lângă el, nu într-o notă generală.
7. Confidențialitatea începe înaintea apelului către model
Documentul original și datele derivate au trasee diferite. La verificarea și extracția inițială, furnizorul AI poate vedea informațiile prezente în pagină; KlarLab nu face redactare vizuală înainte de acest pas. Această limită trebuie spusă direct, mai ales într-un produs care procesează documente medicale.
Pentru apelurile ulterioare bazate pe text extras și date structurate, identificatorii direcți detectați — precum nume, CNP, adresă, email, telefon sau identificatori administrativi — sunt înlocuiți înainte de transmitere. Cererile OpenAI Responses folosesc store: false: setarea dezactivează păstrarea răspunsului ca stare a aplicației, dar nu înseamnă zero retention pentru toate jurnalele furnizorului.
De-identificarea textului nu redactează pixelii unei imagini și nu rezolvă singură accesul, logurile, retenția sau ștergerea. Aceste suprafețe au controale distincte. Același principiu se aplică oricărui produs sensibil: protecția trebuie implementată într-un punct comun al fluxului, iar documentația trebuie să spună exact ce acoperă și ce rămâne în afara lui.
8. Testarea include documente ostile, nu doar exemple curate
Un set format numai din scanări curate nu testează condițiile reale de utilizare. Într-o rundă internă documentată, corpusul a inclus 53 de fișiere sintetice, în cinci versiuni. Au fost simulate blur, reflexii, decupări prea strânse, rezoluție joasă, moiré, pagini goale, PDF-uri invalide, tipuri MIME declarate greșit, rezultate duplicate și instrucțiuni ostile introduse în document.
Datele sintetice oferă un adevăr de referință cunoscut și evită folosirea dosarelor reale în testele de stres. Aceeași pagină poate fi deteriorată controlat până când o cifră devine ambiguă. Corpusul este util pentru regresie, dar nu demonstrează performanța pe toate șabloanele de laborator, camerele, compresiile sau obiceiurile utilizatorilor.
Testele urmăresc separat acceptarea imaginii, numărul de rânduri extrase, valorile, unitățile, familia documentului și comportamentul în fața instrucțiunilor ostile. O explicație fluentă nu compensează pierderea unui rând. Nici extracția perfectă nu validează automat textul final. Acceptarea imaginii, extracția și explicația au criterii distincte.
9. Controlul continuă în experiența utilizatorului
Arhitectura backend poate reduce riscul, dar interfața decide cum este înțeles rezultatul. Dacă produsul afișează un indicator fără explicație, ascunde informațiile neclasificabile sau pune un avertisment important după recomandări generale, o parte din controlul tehnic se pierde în design.
În KlarLab, previzualizarea apare înaintea alegerii raportului, iar un document care nu poate fi procesat nu ajunge la checkout. Raportul separă informația extrasă, explicația, corelațiile, limitele și întrebările pentru medic. Este un produs educațional: nu pune diagnostic, nu recomandă tratament și nu face triaj de urgență. Această limită apare în backend, microcopy, ordinea secțiunilor și mesajele de eroare.
Nici acest design nu elimină eroarea. Un control de calitate poate respinge o fotografie lizibilă sau poate accepta una problematică. Un validator poate rata o formulare riscantă. Un utilizator poate acorda explicației mai multă autoritate decât are. Aceste situații sunt tratate ca moduri de eșec care se măsoară și se reduc prin testare și monitorizare.
Maturitatea AI se vede și în ceea ce produsul refuză
Lecția nu se limitează la healthtech. În financiar, juridic, educație, recrutare sau infrastructură critică reapar aceleași întrebări: cum verificăm intrarea, unde separăm faptele de inferențe, câtă autonomie acordăm modelului și ce rezultat nu acceptăm nici dacă sună convingător?
Roadmap-ul unui produs AI este, de obicei, o listă de capabilități. Într-un domeniu sensibil are nevoie și de un roadmap al refuzurilor: ce nu va automatiza produsul, în ce condiții se oprește, ce date nu transmite mai departe și ce rămâne o decizie umană.
Modelele mai bune vor reduce unele erori, dar nu vor înlocui controalele din jurul lor. În producție, diferența o fac verificarea intrării, separarea datelor de explicații, validarea ieșirii, traseele de eroare și limitele explicite ale produsului.
de Vlad Ionesi, fondator KlarLab
