Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio
de BIMPRAXIS.
Hoy os traemos el modelo de IA que
se entrena a sí mismo, desmontando el M2
.7 de Minimax.
¡Hola a todos!
Para arrancar, vamos a poner un caso hipotético
sobre la mesa.
Si alguien contrata a un equipo de arquitectos
para construir un rascacielos gigante, pues lo normal
es que empiecen a poner cimientos o a
dibujar planos, ¿verdad?
Claro, es lo lógico.
Pues en lugar de eso, lo primero que
hacen estos arquitectos es inventarse un nuevo tipo
de grúa, y luego diseñan unas hormigoneras más
eficientes y crean un software de gestión de
obras desde cero.
Todo esto solo para poder trabajar más rápido
después.
Esa idea es muy importante.
Esa idea, esa vuelta de tuerca a la
forma de trabajar, es exactamente lo que subyace
bajo el capó del sistema que nos ocupa
hoy, el M2 .7.
Y fíjate que es un cambio de paradigma
que merece muchísimo la pena diseccionar.
Porque el objetivo de nuestra inmersión de hoy
es rascar muy por debajo de esa capa
de marketing deslumbrante que, a ver, siempre acompaña
los lanzamientos de inteligencia artificial.
Ya, siempre lo pintan todo como una revolución.
Exacto.
Queremos entender...
Queremos entender qué significa, a nivel estrictamente técnico,
que una IA ayude a construirse a sí
misma.
Y además, hay que poner a prueba su
rendimiento real frente a los competidores más asentados.
Porque los números prometen mucho.
Prometen una barbaridad.
Pero sobre todo, hay que evaluar si las
limitaciones operativas, esa letra pequeña que siempre esconde
problemas, justifican un coste de uso que, sorprendentemente,
resulta ser muy, muy bajo.
O sea, hay que separar la promesa comercial...
...de lo que realmente se encuentra un ingeniero
cuando conecta esto a su servidor.
Pues vamos a entrar directos a esa afirmación
principal que resulta tan rompedora.
Porque el análisis exhaustivo en el que nos
basamos hoy deja clarísimo que este modelo de
Minimax no es simplemente uno más que resulta
ser un poco más rápido generando texto.
No, ni mucho menos.
O que araña un par de puntos extra
en un examen estandarizado.
La gran baza aquí es que ha tenido
un papel activo en su propio proceso de
entrenamiento.
Ha construido y refinado su propia infraestructura.
O sea, es lo que en el análisis
denominan un Research Agent Harness, un arnés de
agente de investigación.
Eso es.
Y el término arnés, el harness, es fundamental
para entender el salto técnico.
Tradicionalmente, pues vemos modelos que generan datos sintéticos
para entrenar a versiones futuras de sí mismos,
¿vale?
Eso ya es bastante común.
Sí, eso lo tenemos más visto.
¿Qué infraestructura técnica necesaria para ejecutar los experimentos
de aprendizaje por refuerzo?
O sea, la base del entrenamiento.
Totalmente.
Ha estado monitorizando las tuberías de datos, detectando
y depurando errores en el código de entrenamiento
y evaluando si los resultados de cada experimento
eran útiles o no.
Llevándolo a un terreno más cotidiano, es como
un programador que entra a trabajar a una
empresa y al ver que su entorno de
desarrollo le resulta lento o ineficiente, se pone
a reprogramar el propio editor sobre la marcha
mientras sigue escribiendo la aplicación principal.
¿Una analogía?
Perfecta.
Y el análisis técnico describe esto como un
bucle completamente autónomo.
O sea, la IA detecta un fallo, propone
un cambio en su propio andamiaje de pruebas,
ejecuta las evaluaciones pertinentes y, ojo, decide por
su cuenta si mantiene esa modificación o se
vuelve a la versión anterior.
Y este ciclo ha estado corriendo durante más
de 100 rondas.
Más de 100.
Sí, sí, 100 rondas sin que ningún humano
interviniera.
Es que suena a ciencia ficción.
A ver, genera un escepticismo enorme.
Cuesta creer que esto sea un salto técnico
real y no, bueno, pues una narrativa muy
bien empaquetada para vender titulares sobre IA general.
A ver, esa reserva mental está más que
justificada, sobre todo viendo la tendencia que tiene
esta industria a exagerar cualquier automatización, en plan,
ya tenemos inteligencia general.
Ya te digo.
Sin embargo, el valor técnico real de este
hito no reside en que la máquina haya
cobrado conciencia o ni nada parecido.
Reside en la dirección que marca.
Hasta ahora, el cuello de botella en la
evolución de estos modelos ha sido puramente humano.
Claro, el tiempo que tarda la gente.
Exacto.
Se necesitan ejércitos enteros de ingenieros ajustando hiperparámetros,
revisando por qué Naricio es una métrica ha
bajado, corrigiendo el rumbo manualmente.
Al conseguir que un modelo asuma esa carga
de crear y mantener su propia infraestructura de
evaluación, pues se inicia una transición clarísima.
La IA pasa de ser solo el producto
final a ser también la herramienta de desarrollo.
Exacto.
Eso es.
Y validar ese ciclo continuo de más de
100 rondas demuestra que este concepto de autoevolución
ya no es pura teoría en una pizarra.
Es una base operativa o funcional que reduce
drásticamente la fricción humana.
Vale, pero si aceptamos que este modelo es
capaz de montarse su propio taller de trabajo
y optimizar sus herramientas, la duda ofende.
¿Cómo de bueno es el producto final cuando
lo sacas de ese taller y lo pones
a programar de verdad?
Ahí es donde entramos en terreno pantanoso.
Totalmente.
Hay que entrar en la arquitectura técnica y
en esa especie de garra fría de las
pruebas de rendimiento, los famosos benchmarks.
El análisis subraya que el M2 .7 está
diseñado con una obsesión clarísima por los flojos
agénticos.
Que no es lo mismo que un chatbot
normal, claro.
Exacto.
No estamos hablando de un asistente al que
le haces un par de preguntas rápidas, sino
de tareas largas, donde un agente tiene que
planificar una estrategia, utilizar diversas herramientas externas y,
lo más importante, mantener un contexto coherente durante
mucho tiempo.
Y para sostener eso hace falta mucha memoria
a corto plazo, digamos.
Eso es.
Le han dotado de una ventana de contexto
enorme de 243 .800 tokens.
Y en velocidad, la versión estándar escupe 60
tokens por segundo, mientras que la versión high
speed llega a los 100 tokens por segundo.
Bueno, a ver, esas cifras de velocidad y
capacidad de retención, hoy en día son los
cimientos mínimos necesarios para que un flujo agéntico
largo no colapse por pura lentitud.
Ya, es el desde.
Exacto, es lo mínimo que se despacha.
Pero la verdadera prueba de fuego está en
las métricas de programación pura y dura.
Los datos del análisis arrojan un 56 ,2
% de éxito en CWP Bench Pro, un
55 ,6 % en Byte Pro y un
52 ,7 % en MultiCW Bench.
Y aquí es importantísimo hacer una pausa, creo
yo, porque para alguien que esté fuera del
día a día del desarrollo de software, un
56 % de éxito en un test.
Parece un suspenso catastrófico.
Cualquiera pensaría que el modelo es inútil porque
falla casi la mitad de las veces.
Es un matiz crucial, me alegra que lo
saques.
Porque pruebas como SWI Bench Pro no son
exámenes tipo test de universidad.
No es marcar la casilla correcta.
Qué va, qué va.
Consisten en volcar problemas reales, issues sacados directamente
de repositorios de código abierto de GitHub, que
son inmensos y súper complejos.
Un cristo de código, vamos.
Literalmente.
El modelo tiene que navegar por miles de
archivos, entender dónde narices está el problema, proponer
la solución, escribir el código modificado y encima
asegurar que nada más se rompa al hacerlo.
Que una máquina logre resolver el 56 con
2 % de esos problemas de forma totalmente
autónoma es un porcentaje altísimo.
¿Rivaliza con el esfuerzo de un humano?
Rivaliza con el tiempo y esfuerzo que le
tomaría un ingeniero humano señor tirarse días mirando
el código.
Lo cual lo pone cara a cara con
la artillería pesada del mercado.
Igualando o incluso superando en ciertas áreas a
pesos pesados como Cloud 4 .6 Opus, a
Gemini 3 .1 Pro y a los equivalentes
a GPT 5 .4.
Son palabras mayores, sí.
Pero hay otra métrica en el análisis que
resulta fascinante por cómo funciona.
Se trata de ML Benchlight, que es una
evaluación creada por OpenAI.
Compila 22 tareas de Machine Learning inspiradas en
Kaggle.
Y Kaggle no es ninguna broma.
Para nada.
Para dar un poco de perspectiva, Kaggle es
una plataforma donde científicos de natos de todo
el mundo compiten, compiten durante semanas, para crear
modelos predictivos súper complejos.
Pues el M2 .7 no sólo aprueba, sino
que logra un promedio de medallas del 66
con 6 % en estas competiciones.
Que es una barbaridad.
Es una barbaridad, pero lo impactante es cómo
llega a ese número.
Resulta que escala en función del tiempo de
cómputo.
A las 5 horas de procesamiento.
El modelo ronda un 57 % de éxito.
Y si se le deja seguir pensando, esa
cifra continúa subiendo escalonadamente hasta llegar a las
25 horas.
Esto que comentas ilustra un cambio de paradigma
potentísimo en el sector.
Hemos pasado de valorar a los modelos por
su inmediatez, es decir, quién te responde más
rápido en una ventanita de chat, a valorar
el cómputo en tiempo de inferencia.
Permitir que la máquina piense.
Exacto.
Permitir que la máquina piense durante un día
entero si hace falta.
En problemas de ciencia de datos complejos, la
primera respuesta rara vez es la óptima.
El hecho de que el rendimiento del modelo
siga escalando tras 25 horas demuestra una capacidad
de iteración brutal.
Prueba una hipótesis matemática, ve que el modelo
predictivo no alcanza la precisión deseada, ajusta los
pesos de las variables y vuelta a empezar.
Todo esto suena espectacular, verdaderamente.
Pero hay un detalle en las especificaciones del
análisis.
Una especie de letra pequeña que cambia completamente.
La letra pequeña, sí.
Esos 204 .800 tokens de la ventana de
contexto tienen trampa.
Resulta que la fuente subraya que no representan
sólo la cantidad de información que se le
puede dar al modelo como instrucción de entrada,
sino que es un límite combinado.
Suma la entrada más la salida.
¿No significa esto que puede quedarse a medias
y cortar tareas largas?
Ese es el gran cuello de botella estructural,
sin duda.
Es un riesgo altísimo.
Para visualizar el problema, es como si a
un trabajador le dieras un presupuesto estricto de
200 .000 caracteres para usar en una libreta
compartida para todo el proyecto.
Vale.
Si la tarea exige leer un manual técnico
larguísimo que consume, pongamos, 150 .000 caracteres, a
ese trabajador sólo le quedan 50 .000 para
redactar su informe, razonar sus pasos en la
libreta y usar herramientas.
Y 50 .000 tokens vuelan.
Vuelan.
Si el modelo supera ese límite combinado en
medio de un flujo, en medio de un
flujo agéntico largo, sencillamente colapsa.
La tarea se corta de forma totalmente abrupta.
Y claro, esto obliga a los desarrolladores a
llevar una contabilidad de tokens casi milimétrica, lo
cual añade una fricción enorme a la hora
de programar.
Y a esto hay que sumarle una capa
de precaución adicional.
El análisis destaca que las métricas de Minimax,
aunque son impresionantes, se basan en protocolos de
evaluación internos.
Ellos mismos han configurado el entorno de pruebas
y las herramientas que estaban habilitadas para que
el modelo se examine.
A ver, cuando el arquitecto que diseña el
examen y el alumno que lo hace son
el mismo, siempre existe un riesgo inelente de
sobreoptimización.
Que se saben las respuestas, vamos.
No implica necesariamente que los datos sean falsos,
no.
Pero en la industria del machine learning, un
protocolo interno rara vez es 100 % reproducible
por agentes externos, sin que haya variaciones en
los resultados.
Por eso, explican que estos porcentajes estratosféricos deben
tomarse como indicadores orientativos.
¿Orientativos?
Claro.
Sí.
Te indican una capacidad indudable, pero no como
verdades absolutas o una tabla de clasificación inamovible.
Dejando a un lado el entorno supercontrolado del
laboratorio y de los test, la verdadera pregunta
es ¿qué pasa cuando pones esta maquinaria a
funcionar en un entorno real?
El análisis detalla que en ingeniería de software,
el M2 .7 va muchísimo más allá de
un simple autocompletado de código.
Ya no sólo que te termine la frase
de programación.
¿Qué va?
Brilla en diagnósticos de producción, es capaz de
correlacionar múltiples métricas de rendimiento, analizar cronologías de
despliegue, timelines completos y buscar el origen exacto
de una regresión en el código.
Que eso es dificilísimo.
Tela.
Y también destaca en tareas de productividad de
oficina avanzada, lo que el análisis llama GDPAA.
Logra editar documentos de Word, hojas de Excel
y presentaciones de PowerPoint en múltiples rondas de
trabajo.
Sí.
Efectivamente, el tema ofimático lo maneja de maravilla.
Totalmente.
Maneja más de 40 habilidades complejas con un
97 % de adherencia a las instrucciones, obteniendo
una puntuación de 46 ,3 en la métrica
TULSLON.
La versatilidad entre lo que es el código
puro y duro en la ofimática es muy
destacable.
Pero el núcleo de este éxito práctico, el
secreto, reside en una técnica concreta, el tool
use con pensamiento intercalado, el tool use with
interleaved thinking.
Pensamiento intercalado.
Exacto.
Los modelos clásicos tienden a ser monolíticos, es
decir, reciben un prompt inicial y te escupen
una parrafada enorme de una sola vez.
Si se equivocan en el primer paso de
esa parrafada, todo el resto de la respuesta
es basura, es inútil.
El M2 .7, en cambio, rompe ese proceso.
Y ese concepto de pensamiento intercalado cobra todo
el sentido cuando se analiza el escenario estrella
que plantea la fuente de hoy, los agent
teams, los equipos de colaboración multiagente.
El caso de uso que describen, sinceramente, es
para quedarse con la boca abierta.
El del servidor, ¿verdad?
Ese.
Pongamos que hay un incidente crítico en producción
en una empresa tecnológica, una caída de servidores
a las 3 de la madrugada.
Según el análisis, un agente autónomo detecta el
fallo y empieza a correlacionar las métricas de
rendimiento con la cronología reciente de cambios.
Identifica el bloque de código problemático mediante análisis
estadístico.
Y luego, sin consultar al ADIA, accede a
la aplicación.
Encontra la base de datos para verificar su
hipótesis y, finalmente, propone una mitigación directa del
error.
Todo este proceso sin despertar a un solo
humano.
A ver, la idea de que un equipo
de agentes detecte una caída a las 3
de la mañana, busque el error en el
código y lo arregle solo es fascinante, pero
requiere un nivel de confianza ciego en la
máquina que, sinceramente, da terror.
Sí, sí.
Entregar ese nivel de control en producción a
un modelo produce vértigo.
Pero ahí es justo donde el pensamiento intercalado
actúa como… digamos, una red de seguridad técnica.
¿Cómo funciona esa red de seguridad?
Pues, en ese escenario del servidor caído a
las 3 de la mañana, el agente no
intenta adivinar el fallo desde el minuto 1
y cambiarlo todo.
Funciona más como un detective frente a una
pizarra.
Lee la alerta.
Hace una pausa para pensar internamente su próximo
paso.
Vale.
Decide invocar una herramienta externa, como ejecutar una
consulta en el registro de errores.
Lee los resultados de esa consulta.
Y, ojo.
Hace otra pausa para evaluar.
¿Esto confirma mi teoría inicial?
Si la respuesta es no, descarta la idea,
fórmula una hipótesis nueva y busca en otra
tabla de la base de datos.
Va paso a paso.
No se tira a la piscina.
Exacto.
Esta iteración constante, este ciclo de observar, razonar
y actuar paso a paso, es lo que
permite que el modelo navegue por el caos
de un entorno de producción real sin volverse
loco y romper más cosas.
Bueno.
Una vez entendido este enorme potencial.
Y cómo gestiona los flujos agénticos, toca hablar
de la implementación práctica.
Porque promete ser la salvación de la oficina
y el guardián de los servidores de madrugada.
Y, además, promete hacerlo a precio de saldo.
Sí.
La factura es un tema clave aquí.
Analicemos la integración, los precios y, casi lo
más interesante, sus tropiezos más básicos.
A nivel de integración, parece bastante fluido.
Se puede conectar como un proveedor personalizado con
una simple clave de API, una API key.
En editores de código como Cursor .com.
Y también funciona con herramientas de terminal como
Cloud Code.
Todo esto disponible vía Minimax o a través
de Open Router.
La facilidad de conexión es un gancho comercial
fuertísimo.
Obvio.
Pero el verdadero golpe en la mesa, como
decías, es su estructura de costes.
Es agresivísima.
Muy, muy agresiva.
Su modalidad de pago por uso está fijada
en 0 ,30 dólares por cada millón de
tokens de entrada.
Y apenas 0 ,20 dólares por el millón
de servidores.
Si comparamos esto con las tarifas habituales de
los modelos de frontera actuales, es que es
una fracción minúscula del coste operativo.
Es bajísimo.
Es que te sale casi gratis, vaya.
Ya te digo.
Además, plantean suscripciones súper accesibles, que empiezan en
los 10 dólares mensuales para la versión Starter
y suben hasta los 50 dólares en el
plan Max.
La versión High Speed está desde 40 dólares
al mes.
Todo esto democratiza muchísimo el acceso a arquitecturas
agénticas súper complejas.
Y justo cuando parece que estamos ante la
máquina perfecta e imbatible, capaz de arreglar una
infraestructura de red súper compleja, mientras cuesta lo
mismo que tomarse un café, llega el baño
de realidad, el tropiezo del que habla la
fuente.
¡Ay!
¡El tropiezo!
Es buenísimo.
Es que, a ver si lo entiendo, tenemos
un modelo capaz de arreglar una caída de
servidores coordinando un equipo de IAs autónomas, pero
tropieza estrepitosamente al intentar resolver un cifrado César.
Pues mira, este fallo tan absurdo con el
cifrado César es la radiografía perfecta de la
naturaleza de la inteligencia artificial hoy en día.
¿Por qué lo dices?
Porque tendemos a antropomorfizar estas herramientas.
Asumimos instintivamente que si un modelo es un
genio brillante en flujos de trabajo complejos de
programación, pues automáticamente debe ser un genio en
lógica básica o en puzles sencillos, porque así
funciona el intelecto humano.
Si sabes hacer una integral, sabes sumar.
Claro, esa es la lógica que aplicamos.
Pero en las redes neuronales hay una simetría
muy profunda.
Estos sistemas son, al final del día, devoradores
de patrones estadísticos.
El modelo domina los lenguajes de programación porque
ha ingerido millones y millones de repositorios y
entiende perfectamente la estructura estadística de las llamadas
a una API.
Vale, tiene el patrón memorizado.
Las algorítmicas secuenciales, como ir desplazando caracteres uno
a uno, sufren muchísimo porque lo sacas totalmente
de su zona de confort predictiva.
No es estadística.
Es lógica.
¿Por qué?
Es pura.
Es un golpe de realidad muy necesario, desde
luego.
No estamos ante una inteligencia general uniforme que
sirva para todo.
Y creo que este tropiezo encadena perfectamente con
las cuatro limitaciones técnicas clave que detalla el
informe.
Letra pequeña, que todo el mundo debería conocer
antes de lanzar campanas al vuelo.
Fundamental conocerlas, sí.
La primera es un bloqueador directo para muchísimas
corporaciones.
Es un modelo propietario.
No ofrece los pesos abiertos.
Y esto para la privacidad.
La segunda limitación es un bloqueador directo para
las autoridades y las auditorías.
Es letal.
Si una empresa maneja datos médicos o información
financiera confidencial, o necesita someter sus sistemas a
auditorías de seguridad súper estrictas, enviar información sensible
a una API cerrada sencillamente no es una
opción viable.
El cumplimiento normativo no te lo permite.
La segunda limitación ya la hemos diseccionado un
poco.
Ese peligroso límite de tokens combinado de entrada
y salida, que te funciona como una guillotina
silenciosa.
Y te corta el proceso a la mitad
si no tienes cuidado.
Sí.
Te exige estar con la calculadora de tokens
en la mano.
Pero la tercera limitación es, probablemente, la que
más dolores de cabeza genera a los ingenieros
de software a nivel práctico.
La extrema complejidad operativa.
Resulta que, para que el modelo mantenga ese
nivel de brillantez usando el pensamiento intercalado, requiere
que el sistema que lo aloja preserve los
campos de razonamiento de manera impecable.
Las reflexiones internas y las llamadas a herramientas
son muy importantes.
Exacto.
Tienen que preservarse con una fidelidad absoluta en
el código.
O sea, si durante un proceso largo de
varios pasos, el código del desarrollador recorta o
formatea mal accidentalmente una de esas reflexiones internas
que hizo el modelo hace cinco minutos, todo
se desmorona.
Literalmente.
El modelo sufre una especie de amnesia instantánea.
Al perder el hilo conductor exacto de por
qué tomó una rescisión específica tres pasos atrás,
la degradación de su rendimiento se desmorona.
El rendimiento es brutal.
Empieza a alucinar, o a inventarse cosas, o
directamente a repetir acciones en bucle porque no
sabe por qué está ahí.
Y esto exige que la arquitectura de software
de la empresa sea absolutamente impecable.
Y eso es difícil.
Y la cuarta limitación termina de apretar las
tuercas técnicas.
Porque hablamos de topes estrictos impuestos por la
propia plataforma.
Tienen un límite de 500 peticiones por minuto
y un máximo de 20 millones de tokens
por minuto.
Pero el dato que me parece verdadero a
mí es que, en el caso de las
empresas, el más crítico es el comportamiento del
prompt catching.
Uff, ese dato es demoledor.
Ese sistema de memoria a corto plazo, que
guarda las instrucciones iniciales para ahorrar tiempo y
dinero en tareas largas, resulta que caduca en
tan sólo cinco minutos.
¿Cinco minutos?
Exige una disciplina de implementación brutal.
Es que las implicaciones operativas de esa caducidad
tan agresiva son enormes para un flujo agéntico.
El prompt catching es como un camarero que
recuerda el larguísimo pedido de una mesa sin
tener que volver a anotarlo entero.
Buena analogía.
Pues imagínate que el agente autónomo decide consultar
una base de datos externa muy pesada.
Y esa consulta tarda seis minutos en devolver
los resultados.
Pues en ese tiempo, la memoria caché de
Minimax ya se ha borrado por completo.
Madre mía.
O sea, el modelo olvida instantáneamente todo.
Todo el documento técnico de 200 .000 tokens
que le habías proporcionado al principio se esfuma.
Para continuar trabajando, el usuario tiene que volver
a enviar y procesarlo.
El usuario tiene que pasar toda esa cantidad
de información desde cero.
Y esto multiplica el coste económico y destroza
el tiempo de latencia.
En tareas asíncronas complejas, cinco minutos es un
margen de maniobra inasumiblemente corto.
Resumiendo un poco todas estas piezas de la
inmersión de hoy, el panorama que nos pinta
el análisis es un contraste constante entre innovación
deslumbrante y fricción técnica.
Promete una reducción drástica en la intervención humana
y además presenta unos precios súper disruptivos.
Pero, a cambio, exige lidiar con límites de
memoria estrictos, caídas de rendimiento por un mal
formato y un ecosistema totalmente propietario.
La conclusión más sólida a la que se
puede llegar, tal y como dice la fuente,
es que el M2 .7 representa una apuesta
económicamente demoledora por asentar este paradigma de los
flujos agénticos.
Es barato y muy capaz.
Sí, los números están ahí.
Sin embargo, su éxito y consolidación final en
el mercado no es un problema.
No van a depender de que consiga un
puntito porcentual más en un benchmark de programación.
Dependerá enteramente de si los desarrolladores están dispuestos
a rediseñar sus propias infraestructuras para acomodar esta
estricta complejidad operativa y la fragilidad del modelo.
Al final, las tablas de clasificación sirven para
acaparar titulares, pero el mejor benchmark siempre es
el caso de uso real de cada uno
en el barro del día a día.
Totalmente de acuerdo.
Y para cerrar esta inmersión.
Hay una idea latente en todo este análisis
que creo que merece una reflexión profunda.
Si asumimos como cierto que la próxima generación
de inteligencias artificiales ya está invirtiendo su inmenso
tiempo de cómputo en crear, refinar y automatizar
sus propios entornos de entrenamiento para la siguiente
generación, el escenario futuro cambia drásticamente.
Ya lo creo que cambia.
Cabe preguntarse si llegará un punto, a no
muy largo plazo, en el que el verdadero
cuello de botella para el avance tecnológico no
sea la falta de microprocesadores o la capacidad
matemática de la máquina, sino la pura velocidad
a la que los cerebros humanos podamos procesar,
comprender y auditar lo que estas infraestructuras están
construyendo a puerta cerrada.
Antes de despedirnos hasta el próximo programa, os
informamos de que las voces que oyes han
sido generadas por la IA de Notebook LM
y que dirigiendo el podcast se encuentra Julio
Pablo Vázquez, un humano que te envía saludos.
En caso de error, probablemente sean errores humanos.
Nos escuchamos.
Y hasta aquí el episodio de hoy.
Muchas gracias por tu atención.
Esto es BIM Praxis.
Nos escuchamos en el próximo episodio.