AI evaluacija u praksi: Kako odabrati model koji radi posao

Priznajem, prvi put kada sam implementirao LLM (Large Language Model) u produkciju, napravio sam klasičnu početničku grešku: odabrao sam najskuplji model na tržištu pretpostavljajući da ‘najveći’ znači ‘najbolji’ za svaki zadatak. Tri sedmice kasnije, moj CFO me je pozvao na razgovor jer smo potrošili 4.000 dolara na API pozive za zadatak koji je mogao obaviti model deset puta jeftiniji, a uz to smo imali ogroman problem sa nekonzistentnošću. Napisao sam ovaj vodič kako biste izbjegli skupe greške i naučili kako naučno pristupiti odabiru AI modela koji zaista rješava vaše poslovne probleme.

Prerequisites: Tehnološki stog za evaluaciju

Prije nego što uopšte počnete testirati modele, potreban vam je stabilan setup. Evaluacija nije samo ‘pitanje i odgovor’ u ChatGPT interfejsu; to je inženjerski proces. Za ozbiljnu evaluaciju trebat će vam: Python 3.10+, API ključevi za provajdere (OpenAI, Anthropic, Google Vertex AI), te biblioteke kao što su Ragas (za RAG evaluaciju) ili DeepEval. Također, neophodno je imati spreman set ‘zlatnih podataka’ (ground truth) – skup od najmanje 50-100 parova pitanja i idealnih odgovora koje su verifikovali stručnjaci iz domene.

Šta je hallucination u AI modelima i kako je mjeriti?

Jedan od najvećih rizika pri odabiru modela je fenomen poznat kao halucinacija. Šta je hallucination u AI modelima? To je situacija u kojoj model generiše informaciju koja je gramatički ispravna i uvjerljiva, ali činjenično netačna ili neutemeljena u pruženom kontekstu. U praksi, to može značiti da će vaš AI psihoterapeut (hipotetički model za podršku) izmisliti medicinsku studiju ili da će sistem za automatizaciju koda generisati funkcije koje ne postoje. [IMAGE_PLACEHOLDER] Da biste mjerili halucinacije, morate koristiti metriku Faithfulness (vjernost izvoru). Ako model koristi eksterne podatke (RAG), mjerimo koliko procenata tvrdnji u odgovoru se direktno može mapirati nazad na izvorne dokumente.

Kako se detektuje i rešava data imbalance problem u evaluaciji?

Često se dešava da testni set podataka nije reprezentativan. Kako se detektuje i rešava data imbalance problem? Ako vaš dataset za testiranje sadrži 90% jednostavnih upita i samo 10% kompleksnih rubnih slučajeva (edge cases), vaši rezultati evaluacije će biti vještački visoki. Detekcija se vrši klasterizacijom testnih primjera – ako vidite da većina upita pripada istoj semantičkoj grupi, imate debalans. Rješenje je Synthetic Data Generation gdje koristite jači model (poput GPT-4o) da generiše teške, rijetke primjere kako biste ‘stresirali’ modele koje evaluirate. Bez balansiranog dataseta, izabrat ćete model koji dobro rješava trivijalne stvari, a puca pod pritiskom u produkciji.

The Configuration: Korak po korak proces evaluacije

[Visual Cue]: U vašem razvojnom okruženju, navigirajte do foldera /evals i kreirajte novu skriptu compare_models.py. Prvi korak je definisanje metrika. Ne fokusirajte se samo na preciznost, već i na latenciju (brzinu) i cijenu po tokenu.

from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

# Definisanje metrike
metric = FaithfulnessMetric(threshold=0.7)
test_case = LLMTestCase(
    input="Koji su uslovi za otvaranje firme u BiH?",
    actual_output="Potrebna je lična karta i 2000 KM.",
    retrieval_context=["Zakon o privrednim društvima nalaže posjedovanje identifikacionog dokumenta..."]
)

metric.measure(test_case)
print(f'Score: {metric.score}')

Ovaj kod vam omogućava da automatizujete provjeru. Ako model dobije score ispod 0.7, on automatski pada na testu za taj specifičan slučaj. Ponovite ovo za 5 različitih modela (npr. Llama 3, Claude 3.5, GPT-4o-mini) i uporedite rezultate u tabeli.

Deep Review: Under the Hood evaluacijskih algoritama

Moderni sistemi evaluacije koriste koncept ‘LLM-as-a-judge’. To znači da koristite jedan, superiorniji model da ocjenjuje rad manjih modela. Iako zvuči kao naučna fantastika, ovo je trenutno najprecizniji način za mjerenje subjektivnih kvaliteta kao što su ‘ton komunikacije’ ili ‘korisnost’. Međutim, pazite na positional bias – sudija model često daje prednost prvom ponuđenom odgovoru ili dužem odgovoru, čak i ako nije tačniji.

Troubleshooting: Šta kada su svi modeli loši?

Ako vaša evaluacija pokazuje loše rezultate na svim modelima, problem vjerovatno nije u modelima, već u Prompt Engineering-u ili Data Imbalance problemu koji smo pomenuli. Provjerite da li su instrukcije jasne. Ako model ‘halucinira’, pokušajte dodati Chain-of-Thought (CoT) instrukciju: ‘Razmišljaj korak po korak prije nego što daš konačan odgovor’. Također, provjerite sistemske logove za Error 429 (Rate Limit) koji može prekinuti proces evaluacije i dati vam lažne ‘nule’ u rezultatima.

Optimizacija i finalni odabir

Kada dobijete podatke, koristite Pareto Frontier analizu. Tražite model koji nudi najbolji balans između cijene i performansi. Za zadatke kao što je proceduralno generisanje igara ili kompleksno programiranje, možda će vam trebati najskuplji model. Ali za klasifikaciju mailova ili ekstrakciju podataka, manji modeli poput GPT-4o-mini će raditi posao identično dobro za dio cijene. Evaluacija nije jednokratan posao; to je kontinuirani proces koji se ponavlja sa svakim novim ažuriranjem modela na tržištu.