In-Memory Layers: LLM-Context-Window clever umgehen

Ein praktisches Architektur-Problem bei LLM-Agenten: Große Datenmengen durch Tool-Calls schleifen. Allan Bogh von RidgeText dokumentiert eine elegante Lösung für seinen SMS-basierten Kartendienst.

Das Problem

Wenn Nutzer per SMS eine Karte mit Feuer-Perimetern und Wanderwegen anfordern, liegen die Geodaten als GeoJSON vor – typischerweise 50-500 KB pro Anfrage. Das entspricht ~125.000 Tokens bei einem Token ≈ 4 Bytes. Das sprengt die meisten Context-Windows oder macht jeden Call teuer.

Die naive Implementierung:

LLM ruft get_wildfire_data() → erhält 2000 Feuer-Polygone als GeoJSON
LLM ruft render_map(geojson: ...) → reicht GeoJSON weiter

Das LLM wird zur “Daten-Pipe” – es kann das GeoJSON nicht vereinfachen, nicht validieren, zahlt aber die vollen Context-Kosten.

Das Layer-First Pattern

RidgeText nutzt ein Mapbox-inspiriertes Kompositions-Modell:

LLM ruft retrieve_wildfire_layer(location: "Cascades")
→ { status: "queued", layerId: "wildfires-0", featureCount: 847 }

LLM ruft retrieve_trail_layer(trailName: "PCT Section J")
→ { status: "queued", layerId: "trail-1", featureCount: 1 }

LLM ruft generate_map()
→ { mapUrl: "https://storage.../map-abc123.jpg" }

Key Insight: Das LLM sieht nur die 50-Byte-Acknowledgments. Das GeoJSON lebt serverseitig in einem Layer-Queue (Map<SessionID, MapLayer[]> mit 30-min TTL) bis generate_map die Layer kompostiert.

Warum das funktioniert

• Context-Window bleibt winzig: Statt 125K Token nur ~100 Token für 3 Tool-Calls
• Layer-Reihenfolge via Call-Sequenz: Das LLM kontrolliert implizit die Z-Reihenfolge durch die Reihenfolge der Tool-Calls
• Mapbox-kompatibel: Die Layer-Deskriptoren folgen Mapbox-Format – später könnte ein headless Mapbox GL JS Renderer eingewechselt werden

Das Pattern ist generalisierbar: Immer wenn ein LLM große Datenmengen orchestrieren soll, die es nicht selbst verarbeiten muss – Queue serverseitig, return tiny handles.

Originalartikel