Gemento: Ein experimentelles Harness, das lange Aufgaben kleiner lokaler LLMs mit externem Zustand, Tools, Rollen und Schleifen verstärkt

Hallo.

Ich habe ein Repository veröffentlicht, mit dem sich experimentell prüfen lässt, wie gut kleine lokale LLMs lange Aufgaben durchhalten können.

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

Dieses Projekt ist weder eine neue Modellarchitektur noch ein Paper, und es behauptet auch nicht, dass ein 4B-Modell Frontier-Modelle ersetzt.

Vielmehr ist es näher an einem experimentellen Harness, mit dem sich in reproduzierbarer Form messen lässt: „Wenn man einige Dinge, von denen wir dachten, sie müssten im Modell selbst stecken, aus dem Workflow herauszieht, lässt sich dann auch bei kleinen Modellen ein gewisses Maß an Leistung wiederherstellen?“

Der Ausgangspunkt waren Probleme, auf die ich beim Erstellen von seCall und tunaFlow immer wieder gestoßen bin.

• Lange Aufgaben überleben keine Sitzung hinweg
• Kontext wird zu schnell zu teuer
• Das Modell erkennt eigene Fehler nicht gut selbst
• Kleine lokale Modelle haben bei einmaliger Inferenz klare Grenzen

Daher begann ich mit einer einfachen Frage.

Was passiert, wenn man statt den Prompt-Kontext immer weiter zu vergrößern, Gedächtnis, Zustand, Verifikation, Berechnung und Schleifensteuerung nach außen verlagert?

In Gemento habe ich das in vier Achsen aufgeteilt.

1. Tattoo
   Arbeitsgedächtnis / Zwischenzustände werden in einen strukturierten JSON-Zustand externalisiert

2. Tools
   Berechnungen werden in funktionsaufrufbasierte Tools externalisiert

3. Role
   Selbstverifikation wird durch die Trennung der Rollen Proposer / Critic / Judge externalisiert

4. Orchestrator
   Abbruchbedingungen und Iterationssteuerung werden in eine Python-Schleife externalisiert

Der Name stammt von den Metaphern Tätowierungen, Polaroids und Notizen aus dem Film Memento.

Das bisher hauptsächlich verwendete Modell ist Gemma 4 E4B, ein effektives lokales Modell der 4B-Klasse.

Bislang ist die Stichprobe noch klein, und einige Ergebnisse sind statistisch nicht signifikant. Deshalb habe ich im README auch zwischen supported / conditionally supported / inconclusive / rejected unterschieden.

Auffällig waren unter anderem die folgenden Ergebnisse.

• Mehrfachschleifen waren klar besser als einmalige Inferenz.
  Exp02: 50% → 94.4%
  Exp10: 1-loop 41.3% → 8-loop ABC 78.1%

• Der Ansatz, demselben Modell zu sagen „Prüfe, ob du falsch liegst“, ist nahezu gescheitert.
  Exp03: 0 von 15 eingebauten Fehlern erkannt

• Trennt man dagegen die Rollen, verbesserte sich die Fehlererkennung deutlich.
  Exp035: 12 von 15 erkannt, 80%

• Bei mathematischen Berechnungen war der Effekt der Tool-Externalisierung eindeutig.
  In Exp08 / Exp08b erholte sich eine bestimmte Mathematikaufgabe von 0% auf 100%, als tool call und error hint erzwungen wurden.

• Bei Aufgaben mit langem Kontext schnitt chunked ABC+Tattoo deutlich besser ab als ein einfacher Dump.
  Unter Exp09 Large 20K lag Solo bei 0%, RAG bei 67%, ABC+Tattoo bei 100%
  Daraus ziehe ich jedoch noch nicht den Schluss, dass ABC+Tattoo allgemein besser ist als RAG. H9b ist inconclusive.

• Die Methode, ein starkes Modell als Judge einzusetzen, ist im Gegenteil gescheitert.
  In Exp11 wurde nur der Judge durch Gemini 2.5 Flash ersetzt, doch die mixed condition lag unter der Baseline mit ausschließlich Gemma.
  Der beobachtete Mechanismus war eher: „Ein starker Judge hilft nicht dem Selbstentdeckungsprozess des schwächeren Modells, sondern kann das Schema des Zwischenzustands und die Konvergenz der Schlussfolgerung stören.“

• Dagegen war das Hinzufügen einer Extractor-Rolle im vorderen Teil ein kleiner, aber positiver Schritt.
  Exp12: Δ +0.050
  Besonders in einigen katastrophalen Fällen war eine Erholung zu sehen.

• Eine Reducer-Rolle im hinteren Teil war dagegen schlechter.
  Exp13: Δ -0.053
  Es wurde ein abstraction loss beobachtet, bei dem die Struktur der Begründung beim „sauberen Aufbereiten“ der finalen Antwort komprimiert wurde und dadurch die Bewertung sank.

Meine derzeitige Interpretation ist daher wie folgt.

Statt kleine Modelle pauschal von stärkeren Modellen beurteilen zu lassen, könnte wichtiger sein, wo man selbst beim gleichen Modell die Rollen platziert.

Insbesondere das Hinzufügen einer Rolle in der Pre-Stage war relativ sicher, während Zusammenfassung/Aufbereitung in der Post-Stage riskant war.

Ich habe auch klar notiert, was dieses Projekt derzeit noch nicht behauptet.

• Keine Behauptung, dass 4B-Modelle große Modelle ersetzen
• Keine Behauptung, dass ABC+Tattoo immer besser ist als RAG
• Keine neue Architektur oder Trainingsmethode
• Keine Behauptung, dass statistische Tests auf Paper-Niveau abgeschlossen sind
• Bei Teilen der Related work ist die bibliografische Verifikation noch nicht abgeschlossen

Im Moment ist es eher ein „öffentliches Experimentiernotizbuch“.

Bei Experimenten, die man allein erstellt, entstehen leicht optische Täuschungen. Gerade bei solchen Strukturexperimenten können Ergebnisse je nach taskset, scorer, prompt und loop-Bedingungen leicht schwanken.

Deshalb habe ich es veröffentlicht, bevor es ein polished paper wurde.

Gewünschtes Feedback geht ungefähr in diese Richtung.

• Ob es sich auf anderen lokalen Modellen reproduzieren lässt
• Ob taskset / scorer nicht verzerrt sind
• Ob die RAG-Baseline ausreichend fair ist
• Ob ABC+Tattoo tatsächlich andere Fehlermodi zeigt
• Ob mit Search Tool / Graph Tool / Evidence Tool auf der Tool-Achse deutlichere Effekte entstehen

Der nächste Kandidat für ein Experiment ist Exp14 Search Tool.

Wer interessiert ist, kann ins README oder in docs/reference schauen.

Gegenbeispiele, Reproduktionsfehler und Kritik sind alle willkommen.