Esta semana, veinticinco empresas tecnológicas han firmado un documento pidiéndole a Estados Unidos que no ponga restricciones a los modelos de inteligencia artificial de pesos abiertos. Lo firman la empresa Nvidia, Microsoft, Meta y unas cuantas más de ese tamaño. Y modelos abiertos, para entendernos, son los que cualquiera puede descargarse y ejecutar en su propia máquina.

Leyendo aquello me entró el gusanillo. Porque una cosa es opinar sobre los modelos abiertos, y otra es haber ejecutado uno.

Y además tenía una cuenta pendiente. Hace poco descarté una idea por dinero. Quería montar una herramienta que generase preguntas de examen para Moodle a partir de unos apuntes. Al echar cuentas, cada uso me costaba unos céntimos. Pocos, pero por cada llamada, y pagando yo. Así que la aparqué.

Y me quedé con la pregunta obvia. ¿No podría hacerme eso gratis mi propio servidor?

El escenario no es un laboratorio. Es un Mac mini con dieciséis gigas de memoria que ya sostiene esta web, un Moodle, un Jitsi y todo el sistema de monitorización. Ahí es donde tiene que caber el invitado. Y ando justo de disco, así que nada de bajarme el modelo más grande que quepa.

Lo he probado. Y por el camino me he equivocado dos veces, que suele ser la parte interesante.

La instalación fue decepcionantemente aburrida, que en un servidor es el mayor de los elogios.

El programa que ejecuta los modelos ocupa cuarenta y siete megas. El modelo que elegí, dos gigas y medio. Y una decisión pequeña pero deliberada: no lo dejé instalado como servicio permanente. En una máquina de producción, lo que arranca solo al encender es una decisión, no un descuido.

Le di unos apuntes sobre el modelo OSI, ese de las siete capas de red, y le pedí cuatro preguntas tipo test en el formato que Moodle sabe importar.

Y lo que me devolvió fue un muro de texto en inglés. El modelo se puso a pensar en voz alta, párrafo tras párrafo, hasta quedarse sin espacio y cortarse a media frase.

Aquí conviene explicar algo, porque es la clave de todo lo que vino después. Los modelos actuales vienen en dos sabores. Están los clásicos: les preguntas y responden. Y están los razonadores, que antes de contestar escriben un monólogo interno resolviendo el problema. Un "a ver, primero identifico las capas, luego pienso qué preguntar". No es un capricho: en tareas difíciles, así aciertan más.

Lo normal es que ese monólogo vaya por un canal aparte y tú solo veas la respuesta final. Pues a mí ese canal me volvía vacío, y el monólogo entero se me mezclaba con la respuesta. Guarda ese detalle, porque al final resulta que el error era mío.

Antes del giro, la otra cosa que quiero explicar, porque el nombre engaña.

Cuando lanzas una petición pones un límite de cuánto texto puede generar el modelo. En el mundo de las interfaces de pago, ese número es dinero. En mi servidor no cuesta ni un céntimo. Pero existe igualmente, porque un modelo no sabe parar solo: puede enrollarse, o entrar en bucle repitiendo lo mismo para siempre. Es el freno de mano.

Lo que pasa es que en local sí pagas, solo que no en euros. Pagas en segundos, porque a treinta palabras por segundo, el doble de límite es el doble de espera. Y pagas en memoria, en una máquina que ya sostiene otras cosas.

Resumido: en la nube pagas por token, en tu casa pagas por segundo.

Yo había puesto el límite en mil quinientos. El modelo gastó unos mil cuatrocientos pensando en voz alta y le quedaron cien para responder. Es como dar dos folios para un examen y que el alumno gaste folio y tres cuartos en el "a ver, déjame que me organice".

Con eso en la cabeza, cometí mi primer error de razonamiento. Pensé que el problema era que ese modelo se enrollaba demasiado. Así que me bajé otro que no razona. Misma familia, tamaño parecido, pero de los que van al grano.

Siete segundos. Formato impecable. Cuatro preguntas limpias, sin una palabra de más.

Y entonces las leí. Una preguntaba qué protocolo opera en la capa de red. Y marcaba como respuesta correcta... TCP. La buena, que es IP, la ponía como respuesta falsa. La siguiente preguntaba cuál de los protocolos no garantiza la entrega, y contestaba otra vez TCP. Cuando es UDP.

Dos de cada cuatro preguntas, con la respuesta equivocada marcada como buena.

Y aquí va un detalle que me deja en mal lugar pero que cuenta bien lo fácil que es engañarse. Yo tenía un validador comprobando la salida. Miraba que las llaves estuvieran equilibradas, que hubiera una sola respuesta correcta, que hubiera distractores suficientes. Y dio las cuatro preguntas por buenas. Las cuatro. Porque mi validador sabe de llaves y de signos, pero no sabe de redes.

Y ahora el giro, que es donde el experimento se puso interesante de verdad.

Contando todo esto, alguien me hizo la pregunta obvia. ¿Y no será cuestión de configuración?

Fui a comprobarlo. Le pregunté al programa qué sabía hacer aquel modelo, y ahí estaba, escrito: razonamiento separado. Lo soportaba perfectamente.

El problema era yo. Yo le estaba pasando un parámetro para desactivar el razonamiento, creyendo que así lo callaba. Y lo que hace ese parámetro en realidad es decirle al programa "no esperes que este modelo razone". Pero el modelo razona igual, porque es como está entrenado. Y al no haber nadie esperando ese monólogo, se vuelca entero en la respuesta.

La configuración correcta era justo la contraria: dejarle pensar, y leer el otro canal.

Lo repetí bien. Tres minutos de reloj. Dieciocho mil caracteres de monólogo, todos por el canal de razonamiento, donde no molestan. Y en la respuesta, mil caracteres de formato limpio. Cuatro preguntas. Sin una palabra de más, sin nada que rescatar del ruido. Y las cuatro, correctas.

Así que la comparación de verdad es otra. El modelo que piensa tarda tres minutos y acierta cuatro de cuatro. El que no piensa tarda siete segundos y acierta dos de cuatro. Veintiséis veces más lento, a cambio del doble de aciertos.

Y esa es la lección que me llevo. Ese monólogo que a mí me parecía ruido... era el trabajo. Quítale a un modelo el rato de pensar y te queda un texto perfecto por fuera y vacío por dentro. Los tres minutos no son el precio del formato. Son el precio de que las respuestas estén bien.

Hay otra lección, menos halagadora: di por imposible algo que solo estaba mal configurado. Y en el camino, mi propio validador me dijo que todo iba bien. El fallo escandaloso se ve. El fallo silencioso llega al examen, y del examen, al alumno.

¿Se puede, entonces? Sí. Gratis en euros, se puede. Un modelo de dos gigas y medio, en un servidor que ya está haciendo otras cinco cosas, genera preguntas de examen correctas sin mandarle los apuntes a nadie. Y para un centro educativo, que los datos de sus alumnos no salgan del edificio no es un detalle menor.

Pero gratis no es lo mismo que sin coste. Se paga en minutos de espera, en leerse la documentación antes de dar algo por imposible, y en un profesor revisando las preguntas antes de ponerlas. Que, bien mirado, es exactamente lo que hace un profesor con cualquier examen.

De momento los modelos se quedan instalados, porque esto no ha hecho más que empezar. Quiero probar modelos algo más grandes, a ver hasta dónde aguanta la máquina, y darles usos que no sean preguntas de examen. Así que ya os iré contando cómo sigue el experimento.

Y si quieres el detalle completo, los números, los comandos exactos y las preguntas tal y como las escribió cada modelo, lo he dejado todo escrito en un artículo en el blog. Lo tienes en sergiocomeron.com.

Gracias por escuchar el podcast de Sergio.