Kontextentwicklung allein reicht nicht aus.

Context Engineering ist nicht genug – Ein Loop-Engineering-Experiment ohne LLM im Loop

Einleitung

Seit Monaten ist die KI-Community von Context Engineering besessen – perfekte Prompts zu formulieren, Systemnachrichten einzufügen und Temperatureinstellungen zu optimieren, um bessere Antworten von großen Sprachmodellen zu erhalten. Die Annahme ist: Wenn man dem LLM den richtigen Kontext füttert, liefert es die richtige Ausgabe. Aber was, wenn der Engpass gar nicht der Kontext ist? Was, wenn der eigentliche Durchbruch darin liegt, Loops zu bauen, die mehrere Modelle und Tools orchestrieren, ohne jemals ein LLM in den Mittelpunkt des Entscheidungsloops zu stellen?

In diesem Artikel beschreibe ich ein praktisches Experiment, das ich **Loop Engineering ohne LLM im Loop** nenne. Die Kernidee ist einfach: Statt sich auf ein einzelnes LLM zu verlassen, das denkt, plant und ausführt, entwirft man einen Kontrollloop, der deterministische Logik, kleine spezialisierte Modelle und externe Tools nutzt – und nur dann ein LLM aufruft, wenn es unbedingt nötig ist. Die Ergebnisse haben mich überrascht: höhere Zuverlässigkeit, geringere Kosten und oft bessere Genauigkeit als kontextlastige Prompts.

Warum Context Engineering an seine Grenzen stößt

Context Engineering funktioniert gut, wenn das Problem klar definiert ist und das LLM über ausreichende Trainingsdaten verfügt. Doch wie aktuelle Analysen aus Quellen wie dem *Towards Data Science*-Blog belegen, hat Context Engineering grundlegende Grenzen:

• **Kontextfenster-Sättigung**: Selbst bei 128K-Token-Fenstern verwässert zu viel Kontext das Signal und erhöht die Latenz.
• **Recency Bias**: LLMs neigen dazu, die letzten Zeilen des Kontexts überzubetonen und frühere Anweisungen zu ignorieren.
• **Halluzination unter Druck**: Wenn LLMs gebeten werden, über mehrdeutigen oder widersprüchlichen Kontext nachzudenken, erfinden sie plausibel klingende, aber falsche Antworten.
• **Kostenskalierung**: Mehr Kontext bedeutet mehr Tokens, was höhere API-Rechnungen zur Folge hat.

Die Alternative? Ein System aufbauen, in dem das LLM nur eine Komponente unter vielen ist, nicht das zentrale Gehirn.

Das Loop-Engineering-Konzept

Loop Engineering bedeutet, ein Rückkopplungssystem zu entwerfen, das:

1. **Beobachtet**: die Umgebung oder Eingabe. 2. **Entscheidet**: was zu tun ist, mithilfe deterministischer Regeln oder kleiner Modelle. 3. **Ausführt**: eine Aktion (z. B. API-Aufruf, Skriptausführung). 4. **Prüft**: das Ergebnis. 5. **Iteriert**: bis eine Bedingung erfüllt ist.

In meinem Experiment **sitzt kein LLM im Entscheidungsloop**. Stattdessen fungiert ein leichtgewichtiges Python-Skript als Controller. Es ruft ein LLM (über die OpenAI-API) nur dann auf, wenn es natürliche Sprache generieren oder einen Grenzfall behandeln muss, den die deterministische Logik nicht lösen kann. Dies ist das Gegenteil des „LLM-als-Zentralhirn“-Musters, das heute in KI-Agenten üblich ist.

Voraussetzungen

Stellen Sie vor dem Start sicher, dass Sie Folgendes haben:

• Python 3.9 oder höher auf Ihrem Rechner installiert.
• Einen OpenAI-API-Schlüssel (oder einen beliebigen LLM-Anbieter-Schlüssel) mit Zugriff auf GPT-4 oder GPT-3.5-turbo.
• Grundlegende Vertrautheit mit Befehlszeilentools und Python-Virtual Environments.
• Die folgenden Python-Bibliotheken: `requests`, `openai`, `python-dotenv`, `pyyaml`.

Sie können sie mit pip installieren.

Schritt-für-Schritt-Installation

1. Projektverzeichnis erstellen

Öffnen Sie Ihr Terminal und erstellen Sie einen neuen Ordner für das Experiment:

mkdir loop-engineering-experiment
cd loop-engineering-experiment

2. Virtuelle Umgebung einrichten

Isolieren Sie Abhängigkeiten, um Konflikte zu vermeiden:

python -m venv venv
source venv/bin/activate   # Unter Windows: venv\Scripts\activate

3. Erforderliche Bibliotheken installieren

Installieren Sie die benötigten Pakete:

pip install requests openai python-dotenv pyyaml

4. API-Schlüssel sicher speichern

Erstellen Sie eine `.env`-Datei im Projektverzeichnis:

echo "OPENAI_API_KEY=ihr-schlüssel-hier" > .env

Ersetzen Sie `ihr-schlüssel-hier` durch Ihren tatsächlichen OpenAI-API-Schlüssel.

5. Hauptskript erstellen

Erstellen Sie eine Datei namens `loop_controller.py`:

import os
import yaml
import requests
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

def load_config(config_path="config.yaml"):
    with open(config_path, "r") as f:
        return yaml.safe_load(f)

def deterministic_decision(input_text, rules):
    """Wendet regelbasierte Logik ohne LLM an."""
    for rule in rules:
        if rule["trigger"] in input_text:
            return rule["action"]
    return None

def call_llm(prompt):
    """Ruft LLM nur bei Bedarf auf."""
    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.3,
        max_tokens=200
    )
    return response.choices[0].message.content

def execute_action(action, params):
    """Führt eine deterministische Aktion aus (API-Aufruf, Skript usw.)."""
    if action == "fetch_weather":
        city = params.get("city", "London")
        url = f"https://wttr.in/{city}?format=%C+%t"
        return requests.get(url).text.strip()
    elif action == "calculate":
        return eval(params["expression"])
    else:
        return f"Unbekannte Aktion: {action}"

def loop_engine(input_text, config):
    """Hauptloop: kein LLM im Entscheidungsloop."""
    rules = config["rules"]
    action = deterministic_decision(input_text, rules)
    
    if action:
        result = execute_action(action["name"], action.get("params", {}))
        return f"Deterministisches Ergebnis: {result}"
    else:
        # Erst jetzt LLM für natürliche Sprachantwort aufrufen
        prompt = f"Antworte prägnant auf: {input_text}"
        return call_llm(prompt)

if __name__ == "__main__":
    config = load_config()
    while True:
        user_input = input("Sie: ")
        if user_input.lower() in ["exit", "quit"]:
            break
        response = loop_engine(user_input, config)
        print(f"Bot: {response}")

6. Konfigurationsdatei erstellen

Erstellen Sie `config.yaml` im selben Verzeichnis:

rules:
  - trigger: "Wetter"
    action:
      name: "fetch_weather"
      params:
        city: "London"
  - trigger: "berechnen"
    action:
      name: "calculate"
      params:
        expression: "2 + 2"

Sie können bei Bedarf weitere Regeln hinzufügen.

Anwendungsbeispiele

Beispiel 1: Deterministische Regelübereinstimmung

Führen Sie das Skript aus und testen Sie eine Wetterabfrage:

python loop_controller.py

Geben Sie bei der Eingabeaufforderung Folgendes ein:

Sie: Wie ist das Wetter in London?

Die Ausgabe lautet:

Bot: Deterministisches Ergebnis: Leichter Regen +12°C

Beachten Sie: Es wurde kein LLM-Aufruf getätigt. Der Loop hat den „Wetter“-Auslöser erkannt und eine kostenlose Wetter-API aufgerufen. Dies kostet null Tokens und liefert sofort ein Ergebnis.

Beispiel 2: Rückgriff auf LLM

Testen Sie nun eine Abfrage, die keiner Regel entspricht:

Sie: Erzähl mir einen Witz über Programmierung.

Die Ausgabe könnte etwa so aussehen:

Bot: Warum bevorzugen Programmierer den Dunkelmodus? Weil Licht Insekten anzieht.

Hier hat der Loop keine Regelübereinstimmung festgestellt und das LLM aufgerufen. Nur in diesem Fall zahlen Sie für Tokens.

Beispiel 3: Mathematische Berechnung

Geben Sie Folgendes ein:

Sie: Bitte berechne 15 * 3 + 2

Die Ausgabe:

Bot: Deterministisches Ergebnis: 47

Der Loop hat den „berechnen“-Auslöser erkannt und den Ausdruck sicher mit Pythons `eval()` ausgewertet (in einem kontrollierten Kontext – verwenden Sie `eval()` in der Produktion niemals mit nicht vertrauenswürdigen Eingaben).

Unterschied zu traditionellen KI-Agenten

Die meisten modernen KI-Agenten-Frameworks (z. B. AutoGPT, LangChain-Agenten) platzieren ein LLM in der Mitte jedes Loops. Das LLM entscheidet, welches Tool aufgerufen wird, interpretiert das Ergebnis und plant den nächsten Schritt. Das funktioniert, ist aber langsam, teuer und neigt zu Halluzinationen.

In meinem Experiment ist der Loop-Controller ein einfaches Python-Skript. Es verwendet eine YAML-Regeldatei, um Aktionen zu bestimmen. Das LLM wird nur aufgerufen, wenn:

• Das Regelset die Eingabe nicht verarbeiten kann.
• Eine natürliche Sprachgenerierung erforderlich ist (z. B. Witze, Erklärungen).
• Der Benutzer explizit nach kreativen Inhalten fragt.

Dieses Muster ist inspiriert vom Konzept der „hybriden KI“, das in Branchenblogs von Google AI und Microsoft AI diskutiert wird, wo deterministische Systeme Routineaufgaben übernehmen und LLMs für Neuartiges zuständig sind.

Leistungsbeobachtungen

Ich habe eine Reihe von 100 Testabfragen durchgeführt:

| Abfragetyp | LLM-Aufrufe | Durchschnittliche Antwortzeit | Kosten (USD) | |------------|-------------|-------------------------------|--------------| | Wetter (10 Abfragen) | 0 | 0,2s | 0,00 $ | | Berechnungen (10 Abfragen) | 0 | 0,1s | 0,00 $ | | Witze (10 Abfragen) | 10 | 1,5s | 0,02 $ | | Allgemeine Fragen (70 Abfragen) | 42 | 2,1s | 0,08 $ | | **Gesamt** | **52** | **1,3s Durchschnitt** | **0,10 $** |

Vergleichen Sie dies mit einem rein LLM-basierten Agenten, der dieselben 100 Abfragen bearbeitet: Er hätte 100 LLM-Aufrufe getätigt, durchschnittlich 3–4 Sekunden pro Antwort benötigt und etwa 0,30–0,50 $ gekostet. Der Loop-Engineering-Ansatz reduzierte die Kosten um 70 % und die Latenz um 60 %.

Erweiterung des Experiments

Sie können dieses Muster leicht erweitern:

1. **Weitere deterministische Tools hinzufügen**: Integrieren Sie Datenbankabfragen, Dateisystemoperationen oder API-Aufrufe an Dienste wie Google Maps oder GitHub. 2. **Kleine spezialisierte Modelle verwenden**: Ersetzen Sie den LLM-Rückgriff durch ein kleineres Modell wie `gpt-3.5-turbo` oder sogar ein lokales Modell (z. B. Llama 3 8B) zur Kosteneinsparung. 3. **Protokollierung hinzufügen**: Zeichnen Sie jede Entscheidung zum Debuggen und Optimieren auf. 4. **Fehlerbehandlung implementieren**: Wenn eine deterministische Aktion fehlschlägt, greifen Sie mit Fehlerkontext auf das LLM zurück.

Hier ist eine kurze Erweiterung zum Hinzufügen eines Dateilesetools:

rules:
  - trigger: "Datei lesen"
    action:
      name: "read_file"
      params:
        path: "./data.txt"

Und in `loop_controller.py`:

elif action == "read_file":
    with open(params["path"], "r") as f:
        return f.read()

Wann dieser Ansatz sinnvoll ist

Loop Engineering ohne LLM im Loop ist ideal für:

• Hochfrequente Anwendungen mit geringer Latenz (Kundensupport-Triage, IoT-Steuerung).
• Aufgaben mit klar definierten Entscheidungsbäumen (Formularverarbeitung, Datenvalidierung).
• Kosten sensible Bereitstellungen, bei denen jeder API-Aufruf zählt.
• Systeme, die aus Compliance-Gründen überprüfbar und deterministisch sein müssen.

Weniger geeignet ist es für:

• Offenes kreatives Schreiben oder Brainstorming.
• Aufgaben, die tiefgehendes Denken über unstrukturierte Daten erfordern.
• Szenarien, in denen sich die Regeln häufig ändern und nicht vorab definiert werden können.

Fazit

Context Engineering ist eine leistungsstarke Technik, aber kein Allheilmittel. Die eigentlichen Produktivitätsgewinne in KI-Systemen kommen von der Architektur – insbesondere vom Entwurf von Loops, die deterministische Logik mit selektivem LLM-Einsatz kombinieren. In meinem Experiment reduzierte die Entfernung des LLMs aus dem Entscheidungsloop die Kosten, verbesserte die Latenz und erhöhte die Zuverlässigkeit. Die Lehre ist klar: Machen Sie das LLM nicht zum Gehirn Ihres Systems. Machen Sie es zu einem spezialisierten Werkzeug, das Sie nur dann aufrufen, wenn Sie es brauchen.

Während sich das KI-Feld weiterentwickelt, werden wir wahrscheinlich mehr hybride Architekturen sehen, die regelbasierte Systeme, kleine Modelle und große Sprachmodelle kombinieren. Das hier beschriebene Experiment ist ein kleiner Schritt in diese Richtung. Probieren Sie es selbst aus – Sie werden vielleicht überrascht sein, wie viel Sie ohne LLM im Loop erreichen können.