Il mio sistema, DiSE, è un auto-ottimista, auto-assembling, software ingegneria workflow builder grounded. Genera artefatti di codice testabili, li valuta oggettivamente, e li evolve nel tempo senza costante supervisione umana. Ma ecco la cosa: non è stato Voyager che impressionante bot Minecraft dal 2023 ha già fatto questo generando abilità riutilizzabili? E Toolformer non ha già dimostrato che LLM potrebbe imparare a utilizzare strumenti misurando risultati? Se abbiamo già agenti che scrivono i propri strumenti e imparare quando usarli, non abbiamo già risolto il problema degli agenti di auto-miglioramento AI?
Spoiler: No. E capire perché importa se si sta costruendo qualcosa che ha bisogno di funzionare in produzione.
"Sembra Voyager, ma con altri passi."
Se stai seguendo la ricerca di agenti guidati da LLM, probabilmente hai sentito parlare di VoyagerCity name (optional, probably does not need a translation) (Wang et al., 2023) - il sistema che ha insegnato GPT-4 a giocare Minecraft generando codice riutilizzabile "skills" - e Strumentazione (Schick et al., 2023) - che ha insegnato ai LLM a utilizzare strumenti misurando i risultati effettivi. Entrambi sono stati impressionanti, influenti e ampiamente citati.
A prima vista, DiSE (Directed Synthetic Evolution) potrebbe assomigliare Voyager + Toolformer con una nuova mano di vernice. Ma questo è come dire un database di produzione è solo un foglio di calcolo con più passi. La distinzione importa se ti importa scala, costo, e in realtà la spedizione qualcosa.
E' nuovo a DiSE? Check out il mio passo dell'ascensore per il quadro generale, poi esplorare la serie "Cooking with DiSE": Parte 2 sugli apprendistati laureati e Parte 3 sui LLM inaffidabili. Questo post si concentra specificamente su come l'architettura di DiSE differisce da Voyager e Toolformer.
Questo post spiega cosa hanno fatto Voyager e Toolformer, dove hanno raggiunto i limiti, e perché l'approccio architettonico di DiSE risolve problemi che nessuno dei due poteva affrontare da solo.
Due articoli del 2023 hanno cambiato il nostro modo di pensare agli agenti e agli strumenti LLM:
La Voyager ha introdotto un'intuizione cruciale:
I LLM possono generare i propri strumenti riutilizzabili.
Invece di codificare ogni azione in Minecraft, Voyager ha usato GPT-4 per scrivere funzioni al volo. Ogni azione di successo è diventata un'abilità riutilizzabile memorizzata in un database vettoriale. Il prompt era esplicito:
"La vostra funzione sarà riutilizzata per costruire funzioni più complesse. Pertanto, dovreste renderlo generico e riutilizzabile."
Questo era importante. Per la prima volta, un sistema agente trattato la generazione di utensili come ingegneria del software reale La Voyager ha mostrato che gli agenti potevano:
E ha funzionato... piu' o meno... a Minecraft... con GPT-4.
Strumentazione (Schick et al., 2023) ha adottato un approccio diverso. Invece di generare strumenti, ha insegnato LLMs quando chiamare gli strumenti esistenti.
La punta intelligente: Toolformer ha generato i propri dati di allenamento.
Questo creato modelli che lo strumento imparato utilizzare da risultati obiettivi Una API calcolatrice che restituisce la risposta giusta è meglio di una API che non lo fa - nessun giudizio LLM necessario.
DiSE prende visione da entrambi i documenti, ma risolve le loro lacune:
Da Voyager:
Da Toolformer:
La genealogia di DiSE:
Pensate a DiSE come il nipote di ReAct, Reflexion, Toolformer, e Voyager. Ogni antenato ha contribuito qualcosa di cruciale:
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
L'eredità:
Cosa aggiunge DiSE:
Toolformer ha dimostrato di poter addestrare modelli per utilizzare strumenti misurando risultati reali. Voyager ha dimostrato agenti in grado di costruire le proprie librerie strumenti. Reflexion ha dimostrato il lavoro cicli di riflessione. ReAct dimostrato ragionamenti strutturati aiuta.
DiSE chiede: E se combinassimo tutte queste intuizioni, ma lo rendessimo abbastanza economico da funzionare in produzione e abbastanza intelligente da migliorarsi nel tempo?
E sì, c'è un trattino dell'architettura REST di Roy Fielding anche lì dentro - gli strumenti sono risorse statali con URI, metadati e versioni. Ogni strumento è indirizzabile, cacheable e può essere composto con altri. Il registro degli strumenti non è solo un database vettoriale; è un archivio RESTful dove le risorse (strumenti) hanno stato (statistiche di utilizzo, metriche delle prestazioni, cronologia delle versioni) che influenza il modo in cui vengono recuperate ed evolute.
Questo non e' allenamento, non e' una generazione una tantum. evoluzione diretta.
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
Vedi il problema? Ogni decisione - pianificazione, valutazione, debug, composizione - passa attraverso lo stesso modello di frontiera. Quando hai bisogno di brillantezza ad ogni passo, hai bisogno di GPT-4 (o equivalente) ovunque.
Voyager non stava solo usando GPT-4 per la generazione di codice. Si basava su GPT-4 per:
Quando il modello fa tutto, deve essere ogni volta brillante a livello di frontiera.
E' proprio per questo che la Voyager non ha scalato oltre Minecraft, ed e' per questo che mandarla in produzione costerebbe una fortuna.
Facciamo un po' di matematica dei tovaglioli.
Ora aggiungi query di recupero, tentativi di composizione, cicli di debug. Stai cercando facilmente centinaia di dollari per un singolo agente per costruire una libreria di abilità moderata.
Per il confronto, ecco cosa potrebbe costare un approccio a più livelli:
| Task | Voyager (GPT-4) | DiSE (Tiered) | Savings |
|---|---|---|---|
| Triage/routing | $0.05 | $0.001 (Llama 3.1 8B) | 98% |
| Generazione iniziale | $0.05 | $0.02 (codice Qwen 2.5) | 96% |
| Valutazione | $0.05 | $0 (test statici) | 100% |
| Scalatura (10%) | $0.05 | $0.05 (GPT-4o) | 0% |
| Media per attività | $0.20 | $0.016 | 92% |
Quando si chiama solo il modello costoso per problemi veramente difficili, l'economia cambia drammaticamente.
Voyager, Toolformer e Reflexion non erano fallimenti, ma semplicemente colpivano il soffitto tecnico ed economico del loro momento.
Tre vincoli hanno bloccato i progressi nel 2023:
| Limitazione (2023) | Sequenza | Cosa è cambiato (2024) 2025 (2025) |
|---|---|---|
| GPT-4 è stato l'unico motore affidabile di ragionamento | Un modello ha dovuto fare tutto | Tiered model stacks - GPT-4o + Qwen + DeepSeek + Llama |
| I montaggi locali erano deboli o non utilizzati | Il recupero era costoso | BGE / Arctic / MiniLM sulle GPU di consumo |
| Imbragatura di valutazione non strutturata | LLM giudicata LLM | I LLM ora eseguono il codice in modo pulito tramite il componente containerizzato |
Quindi Voyager e Toolformer non potevano evolversi.
Potevano chiamare solo modelli o modelli di fine-tune. Non potevano distribuire la cognizione su un sistema. Non potevano fare pressione sulla selezione.
Hanno risolto il problema. "Possiamo?" Domanda.
DiSE risolve il "Come facciamo a continuare a migliorare?" Domanda.
Non perché sono più intelligente di Wang o Schick - ma perché l'hardware, l'attrezzatura e l'economia finalmente raggiunto.
E' un problema di ingegneria. E l'ingegneria è sempre una questione di tempismo.
L'idea chiave di DiSE è semplice ma profonda:
La struttura sostituisce la brillantezza.
Invece di aspettarsi che un modello faccia tutto alla perfezione, DiSE distribuisce il problema in un sistema di orchestrazione. Non assume modelli "saper codificare." Invece, crea pressione, feedback e memoria così i modelli possono migliorare il codice iterativamente piuttosto che generarlo perfettamente al primo tentativo.
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
La differenza è netta:
| Capability | Voyager | DiSE |
|---|---|---|
| Generazione del codice | GPT-4 | Conduttura multiLLM a livello |
| Valutazione | GPT-4 giudizio | Non-LLM tests, metriche |
| Riutilizzo degli strumenti | Inserti solo | Registro con metadati + tag + statistiche di utilizzo |
| Miglioramento | GPT-4 suggerisce correzioni | Condotti di scalatura e mutazione |
| Memoria | Vettore DB | RAG + clustering + tracking dell'evoluzione |
| Composizione | Piani GPT-4 | Pianificazione del grafico del flusso di lavoro |
| Controllo dei costi | Nessuna | Prioritizzazione + logica di ripiego |
Perche' ogni unità di codice generato è trattata come un manufattoNon e' una risposta rapida.
Non è giudicato da "questo sembra buono?" - è giudicato da:
Un LLM economico (Qwen 2.5 Coder 7B, Llama 3.1 8B) può generare cinque varianti. I test selezionano i migliori. Un modello più forte viene coinvolto solo quando quelli più deboli falliscono.
Nel corso del tempo, il sistema impara quali modelli sono buoni per quali domini. Come ho fatto con il mio implementazione ricerca semantica - non hai bisogno del modello più grande quando hai l'architettura giusta.
Il processo di perfezionamento diventa evolutivo, non autoregressivo.
Diciamo che vuoi che il tuo agente implementi una selezione efficiente.
Avvicinamento Voyager:
Approccio DiSE:
Il modello economico può esplorare lo spazio della soluzione. I test fanno la selezione. Il modello costoso viene coinvolto solo se tutte e 5 le varianti falliscono.
Ho sperimentato con principi simili in sistema RAG del mio blog e caratteristiche di intelligenza semantica. Il modello è coerente:
Usa il modello più grande per le decisioni di architettura, non per l'esecuzione.
Quando ho costruito il Gestore collegamento rotto con la ricerca semantica ripiego, non ho usato GPT-4 per controllare ogni collegamento. Il sistema:
L'intelligenza costosa è nel progetto, non nell'esecuzione.
Ogni sistema pone una domanda diversa:
Toolformer chiede:
Può un LLM imparare quando usare gli strumenti misurando quale strumento chiama realmente aiutare?
La Voyager chiede:
Può un LLM generare un codice riutilizzabile che aiuta nelle attività future?
DiSE chiede:
Un sistema può generare strumenti, valutarli obiettivamente, evolverli sulla base di risultati reali, e fare tutto questo in modo abbastanza efficiente da funzionare in produzione?
Esperto di strumenti dimostrato opere di apprendimento basate sui risultati. Voyager ha dimostrato strumenti generati possono essere riutilizzati. DiSE prova strumenti in grado di evolvere continuamente senza rompere la banca.
Toolformer è tempo di formazione. La Voyager e' flash. DiSE è infrastrutture.
Uno mostra che si può imparare dai risultati. Uno mostra che è possibile generare strumenti. L'altro costruisce macchinari per l'evoluzione continua.
Se state costruendo sistemi alimentati da LLM oggi, l'approccio DiSE suggerisce:
Non generare codice e sperare che funzioni. Scrivere test che definiscono "lavora." Come faccio per le mie Migrazioni del Quadro di Entità Non c'e' bisogno di giudicare l'LLM.
Percorrere semplici compiti per modelli economici. Prenotare modelli costosi per problemi veramente difficili. Il portafoglio vi ringrazierà.
Conservare non solo il codice, ma:
Questo metadati diventa dati di allenamento per la vostra logica di routing.
Non aspettatevi la perfezione al primo tentativo. Generate varianti, provateli, tenete i vincitori, mutate quelli buoni ma non perfetti.
Ecco come mi avvicino allo sviluppo di questo blog - iterate in pubblico, imparare dal traffico reale, migliorare in base all'uso effettivo.
La differenza tra Voyager e DiSE non riguarda solo i costi. cosa succede quando le cose falliscono.
In Voyager, il fallimento significa:
In DiSE, trigger di guasto:
Il sistema ottiene Piu' intelligente di quello che non sa..
Non credo che vedremo puri sistemi di "modello singolo fa tutto" vincere nella produzione. L'economia non funziona, e le modalità di guasto sono troppo opache.
Invece, vedremo sistemi ibridi come DiSE:
Stiamo vedendo questo schema ovunque:
La magia non consiste nell'avere un modello geniale. modello giusto al momento giusto con contesto giusto.
La Voyager era un faro, ha mostrato che gli agenti potevano imparare generando codice.
Il passo successivo non è stato più motivante. Quell'approccio sta raggiungendo i suoi limiti.
Il prossimo passo è evoluzione sintetica diretta:
DiSE non sta cercando di essere piu' intelligente in un colpo solo. Sta cercando di essere migliore sul successivo Spara.
Questa differenza è dove inizia l'evoluzione.
E a differenza dell'evoluzione biologica, non dobbiamo aspettare milioni di anni per vedere i risultati.
Documenti:
Su questo blog:
Strumenti:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.