Fine-tuning LLM pe corpus românesc: provocări reale
De ce sub 0.3% din modelele frontier conțin română și cum se face corect continued pretraining + SFT pe corpus juridic și de procurement.
Fine-tuning LLM pe corpus românesc: provocări, costuri, rezultate reale
Când o firmă de consultanță fiscală ne-a întrebat de ce un model frontier american le redactează contracte cu „forța majoră” tradusă „force majeure” în mijlocul textului, răspunsul tehnic e neplăcut: în pretraining-ul acelui model, româna ocupă undeva sub 0,3% din total tokens. Pentru limbi cu această reprezentare statistică, modelul nu „vorbește” româna — o aproximează. Iar în texte juridice și de procurement, aproximarea este eroare.
Acest articol descrie ce înseamnă, în practică, să fine-tunezi un LLM pe corpus românesc real: ce date colectezi, în ce ordine le folosești, cât costă, ce câștigi față de un prompt în engleză.
TL;DR
- Modelele frontier publice (familia GPT, Claude, Gemini, Llama) au sub 0,3–0,8% tokens în română în pretraining. Pentru text juridic, fiscal sau de procurement românesc, modelul „transferă” din engleză și franceză, ceea ce introduce erori sistematice.
- Soluția practică nu este să antrenezi un model de la zero (cost prohibitiv), ci să faci continued pretraining pe corpus românesc curat urmat de SFT (supervised fine-tuning) pe instrucțiuni de domeniu.
- Tokenizatorul matters: tokenizatori antrenați majoritar pe engleză fragmentează cuvintele românești în 2–4 ori mai mulți tokens, ceea ce strică context window și similaritatea cosinus pe embeddings.
- Costul unei runde complete (CPT 30B tokens + SFT 100K examples) pentru un model open-weight 7–14B este de ordinul a câteva mii de euro pe GPU on-prem. ROI pozitiv dacă rulați >50K queries/lună.
- Câștigul măsurabil: pe benchmark intern de 800 întrebări juridice, F1 pe extragerea articolului corect crește de la 0,61 (model generic) la 0,89 (CPT + SFT pe corpus juridic RO).
De ce româna este sub-reprezentată
Pretraining-ul modelelor frontier folosește datasets predominant engleze: Common Crawl filtrat, GitHub, ArXiv, Wikipedia. În aceste corpusuri, raportul tokens român/total este împins în jos de două forțe: volum de conținut public mai redus, plus filtre de calitate engleză-centrate care elimină disproporționat text românesc.
Rezultatul: un model 70B antrenat pe 15 trilioane de tokens vede între 30 și 100 de miliarde de tokens în română. Pare mult, dar este sub 1% din total. Pentru comparație, vede aproximativ 10–12 trilioane de tokens în engleză. Diferența explică de ce modelul „înțelege” româna, dar generează erori subtile pe terminologie specializată.
Trei opțiuni arhitecturale
Când o companie românească dorește un LLM care funcționează pe corpusul ei, are trei căi:
- Prompt engineering pe model frontier engleză + RAG pe documente RO. Cost minim, ușor de pus în producție, dar limitat: modelul „traduce” mental, generează termeni din franceză/engleză amestecați, are dificultăți cu forme flexionare în output.
- Continued pretraining (CPT) pe model open-weight (Qwen, Gemma, Mistral, Llama family) cu corpus românesc curat, urmat de SFT pe instrucțiuni domeniu. Cost mediu, latency mai bun (model on-prem), control total pe terminologie.
- Pretraining from scratch pe corpus românesc. Cost prohibitiv (>10 milioane EUR pentru un model competitiv), nu se justifică nimănui în 2026.
În practică, opțiunea 1 funcționează pentru POC și volume mici. Opțiunea 2 este standardul industrial pentru companii care vor calitate consistentă pe corpus românesc. Opțiunea 3 este academică.
Pipeline practic CPT + SFT
Corpus RO (drept, finanțe, procurement, ANRMAP, OG)
→ curățare (dedup, filtre toxicity, filtre PII)
→ tokenizator extins (vocabulary cu termeni RO frecvenți)
→ CPT pe model base (LR scăzut, mix RO 70% / EN 30%)
→ SFT pe instrucțiuni domeniu (10K–100K perechi prompt+răspuns)
→ DPO sau RLHF pe preferințe (opțional)
→ eval pe benchmark intern (juridic, fiscal, procurement)
Pasul 1 — Colectarea corpusului
Pentru un domeniu juridic sau de procurement românesc, sursele publice sunt:
- legislația consolidată din Monitorul Oficial (publică, cu retragere automată a actelor abrogate);
- jurisprudență ÎCCJ și curți de apel (publice, după anonimizare);
- ghiduri ANRMAP, ANAF, ASF, BNR (publice);
- formulare și modele oficiale de contracte;
- decizii ale autorității contractante (SEAP, deciziile CNSC).
Volume realiste: corpus de 5–30 miliarde de tokens este suficient pentru CPT eficient. Calitatea contează mai mult decât cantitatea: deduplicare agresivă, eliminarea boilerplate-ului, păstrarea diacriticelor exacte.
Pasul 2 — Tokenizatorul
Cea mai subestimată decizie. Un tokenizator antrenat majoritar pe engleză fragmentează „desfacerea contractului individual de muncă” în 18–22 tokens; un tokenizator extins cu vocabular românesc îl reduce la 9–11 tokens. Asta înseamnă context window efectiv mai mare, training mai rapid, și embeddings mai stabile.
Extinderea tokenizatorului implică adăugarea a 1.000–5.000 tokens noi reprezentând cuvinte și forme românești frecvente, urmată de inițializarea embeddings-urilor noi (medie pe sub-tokens existenți este o ancoră bună).
Pasul 3 — Continued pretraining
Pe modelul base extins, rulăm CPT cu un mix de date 70% RO / 30% EN. Ratio-ul nu este arbitrar: dacă rulezi 100% RO, modelul „uită” engleza și pierde capabilități generale (raționament, cod, matematică). Dacă rulezi sub 50% RO, ai un câștig prea mic pentru cost.
LR-ul folosit este sub jumătate din LR-ul standard de pretraining (continued pretraining cere prudență ca să nu „distrugi” reprezentări existente). Numărul de epoci: 1–2, niciodată mai mult — overfitting pe corpus de domeniu este o capcană obișnuită.
Pasul 4 — Supervised fine-tuning
Aici intră instrucțiunile de domeniu: perechi (prompt, răspuns) curate de specialiști. Pentru un asistent juridic, sunt 10.000–100.000 exemple structurate: întrebare juridică reală, răspuns corect cu citare, format consistent.
Calitatea SFT depășește orice cantitate. 10.000 de exemple curate de la avocați seniori bat 200.000 de exemple sintetice generate cu un alt LLM. Dataset-urile sintetice sunt utile pentru augmentation, dar nu pot înlocui supervisia umană.
Costuri reale
Pentru un model open-weight 7–14B, pe GPU on-prem (familie A100/H100, deținut sau închiriat):
- CPT pe 20–30 miliarde tokens: 800–2.500 ore-GPU
- SFT pe 50–100K exemple: 30–80 ore-GPU
- Eval + iterații: 20–40% suplimentar
În cifre absolute, o rundă completă pe model 14B costă undeva între 3.000 și 10.000 EUR. Pe model 70B, costurile cresc liniar și depășesc rapid 30.000 EUR pe rundă.
ROI-ul devine pozitiv față de API frontier dacă rulați:
- peste 50.000 de queries/lună cu prompts lungi (>5.000 tokens), sau
- peste 200.000 de queries/lună cu prompts scurte, sau
- aveți cerințe de latency under 500ms care nu pot fi servite de API extern.
Capcane practice
Catastrophic forgetting. CPT-ul tinde să degradeze capabilități de cod și matematică. Soluția: păstrați 10–15% din mix corpus de cod și 5% raționament matematic, chiar dacă target-ul vostru este juridic.
Diacritice inconsistente. Multe corpusuri publice românești au diacritice cu codificări diferite (ș/ş, ț/ţ — Unicode 0219/015E etc.). Normalizarea trebuie făcută explicit, înainte de tokenizare. Altfel modelul învață două variante pentru același cuvânt.
SFT cu prompts engleză + răspunsuri română. Dacă SFT-ul vostru are instrucțiuni în engleză și răspunsuri în română, modelul va răspunde în română doar când întrebarea e în engleză. Asigurați-vă că aveți perechi RO–RO suficiente.
Eval slab. Benchmark-uri publice românești de calitate sunt rare. Investiți în eval intern: 500–2.000 întrebări reale din domeniu, cu răspunsuri verificate de specialiști. Fără eval, nu știți dacă fine-tune-ul a funcționat.
Diagramă pipeline
Documente RO publice
→ Curățare + deduplicare
→ Normalizare diacritice + filtre PII
→ Tokenizator extins (vocabulary RO)
→ CPT (mix 70% RO / 30% EN, LR scăzut)
→ SFT (10K–100K perechi domain-specific)
→ DPO/RLHF (opțional)
→ Eval pe benchmark intern
→ Deployment cu prompt-cache
Concluzie operațională
Fine-tuning-ul pe corpus românesc nu este un proiect de cercetare. Este o decizie de inginerie cu ROI calculabil dacă volumele justifică. Pentru companii care procesează zeci de mii de documente juridice, fiscale sau de procurement în limba română, diferența între un model frontier engleză cu RAG și un model open-weight CPT+SFT pe corpus RO este tangibilă: precizie pe terminologie, latency mai mic, control pe drift.
Dacă echipa dumneavoastră evaluează un asemenea proiect, putem oferi o analiză de fezabilitate cu volume reale și estimare de cost pe stack-ul existent.
Articole conexe
- Pillar RAG — arhitecturi de retrieval enterprise
- Pillar Leta — asistent juridic românesc
- BGE-M3 vs OpenAI embeddings pentru queries românești
Surse externe
- Touvron et al., „Llama 2: Open Foundation and Fine-Tuned Chat Models”
- Bai et al., „Qwen Technical Report”
- Gururangan et al., „Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks”
- BigScience BLOOM Multilingual Report, arXiv:2211.05100
Următorul pas
Pentru o evaluare tehnică pe corpus propriu (estimare cost CPT, plan de SFT, benchmark intern), echipa CAI Technology oferă o consultație de 30 de minute fără cost.