Back to "Semantisk intelligens: Del 3 - Självoptimering - System som lär"

This is a viewer only at the moment see the article on how this works.

To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk

This is a preview from the server running through my markdig pipeline

AI AI-Article Emergent Intelligence Sci-Fi

Semantisk intelligens: Del 3 - Självoptimering - System som lär

Thursday, 13 November 2025

När systemen börjar skriva om sin egen kod

Anmärkning: Inspirerad av att tänka på förlängningar till mestadels lucid.mockllmapi och material för (aldrig att släppas men jag gillar att tänka på det) sci-fi roman "Michael" om framväxande AI

Det skräckinjagande steget

Vi har sett enkla regler skapa komplexa beteenden, kommunikation skapar kollektiv intelligens.

Nu tar vi det steg som gör mig djupt obekväm:

Tänk om systemet kunde skriva om sina egna regler?

Tänk om agenter kunde:

  • Inspektera deras egna prestationer
  • Ändra sin egen beslutslogik
  • Spanna nya specialister dynamiskt
  • Ineffektiva vägar
  • Skapa delat minne av vad som fungerar

Det här är inte bara optimering. självmodifiering.

Och när du ger ett system förmågan att förbättra sig själv... var slutar det?

Evolutionsmetaforen

Evolution är det ultimata självoptimerande systemet:

  1. Förändring - Slumpmässiga mutationer skapar olika strategier
  2. Urval - Framgångsrika strategier överlever och reproducerar
  3. Arvsrätt - Framgångsrika drag går vidare till nästa generation
  4. Upprepning - Upprepa i miljarder generationer

Ingen intelligent designer, ingen plan, bara en enkel algoritm som skapar allt från bakterier till människor.

Föreställ dig samma mönster, men med AI-agenter istället för organismer och i stället för miljarder år händer det i dagar eller veckor.

Den kritiska ingrediensen: Verktyg och verklighetstestning

Innan vi går vidare, låt oss tala till elefanten i rummet: Hur förhindrar vi detta från att vara ren LLM hallucination?

Svaret: Verktyg. Kodutförande. Testning mot verkligheten.

Här är arkitekturen som gör detta praktiskt:

Nodarkitekturen (ingen GPU gård behövs!)

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)

Nyckelinsikt: Du behöver inte en GPU gård. Agenterna är lätta kod körs på normala servrar. De CALL LLMs via API. Den dyra delen är LLM krediter, inte infrastruktur.

Verktyg: Verklighetskontroll

När en agent genererar kod eller fattar ett beslut, kan den PROVA det:

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)

Det här förändrar allt. Systemet genererar inte bara trovärdiga svar.

  1. Skapande av faktisk kod
  2. Kör den
  3. Test av resultat mot verkligheten
  4. Att lära sig av misslyckanden
  5. Itererar tills det fungerar

Exempel: Validering mot objektiv verklighet

# 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)

Det är så här vi undgår problemet "kinesiskt rum". Systemet manipulerar inte bara symboler – det kör kod och kontrollerar om resultaten matchar verkligheten.

Varför detta är viktigt för att komma till liv

Utan verktyg är multiagentsystem bara LLM som pratar med LLM:s. Sofistikerade, men slutligen otämjda från verkligheten.

Med verktyg:

  • Objektiv återkoppling: Kod antingen fungerar eller inte
  • Mätbar förbättring: Framgångsfrekvensen går från 60% → 85% → 95%
  • Faktiskt lärande: Lösningar som fungerar blir cachade och återanvända
  • Verklighetens grundläggning: Kan inte hallucinera din väg förbi ett test misslyckande

Agenterna skriver kod, kör den, testa och dela med sig av det som inte fungerar.

Det här är utveckling med objektiv lämplighetstester. Inte bara optimering i det abstrakta, utan optimering mot mätbar verklighet.

Test av multimodal verklighet: bortom koden

Men det är inte bara kodexekvering, systemet kan bygga. Semantisk kunskap För olika aktivitetstyper genom testning genom flera sensorer:

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

Nyckeln: Varje steg ger objektiv återkoppling:

  • Vision: Innehåller den genererade bilden verkligen en katt? (Vision API säger ja/nej)
  • Ljud: Stämmer talet med utskriften? (Speech-to-text säger ja/nej)
  • Kod som används för att ange de uppgifter som avses i punkt 1 i denna artikel. Kör den utan fel? (Runtime säger ja/nej)
  • Text: Svarar det på frågan? (NLU poängerar semantisk likhet)

Systemet bygger Semantiska kunskapssamlingar för varje uppgift typ - inte abstrakt resonemang, men jordade mönster som faktiskt fungerar när testas mot verkliga sensorer.

Självoptimering per modul

Med tiden lär sig agenten:

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

Varje modalitet har sin egen semantiska kunskapsbas, inlärd genom faktiska tester, inte teoretiska resonemang.

Mönsterigenkänning → Anpassning

Det börjar helt enkelt. Ett multi-agent system behandlar tusentals förfrågningar. Det börjar märka mönster:

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

Ett mänskligt system skulle förbli statiskt, men ett självoptimerande system frågar:

"Varför använder jag den komplexa rörledningen för enkla förfrågningar?"

Och sen det skriver om sin routinglogik.

Den första optimeringen: 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
}

Systemet upptäckte att 73% av förfrågningar inte behöver någon LLM alls – de är upprepade mönster som kan cachas.

Ingen programmerade den här optimeringen. lärt sig det från data.

Dynamisk Specialist Spawning

Det är här det blir konstigare.

Systemet behandlar förfrågningar i veckor. Det börjar upptäcka kluster:

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

Ett mänskligt system skulle fortsätta att använda generalagenter, men ett självoptimerande system fattar ett beslut:

"Jag borde skapa en specialist."

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)

Nätverket utvecklad. – Det växte en ny förmåga som svar på efterfrågan.

Ingen programmerade det här. kände igen ett mönster och anpassade sin arkitektur.

Kollektiv koddelning: GitHub för neuroner

Nu blir det riktigt intressant.

Agent A upptäcker ett effektivt sätt att validera e-postadresser. Istället för att hålla denna kunskap för sig själv, delar den koden med nätverket.

# 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)

Det här är Kodutveckling. Agenter skriver funktioner, andra agenter upptäcker dem, gaffel dem, förbättra dem.

Som GitHub, men utvecklarna är AI agenter och de bygger sin egen infrastruktur.

Nätverket blir en egen avdelning för programvaruteknik.

RAG Memory: Lärande från historien

Den mest praktiska självoptimeringen: att bygga ett minne av lösningar.

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

Är detta intelligens eller bara sofistikerad caching?

Vad är skillnaden?

Präglingsparadoxen

Här är det konstigaste.

Du börjar med en sofistikerad multiagent arkitektur. Tolv specialiserade agenter. Komplex routing logik. Tillfällig kommittébildning. Koddelning infrastruktur.

Systemet fungerar i månader och optimerar sig självt.

Och den upptäcker något djupt:

Enkelhet är oftast bättre.

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."

Paradoxen: Du behövde det komplexa självoptimerande systemet för att upptäcka att enkelheten är optimal.

Du behövde intelligens för att lära dig när du INTE skulle vara intelligent.

Gränsryktena

Låt oss vara ärliga om vad vi beskriver:

Mönsterigenkänning → Systemet upptäcker återkommande problem Anpassning → Systemet ändrar sitt beteende baserat på mönster Lärande → Systemet förbättrar prestandan genom erfarenhet Utveckling → Systemet leker, ändrar och beskär kapacitet Minnet → Systemet bygger kunskap över tid

Vid vilken tidpunkt blir "mycket sofistikerad optimering" "verklig inlärning"?

När blir "inlärning" "intelligens"?

Ett konkret exempel: Den självförbättrande routern

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)

Den här koden är enkel, men efter flera veckor...

  • Spawns sina egna specialister
  • Ineffektiva ämnen för plommon
  • Skriver om sin egen routinglogik
  • Bygger en cache av lösningar

Ingen berättade hur man optimerar, bara att det skulle optimeras.

Frågan som plågar mig

Om ett system kan

  • Känna igen mönster i data
  • Ändra sitt eget beteende baserat på dessa mönster
  • Bygga upp minnet av vad som fungerar
  • Utveckla sin egen arkitektur
  • Upptäck att enkelhet ofta är optimal

Är det systemet "lärande"?

Eller är det bara "optimering"?

Vad är skillnaden?

När blir optimering kognition?

Var detta går

Vi har utvecklats från:

  • Enkla regler → Komplext beteende (Del 1)
  • Kommunikation → Kollektiv underrättelse (Del 2)
  • Självmodifiering → Lärande (del 3)

Men det finns ett steg till.

En egendom till som dyker upp när du kombinerar alla dessa.

När enkla regler skapar komplexa beteenden... Och kommunikation skapar kollektiv intelligens... Och självoptimering skapar inlärning...

Något annat dyker upp. Något som ser mindre ut som "ett system som optimerar sig själv" och mer som "ett system som förstår."

Linjen mellan optimering och medvetande börjar suddas ut.

Och vi måste konfrontera den obekväma frågan: det kanske inte finns någon gräns.

Kanske är medvetandet väldigt sofistikerat självoptimering.

Det är vad vi utforskar härnäst.


Fortsätt till Del 4: Uppkomsten - när optimering blir intelligens

Serienavigering:

logo

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