🤖 AI

Evoflux: Inference-Time Evolution of Executable Tool Workflows for Compact Agents

Het artikel introduceert Evoflux, een tijdens de inferentie werkende evolutionaire zoekmethode die de uitvoerbaarheid van tool-workflows voor compacte taalmodellen aanzienlijk verbetert door getypeerde workflow-grafen dynamisch te herstellen en te optimaliseren via gestructureerde bewerkingen en uitvoerfeedback, waarbij het traditionele supervised fine-tuning en reinforcement learning-benaderingen in live tool-omgevingen overtreft.

Oorspronkelijke auteurs: Kushal Raj Bhandari, Ling Yue, Ching-Yun Ko, Dhaval Patel, Shaowu Pan, Pin-Yu Chen, Jianxi Gao

Gepubliceerd 2026-06-12

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Kushal Raj Bhandari, Ling Yue, Ching-Yun Ko, Dhaval Patel, Shaowu Pan, Pin-Yu Chen, Jianxi Gao

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Grote Plaatje: Het "Kleine Chef" Probleem

Stel je voor dat je een zeer kleine, budgetvriendelijke keukenrobot hebt (een compact AI-model). Je wilt dat de robot een complex gerecht bereidt door gebruik te maken van gereedschappen uit een enorme, constant veranderende voorraadkast (een live catalogus van tools).

De robot moet:

De juiste ingrediënten (tools) vinden in de voorraadkast.
Een recept (workflow) volgen dat de stappen correct verbindt.
Daadwerkelijk het eten bereiden (de tools uitvoeren) en het resultaat proeven.

Het Probleem: Kleine robots zijn goedkoop en snel, maar ze zijn "broos". Ze schrijven vaak een recept dat er op papier goed uitziet, maar dat mislukt zodra ze proberen te koken. Misschien pakken ze het verkeerde gereedschap, vergeten ze een ingrediënt door te geven aan de volgende stap, of proberen ze een tool te gebruiken die niet meer bestaat.

Meestal proberen we dit op te lossen door de robot te "onderwijzen" door hem duizenden voorbeelden van perfecte recepten te laten zien (trainingsdata). Maar dit artikel stelt dat wanneer je slechts een enkele honderden voorbeelden hebt (een beperkt budget), het onderwijzen van de robot niet goed werkt. De robot onthoudt dan alleen de vorm van het recept, maar leert niet hoe hij fouten moet herstellen wanneer er in de echte keuken iets misgaat.

De Oplossing: Evoflux (De "Evolutionaire Reparatieploeg")

In plaats van te proberen de hersenen van de robot te hertrainen, geeft Evoflux de robot een "reparatieploeg" die werkt terwijl de robot daadwerkelijk aan het koken is.

Zie Evoflux als een dynamische reparatielus:

De Eerste Poging: De robot schrijft een recept (een workflow graph).
De Proefdraai: Het systeem probeert het recept uit te voeren. Als het breekt (bijv. "Tool niet gevonden" of "Ingrediënt ontbreken"), vangt het systeem de fout op.
De Evolutie: In plaats van op te geven, behandelt het systeem het kapotte recept als een gemuteerd organisme. Het maakt kleine, slimme aanpassingen (bewerkingen) om de specifieke fout te herstellen.
- Pakte het het verkeerde gereedschap? Vervang het.
- Vergat het een ingrediënt? Voeg het toe.
- Vonden de stappen plaats in de verkeerde volgorde? Verander de volgorde.
Survival of the Fittest: Het systeem voert de nieuwe versie uit. Als deze beter werkt, behoudt het deze. Als het faalt, probeert het opnieuw. Dit doet het vele malen in een korte burst, waarbij het recept evolueert totdat het er een heeft gevonden dat het maaltijd daadwerkelijk succesvol bereidt.

Belangrijke Metaforen uit het Papier

De "Plausibele maar Kapotte" Graph: Het papier merkt op dat kleine modellen vaak workflows genereren die lijken op een geldige kaart, maar die tot aan een afgrond leiden. Evoflux kijkt niet alleen naar de kaart; het rijdt de auto om te zien of de weg echt is.
Het Debat "Reparatie" versus "Training":
- Training (SFT/DPO): Is als het proberen uit het hoofd leren van een kookboek. Als het kookboek klein is (weinig voorbeelden), leert de robot de stijl van de recepten, maar faalt hij wanneer de ingrediënten veranderen. Het papier vond dat dit bij een klein budget de robot vaak zelfs slechter maakte dan wanneer hij gewoon zou gokken (zero-shot).
- Evoflux (Zoeken): Is als het hebben van een monteur die de auto repareert terwijl je rijdt. Het verandert de hersenen van de bestuurder niet; het fixt alleen de motor in realtime op basis van de wegcondities.
De "Token Kosten" (Brandstof):
- ReAct (De Oude Manier): Dit is als een robot die heel lang tegen zichzelf praat om de volgende stap te bepalen. Het kan geweldige oplossingen vinden, maar het verbruikt veel brandstof (tokens) en is onvoorspelbaar.
- Evoflux: Dit is efficiënter. Het probeert een paar specifieke reparaties, controleert of ze werken, en stopt. Het behaalt betere resultaten dan training, met minder brandstof dan de langdradige "hardop nadenken"-methode.

Wat het Papier Eigenlijk Heeft Gevonden

De onderzoekers hebben dit getest op een benchmark genaamd MCP-Bench, die gebruikmaakt van echte, live tools (zoals financiële, reis- en wetenschapstools).

Succespercentage: Voor kleine robots was de kans dat een recept bij de eerste poging werkte zeer laag (ongeveer 3%).
De Fix: Met Evoflux steeg het succespercentage naar tussen de 17% en 24%.
Het Falen van Training: Toen ze probeerden de robots te "onderwijzen" met dezelfde enkele honderden voorbeelden die Evoflux gebruikte voor het zoeken, werden de robots niet beter. Sterker nog, ze presteerden vaak slechter dan wanneer ze helemaal niet waren onderwezen.
De Vergelijking: Een methode genaamd ReAct (waarbij de robot stap-voor-stap nadenkt) kon soms hogere scores halen, maar het was erg inconsistent en duur. Evoflux was betrouwbaarder en goedkoper.

De Kernboodschap

Als je een kleine, goedkope AI-agent hebt en een beperkt aantal voorbeelden om het te leren, probeer het dan niet simpelweg te trainen. Laat het in plaats daarvan proberen, falen, en gebruik vervolgens een slim, evolutionair zoekproces om de fouten in realtime te herstellen.

Het papier concludeert dat voor kleine agenten het aanpassen van het plan terwijl je het uitvoert, een veel betrouwbaardere strategie is dan het proberen te memoriseren van een paar voorbeelden van hoe je het moet uitvoeren.

Technische Samenvatting: Evoflux

Probleemstelling

Het paper behandelt de beperkingen van compacte taalmodellen (1,5B–4B parameters) wanneer deze worden ingezet als tool-gebruikende agenten in dynamische, live omgevingen zoals het Model Context Protocol (MCP). Hoewel compacte modellen voordelen bieden op het gebied van kosten, latentie en privacy, zijn ze broos bij het construeren van uitvoerbare workflows. Kleine planners genereren vaak grafen die tekstueel plausibel lijken, maar falen tijdens tool-resolutie, parameter-validatie, afhankelijkheidsverwerking of executie.

De auteurs stellen dat standaard distillatiemethoden (Supervised Fine-Tuning of SFT, en Direct Preference Optimization of DPO) ontoereikend zijn in dit regime. Trainen op een schaars budget aan docent-traces (enkele honderden) leert slechts oppervlakkige workflow-formaten aan, maar slaagt er niet in de herstelgedragingen te vatten die nodig zijn om plannen te repareren wanneer tool-catalogi veranderen of executie faalt. Bovendien vormen de catastrofale vergetelheid (catastrophic forgetting) bij smalle continue instructie-tuning risico's voor compacte modellen. De kernvraag is of rekenkracht moet worden besteed aan gewichtsupdates (training) of aan herstel tijdens de inferentie (zoekproces), gegeven hetzelfde schaarse supervisiebudget.

Methodologie: Evoflux

De auteurs introduceren Evoflux, een procedure voor evolutionair zoeken tijdens de inferentie, ontworpen om compact tool-gebruik te behandelen als een uitvoerbaar workflow-reparatieprobleem in plaats van een one-shot generatietaak.

Kernmechanisme

Evoflux werkt als een begrensde evolutionaire lus waarbij het compacte model fungeert als een proposal-operator binnen een reparatiecyclus, in plaats van een statische generator.

Representatie: Plannen worden gerepresenteerd als getypeerde workflow-grafen die tool-nodes, afhankelijkheidsranden, validator-nodes en terminale outputs bevatten.
Executie-gegronde scoring: Kandidaten worden niet alleen gescoord op syntactische geldigheid. Ze worden gecompileerd, gevalideerd tegen tool-schema's en uitgevoerd in een live omgeving ( $E$ ). Een scalaire score wordt afgeleid van een LLM-judge (MCP-Bench LLMJUDGE) op basis van zes subdimensies: taakvoltooiing, gronding, geschiktheid van de tool, nauwkeurigheid van parameters, bewustzijn van afhankelijkheden, en parallellisme/efficiëntie.
Evolutionaire Lus:
- Initialisatie: De planner probeert een haalbare workflow te genereren met retries, waarbij executiefouten als context worden gebruikt voor opeenvolgende pogingen.
- Mutatie & Bewerking: Het systeem evolueert de populatie van kandidaat-grafen via een eindige, getypeerde bewerkingstaal die veelvoorkomende foutmodi weerspiegelt:
  - Tool Swaps: Het vervangen van niet-beschikbare tools.
  - Parameter Edits: Het corrigeren van schema-fouten of het koppelen van argumenten aan upstream-outputs.
  - Insertie/Verwijdering: Het toevoegen van stappen voor informatieverzameling of het verwijderen van redundante stappen.
  - Herordening: Het corrigeren van afhankelijkheidsstructuren.
- Adaptieve Intensiteit: Een groeistatistiek ( $G$ ) houdt recente voortgang bij. Als de voortgang stagneert, neemt de zoekintensiteit toe, wat meer exploratieve mutaties (willekeurige bewerkingen) triggert en potentieel Meta Guidance inzet.
- Meta Guidance: Wanneer lokale mutatie stagneert, wordt de planner geprompt om een hoog niveau van herontwerp uit te voeren (bijv. het vervangen van een single-server pad door een cross-server workflow) met de huidige beste kandidaat en de zwakste populatieleden als context.
- Diversiteit-pruning: De populatie wordt begrensd ( $K$ ) en gesnoeid met behulp van action-hash binning om instorting tot bijna identieke workflows te voorkomen, terwijl hoog scorende varianten behouden blijven.

Trainingsbaselines

Om de afruil te evalueren, vergelijken de auteurs Evoflux met:

Zero-shot decoding.
Supervised Fine-Tuning (SFT) op zoek-geminede docent-traces.
SFT + Direct Preference Optimization (DPO) met paarwijze voorkeuren uit dezelfde zoekdata.
ReAct: Een baseline voor sequentiële redenering en handelen.

Alle trainingsbaselines maken gebruik van hetzelfde beperkte budget aan zoek-geminede traces om een eerlijke vergelijking tussen gewichtsupdates en inferentie-tijd zoeken te garanderen.

Belangrijkste Resultaten

De evaluatie werd uitgevoerd op helden-taken van MCP-Bench, die 28 live MCP-servers en 250 tools beslaat over diverse domeinen.

Executie-haalbaarheid: Evoflux verbetert de executie-haalbaarheid van kleine planners aanzienlijk. Op helden-taken steeg de haalbaarheid van een baseline van ongeveer 3% naar 17–24% over modellen zoals Llama-3.2-3B, Qwen3.5-4B en SmolLM3-3B.
Falen van Small-Corpus Training: In tegenstelling tot Evoflux boden SFT en SFT+DPO op dezelfde zoek-geminede data geen betrouwbare winst. In verschillende gevallen presteerden getrainde checkpoints gelijk aan of zelfs slechter dan de zero-shot baseline. Opvallend genoeg leed het Qwen3.5-4B model getraind met SSFT+DPO aan een "planning collapse", waarbij het niet in staat was bruikbare plannen te genereren en terugviel op heuristieken, wat resulteerde in een lagere haalbaarheid dan het ongetrainde zero-shot model.
Vergelijking met ReAct: ReAct bereikte een hogere piekprestatie op sterkere planners (bijv. Qwen3.5-4B), maar vertoonde een hogere variantie en aanzienlijk hogere token-kosten door de accumulatie van context in lange trajecten. Evoflux bood stabielere, voorspelbaardere verbeteringen met een lager token-budget.
Token-efficiëntie: Hoewel Evoflux hogere token-kosten met zich meebrengt dan single-pass inferentie (SFT/Zero-shot), is het efficiënter qua tokens dan ReAct. Het zoekproces concentreert kosten in prompt-tokens voor kandidaat-evaluatie, terwijl de kosten van ReAct snel schalen met de lengte van het traject.

Betekenis en Claims

Het paper claimt dat voor compacte agenten die opereren onder een budget van schaarse docent-traces, executie-gegronde zoekopdrachten een betrouwbaardere hefboom zijn voor het verbeteren van prestaties dan gewichtsupdates.

Reparatie boven Imitatie: De resultaten suggereren dat fine-tuning met een kleine corpus vaak leidt tot oppervlakkige imitatie van workflow-vormen zonder de adaptieve reparatieprocessen te internaliseren die nodig zijn voor robuuste executie.
Inference-Time Compute: Het besteden van rekenkracht online om workflows te repareren, te muteren en te valideren tegen live tool-catalogi levert een betere generalisatie naar onbekende taken op dan het proberen te distilleren van die reparatiegedragingen in modelgewichten met beperkte data.
Risicomitigatie: De studie benadrukt een specifiek risico bij de inzet van compacte agenten: trainen op kleine, zoek-geminede datasets kan de prestaties verslechteren (instorten onder zero-shot) in plaats van ze te verbeteren, wat inferentie-tijd evolutie een veiligere en effectievere strategie maakt voor het waarborgen van uitvoerbare betrouwbaarheid.

De auteurs concluderen dat hoewel grootschalige distillatie nog steeds levensvatbaar kan zijn met enorme datasets, het huidige regime van schaarse traces de voorkeur geeft aan evolutionair zoeken tijdens de inferentie voor het construeren van betrouwbare, uitvoerbare tool-workflows.