Evaluation: model-i ölçmək

Əvvəlki fəsillərdə model-i train etməyi, post-training etməyi və serve etməyi öyrəndik. Bunların hər biri qərarlar tələb edir: hansı checkpoint daha yaxşıdır, quantization keyfiyyəti pozdumu, yeni data qarışığı kömək etdimi. Bu suallara cavab verən yeganə alət evaluation-dır. Foundation model mühəndisliyində ən çox vaxt aparan və ən çox səhv edilən iş də budur. Bu fəsil evaluation-ın fundamental anlayışlarını verir. Kitabın qalan hissələrində (fine-tuning, RAG, agent-lər) hər şey bu anlayışların üzərində qurulacaq.

Evaluation niyə ən çətin hissədir

Klassik machine learning-də test set və bir metrik adətən kifayət edirdi: accuracy, F1, AUC. Foundation model-lərdə bu sadəlik yoxdur, çünki:

Çıxış açıq formalıdır. Bir sualın onlarla düzgün cavabı ola bilər və onlar söz-söz üst-üstə düşmür.
Qabiliyyətlər çoxölçülüdür. Model kodda yaxşılaşıb təlimatlara əməl etməkdə pisləşə bilər. Tək rəqəm bu dəyişikliyi gizlədir.
Model prompt-a həssasdır. Format, nümunələrin sırası, hətta boşluq simvolları nəticəni bir neçə bal dəyişə bilər.
Test data training data-ya sızır. İnternet miqyasında pretraining olunan model ictimai benchmark-ları görmüş ola bilər.

Nəticədə "model X benchmark-da 85% aldı" cümləsi tək başına az məlumat verir. Evaluation-ı mühəndislik problemi kimi qurmaq lazımdır.

Perplexity və tapşırıq metrikləri

Perplexity model-in held-out mətnə nə qədər "təəccübləndiyini" ölçür. Bu, orta cross-entropy loss-un eksponentidir:

perplexity = exp( -(1/N) × Σ log p(token_i | əvvəlki token-lər) )

Pretraining zamanı bu, əsas siqnaldır (Fəsil 5). Ucuzdur, stabil hesablanır və scaling law-lar onunla ifadə olunur. Amma məhdudiyyətləri var. Fərqli tokenizer-li model-lərin perplexity-si birbaşa müqayisə edilə bilməz. Post-training-dən sonra isə perplexity faydalılıqla zəif korrelyasiya edir: RLHF keçmiş assistant model ümumi mətndə daha yüksək perplexity göstərə bilər, halbuki istifadəçi üçün xeyli yaxşıdır.

Ona görə base model-lər üçün perplexity faydalıdır. Assistant və domain model-lər üçün isə tapşırıq metrikləri lazımdır: model real tapşırığı yerinə yetirirmi?

Əsas metriklər

Exact match. Normalizasiyadan sonra (kiçik hərf, punktuasiya, artikllər) cavab etalonla tam üst-üstə düşürmü. Qısa faktlar, riyazi cavablar və multiple choice üçün uyğundur.
Token-level F1. Cavab və etalon token çoxluqları arasında precision və recall hesablanır. Qismən düzgün cavablara qismən bal verir.
pass@k. Kod üçün standartdır. Model k nümunə yaradır və onlardan ən azı biri unit test-ləri keçirsə tapşırıq həll olunmuş sayılır. Variance-ı azaltmaq üçün n > k nümunə yaradılır, c düzgün nümunə sayılır və unbiased estimator istifadə olunur:

from math import comb

def pass_at_k(n, c, k):
    if n - c < k:
        return 1.0
    return 1 - comb(n - c, k) / comb(n, k)

Bu metriklərin ümumi xüsusiyyəti verifiable olmalarıdır: cavabı proqram yoxlaya bilir. Fəsil 6-da gördük ki, reasoning model-lərin RL training-i də məhz belə yoxlanıla bilən mükafatlara əsaslanır. Mümkün olduqca evaluation-ı verifiable formaya salın: cavabı strukturlaşdırılmış formatda tələb edin, test yazın, deterministik checker qurun.

Benchmark ailələri və saturation

İctimai benchmark-lar model-ləri müqayisə etmək üçün ortaq dildir. Əsas ailələr bunlardır:

Knowledge: geniş fənlər üzrə multiple choice suallar (MMLU, MMLU-Pro, GPQA kimi).
Reasoning və riyaziyyat: çoxaddımlı məsələlər, olimpiada səviyyəli tapşırıqlar (GSM8K, MATH, AIME).
Code: funksiya yazmaq və ya real repository-də issue həll etmək (HumanEval, LiveCodeBench, SWE-bench).
Long-context: uzun sənəddə məlumat tapmaq və onu birləşdirmək. "Needle in a haystack" testinin daha çətin variantları (RULER kimi) buraya aiddir.
Agentic: model-in tool-larla çoxaddımlı tapşırıqları yerinə yetirməsi, məsələn veb naviqasiya, terminal işi və ya müştəri xidməti simulyasiyası.

Hər benchmark-ın həyat dövrü var. Çıxır, model-lər tədricən yaxşılaşır, nəhayət yuxarı hədd ~90%+ olur və benchmark artıq model-ləri bir-birindən ayıra bilmir. Buna saturation deyilir. GSM8K və HumanEval artıq bu mərhələdədir. Saturated benchmark-da 1–2 ballıq fərq çox vaxt səs-küydür, bəzən isə etalon cavabların özündəki səhvləri əks etdirir. Ona görə sahə daim daha çətin və ya mütəmadi yenilənən benchmark-lara keçir.

Contamination

Fəsil 4-də gördük ki, pretraining data-sı internetdən toplanır və dedup prosesi benchmark-ları avtomatik təmizləmir. Test sualları training data-ya düşübsə, model həll etməyi yox, xatırlamağı nümayiş etdirir. Buna contamination deyilir.

Əlamətlər və müdafiə yolları:

N-gram overlap. Test nümunələri ilə training korpusu arasında uzun n-gram üst-üstə düşmələrini axtarın. Öz data-nızı nəzarətdə saxlayırsınızsa, bu, ən birbaşa yoxlamadır.
Perturbation test. Sualdakı rəqəmləri və adları dəyişin, variantların sırasını qarışdırın. Nəticə kəskin düşürsə, model nümunəni əzbərləyib.
Zamana görə ayrılmış data. Model-in training cutoff-undan sonra yaradılmış tapşırıqlar contamination-a qarşı ən güclü müdafiədir. LiveCodeBench kimi benchmark-lar bu prinsiplə işləyir.
Private held-out set. Heç vaxt internetə çıxmayan öz test set-iniz.

Praktik nəticə: ictimai benchmark-lar model seçimində ilkin filtrdir, son qərar üçün isə öz eval set-iniz lazımdır.

LLM-as-judge

Açıq formalı cavabları (xülasə, izah, söhbət) exact match ilə ölçmək olmur. İnsan qiymətləndirməsi isə baha və yavaşdır. Kompromis güclü bir model-dən hakim kimi istifadə etməkdir: ona sual, cavab, lazım gələrsə etalon və konkret rubric verilir, o da bal və ya müqayisə nəticəsi qaytarır.

LLM hakimlərin sistematik bias-ları var:

Position bias. Pairwise müqayisədə hakim birinci (bəzən ikinci) cavaba üstünlük verir. Mitigation: hər cütü iki sırada qiymətləndirin və yalnız ardıcıl nəticələri qəbul edin.
Verbosity bias. Uzun cavablar daha yaxşı görünür. Mitigation: rubric-də uzunluğun özünün üstünlük olmadığını açıq yazın, uzunluğu ayrıca izləyin.
Self-preference. Model öz ailəsinin üslubunda yazılmış cavabları yüksək qiymətləndirir. Mitigation: hakimi qiymətləndirilən model-lərdən fərqli ailədən seçin və ya bir neçə hakimin nəticəsini birləşdirin.

Ən vacib addım hakimi kalibrasiya etməkdir. Kiçik bir set-i (50–200 nümunə) insanlar qiymətləndirir. Sonra hakimin insanlarla razılaşma dərəcəsi ölçülür və rubric bu dərəcə qənaətbəxş olana qədər düzəldilir. Kalibrasiya olunmamış hakim sadəcə başqa bir yoxlanılmamış model-dir. Mümkün olanda 1–10 kimi mütləq bal əvəzinə binary meyarlar ("cavab mənbəyə istinad edirmi?", "rəqəm düzgündürmü?") istifadə edin. Onlar daha sabitdir.

İnsan qiymətləndirməsi və pairwise müqayisə

İnsanlara mütləq bal verdirmək ziddiyyətli nəticələr verir: bir nəfərin "7"-si başqasının "5"-idir. Pairwise müqayisə daha etibarlıdır: eyni sual üçün iki anonim cavab göstərilir və "hansı daha yaxşıdır?" soruşulur. Çoxlu belə müqayisədən Elo və ya Bradley-Terry modeli ilə hər model üçün reytinq hesablanır. Bu, şahmat reytinqi ilə eyni ideyadır. Açıq arena tipli leaderboard-lar bu üsulla işləyir.

Bu yanaşmanın da zəif tərəfləri var. Arena istifadəçiləri real istifadə paylanmasını əks etdirməyə bilər, üslub və formatlama isə məzmundan çox təsir göstərir. Model-lər bu üslubu optimallaşdırmağa başlayanda reytinq faydalılıqdan uzaqlaşır. Bu, Goodhart qanununun klassik nümunəsidir: ölçü məqsədə çevriləndə yaxşı ölçü olmaqdan çıxır.

Öz eval set-inizi qurmaq

Domain model-lər üçün ən dəyərli aktiv öz eval set-inizdir. Onu qurmaq üçün:

Real istifadədən başlayın. Log-lardan, istifadəçi suallarından, ekspertlərin real tapşırıqlarından nümunə götürün. Uydurulmuş suallar real paylanmanı əks etdirmir.
Kateqoriyalara bölün. Tapşırıq tipləri, çətinlik səviyyələri, tez-tez rast gəlinən və nadir hallar. Ümumi rəqəm sabit qalarkən bir kateqoriyada regressiya ola bilər.
Etalon və yoxlama üsulunu yazın. Hər nümunə üçün ya verifiable cavab, ya da hakim üçün rubric hazırlayın.
Failure-ları əlavə edin. Production-da hər yeni səhv tipi eval set-ə yeni nümunə kimi düşür. Set zamanla canlı regressiya test toplusuna çevrilir.
Training data-dan ayrı saxlayın. Eval nümunələrinin fine-tuning data-sına sızmaması üçün ayrıca saxlanılan və version-lanan set qurun.

Başlamaq üçün 100–300 yaxşı seçilmiş nümunə minlərlə təsadüfi nümunədən daha faydalıdır.

Statistik əhəmiyyət və variance

200 suallıq set-də 70% accuracy alan model-in standart xətası təxminən belədir:

SE = sqrt(p × (1 - p) / n) = sqrt(0.7 × 0.3 / 200) ≈ 0.032

95% confidence interval ≈ 70% ± 6.4%

Yəni 70%-dən 73%-ə qalxmaq bu set-də sübut deyil. Variance-ın digər mənbələri də var: sampling temperature, random seed, prompt formatı. Ona görə:

Nəticəni bir neçə seed ilə və ya temperature > 0 olanda hər nümunə üçün bir neçə cavabla ölçün və ortalamanı götürün.
Eyni sual set-ində iki model-i müqayisə edəndə paired test istifadə edin (məsələn, nümunələr üzrə bootstrap). Bu, müstəqil müqayisədən daha həssasdır.
Kiçik prompt dəyişikliklərinə həssaslığı ayrıca ölçün. Nəticə 2–3 ekvivalent prompt variantında sabit qalmırsa, ona etibar etməyin.
Confidence interval-ı nəticə ilə birlikdə yazın.

Eval-driven development

Bütün bunlar bir iş dövrünə birləşir:

Tapşırığı və uğur meyarını müəyyən edin.
Hər hansı dəyişiklikdən əvvəl eval set və baseline qurun.
Bir dəyişiklik edin: prompt, data, hyperparameter, quantization, model.
Eval-ı işə salın, nəticəni kateqoriyalar üzrə və confidence interval ilə oxuyun.
Failure-lara əllə baxın. Rəqəmlər nə baş verdiyini, nümunələr niyə baş verdiyini göstərir.
Qəbul edin və ya geri qaytarın. Yeni failure tiplərini eval set-ə əlavə edin.

Bu dövr software mühəndisliyindəki test-driven development-in foundation model analoqudur. Onsuz hər dəyişiklik təxmindir.

Fundament tamamlandı

Bu fəsillə Hissə I bitir. İndi model-in necə öyrəndiyini (Fəsil 1), dünyanı vektorlarla necə təmsil etdiyini (Fəsil 2), transformer-in içəridən necə işlədiyini (Fəsil 3), data-nın necə hazırlandığını (Fəsil 4), pretraining-in necə miqyaslandığını (Fəsil 5), base model-in assistant-a necə çevrildiyini (Fəsil 6), necə serve edildiyini (Fəsil 7) və necə ölçüldüyünü bilirsiniz.

Hissə II bu bilikləri praktik məqsədə yönəldir: hazır open-source model-i götürüb konkret domain üçün uyğunlaşdırmaq. Orada model seçimi və lisenziyalar, domain data-sının toplanması və synthetic data, LoRA və QLoRA ilə parameter-efficient fine-tuning, DPO və GRPO ilə preference tuning, distillation və model merging öyrəniləcək. Bu fəsildə qurduğunuz eval set isə hər addımda istifadə olunacaq. Fine-tuning-in uğurlu olub-olmadığını yalnız o göstərə bilər.

Tapşırıqlar

Maraqlandığınız domain üçün 100 nümunəlik eval set qurun: ən azı 4 kateqoriya, hər nümunə üçün verifiable cavab və ya binary meyarlı rubric. İki fərqli open model-i orada qiymətləndirin və nəticəni kateqoriyalar üzrə confidence interval ilə yazın.
LLM-as-judge qurun və 50 cavabı həm hakim, həm də özünüz qiymətləndirin. Razılaşma faizini hesablayın. Sonra pairwise müqayisəni hər iki sırada işə salıb position bias-ı ölçün və rubric-i razılaşma artana qədər düzəldin.
İctimai bir riyaziyyat benchmark-ından 30 sual götürün və onlardakı rəqəmləri, adları dəyişərək perturbation variantı yaradın. Bir model-in orijinal və dəyişdirilmiş variantlardakı nəticəsini müqayisə edin. Fərq contamination-a işarə edirmi?