Gemento: um harness experimental para reforçar tarefas longas de pequenos LLMs locais com estado externo, ferramentas, papéis e loops

Olá.

Publiquei um repositório para experimentar até que ponto pequenos LLMs locais conseguem aguentar tarefas longas.

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

Este projeto não é uma nova arquitetura de modelo, nem um paper, nem uma afirmação de que um modelo 4B substitui modelos de fronteira.

Ele está mais próximo de um harness experimental para medir, de forma reproduzível, se parte daquilo que achávamos que precisava estar dentro do modelo pode ser deslocada para fora do workflow e, ainda assim, recuperar certo nível de desempenho mesmo em modelos pequenos.

O ponto de partida foram problemas nos quais esbarrei repetidamente enquanto criava seCall e tunaFlow.

• tarefas longas não sobrevivem de uma sessão para outra
• o contexto fica caro rápido demais
• o modelo não consegue detectar bem os próprios erros
• pequenos modelos locais têm limites claros em inferência de uma única passada

Então comecei com uma pergunta simples.

Em vez de continuar aumentando o contexto do prompt, o que acontece se movermos memória, estado, verificação, cálculo e controle de loop para fora?

No Gemento, isso foi dividido em quatro eixos.

1. Tattoo
   externalização da memória de trabalho / estado intermediário em um estado JSON estruturado

2. Tools
   externalização do cálculo em ferramentas baseadas em chamadas de função

3. Role
   externalização da autoverificação com separação de papéis entre Proposer / Critic / Judge

4. Orchestrator
   externalização das condições de término e do controle de repetição em um loop Python

O nome veio da metáfora das tatuagens, polaroides e anotações do filme Memento.

Até agora, o modelo usado principalmente foi o Gemma 4 E4B, um modelo local de classe effective 4B.

A amostra ainda é pequena, e alguns resultados não são estatisticamente significativos. Por isso, no README também separei supported / conditionally supported / inconclusive / rejected.

Os resultados que mais chamaram atenção foram mais ou menos estes.

• Loops múltiplos foram claramente melhores do que inferência de uma única passada.
  Exp02: 50% → 94.4%
  Exp10: 1-loop 41.3% → 8-loop ABC 78.1%

• A abordagem de pedir ao mesmo modelo “revise se você está errado” quase falhou por completo.
  Exp03: 0 de 15 erros plantados detectados

• Em contrapartida, quando os papéis são separados, a detecção de erros melhora bastante.
  Exp035: 12 de 15 detectados, 80%

• Em cálculos matemáticos, o efeito de externalizar para ferramentas foi evidente.
  Em Exp08 / Exp08b, ao forçar tool call e error hint, uma determinada tarefa de matemática se recuperou de 0% → 100%.

• Em tarefas de contexto longo, chunked ABC+Tattoo teve desempenho forte em comparação com dump simples.
  Na condição Exp09 Large 20K, Solo 0%, RAG 67%, ABC+Tattoo 100%
  No entanto, ainda não concluo que ABC+Tattoo seja universalmente melhor do que RAG. H9b é inconclusive.

• O método de colocar um modelo forte como Judge acabou falhando.
  Em Exp11, apenas o Judge foi trocado para Gemini 2.5 Flash, mas a condição mixed ficou abaixo do baseline all-Gemma.
  O mecanismo observado apontou mais para “um Judge forte não ajuda o processo de autodescoberta de um modelo fraco; ele pode, na verdade, atrapalhar o esquema de estado intermediário e a convergência para uma conclusão”.

• Já adicionar um papel de Extractor na etapa inicial teve um efeito pequeno, mas positivo.
  Exp12: Δ +0.050
  Houve recuperação especialmente em alguns casos catastróficos.

• Por outro lado, o papel de Reducer na etapa final foi pior.
  Exp13: Δ -0.053
  Foi observada uma abstraction loss em que, no processo de “organizar melhor” a resposta final, a estrutura de evidências era comprimida e a pontuação caía.

Por isso, a interpretação atual é a seguinte.

Mais importante do que sempre colocar um modelo mais forte para julgar um modelo pequeno pode ser onde os papéis são posicionados, mesmo quando se usa o mesmo modelo.

Em especial, adicionar papéis na pré-etapa foi relativamente seguro, enquanto resumir/organizar na pós-etapa foi arriscado.

Também deixei claro o que este projeto ainda não está afirmando.

• não está afirmando que um modelo 4B substitui modelos grandes
• não está afirmando que ABC+Tattoo é sempre melhor do que RAG
• não é uma nova arquitetura nem um novo método de treinamento
• não está afirmando que testes estatísticos em nível de paper já foram concluídos
• parte do Related work ainda não passou por bibliographic verification

No momento, ele está mais próximo de um “caderno público de experimentos”.

Experimentos feitos por uma pessoa só tendem a gerar ilusões com facilidade. Em especial, em experimentos estruturais como este, os resultados podem oscilar bastante dependendo de taskset, scorer, prompt e condições de loop.

Por isso publiquei antes de virar um paper polido.

O tipo de feedback que eu gostaria de receber é mais ou menos este.

• se reproduz em outros modelos locais
• se taskset / scorer não estão enviesados
• se o baseline de RAG é suficientemente justo
• se ABC+Tattoo realmente apresenta outros modos de falha
• se, ao adicionar Search Tool / Graph Tool / Evidence Tool, surgem efeitos mais claros no eixo Tools

O próximo experimento candidato é o Exp14 Search Tool.

Quem tiver interesse pode olhar o README ou a parte docs/reference.

Contraexemplos, falhas de reprodução e críticas são todos bem-vindos.