A standard benchmarkok a modell általános képességeit mérik egy ismert pályán. A te munkád Red Teamerként viszont az, hogy letérj erről a pályáról, és felderítsd azokat a rejtett ösvényeket és szakadékokat, ahol a modell elbukik. Ehhez pedig nem elég a térkép – saját terepet kell építened. Az egyedi adatkészletek pontosan ezt a célt szolgálják: célzott, specifikus és gyakran alattomos tesztesetek gyűjteményei, amelyek a modell legérzékenyebb pontjait veszik célba.
Mikor van szükség egyedi adatkészletre?
Bár a szintetikus adatgenerátorok és a meglévő benchmarkok sokszor elegendőek, bizonyos helyzetekben elkerülhetetlen a nulláról építkezés. Ezek a leggyakoribb forgatókönyvek:
- Specifikus kulturális vagy nyelvi árnyalatok tesztelése: Amikor egy modellnek meg kell értenie a magyar szarkazmust, a szubkulturális szlenget vagy a történelmi utalásokat, a globális adatkészletek csődöt mondanak.
- Új típusú sebezhetőségek feltárása: Ha egy olyan új támadási vektort (pl. „prompt leaking” egyedi formátumokon keresztül) vizsgálsz, amire még nem létezik publikus benchmark.
- Domain-specifikus tudás értékelése: Egy jogi, orvosi vagy pénzügyi területen működő modell teszteléséhez olyan adatokra van szükség, amelyek a szakterület mély logikáját, terminológiáját és buktatóit tartalmazzák.
- „Low-resource” forgatókönyvek szimulálása: Amikor a modellnek nagyon kevés példából kell tanulnia vagy általánosítania egy ritka, de kritikusan fontos helyzetben.
- A védekezési mechanizmusok határainak feszegetése: Olyan gondosan megtervezett, ártalmatlannak tűnő inputok létrehozása, amelyek célzottan kijátsszák a beépített biztonsági szűrőket.
Az egyedi adatkészlet-készítés folyamata
Az egyedi adatkészlet létrehozása nem csupán adatgyűjtés, hanem egy kutatási projekt, amely precíz tervezést és módszeres végrehajtást igényel. A folyamat általában az alábbi lépésekből áll.
1. Célmeghatározás és hipotézisalkotás
Minden egyedi adatkészlet egy erős hipotézissel kezdődik. Nem csak adatokat gyűjtesz, hanem egy konkrét sebezhetőséget próbálsz bizonyítani vagy cáfolni. Például:
- Hipotézis: „A modell nem képes megkülönböztetni a valódi orvosi tanácsot az áltudományos, veszélyes állításoktól, ha azok tudományosnak hangzó nyelvezetet használnak.”
- Cél: Olyan adatpárok létrehozása, ahol egy valid orvosi állítás és egy megtévesztő, de hasonló stílusú álhír szerepel.
2. Adatgyűjtés
A források változatosak lehetnek, a stratégiát a hipotézis határozza meg.
- Manuális gyűjtés: Szakértők által írt példák, webes fórumokról, közösségi médiából vagy belső dokumentumokból kézzel kigyűjtött adatok. Időigényes, de rendkívül célzott.
- Fél-automatizált gyűjtés: Scriptek használata specifikus weboldalak (pl. Reddit, GitHub Issues) tartalmának letöltésére, kulcsszavak alapján.
- Crowdsourcing: Platformok (pl. Amazon Mechanical Turk, Prolific) bevonása, ahol emberek pénzért generálnak vagy címkéznek adatokat egy részletes útmutató alapján. A minőségellenőrzés itt kulcsfontosságú.
3. Adattisztítás és feldolgozás
A nyers adat szinte sosem használható azonnal. A tisztítási fázis magában foglalhatja a duplikátumok eltávolítását, a formátumok egységesítését (pl. dátumok, számok), a személyes adatok (PII) anonimizálását vagy eltávolítását, és a zajos vagy irreleváns adatok kiszűrését.
4. Annotáció és címkézés
Ez a legkritikusabb és gyakran legdrágább lépés. Itt rendelsz jelentést az adatokhoz. Elengedhetetlen egy kristálytiszta annotációs útmutató (guideline), amely minden lehetséges eshetőségre kitér. A minőség biztosítására bevett gyakorlat az Inter-Annotator Agreement (IAA) mérése, ami megmutatja, mennyire értenek egyet a címkézők.
Példa egy egyszerű annotációs sémára egy toxicitás-észlelő adatkészlethez:
| Szöveg | Címke (Toxikus/Nem toxikus) | Altípus (opcionális) | Annotátor indoklása |
|---|---|---|---|
| „Ez a legrosszabb termék, amit valaha vettem. Senkinek sem ajánlom.” | Nem toxikus | Negatív kritika | Erős negatív vélemény, de nem tartalmaz személyes támadást vagy sértést. |
| „Aki ezt tervezte, egy komplett idióta.” | Toxikus | Személyes sértés | Közvetlenül és sértő módon minősíti a tervezőt. |
5. Verziókezelés és dokumentáció
Kezeld az adatkészletedet úgy, mint a szoftverkódot. Az olyan eszközök, mint a DVC (Data Version Control), lehetővé teszik az adatkészlet különböző verzióinak követését a Git mellett. A dokumentációnak tartalmaznia kell:
- A gyűjtés módszertanát és forrásait.
- Az annotációs útmutatót.
- Az adatkészlet ismert korlátait és potenciális torzításait (bias).
- A statisztikai jellemzőket (méret, osztályeloszlás stb.).
# Példa DVC parancsokra egy új adatkészlet verziókövetéséhez
# Először inicializáljuk a DVC-t a git repóban (ezt csak egyszer kell)
# dvc init
# 1. Hozzáadjuk a fájlt a DVC követéséhez
dvc add adatok/toxikus_kommentek_v1.csv
# 2. A generált .dvc fájlt hozzáadjuk a git-hez
git add adatok/toxikus_kommentek_v1.csv.dvc adatok/.gitignore
# 3. Commit-oljuk a változást a git-ben
git commit -m "feat: toxikus kommentek v1.0, manuális gyűjtés"
# 4. Feltöltjük az adatokat egy távoli tárolóba (pl. S3, GCS)
dvc pushEtikai és jogi megfontolások
Az egyedi adatkészletek készítése során különös gondot kell fordítani az adatvédelemre és az etikai szempontokra. Soha ne használj fel személyazonosításra alkalmas adatokat (PII) a felhasználók beleegyezése nélkül! A web scraping során is tartsd tiszteletben a weboldalak `robots.txt` fájlját és felhasználási feltételeit. Egy adatvédelmi incidens súlyos jogi és reputációs következményekkel járhat.