Modelo de decisión que puntúa opciones en vez de generar texto

Problema

Un LLM autoregresivo puede alucinar porque decodifica tokens libremente. Para decidir entre opciones conocidas eso es un defecto, no una función: no necesitas texto nuevo, necesitas elegir bien y saber cuánta confianza merece esa elección.

Solución

El solver no genera nada. Recibe el contexto y las opciones, emite un score por opción y aplica softmax sobre ese conjunto. Al no tener un número fijo de clases, el mismo modelo sirve para 2, 4 o 7 opciones.

El dataset se fabrica solo: un LLM generador produce problemas de opción múltiple y un LLM crítico los valida antes de persistirlos. Los fallos del solver se agrupan en debilidades y el generador recibe peticiones dirigidas a ellas, priorizando los pares de confusión por ser lo más accionable.

Los LLM viven únicamente en la fábrica de datos. En el camino de decisión no hay ninguno.

Arquitectura

Por defecto solo se entrena la cabeza de scoring, con el encoder congelado; LoRA es un flag de configuración. La temperatura se ajusta después del entrenamiento para que las probabilidades signifiquen algo.

Decisiones técnicas

• Separación estricta entre generación de datos y decisión.
• Calibración de temperatura posterior al entrenamiento: un modelo seguro y equivocado es peor que uno dubitativo.
• Persistencia en SQLite con repositorio propio, para poder auditar qué problemas entraron y cuáles falló.
• Clientes LLM intercambiables (Ollama HTTP o CLI de Claude) tras un protocolo común, sin frameworks de agentes.

Resultado

MVP funcionando con ciclo cerrado de entrenamiento y generación dirigida, cubierto por tests sobre solver, repositorio, métricas y calibración.