Mein System, DiSE, ist ein selbstoptimierender, selbstkonfektionierender, Software-Engineering-gegründeter Workflow-Builder. Es generiert testbare Code-Artefakte, wertet sie objektiv aus und entwickelt sie im Laufe der Zeit ohne ständige menschliche Aufsicht. Aber hier ist die Sache: Hat die Voyager – dieser beeindruckende Minecraft-Bot aus dem Jahr 2023 – dies bereits getan, indem sie wiederverwendbare Fähigkeiten generiert? Und hat Toolformer nicht bereits bewiesen, dass LLMs lernen können, Werkzeuge durch Messergebnisse zu verwenden? Wenn wir bereits Agenten haben, die ihre eigenen Werkzeuge schreiben und lernen, wann sie zu benutzen, haben wir nicht bereits das Problem selbstverbessernder KI-Agenten gelöst?

Spoiler: Nein.Und verstehen, warum es wichtig ist, wenn man etwas baut, das in der Produktion laufen muss.

Einleitung

"Das klingt nach Voyager, aber mit mehr Schritten."

Wenn Sie LLM-getriebene Agentenforschung verfolgt haben, haben Sie wahrscheinlich von Voyager (Wang et al., 2023) - das System, das GPT-4 gelehrt, Minecraft zu spielen, indem wiederverwendbaren Code "Skills" - und Werkzeugformer (Schick et al., 2023) - die LLMs lehrte, Werkzeuge zu verwenden, indem sie tatsächliche Ergebnisse messen. Beide waren beeindruckend, einflussreich und weithin zitiert.

Auf den ersten Blick könnte DiSE (Directed Synthetic Evolution) wie Voyager + Toolformer mit einem frischen Lack aussehen. Aber das ist, als ob eine Produktionsdatenbank nur eine Tabellenkalkulation mit mehr Schritten ist. Die Unterscheidung ist wichtig, wenn man sich um Maßstab, Kosten und tatsächlich Versand etwas kümmert.

Neu bei DiSE? Auschecken mein Aufzug pitch für das große Bild, dann erkunden Sie die Serie "Cooking with DiSE": Teil 2 über Absolventen-Ausbildungen und Teil 3 über nicht vertrauenswürdige LLM. Dieser Beitrag konzentriert sich speziell darauf, wie sich die Architektur von DiSE von Voyager und Toolformer unterscheidet.

Dieser Beitrag erklärt, was Voyager und Toolformer haben richtig, wo sie stoßen Grenzen, und warum DiSE's architektonische Ansatz löst Probleme, die weder allein zu bewältigen.

Was Voyager und Toolformer gut gemacht haben

Zwei Papiere aus dem Jahr 2023 veränderten, wie wir über LLM Agenten und Werkzeuge denken:

Voyager: Agenten können Werkzeuge generieren

Die Voyager führte einen entscheidenden Einblick ein:

LLMs können ihre eigenen wiederverwendbaren Werkzeuge erzeugen.

Anstatt jede Aktion in Minecraft hart zu kodieren, benutzte die Voyager GPT-4 zum Schreiben von Funktionen auf der Flucht. Jede erfolgreiche Aktion wurde zu einer wiederverwendbaren Fähigkeit, die in einer Vektordatenbank gespeichert wurde. Die Eingabeaufforderung war explizit:

"Ihre Funktion wird wiederverwendet, um komplexere Funktionen zu erstellen. Daher sollten Sie sie generisch und wiederverwendbar machen."

Dies war wichtig. Zum ersten Mal behandelte ein Agentensystem die Werkzeuggenerierung als echte Software-Engineering Die Voyager zeigte, dass Agenten:

• Aufbau einer wachsenden Bibliothek von Fähigkeiten im Laufe der Zeit
• Einfache Fähigkeiten zu komplexen Verhaltensweisen zusammensetzen
• Vermeiden Sie katastrophales Vergessen durch Einbettung-basierte Retrieval

Und es hat funktioniert, irgendwie. In Minecraft. Mit GPT-4.

Toolformer: Agenten können lernen, wann Werkzeuge verwendet werden sollen

Werkzeugformer (Schick et al., 2023) einen anderen Ansatz. Anstatt Werkzeuge zu generieren, lehrte es LLMs wann bestehende Tools aufgerufen werden sollen.

Das clevere Bit: Toolformer generierte eigene Trainingsdaten. Es würde:

1. Einfügen möglicher Werkzeugaufrufe in Text ("vielleicht sollte ich hier einen Rechner verwenden?")
2. Führen Sie diese Werkzeuge aus
3. Behalten Sie die Beispiele, wo Werkzeuge halfen, verwerfen Sie, wo sie nicht
4. Feinabstimmung auf die erfolgreichen Beispiele

Dies erzeugte Modelle, die die Nutzung von Werkzeugen aus objektive Ergebnisse Statt menschlicher Annotation. Eine Rechner-API, die die richtige Antwort zurückgibt, ist besser als eine, die nicht - kein LLM Urteil benötigt.

Wie DiSE beides kombiniert (und weitergeht)

DiSE nimmt Einsichten aus beiden Papieren entgegen, geht aber auf ihre Lücken ein:

Von der Voyager:

• Erzeugen von wiederverwendbaren Code-Artefakten
• Speichern Sie sie für die zukünftige Retrieval
• Aber fügen Sie hinzu: Objektive Testgeschirre, nicht nur "funktioniert es in Minecraft?"
• Aber fügen Sie hinzu: Tiered Modelle anstelle von GPT-4 für alles
• Aber fügen Sie hinzu: Mutation und Evolution, nicht nur Speicher

Von Toolformer:

• Lerne von objektiven Ergebnissen
• Erzeugen von Trainingsdaten automatisch
• Aber hinzufügen: Runtime Evolution, nicht nur Training-Zeit-Lernen
• Aber fügen Sie hinzu: Generieren Sie die Werkzeuge selbst, nicht nur lernen, sie zu nennen
• Aber fügen Sie hinzu: Voller Lebenszyklus - Werkzeuge können verbessert werden, nicht nur verwendet

Die Genealogie von DiSE:

Denken Sie an DiSE als das Enkelkind von ReAct, Reflexion, Toolformer und Voyager. Jeder Vorfahren trug etwas Entscheidendes bei:

graph TB
    ReAct[ReAct 2022:<br/>Reason + Act<br/>Step-by-step thinking] --> DiSE
    Reflexion[Reflexion 2023:<br/>Self-critique loops<br/>Try → Reflect → Retry] --> DiSE
    Toolformer[Toolformer 2023:<br/>Learn from outcomes<br/>Self-generated training data] --> DiSE
    Voyager[Voyager 2023:<br/>Generate reusable tools<br/>Code as memory] --> DiSE

    DiSE[DiSE 2024:<br/>Directed Synthetic Evolution]

    DiSE --> G[Generate tools with tests]
    DiSE --> E[Evaluate objectively]
    DiSE --> M[Mutate and improve]
    DiSE --> S[Store with usage stats]
    DiSE --> R[Retrieve and reuse]
    DiSE --> C[Tiered execution]

    style ReAct stroke:#8b5cf6,stroke-width:2px
    style Reflexion stroke:#ec4899,stroke-width:2px
    style Toolformer stroke:#f59e0b,stroke-width:2px
    style Voyager stroke:#ef4444,stroke-width:2px
    style DiSE stroke:#10b981,stroke-width:3px

Das Erbe:

• ReAktieren → Strukturierte Argumentation mit Action-Beobachtungsschleifen
• Reflexion → Selbstverbesserung durch Reflexion (aber LLM beurteilt sich selbst)
• Werkzeugformer → Lernen Sie von den tatsächlichen Ergebnissen, nicht nur Aufforderungen
• Voyager → Wiederverwendbare Code-Artefakte erzeugen und speichern

Was DiSE hinzufügt:

• Objektive Testgeschirre (nicht LLM-Selbsteinschätzung)
• Entwicklung der Laufzeit (nicht nur Trainingszeit)
• Tierische Ausführung des Modells (billig → nur bei Bedarf teuer)
• Voller Werkzeuglebenszyklus (Geburt → Mutation → Vererbung → Tod)
• Kostenoptimierungs-Rückkopplungsschleifen
• Stateful Tool Registry (ein bisschen von Fieldings REST Architektur - Werkzeuge als adressierbare Ressourcen mit Zustand)

Toolformer hat bewiesen, dass Sie Modelle trainieren können, um Werkzeuge zu verwenden, indem Sie reale Ergebnisse messen. Voyager hat bewiesen, dass Agenten ihre eigenen Werkzeugbibliotheken bauen konnten.

DiSE fragt: Was wäre, wenn wir all diese Erkenntnisse kombinierten, aber es billig genug machten, um in der Produktion zu laufen und klug genug, um sich im Laufe der Zeit zu verbessern?

Und ja, da ist auch eine Prise von Roy Fieldings REST-Architektur drin - Werkzeuge sind stattliche Ressourcen mit URIs, Metadaten und Versionierung. Jedes Tool ist adressierbar, zwischengespeichert und kann mit anderen zusammengesetzt werden. Die Werkzeugregistrierung ist nicht nur eine Vektordatenbank; es ist ein RESTful-Speicher, in dem Ressourcen (Werkzeuge) Zustand (Nutzungsstatistiken, Leistungskennzahlen, Versionshistorie) haben, der beeinflusst, wie sie abgerufen und entwickelt werden.

Das ist kein Training, das ist keine einmalige Generation. gerichtete Entwicklung.

Die Architektur der Voyager

graph TB
    subgraph Voyager["Voyager (2023)"]
        A[GPT-4] --> B[Generate Code]
        B --> C[Execute in Minecraft]
        C --> D{Success?}
        D -->|Yes| E[Store with embedding]
        D -->|No| F[GPT-4 suggests fix]
        F --> B
        E --> G[Vector DB]
        G --> H[Future retrieval]
        H --> A
    end

    style A stroke:#ef4444,stroke-width:3px
    style F stroke:#ef4444,stroke-width:3px

    note1[All reasoning flows through GPT-4]
    note1 -.-> A

Sehen Sie das Problem? Jede Entscheidung - Planung, Bewertung, Debugging, Zusammensetzung - geht durch das gleiche Grenzmodell. Wenn Sie Brillanz bei jedem Schritt benötigen, benötigen Sie GPT-4 (oder Äquivalent) überall.

Was die Voyager zurückbrachte

Die Voyager benutzte nicht nur GPT-4 für die Codegenerierung, sondern auch GPT-4 für:

• Planung - Durchbrechen von High-Level-Zielen in Teilaufgaben
• Bewertung - Entscheiden, ob eine Fähigkeit richtig funktioniert
• Zersetzung - herauszufinden, welche vorhandenen Fähigkeiten zu kombinieren sind
• Bezeichnung - Erstellen von beschreibenden Identifikatoren für die Speicherung
• Auswahl - Auswahl der richtigen Fähigkeiten aus Einbettungen
• Beurteilung der Qualität - Entscheiden, was "gut genug" ist

Wenn das Modell alles tut, muss es jedes Mal brillant sein.

Genau deshalb hat die Voyager nicht über Minecraft hinaus geskalt, und deshalb würde es ein Vermögen kosten, es in der Produktion zu betreiben.

Das Kostenproblem

Sagen Sie, Sie wollen ein Voyager-System für reale Aufgaben betreiben:

• GPT-4 Turbo: ~$0.01 pro 1K-Eingangstoken, ~$0.03 pro 1K-Ausgangstoken
• Typische Fähigkeitsgenerierung: ~2K-Eingang + 1K-Ausgang = $0,05
• 100 Fähigkeiten mit je 3 Wiederholungsversuchen = ~300 Aufrufe = $15
• Das ist nur der erste Bibliotheksbau

Jetzt fügen Sie Suchanfragen, Kompositionsversuche, Debugging-Zyklen hinzu. Sie suchen leicht Hunderte von Dollar für einen einzelnen Agenten, um eine moderate Geschicklichkeitsbibliothek zu bauen.

Zum Vergleich: Hier ist, was ein gestaffelter Ansatz kosten könnte:

Aufgaben der Voyager (GPT-4) |------|-----------------|---------------|---------| Tria/Routing: 0,05,0,001 $ (Llama 3.1 8B) 98% Ursprüngliche Generation: 0,05,0,002 $ (Qwen 2.5 Coder) 96% Bewertung: 0,05 $0 (statische Tests) 100% (statische Tests) Eskalation (10%)0,05,05,05 (GPT-4o)0,0% | Durchschnitt je Aufgabe | $0.20 | $0.016 | 92% |

Wenn man nur das teure Modell für wirklich harte Probleme nennt, ändert sich die Wirtschaft dramatisch.

Warum DiSE 2023 nicht möglich war (aber jetzt)

Voyager, Toolformer und Reflexion waren keine Ausfälle. Sie trafen einfach die technische und wirtschaftliche Decke ihres Augenblicks.

Drei Einschränkungen blockierten die Fortschritte im Jahr 2023:

Begrenztheit (2023) Begrenztheit (2024–2025) Bezogenheit (2024–2025) Bezogenheit (2024–2025) Bezogenheit (2023) Bezogenheit (2024–2025) Bezogenheit (2024–2025) Bezogenheit (2023) Bezogenheit (2023) Bezogenheit (2023) Bezogenheit (2023) Bezogenheit (2024–2025) Bezogenheit (2024–2025) Bezogenheit (2024–2025) Bezogenheit (2024–2025) Bezogenheit (2023) Bezogenheit (2023) Bezogenheit (2023) Bezogenheit (2023) Bezogenheit (2024–2025) Bezogenheit (2023) Bezogenheit (2024–2025) Bezogenheit (2024–2025) Bezogenheit (2023) Bezogenheit (2023) Bezogenheitigtheit (2024–2025) |-------------------|-------------|--------------------------| GPT-4 war der einzige zuverlässige Argumentationsmotor. Ein Modell musste alles tun. Tiered Modellstacks - GPT-4o + Qwen + DeepSeek + Llama. Die lokalen Einbettungen waren schwach oder ungenutzt.Die Retrieval war teuer. BGE / Arctic / MiniLM auf Verbraucher-GPUs. Kein strukturiertes Bewertungs-Trägersystem. LLM beurteilte LLMs laufen jetzt sauber mit Code über containerisierte exec.

Also konnten sich Voyager und Toolformer nicht weiterentwickeln.

Sie konnten nur Modelle oder Feinabstimmungsmodelle nennen. Sie konnten die Wahrnehmung nicht über ein System verteilen. Sie konnten keinen Selektionsdruck ausüben.

Sie lösten die "Können wir?" Frage.

DiSE löst die "Wie verbessern wir uns weiter?" Frage.

Nicht weil ich klüger bin als Wang oder Schick - sondern weil die Hardware, das Werkzeug und die Ökonomie endlich eingeholt wurden.

Das ist ein technisches Problem. Und Engineering ist immer eine Frage des Timings.

Der Kernunterschied von DiSE

Die Schlüsselidee hinter DiSE ist einfach, aber tiefgründig:

Struktur ersetzt Brillanz.

Anstatt zu erwarten, dass ein Modell alles perfekt macht, verteilt DiSE das Problem über ein Orchestrierungssystem. Es geht nicht davon aus, dass Modelle "Know how to code" sind. Druck, Feedback und Gedächtnis So können Modelle den Code iterativ verbessern, anstatt ihn beim ersten Versuch perfekt zu erzeugen.

DiSE Architektur

graph TB
    subgraph DiSE["DiSE (Distributed System)"]
        A[Triage Agent] -->|Easy| B[Fast Model - Qwen/Llama]
        A -->|Hard| C[Strong Model - GPT-4o]

        B --> D[Test Suite]
        C --> D

        D -->|Pass| E[Structured Registry]
        D -->|Fail| F{Worth escalating?}

        F -->|Yes| G[Optimizer Agent]
        F -->|No| H[Mark as failed]

        G --> I[Mutation Pipeline]
        I --> D

        E --> J[RAG with usage stats]
        J --> K[Clustering & reranking]
        K --> A
    end

    style D stroke:#10b981,stroke-width:3px
    style E stroke:#3b82f6,stroke-width:3px
    style K stroke:#8b5cf6,stroke-width:3px

    note2[Most tasks never hit expensive models]
    note2 -.-> B

Der Unterschied ist stark:

Fähigkeit , Voyager , DiSE , , , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |------------|---------|------| Code-Generierung: GPT-4. Tierierte Multi-LLM-Pipeline Nicht-LLM-Tests, Metriken Werkzeugwiederverwendbarkeit - nur einbetten - Registrierung mit Metadaten + Tags + Nutzungsstatistiken Die Verbesserung von GPT-4 schlägt Korrekturen vor. Eskalations- und Mutationspipelines. Speicher-Vektor DB-RAG + Clustering + Evolutions-Tracking Zusammensetzung, GPT-4-Pläne, Workflow-Graphplanung, Kostenkontrolle Keine Prioritätensetzung + Rückfalllogik

Warum DiSE keine GPT-4 braucht (die meiste Zeit)

Weil jede Einheit des generierten Codes wird als Artefakt behandelt, keine schnelle Antwort.

Es wird nicht danach beurteilt, "es sieht gut aus?" - es wird danach beurteilt:

• Läuft es?
• Löst es die Aufgabe?
• Ist es schneller als vorher?
• Passiert es die Testsuite?

Ein preiswerter LLM (Qwen 2.5 Coder 7B, Llama 3.1 8B) kann fünf Varianten generieren. Tests wählen das Beste aus. Ein stärkeres Modell wird nur dann eingesetzt, wenn schwächere ausfallen.

Im Laufe der Zeit lernt das System, welche Modelle für welche Domains gut sind. semantische Suchimplementierung - Sie brauchen nicht das größte Modell, wenn Sie die richtige Architektur haben.

Der Verfeinerungsprozess wird evolutionär, nicht autoregressiv.

Echtes Beispiel: Algorithmen sortieren

Sagen Sie, Sie wollen, dass Ihr Agent eine effiziente Sortierung implementiert.

Voyager-Ansatz:

1. GPT-4 generiert QuickSort-Implementierung
2. GPT-4 bewertet, ob es "richtig" aussieht
3. GPT-4 läuft es in der Umgebung
4. Wenn es fehlschlägt, schlägt GPT-4 Korrekturen vor
5. Kosten: ~$0,20-0,30 pro Versuch

DiSE-Ansatz:

1. Triage: "Effiziente Sortierung umsetzen" → auf allgemeine Ebene geleitet
2. Qwen 2.5 Coder 7B erzeugt 5 Varianten (QuickSort, MergeSort, HeapSort, Variationen)
3. Test Suite läuft alle 5 gegen:
   • Korrektheitsprüfungen (sortierter Ausgang, Stabilität, Kantenfälle)
   • Leistungsvergleiche (Zeit, Speicher)
   • Statische Analyse (Komplexität, Codequalität)
4. Beste Ausführung Variante geht in die Registrierung mit Metriken
5. Kosten: ~$0.002-0.005
6. Künftige Anfragen nach "Sortierung" holen diese bewährte Umsetzung ab
7. Wenn jemand später "stabile Sortierung" benötigt, kann Optimierer den vorhandenen Code mutieren, anstatt von Grund auf neu zu starten.

Das billige Modell kann den Lösungsraum erkunden. Die Tests führen die Auswahl durch. Das teure Modell wird nur dann einbezogen, wenn alle 5 Varianten fehlschlagen.

Was das in der Praxis bedeutet

Ich habe mit ähnlichen Prinzipien experimentiert. das RAG-System meines Blogs und semantische Intelligenzmerkmale. Das Muster ist konsistent:

Verwenden Sie das größte Modell für Architektur-Entscheidungen, nicht Ausführung.

Als ich die Link-Handler kaputt mit semantischer Suche fallback, Ich habe nicht verwendet GPT-4, um jeden Link zu überprüfen. Das System:

1. Benutzt einfache HEAD-Anfragen, um die Gültigkeit von Links zu überprüfen (kein LLM)
2. Fallt zurück zur semantischen Suche, wenn Links brechen (ONNX-Modell)
3. Nur mit einem LLM verbunden, wenn semantische Suche fehlschlägt (selten erforderlich)

Die teure Intelligenz ist im Design, nicht in der Ausführung.

Die Schlüsselfrage

Jedes System stellt eine andere Frage:

Toolformer fragt:

Kann ein LLM lernen, wann man Werkzeuge benutzt, indem man misst, welches Werkzeug tatsächlich ruft?

Voyager fragt:

Kann ein LLM wiederverwendbaren Code generieren, der bei zukünftigen Aufgaben hilft?

DiSE fragt:

Kann ein System Werkzeuge generieren, sie objektiv bewerten, auf der Grundlage realer Ergebnisse weiterentwickeln und all dies effizient genug ist, um in der Produktion zu laufen?

Werkzeugformer geprüft ergebnisorientierte Lernarbeiten. Die Voyager hat sich bewährt generierte Werkzeuge können wiederverwendet werden. DiSE beweist Werkzeuge können sich kontinuierlich entwickeln, ohne die Bank zu brechen.

Werkzeugformer ist Schulungszeit. Die Voyager ist Blitz. DiSE ist Infrastruktur.

Man zeigt, dass man aus den Ergebnissen lernen kann. Man zeigt, dass Sie Werkzeuge generieren können. Der andere baut Maschinen für die kontinuierliche Evolution.

Praktische Implikationen

Wenn Sie heute LLM-betriebene Systeme bauen, schlägt der DiSE-Ansatz vor:

1. Build Bewertung zuerst

Erzeugen Sie keinen Code und hoffen Sie, dass es funktioniert. Schreiben Sie Tests, die "Arbeiten" definieren. meine Entity Framework Migrationen - die Tests laufen, oder sie nicht. Kein LLM Urteil erforderlich.

2. Verwendung von Tierkörpern aggressiv

Route einfache Aufgaben zu billigen Modellen. Reservieren Sie teure Modelle für wirklich harte Probleme. Ihre Brieftasche wird Ihnen danken.

3. Verfolgen Sie, was funktioniert

Speichern Sie nicht nur den Code, sondern:

• Was es erzeugt wurde für
• Welches Modell es erstellt hat
• Wie gut es funktionierte
• Wie oft es wiederverwendet wird

Diese Metadaten werden zu Trainingsdaten für Ihre Routing-Logik.

4. Umarmung der Evolution

Erwarten Sie nicht Perfektion beim ersten Versuch. Erzeugen Sie Varianten, testen Sie sie, halten Sie die Gewinner, mutieren Sie die gut-aber-nicht-perfekten.

So nähere ich mich der Entwicklung auf diesem Blog - itere in der Öffentlichkeit, aus echtem Verkehr lernen, verbessern auf der Grundlage der tatsächlichen Nutzung.

Warum Struktur mehr zählt, als du denkst

Der Unterschied zwischen Voyager und DiSE geht nicht nur um Kosten. was passiert, wenn die Dinge scheitern.

In der Voyager bedeutet Versagen:

• Fragen Sie GPT-4 zum Debuggen
• Ich hoffe, es versteht das Problem
• Zahlen Sie $0,05 für das Privileg

In DiSE löst ein Fehler aus:

• Strukturierte Fehleranalyse (was fehlgeschlagen ist, warum, was erwartet wurde)
• Unterschiedliche Erzeugung von Arbeitsalternativen
• Eskalation nur, wenn das Problem wirklich neu ist
• Lernen für künftige ähnliche Misserfolge

Das System bekommt Klüger darüber, was es nicht weiß.

Die Zukunft ist hybrid

Ich glaube nicht, dass wir sehen werden, dass reines „Einzelmodell alles tut"-Systeme in der Produktion gewinnen. Die Wirtschaft funktioniert nicht, und die Ausfallmodi sind zu undurchsichtig.

Stattdessen werden wir Hybridsysteme wie DiSE sehen:

• Günstige Modelle für gängige Muster
• Teuere Modelle für neuartige Probleme
• Nicht-LLM-Logik für alles andere (Tests, Metriken, Validierung)
• Speichersysteme, die tatsächlich von Ergebnissen lernen

Wir sehen dieses Muster überall:

• RAG-Systeme Kombination von Retrieval + Erzeugung
• Multi-Agenten-Workflows mit spezialisierten Komponenten
• Semantische Suche Verwendung von Einbettungen + Umranken

Die Magie besteht nicht darin, ein brillantes Modell zu haben. richtiges Modell zur richtigen Zeit mit der Rechter Kontext.

Schlußfolgerung

Die Voyager war ein Leuchtfeuer, das zeigte, dass Agenten durch die Generierung von Code lernen konnten.

Der nächste Schritt war nicht dringender. Dieser Ansatz erreicht seine Grenzen.

Der nächste Schritt ist: gerichtete synthetische Evolution:

• Absichtliche Änderung
• Zielbewertung
• Systematische Erbschaft
• Strukturelles Lernen

DiSE versucht nicht, in einem Schuss schlauer zu sein. Es versucht, besser zu sein auf der Nächster Erschossen.

Dieser Unterschied ist, wo die Evolution beginnt.

Und im Gegensatz zur biologischen Evolution müssen wir nicht Millionen von Jahren warten, um Ergebnisse zu sehen.

Warum DiSE anders ist

• Das muss nicht fein abgestimmt werden. - Funktioniert mit jedem LLM über API
• Braucht nicht GPT-4 für alles - Tierische Ausführung hält die Kosten niedrig
• Läuft nicht halluziniert Bewertung - Objektive Testgeschirre, nicht LLM Urteil
• Er wirft den Code nicht weg. - Jedes Artefakt wird gespeichert, versioniert, verfolgt
• Vergesst nicht die vergangene Arbeit - RAG + Nutzungsstatistik = institutionelles Gedächtnis
• Keine Angst vor Misserfolgen. - Verwendet es als Selektionsdruck für die Evolution

Literaturhinweise

Papiere:

• Voyager: Ein Open End Agent mit großen Sprachmodellen - Das Originalpapier
• ToolFormer - LLMs lehren, Werkzeuge zu benutzen
• ReAktieren - Begründung + Handlungsmuster
• Baum der Gedanken - Beabsichtigte Problemlösung

Auf diesem Blog:

• Aufbau eines RAG-Systems - Hybrid Retrieval + Generationsarchitektur
• Semantische Suche mit ONNX und Qdrant - Einbetten ohne teure APIs
• Der Krieg auf 404 - Tierischer Ansatz zur Linkfixierung
• Verwendung von Ollama für lokale LLMs - Selbst-Hosting kleinere Modelle
• Aufbau einer Anwalts-GPT-Serie - Mehrteilige Reihen zu RAG + LLM

Werkzeuge:

• Ollama - Llama, Qwen und andere Modelle lokal ausführen
• LiteLLM - Unified API für 100+ LLM-Anbieter
• LangChain - Framework für LLM-Apps (obwohl ich eher schwere Frameworks vermeide)