22.2 Címkemegőrző transzformációk

22.2.1 1. Cél, előismeret és induló kérdés

A 22.1. Adateredet, címke és csoportos split egység rögzítette, hogy a GlyphLab 360 képéhez 180 független jelenet tartozik, és a splitet scene-szinten kell nyilvántartani. Ott a címke és a rekord kapcsolatáról a hosszanti, adatkezelési oldalon volt szó. Most ugyanennek a szerződésnek a transzformációs oldalát vizsgáljuk: ha a betanított modellt egy augmentációs pipeline-on keresztül tápláljuk, mikor marad a kimeneti címke változatlan, és mikor változtatja meg a transzformáció magát a feladatot?

A 21.3. Dropout, súlyregularizálás és augmentáció a regularizáló eszközöket úgy vezette be, hogy az augmentációt csak megemlítette. A 10.2. Affín réteg és aktiváció backward a backward VJP-szabályainál a batch- és broadcast-műveleteket kezelte; ott minden tenzorműveletnek egzakt, indexelt definíciója volt. A 18.2. Batch normalization train és eval módban pedig a BatchNorm train/eval kettősségénél hangsúlyozta, hogy ugyanaz a forward-képlet különböző üzemmódban más statisztikát használ. Ugyanez a minta tér vissza az augmentációban: ugyanaz a geometriai művelet egészen más szerződést teljesít, ha a címkét, a maszkot és a dobozt is transzformáljuk vagy éppen nem.

Induló kérdés. A GlyphLab osztályai: 0 = vertical, 1 = horizontal, 2 = diagonal. Ha a 0. osztályú képet 90 fokkal elforgatjuk, a megjelenő gerenda vízszintes lesz. Az eredeti címke 0 maradhat-e? A becslését a 4. szakasz kézi példája után ellenőrizheti: ott a számítás nem szorzás, hanem egy címketér-leképezés felírása lesz.

22.2.2 2. Definíció: augmentáció, transzformáció és a címkemegőrző szerződés

Definíció (augmentáció). Legyen $(X,y)$ egy kép-címke pár, ahol $X \in \mathbb R^{C \times H \times W}$ (a batch-nélküli GlyphLab-konvencióban $C=1$), $H$ a magasság, $W$ a szélesség. Az augmentáció egy $\mathcal T : \mathcal X \to \mathcal X$ adattranszformáció, amelyet a tanítási adatfolyamban a minibatch betöltésekor alkalmazunk, nem előre elmentett fájlként. A célja a gyakorlati variabilitás növelése a tényleges adatgyűjtés nélkül; a modell így ugyanazt a tanítópéldát több realizációban láthatja.

A transzformáció akkor része a szerződésnek, ha külön mondjuk meg, hogy milyen objektumra hat. Két különböző, nem felcserélhető objektumról van szó:

Definíció (címkemegőrző transzformáció). A $\mathcal T$ transzformáció akkor címkemegőrző az adott tanítási feladatra, ha minden olyan $(X,y)$ párra, amelyre $\mathcal T$ értelmezve van, a transzformált képhez is az $y$ osztály tartozik. Rövidebben: a feladat címketér-leképezése $f$ kielégíti az

$$f(\mathcal T(X)) = y = f(X)$$

egyenlőséget a tanítási halmaz elemeire.

A jelölés szándékosan „az adott feladatra” szól. A definícióban $f$ a feladat címkézőfüggvénye, nem a tanított modell. Például a GlyphLab feladatban $f$ a vonás áthaladási irányát adja, és ez a modell címkéjének értelmezését rögzíti, függetlenül attól, hogy a betanított súlyok mit jósolnak. Két rövid megjegyzés a definícióhoz:

1. A címkemegőrzés nem ugyanaz, mint a vizuális hasonlóság. Egy transzformáció lehet percepciósan jelentéktelen, de a feladat címkéjét mégis megváltoztatja – lásd a 3. szakasz forgatási ellenpéldáját, ahol az emberi szem ugyanazt a figurát látja, de az orientációcímke megváltozott.
2. A címkemegőrzés sem ugyanaz, mint a modellinvariancia. Az invariance kifejezést a 16.1. Eltolási equivariance és invariance egység a modell fekete dobozára használta: $h(\mathcal T(X))=h(X)$, ahol $h$ a tanított modell pontszáma. Itt a szerződés a feladat címkéjére, nem a modell outputjára vonatkozik.

A szerződés numerikusan így ellenőrizhető egy konkrét, reprodukálható pipeline-ban: minden olyan $X$-re, amelyre a transzformációt megengedjük, a transzformált $X'=\mathcal T(X)$ párnak is $y$-nak kell lennie a céltenzorgenerátor szerint. Ez a definíció a klasszifikációs transzformáció-katalógusokban label-preserving néven ismert; a PyTorch dokumentációja [D08] a Dataset és DataLoader folyamatában a transzformációk általános alkalmazását rögzíti, de a címke- és annotáció-szinkronizálást a felhasználó szerződéseként kezeli. Az adott transzformációt megvalósító API pontos paramétereit a hallgató a telepített könyvtár dokumentációjában ellenőrzi.

22.2.3 3. A transzformációk alakja, indexelése és a levezetési kötelezettség

22.2.3.1 Crop és a kivágás indexhalmaza

A crop művelet az indexek leszűkítése. Egy kivágási ablakot fél-nyílt, nullától indexelt intervallumokkal adunk meg, ugyanazon konvencióval, mint a 22.1. Adateredet, címke és csoportos split alfejezetben a dobozra: $(i_{\text{top}}, i_{\text{left}}, i_{\text{height}}, i_{\text{width}})$, és a kivágott kép

$$X'_{c,i,j} = X_{c,\, i_{\text{top}} + i,\, i_{\text{left}} + j}, \qquad c<C,\; i < i_{\text{height}},\; j < i_{\text{width}}.$$

A magasságra a fél-nyílt feltétel: $i_{\text{top}} \le i < i_{\text{top}} + i_{\text{height}}$, azaz a kivágott terület az $[i_{\text{top}}, i_{\text{top}}+i_{\text{height}})$ intervallum. Az output alakja $C \times i_{\text{height}} \times i_{\text{width}}$.

A crop címkemegőrző az osztályozási feladatra, ha a kivágás választását az osztályt meghatározó tartalomtól függetlenül rögzítjük, és a kép tartalma elégséges a címke eldöntéséhez. Ahhoz, hogy ezt a feltételt ne csak heurisztikusan mondjuk ki, a tanulási szerződés szempontjából rögzítjük: a transzformáció akkor elfogadott, ha a kivágás utáni kép az eredeti $X$-ből származó, a cél szempontjából reprezentatív mintája. A crop önmagában nem címkeőrző eljárás, hanem indexhalmaz-művelet; a címkeőrzés a kivágási politikától függ. Például a GlyphLabban egy olyan kivágás, amely a gerendát teljesen elhagyja, megszünteti a címkét hordozó tartalmat, tehát megsérti a szerződést, még ha a pixelformát tekintve simának is tűnik.

A hivatalos követelmény a kép és a társannotáció szinkronja esetén szigorúbb, hiszen a maszkhoz és dobozhoz is ugyanazt az indexhalmazt kell használni. A 4. szakaszban a doboz transzformációját külön számoljuk ki.

22.2.3.2 Resize és a kép indexeinek újrahálózása

A resize a diszkrét kép rácsát egy másik rácsra képezi. A legátláthatóbb, matematikailag is következetes fogalom a bilineáris interpoláció: az $X_{c,i,j}$ intenzitást az $i,j$ diszkrét pozíciójú minta folytonos interpolációjának tekintjük, és az $X'$ kimenet $p,q$ mintájához a forrásrácsban keressük az $x$ és $y$ koordinátákat. Pontosabban, az output pixel $(p+0.5)$-normalizált pozícióját az input pixel-centrumoknak megfelelően interpoláljuk. A részletes kernel pozíciófüggő: a $w_{r,s}(p,q)$ súlyok a forrás- és célrács koordinátáitól függenek, a pixelintenzitásoktól viszont nem. Rögzített be- és kimeneti rács mellett ezért a resize az intenzitásokra nézve lineáris operátor, és a kép minden csatornájára ugyanaz:

$$X'_{c,p,q} = \sum_{r,s} X_{c,r,s} w_{r,s}(p,q), \qquad p<H_{out}, q<W_{out},$$

ahol a $w$ súlyok a célrácstól függő, bilineáris kernel. Tehát $R(aX+bY)=aR(X)+bR(Y)$ minden $a,b$ valós számra és azonos méretű $X,Y$ képre; a bilineáris interpoláció koordinátafüggése ezen nem változtat. Valóban nemlineáris lépés csak az, ami az eredményre utólag hat, például a $[0,1]$-be vágás (clipping), a kerekítés uint8-ra, vagy az adaptív, a képtartalomtól függő súlyválasztás (például antialias-szűrő, amelynek mérete a tartalomtól függ); ezeket a szerződésben külön kell megnevezni. A 14.1. Stride, padding, dilation és outputméret padding/stride képletétől eltérően itt nincs konvolúciómag – ez a művelet mintavételi átkonvertálás, nem szűrő.

A resize akkor címkemegőrző az osztályozási feladatra, ha a feladat nem függ egy képpontos részlet abszolút méretétől, csak a geometriai tartalom relatív konfigurációjától. Ez a GlyphLab orientációs feladatán teljesül: a gerenda függőleges vagy vízszintes iránya egy kisebb rácson is olvasható. Az alábbi feltételt írásban is rögzítjük: a resize akkor engedhető meg, ha a forrás- és célméret eltérése nem éri el a klasszifikációhoz szükséges minimális felbontást. Ha például $24 \times 24$-ről $4 \times 4$-re kicsinyítünk, egy vékony, 2 pixel vastag vonal eltűnhet; az ilyen resize nem címkemegőrző, mert a cél-információ megsemmisül. Ez a megállapítás heurisztika, nem bizonyított tétel: a megengedett minimális méretet a konkrét generátor vastagságeloszlása ellenőrzi, amit a 22.1. Adateredet, címke és csoportos split generátorának dokumentációja rögzít.

22.2.3.3 Flip: tengelycsere, ami csak bizonyos tengelyekre címkeőrző

A vízszintes tengelyű tükrözés (horizontal flip) a szélességi indexet tükrözi:

$$X'_{c,i,j} = X_{c,i,W-1-j}, \qquad i<H, j<W.$$

A függőleges tengelyű tükrözés analóg:

$$X'_{c,i,j} = X_{c,H-1-i,j}.$$

A flip fontos tulajdonsága, hogy az osztályozási címkét csak az adott feladat hagyja meg, míg az annotációt szinkronban kell tükrözni. Ez a megkülönböztetés a jelen fejezet magja. Egy kép vízszintes tükrözése a vizuális tartalmat megőrzi, de a GlyphLabban a diagonal osztály csak az egyik ferde irányt tartalmazza. A GlyphLab ADATOK.md szerződése kifejezetten rögzíti: a 90 fokos forgatás a vertical és horizontal címkét felcseréli, és a diagonal osztály csak az egyik ferde irányt tartalmazza, ezért tükrözés/forgatás új célértelmezést igényelhet. A tükrözött diagonal már a másik ferde irány, ami egy másik feladatcímke lenne, nem a meglévő 2. osztály.

22.2.3.4 Rotation és a levezetési kötelezettség: ellenpélda a címkemegőrzésre

Állítás. Nem minden forgatás címkemegőrző minden osztályozási feladathoz. Konkrétan a GlyphLab orientációs feladatán a 90 fokos forgatás a vertical és horizontal osztályokat kölcsönösen felcseréli, így a transzformáció az eredeti címke megtartásával nem érvényes.

Bizonyítás. Legyen a GlyphLab feladat címkézője $f:\mathcal X \to \{0,1,2\}$, ahol a 0 a függőleges, 1 a vízszintes, 2 a diagonal vonalat rendeli a képhez. Legyen $\mathcal R_{90}$ a képsík óramutató járásával megegyező 90 fokos forgatása. A GlyphLab generátora olyan képeket állít elő, amelyeken a vonal függőlegesen, vízszintesen vagy diagonalisan fut. Egy függőleges, az $i$-tengely mentén hosszan elnyúló vonal a forgatás után a $j$-tengely mentén hosszan elnyúlt, azaz vízszintes vonal lesz:

$$f(\mathcal R_{90}(X_{\text{vertical}})) = 1, \qquad\text{de } f(X_{\text{vertical}}) = 0.$$

A vízszintes vonalra szimmetrikusan:

$$f(\mathcal R_{90}(X_{\text{horizontal}})) = 0, \qquad\text{de } f(X_{\text{horizontal}}) = 1.$$

Mivel tehát $f(\mathcal R_{90}(X)) \neq f(X)$ legalább egy $X$-re, a $\mathcal R_{90}$ transzformáció nem címkemegőrző a GlyphLab feladatára. $\blacksquare$

A bizonyítás a definiált célfeladat szintjén teljes; nem szükséges hozzá általános képi ontológia. Szándékosan mutattuk meg, hogy a címkemegőrzés feladattól függ, nem a forgatóképesség gyenge. Egy olyan feladatnál, ahol a cél a vonal jelenléte (nem annak iránya), a $\mathcal R_{90}$ címkemegőrző lenne: a vonal jelen marad. A fontos üzenet tehát: a geometriai invariancia a cél definíciójához képest értendő.

22.2.3.5 Intenzitástranszformáció

Az intenzitástranszformáció a $c$ csatornán a $[0,1]$ tartományú intenzitásra hat, nem az indexre. Az egyszerű eltolás-skálázás például:

$$X'_{c,i,j} = aX_{c,i,j}+b,$$

ahol $a>0$ és $b$ skalár, a kimenetet pedig a $[0,1]$ tartományra vágjuk vagy normalizáljuk. A GlyphLab $[0,1]$ képein $0\le aX+b\le 1$ megkötés mellett az intenzitás a látható tartalmat nem szünteti meg. A brightness csatorna transzformációja akkor címkemegőrző az orientációs feladatban, ha a kontraszt és a fényesség nem befolyásolja a vonal pozícióját. Fontos korlát: ha az intenzitásművelet a zaj szintjét a kép szubjektív osztályozhatóságán túl növeli, a cél címkéje már nem az eredetiből igazoltan levezethető. Ez intenzitásnál és zajosításnál észlelhetőségi feltétel, és a fejezetben mint ellenőrizendő heurisztikát jelöljük.

A normalizálás és az intenzitás-skálázás közötti különbség: az előbbi a modell numerikus bemenetét skálázza, az utóbbi a kép vizuális tartalmát módosítja. A címkemegőrzés szempontjából a minden képen ugyanazzal az affin intenzitástranszformációval végzett normalizálás akkor megengedett, ha a kép normája nem a címke döntő forrása. A GlyphLab feladatban a címkét az átvonuló iránya szolgáltatja, nem az átlagos fényesség, ezért a normalizálás önmagában megengedhető.

22.2.3.6 Mask és box szinkronizáció

A maszk és doboz ugyanazon képhez tartozó annotáció. A 22.1. Adateredet, címke és csoportos split szerint a maszk az előtér 0/1 döntése, a doboz a legszűkebb befoglaló téglalap fél-nyílt xyxy formában. Ha a kép indexeit transzformáljuk, a maszk és doboz indexeit ugyanazzal a geometriai leképzéssel kell transzformálni, különben a kép-pozíció és az annotáció elcsúszik.

A szinkronizáció pontos formája a következő. Legyen a geometriai index-leképezés $\sigma$, amely az output kép minden $i,j$ indexéhez egy $i',j'$ inputpozíciót ad. Ha a maszkot a kép transzformációjával azonos módon transzformáljuk, akkor a címke-annotáció ugyanarra a vizuális objektumra vonatkozik. A doboz esetében ez azt jelenti, hogy a sarkokat is a $\sigma$-nak megfelelően kell leképezni, figyelve a fél-nyílt intervallum konvencióra.

Példa (doboz horizontal flip). Legyen a kép szélessége $W$. Egy doboz $[x_{\min}, y_{\min}, x_{\max}, y_{\max})$ tükrözött alakja:

$$[W - x_{\max},\, y_{\min},\, W - x_{\min},\, y_{\max}).$$

A fél-nyílt konvenciót a tükrözés is megőrzi: az $x_{\min}\le x < x_{\max}$ feltételből $W-x_{\max}< W-x\le W-x_{\min}$ következik, ami a megfelelő fél-nyílt intervallumot adja. A 4. szakasz kézi példája ezt számolja ki.

A gyakori tévedés az, hogy a képhez egy véletlen transzformációt választunk, a maszkhoz/dobozhoz pedig egy másik, tőle független véletlent. Ez hibás tanítópárt eredményez, mert a kép és az annotáció különböző geometriai kölcsönhatásnak van kitéve. A 6. szakasz F4 feladata pontosan ezt a hibát lokalizálja.

22.2.4 4. Kézi kis példa: a GlyphLab 90 fokos rotációja és dobozszinkron

Tekintsünk egy $24\times 24$-es, a GlyphLab-szerű generátorral készült vertical osztályú képet. A vonal a $j=12$ oszlopban, a függőleges irányban fut. A címke 0. A doboz, mint a vonalat befoglaló legszűkebb téglalap:

$$[x_{\min}, y_{\min}, x_{\max}, y_{\max}) = [12, 4, 14, 20).$$

Azaz a vonal a 12. és 13. oszlopban, a 4. és 19. sorban látható (a fél-nyílt intervallum szerint $y_{\max}=20$ már nincs benne).

Az óramutató járásával megegyező 90 fokos forgatás (np.rot90(x, k=3)) egy $H\times W$ képet $W\times H$ képpé alakít, és a sor–oszlop indexpárt így képezi le:

$$(i,j)\mapsto(i',j')=(j,\;H-1-i).$$

Az új sorindex tehát a régi oszlopindex ($i'=j$), az új oszlopindex a régi sorindex tükre ($j'=H-1-i$). A dobozra: a régi $x\in[x_{\min},x_{\max})$ oszloptartományból az új sortartomány lesz, $y'\in[x_{\min},x_{\max})$; a régi $y\in[y_{\min},y_{\max})$ sortartományból pedig az új oszloptartomány $x'=H-1-y$, azaz $x'\in[H-y_{\max},\,H-y_{\min})$, mert $y\le y_{\max}-1$ esetén $H-1-y\ge H-y_{\max}$, és $y\ge y_{\min}$ esetén $H-1-y<H-y_{\min}$. Az xyxy sorrendben az új doboz

$$[x'_{\min},y'_{\min},x'_{\max},y'_{\max})=[H-y_{\max},\;x_{\min},\;H-y_{\min},\;x_{\max}).$$

A szélesség és a magasság szerepet cserél, a terület változatlan: $(H-y_{\min}-H+y_{\max})(x_{\max}-x_{\min})=(y_{\max}-y_{\min})(x_{\max}-x_{\min})$.

A példában $H=24$:

$$[24-20,\;12,\;24-4,\;14)=[4,\;12,\;20,\;14).$$

Az új doboz a 12. és 13. sort és a 4–19. oszlopot fedi: két pixel magas, 16 pixel széles vízszintes sáv, területe $2\cdot16=32$, ugyanannyi, mint az eredeti $2\cdot16$. Ez éppen a vízszintes vonal; a címke most 1 kellene hogy legyen, a 0 címkét meghagyni nem szabad, mert a transzformáció a címkét megváltoztatta. Ellenőrzés: a dobozból képzett $24\times24$-es bináris maszkot np.rot90(mask, k=3)-mal forgatva, majd a legszűkebb dobozt újraszámolva szintén $[4,12,20,14)$ adódik, a maszk elemszáma 32 marad.

22.2.5 5. Konkrét labor: a 90 fokos rotáció címkeváltoztató hatása

A jelen alfejezethez a következő helyi főutat írjuk elő. A labor a lab könyvtárban dolgozik, CPU-s NumPy-vel.

Protokoll. A gyakorlat célja: a GlyphLab train-képből válasszon ki egy vertical és egy horizontal képet, és igazolja a 90 fokos rotáció címkeváltoztató hatását.

Lépések.

1. python3 -c "import numpy as np; print(np.__version__)" ellenőrzi a NumPy-verziót. A labor Python 3.10+ és NumPy 1.21+ verziót feltételez, CPU-n.
2. A képek data/images.npy-ből töltődnek be: np.load("data/images.npy"); a train indexek metadata.csv-ből.
3. A transzformáció a 90 fokos forgatás: np.rot90(x, k=3, axes=(1,2)) a C×H×W tengelyen.
4. A kimeneti jelentés minden kiválasztott képhez kiírja az eredeti címkét, a forgatás utáni címkét, valamint a függőleges és vízszintes tengelyű projekció hosszát.
5. Az ellenőrzés: a vertical kép projekciója a magasság mentén koncentrált, a horizontálja szétterül; a forgatott képen a projekció tengelyei felcserélődnek.

Ellenőrzött jelentés helye. A lab/conv_check_report.json a korábbi labor futásait rögzíti; a 22.2. Címkemegőrző transzformációk laborhoz nem állítunk előre elvégzett futást. Ha a tanuló futtat, az eredményt a saját jegyzékébe kell feljegyezni. A laborban a seed és a dtype: a generátor 1.0, a képek float32. A labor csak a train splitet használja.

22.2.6 6. Feladatok

22.2.6.1 F1 (fogalmi, nehézség 1)

A 16.1. Eltolási equivariance és invariance equivariance és invariance fogalmával szemben itt a címkemegőrzésről van szó. Magyarázza el röviden a különbséget, és adja meg, hogy a 90 fokos rotáció a GlyphLab osztályozón melyik módon sérti a címkemegőrzést: a címke definícióját vagy a modell pontszámát változtatja meg?

22.2.6.2 F2 (levezetési, nehézség 2)

Adott egy $24\times 24$-es GlyphLab kép, rajta egy diagonal vonallal, amely a bal alsó sarokból a jobb felsőbe tart. A doboz $[2, 4, 22, 20)$. Számítsa ki a 90 fokos rotáció utáni dobozt, és ellenőrizze a fél-nyílt intervallum tartalmi értelmét.

22.2.6.3 F3 (implementációs, nehézség 2)

Írjon Python-függvényt, amely egy $N\times C\times H\times W$ tenzoron a vízszintes flipet hajtja végre a $W$ tengelyre. A függvény inputja a tensor, a kimenete ugyanolyan dtype; az ellenőrzéshez használjon egy $2\times 1\times 3\times 4$ bemenetet a $[[0,1,2,3],[4,5,6,7],[8,9,10,11]]$ panelre. Várt eredmény: minden sor fordított sorrendben.

22.2.6.4 F4 (hibakeresési, nehézség 2)

A következő pszeudokód szegmentálási augmentációt próbál létrehozni. Keresse meg a hibát, és indokolja, miért keletkezik hibás tanítópár.

for x, mask in loader:
    angle = np.random.uniform(0, 90)
    x_aug = rotate(x, angle)
    mask_aug = rotate(mask, angle + 5)
    train_step(x_aug, mask_aug)

22.2.6.5 F5 (kísérleti transzfer, nehézség 3)

A GlyphLab orientációs feladatban a class-stratified split 240 train és 60 val képet ad. Tervezzen kísérletet annak ellenőrzésére, hogy egy kiválasztott flip-augmentáció a diagonal osztályra címkét változtat-e. Ne hajtsa végre teljes körűen; a protokollhoz írjon megfigyelési egységet, baseline-t, metrikát és a konklúzió érvényességi határát.

22.2.7 7. Megoldások és indoklás

22.2.7.1 F1 megoldás

A címkemegőrzés a feladat címketér-leképezésére vonatkozik: a transzformált kép címkéje megegyezzen. Ezzel szemben az equivariance/invariance a modellfüggvény és a transzformáció felcserélhetőségét rögzíti. A 90 fokos rotáció a GlyphLab cél definícióját változtatja meg, mert az orientáció címkéje maga az irány; a modell viselkedése ettől független kérdés. A feladatcím már a kalibrált cél definíciójában sérül.

22.2.7.2 F2 megoldás

A diagonal doboz $[2,4,22,20)$ a 0-tól számozott rácsban a bal alsó sarkot és a jobb felső sarkot foglalja be. A 90 fokos óramutató szerinti forgatás képlete $(i,j)\mapsto(j,H-1-i)$, a 4. szakasz szerint az új doboz $[H-y_{\max},\,x_{\min},\,H-y_{\min},\,x_{\max})$:

$$[24-20,\;2,\;24-4,\;22)=[4,\;2,\;20,\;22).$$

A fél-nyílt intervallum most a 2–21. sort és a 4–19. oszlopot jelöli; a doboz $16\times20$-as lett a korábbi $20\times16$-os helyett, a terület (320) változatlan. A np.rot90(mask, k=3) után újraszámolt doboz ugyanez. Ez éppen az a diagonal, amely a bal alsó sarokból jobb felsőbe tart; a forgatás a geometriai irányt a másik ferde irányba vitte, így a diagonal osztály a forgatás után már nem áll fenn. A válasz konzisztens a 3. szakasz állításával: a doboz szinkronban transzformálódott, a címke azonban a cél definíciója miatt megváltozott.

22.2.7.3 F3 megoldás

A teljes futtatható ellenőrzés:

import numpy as np

def horizontal_flip_nchw(X):
    # X: ndarray, N x C x H x W
    return X[..., ::-1].copy()

x = np.arange(24, dtype=np.float32).reshape(2, 1, 3, 4)
# A feladat panelje: [0,1,2,3], [4,5,6,7], [8,9,10,11]
x[0,0] = [[0,1,2,3],[4,5,6,7],[8,9,10,11]]
x[1,0] = [[12,13,14,15],[16,17,18,19],[20,21,22,23]]
y = horizontal_flip_nchw(x)
print(y[0,0].tolist())
# [[3,2,1,0],[7,6,5,4],[11,10,9,8]]

Az ellenőrzés a dtype-ra: a .copy() nélkül a negatív stride nézet maradna, ami a későbbi np.ascontiguousarray-vel nem garantált. A kimenet float32, shape $2\times 1\times 3\times 4$. A tolerancia itt nincs, mert az indexcsere egzakt.

22.2.7.4 F4 megoldás

A hiba a kép és a maszk különböző szögű elforgatása. A mask-ra angle + 5 jut, tehát a pixelannotáció öt fokkal más pozícióba kerül. Ettől a maszk már nem a valódi előtér, és a tanító lépés ellentmondásos párt kap. A szegmentáló modell így csökkenteni fogja a hibát a képhez képest elcsúszott háttérként. A javítás: a két forgatás egy közös szöggel, azonos interpolációs konvencióval futtasson. A maszkhoz a legközelebbi szomszéd (nearest) ajánlott, hogy a 0/1 érték ne kenődjön el; a képhez bilineáris is lehet. A visszaellenőrzéshez ki lehet számolni a transzformált maszk és a transzformált kép előterének átlapolását, vagy egyszerűen egy mini batchre a feladat dobozát is szinkronban transzformálni és konzisztenciáját ellenőrizni.

22.2.7.5 F5 megoldásvázlat

Kérdés: a horizontal flip a GlyphLab diagonal osztályon címkét változtat-e?

Megfigyelési egység: scene_id, mert a két view ugyanazon jelenetből származik; a kísérlet a train és val split 30–30 diagonal jelenetét vizsgálja.

Baseline: a nem augmentált train spliten tanított kis ConvNet, a validációra mérve, a 16.1. Eltolási equivariance és invariance és 12.4. III. ellenőrző pont: önállóan tanuló kis háló eljárásához hasonlóan. Változó tényező: a flip mint transzformáció engedélyezése a betöltő pipeline-ban.

Metrika: a per-image osztályozási pontosság, de először a címkeinvariáns ellenőrzés: a transzformált képek diagonal céljain a modell a 2-es osztályt jósolja-e. Ez utóbbi a kérdés közvetlen mérőszáma, nem csak a teljes pontosság. A cél a címkét nem változtató, azaz a 2-es osztályt megtartó diagontranszformáció.

Protokoll: a train és val splitet a scene alapján rögzítjük. A diagonal osztályra szűrt halmazban a flip előtti és utáni célok változását mérjük a címkézőfüggvény szintjén: a generátor által ismert geometriai definíció szerint a diagonal a bal alsó–jobb felső irányt jelenti. A horizontal flip a diagonal vonalat a másik irányba viszi. Ezután a megengedett transzformációt az osztályokra aszimmetrikusan definiáljuk: vertical és horizontal osztályon a horizontal flip megengedhető, diagonalon nem.

Következtetési határ: a konklúzió a GlyphLab geometriai definíciójára vonatkozik, nem általános diagonal feladatokra. A generátor seedjével, verziójával és splitjével együtt megismételhető. A pontos kísérlethez a train/val split arányok az ADATOK.md-ben szerepelnek, és a 90 fokos forgatásos állítást a 3. szakasz bizonyította; a flipre a tükrözési szimmetria hiánya analóg, így az állítás a célfüggvény-definícióból következik. A kísérleti újdonság az lenne, hogy a pipeline-léptékű ellenőrzés mutassa a hatást, nem pedig a modell pontosságán.

A megoldás rubrikája: korrekt scene-stratifikáció, a flip és rotáció címkeingatásának elkülönítése, az érvényességi határ és annak rögzítése, hogy az eredmény a cél definíciójából következik.

22.2.8 8. Tipikus tévedés, önellenőrzés és visszahívás

Tipikus tévedés. Az a feltevés, hogy az augmentáció a vizuális hasonlóságot őrzi, ezért a címkét is. Az ellenpélda a 90 fokos rotáció: vizuálisan ugyanaz a vonal látható, de a feladat iránya megváltozott. Másik gyakori hiba: a flipet minden osztályra megengedni, mert a „vízszintes tükrözés nem változtat az ábrán”. A GlyphLab diagonal osztálya irányelvű, így a flip egy másik irányt ad.

Önellenőrzés. Válasszon egy képet a trainből, és forgassa 90 fokkal. Ha a címkét megtartva adná be, a modell a képet az ellenkező irányba tartozónak tanulná. Ezt önellenőrzéshez a fenti F3 flip és F2 dobozpélda segítségével ellenőrizheti: a kép, a maszk és a doboz ugyanazt a geometriai transzformációt kapja.

Visszahívás. A 10.2. Affín réteg és aktiváció backward batch-reduction és broadcast-szabálya itt is él: ha az augmentációt a minibatch betöltésekor alkalmazzuk, a képet és a célokat együtt kell transzformálni, és a batch-művelet nem tompíthatja el a hibás párokat. A 18.2. Batch normalization train és eval módban train/eval különbség ahhoz hasonló, ahogy az augmentáció csak a train pipeline-ban futtatható, az eval csővezetékben nem, vagy csak determinisztikusan. A 21.2. Learning rate és ütemezés üteme pedig arra figyelmeztet, hogy a training adat augmentációjának mennyisége és a learning rate schedule együtt befolyásolja a tanítási pályát.

22.2.9 9. Rövid összefoglaló

A címkemegőrző transzformáció fogalma a feladat célfüggvényéhez, nem a vizuális hasonlósághoz kötött. A crop, resize és intenzitásváltoztatás akkor megengedett, ha nem semmisíti meg a cél szempontjából szükséges tartalmat; a flip csak a feladat szimmetriái szerint címkeőrző; a 90 fokos forgatás a GlyphLab irányfeladatán a vertical és horizontal címkét felcseréli, a diagonal pedig más irányt jelöl. A kép, maszk és doboz minden geometriai transzformációjának ugyanazt az indexleképzést kell követnie; független véletlen transzformáció ellentmondásos tanítópárokat ad. Az augmentáció kizárólag a train pipeline-ban futtatható, a tesztfolyamat valós eloszlását nem szabad augmentálni.

22.2.10 Következő alkalmazás

A 22.3. Zajos és hiányos címke a zajos és hiányos címke kezelésére tér át. Az ott tárgyalt címkebizonytalanság éppen abból a pontból ered, ahol a transzformáció már nem tudja garantálni a cél hűségét; az itt tanult szinkron és címkeőrző eljárás a zajos címke kontrolljához is nélkülözhetetlen.

22.2.11 Felhasznált források

• [D08] PyTorch contributors. (2.14). torch.utils.data. https://docs.pytorch.org/docs/2.14/data.html.
• [S02] NIST/SEMATECH. (n.d.). e-Handbook of Statistical Methods: Confidence Limits for the Mean. https://www.itl.nist.gov/div898/handbook/eda/section3/eda352.htm.
• [D13] PyTorch contributors. (online). TorchVision models. https://docs.pytorch.org/vision/stable/models.html.