“Sacan la misma nota, así que me da igual cuál coger”
Cuando comparas herramientas de IA y las puntuaciones van pegadas, da la sensación de que cualquiera vale.
Y es un atajo tentador. La tabla está ahí, los números casi se tocan, eliges el más barato y a otra cosa.
Pero cuando las pones a trabajar de verdad, dos modelos “empatados” fallan en sitios distintos. Uno resume de maravilla y patina en cuanto le pides comparar opciones. A Hex-ko también le pasó.
En el artículo anterior de la serie vimos que la IA, por dentro, sí maneja la estructura de la frase. Hoy vamos al paso siguiente: qué decisión de diseño hace que esa comprensión sea más o menos profunda.
Seguimos con el mismo trabajo, Physics of Language Models (estudio). Y la pregunta de fondo es muy práctica: cómo cambia el diseño la forma en que el modelo se equivoca en tu día a día.
Solo por cómo guarda “dónde va cada palabra” cambia lo que entiende
El equipo comparó varios diseños con datos de frases anidadas —frases metidas dentro de otras frases—. Y lo primero que separó a unos de otros fue algo que suena menor: cómo el modelo guarda la posición de cada palabra.
Eso tiene nombre. La codificación de posición (position embedding) es el mecanismo que le dice al modelo en qué lugar de la frase está cada palabra. A grandes rasgos, hay dos formas: la posición absoluta (“esta palabra es la número 7”) y la posición relativa (“esta palabra está dos sitios después de aquella”).
¿Y cuál ganó? El resultado fue claro: la posición relativa —del estilo de RoPE— le sacó ventaja a la absoluta de forma consistente en estas pruebas.
El motivo es bastante intuitivo. Entender una frase depende menos del “número de orden” de cada palabra y más de “qué se conecta con qué”.
Para ti, la lectura es directa: en una ficha técnica importa menos el número exacto de cada métrica y más saber qué enfoque usa el modelo por dentro.
A veces el diseño “más limitado” entiende más
Lo siguiente es más contraintuitivo. El estudio enfrentó dos familias de modelos: una tipo GPT, que lee de izquierda a derecha, y otra tipo BERT, que puede mirar el texto por delante y por detrás a la vez.
A primera vista, el que ve los dos lados parece que lo tiene más fácil. Pero el resultado no fue tan simple.
En la comprensión de estructuras profundamente anidadas, hubo condiciones en las que el diseño tipo GPT —el más restringido— entendía mejor la estructura. Justamente porque, al tener menos margen, no le queda otra que seguir el hilo para responder.
Lo importante aquí no es el detalle de ingeniería. Es la idea de fondo: el diseño que parece más completo no siempre rinde más. Según para qué lo uses, gana uno u otro.
En la práctica, mira cómo falla, no la media
Si bajamos esto a la decisión de compra, el promedio no basta. Lo que de verdad pesa es por dónde se rompe cada modelo: el tipo de .
Dos modelos con un 90% no son iguales. Uno flojea en preguntas de comparación. Otro se cae en textos largos con varias condiciones del tipo “si pasa esto, entonces aquello”. El riesgo para tu trabajo cambia mucho según cuál sea tu tarea principal.
En el equipo de Hex-ko esto se ve a diario: el modelo que mejor quedaba en la demo es justo el que luego tropezaba en el caso que de verdad importaba.
Por eso conviene mirar primero si el patrón de fallos de un modelo encaja —o choca— con lo que tú haces cada día.
Conclusión: elige la IA que menos te falla en tu terreno, no la de nota más alta
Si te quedas con una sola idea, que sea esta: al elegir una IA, la nota global importa menos de lo que parece. Lo que decide es dónde se rompe en los momentos que a ti te importan, y si vas a poder darte cuenta cuando lo haga.
No buscas “la IA que parece más lista”. Buscas la que menos la lía en tu forma de trabajar.
Para eso, lo práctico es fijar de tres a cinco tareas reales de tu negocio y pasárselas a cada modelo candidato en las mismas condiciones, varias veces. Pero hazlo siempre con tus tareas, no con las del catálogo del proveedor: así comparas comportamiento, no folletos.
Y cuando un proveedor te lo venda, usa el mismo cuestionario para todos: en qué condiciones flojea el modelo, cómo de cerca está su prueba de tu caso real y hasta dónde llega la revisión humana. Esas tres respuestas te dejan comparar por riesgo de uso, no por lo bonita que sea la presentación de ventas.
Fuentes
- Zeyuan Allen-Zhu, Yuanzhi Li, “Physics of Language Models: Part 1, Learning Hierarchical Language Structures”, ICML 2023, arXiv:2305.13673
- Physics of Language Models (sitio de la serie), physics.allen-zhu.com
