CAI Technology
Menu ☰
rag · · 14 min citire

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.

CAI Technology · Ultima revizuire: 30.04.2026
Fine-tuning LLM pe corpus românesc: provocări reale

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

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:

  1. 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.
  2. 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.
  3. 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:

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):

Î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:

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

Surse externe

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.

Începem cu o conversație de 30 de minute.

Audit AI-readiness gratuit pentru companii peste 50 angajați. Răspundem în 24 de ore.