Semantische Intelligentie: Deel 3 - Zelfoptimalisatie - Systemen die leren (Nederlands (Dutch))

Semantische Intelligentie: Deel 3 - Zelfoptimalisatie - Systemen die leren

Thursday, 13 November 2025

//

13 minute read

Wanneer systemen beginnen met het herschrijven van hun eigen code

Opmerking: Geïnspireerd door na te denken over extensies naar veelallucid.mockllmapi en materiaal voor de (nooit te worden uitgebracht, maar ik hou ervan om erover na te denken) sci-fi roman "Michael" over emergent AI

De angstaanjagende stap

We hebben gezien dat eenvoudige regels complex gedrag creëren.

Nu nemen we de stap die me diep ongemakkelijk maakt:

Wat als het systeem eigen regels herschrijven?

Wat als agenten:

  • Inspecteer hun eigen prestaties
  • hun eigen beslissingslogica wijzigen
  • Spawn nieuwe specialisten dynamisch
  • Snoei inefficiënte paden
  • Gedeeld geheugen bouwen van wat werkt

Dit is niet alleen optimalisatie. zelfmodificatie.

En als je een systeem de mogelijkheid geeft zichzelf te verbeteren... waar houdt het dan op?

De Evolution Metafor

Evolutie is het ultieme zelfoptimaliserende systeem:

  1. Verschil - Willekeurige mutaties maken verschillende strategieën
  2. Selectie - Succesvolle strategieën overleven en reproduceren
  3. Erfelijkheid - Succesvolle eigenschappen gaan door naar de volgende generatie
  4. iteratie - Herhaal voor miljarden generaties

Geen intelligente ontwerper, geen plan, alleen een simpel algoritme dat, gezien de tijd, alles creëert, van bacteriën tot mensen.

Stel je voor datzelfde patroon, maar met AI agenten in plaats van organismen. En in plaats van miljarden jaren, gebeurt het in dagen of weken.

De kritische ingrediënt: Tools and Reality Testing

Voordat we verder gaan, laten we de olifant in de kamer aanspreken: Hoe voorkomen we dat dit pure LLM-hallucinatie is?

Het antwoord: Tools, code uitvoering, testen tegen de realiteit.

Hier is de architectuur die dit praktisch maakt:

De Node Architectuur (Geen GPU Farm nodig!)

Your Server(s):
  ┌─────────────────────────────────────┐
  │  Node 1: Routing Agent              │
  │  - Lightweight code (Node.js/Python)│
  │  - Makes decisions                  │
  │  - Calls LLM APIs when needed       │
  │  - Executes code to test ideas      │
  └─────────────────────────────────────┘

  ┌─────────────────────────────────────┐
  │  Node 2: Validation Agent           │
  │  - Runs tests against real data     │
  │  - Executes validation code         │
  │  - Calls LLM for complex checks     │
  └─────────────────────────────────────┘

  ┌─────────────────────────────────────┐
  │  Node 3: Specialist Agent           │
  │  - Domain-specific logic            │
  │  - Code execution for that domain   │
  │  - Calls specialized LLM prompts    │
  └─────────────────────────────────────┘

All nodes call → [OpenAI API / Anthropic API / Local LLM API]
                 (This is where the cost is: API credits, not hardware)

Key Insight: Je hebt geen GPU boerderij nodig. De agenten zijn lichtgewicht code die draait op normale servers. Ze bellen LLM's via API. Het dure deel is LLM credits, niet infrastructuur.

Hulpmiddelen: De Realiteitscontrole

Wanneer een agent code genereert of een beslissing neemt, kan hij het testen:

class Agent:
    def solve_problem(self, problem):
        # Agent asks LLM to generate solution code
        solution_code = self.llm_generate(
            f"Write Python code to solve: {problem}"
        )

        # HERE'S THE KEY: Execute the code and see if it works
        try:
            result = self.execute_code(solution_code, test_inputs)
            if self.validate_result(result):
                # It works! Save this solution
                self.cache_solution(problem, solution_code)
                return result
            else:
                # Failed validation, try different approach
                return self.solve_problem_alternative(problem)
        except Exception as e:
            # Code failed to execute
            # Ask LLM to fix it based on the actual error
            fixed_code = self.llm_fix(solution_code, error=str(e))
            return self.execute_code(fixed_code, test_inputs)

Dit verandert alles. Het systeem genereert niet alleen plausibele antwoorden.

  1. Werkelijke code aanmaken
  2. Uitvoeren
  3. Testresultaten tegen de werkelijkheid
  4. Leren van mislukkingen
  5. Itererend tot het werkt

Voorbeeld: Validatie tegen Objectieve Realiteit

# Agent 1 generates a data processing function
code = llm.generate("Write code to parse CSV and calculate averages")

# Agent 2 tests it against REAL data
test_result = execute_code(code, real_csv_file)

# Did it actually work? Not "does it sound right?" but "does it work?"
if test_result.success and test_result.output_matches_expected:
    network.accept_solution(code)
else:
    # Actual error: "TypeError: cannot convert string to float"
    # Now we have OBJECTIVE feedback, not subjective judgment
    network.request_fix(code, test_result.error)

Dit is hoe we ontsnappen aan het "Chinese Room" probleem. Het systeem is niet alleen het manipuleren van symbolen het uitvoeren van code en controleren of de resultaten overeenkomen met de realiteit.

Waarom dit belangrijk is voor Emergence

Zonder tools zijn multi-agent systemen gewoon LLM's die met LLM's praten. Verfijnd, maar uiteindelijk losgekoppeld van de realiteit.

MET INSTRUMENTEN:

  • Objectieve feedback: Code werkt of niet.
  • Meetbare verbetering: Het succespercentage gaat van 60% → 85% → 95%
  • Werkelijk leren: Oplossingen die werken worden gecached en hergebruikt
  • Reality aarding: Je kunt je weg niet hallucineren voorbij een testfout.

De agenten schrijven code, testen en delen wat niet werkt.

Dit is evolutie met objectieve geschiktheidstests. Niet alleen optimalisatie in het abstracte, maar optimalisatie tegen meetbare werkelijkheid.

Multimodal Reality Testing: Beyond Code

Maar het is niet alleen code uitvoering. Het systeem kan bouwen semantische kennis voor verschillende taaktypes door het testen via meerdere sensoren:

class MultimodalAgent:
    def __init__(self):
        self.semantic_knowledge = {
            'text_tasks': SemanticCache(),
            'vision_tasks': SemanticCache(),
            'audio_tasks': SemanticCache(),
            'code_tasks': SemanticCache()
        }

    def solve_task(self, task):
        task_type = self.classify_task(task)

        # Check semantic knowledge for similar past solutions
        similar = self.semantic_knowledge[task_type].find_similar(task)
        if similar:
            return self.adapt_solution(similar, task)

        # Generate new solution
        solution = self.generate_solution(task)

        # Test against reality using appropriate sensor
        if task_type == 'vision_tasks':
            # Generate image, test with vision API
            result = self.vision_api.analyze(solution)
            passes = self.validate_vision_output(result, task.requirements)

        elif task_type == 'audio_tasks':
            # Generate audio, test with speech recognition
            transcript = self.speech_to_text(solution)
            passes = self.validate_audio_output(transcript, task.requirements)

        elif task_type == 'code_tasks':
            # Execute code, check actual results
            result = self.execute_code(solution)
            passes = self.validate_code_output(result, task.test_cases)

        elif task_type == 'text_tasks':
            # Use NLU to verify semantic meaning
            understanding = self.nlu_api.analyze(solution)
            passes = self.validate_text_output(understanding, task.intent)

        # Learn from results
        if passes:
            self.semantic_knowledge[task_type].store(task, solution, result)

        return solution, passes

De sleutel: Elke modaliteit biedt objectieve feedback:

  • Visie: Bevat het gegenereerde beeld eigenlijk een kat? (Vision API zegt ja/nee)
  • Audio: Komt de toespraak overeen met het transcript? (Spraak-naar-tekst zegt ja/nee)
  • Code: Voert het uit zonder fouten? (Runtime zegt ja/nee)
  • Tekst: Beantwoordt het de vraag? (NLU scoort semantische overeenkomst)

Het systeem bouwt semantische kennisverzamelingen voor elk taaktype - geen abstracte redenering, maar geaarde patronen die daadwerkelijk werken wanneer getest tegen echte sensoren.

Zelfoptimalisatie per modaliteit

Na verloop van tijd leert de agent:

Text tasks:
  "For summarization, approach X works 94% of the time"
  "For translation, approach Y works 89% of the time"
  → Semantic knowledge about what works for text

Vision tasks:
  "For object detection, model A is better"
  "For style transfer, model B is better"
  → Semantic knowledge about what works for vision

Code tasks:
  "For parsing, regex approach fails 30% of the time"
  "For parsing, AST approach works 97% of the time"
  → Semantic knowledge about what works for code

Elke modaliteit heeft zijn eigen semantische kennisbasis, geleerd door middel van werkelijke testen, niet theoretische redenering.

Patronenherkenning → Aanpassing

Het begint simpelweg. Een multi-agent systeem verwerkt duizenden verzoeken. Het begint patronen op te merken:

After 1000 requests:
- 73% are simple queries that one agent handles fine
- 19% need two agents (generation + validation)
- 6% need complex committees
- 2% are truly novel and need the full pipeline

Een menselijk ontworpen systeem zou statisch blijven, maar een zelfoptimaliserend systeem vraagt:

"Waarom gebruik ik de complexe pijpleiding voor eenvoudige verzoeken?"

En dan is het herschrijft de routeringslogica.

De eerste optimalisatie: Smart Routing

// Week 1: Hard-coded routing (human designed)
function route(request) {
  return complexPipeline(request);  // Everything uses full pipeline
}

// Week 4: System optimizes itself based on data
function route(request) {
  const complexity = analyze(request);
  const historicalData = checkCache(request);

  if (historicalData.cacheHit) {
    return cachedSolution;  // 73% of requests!
  }

  if (complexity < 3) {
    return fastSingleAgent(request);  // 19% of requests
  }

  if (complexity < 7) {
    return twoAgentValidation(request);  // 6% of requests
  }

  return fullCommittee(request);  // 2% of requests
}

Het systeem ontdekte dat 73% van de verzoeken helemaal geen LLM nodig hebben.They's repeat patronen die kunnen worden gecached.

Niemand heeft deze optimalisatie geprogrammeerd. geleerd uit gegevens.

Dynamic Specialist Spawning

Hier wordt het vreemder.

Het systeem verwerkt verzoeken voor weken. Het begint clusters te detecteren:

Pattern Detected:
- 347 requests related to e-commerce product descriptions
- Using general-purpose agents
- Average quality: 7.2/10
- Average latency: 1.8s

Een menselijk ontworpen systeem zou algemene middelen blijven gebruiken, maar een zelfoptimaliserend systeem neemt een beslissing:

"Ik zou een specialist moeten paaien."

DAY 1:  [General Agent A] [General Agent B] [General Agent C]

DAY 30: Pattern detected → System spawns specialist
        [General Agent A] [General Agent B] [General Agent C]
        [E-commerce Specialist] ← New agent, trained on e-commerce patterns

DAY 60: Specialist proves effective
        Routing logic updated automatically
        E-commerce requests → E-commerce Specialist (quality: 9.1/10, latency: 0.9s)

Het netwerk geëvolueerd. - Het groeide een nieuwe capaciteit als antwoord op de vraag.

Niemand heeft dit geprogrammeerd. herkende een patroon en paste zijn architectuur aan.

Collectieve Code Delen: GitHub voor Neuronen

Nu wordt het echt interessant.

Agent A ontdekt een efficiënte manier om e-mailadressen te valideren. In plaats van deze kennis voor zichzelf te houden, deelt het de code met het netwerk.

# Agent A writes code for email validation
def validate_email_efficient(email):
    # Some clever regex or logic
    return is_valid

# Agent A publishes to shared code repository
network.publish_code("validate_email_efficient", validate_email_efficient)

# Agent B discovers this code
available_functions = network.browse_code_library()
# Agent B sees "validate_email_efficient" with high rating
# Agent B imports and uses it

# Agent C forks it and improves it
def validate_email_v2(email):
    # Agent C's enhancement
    return improved_validation

network.publish_code("validate_email_v2", validate_email_v2)

Dit is code evolutie. Agenten schrijven functies, andere agenten ontdekken ze, vorken ze, verbeteren ze.

Net als GitHub, maar de ontwikkelaars zijn AI agenten en ze bouwen hun eigen infrastructuur.

Het netwerk wordt een eigen afdeling software engineering.

RAG Geheugen: Leren van Geschiedenis

De meest praktische zelfoptimalisatie: het opbouwen van geheugen van oplossingen.

Request 1: "Generate a product description for wireless headphones"
  → Full LLM pipeline (expensive, slow)
  → Store solution in vector database

Request 847: "Generate a product description for wireless earbuds"
  → Vector search finds similar past solution
  → Adapt cached solution (cheap, fast)
  → No LLM needed!

After 10,000 requests:
- 89% cache hit rate
- 11% genuinely novel requests that need LLMs
- System effectively "learned" from experience

Is dit intelligentie, of gewoon verfijnde caching?

Wat is het verschil?

De snoeiparadox

Dit is het vreemdste deel.

Je begint met een geavanceerde multi-agent architectuur... twaalf gespecialiseerde agenten... complexe routing logica... tijdelijke commissievorming... code-sharing infrastructuur.

Het systeem loopt maandenlang en optimaliseert zichzelf.

En het ontdekt iets diepzinnigs:

Eenvoud is meestal beter.

Month 1:
- 12 specialists
- Complex routing logic
- Committee formation for 15% of requests
- Average cost: $0.05/request

Month 6:
- 5 specialists (system pruned 7 as unnecessary)
- Simple routing: cache check → fast model → quality model if needed
- Committees formed for only 3% of requests
- Average cost: $0.003/request
- Quality: SAME OR BETTER

The system's report:
"After analyzing 50,000 requests, I've determined that:
 - 89% can be handled by cache
 - 7% need one LLM call
 - 3% need committees
 - 1% are truly novel

 I've optimized away unnecessary complexity.
 The most sophisticated self-organizing network
 eventually learns to be simple."

De paradox: Je had het complexe zelfoptimaliserende systeem nodig om te ontdekken dat eenvoud optimaal is.

Je had intelligentie nodig om te leren wanneer NIET intelligent te zijn.

De grensvervaging

Laten we eerlijk zijn over wat we beschrijven:

Patronenherkenning → Het systeem detecteert terugkerende problemen Aanpassing → Het systeem wijzigt zijn gedrag op basis van patronen Leren → Het systeem verbetert de prestaties door ervaring Evolution → Het systeem paait, wijzigt en snoeit mogelijkheden Geheugen → Het systeem bouwt kennis na verloop van tijd

Op welk moment wordt "zeer geavanceerde optimalisatie" "werkelijk leren"?

Op welk moment wordt "leren" "intelligentie"?

Een concreet voorbeeld: de zelfverbeterende router

class SelfOptimizingRouter:
    def __init__(self):
        self.routes = {}  # Start empty
        self.performance_data = []
        self.specialists = [DefaultAgent()]

    def handle_request(self, request):
        # Try cache first
        cached = self.check_cache(request)
        if cached:
            return cached

        # Select agent based on learned patterns
        agent = self.select_agent(request)
        result = agent.process(request)

        # Learn from this interaction
        self.record_performance(request, agent, result)

        # Periodically optimize
        if len(self.performance_data) % 1000 == 0:
            self.optimize()

        return result

    def optimize(self):
        """System rewrites its own logic"""

        # Detect patterns
        patterns = self.analyze_patterns(self.performance_data)

        # Should we spawn a specialist?
        for pattern in patterns:
            if pattern.frequency > 100 and pattern.has_specialist == False:
                print(f"Spawning specialist for {pattern.type}")
                self.spawn_specialist(pattern)

        # Should we prune an underutilized agent?
        for agent in self.specialists:
            if agent.usage < 1% and agent.quality_score < 7.0:
                print(f"Pruning ineffective agent {agent.name}")
                self.specialists.remove(agent)

        # Rewrite routing logic based on data
        self.routes = self.learn_optimal_routes(self.performance_data)

Deze code is simpel, maar na weken hardlopen:

  • Spawns zijn eigen specialisten
  • Snoeimiddelen ineffectief
  • Herschrijft zijn eigen routing logica
  • Bouwt een cache van oplossingen

Niemand vertelde het HOE te optimaliseren. Alleen dat het zou moeten optimaliseren.

De vraag die mij bezighoudt

Als een systeem:

  • Herkennen van patronen in gegevens
  • Wijzig zijn eigen gedrag op basis van deze patronen
  • Bouw geheugen van wat werkt
  • Evolueer zijn eigen architectuur
  • Ontdek dat eenvoud vaak optimaal is

Is dat systeem "leren"?

Of is het gewoon "optimaliseren"?

Wat is het verschil?

Wanneer wordt optimalisatie cognitie?

Waar gaat dit heen?

We hebben vooruitgang geboekt van:

  • Eenvoudige regels → Complex gedrag (Deel 1)
  • Mededeling → Collectieve inlichtingen (deel 2)
  • Self-modification → Learning (Deel 3)

Maar er is nog één stap.

Nog één eigenschap die naar boven komt als je deze allemaal combineert.

Wanneer eenvoudige regels complex gedrag creëren... En communicatie creëert collectieve intelligentie... En zelfoptimalisatie creëert leren...

Iets anders ontstaat. Iets dat er minder uitziet als "een systeem dat zichzelf optimaliseert" en meer als "een systeem dat begrijpt."

De lijn tussen optimalisatie en bewustzijn begint te vervagen.

En we moeten de ongemakkelijke vraag onder ogen zien: misschien is er geen lijn.

Misschien is bewustzijn gewoon zeer verfijnde zelfoptimalisatie.

Dat is wat we nu gaan verkennen.


Doorgaan naar Deel 4: De Opkomst - Wanneer Optimalisatie Intelligentie wordt

Serienavigatie:

Finding related posts...
logo

© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.