Base model-dən assistant-a: post-training

Əvvəlki fəslin sonunda əlimizdə base model qaldı. Bu model çox şey bilir, amma sual verəndə cavab vermək əvəzinə mətni davam etdirir. Onu təlimata əməl edən, nə vaxt dayanacağını bilən və bəzi sorğulardan imtina edən assistant-a çevirən mərhələyə post-training deyilir. Compute baxımından post-training pretraining-in kiçik bir hissəsidir. Davranış baxımından isə modeli istifadəçinin hiss etdiyi şəkildə ən çox dəyişən mərhələdir. Bu fəsil üç əsas alət ailəsini izah edir: nümunədən öyrənmə (SFT), üstünlükdən öyrənmə (RLHF, DPO) və yoxlanıla bilən nəticədən öyrənmə (RLVR). Part II-də öz modelinizi fine-tune edəndə eyni alətlərdən istifadə edəcəksiniz, sadəcə kiçik miqyasda.

Base və instruct

Model kartlarında adətən iki variant görəcəksiniz: Qwen3-8B-Base və Qwen3-8B (və ya -Instruct). Fərq budur:

Base model pretraining-in birbaşa nəticəsidir. Few-shot prompt-larla güclüdür, davranışı isə proqnozlaşdırılmazdır.
Instruct model post-training-dən keçib. Chat formatını, rolları və dayanma token-lərini tanıyır, təlimata əməl edir, təhlükəsizlik davranışı var.

Instruct model istifadə üçün hazırdır. Base model isə yeni davranış öyrətmək üçün daha təmiz başlanğıc nöqtəsidir. Bu seçim Part II-də yenidən qarşımıza çıxacaq.

SFT: nümunədən öyrənmək

Supervised fine-tuning ən sadə addımdır. Model yaxşı yazılmış söhbət nümunələri üzərində eyni next-token objective ilə train edilir. Dəyişən objective deyil, data-dır: internet mətni əvəzinə "istifadəçi soruşur, assistant cavab verir" formatında nümunələr verilir.

Bir nümunə adətən mesajlar siyahısı kimi saxlanır:

[
  {"role": "system", "content": "Sən qısa cavab verən köməkçisən."},
  {"role": "user", "content": "Fransanın paytaxtı hansıdır?"},
  {"role": "assistant", "content": "Paris."}
]

Model JSON görmür. Bu struktur chat template vasitəsilə xüsusi token-lərlə tək bir mətnə çevrilir:

<|im_start|>system
Sən qısa cavab verən köməkçisən.<|im_end|>
<|im_start|>user
Fransanın paytaxtı hansıdır?<|im_end|>
<|im_start|>assistant
Paris.<|im_end|>

Hər model ailəsinin öz template-i var. Fine-tuning və inference zamanı template-in tam eyni olmaması praktikada ən çox rast gəlinən və ən çətin tapılan xətalardan biridir. Model sanki "axmaqlaşır", amma səbəb sadəcə bir yanlış token olur.

İkinci vacib detal loss masking-dir. Model istifadəçinin mətnini proqnozlaşdırmağı öyrənməməlidir, yalnız assistant-ın cavabını. Ona görə system və user token-ləri loss-dan çıxarılır:

# labels: input_ids-in surəti; maskalanan mövqelər -100 olur
labels = input_ids.clone()
labels[~is_assistant_token] = -100   # cross-entropy bu mövqeləri nəzərə almır

SFT-də keyfiyyət miqdardan qat-qat vacibdir. Meta-nın LIMA işi göstərdi ki, diqqətlə seçilmiş cəmi 1000 nümunə base modeldə güclü instruction-following davranışı yarada bilər. Səbəb budur: bilik artıq pretraining-dən gəlir, SFT isə əsasən format və üslub öyrədir. Buradan vacib bir nəticə çıxır: SFT modelə yeni fakt öyrətməkdə zəifdir. Bilik əlavə etmək lazım olanda continued pretraining (Part II) və ya retrieval (Part III) daha uyğun yollardır.

Üstünlük data-sı

SFT-nin bir məhdudiyyəti var: o, yalnız göstərilən cavabı təqlid edir. Halbuki çox vaxt "ideal cavabı yazmaq" "iki cavabdan hansının yaxşı olduğunu demək"dən xeyli çətindir. Preference data məhz bu asimmetriyadan istifadə edir. Hər nümunədə bir prompt və iki cavab olur: üstün tutulan (chosen) və rədd edilən (rejected).

prompt:   "Rekursiyanı bir cümlə ilə izah et."
chosen:   "Funksiyanın problemi özünün kiçik versiyasına bölüb özünü çağırmasıdır."
rejected: "Rekursiya proqramlaşdırmada çox vacib və maraqlı mövzudur..."

Üstünlükləri insanlar, güclü model (RLAIF) və ya ikisinin qarışığı təyin edə bilər. Müasir pipeline-larda annotasiyanın böyük hissəsini artıq model-lər edir, insanlar isə yoxlayır və çətin halları həll edir.

RLHF: reward model və PPO

Klassik RLHF iki addımdan ibarətdir.

1. Reward model. Ayrıca bir model (adətən SFT modelinin kopyası, sonunda skalyar çıxışla) cavablara bal verməyi öyrənir. Training belə qurulur: chosen cavabın balı rejected cavabın balından yüksək olmalıdır (Bradley-Terry modeli).

2. Policy optimization. Assistant model (policy) prompt-lara cavab yaradır, reward model onları qiymətləndirir və PPO alqoritmi policy-ni yüksək bal alan cavablara doğru itələyir. Burada əsas tormoz KL penalty-dir: policy ilkin SFT modelindən çox uzaqlaşanda cəzalandırılır.

objective = reward(x, y) − β · KL(π_θ || π_ref)

KL olmasa, model reward hacking-ə keçir: reward model-in zəif yerlərini tapır. Məsələn, uzun və özünəinamlı cavablar yüksək bal alırsa, model getdikcə daha uzun və daha özünəinamlı danışır, faydalılığı isə artmır. Reward model həqiqi insan üstünlüyünün yalnız qüsurlu bir proxy-sidir və optimallaşdırma bu proxy-ni amansızcasına sınayır.

RLHF güclüdür, amma mühəndislik baxımından ağırdır. Eyni anda dörd model (policy, reference, reward, value) yaddaşda olur. Hyperparameter-lərə həssasdır və stabil işlətmək təcrübə tələb edir.

DPO və variantları

2023-cü ildə təqdim olunan Direct Preference Optimization göstərdi ki, reward model və RL loop-u olmadan eyni məqsədə çatmaq mümkündür. Riyazi olaraq KL-məhdud RLHF-in optimal policy-si bağlı formada ifadə olunur. Bu, preference cütləri üzərində birbaşa classification-a bənzər loss verir:

L_DPO = −log σ( β · [ log π_θ(y_w|x)/π_ref(y_w|x)
                    − log π_θ(y_l|x)/π_ref(y_l|x) ] )

Sözlə desək: model chosen cavabın (y_w) ehtimalını reference modelə nisbətən artırmalı, rejected cavabın (y_l) ehtimalını isə azaltmalıdır. β nə qədər uzaqlaşmağa icazə verildiyini tənzimləyir. Bu, SFT qədər sadə bir training loop-dur. Yaddaşda yalnız iki model saxlanır və nəticələr çox vaxt PPO-ya yaxındır. Buna görə open-source dünyasında preference tuning-in default seçimi DPO oldu.

Ondan sonra bir sıra variantlar yarandı:

IPO: DPO-nun preference-lərə həddən artıq uyğunlaşma meylini azaldır.
KTO: cüt tələb etmir, hər cavab üçün sadəcə "yaxşı" və ya "pis" etiketi kifayətdir. Bu cür data toplamaq daha asandır.
ORPO: SFT və preference addımını reference modelsiz tək mərhələdə birləşdirir.
SimPO: reference model əvəzinə uzunluğa görə normallaşdırılmış ehtimaldan istifadə edir.

Praktik məsləhət: əvvəlcə DPO ilə başlayın. Variantlara yalnız konkret problem görəndə keçin, məsələn cavabların uzunluğu şişəndə və ya data cütləşmiş olmayanda.

RLVR: yoxlanıla bilən mükafat

Bəzi tapşırıqlarda cavabın düzgünlüyünü proqram yoxlaya bilir. Riyaziyyat məsələsinin yekun ədədi ya düzdür, ya səhv. Kod ya unit test-lərdən keçir, ya keçmir. Reinforcement learning with verifiable rewards belə tapşırıqlarda reward model-i tamamilə çıxarır: mükafatı checker verir. Bu yanaşma reward hacking-ə daha davamlıdır, çünki checker-i aldatmaq öyrənilmiş reward model-i aldatmaqdan qat-qat çətindir. Ancaq tamamilə immun deyil: test-lər zəifdirsə, model test-ləri keçən, amma səhv kod yazmağı öyrənəcək.

Bu sahənin əsas alqoritmi DeepSeek-in təqdim etdiyi GRPO-dur (Group Relative Policy Optimization). PPO-dan fərqli olaraq ayrıca value model-ə ehtiyac yoxdur. Hər prompt üçün bir qrup cavab yaradılır və hər cavabın "nə qədər yaxşı olduğu" qrupun ortasına görə ölçülür:

rewards = [check(answer) for answer in group]   # məsələn, 8 cavab: 1 və ya 0
mean, std = np.mean(rewards), np.std(rewards) + 1e-6
advantages = [(r - mean) / std for r in rewards]
# ortadan yaxşı cavabların ehtimalı artırılır, pislərinki azaldılır

Bir incəlik var: qrupdakı bütün cavablar düzdürsə və ya hamısı səhvdirsə, advantage sıfır olur və o prompt heç nə öyrətmir. Ona görə RLVR üçün data seçimi vacibdir: tapşırıqlar model üçün nə çox asan, nə də çox çətin olmalıdır.

Reasoning model-lər və test-time compute

2024-cü ilin sonu ilə 2025-ci ilin əvvəlində OpenAI o1 və DeepSeek-R1 göstərdi ki, RLVR ilə train edilən model-lər öz-özünə uzun chain-of-thought yaratmağı öyrənir. Cavab verməzdən əvvəl minlərlə token "düşünür", ara nəticəni yoxlayır, səhvini görəndə geri qayıdır və başqa yol sınayır. DeepSeek-R1-Zero bu davranışın SFT nümunələri olmadan, yalnız düzgünlük mükafatı ilə yarandığını göstərdi.

Bu, yeni bir scaling oxu açdı: test-time compute. Pretraining-də compute model ölçüsünə və data-ya xərclənir. Reasoning model-lərdə isə hər sorğuya əlavə compute xərcləmək olur: daha uzun düşünmə, bir neçə cavab yaradıb ən yaxşısını seçmək. 2026-cı ildə əksər frontier və güclü open model-lər "thinking" rejimini dəstəkləyir və düşünmə büdcəsini tənzimləməyə imkan verir. Mühəndis üçün nəticə praktikdir: çətin tapşırıqda daha böyük modelə keçməzdən əvvəl eyni modelə daha çox düşünmə vaxtı vermək çox vaxt daha ucuz həlldir. Qiyməti latency və token xərcidir.

Alignment tax və safety tuning

Post-training pulsuz deyil. Alignment tax termini post-training-dən sonra bəzi qabiliyyətlərin zəifləməsini təsvir edir. Məsələn, model yaradıcı yazıda daha şablon olur, kalibrləmə pisləşir (base model öz ehtimallarında daha "dürüst"dür) və ya müəyyən benchmark-larda bal düşür. Hər tuning mərhələsi modeli dar bir paylanmaya doğru itələyir və bu, digər bacarıqların unudulması (catastrophic forgetting) riskini yaradır.

Safety tuning eyni alətlərlə aparılır: zərərli sorğulara imtina nümunələri SFT-yə daxil edilir, preference data-da təhlükəsiz cavablar üstün tutulur. Anthropic-in Constitutional AI yanaşmasında model yazılı prinsiplər toplusuna əsasən öz cavablarını tənqid edib düzəldir və preference-lər buradan yaradılır. Əsas balans over-refusal ilə bağlıdır: həddən artıq ehtiyatlı model zərərsiz sualları da rədd edir ("Python prosesini necə öldürüm?"). Bu da bir uğursuzluq formasıdır və ayrıca ölçülməlidir.

Bir vacib xəbərdarlıq: safety davranışı fine-tuning ilə asanlıqla zəifləyir. Tədqiqatlar göstərib ki, tamamilə zərərsiz data ilə edilən kiçik fine-tune belə imtina davranışını poza bilər. Öz modelinizi fine-tune etdikdən sonra təhlükəsizlik eval-larını yenidən işə salmaq məcburidir.

Bunun üzərinə nə qurulacaq

Bu fəsildəki hər texnika Part II-də sizin əlinizdə alətə çevriləcək. Domain modeli üçün SFT data-sı hazırlamaq, chat template-i düzgün tətbiq etmək, DPO ilə üslubu tənzimləmək, yoxlanıla bilən tapşırıqlarda GRPO işlətmək. Fərq miqyasdadır: laboratoriyalar milyonlarla nümunə və minlərlə GPU istifadə edir, siz isə LoRA (Part II) ilə bir neçə GPU-da eyni prinsipləri tətbiq edəcəksiniz. Bütün bu proseslərin uğurunu necə ölçmək Fəsil 8-in mövzusudur.

Tapşırıqlar

İstifadə etdiyiniz bir open model-in tokenizer konfiqurasiyasından chat template-i çıxarın. Üç mesajlı söhbəti əl ilə template-ə çevirin və hansı token-lərin loss-a daxil olacağını işarələyin. Template-də bir token-i (məsələn, son <|im_end|>) unutsanız, inference zamanı nə baş verər?
Öz sahənizdən 20 preference cütü yazın: hər prompt üçün chosen və rejected. Rejected cavabları üç növə bölün: faktiki səhv, üslub zəifliyi, həddən artıq uzunluq. Hansı növ annotasiya edərkən ən çox mübahisə yaratdı və bu, reward hacking riski barədə nə deyir?
50 riyaziyyat məsələsi üçün kiçik instruct model-dən hər məsələyə 8 cavab götürün və yekun cavabı yoxlayan checker yazın. Hər məsələ üçün düzgünlük nisbətini hesablayın. Neçə məsələ GRPO üçün faydasızdır (0/8 və ya 8/8)? Faydalı aralığa düşən məsələlərin payı nə qədərdir?