Shape suffixek — avagy nevezd el úgy a változóidat, hogy magukért beszéljenek

Ha valaha is dolgoztál neurális hálózatokkal, tudod, hogy a kód debugolása önmagában is kihívás. És akkor még nem is beszéltünk a változónevekről.

Volt már olyan pillanat, amikor az outputs változó felett töltöttél perceket, és próbáltad kitalálni, hogy batch-first vagy batch-last-e az elrendezése, tartalmazza-e a sequence dimenziót, vagy valaki átalakította-e valahol a kódban, ahol nem is számítottál rá?

Van egy jobb megoldás, és meglepően egyszerű.

Mi az a Shape Suffix?

A shape suffixek kis betűkódok, amelyeket a tensor változók nevei után teszel, hogy leírd a dimenzióit. Ahelyett, hogy outputs lenne, inkább outputs_bc-t írsz. Ahelyett, hogy activations, inkább activations_bcn.

Első ránézésre extra gépelésnek tűnhet. Hidd el nekem — az ellenkezője igaz. Ez az egyik leghasznosabb kódolási konvenció, amit gépi tanulási projektekben alkalmazhatsz.

A Dimenzió ABC

Íme a standard betűkészlet:

• b — batch dimenzió
• p — pozíció vagy szekvencia index
• n — neuron dimenzió (általában egy súlymátrix szorzás eredménye)
• c — csatorna dimenzió
• h — magasság (képtenzoroknál)
• w — szélesség (képtenzoroknál)
• d — mélység (3D adatoknál)
• k — kernel dimenzió

Tehát a logits_bc azt jelenti, hogy batch méretű logitok csatorna dimenzióval — klasszikus classification feladatoknál. A positional_embeddings_bpn pedig batch, pozíció és neuron dimenziókat tartalmaz ebben a sorrendben.

Miért éri meg ez a konvenció?

Azonnali kontextus. Amikor meglátod a probs_bc változót, azonnal tudod, hogy valószínűségeket látsz, batch és osztály szerint rendezve. Nincs találgatás, nincs dokumentáció vadászat.

Beépített hibafelismerés. Itt jön a lényeg. Ha leírod, hogy outputs_bc = torch.matmul(activations_bcn, weights_bcn), a hibás rész azonnal szembetűnik. A súlymátrixodnak weights_nc-nek kellene lennie, nem weights_bcn-nek, hogy megfelelően szorozzon az activations_bcn-nel. A nevek maguk válnak egyfajta statikus típusellenőrré a tensor alakokhoz.

Öndokumentáló kód. A kommentek elavulnak. Senki nem frissíti őket refaktoráláskor. De a embeddings_bpn mindig pontos marad, amíg tartod a konvencióhoz magad — mert a változó neve MAGA a dokumentáció.

Gördülékenyebb code review. A reviewer-ek kiszúrják a dimenzióeltéréseket a pull request-ekben anélkül, hogy futtatniuk kellene a kódot vagy végig kellene követniük a függvényhívásokat. Mindenki idejét megtakarítja, és hamarabb elkapszátok a hibákat.

Gyakorlati Minták

Összefűzések és stackek esetén: Amikor tensort kombinálsz, frissítsd a suffixet az új struktúrához. Két features_bc tensort stackelsz egy új dimenzió mentén? Most már features_bck vagy features_bkc — attól függően, melyik tengelyt választottad.

Redukciók esetén: Összeadod a pozíció dimenziót és az inputs_bp-ből inputs_b lesz. Argmax-olsz a csatornákon és a logits_bc-ből logits_b lesz. A suffix összeme

gyk a valósággal.

Komplex tensorok esetén: Több dimenziókódot is stackelhetsz: attention_bpp a pozíciópárok közötti attention score-okhoz, vagy gradients_bpn a batch, pozíció és neuron szerint rendezett gradiensékhez.

Hogyan csináld jól?

A kulcs a következetesség. Válaszd ki a konvenciót, és alkalmazd mindenhol — inputok, outputok és minden közbenső tensor. Igen, még azt az egysoros változót is, amit csak ideiglenesen hoztál létre debug célból.

A jövőbeli énod köszönetet mond majd érte. A csapattársaid is.

Ha ML alkalmazásokat fejlesztesz és tiszta, karbantartható kódot akarsz, ami skálázódik a csapatoddal, ezek a apró konvenciók hatalmas termelékenységnövekedésben gyűlnek össze. Ugyanaz az elv működik itt, mint bárhol máshol a szoftverfejlesztésben — írd úgy a kódot, hogy dokumentációnak is beillően olvasható legyen.

Próbáld ki egy hétig a következő projektedben. Azt hiszem, utána azon fogsz gondolkodni, hogy eddig hogyan írtál kódot nélküle.