Gemento : un harnais expérimental pour renforcer les longues tâches de petits LLM locaux avec état externe, outils, rôles et boucles

Bonjour.

J’ai rendu public un dépôt pour expérimenter jusqu’où de petits LLM locaux peuvent tenir sur des tâches longues.

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

Ce projet n’est ni une nouvelle architecture de modèle, ni un article de recherche, ni une affirmation selon laquelle un modèle 4B remplacerait les modèles frontier.

Il s’agit plutôt d’un harnais expérimental permettant de mesurer, de façon reproductible, si l’on peut récupérer une partie des performances sur de petits modèles en sortant du workflow certains éléments que l’on pensait devoir rester à l’intérieur du modèle.

Le point de départ a été des problèmes auxquels je me suis heurté à répétition en créant seCall et tunaFlow.

• les tâches longues ne survivent pas au-delà d’une session
• le contexte devient trop coûteux trop rapidement
• le modèle repère mal ses propres erreurs
• les petits modèles locaux montrent des limites nettes en inférence en une seule passe

Je suis donc parti d’une question simple.

Au lieu d’augmenter sans cesse le contexte du prompt, que se passe-t-il si l’on externalise mémoire, état, vérification, calcul et contrôle de boucle ?

Dans Gemento, cela a été réparti en quatre axes.

1. Tattoo
   externaliser la mémoire de travail / l’état intermédiaire dans un état JSON structuré

2. Tools
   externaliser le calcul vers des outils fondés sur des appels de fonction

3. Role
   externaliser l’auto-vérification via une séparation des rôles Proposer / Critic / Judge

4. Orchestrator
   externaliser les conditions d’arrêt et le contrôle d’itération dans une boucle Python

Le nom vient de la métaphore des tatouages, polaroids et mémos du film Memento.

Le modèle principalement utilisé jusqu’à présent est Gemma 4 E4B, un modèle local effectif de classe 4B.

L’échantillon reste encore réduit, et certains résultats ne sont pas statistiquement significatifs. C’est pourquoi le README distingue aussi supported / conditionally supported / inconclusive / rejected.

Voici les résultats les plus marquants.

• Les boucles multiples étaient nettement meilleures que l’inférence en une seule passe.
  Exp02 : 50% → 94.4%
  Exp10 : 1-loop 41.3% → 8-loop ABC 78.1%

• Demander au même modèle « vérifie si tu t’es trompé » a presque complètement échoué.
  Exp03 : 0 erreur détectée sur 15 erreurs injectées

• En revanche, séparer les rôles a fortement amélioré la détection d’erreurs.
  Exp035 : 12 détections sur 15, soit 80%

• Pour les calculs mathématiques, l’effet de l’externalisation par outils était net.
  Dans Exp08 / Exp08b, le fait d’imposer tool call et error hint a permis à certaines tâches de mathématiques de remonter de 0% à 100%.

• Sur les tâches à long contexte, le schéma chunked ABC+Tattoo a nettement surpassé un simple dump.
  En condition Exp09 Large 20K, Solo 0%, RAG 67%, ABC+Tattoo 100%
  En revanche, je n’en conclus pas encore qu’ABC+Tattoo est globalement meilleur que RAG. H9b reste inconclusive.

• Introduire un modèle fort comme Judge a au contraire échoué.
  Dans Exp11, seul le Judge a été remplacé par Gemini 2.5 Flash, mais la condition mixte est sortie en dessous du baseline all-Gemma.
  Le mécanisme observé allait plutôt dans ce sens : « un Judge plus fort n’aide pas le petit modèle dans son processus d’auto-découverte ; il peut au contraire perturber le schéma d’état intermédiaire et la convergence vers la conclusion ».

• À l’inverse, ajouter un rôle d’Extractor en amont a eu un effet positif, certes modeste.
  Exp12 : Δ +0.050
  Une récupération a notamment été observée sur certains cas catastrophiques.

• En revanche, le rôle de Reducer en aval a dégradé les résultats.
  Exp13 : Δ -0.053
  On a observé une abstraction loss : en « nettoyant » la réponse finale, la structure de justification se trouvait compressée, ce qui faisait baisser le score.

Mon interprétation actuelle est donc la suivante.

Plutôt que de faire systématiquement arbitrer un petit modèle par un modèle plus puissant, il se peut que l’emplacement des rôles, même avec le même modèle, soit plus important.

En particulier, l’ajout de rôles en pre-stage s’est révélé relativement sûr, tandis que la synthèse / mise en forme en post-stage était risquée.

J’ai aussi indiqué clairement ce que ce projet ne prétend pas démontrer à ce stade.

• il ne prétend pas qu’un modèle 4B remplace les grands modèles
• il ne prétend pas qu’ABC+Tattoo est toujours meilleur que RAG
• ce n’est ni une nouvelle architecture ni une nouvelle méthode d’entraînement
• il ne prétend pas que des tests statistiques de niveau article scientifique soient terminés
• pour une partie des Related work, la bibliographic verification n’est pas encore terminée

À ce stade, cela ressemble davantage à des « notes d’expérimentation publiques ».

Les expérimentations menées seul produisent facilement des illusions d’optique. En particulier, sur ce genre d’expériences structurelles, les résultats peuvent facilement fluctuer selon le taskset, le scorer, le prompt ou les conditions de boucle.

C’est pourquoi j’ai préféré publier avant d’en faire un polished paper.

Le type de retours que j’aimerais recevoir va globalement dans ces directions.

• vérifier si cela se reproduit sur d’autres modèles locaux
• vérifier si le taskset / scorer n’est pas biaisé
• vérifier si le baseline RAG est suffisamment équitable
• vérifier si ABC+Tattoo présente réellement d’autres modes d’échec
• vérifier si l’ajout de Search Tool / Graph Tool / Evidence Tool rend l’effet de l’axe Tools plus net

La prochaine expérience candidate est Exp14 Search Tool.

Si cela vous intéresse, vous pouvez regarder le README ou la section docs/reference.

Les contre-exemples, échecs de reproduction et critiques sont tous les bienvenus.