1
00:00:09,680 --> 00:00:17,950
Buenas, esto es BIMPRAXIS, el podcast donde el BIM se encuentra con la inteligencia artificial.

2
00:00:20,330 --> 00:00:27,230
Exploramos la ciencia, la tecnología y el futuro desde el enfoque de la arquitectura, ingeniería y construcción.

3
00:00:28,930 --> 00:00:29,650
¡Empezamos!

4
00:00:37,160 --> 00:00:40,200
Hola y bienvenidos a una nueva entrega.

5
00:00:40,200 --> 00:00:45,680
Hoy llegamos al noveno análisis de nuestra serie especial de BIMPRAXIS.

6
00:00:45,680 --> 00:00:48,360
Los papers que cambiaron la historia de la IA.

7
00:00:48,780 --> 00:00:56,460
Exacto. Y hoy nos metemos de lleno en un campo de batalla que es, bueno, constante en este mundo, la lucha por la eficiencia.

8
00:00:57,240 --> 00:01:03,380
Todos queremos modelos de IA que sean como atletas de élite, potentes, precisos, pero a la vez…

9
00:01:03,380 --> 00:01:06,740
Ágiles, rápidos y que no se agoten a la primera de cambio.

10
00:01:07,220 --> 00:01:14,860
Ese es el santo grial, sí. Pero la realidad en ingeniería, y sobre todo en MLOPS, es que casi siempre te encuentras con un compromiso.

11
00:01:14,860 --> 00:01:15,660
El famoso.

12
00:01:15,680 --> 00:01:16,380
El famoso trade-off.

13
00:01:16,560 --> 00:01:21,020
El trade-off de rendimiento, sí. Para ganar precisión tienes que pagar un precio.

14
00:01:21,440 --> 00:01:26,700
Y ese precio es coste computacional, velocidad, tamaño… Un precio que a veces es altísimo.

15
00:01:27,140 --> 00:01:31,580
Pero la pregunta que flota en el aire, y que es el corazón del paper de hoy, es…

16
00:01:31,580 --> 00:01:35,340
¿Y si esa elección no fuera necesaria? ¿Y si pudieras tenerlo todo?

17
00:01:35,600 --> 00:01:43,680
Imagina, un único modelo de IA que pudiera como cambiar de marcha, que adaptara su complejidad y su coste sobre la marcha.

18
00:01:43,900 --> 00:01:45,400
Sin tener que volver al taller.

19
00:01:45,680 --> 00:01:46,620
Sin reentrenarlo.

20
00:01:46,980 --> 00:01:50,320
Una especie de navaja suiza para las representaciones de datos.

21
00:01:50,620 --> 00:01:57,420
Justo. Y es una idea que suena casi a ciencia ficción, porque va en contra de cómo se han construido los modelos durante años.

22
00:01:57,920 --> 00:01:59,420
La rigidez es la norma.

23
00:01:59,780 --> 00:02:05,260
Totalmente. Pues esa es precisamente la norma que viene a romper el paper que tenemos sobre la mesa.

24
00:02:06,020 --> 00:02:11,100
Matryoshka Representation Learning. Publicado por primera vez en mayo de 2022.

25
00:02:11,660 --> 00:02:15,480
Y el propio nombre, Matryoshka, como las muñecas rusas, ya nos da una pista.

26
00:02:15,680 --> 00:02:22,420
Una pista muy, muy clara de por dónde va la solución. Es una idea tan elegante como intuitiva.

27
00:02:22,420 --> 00:02:27,620
Es una de esas ideas que, cuando la lees, piensas, ¿cómo no se le había ocurrido a nadie antes?

28
00:02:28,380 --> 00:02:33,560
Ataca un problema que es un verdadero quebradero de cabeza en el despliegue de sistemas de IA a gran escala.

29
00:02:33,640 --> 00:02:35,840
Y lo hace desde la raíz misma del modelo.

30
00:02:36,600 --> 00:02:39,540
Exacto. De acuerdo, pues vamos a meternos en faena.

31
00:02:40,360 --> 00:02:44,920
A ver, para entender la genialidad de la propuesta, primero tenemos que hablar de la pieza central.

32
00:02:44,920 --> 00:02:50,640
Las representaciones aprendidas. O los embeddings, como se les conoce en la jerga.

33
00:02:50,700 --> 00:02:56,060
Eso es. A mí me gusta pensar en ellos como la ficha técnica que una IA crea de algo.

34
00:02:56,580 --> 00:03:01,040
Si le muestras una foto de un gato, no ve un gato. Ve una lista larguísima de números.

35
00:03:01,240 --> 00:03:05,400
Y esa lista de números, para ella, codifica la esencia del hogatuno en esa imagen.

36
00:03:05,620 --> 00:03:10,980
Es una analogía perfecta. Es un resumen numérico que captura las características más importantes.

37
00:03:10,980 --> 00:03:14,620
Y el dilema fundamental, el pecado original de muchos sistemas,

38
00:03:14,920 --> 00:03:15,900
empieza justo ahí.

39
00:03:16,140 --> 00:03:20,300
En el momento de decidir cómo de larga y detallada va a ser esa ficha técnica.

40
00:03:20,520 --> 00:03:24,960
Exacto. Tienes que elegir una dimensión. Pongamos 1024 números.

41
00:03:25,120 --> 00:03:29,620
Con eso, obtienes una ficha súper detallada. Muy rica en matices.

42
00:03:30,180 --> 00:03:32,460
Perfecta para tareas de análisis muy complejas.

43
00:03:32,680 --> 00:03:33,180
Pero claro.

44
00:03:33,460 --> 00:03:40,640
Mover, almacenar y comparar millones de esas fichas de 1024 números es increíblemente lento.

45
00:03:40,640 --> 00:03:41,960
Y caro.

46
00:03:42,260 --> 00:03:44,020
Y la alternativa es decirte al otro extremo.

47
00:03:44,920 --> 00:03:51,240
Es una ficha muy corta, de 128 números. Rapidísima de procesar. Ideal para una búsqueda en un móvil.

48
00:03:51,420 --> 00:03:57,360
El problema es que en esa compresión tan agresiva pierdes información. Es como intentar describir el Quijote.

49
00:03:57,920 --> 00:04:00,620
Puedes hacerlo en un tuit de 280 caracteres.

50
00:04:00,760 --> 00:04:02,460
O en un ensaño de 50 páginas.

51
00:04:02,520 --> 00:04:07,660
Pues eso. El tuit es rápido, pero te dejas el 99% de la obra por el camino.

52
00:04:07,880 --> 00:04:09,300
Es una gran analogía.

53
00:04:10,040 --> 00:04:13,760
Me recuerda cuando intentas explicar una película compleja a un amigo en 30 segundos.

54
00:04:14,040 --> 00:04:14,900
Te quedas con un amigo en 30 segundos.

55
00:04:14,920 --> 00:04:18,140
Con... va de un tipo que... y pierdes todo el matiz.

56
00:04:18,320 --> 00:04:19,360
Pues aquí pasa lo mismo.

57
00:04:19,540 --> 00:04:22,840
Pero con millones de euros en costes de computación en juego.

58
00:04:23,300 --> 00:04:30,080
Y lo peor de todo es que, una vez que has entrenado a tu modelo para que escriba ensayos de 50 páginas...

59
00:04:30,080 --> 00:04:31,900
No puedes pedirle que te haga un tuit.

60
00:04:32,100 --> 00:04:34,880
Estás atado a ese formato. No hay marcha atrás.

61
00:04:35,000 --> 00:04:37,380
Y esa rigidez es una pesadilla a nivel operativo.

62
00:04:37,880 --> 00:04:43,480
Obliga a las grandes empresas a entrenar y mantener, bueno, ecosistemas enteros de modelos.

63
00:04:43,480 --> 00:04:43,840
Claro.

64
00:04:44,920 --> 00:04:46,500
En la plataforma de comercio electrónico.

65
00:04:46,720 --> 00:04:50,920
Necesitan una versión ligera del modelo para las búsquedas visuales en la app, que tienen que ser instantáneas.

66
00:04:51,600 --> 00:04:51,900
Ajá.

67
00:04:52,060 --> 00:04:57,640
Pero también necesitan una versión pesada, ultra precisa, en sus servidores para analizar patrones de compra.

68
00:04:57,820 --> 00:05:01,920
Y son dos modelos distintos, con dos pipelines de datos, dos equipos de mantenimiento...

69
00:05:02,500 --> 00:05:06,020
El coste se dispara. Y no es solo un problema de coste económico.

70
00:05:06,460 --> 00:05:09,920
El propio paper señala que es un sistema estadísticamente ineficiente.

71
00:05:10,080 --> 00:05:11,360
¿A qué se refieren con eso?

72
00:05:11,360 --> 00:05:14,680
Pues que para una tarea simple, como distinguir un perro de un gato,

73
00:05:14,920 --> 00:05:18,320
esa ficha de 1024 números es excesiva, es un derroche.

74
00:05:18,320 --> 00:05:23,840
Y para una tarea muy compleja, como identificar una subespecie concreta de pájaro,

75
00:05:24,300 --> 00:05:26,920
quizás la ficha de 128 se queda corta.

76
00:05:27,120 --> 00:05:31,740
Y pierdes la precisión que necesitabas. Al final, es el clásico un tamaño para todo.

77
00:05:31,880 --> 00:05:35,920
Que en la práctica significa que no es el tamaño perfecto para casi nada.

78
00:05:36,220 --> 00:05:39,520
Siempre estás o malgastando recursos o sacrificando rendimiento.

79
00:05:39,920 --> 00:05:44,180
Vale, el problema está clarísimo. O rápido y simple, o listo y lento.

80
00:05:44,180 --> 00:05:47,640
Y estás atado a tu elección inicial. Parece un callejón sin salida.

81
00:05:48,060 --> 00:05:50,520
¿Cómo demonios lo solucionan los autores? ¿Cuál es el truco?

82
00:05:50,700 --> 00:05:54,520
Pues el truco es dejar de pensar en la ficha técnica como un bloque monolítico.

83
00:05:54,640 --> 00:05:59,180
Y empezar a pensar en ella como... como una muñeca matriosca.

84
00:06:00,320 --> 00:06:06,240
La idea es brillante. Entrenas un único modelo para que genere la ficha más grande y detallada posible.

85
00:06:06,620 --> 00:06:08,740
La de 1024. La más completa.

86
00:06:09,060 --> 00:06:10,720
Pero lo haces de una forma muy especial.

87
00:06:10,720 --> 00:06:13,700
De modo que dentro de esa gran representación,

88
00:06:14,180 --> 00:06:16,860
anidadas, ya existen versiones más pequeñas.

89
00:06:17,220 --> 00:06:18,720
Y totalmente funcionales.

90
00:06:18,900 --> 00:06:22,080
Como las muñecas rusas. Abres la grande y dentro hay otra.

91
00:06:22,320 --> 00:06:24,600
Un poco más pequeña, pero perfectamente formada.

92
00:06:24,840 --> 00:06:26,640
La abres y hay otra más.

93
00:06:27,040 --> 00:06:30,700
Cada una es una versión completa de la muñeca, pero a una escala diferente.

94
00:06:31,100 --> 00:06:35,980
Llevado a la práctica, esto significa que si una aplicación necesita velocidad máxima,

95
00:06:36,200 --> 00:06:40,640
en lugar de usar los 1024 números, simplemente coge los primeros 128.

96
00:06:40,640 --> 00:06:41,900
Y ignora el resto.

97
00:06:42,300 --> 00:06:43,640
Y lo revolucionario es que...

98
00:06:44,180 --> 00:06:48,900
Estos 128 números no son un trozo incompleto y sinsentido de la ficha grande.

99
00:06:49,640 --> 00:06:53,900
Son, por sí mismos, una ficha técnica coherente y de alta calidad.

100
00:06:54,400 --> 00:06:56,060
Sólo que con menos resolución.

101
00:06:56,060 --> 00:06:56,560
Exacto.

102
00:06:56,800 --> 00:06:59,680
Espera, eso es lo que me parece casi mágico.

103
00:07:00,240 --> 00:07:05,300
Intuitivamente, si tienes una lista de datos que describe algo y la cortas,

104
00:07:05,660 --> 00:07:07,740
esperarías que el resultado fuera basura.

105
00:07:07,800 --> 00:07:08,820
¿Información corrupta?

106
00:07:08,960 --> 00:07:11,180
Claro, como si cortas una foto por la mitad.

107
00:07:11,780 --> 00:07:14,140
¿Cómo consiguen que la primera parte del vector siga la misma?

108
00:07:14,180 --> 00:07:15,800
Está teniendo sentido por sí sola.

109
00:07:15,980 --> 00:07:17,200
Ahí está la clave del asunto.

110
00:07:17,720 --> 00:07:20,800
Y la palabra que usan es aprendizaje de grano grueso afino.

111
00:07:21,240 --> 00:07:22,060
Course to find.

112
00:07:22,260 --> 00:07:22,640
De acuerdo.

113
00:07:23,380 --> 00:07:27,820
La genialidad está en modificar ligeramente el objetivo del entrenamiento.

114
00:07:28,400 --> 00:07:30,640
Normalmente, al entrenar, le dices al modelo.

115
00:07:31,360 --> 00:07:36,700
Tu objetivo es que la ficha completa de 1024 números sea lo más precisa posible.

116
00:07:37,460 --> 00:07:37,740
Ajá.

117
00:07:38,440 --> 00:07:43,300
Con Matriuska Representation Learning, o MRL, el objetivo cambia.

118
00:07:43,300 --> 00:07:43,340
¿Qué pasa?

119
00:07:43,340 --> 00:07:43,360
¿Qué pasa?

120
00:07:43,360 --> 00:07:43,380
¿Qué pasa?

121
00:07:43,380 --> 00:07:43,480
¿Qué pasa?

122
00:07:43,480 --> 00:07:43,500
¿Qué pasa?

123
00:07:43,500 --> 00:07:43,520
¿Qué pasa?

124
00:07:43,520 --> 00:07:43,540
¿Qué pasa?

125
00:07:43,540 --> 00:07:43,560
¿Qué pasa?

126
00:07:43,560 --> 00:07:43,600
¿Qué pasa?

127
00:07:43,600 --> 00:07:43,640
¿Qué pasa?

128
00:07:43,640 --> 00:07:43,700
¿Qué pasa?

129
00:07:43,700 --> 00:07:43,720
¿Qué pasa?

130
00:07:43,720 --> 00:07:43,760
¿Qué pasa?

131
00:07:43,760 --> 00:07:43,780
¿Qué pasa?

132
00:07:43,780 --> 00:07:43,820
¿Qué pasa?

133
00:07:43,820 --> 00:07:43,840
¿Qué pasa?

134
00:07:43,840 --> 00:07:43,860
¿Qué pasa?

135
00:07:43,860 --> 00:07:44,580
Ahora le dices.

136
00:07:45,060 --> 00:07:50,880
Tu objetivo es que la ficha completa sea precisa, pero también que los primeros 512 números

137
00:07:50,880 --> 00:07:52,240
sean una versión precisa.

138
00:07:52,620 --> 00:07:55,660
Y que los primeros 256 también lo sean.

139
00:07:56,100 --> 00:07:57,240
Y los primeros 128.

140
00:07:57,900 --> 00:07:58,980
Y así sucesivamente.

141
00:07:59,660 --> 00:08:03,540
O sea que lo fuerzas a organizar la información de forma jerárquica.

142
00:08:04,080 --> 00:08:08,760
Es como si le dijeras, en los primeros números quiero el boceto general, la información

143
00:08:08,760 --> 00:08:09,580
más importante.

144
00:08:10,080 --> 00:08:12,320
Y a medida que añades más números…

145
00:08:12,320 --> 00:08:13,680
Vas añadiendo detalles.

146
00:08:13,680 --> 00:08:16,240
… texturas y matices cada vez más finos.

147
00:08:16,360 --> 00:08:17,200
¿Has dado en Eikau?

148
00:08:17,660 --> 00:08:20,640
Es un diseño de información increíblemente inteligente.

149
00:08:21,200 --> 00:08:24,660
La información más crítica y general se empaqueta al principio del vector.

150
00:08:25,220 --> 00:08:27,380
Y la más específica y detallada al final.

151
00:08:27,840 --> 00:08:32,660
Y lo más importante, un detalle crucial que mencionan y que es la clave de su viabilidad.

152
00:08:33,280 --> 00:08:38,460
Esta flexibilidad no añade ningún coste extra en el momento de usar el modelo, en

153
00:08:38,460 --> 00:08:40,440
lo que se conoce como inferencia.

154
00:08:40,800 --> 00:08:41,360
Exacto.

155
00:08:41,360 --> 00:08:41,640
Exacto.

156
00:08:41,900 --> 00:08:42,020
Exacto.

157
00:08:42,020 --> 00:08:42,060
Exacto.

158
00:08:42,060 --> 00:08:42,080
Exacto.

159
00:08:42,080 --> 00:08:42,100
Exacto.

160
00:08:42,100 --> 00:08:42,120
Exacto.

161
00:08:42,120 --> 00:08:42,140
Exacto.

162
00:08:42,140 --> 00:08:42,180
Exacto.

163
00:08:42,180 --> 00:08:42,240
Exacto.

164
00:08:42,240 --> 00:08:42,300
Exacto.

165
00:08:42,300 --> 00:08:42,360
Exacto.

166
00:08:42,360 --> 00:08:42,420
Exacto.

167
00:08:42,420 --> 00:08:42,460
Exacto.

168
00:08:42,460 --> 00:08:42,520
Exacto.

169
00:08:42,520 --> 00:08:42,540
Exacto.

170
00:08:42,540 --> 00:08:42,580
Exacto.

171
00:08:42,580 --> 00:08:42,600
Exacto.

172
00:08:42,600 --> 00:08:44,520
Exacto.

173
00:09:11,120 --> 00:09:12,040
Exacto.

174
00:09:12,040 --> 00:09:12,400
Exacto.

175
00:09:12,400 --> 00:09:12,580
Exacto.

176
00:09:12,580 --> 00:09:19,500
escala. Construir modelos gigantescos. Y luego, comprime, comprime, comprime. Intentar hacerlos

177
00:09:19,500 --> 00:09:24,740
más pequeños con técnicas posteriores. Este paper demuestra que la eficiencia no tiene por

178
00:09:24,740 --> 00:09:30,560
qué ser un paso posterior, una ocurrencia tardía. Puede ser una propiedad intrínseca del modelo.

179
00:09:30,900 --> 00:09:35,440
Horneada en su ADN desde el principio. Y es interesante ponerlo en contexto con otras

180
00:09:35,440 --> 00:09:41,400
técnicas. Antes de MPRL, ¿qué se hacía para intentar solucionar este problema? Había

181
00:09:41,400 --> 00:09:47,240
principalmente dos enfoques. Uno es la poda o pruning, que es como coger el modelo ya entrenado

182
00:09:47,240 --> 00:09:51,700
y literalmente ir cortando las conexiones neuronales que parecen menos importantes.

183
00:09:52,100 --> 00:09:57,220
Como un jardinero que poda un arbusto. Justo. El otro es la cuantificación,

184
00:09:57,800 --> 00:10:02,500
que consiste en coger los números de la ficha técnica y representarlos con menos precisión,

185
00:10:03,020 --> 00:10:07,720
usando enteros en lugar de decimales largos, por ejemplo. Pero ambos métodos suenan

186
00:10:07,720 --> 00:10:11,380
destructivos. Una vez que podas algo,

187
00:10:11,400 --> 00:10:17,520
no lo puedes recuperar. Y si reduces la precisión, pierdes información para siempre. Ese es el punto.

188
00:10:18,360 --> 00:10:23,420
Son técnicas que se aplican a posteriori y que implican una pérdida de información irreversible.

189
00:10:24,200 --> 00:10:30,540
MRL es fundamentalmente distinto. No destruye nada. Exacto. Te da acceso a la representación

190
00:10:30,540 --> 00:10:35,540
de máxima fidelidad si la necesitas, pero también te ofrece atajos eficientes que ya

191
00:10:35,540 --> 00:10:40,780
estaban previstos en el diseño original. Es una solución mucho más elegante. Y flexible.

192
00:10:41,400 --> 00:10:47,320
La verdad es que la idea es brillante. Pero las ideas hay que demostrarlas. ¿Qué tal funcionan

193
00:10:47,320 --> 00:10:52,000
estas muñecas en el mundo real? ¿Los resultados que presentan están a la altura?

194
00:10:52,380 --> 00:10:58,020
Están más que a la altura. Son espectaculares. Y los autores se cuidan mucho de probarlo en

195
00:10:58,020 --> 00:11:00,900
múltiples escenarios para demostrar que no es un golpe de suerte.

196
00:11:01,520 --> 00:11:07,060
A ver, vamos a ver esos números. En el resumen hablan de una reducción de tamaño de hasta 14

197
00:11:07,060 --> 00:11:11,180
veces en los embeddings. En clasificación, en la famosa base de datos ImageNet,

198
00:11:11,400 --> 00:11:18,000
1K. Y manteniendo el mismo nivel de precisión. 14 veces. Pensemos lo que eso significa. Es la

199
00:11:18,000 --> 00:11:23,660
diferencia entre un archivo que ocupa 140 megas y uno que ocupa 10, para un móvil con almacenamiento

200
00:11:23,660 --> 00:11:29,120
limitado. O para transmitir datos por una red con poco ancho de banda. Esa diferencia es abismal.

201
00:11:29,740 --> 00:11:34,760
Abre la puerta a tener IA mucho más potente en dispositivos de borde, los Edge Devices. Claro,

202
00:11:35,260 --> 00:11:40,980
como sensores, cámaras de seguridad inteligentes o incluso wearables. Eso es. Y no solo más pequeños,

203
00:11:41,400 --> 00:11:47,420
también más rápidos. Mencionan aceleraciones de hasta 14 veces en tareas de búsqueda a gran escala.

204
00:11:47,740 --> 00:11:52,860
Que si tienes una base de datos con millones de imágenes. Encontrar la que más se parece a la

205
00:11:52,860 --> 00:11:59,160
tuya podría pasar de tardar 14 segundos a tardar solo uno. Que, a efectos prácticos para quien lo

206
00:11:59,160 --> 00:12:04,500
usa, es la diferencia entre una experiencia frustrante y una que parece mágica. Casi

207
00:12:04,500 --> 00:12:10,040
instantánea. Piensa en las aplicaciones de busca por imagen en el comercio electrónico. Una

208
00:12:10,040 --> 00:12:11,380
velocidad así cambia por cada vez más. Y no solo en el comercio electrónico, sino en el comercio

209
00:12:11,400 --> 00:12:17,000
completo la experiencia de compra. Y aquí viene algo que me sorprendió. No solo se trata de ser

210
00:12:17,000 --> 00:12:23,980
más eficiente. El paper afirma que MRL puede incluso mejorar la precisión en ciertas tareas. Citan una

211
00:12:23,980 --> 00:12:29,600
mejora de hasta un 2% en la clasificación Few Shot de cola larga. Esto suena muy técnico. ¿Qué

212
00:12:29,600 --> 00:12:34,680
significa exactamente? Es uno de los resultados más interesantes y, como dices, contraintuitivos.

213
00:12:35,280 --> 00:12:40,140
La clasificación Few Shot de cola larga es básicamente el reto de identificar categorías

214
00:12:41,400 --> 00:12:45,860
muy pocos ejemplos. Entiendo. Piensa en un sistema que tiene que identificar miles de

215
00:12:45,860 --> 00:12:50,140
especies de animales. Pero para una especie de mariposa muy rara, solo tiene dos fotos.

216
00:12:50,320 --> 00:12:56,080
Un problema increíblemente difícil y muy común en el mundo real. Exacto. La hipótesis de por qué

217
00:12:56,080 --> 00:13:01,620
MRL ayuda aquí es fascinante. Parece que las representaciones más pequeñas, las muñecas

218
00:13:01,620 --> 00:13:05,840
interiores, al ser forzadas a resumir la información, capturan las características

219
00:13:05,840 --> 00:13:11,300
más generales, robustas y abstractas. El concepto de mariposa, por así decirlo. Y cuando

220
00:13:11,400 --> 00:13:15,420
tienes muy pocos ejemplos, apoyarte en esas características generales es más efectivo.

221
00:13:15,560 --> 00:13:20,860
Que intentar aprender de los detalles súper específicos que podrían estar en la representación

222
00:13:20,860 --> 00:13:27,580
más grande. Justo. Es un doble tanto. No solo eres más eficiente, sino que mejoras en los casos

223
00:13:27,580 --> 00:13:33,480
más difíciles. Y para rematar, subrayan que estas representaciones son igual de robustas

224
00:13:33,480 --> 00:13:39,220
que las originales. No se pierde fiabilidad. Fundamental. Pero esto es un truco que solo

225
00:13:39,220 --> 00:13:41,060
funciona con imágenes. Para nada.

226
00:13:41,400 --> 00:13:45,980
Y esa es otra de las grandes fortalezas del paper. Demuestran la versatilidad de la idea

227
00:13:45,980 --> 00:13:49,960
aplicándola a un abanico enorme de arquitecturas y modalidades de datos.

228
00:13:50,140 --> 00:13:50,460
Vale.

229
00:13:51,000 --> 00:13:55,640
Lo validan en visión, con modelos clásicos como ResNet y más modernos como los Vision

230
00:13:55,640 --> 00:14:00,560
Transformers, los BIT. Lo prueban en lenguaje, con el archiconocido modelo BERT.

231
00:14:00,940 --> 00:14:02,460
E incluso van un paso más allá.

232
00:14:02,460 --> 00:14:07,440
Y lo aplican en modelos multimodales, que entienden a la vez imágenes y texto. Como

233
00:14:07,440 --> 00:14:07,760
Align.

234
00:14:08,040 --> 00:14:11,260
Y todo esto no en datasets de juguete, sino en...

235
00:14:11,400 --> 00:14:17,080
En conjuntos de datos a escala web, como ImageNet o JFT, que tienen millones y millones

236
00:14:17,080 --> 00:14:17,760
de ejemplos.

237
00:14:18,040 --> 00:14:22,660
Correcto. Esto es una señal muy clara para la comunidad científica y para la industria.

238
00:14:22,740 --> 00:14:24,040
El mensaje es...

239
00:14:24,040 --> 00:14:29,340
Esto no es un experimento de laboratorio. Es una técnica robusta, validada a gran escala

240
00:14:29,340 --> 00:14:31,720
y lista para ser implementada en producción.

241
00:14:32,180 --> 00:14:37,220
Vale. Llegados a este punto, está claro que la idea es potente. Pero toda solución

242
00:14:37,220 --> 00:14:41,220
suele tener sus contrapartidas. ¿Hay alguna limitación? ¿Es MRT?

243
00:14:41,400 --> 00:14:43,840
¿RL la solución perfecta para todo?

244
00:14:43,940 --> 00:14:49,160
Es una pregunta muy pertinente. Los propios autores son honestos al respecto. La técnica

245
00:14:49,160 --> 00:14:50,220
no es perfecta.

246
00:14:50,240 --> 00:14:50,560
Ajá.

247
00:14:50,860 --> 00:14:55,400
Reconocen que para las representaciones más pequeñas, las muñecas más internas, sí

248
00:14:55,400 --> 00:14:58,320
que existe una pequeña pero medible pérdida de precisión.

249
00:14:58,500 --> 00:14:59,400
¿Comparado con qué?

250
00:14:59,400 --> 00:15:03,520
Si las comparas con un modelo que hubiera sido entrenado específicamente para esta

251
00:15:03,520 --> 00:15:05,340
dimensión tan pequeña desde el principio.

252
00:15:05,640 --> 00:15:11,400
O sea, que una matrioska de 128 dimensiones es muy buena, pero un modelo específico,

253
00:15:11,400 --> 00:15:17,660
especializado, entrenado, solo para 128 dimensiones, podría ser ligeramente mejor.

254
00:15:17,900 --> 00:15:23,600
Podría serlo. El truco, y el motivo por el que MRL es tan valioso, es que esa pérdida

255
00:15:23,600 --> 00:15:24,920
de rendimiento es mínima.

256
00:15:25,220 --> 00:15:26,980
A menudo insignificante.

257
00:15:27,040 --> 00:15:31,020
Mientras que el beneficio que obtienes en flexibilidad y en no tener que entrenar 10

258
00:15:31,020 --> 00:15:36,460
modelos distintos es absolutamente gigantesco. El balance es abrumadoramente positivo.

259
00:15:36,460 --> 00:15:41,220
Entonces, si tuviéramos que resumir la gran aportación, la palabra clave…

260
00:15:41,400 --> 00:15:44,160
La palabra clave que se me viene a la mente es adaptabilidad.

261
00:15:44,160 --> 00:15:44,660
Sí.

262
00:15:44,660 --> 00:15:51,120
Es un cambio de paradigma. Pasamos de la filosofía rígida de un tamaño para todos a una mucho

263
00:15:51,120 --> 00:15:54,520
más inteligente, de un tamaño para cada necesidad.

264
00:15:54,520 --> 00:16:00,580
Y todo ello dentro de un único modelo entrenado una sola vez. Es la síntesis perfecta. MRL

265
00:16:00,580 --> 00:16:04,700
integra la eficiencia y la flexibilidad en el núcleo mismo del aprendizaje.

266
00:16:05,080 --> 00:16:05,960
No es un parche.

267
00:16:06,080 --> 00:16:11,020
No es un parche, no es una compresión posterior. Es una propiedad fundamental de la representación.

268
00:16:11,400 --> 00:16:16,920
Desde su concepción, es como diseñar un motor que, por su propia naturaleza, puede funcionar en

269
00:16:16,920 --> 00:16:18,880
modo eco, normal o sport.

270
00:16:19,120 --> 00:16:21,520
En lugar de construir tres motores distintos.

271
00:16:21,720 --> 00:16:27,320
Exacto. Una idea que parece abrir un campo de posibilidades enorme. Y esto me lleva a la

272
00:16:27,320 --> 00:16:32,340
pregunta que planteabas al principio. Si hemos conseguido hornear la eficiencia computacional

273
00:16:32,340 --> 00:16:37,400
directamente en las representaciones, ¿qué otras capacidades podríamos integrar de la misma manera?

274
00:16:37,580 --> 00:16:41,280
Esa es la pregunta del millón. Y la que hace que este paper sea

275
00:16:41,400 --> 00:16:47,600
tan inspirador. Podríamos diseñar representaciones que fueran inherentemente más justas, para mitigar

276
00:16:47,600 --> 00:16:48,160
sesgos.

277
00:16:48,280 --> 00:16:49,200
O más interpretables.

278
00:16:49,300 --> 00:16:54,320
O más interpretables, para que podamos entender mejor por qué toman una decisión. Quizás

279
00:16:54,320 --> 00:17:00,140
representaciones que tuvieran capas de privacidad, donde la parte más externa fuera anónima.

280
00:17:00,440 --> 00:17:05,680
Y solo ciertas aplicaciones pudieran acceder a las capas internas más detalladas.

281
00:17:05,680 --> 00:17:10,940
Abre una nueva forma de pensar sobre qué propiedades deseables podemos construir en

282
00:17:11,400 --> 00:17:12,400
las representaciones de la IA.

283
00:17:12,400 --> 00:17:22,160
Una perspectiva fascinante. Sin duda, Matryoshka Representation Learning es un ejemplo perfecto de una idea elegante, inspirada en un objeto casi infantil.

284
00:17:22,260 --> 00:17:22,840
Totalmente.

285
00:17:23,100 --> 00:17:27,280
Que resulta ser profundamente práctica y con un potencial transformador enorme.

286
00:17:27,480 --> 00:17:30,180
Es la belleza de la investigación en su máxima expresión.

287
00:17:30,320 --> 00:17:41,280
Ha sido un análisis fascinante. Y mañana tenemos otro paper que no se queda atrás. Vamos a explorar una idea que redefinió por completo la forma en que los modelos de lenguaje entienden y generan.

288
00:17:42,280 --> 00:17:44,600
Sentando las bases de mucho de lo que vemos hoy.

289
00:17:44,640 --> 00:17:49,680
En los asistentes virtuales y los chatbots más avanzados. No se lo pueden perder.

290
00:17:50,280 --> 00:17:54,840
Y como pensamiento final, el concepto de Matryoshka nos deja con una reflexión.

291
00:17:55,480 --> 00:18:03,600
Quizás el futuro no está en la carrera armamentística de entrenar modelos cada vez más gigantes para luego intentar hacerlos más pequeños a la fuerza.

292
00:18:03,720 --> 00:18:10,840
Sino que quizás el futuro está en enseñar a los modelos a ser inherentemente flexibles, modulares y eficientes.

293
00:18:11,280 --> 00:18:13,920
Desde su concepción. En cada una de sus capas.

294
00:18:14,200 --> 00:18:16,080
Un punto de vista muy potente.

295
00:18:16,960 --> 00:18:21,340
Con esa idea nos despedimos por hoy. Gracias por acompañarnos en este análisis.

296
00:18:21,800 --> 00:18:22,360
Hasta mañana.

297
00:18:33,380 --> 00:18:37,340
Y hasta aquí el episodio de hoy. Muchas gracias por tu atención.

298
00:18:38,740 --> 00:18:50,960
Esto es BIMPRAXIS. Nos escuchamos en el próximo episodio.