Modelos pequeños en una Raspberry Pi: enrutar antes de razonar

Una Raspberry Pi 4B con 8 GB de RAM y sin GPU es el banco de pruebas de Neurosymbolic Routing for Reliable Reasoning on Resource-Constrained Edge Devices, un trabajo publicado en arXiv el 30 de septiembre. Sus autores parten de un problema conocido para cualquiera que haya intentado ejecutar un modelo de lenguaje en local: los modelos que caben en ese tipo de hardware fallan justo en las tareas que se espera que un ordenador resuelva bien, como la aritmética, el álgebra o la lógica formal.

La tesis del paper es que buena parte de esa falta de fiabilidad se puede evitar. Muchas consultas que parecen exigir razonamiento son, en realidad, estructuralmente deterministas y admiten una solución simbólica rápida y exacta. Obligar a un modelo probabilístico a aproximarlas, argumentan, sacrifica precisión y energía a cambio de muy poco.

Cómo funciona el router

La propuesta es un router neurosimbólico que clasifica cada consulta entrante y la envía al solver correcto más barato. Las tareas estructuradas van a motores deterministas y el modelo pequeño (SLM, por sus siglas en inglés) queda reservado para los problemas de enunciado abierto. Dicho de forma llana: multiplicar 17 por 38 no debería pasar por un modelo de lenguaje, mientras que un problema redactado con cantidades implícitas probablemente sí.

Lo más interesante está en cómo se construye la lógica de enrutado. En lugar de escribir reglas a mano, los autores aprenden un autómata finito determinista (DFA) con L, el algoritmo de inferencia gramatical que Dana Angluin propuso en 1987. L trabaja con dos oráculos: uno de pertenencia, que responde si una cadena concreta pertenece al lenguaje, y otro de equivalencia, que confirma si la hipótesis actual es correcta o devuelve un contraejemplo. En este trabajo el SLM hace de oráculo de pertenencia y un conjunto de datos etiquetados cumple el papel de oráculo de equivalencia.

El resultado es un clasificador que, una vez aprendido, se ejecuta como un autómata: no hay pesos que cargar ni inferencia que pagar para decidir adónde va cada consulta. Además, un DFA se puede inspeccionar, algo mucho más difícil con un clasificador neuronal. En hardware tan limitado, ambas cosas cuentan.

Cómo lo evaluaron

La evaluación se hizo sobre 100 prompts no probados previamente, procedentes de conjuntos conocidos como DeepMind Mathematics y GSM8K, entre otros. El primero reúne problemas matemáticos generados de forma sintética y organizados por áreas como álgebra, aritmética o polinomios; el segundo, problemas escolares redactados en lenguaje natural. La mezcla encaja con el objetivo, porque obliga al router a separar las consultas que un motor simbólico resuelve directamente de las que requieren interpretar un enunciado.

Cien prompts es una muestra pequeña y conviene tenerlo en cuenta antes de extrapolar. Para valorar el enfoque habrá que revisar con calma las cifras de precisión y consumo del paper completo, sobre todo frente a la alternativa más obvia: usar un modelo algo mayor y aceptar el coste.

Para quién es útil

El caso más claro son los despliegues on-device en los que la privacidad o la falta de conexión impiden llamar a un modelo en la nube: equipos industriales, herramientas educativas sin conexión o asistentes embebidos. También encaja allí donde el consumo energético por consulta es una restricción real, como en dispositivos que funcionan con batería. Pero la idea de fondo sirve igual para arquitecturas mucho mayores.

En el ecosistema de Claude el patrón resulta familiar. Cuando un agente en Claude Code delega un cálculo en una herramienta expuesta vía MCP en lugar de resolverlo dentro del propio razonamiento del modelo, está aplicando una versión informal de la misma idea: mandar la parte determinista a un motor determinista. Lo que añade este trabajo es una manera de aprender esa decisión de forma sistemática, con un resultado que se puede leer y auditar, en lugar de dejarla en manos de una descripción de herramienta y del criterio del modelo.

En ElephantPink vemos a menudo la tentación de pedir al modelo más grande disponible cosas que una librería resuelve en milisegundos. Este trabajo lo lleva a un entorno extremo, pero la lección vale igual para un servidor con GPU: antes de escalar el modelo, conviene revisar qué consultas no deberían llegar a él.