Какво се крие зад грешките в tensor shape

Познавате това усещане. Моделът се обучава, загубата намалява, метриките изглеждат нормално. Три седмици по-късно в production някой забелязва, че резултатите са постоянно грешни – и причината не може да се открие.

Виновникът обикновено е ос, която в главата ви означава едно, а кодът я третира по друг начин.

Това не е грешка при компилация. Не е и срив по време на работа. Това е по-лошо – тиха грешка в точността, която се крие във всяко предсказание.

Проблемът с наименованието

Истината е, че не можеш да провериш това, което не можеш да назовеш.

Повечето tensor frameworks не се интересуват от семантиката. Shape (32, 768, 12, 64) може да означава:

• (batch, sequence, heads, dim_per_head) в един контекст
• (batch, features, height, width) в друг
• (batch, tokens, layers, channels) в трети

Компилаторът вижда само числа. Докато размерностите се умножават правилно, операцията минава. Така семантиката се изгубва, а грешката остава.

Какво би дало по-доброто наименование

Представете си, че всяка ос носи име още при създаването си. Вместо да гадаете коя е коя, просто декларирате:

tensor: [batch=32, sequence=128, heads=12, dim_per_head=64]

Тогава компилаторът може да провери:

• Дали broadcast-ът се случва по правилните оси
• Дали намаляването на размерностите засяга точно онези, които сте искали
• Дали heads остават разделени от feature dimensions
• Дали LayerNorm нормализира по подходящите оси

Компилаторът става ваш партньор – той открива грешките преди да започнете дълго обучение.

Колко струва една тиха грешка

Такива dimension bugs струват скъпо:

В изследванията: часове на тестване, за да разберете защо резултатите не се възпроизвеждат. Може да се крие в хиперпараметрите, в seed-а или в подреждането на оси. И това се умножава по броя на опитите.

В production: модел, който е леко грешно калибриран. Постигате 94% точност вместо 96%. Грешката е малко голяма да се игнорира, но достатъчно малка да се скрие.

В екипите: когато конвенциите са неявни, те се разминават. Една част от екипа използва [batch, seq, heads, dim], друга – [batch, heads, seq, dim]. Когато кодът се обединява, грешките се разпространяват.

Как наименованието променя възможностите

Това засяга нещо по-дълбоко: наименованието определя какво можете да разберете.

Ако framework-ът не може да каже „тази ос е batch size“, компилаторът не може да я проверява. И повече от това – вие не можете да я разсъждавате точно. Семантиката се крие в коментари и документи.

Добавете имената и тогава:

• Кодът може да проверява broadcast operations
• Градиентите могат да се проверяват по-добре
• Комбинацията на layers съсредото<|eos|>