Utoljára frissítve:
Nyílt AI Modellek · Spoke
LoRA fine-tuning vállalati adatokon: hogyan hangold a modellt 2026-ban
A LoRA (Low-Rank Adaptation) lehetővé teszi, hogy egy 7B paraméteres modellt saját vállalati adatokon, egyetlen fogyasztói GPU-n, 1–2 nap alatt finomhangolj. Ez az útmutató végigveszi az adatkészlet-előkészítéstől a merged Ollama deployment-ig az összes lépést — és megmutatja, mikor éri meg fine-tuningot végezni RAG helyett.
LoRA = az alap modell súlyait befagyasztod, csak kis rang-mátrixokat tanítasz — 100× kevesebb paramétert, töredék compute. QLoRA = 4-bites kvantált alap + full precision adapter = 8 GB VRAM elegendő egy 7B modellhez. 1000–5000 minőségi példa elég az első fine-tuninghoz. Fine-tuning: stílus, terminológia, viselkedés — RAG: változó adatok, forrásjelölés.
LoRA és QLoRA: hogyan működik és miért hatékony
A full fine-tuning problémája: egy 7B paraméteres modell teljes fine-tuningja módosítja mind a 7 milliárd súlyt. Ez legalább 28 GB VRAM-ot igényel bfloat16 precizitáson (model + optimizer states + gradients) — ami a legtöbb vállalati GPU-n, és minden fogyasztói kártyán, egyszerűen nem fér el. Emellett a teljes fine-tuning hajlamos az catastrophic forgetting jelenségre: az alap modell általános képességei degradálódhatnak, ha az adatkészlet szűk tartományra koncentrál.
A LoRA megközelítése elegánsan kerüli meg mindkét problémát. Az alap modell súlyait befagyasztja — azok változatlanul maradnak. Ehelyett minden transzformer réteghez két kis mátrixot illeszt be: egy alacsony rang-mátrix párt (A és B), amelyek szorzata adja az adaptert. Ha az alap modell egy rétegének súlymátrixa d×d dimenzójú, a LoRA adapter mindössze d×r és r×d mátrixokból áll — ahol r a rank (tipikusan 4–64). Az összes tanítható paraméter így az alap modell paramétereinek csupán 0,1–1%-a.
A QLoRA (Quantized LoRA, Dettmers et al., 2023) egy lépéssel tovább megy. Az alap modellt 4-bites NF4 kvantálással tölti be a memóriába — ez önmagában 70% memória-megtakarítást jelent a bfloat16-hoz képest. A LoRA adapter mátrixai ugyanakkor full precision (bfloat16) maradnak, hogy a gradiens-számítás ne veszítsen precizitást. A kombináció eredménye: egy 7B modell QLoRA-val elfér 8–10 GB VRAM-on, miközben a fine-tuning minősége alig marad el a full precision LoRA mögött.
Az r paraméter (rank) határozza meg az adapter kapacitását. Alacsonyabb rank (r=4, r=8): kisebb adapter, kevesebb VRAM, gyorsabb tanítás, de korlátozott kapacitás — stílus és hang tanításához elegendő. Magasabb rank (r=32, r=64): nagyobb adapter, több paramétert tanulhat — összetett viselkedési változáshoz javasolt. A legtöbb vállalati use case-hez r=16 jó alapértelmezés: elegendő kapacitás, kezelhető memóriaigény.
Mikor fine-tuning, mikor RAG?
Ez az a döntési pont, amelyet sok csapat rosszul kezel — vagy RAG-ot alkalmaz ott, ahol fine-tuning kellene, vagy fordítva. A két megközelítés nem versenyez egymással: különböző problémákat old meg.
A RAG (Retrieval-Augmented Generation) az optimális megoldás, ha az adatok rendszeresen változnak (nem érdemes folyamatosan újra fine-tunolni), ha a forrásjelölés és az átláthatóság kritikus (honnan jött az információ), ha a tartalom terjedelmes és heterogén (tudásbázis, dokumentumtár), vagy ha az adatvédelem nem engedi meg, hogy az adatok a modell súlyaiba kerüljenek.
A LoRA fine-tuning erősebb, ha a cél a modell stílusának és hangjának megtanítása (vállalati kommunikációs stílus, brand voice), ha domain-specifikus terminológia kell, amelyet a keresés önmagában nem old meg (orvosi, jogi, műszaki szóhasználat), ha az instrukció-követési viselkedést kell módosítani (pl. mindig egy meghatározott struktúrájú JSON-t adjon vissza), vagy ha a latency-kritikus és a RAG retrieval overhead elfogadhatatlan.
Döntési táblázat: RAG vs. fine-tuning use case-enként
| Use case | RAG | Fine-tuning | Hibrid |
|---|---|---|---|
| Vállalati tudásbázis kérdezése | Kiváló | Gyenge | Jó (RAG + FT stílus) |
| Brand voice / kommunikációs stílus | Gyenge | Kiváló | — |
| Domain terminológia (orvosi, jogi) | Közepes | Jó | Kiváló |
| Strukturált kimenet (JSON, táblázat) | Közepes | Kiváló | — |
| Friss, változó tartalom | Kiváló | Nem alkalmas | RAG kötelező |
| Ügyfélszolgálati chatbot (saját termék) | Jó | Közepes | Kiváló |
Az optimális vállalati AI stack 2026-ban általában hibrid: RAG a változó tudáshoz + fine-tuned modell a stílus- és viselkedés-adaptációhoz. A fine-tuning megtanítja a modellnek, hogyan kommunikáljon; a RAG biztosítja, hogy mindig a naprakész adatból dolgozzon.
Adatkészlet előkészítés
Az adatkészlet minősége a fine-tuning sikerének legkritikusabb tényezője — fontosabb a mennyiségnél, fontosabb a modellválasztásnál, és fontosabb a hyperparaméter-hangolásodnál. Rossz adatok hibás viselkedést tanítanak — és a modell ezeket éppoly következetesen fogja reprodukálni, mint a jó mintákat.
Az instruction-following formátum
A legelterjedtebb fine-tuning adatformátum a JSON Lines (JSONL): minden sor egy önálló JSON objektum, amelynek három kulcsa van. Az instruction mező tartalmazza a feladat leírását — pl. "Foglald össze az alábbi ügyfélszolgálati hívás tartalmát maximum 3 mondatban, formális stílusban." Az input mező az opcionális bemeneti szöveget tartalmazza (pl. a hívás átirata). Az output mező a kívánt választ tartalmazza — ez pontosan az, amit a fine-tunolt modelltől elvársz. A három mezőt a Alpaca formátumnak is nevezik, és a legtöbb fine-tuning keretrendszer (Unsloth, Axolotl, LLaMA-Factory) natívan kezeli.
Mielőtt elindítod a fine-tuningot: (1) Távolítsd el a duplikátumokat — azonos vagy közel azonos példák torzítják a modellt. (2) Ellenőrizd a hosszakat — a túl rövid output (<10 szó) és a túl hosszú (>800 szó) példák egyaránt problémásak. (3) Ellenőrizd a konzisztenciát — az instruction és output stílusának, formátumának és hangnemének következetesnek kell lennie. (4) Szűrd ki az inkonzisztens példákat — ahol az output nem felel meg az instruction-ben leírtaknak.
Vállalati adatforrások
A legjobb vállalati fine-tuning adatkészletek általában a meglévő, ellenőrzött tartalmakból születnek. Kiváló forrásokra néhány példa: belső e-mail kommunikáció (különösen, ha van meghatározott "jó kommunikáció" minta), ügyfélszolgálati jegyek és azok megoldásai, call center átiratok + a hozzájuk tartozó összefoglalók, dokumentáció és FAQ + a tényleges felhasználói kérdések, korábbi tanácsadói riportok és ajánlások. A cél: olyan példák, ahol a bemenet és az elvárt kimenet már rendelkezésre áll — és ahol az output megbízhatóan helyes és a kívánt stílust képviseli.
Fine-tuning lépései — Unsloth + HuggingFace
Az Unsloth keretrendszer 2024 óta a leggyakrabban használt eszköz LoRA/QLoRA fine-tuninghoz: 2–5× gyorsabb a vanilla HuggingFace Trainer-nél azonos hardveren, és 30–60% kevesebb VRAM-ot igényel. Aktívan fejlesztik, és az összes fontosabb modell-architektúrát (Llama, Mistral, Qwen, Phi) támogatja.
A fine-tuning folyamata lépésről lépésre
1. Modell betöltése. Az Unsloth FastLanguageModel osztályával töltsd be az alap modellt — megadva a modell nevét (pl. "unsloth/Qwen2.5-7B-Instruct"), a maximális szekvencia-hosszt (tipikusan 2048), és az adattípust (None = automatikus detektálás). A load_in_4bit=True kapcsoló aktiválja a QLoRA módot.
2. LoRA konfiguráció. A get_peft_model() hívással alkalmazd a LoRA adaptert az alap modellre. A legfontosabb paraméterek: r=16 (rank), lora_alpha=32 (általában 2×r), lora_dropout=0.05 (regularizáció), és a target_modules lista — azok a rétegek, amelyekre az adapter kerül (q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj a legtöbb Llama-szerű architektúránál). A tanítható paraméterek száma a model.print_trainable_parameters() hívással ellenőrizhető — tipikusan az összes paraméter 0,5–2%-a.
3. Adatkészlet formázás. Az Unsloth a standardize_sharegpt() vagy az Alpaca formátum közvetlen betöltését támogatja. Az adatot HuggingFace Dataset objektumba kell tölteni, majd a chat template-tel formázni (pl. apply_chat_template() az instruct modellekhez). Ez biztosítja, hogy a modell ugyanolyan tokenizálást kap, mint amit az alap modell előtanításakor használtak.
4. Trainer futtatása. A HuggingFace SFTTrainer (Supervised Fine-Tuning Trainer) az ajánlott eszköz. Legfontosabb hyperparaméterek: num_train_epochs=3 (3 epoch általában elegendő), per_device_train_batch_size=4 (VRAM-tól függően), gradient_accumulation_steps=4 (effective batch size növeléshez), learning_rate=2e-4 (LoRA-hoz tipikus érték), warmup_steps=100. A training loss figyelése a konvergencia indikátora — ha 0.05 alá esik, általában overfitting veszélye áll fenn.
5. Mentés és merge. A LoRA adapter mentése model.save_pretrained("lora_adapter"). A merge (adapter + alap modell egyesítése) model.merge_and_unload() majd model.save_pretrained_gguf("merged_model", tokenizer, quantization_method="q5_k_m") — ez közvetlenül GGUF fájlt exportál, amelyet Ollama-ba tölthetsz.
Két tipikus hiba fine-tunoláskor: (1) Overfitting — a modell betanulja az adatkészlet konkrét példáit, de nem általánosít. Jele: training loss alacsony, de manuális teszteléskor a modell szó szerint visszaad tanítási példákat. Megoldás: kevesebb epoch (1–2), nagyobb adatkészlet, dropout növelése. (2) Catastrophic forgetting — az alap modell általános képességei degradálódnak. Jele: a modell elveszíti az instrukció-követési képességét a saját tartományán kívül. Megoldás: alacsonyabb learning rate, kevesebb epoch, vagy az adatkészletbe "általános" példák keverése.
Evaluáció és deployment
A fine-tuning után a legfontosabb kérdés: valóban jobban teljesít-e a modell a kívánt feladaton, és nem rontottuk-e el az alap képességeit? A kiértékelés három szinten javasolt.
Manuális spot-check
Az első és legfontosabb lépés: 20–50 kézzel kiválasztott tesztpéldán ellenőrizd a modell kimenetét. Tesztelj az adatkészletből nem látott példákon (held-out set). Ellenőrzési szempontok: (1) megjelent-e a kívánt stílus/terminológia, (2) megőrződött-e az általános instrukció-követési képesség, (3) nem generál-e a modell inkonzisztens vagy ellentmondó válaszokat. A manuális ellenőrzés nem helyettesíthető automatikus metrikákkal — a végső ítélet mindig emberi értékelés.
Automatikus benchmark
Az Eleuther AI LM Eval Harness a de facto standard eszköz nyílt LLM-ek értékelésére. Domain-specifikus feladatokhoz saját task-et definiálhatsz YAML konfigurációval. Az általános képességek degradációjának ellenőrzéséhez az HellaSwag, MMLU vagy ARC benchmark-ok alkalmasak — ha ezek pontszáma szignifikánsan (több mint 3–5%) csökkent az alap modellhez képest, a fine-tuning ártott az általános képességeknek.
Deployment Ollama-ban
Ha az Unsloth GGUF exportot használtad, az Ollama deployment két lépéses. Először egy Modelfile létrehozása szükséges — ez egy egyszerű szöveges fájl, amely megadja az alap GGUF fájl elérési útját (FROM ./merged_model.Q5_K_M.gguf), a rendszer promptot (SYSTEM), és opcionálisan a generálási paramétereket (PARAMETER temperature 0.7). Majd ollama create sajat-modell -f Modelfile regisztrálja a modellt az Ollama-ban. Ezt követően ollama run sajat-modell az interaktív teszteléshez, vagy a REST API-n keresztül pontosan ugyanúgy hívható, mint bármely más Ollama modell.
Monitoring és újraértékelés
A fine-tunolt modell teljesítménye idővel driftálhat — nem maga a modell változik, hanem a felhasználói igények és a bejövő adatok. 30 naponként ajánlott egy gyors kiértékelési ciklus: 20–30 friss tesztpéldán ellenőrizd a modell minőségét. Ha a minőség csökkent, általában az adatkészlet bővítése és egy újabb fine-tuning ciklus elegendő — nem szükséges az alap modellt cserélni.
Ha a fine-tunolt modellt nem helyi Ollama-ban, hanem megosztott infrastruktúrán szeretnéd elérhetővé tenni, a HuggingFace Hub privát repója kényelmes megoldás. A model.push_to_hub("szervezet/modell-nev", private=True) feltölti a HuggingFace-re. Onnan ollama pull hf.co/szervezet/modell-nev paranccsal bármely szerver letöltheti — feltéve, hogy HF_TOKEN beállítva van. Ez biztosítja a verziókövetést és a csapatmegoszthatóságot anélkül, hogy saját modell-hosting infrastruktúrát kellene üzemeltetni.
Kérdések és válaszok
Mi az a LoRA és miben különbözik a teljes fine-tuningtól?
A full fine-tuning az összes modellparamétert módosítja — egy 7B modellnél ez 7 milliárd súlyt jelent, hatalmas VRAM- és compute-igénnyel. A LoRA (Low-Rank Adaptation) az eredeti súlyokat befagyasztja, és csak kis rang-mátrixokat ad hozzá az egyes rétegekhez. A tanítható paraméterek száma az eredeti 0,1–1%-a, mégis hasonló teljesítményt ad tartomány-specifikus feladatokon.
Mi az a QLoRA és mikor érdemes QLoRA-t választani?
A QLoRA (Quantized LoRA) az alap modellt 4-bites kvantálással tölti be, miközben a LoRA adapter matrixin full precision (bfloat16) marad. Eredmény: 70% memória-megtakarítás a full LoRA-hoz képest. 7B modell QLoRA-val elfér 8–10 GB VRAM-on. Válaszd, ha RTX 3090-nél kisebb GPU-d van, vagy ha egy 13B/34B modellt szeretnél egyetlen fogyasztói GPU-n fine-tunolni.
Mekkora adatkészlet szükséges az első fine-tuninghoz?
Instruction fine-tuninghoz 1000–5000 minőségi példa általában elegendő, ha az alap modell már erős általános képességekkel rendelkezik. Stílusmódosításhoz vagy terminológia-adaptációhoz akár 200–500 példa is eredményes lehet. A minőség fontosabb a mennyiségnél: 1000 konzekvens, pontos example jobb, mint 10 000 vegyes minőségű — a rossz adatok a hibás viselkedést is megtanítják.
Milyen formátumban kell az adatkészlet?
A legelterjedtebb formátum a JSON Lines (JSONL) — minden sor egy önálló JSON objektum. Az instruction-following formátum három mezőt tartalmaz: instruction (mi a feladat), input (opcionális kontextus vagy bemeneti szöveg) és output (a kívánt válasz). Néhány keretrendszer (pl. Unsloth, Axolotl) a ShareGPT formátumot preferálja: messages lista, amelyben role és content váltakozik.
Milyen hardver kell LoRA fine-tuninghoz?
7B modell QLoRA-val: 8–10 GB VRAM elegendő — RTX 3090, RTX 4080, A10G. 7B teljes LoRA-val: 16–20 GB VRAM szükséges. 13B modell QLoRA: 12–16 GB VRAM. Ha nincs megfelelő lokális GPU, RunPod vagy Lambda Labs cloud GPU rentelés 50–200 USD közötti teljes fine-tuning costtal reális alternatíva — tipikusan 1–8 óra GPU időt vesz igénybe egy 7B modell.
Mennyi ideig tart egy 7B modell fine-tuningja?
1000–3000 példával, QLoRA-val, RTX 4090-en tipikusan 1–3 óra. RTX 3090-en 2–5 óra. RunPod A100 40GB-on 30–90 perc. Az epoch-ok száma (tipikusan 2–5) és a batch_size (nagyobb GPU-n nagyobb batch) dominálják az időt. Az Unsloth keretrendszer 2–5× gyorsítást ad vanilla HuggingFace Trainer-hez képest — érdemes használni.
Hogyan értékeljük a fine-tuning minőségét?
Három szint: (1) manuális spot-check — 20–50 példán kézzel értékeld a kívánt viselkedés megjelenését; (2) automatikus benchmark — Eleuther AI LM Eval Harness domain-specifikus kérdéseivel; (3) production A/B teszt — fine-tuned vs. alap modell válaszainak összehasonlítása valós felhasználói kérdéseken. A legfontosabb: az alap modell képességeit (instruction-following) nem rontottuk el.
Mikor éri meg fine-tuningot végezni vs. RAG-ot használni?
RAG: ha az adatok változnak, ha forrásjelölés szükséges, ha az adatvédelem kritikus (az adatok nem kerülnek a modellbe). Fine-tuning: ha stílust/hangot kell megtanítani, ha a terminológia domain-specifikus és nem keresés-alapú, ha az instrukció-követési viselkedést kell módosítani. Az optimális vállalati stack általában hibrid: RAG + fine-tuned modell.
Hogyan mergeljük a LoRA adaptert az alap modellbe?
A LoRA adapter és az alap modell súlyait matematikailag össze lehet vonni (merge) — az eredmény egyetlen teljes modell, amelynek nincs futásidejű LoRA overhead-je. HuggingFace PEFT könyvtárban a merge_and_unload() metódus végzi ezt. A merged modell ezután GGUF formátumba konvertálható (llama.cpp convert script), és közvetlenül betölthető Ollama-ba egy Modelfile-lal.
Milyen use case-ekre a legjobb a LoRA fine-tuning?
Legeredményesebb use case-ek: vállalati stílus és hang megtanítása (pl. formális vs. köznyelvi kommunikáció), domain-specifikus terminológia elsajátítása (jogi, orvosi, műszaki), instrukció-formátum adaptáció (pl. mindig JSON-t adjon vissza), és specifikus elutasítási viselkedés módosítása. Kevésbé alkalmas friss tudás injectálásra — arra RAG hatékonyabb.
LoRA fine-tuningot tervezel? Segítek az adatkészlet-stratégiától a deploymentig.
Áttekintem a rendelkezésre álló vállalati adatokat, segítek az adatkészlet kialakításában, és elkészítjük együtt az első fine-tuning futtatást — validált evaluációval és deployment tervvel.
Konzultáció kérése Vissza a hubhoz →