Gemento: un arnés experimental para reforzar tareas largas de LLM locales pequeños con estado externo, herramientas, roles y bucles

Hola.

Publiqué un repositorio para experimentar cuánto pueden aguantar los LLM locales pequeños en tareas largas.

Gemento
https://github.com/hang-in/gemento

Este proyecto no es una nueva arquitectura de modelo, ni un paper, ni una afirmación de que un modelo 4B reemplaza a los modelos frontier.

Más bien, se parece a un arnés experimental para medir de forma reproducible si, al sacar fuera del flujo de trabajo algunas cosas que pensábamos que debían estar dentro del modelo, se puede recuperar cierto nivel de rendimiento incluso con modelos pequeños.

El punto de partida fue un problema con el que me topé repetidamente mientras hacía seCall y tunaFlow.

• Las tareas largas no sobreviven más allá de la sesión
• El contexto se vuelve demasiado caro demasiado rápido
• El modelo no detecta bien por sí solo sus propios errores
• Los modelos locales pequeños muestran límites claros en inferencia de un solo intento

Así que partí de una pregunta simple.

En vez de seguir ampliando el contexto del prompt, ¿qué pasa si sacamos hacia afuera la memoria, el estado, la validación, el cálculo y el control del bucle?

En Gemento, esto se dividió en cuatro ejes.

1. Tattoo
   Externalizar la memoria de trabajo / estado intermedio como un estado JSON estructurado

2. Tools
   Externalizar el cálculo como herramientas basadas en llamadas a funciones

3. Role
   Externalizar la autoverificación separando los roles Proposer / Critic / Judge

4. Orchestrator
   Externalizar las condiciones de terminación y el control de iteración a un bucle de Python

El nombre viene de la metáfora de los tatuajes, polaroids y notas de la película Memento.

Hasta ahora, el modelo que más he usado es Gemma 4 E4B, un modelo local de clase effective 4B.

Aún hay pocas muestras y algunos resultados no son estadísticamente significativos. Por eso, en el README también los separé en supported / conditionally supported / inconclusive / rejected.

Los resultados más llamativos fueron más o menos estos.

• Los bucles múltiples fueron claramente mejores que la inferencia de un solo intento.
  Exp02: 50% → 94.4%
  Exp10: 1-loop 41.3% → 8-loop ABC 78.1%

• Pedirle al mismo modelo “revisa si estás equivocado” prácticamente fracasó.
  Exp03: detectó 0 de 15 errores plantados

• En cambio, al separar roles, la detección de errores mejoró mucho.
  Exp035: detectó 12 de 15, 80%

• En cálculo matemático, el efecto de externalizar con herramientas fue claro.
  En Exp08 / Exp08b, al forzar tool call y error hint, una tarea matemática específica se recuperó de 0% → 100%.

• En tareas de contexto largo, chunked ABC+Tattoo funcionó con fuerza frente a un dump simple.
  En Exp09 Large, bajo la condición 20K: Solo 0%, RAG 67%, ABC+Tattoo 100%
  Aun así, todavía no saco la conclusión de que ABC+Tattoo sea universalmente mejor que RAG. H9b sigue siendo inconclusive.

• El enfoque de poner un modelo fuerte como Judge más bien fracasó.
  En Exp11, cambié solo Judge por Gemini 2.5 Flash, pero la mixed condition salió por debajo del baseline all-Gemma.
  El mecanismo observado apuntó más bien a esto: “un Judge fuerte no ayuda al proceso de autodescubrimiento del modelo débil, sino que puede interferir con el esquema de estado intermedio y la convergencia de la conclusión”.

• En cambio, agregar un rol Extractor al inicio dio una mejora pequeña pero positiva.
  Exp12: Δ +0.050
  En particular, se vio recuperación en algunos casos catastróficos.

• Por el contrario, el rol Reducer al final fue peor.
  Exp13: Δ -0.053
  Se observó una abstraction loss donde, al “ordenar prolijamente” la respuesta final, la estructura de evidencia se comprimía y bajaba la puntuación.

Así que mi interpretación actual es esta.

Más que hacer que un modelo pequeño sea juzgado a la fuerza por uno más potente, puede ser más importante dónde se ubican los roles, incluso si se trata del mismo modelo.

En particular, añadir roles en la pre-stage fue relativamente seguro, mientras que resumir/ordenar en la post-stage fue riesgoso.

También dejé claramente escrito lo que este proyecto todavía no afirma.

• No afirma que un modelo 4B reemplace a modelos grandes
• No afirma que ABC+Tattoo sea siempre mejor que RAG
• No es una nueva arquitectura ni un nuevo método de entrenamiento
• No afirma que ya se hayan completado pruebas estadísticas al nivel de un paper
• Parte del related work todavía no ha terminado la bibliographic verification

Por ahora, se parece más a un “cuaderno público de experimentos”.

Los experimentos hechos por una sola persona se prestan fácilmente a ilusiones ópticas. En especial, creo que en este tipo de experimentos estructurales los resultados pueden variar con facilidad según el taskset, el scorer, el prompt y las condiciones del bucle.

Por eso lo publiqué antes de convertirlo en un paper polished.

El tipo de feedback que me interesa es más o menos este.

• Si se reproduce en otros modelos locales
• Si el taskset / scorer no está sesgado
• Si el baseline de RAG es lo suficientemente justo
• Si ABC+Tattoo realmente muestra otros modos de fallo
• Si al añadir Search Tool / Graph Tool / Evidence Tool aparece un efecto más claro en el eje de Tools

El siguiente experimento candidato es Exp14 Search Tool.

Si les interesa, pueden ver el README o la parte de docs/reference.

Son bienvenidos los contraejemplos, los fallos de reproducción y las críticas.