A döntésmodellek egy alternatív megközelítést kínálnak a nagynyelvi modellek (LLM-ek) szövegtermelés-központú működésével szemben: nem tokenenként generált, szabad szöveget adnak vissza, hanem előre meghatározott válaszlehetőségek fölött számított döntéseket és azok valószínűségi eloszlását. Ennek gyakorlati példája egy ügyfélszolgálati jegy feldolgozása: a rendszernek meg kell határoznia, melyik csapat foglalkozzon vele, mennyire sürgős, és kér-e a felhasználó visszatérítést. A döntésmodellek közvetlenül ezeket a választípusokat és azok valószínűségeit szolgáltatják, anélkül, hogy teljes JSON- vagy szabad szöveges választ kellene generálniuk.
Miben különböznek a döntésmodellek
A döntésmodellek alapfelülete röviden: Állapot (state) + Kérdések (questions) + Engedett válaszok → Döntések + Valószínűségek. Három alap primitívet definiálnak:
- Choice: diszkrét opciók közötti eloszlás (például Billing, Technical, Sales). A modell minden opcióhoz logitot rendel, softmaxszal valószínűséget kapunk.
- Score: rendezett skála esetén a modell eloszlása alapján számított várható érték (például 0=low, 1=medium, 2=high). A visszaadott "score" az eloszlás várható értéke.
- Noul: bináris (Bernoulli) kérdésnél a „Yes” valószínűségét adja vissza (például: kér-e a felhasználó visszatérítést?).
A döntésmodellek így egyszerre képesek több, tipizált kérdés kezelésére ugyanarról az állapotról, és minden válasz mellé valószínűséget és (Choice/Score esetén) konfidenciát adnak.
Miért nem elég az LLM-ek JSON-írása?
Sok alkalmazás ma is LLM-eket használ osztályozásra vagy routingra, és egyszerű promptra kér JSON-t. Ennek hátrányai:
- A generált kimenet nem garantáltan követi a várt sémát (érvénytelen JSON, váratlan kulcsok, a megengedett opciókon kívüli válaszok).
- A megszorításos dekódolás (constrained decoding) megoldja a sémaproblémát, de számítási többlettel jár.
- Autoregresszív szövegtermelés felesleges lehet, ha az alkalmazás csak előre definiált kategóriák között akar választani.
A döntésmodellek nemcsak a futásidejű címke-definíciót és a valószínűségeket teszik elérhetővé, hanem egy egységes, nem generatív API-t is, amelyet optimalizálni lehet megbízható, kalibrált döntésekre.
Konfidencia és hogyan számolják
A Choice és Score típusú válaszokhoz a felület "confidence" mezőt is ad. Choice esetén a konfidencia a legnagyobb valószínűség (p_max) normalizálása a kategóriák számához (K):
C = (p_max - 1/K) / (1 - 1/K)
Intuíció: ha a disztribúció uniform, a konfidencia 0; ha teljesen koncentrált egy opcióra, a konfidencia 1. A konfidencia segít összefoglalni, mennyire koncentrál a modell hite az egyik opció körül.
Hogyan illeszkedik mindez a Hugging Face ökoszisztémába
Hugging Face célja egy közös döntésmodellezési interfész definiálása anélkül, hogy előírná a belső implementációt. Ezt úgy valósítják meg, hogy több rétegben támogatást adnak:
- Inference / Transformers
- A Transformers könyvtár kiegészült DecisionPipeline, AutoModelForDecision és DecisionConfig osztályokkal, amelyek a döntésmodellek felületére szabottak.
- Létezik /v1/systemone végpont is; lokálisan a "transformers serve" parancs indítható (a szükséges serving csomaggal).
- Példa válasz egy kérésre tartalmazhatja a három választ: department (choice) + urgency (score) + refund (noul) mezőket, valószínűségekkel és konfidenciákkal. Egy demonstrációban a választ tartalmazó JSON-ban az "input_tokens" értéke 148, "output_tokens" 0 volt.
- Serving via llama.cpp
- A llama.cpp is támogatja a /v1/systemone API-t, és GGUF modelleket lehet indítani szerverként (például: "llama serve -hf ggml-org/Kev-4B-GGUF"). A példában a szerver alapértelmezett portja 9931.
- A hasonló API miatt az ugyanazon kérésformátummal különböző futtatók (Transformers, llama.cpp) is kompatibilisek.
- Felfedezés a Hubon
- A Hugging Face Hubon külön "decision-model" tag segít megtalálni a kompatibilis modelleket. A döntésmodellek között különböző belső architektúrák (encoder alapú ModernBERT-től nagy generatív hátterű modellekig) is megtalálhatók.
- Finomhangolás és tréning
- Mivel a döntésmodellek integrálva vannak a Transformers-be, finomhangolhatók a Trainer API-val. A cikkben példaként szerepel egy JEV-9B checkpoint, amelyet egy apró, demonstrációs adathalmazon tanítanak döntés-kimenetekre (példák: "I was charged twice. Please refund me." → "refund" stb.).
- A finomhangolásnál a modell döntéskonfigurációja készíti elő az inputokat; choice kérdésekre cross-entropy loss-szal tanítanak.
- Később TRL és egyéb eszközök is támogatást kapnak, és van recept (Unsloth) arra, hogyan lehet generatív LLM-eket döntésmodellekké alakítani LoRA-val és döntés-scoring fejjel.
Miért fontos ez a gyakorlatban
Döntésmodellek azért hoznak újat, mert a döntést és a valószínűséget elsőrendű, géppel feldolgozható kimenetté emelik. Ez egyszerűsíti a rendszerek integrációját, csökkenti a generatív dekódolás szükségességét strukturált feladatoknál, és lehetővé teszi specializált tréninget a megbízhatóság és kalibráció javítására. Emellett az egységes API-k (Transformers DecisionPipeline, /v1/systemone) és a Hub-tag segítik az ökoszisztéma eszközeinek és modelleinek interoperabilitását.
Összegzés
A döntésmodellek nem feltalálnak egy teljesen új képességet—klasszikus osztályozás és zero-shot megközelítések már sok mindent tudnak—viszont egy egységes, tipizált és valószínűségeket hangsúlyozó felületbe foglalják ezeket az eszközöket. A Hugging Face és a kapcsolódó futtatók (például llama.cpp) támogatása gyorsítja az éles használatba vételt: ugyanaz a kérésforma, több primitív (choice/score/noul), valószínűségi kimenetek és konfidencia-értékek állnak rendelkezésre a produkciós döntéshozatalhoz.
