06 - Sampling és modellviselkedés¶
Az LLM outputja nem úgy készül, mint egy determinisztikus függvényé, például a calculateTax(amount) esetén. A modell valószínűségi eloszlást becsül a lehetséges következő tokenekre, majd egy decoding stratégia választ ebből az eloszlásból.
Ez azt jelenti, hogy két teljesen azonos request is adhat eltérő, mégis érvényes választ.
Alap mentális modell¶
A generálás minden lépésében a modell valószínűségeket ad a lehetséges következő tokenekhez.
Egyszerűsített példa:
Input: "The capital of France is"
Possible next tokens:
Paris 0.96
Lyon 0.01
Marseille 0.005
...
Egyértelmű tényeknél egy opció erősen dominálhat. Kreatív vagy bizonytalan feladatoknál több folytatás is valószínű lehet.
Temperature¶
A temperature azt befolyásolja, hogy a modell mennyire szűken vagy szélesen mintavételez a token-valószínűségekből.
Koncepcionálisan:
- alacsonyabb temperature → konzervatívabb, ismételhetőbb választások,
- magasabb temperature → változatosabb, exploratívabb választások.
Példák:
Alacsony temperature:
- classification
- extraction
- code transformation
- structured business output
Magasabb temperature:
- brainstorming
- naming ideas
- creative writing
- alternatives feltérképezése
A temperature nem teszi okosabbá a modellt. A magasabb érték nem javítja automatikusan a reasoning minőségét; főleg a változatosságot és a véletlenszerűséget növeli.
Top-p¶
A top-p, más néven nucleus sampling, a candidate tokeneket arra a legkisebb halmazra korlátozza, amelynek összesített valószínűsége elér egy megadott küszöböt.
Általában nincs szükség arra, hogy egyszerre agresszívan hangoljuk a temperature-t és a top-p-t. Application engineeringben érdemes az alapértékekkel kezdeni, amíg evaluation nem mutat konkrét problémát.
A determinizmus relatív¶
Még konzervatív sampling beállítások mellett sem feltétlen garantált a teljes determinizmus különböző:
- model versionök,
- provider backend változások,
- floating-point execution különbségek,
- reasoning systemek,
- tool usage,
- változó retrieved context
között.
Ha egy business rule-nak mindig pontosan ugyanúgy kell működnie, implementáld determinisztikus kódban.
Rossz design:
Prompt:
"If total > 10,000 EUR, require manager approval."
Jobb design:
requires_approval = total > 10_000
A modell elmagyarázhatja a szabályt, de az application code enforce-olja.
Seed¶
Néhány API seedet is biztosít, amellyel reprodukálhatóbbá tehető a sampling. Ez teszteknél hasznos lehet, de nem szabad univerzális garanciaként kezelni arra, hogy az output örökre bitre pontosan ugyanaz lesz.
Model upgrade vagy infrastruktúraváltozás továbbra is módosíthatja az eredményt.
Miért különbözhetnek az ismételt válaszok?¶
Tegyük fel, hogy a feladat:
Adj három nevet egy AI monitoring terméknek.
Nincs egyetlen helyes válasz. Sok token-útvonal elfogadható, ezért az ismételt hívások természetesen eltérhetnek.
Ezzel szemben:
Extract invoice_number from this document.
feladatnál alacsony varianciára érdemes törekedni világos instructionnel, structured outputtal, validationnel és evaluationnel.
Reasoning behaviour¶
A reasoning-capable modellek több computationt használhatnak a válasz előtt. Ez javíthatja a planning, coding, matematika és összetett decision taskok teljesítményét, de nem szünteti meg a bizonytalanságot.
Fontos különbség:
more reasoning
!=
guaranteed correctness
A reasoning eredményt továbbra is validálni kell, ha application state-et befolyásol.
A task típusa befolyásolja a kívánt modellviselkedést¶
Hasznos application-level felosztás:
| Task | Kívánt viselkedés |
|---|---|
| Extraction | Stabil és korlátozott |
| Classification | Stabil és korlátozott |
| Code generation | Többnyire kötött, némi rugalmassággal |
| Planning | Explorative, de grounded |
| Brainstorming | Változatos |
| User-facing prose | Természetes, mérsékelten rugalmas |
Ez hasznosabb, mint egyetlen globális sampling konfigurációt keresni az egész alkalmazásra.
Variance és evaluation¶
Mivel az output változhat, egyetlen példát egyszer lefuttatni gyenge bizonyíték.
Ahelyett, hogy:
Prompt v2 egyszer jobb választ adott.
inkább:
Run evaluation set
|
+--> quality score
+--> failure rate
+--> format compliance
+--> latency
+--> cost
Bizonyos taskoknál több futás/test case is hasznos lehet a variance mérésére.
Gyakori hibák¶
1. Temperature mint quality knob¶
A temperature növelése nem oldja meg a gyenge reasoninget vagy a hiányzó contextet.
2. Pontos szövegegyezés kikényszerítése¶
Két szemantikailag azonos válasz eltérő megfogalmazást használhat. Open-ended generationnél az exact string test sokszor nem megfelelő.
3. Determinisztikus szabályok promptba helyezése¶
Ha valamit biztonságosan ki lehet fejezni kóddal, validationnel vagy schemával, azt használd.
4. Feltételezni, hogy reasoning model nem hallucinál¶
Az erősebb reasoning csökkenthet bizonyos hibákat, de a modell továbbra is tehet rossz feltételezést, félreértheti a contextet vagy kitalálhat tényt.
Developer takeaway¶
A model outputot probabilisztikus komponensként kezeld egy determinisztikus software systemen belül.
A modell rugalmasságát ott használd, ahol értéket ad, és determinisztikus boundarykkal vedd körül ott, ahol correctness szükséges.