Por qué tus variables de tensor necesitan un sistema de nombres mejor

Vamos a ser directos: depurar código de redes neuronales ya es bastante difícil sin tener que adivinar qué forma tiene cada variable en cada momento. Todos hemos pasado por eso: miras outputs,intentas recordar si es batch-primero o batch-último, si incluye la dimensión de secuencia, o si alguien le hizo un reshape en algún lugar que ya olvidaste revisar.

Hay una forma mejor de trabajar, y es sorprendentemente sencilla.

Qué son los Sufijos de Forma

Los sufijos de forma son códigos con letras minúsculas que se añaden a los nombres de variables tensor para describir sus dimensiones. En lugar de escribir outputs, usas outputs_bc. En lugar de activations, escribes activations_bcn.

A primera vista puede parecer más trabajo de escritura. Créeme: es justo lo contrario. Es una de las convenciones más útiles que puedes implementar en proyectos de machine learning.

El Alfabeto de las Dimensiones

Aquí tienes el estándar que funciona para las dimensiones de tensores:

• b — dimensión de batch
• p — posición o índice de secuencia
• n — dimensión de neurona (típicamente el resultado de una multiplicación por matriz de pesos)
• c — dimensión de canal
• h — altura (para tensores de imagen)
• w — anchura (para tensores de imagen)
• d — profundidad (para datos 3D)
• k — dimensión de kernel

Así que logits_bc te indica que es un batch de logits con dimensiones de canal, ideal para tareas de clasificación. Y positional_embeddings_bpn significa que tienes dimensiones de batch, posición y neurona en ese orden.

Por Qué Esta Conveniencia Te Ahorra Tiempo

Contexto instantáneo. Cuando ves probs_bc, sabes al instante que estás mirando probabilidades organizadas por batch y clase. Sin adivinar, sin buscar documentación.

Detección de errores integrada. Aquí es donde la cosa se pone interesante. Si escribes outputs_bc = torch.matmul(activations_bcn, weights_bcn), el error destaca inmediatamente. Tu matriz de pesos debería ser weights_nc para multiplicar correctamente con activations_bcn. Los propios nombres se convierten en un verificador estático de formas tensoriales.

Documentación que se actualiza sola. Los comentarios quedan obsoletos. Nadie los actualiza cuando refactoriza. Pero embeddings_bpn se mantiene preciso mientras mantengas la convención, porque el nombre de la variable ES la documentación.

Reviews de código más fluidos. Los revisores pueden detectar desajustes de dimensiones en los pull requests sin ejecutar código ni rastrear llamadas de función. Esto le ahorra tiempo a todo el equipo y detecta bugs antes.

Patrones que Conviene Adoptar

Para concatenaciones y stacks: Cuando combinas tensores, actualiza el sufijo para reflejar la nueva estructura. Apilas dos tensores features_bc a lo largo de una dimensión nueva? Ahora es features_bck o features_bkc dependiendo del eje que hayas elegido.

Para reducciones: Sumas sobre la dimensión de posición y tu inputs_bp se convierte en inputs_b. Haces argmax entre canales y logits_bc se convierte en logits_b. El sufijo se encoge para coincidir con la realidad.

Para tensores complejos: Puedes combinar múltiples códigos de dimensión: attention_bpp para puntuaciones de atención entre pares de posiciones, o gradients_bpn para gradientes organizados por batch, posición y neurona.

Cómo Hacer que Funcione

La clave está en la consistencia. Elige la convención, aplícala en todas partes: entradas, salidas y cada tensor intermedio. Sí, incluyendo ese nombre de una sola línea que creaste solo para hacer debugging.

Tu yo del futuro te lo agradecerá. Y también tus compañeros de equipo.

Si estás construyendo aplicaciones de ML y quieres código limpio y mantenible que escale con tu equipo, estas pequeñas convenciones se multiplican en ganancias enormes de productividad. Es el mismo principio detrás de cualquier buen nombre en desarrollo de software: haz que el código se lea como documentación.

Pruébalo una semana en tu próximo proyecto. Creo que te preguntarás cómo programabas sin esto.