RO
English (English)
Alegerea unui model lingvistic mare nu ar trebui să înceapă cu întrebarea „care este cel mai inteligent model?”. Pentru o companie, întrebarea utilă este: care este cel mai mic, mai predictibil și mai ușor de administrat model care îndeplinește cerințele unei sarcini concrete?
Un model excelent la programare poate fi inutil de scump pentru clasificarea mesajelor. Un model rapid poate rata excepțiile dintr-un contract. Un model care obține scoruri mari pe teste internaționale poate formula nefiresc în limba română sau poate interpreta greșit date, sume și denumiri locale.
De aceea, alegerea corectă nu este un concurs între furnizori. Este un proces de achiziție și inginerie: definim sarcina, riscul și bugetul, construim un set de teste apropiat de activitatea reală, comparăm variantele și monitorizăm rezultatul după lansare.
Ideea centrală: nu căutăm un singur LLM pentru întreaga firmă. Alegem un profil de model pentru fiecare categorie de sarcini și păstrăm posibilitatea de a-l înlocui.
Un LLM, de la „large language model”, este un model antrenat să proceseze și să genereze limbaj. Aplicația folosită de angajați sau clienți conține însă mai mult decât modelul: instrucțiuni, documente recuperate prin RAG, instrumente, reguli de business, filtre, aprobări și interfața cu utilizatorul.
Când evaluăm o soluție, trebuie să distingem trei niveluri:
Această distincție contează. O problemă de calitate nu se rezolvă întotdeauna prin trecerea la un model mai mare. Uneori lipsesc documentele corecte, instrucțiunile sunt ambigue, schema de date este slabă sau modelului i s-a permis să ia o decizie pe care ar fi trebuit doar să o propună.
Cataloagele comerciale actuale includ, în general, mai multe clase de modele: modele de vârf pentru sarcini dificile, modele echilibrate pentru utilizare curentă, modele compacte pentru volum mare și modele specializate pentru cod, voce, imagini, OCR, căutare semantică sau moderare. Cataloagele oficiale ale OpenAI, Anthropic, Google și Mistral AI ilustrează această fragmentare.
Aceasta este o fotografie datată, nu un clasament. Denumirile, prețurile, limitele și disponibilitatea se modifică frecvent. Documentația furnizorilor include pagini separate pentru retrageri și migrări, iar cataloagele conțin deja familii și versiuni retrase. O alegere tehnică serioasă trebuie să includă identificatorul exact al versiunii testate, data evaluării și o procedură de migrare.
În același timp, „open-weight” și „open-source” nu sunt sinonime. Un model open-weight oferă acces la parametrii învățați, dar licența, codul de antrenare și informațiile despre date pot rămâne restrictive sau incomplete. Open Source AI Definition 1.0 cere libertatea de utilizare, studiere, modificare și distribuire, împreună cu acces la forma preferată pentru modificare, inclusiv informații despre date, cod și parametri. Pentru o companie, licența trebuie verificată separat de disponibilitatea fișierelor modelului.
Benchmarkurile publice sunt utile pentru alcătuirea unei liste scurte. Nu pot decide însă singure ce model trebuie cumpărat.
Lucrarea HELM, Holistic Evaluation of Language Models arată de ce evaluarea trebuie să folosească mai multe scenarii și mai multe dimensiuni, nu doar acuratețea. HELM măsoară, între altele, robustețea, calibrarea, echitatea, toxicitatea și eficiența. NIST AI 600-1 avertizează că testele de laborator și benchmarkurile pot să nu reflecte contextul real de utilizare și recomandă evaluarea performanței în scenarii practice.
Un scor public poate induce în eroare din mai multe motive:
Pentru limba română, testarea internă este obligatorie. Evaluarea trebuie să includă diacritice, nume de persoane și localități, formate românești de dată și număr, lei și euro, formule de adresare, texte fără diacritice, greșeli reale de tastare și terminologia companiei.
LLM-urile sunt potrivite când intrarea este ambiguă, predominant textuală sau vizuală, iar rezultatul necesită interpretare, reformulare ori sinteză. Nu sunt prima alegere pentru orice automatizare.
O regulă deterministă, o interogare SQL, un validator de schemă sau un motor de căutare clasic sunt adesea mai ieftine și mai verificabile pentru:
LLM-ul poate interpreta cererea și propune acțiunea, dar regulile de business trebuie să valideze rezultatul înainte de execuție.
Înainte de a testa modele, descriem sarcina într-o pagină. Fără această fișă, comparația devine o colecție de impresii.
Fișa minimă trebuie să răspundă la următoarele întrebări:
Exemplu: „Clasifică mesajul clientului într-una dintre cele 12 categorii, extrage numărul comenzii și returnează JSON valid în maximum două secunde. Dacă numărul nu apare, returnează null. Nu răspunde clientului.”
Aceasta este o sarcină testabilă. „Folosește AI pentru suport” nu este.
Criteriile eliminatorii se verifică înaintea calității. Dacă un furnizor nu poate respecta cerințele de date, licență sau disponibilitate, un scor mai bun nu îl face potrivit.
Inventariem datele care pot ajunge în sistem:
Pentru serviciile administrate verificăm contractual și tehnic: utilizarea datelor pentru antrenare, perioada de retenție, regiunea de procesare, subcontractorii, acordul de prelucrare, ștergerea, jurnalizarea, criptarea, controlul accesului și răspunsul la incidente. Principiile de limitare a scopului și minimizare a datelor din Regulamentul general privind protecția datelor rămân relevante indiferent de popularitatea furnizorului.
Găzduirea locală poate reduce expunerea către un API extern, dar nu elimină riscul. Compania devine responsabilă pentru configurare, actualizări, acces, copii de siguranță, vulnerabilități și jurnale.
Pentru modelele descărcabile verificăm:
„Disponibil gratuit” nu înseamnă automat „fără cost” sau „fără restricții”.
Cerem răspuns pentru:
O listă scurtă sănătoasă conține modele din două sau trei clase, nu zece variante aproape identice.
| Profil | Potrivit pentru | Principalul compromis |
| --- | --- | --- |
| Compact și rapid | clasificare, extragere simplă, răspunsuri repetitive, volum mare | cedează mai repede la ambiguitate și excepții |
| Generalist echilibrat | suport intern, redactare, sinteză, RAG, apeluri de instrumente | nu este optim pentru fiecare specialitate |
| Raționament avansat | analiză cu mai mulți pași, cod dificil, planificare și verificare | cost și latență mai mari |
| Specializat | OCR, transcriere, embeddings, cod, moderare sau domenii înguste | acoperire redusă în afara specializării |
| Open-weight găzduit intern | control operațional, procesare locală, personalizare | infrastructură, mentenanță și responsabilitate proprie |
| API administrat | lansare rapidă, scalare și acces la modele noi | dependență de furnizor și condiții contractuale |
Aceste profiluri sunt categorii de proiectare, nu afirmații că un model anume va reuși într-o companie. Confirmarea vine din test.
Pentru un pilot de IMM, un set inițial de 50 până la 200 de cazuri bine alese este, de regulă, mai util decât mii de întrebări generice. Dimensiunea exactă depinde de variația și riscul procesului.
O distribuție practică poate fi:
Setul trebuie extras, unde este legal, din munca reală și anonimizat. Păstrăm separat un lot pe care nu îl folosim pentru ajustarea promptului. Altfel, optimizăm sistemul pentru test și supraestimăm performanța.
Pentru fiecare caz definim:
Un singur procent nu este suficient. Urmărim cel puțin patru grupe de indicatori.
NIST include confabulația, confidențialitatea, securitatea informației și integrarea componentelor în lista riscurilor relevante pentru AI generativ. Documentul recomandă testare înainte de lansare, verificarea surselor și monitorizare continuă.
Media poate ascunde experiențe proaste. Pentru un asistent interactiv, p95 este deseori mai important decât cea mai bună demonstrație.
Costul unui API nu este doar prețul unui milion de tokeni. O estimare lunară simplificată este:
număr cereri × cost mediu intrare și ieșire + instrumente + stocare + observabilitate + revizie umană + costul erorilor
Pentru găzduire proprie adăugăm:
Indicatorul mai util decât „cost per token” este costul per rezultat acceptat. Un model ieftin care necesită două reluări și zece minute de corectură poate costa mai mult decât unul cu tarif superior.
Ponderile trebuie stabilite înainte de rezultate. Altfel, există tentația de a modifica regulile pentru modelul preferat.
Exemplu pentru un asistent intern care răspunde din procedurile companiei:
| Criteriu | Pondere | Prag eliminatoriu |
| --- | ---: | --- |
| Corectitudine pe setul intern | 30% | fără erori critice |
| Citarea și folosirea surselor | 15% | minimum 95% citări valide |
| Limba română | 10% | fără ambiguități operaționale |
| Confidențialitate și contract | 15% | toate cerințele obligatorii |
| Latență p95 | 10% | sub limita procesului |
| Cost per rezultat acceptat | 10% | în bugetul aprobat |
| Integrare și observabilitate | 5% | jurnale și versiuni identificabile |
| Continuitate și portabilitate | 5% | alternativă documentată |
Valorile sunt un scenariu orientativ, nu un standard universal. Pentru generarea de texte de marketing poate crește ponderea stilului. Pentru extragerea din facturi, validitatea structurii și acuratețea câmpurilor devin dominante. Pentru un agent care poate iniția plăți, pragurile de securitate, autorizare și aprobare umană trebuie să fie mult mai stricte.
Fereastra de context reprezintă cantitatea maximă de intrare și ieșire pe care modelul o poate procesa într-o cerere, măsurată de obicei în tokeni. Tokenii sunt fragmente de text, nu cuvinte întregi.
O fereastră mare ajută la documente lungi, dar nu dovedește că modelul găsește și folosește corect fiecare informație. Studiul Lost in the Middle a observat degradări când informația relevantă se afla în mijlocul unui context lung, chiar la modele declarate pentru context extins.
În practică, testăm:
RAG poate selecta fragmente relevante înaintea generării și poate reduce contextul inutil. Nu repară însă automat documente greșite, permisiuni slabe sau o metodă de căutare nepotrivită.
Pentru primul pilot, un singur model implicit și unul de rezervă sunt mai ușor de administrat. După ce există măsurători, compania poate introduce rutare.
Trei arhitecturi uzuale sunt:
Cercetările FrugalGPT și RouteLLM arată că selectarea dinamică sau în cascadă poate îmbunătăți raportul cost-calitate în configurațiile studiate. Aceste rezultate nu garantează aceeași economie într-un proces local. Ele justifică testarea rutării după ce avem o bază de evaluare și suficiente cereri reale.
O regulă de rutare trebuie să poată explica de ce a ales un model, să aibă limite de cost și să escaladeze când încrederea este mică. Pentru acțiuni importante, escaladarea finală rămâne către un om.
Începem cu un model compact. Cerem etichete dintr-o listă închisă și JSON valid. Măsurăm acuratețea pe categorii, nu doar media, deoarece o categorie rară poate fi critică. Dacă scorul de încredere este mic sau mesajul conține mai multe intenții, escaladăm.
Alegem un generalist bun la respectarea instrucțiunilor și citarea contextului, conectat la RAG. Testăm întrebări fără răspuns și documente conflictuale. Modelul trebuie să spună când sursele nu sunt suficiente, nu să completeze golul din cunoștințe generale.
Comparăm un model multimodal sau OCR specializat cu o combinație OCR clasic plus model lingvistic. Validăm fiecare câmp prin reguli deterministe: totaluri, monedă, CUI, TVA și date. Câmpurile cu încredere redusă merg la revizie umană.
Folosim teste automate, analiză statică și revizie, nu doar preferința dezvoltatorului pentru un răspuns. Măsurăm proporția de taskuri rezolvate, regresiile, vulnerabilitățile introduse, timpul total și costul. Accesul la shell, repository și producție trebuie separat prin permisiuni și aprobări.
Acestea sunt scenarii de proiectare. Modelul câștigător poate fi diferit pentru fiecare companie și chiar pentru două procese similare din aceeași firmă.
Un pilot restrâns poate urma acest ritm:
Definim rezultatul, utilizatorii, datele, riscurile, volumul, bugetul și pragurile de acceptare.
Colectăm și anonimizăm cazurile, adăugăm excepții și stabilim evaluarea de referință cu experții procesului.
Rulăm aceleași intrări, aceleași instrucțiuni și aceleași instrumente pe modelele din lista scurtă. Fixăm versiunea și parametrii. Evaluatorii nu trebuie să știe ce model a produs fiecare răspuns, când acest lucru este posibil.
Sistemul primește copii ale cererilor reale, dar rezultatele sale nu produc efecte. Comparăm cu deciziile oamenilor și căutăm erori care nu apăreau în setul inițial.
Un grup mic folosește sistemul cu aprobare umană. Stabilim bugete, alerte, oprire rapidă și canal pentru incidente.
La final, decizia nu este doar „lansăm” sau „nu lansăm”. Putem lansa pentru categoriile sigure, păstra revizia pentru excepții și amâna funcțiile cu risc ridicat.
Fișa modelului folosit în companie trebuie să conțină:
Reevaluăm la modificarea modelului, a promptului, a surselor RAG, a instrumentelor sau a procesului. Monitorizăm rata de acceptare, corecturile, incidentele, latența, consumul și distribuția tipurilor de cereri. Un model poate rămâne neschimbat, dar datele și comportamentul utilizatorilor se modifică.
Modelul potrivit nu este cel care impresionează într-o demonstrație, ci cel care produce constant rezultate acceptabile în condițiile, limba, bugetul și limitele de risc ale companiei.
Pentru majoritatea IMM-urilor, strategia realistă este:
Alegerea unui LLM este o decizie reversibilă doar dacă aplicația, datele și evaluările au fost proiectate pentru portabilitate. În lipsa lor, schimbarea unei denumiri de model poate deveni un nou proiect.
Vrei să alegem și să testăm modelele potrivite pentru procesele companiei tale, cu criterii clare de cost, calitate și risc? Discută cu noi despre un audit sau un pilot controlat.