Evaluarea unui AI local trebuie să arate dacă sistemul termină corect sarcinile firmei, în timpul și condițiile de acces acceptate. Un benchmark general poate orienta lista de modele, însă recepția se bazează pe cereri reprezentative și pe configurația efectiv instalată. Pentru un antreprenor, indicatorul util este rezultatul acceptat în fluxul de lucru, împreună cu timpul și resursele necesare.

Definește ce înseamnă un rezultat acceptat

Pentru un asistent de documente, rezultatul poate cere pasajul corect, versiunea potrivită și păstrarea condițiilor din text. Pentru extragere, verificăm câmpurile și calculele. Pentru programare, modificarea trebuie să respecte cerința și să treacă verificările proiectului. Criteriile sunt scrise înainte de compararea modelelor, astfel încât fiecare candidat să primească aceeași probă.

Separă erorile critice de observațiile de stil. O cantitate greșită, o informație preluată dintr-un document nepermis sau o acțiune executată de două ori pot avea un impact diferit de o frază prea lungă. Proprietarul procesului stabilește criteriile eliminatorii, iar revizorul aplică aceeași regulă tuturor rezultatelor evaluate.

Evaluarea are patru axe

  1. Corectitudine

    Rezultatul respectă datele și criteriile sarcinii.

  2. Timp

    Primul răspuns, finalizarea și revizia.

  3. Resurse

    Memorie, concurență și consum măsurat.

  4. Acces

    Documente și operațiuni autorizate.

Criteriile sunt stabilite înainte de compararea candidaților.

Construiește un set reprezentativ în română

Include cereri obișnuite, formulări alternative, termeni interni, cifre și excepții. Adaugă cazuri în care informația necesară lipsește și situații cu acces restricționat. Pentru documente, păstrează răspunsurile de referință și pasajele care le justifică. Setul trebuie să reflecte activitatea firmei, inclusiv cazurile mai rare care pot produce erori importante.

Un set demonstrativ poate avea familii distincte pentru vânzări, operațiuni și suport. Rezultatele se raportează pe familie, pentru a vedea unde funcționează bine configurația și unde este necesară o intervenție. Un total agregat poate ascunde o categorie slabă. Păstrează cazuri separate pentru verificarea finală, după alegerea parametrilor.

Mână cu un pix indicând graficele unui raport tipărit
Lukas Blazek

Fixează configurația înaintea măsurării

Fișa testului include calculatorul, RAM, GPU și memoria video, sistemul, driverul și motorul. Adaugă modelul, artefactul, cuantizarea, contextul, setările de generare și cererile active. Pentru RAG se păstrează și versiunea colecției, modelul de embeddings și regulile de căutare. Aceste informații permit identificarea schimbării care a produs un rezultat diferit.

O comparație între două modele pe aceeași stație este diferită de o comparație între două calculatoare. Alege variabila pe care o schimbi și menține celelalte condiții relevante. Dacă se schimbă și cuantizarea, acest lucru apare explicit în raport. Configurațiile trebuie comparate în forma în care vor fi folosite, cu resursele necesare aplicației incluse.

Măsoară primul răspuns și operațiunea completă

Timpul până la primul text ajută la evaluarea interactivității. Timpul până la rezultatul utilizabil include pregătirea datelor, căutarea, generarea și validarea. Într-un flux cu instrumente se adaugă executarea autorizată și verificarea rezultatului. Măsoară aceste intervale din perspectiva utilizatorului, nu doar în interiorul motorului.

În Ollama, răspunsul API poate include load_duration, prompt_eval_duration, eval_count și eval_duration. Duratele sunt documentate în nanosecunde. Viteza generării se poate calcula ca eval_count / eval_duration × 1.000.000.000. Această valoare descrie etapa de generare și se păstrează separat de durata completă a cererii.

Exemplu aritmetic pentru viteza generării

  1. Tokeni generați

    120, aleși pentru acest exemplu.

  2. Durată

    6.000.000.000 ns = 6 secunde.

  3. Calcul

    120 ÷ 6 = 20 tokeni/secundă.

Exemplu demonstrativ de conversie a duratei și calcul al vitezei de generare.

Separă pornirea la rece de rularea cu modelul încărcat

După pornire, prima cerere poate include încărcarea ponderilor. O cerere ulterioară poate folosi modelul deja în memorie și unele date cache. Notează starea modelului și ordinea probelor. Un rezultat rapid cu modelul încărcat și un rezultat după restart răspund unor întrebări operaționale diferite, utile pentru planificarea serviciului.

Alege un protocol repetabil, de exemplu trei rulări pentru fiecare condiție a pilotului, și păstrează toate valorile. Raportează mediana și variația observată, alături de datele brute. Evită selectarea numai a celei mai rapide rulări. La schimbări de sistem, repetă aceeași probă și explică exact ce versiuni sau parametri au fost modificați.

Testează contextul și utilizatorii simultani

Creșterea lungimii documentului poate modifica memoria și durata prelucrării chiar dacă răspunsul final este scurt. Compară sarcini cu documente scurte și lungi, păstrând criteriul de acceptare. Verifică dacă aplicația a inclus informația necesară și dacă a trunchiat intrarea. Un răspuns corect la începutul unui document nu verifică automat întregul flux pentru fișiere mai mari.

Pentru o echipă, începe cu o cerere activă și adaugă niveluri controlate de concurență. Înregistrează coada, durata fiecărui utilizator, memoria maximă și erorile. Limita de operare este aleasă pentru nivelul care respectă cerințele firmei. Numărul de conturi și numărul de cereri procesate pe minut rămân indicatori diferiți.

De la măsurare la decizie

  1. Referință

    Configurație și teste păstrate.

  2. Candidat

    O schimbare identificată și aceleași probe.

  3. Comparație

    Calitate, timp, resurse și cazuri critice.

  4. Adoptare

    Versiune aprobată și posibilitate de revenire.

Toate rulările și condițiile relevante rămân în evidență.

Calculează timpul până la un rezultat acceptat

Adaugă timpul de revizie și corectare la timpul tehnic. Un model care generează mai repede poate cere mai multă muncă pentru aprobarea rezultatului. Pentru comparare, păstrează numărul cazurilor acceptate, cazurile trimise la revizie și erorile critice. O schimbare a regulii de acceptare trebuie documentată și aplicată coerent comparației.

Verifică și oprirea serviciului, accesul refuzat și reluarea unei sarcini. Rezultatul recepției cuprinde configurația, probele, observațiile și decizia pentru utilizarea propusă. Aceste date devin o referință pentru actualizări. O versiune nouă de model sau de motor trece prin aceeași verificare înainte de schimbarea sistemului folosit de echipă.

Un protocol practic de comparație

Pregătește o fișă pentru fiecare caz, cu intrarea, rezultatul așteptat și regula de acceptare. Ascunde numele candidatului față de revizor atunci când evaluarea presupune aprecierea textului. Păstrează în raport identificatorul complet pentru reproducere, dar separă-l de formularul de notare. Astfel, preferința pentru o marcă are mai puține ocazii să influențeze lectura rezultatului.

Înregistrează și ordinea rulărilor, starea cache-ului și aplicațiile care rulează pe stație. Dacă un test este întrerupt de o activitate neplanificată, păstrează proba și motivul separat de seria principală. Când repeți, folosește aceleași condiții definite în protocol. Raportul arată atât datele brute, cât și criteriul folosit pentru alegerea configurației de operare.

WebHat folosește un sistem AI local personalizat și oferă consultanță pentru definirea probelor și alegerea configurației potrivite firmei. Evaluarea poate fi inclusă într-un proiect de aplicație custom cu AI. Pentru cazurile cu informații interne, se verifică împreună calitatea rezultatului și controlul accesului la date.

Întrebări despre evaluarea unui AI local

Este suficient numărul de tokeni pe secundă?

El măsoară o etapă. Recepția include corectitudinea, primul răspuns, durata rezultatului complet, revizia și comportamentul aplicației.

Cum comparăm două configurații?

Cu aceleași sarcini, criterii și condiții relevante. Raportul identifică fiecare diferență de model, cuantizare, context, hardware sau versiune.

De ce păstrăm și rezultatele slabe?

Ele arată variația și cazurile în care sistemul cere corecții. Decizia de operare trebuie să includă aceste situații și costul lor.

Când repetăm recepția?

După schimbări relevante de model, motor, date, acces sau hardware. Păstrăm referința anterioară și comparăm înainte de activarea noii configurații.