Почему баги с формой тензоров остаются незамеченными

Вы запускаете обучение. Loss падает, метрики выглядят нормально. А через три недели в продакшене кто-то обнаруживает: модель систематически ошибается, и понять, почему — невозможно.

Причина чаще всего одна: ось, которая в вашей голове означала одно, в коде обрабатывалась как другое. Это не ошибка компиляции и не падение на рантайме. Это тихий баг, который встроен в каждое предсказание модели.

Проблема обозначений

Суть в том, что то, что не имеет имени, нельзя проверить.

Большинство фреймворков работают с формами тензоров как с простыми кортежами чисел. Один и тот же 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 по нужным осям
• Какие оси действительно нужно сворачивать при reduction
• Не перепутаны ли attention heads с feature dimensions
• Правильно ли работает LayerNorm

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

Сколько стоят такие баги

В исследованиях это десятки часов на проверку гипотез — а виноват был всего лишь порядок осей. В продакшене — модель с чуть-чуть заниженной точностью, которую сложно обнаружить. В командах — когда разные группы используют разные соглашения, при слиянии кодов возникают новые скрытые ошибки.

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

Когда фреймворк не умеет хранить смысл осей, он не может их проверить. А главное — вам самим сложнее рассуждать логично. Смысл остаётся в комментариях и памяти команды.

Но стоит только добавить именование, как появляется возможность:

1. Автоматически проверять, можно ли делать broadcast по конкретным осям
2. Контролировать, совпадают ли оси в forward и backward pass
3. Комбинировать разные слои, не опасаясь потерять смысл
4. Безопасно делать reshape, зная, что это не нарушит семантику

Что это значит для тех, кто строит инфраструктуру

Если вы создаёте:

• DSL для тензоров внутри команды
• Библиотеки с поддержкой автодифференциации
• Компиляторные проходы для ML
• Общие соглашения по обозначениям

— выбор способа обозначения влияет на количество bugs, которые доходят до prod.

Как начать уже сейчас

Необязательно переходить на новый язык. Достаточно:

• Явно комментировать каждую ось при создании тензора
• Писать проверки на стыках компонентов
• Использовать named tuples вместо обычных кортежей
• Договориться в команде о стандартах и проверять их на code review

Некоторые группы уже строят DSL, где именованные оси становятся частью языка. В таких случаях ошибка с осями поймётся до запуска кода.

Что в итоге

Баги, которые остаются незаметными, не столько в тензорах, сколько в разрыве между тем, что код говорит и что он в действительности означает.

Закрыть этот разрыв можно, если давать осей именам. Это не про aesthetics — это про безопасность.