Un modelo de 270M para preguntas multisalto: pierde en precisión, gana en local

Se ajustó un modelo de 270 millones de parámetros para una parte muy concreta del razonamiento multisalto y luego se comparó con modelos mucho más grandes. Perdió en todas las cifras de precisión. Aun así es útil, y merece la pena explicar por qué.

La tarea suena modesta. Llega una pregunta multisalto y el modelo tiene que nombrar la primera búsqueda para un sistema de recuperación. De 95 preguntas reservadas para test, el diminuto Gemma-3-270M acertó 81 veces, un 85,3 %. Los dos rivales más grandes puntuaron más alto. Aun así, cabe en un portátil, no cuesta nada por llamada y funciona sin conexión. Del trabajo salió además un hallazgo extra: un system prompt fijo ayuda a un modelo de este tamaño mucho más de lo esperado, y la mejora se puede cuantificar.

El planteamiento

Las preguntas multisalto necesitan más de un dato. Pensemos en «Were Scott Derrickson and Ed Wood of the same nationality?» («¿Tenían Scott Derrickson y Ed Wood la misma nacionalidad?»). Para responder hay que encontrar la nacionalidad de una persona, después la de la otra y luego compararlas. HotpotQA, el dataset usado aquí, está formado por preguntas así, cada una con al menos dos datos que suelen venir de dos artículos distintos de Wikipedia.

El objetivo era solo el primer paso, llamado Hop-1: la primera búsqueda que un sistema debe hacer antes de poder ir a buscar cualquier otra cosa. Para una pregunta dada, el modelo escribe un objeto YAML corto con tres partes. thought explica qué buscar primero, action siempre es el valor fijo Lookup, y target_entity nombra exactamente lo que hay que buscar. Una salida correcta para la pregunta de Derrickson es así:

thought: "I need to find the nationality of Scott Derrickson first to eventually compare it to Ed Wood."
action: "Lookup"
target_entity: "Scott Derrickson"

El modelo no recupera documentos, no hace un segundo salto ni da una respuesta final. Solo decide qué buscar primero.

En preguntas de comparación, el modelo podría haber emitido las dos entidades y la comparación en una sola salida. El diseño lo evita a propósito. Cada salto recibe una acción atómica, así que una pregunta de comparación se convierte en tres pasos separados. Encontrar la entidad uno, encontrar la entidad dos y solo entonces comparar los resultados. Cuando algo falla, es fácil localizar el paso culpable. También cuesta precisión, porque los errores se acumulan a lo largo de una cadena más larga. Con un 90 % por paso, una cadena de tres pasos se queda en torno al 73 % de extremo a extremo. El intercambio es aceptable, porque un sistema que falla y dice dónde vale más que uno que falla en silencio.

El entrenamiento necesitaba ejemplos etiquetados de descomposiciones Hop-1 correctas, y GPT-4o hizo de profesor. Su prompt contenía cinco ejemplos resueltos y reglas estrictas: el objetivo debe salir directamente de la redacción de la pregunta y nunca ser un nombre que el modelo deduzca por su cuenta, y todo lo desconocido va en thought y no en target_entity. Ese prompt se pasó por preguntas de HotpotQA, y una segunda llamada a GPT-4o evaluó cada salida frente a los títulos de referencia del propio HotpotQA. Sobrevivieron 474 etiquetas.

Las reglas del profesor importan más de lo que parece. Obligar a que el objetivo reutilice las palabras de la pregunta evita que el modelo pequeño tenga que resolver nombres de memoria, que es justo donde un modelo de 270M alucinaría. Poner la incertidumbre en thought mantiene target_entity lo bastante limpio como para pasarlo directamente a una llamada de búsqueda.

Las etiquetas se dividieron 80/20: 379 para entrenamiento y 95 reservadas para todas las evaluaciones de abajo. Después Gemma-3-270M se ajustó con las 379 mediante supervised fine-tuning, es decir, entrenando directamente con pares de pregunta y respuesta y sin ninguna señal de recompensa.

Cómo se puntúa

Todas las cifras de abajo usan las mismas 95 preguntas reservadas y dos medidas distintas.

• Corrección del objetivo. ¿Eligió el modelo lo correcto para buscar? Un acierto significa que target_entity coincide con uno de los títulos de referencia de HotpotQA para esa pregunta (sin distinguir mayúsculas), o bien que un juez GPT-4o dictamina que ambas cadenas llevan a la misma búsqueda. Es la métrica principal.

Noventa y cinco preguntas significan que cada una mueve la puntuación unos 1,05 puntos. Por eso se dan los recuentos en bruto junto a los porcentajes. El juez también tiene su propia variabilidad: al volver a evaluar 75 filas ya aceptadas con temperature 0, cambiaron dos veredictos. Las diferencias por debajo de unos 3 puntos se tratan, por tanto, como ruido.

Una línea de prompt que importó

Primero hubo un experimento lateral. Se entrenaron dos copias del modelo con datos idénticos (los mismos 379 ejemplos, la misma división y los mismos hiperparámetros) que solo se diferenciaban en un párrafo. La copia A veía antes de cada ejemplo un mensaje de sistema fijo que describía la tarea y el formato YAML con palabras sencillas. La copia B veía solo la pregunta y la respuesta.

De entrada, la apuesta iba contra el mensaje de sistema. Con assistant_only_loss=True, el loss se calcula únicamente sobre los tokens de la respuesta del propio modelo, la señal que impulsa el aprendizaje. El mensaje de sistema y la pregunta nunca reciben un loss propio, así que parecía que no podían enseñar nada.

Esa apuesta se perdió. La copia A quedó por delante en ambas métricas, por cinco preguntas en cada una.

El resultado justificó mantener el mensaje, pero no conviene exagerarlo. Mejoras de 5,3 puntos (corrección del objetivo) y 5,2 puntos (coincidencia exacta) superan la variabilidad de 3 puntos del juez. Queda otro ruido, eso sí: solo 95 preguntas de test y una única ejecución de entrenamiento por copia. Al reentrenar desde cero más tarde la configuración con mensaje de sistema, para otro benchmark, salió 81/95 donde la primera ejecución dio 83/95. Una oscilación de dos puntos solo por una nueva ejecución significa que el tamaño real de la mejora entre ejecuciones sigue sin conocerse.

Parte del porqué está claro. Ningún loss cae directamente sobre los tokens del mensaje de sistema, pero eso no los hace invisibles para el entrenamiento. Los gradientes de los tokens de respuesta fluyen hacia atrás por las capas de atención que leen el mensaje de sistema, así que el modelo puede aprender a usar ese contexto en lugar de depender solo de lo que el modelo base ya sabía. A partir de ahí son conjeturas fundadas. Una teoría razonable: explicitar la tarea y el esquema da ventaja a las predicciones del siguiente token del modelo base incluso antes de entrenar, y quedan menos huecos por cerrar. El modelo publicado conserva el mensaje de sistema.

Una lectura práctica del resultado: el texto de instrucciones también forma parte de la entrada del modelo en inferencia, así que el mismo mensaje corto debe estar presente cuando se use el modelo. Quitarlo al desplegar pondría al modelo en una situación que nunca vio durante el entrenamiento.

El benchmark frente a modelos más grandes

Terminado el entrenamiento, el modelo se enfrentó a tres referencias con las mismas 95 preguntas: su propio modelo base sin tocar, Llama-3.1-8B-Instruct servido a través de Groq y el profesor GPT-4o cuyas salidas generaron las etiquetas.

Leer las dos primeras columnas lado a lado muestra lo que aporta el ajuste con un prompt fijo. Leer el modelo ajustado frente a los otros dos muestra cómo le va a un especialista pequeño frente a modelos mayores que recibieron cada uno un prompt completo. Los dos prompts son realmente cosas distintas. El corto es el mensaje de sistema con el que el modelo pequeño se entrenó y se evaluó: la tarea y los tres nombres de campo, nada más. El largo, de cinco ejemplos, es el que produjo las etiquetas de entrenamiento. Incluye cinco ejemplos resueltos más reglas de formato que el corto omite, como la cadena literal "Lookup" y el requisito de que la salida sea un mapeo plano en lugar de una lista. Dar el prompt largo a los modelos grandes fue intencionado. Se buscaba ver su rendimiento con instrucciones adecuadas, no comprobar si adivinaban un formato no especificado. Con el prompt corto, ambos quedaron cerca de cero, y la causa no fue un razonamiento flojo sino la falta de reglas de formato. El prompt largo lo arregló en los dos.

En precisión, el modelo pequeño queda por detrás de Llama-3.1-8B, y con más distancia por detrás de GPT-4o. En velocidad también va por detrás de GPT-4o, incluso sin ida y vuelta por red. La razón es que GPT-4o está sobre una infraestructura de serving optimizada para tráfico rápido a gran escala, mientras que el modelo pequeño atiende una llamada tras otra en una GPU compartida de Colab, donde el batching y la caché de pesos no están en manos de nadie.

Llama-3.1-8B tiene unas 30 veces más parámetros. OpenAI no revela el tamaño de GPT-4o, así que no hay proporción, pero nadie lo llamaría pequeño. Aquí no se superó a ninguno de los modelos grandes. El benchmark sí resuelve otra pregunta: ¿puede un modelo de este tamaño encargarse de esta única tarea concreta? Puede, con 81 de 95. Pero si la tabla de precisión es el único criterio, el modelo pequeño no gana.

Lo que el benchmark no pudo captar

El verdadero argumento a favor de este modelo no sale de esa tabla. Sale de tres cosas que la tabla nunca midió.

Coste. Medido, no supuesto. Los recuentos de tokens salieron de los prompts y respuestas reales de las ejecuciones con GPT-4o, contados con tiktoken (el tokenizador de los modelos de OpenAI) y valorados con las tarifas publicadas de OpenAI. Una llamada típica a GPT-4o consumió 606,6 tokens de prompt y 39,4 de respuesta, unos $0,0019 cada una, o cerca de $1,91 por cada 1.000 llamadas. El modelo ajustado no tiene cargo por llamada. Su hardware y su consumo eléctrico siguen costando algo, así que «gratis» no es del todo exacto, pero no hay factura por petición ni límite de uso.

Privacidad. Las dos funciones de inferencia local no hacen ninguna petición de red. La pregunta entra en el tokenizador, luego en el modelo, y se queda en el dispositivo. Es una propiedad del código y no una cifra de benchmark, así que basta con leerlo para comprobarlo. Hay una salvedad con la demo alojada: se ejecuta en servidores de Hugging Face, así que el texto que se escribe allí sale del equipo del visitante. La afirmación de privacidad cubre solo las ejecuciones autoalojadas.

Funcionamiento sin conexión. Comprobado dos veces, no supuesto. Primero se establecieron HF_HUB_OFFLINE=1 y TRANSFORMERS_OFFLINE=1. Esas variables hacen que las librerías de Hugging Face lancen un error ante cualquier intento de red, en lugar de usar una caché en silencio. Después se apagó el Wi-Fi por completo y se ejecutó el propio código de carga y generación de la demo con ambas variables activas. Una pregunta totalmente nueva, ausente de los datos de entrenamiento y de test, produjo igualmente una descomposición correcta sin conexión.

Ninguna tabla de precisión muestra estos tres rasgos. Son las razones reales para ejecutar un modelo pequeño en local en lugar de llamar a uno gigante por la red, y el argumento resulta más honesto con las poco favorecedoras cifras de precisión justo al lado.

Qué está disponible

El modelo, el dataset y una demo funcional son públicos en Hugging Face:

• el modelo ajustado
• el dataset de descomposiciones
• un Space con la demo en vivo

La demo usa un pool compartido de GPU gratuitas, así que la primera petición tras un periodo inactivo es lenta mientras cargan los pesos. Trae dos preguntas integradas, una de tipo puente y otra de comparación, para que los visitantes vean ambas formas de descomposición sin escribir nada.

Las comprobaciones fueron más allá de esos dos ejemplos. Una pregunta realmente nueva, ausente tanto del entrenamiento como del test («The author of The Hobbit was born in which country?» – «¿En qué país nació el autor de El hobbit?»), obtuvo una descomposición limpia y correcta. No todos los intentos fueron impecables: una pregunta sobre dónde tiene su sede SpaceX produjo la entidad objetivo correcta pero una línea thought sin sentido. Por ahora, la elección de la búsqueda es más estable que la explicación que la acompaña, sobre todo cuando la redacción se aleja de lo habitual en HotpotQA.

En resumen

Toma un paso bien delimitado de una cadena de razonamiento más grande. Un modelo de 270 millones de parámetros lo resuelve correctamente en 81 de 95 casos, va por detrás de modelos mucho mayores en precisión y aun así funciona en un portátil sin factura y sin red. Para escenarios donde las preguntas no pueden salir del dispositivo, y donde una primera búsqueda errónea se puede detectar o reintentar más adelante en el pipeline, Hop-1 merece una prueba. No demuestra que un modelo tan pequeño pueda sostener por sí solo toda una cadena de razonamiento sin un verificador detrás.