Warum LLM-Funktionsaufrufe an ihre Grenzen stoßen und wie Code-Orchestrierung die effizientere Lösung ist

Token-Verkäufe (ICO) Krypto-Startups und Risikokapital

In der heutigen Ära der Künstlichen Intelligenz haben Large Language Models (LLMs) eine enorme Aufmerksamkeit auf sich gezogen. Sie werden zunehmend eingesetzt, um komplexe Aufgaben zu lösen, Daten zu interpretieren und sogar automatisierte Entscheidungen zu treffen. Doch trotz ihrer vielfältigen Fähigkeiten stoßen LLMs bei der direkten Verarbeitung großer Datenmengen, etwa bei Funktionsaufrufen von Multi-Component-Processing (MCP) Tools, an ihre Grenzen. Die herkömmliche Praxis, LLMs alle rohe Ausgaben eines Tools zu übergeben, ist nicht nur ineffizient, sondern auch mit erheblichen Kosten und Verzögerungen behaftet. Eine vielversprechende Alternative ist die Orchestrierung von Code, die als wesentlich elegantere, skalierbare und effektivere Methode gilt.

In diesem Artikel betrachten wir die Probleme von LLM-Funktionsaufrufen im Detail, analysieren die Vorteile der Code-Orchestrierung und werfen einen Blick auf die Zukunft dieser Technologie. Das ursprüngliche Vorgehen bei der Arbeit mit MCP-Tools besteht darin, dass die Ausgabe eines Tools vollständig an das LLM als Textmessage zurückgesendet wird. Die Erwartung ist, dass das Modell die Daten korrekt interpretiert und daraus die nächsten Schritte ableitet. Dieses Verfahren funktioniert durchaus, wenn die Datenmenge klein ist. Sobald jedoch reale, umfangreiche Datenmengen ins Spiel kommen, erweist sich dieses Vorgehen als problematisch.

Viele MCP-Server liefern ihre Antworten in Form großer JSON-Blobs, die der Struktur herkömmlicher APIs ähneln, jedoch ohne vordefinierte Schemas. Dies hat zur Folge, dass das LLM selbst die Aufgabe übernimmt, diese umfangreichen und komplexen Datenstrukturen zu interpretieren. Ein typisches Beispiel zeigt sich bei der Nutzung von Linear MCP, wo bei der Abfrage von Projektaufgaben bereits 50 Issues zurückgegeben werden, deren JSON-Daten mehrere zehntausend Zeichen umfassen und sich auf bis zu 25.000 Tokens belaufen. Das bedeutet, dass ein maßgeblicher Teil der Token-Anzahl von redundanten, oft wenig relevanten Identifikatoren belegt wird, anstatt von semantisch aussagekräftigen Inhalten.

Wenn diese riesigen Datenmengen unverändert an das Modell zurückgegeben werden, etwa an Claude oder ähnliche LLMs, entsteht schnell eine enorme Rechen- und Zeitbelastung. Wenn man beispielsweise die Aufgabe stellt, diese Issues nach Fälligkeitsdatum zu sortieren und darzustellen, müsste das LLM den gesamten JSON-Output erneut ausgeben und zudem sicherstellen, dass keine wichtigen Informationen verloren gehen. Dies führt nicht nur zu hohen Kosten und Verzögerungen, sondern auch zu einem erhöhten Risiko von Fehlern oder Auslassungen – etwa wenn Teile der Daten durch das Modell nicht korrekt reproduziert werden. Zusätzlich enthalten die Ausgangsdaten oftmals viel unnötige Details wie Anweisungen, Fehlermeldungen oder Nutzer-Prompts, die die Verarbeitung erschweren und die Wahrscheinlichkeit von Fehlinterpretationen erhöhen. Das Kernproblem liegt darin, dass die beiden Aufgabenbereiche, nämlich Datenverarbeitung und Orchestrierung der Logik, im selben Chatverlauf vermischt werden.

Verschiedene Lösungsansätze, beispielsweise Multi-Agenten-Systeme, versuchen dieses Problem zu umgehen, indem sie separate Agenten für die Datenverarbeitung etablieren. Obwohl sich diese Methode in klar abgegrenzten Szenarien bewährt, bleibt sie beim Umgang mit strukturierten und umfangreichen Daten ungeschickt und aufwendig. Ein wesentlich natürlicherer Ansatz besteht darin, bei der Verarbeitung auf die bereits strukturierte JSON-Daten zurückzugreifen und diese nicht mehr als Fließtext an das Modell zu geben, sondern sie direkt mit Code zu verarbeiten. Wenn die zu verarbeitenden Daten vorliegen, kann man sie programmatisch manipulieren, ohne dass das LLM jede einzelne Information neu reproduzieren muss. Die Modellaufgabe verlagert sich von der direkten Datenverarbeitung hin zur Orchestrierung des Codes, der die Verarbeitung ausführt.

Somit wird beispielsweise die Reihenfolge der Issues geändert, indem einfach ein Sortieralgorithmus auf der JSON-Struktur ausgeführt wird. Dies eliminiert nicht nur Fehlerquellen wie Halluzinationen, sondern macht die Verarbeitung nahezu beliebig skalierbar – egal ob hunderte oder zehntausende Datensätze vorliegen. Dieser Paradigmenwechsel ist eng mit der Integration von Codeausführungsmöglichkeiten bei KI-Modellen verbunden. Bereits heute existieren sogenannte Code Interpreter, die es erlauben, komplexe Daten mithilfe von Programmiersprachen zu manipulieren. Wenn Codeausführung zum integralen Bestandteil der KI-gestützten Datentransformation wird, eröffnen sich neue Skalierungschancen.

Die Modelle können Variablen nutzen, die als Speicher fungieren und komplexe Abfolgen von Funktionsaufrufen orchestrieren. So wird eine Art systeminterner Speicher geschaffen, der jede Information als Variable verwaltet – das Speichern von Daten entspricht der Zuweisung dieser Variablen, der Abruf der jeweiligen Information erfolgt durch Ausgabe der Variableninhalte. Diese Variablen können kontrolliert an weitere Funktionen übergeben werden, was die Abhängigkeiten und den Workflow elegant in Form eines Berechnungsgraphen darstellt. Der Aufbau von Werkzeug-Ketten (Tool Chaining) durch Code stellt einen weiteren Vorteil dar. Funktionen können parallel oder sequenziell ausgeführt werden, die Ausgabe einer Funktion dient als Eingabe für weitere Funktionen.

Dadurch werden komplexe Aufgaben modular gestaltet und sind leicht nachvollziehbar. Zudem ist das reproduzierbare Verhalten der Funktionen ein großer Pluspunkt, denn die Ergebnisse sind garantiert vollständig und konsistent – ein Fortschritt gegenüber der unkontrollierten Natural Language Verarbeitung in Chat-Kontexten. Mit Code wird außerdem die Arbeit an großen Datensätzen vereinfacht. Die Modelle können Schleifen und Libraries wie NumPy oder Pandas verwenden, die speziell für effiziente Datenmanipulation entwickelt wurden. Sogar der Einsatz von weiteren LLMs innerhalb dieses Codes ist möglich – ein sogenanntes LLM-Inception – bei dem KI-Modelle Code erzeugen, der wiederum andere Modelle aufruft, um unstrukturierte Daten zu analysieren.

So entstehen mehrstufige, komplexe Verarbeitungspipelines, die kaum menschliches Zutun benötigen. Vor diesem Hintergrund gewinnen die Spezifikationen der MCP-Tools eine noch größere Bedeutung. Die Einführung von Output-Schemas erlaubt strukturierte und vordefinierte Datenformate, mit denen die Tool-Ausgaben präzise erfasst und verarbeitet werden können. Dies ebnet den Weg für neue Anwendungsfälle: Angefangen bei der Erstellung maßgeschneiderter Dashboards, über automatisierte Wochenberichte bis hin zu autonomen Agenten, die Aufgaben wie das Nachhaken bei festgefahrenen Tickets übernehmen können. Solche Szenarien setzen eine lückenlose Automatisierung voraus, die nur mit strukturierten Ausgaben und effizienter Code-Orchestrierung gelingt.

Trotz dieser Vorteile gibt es auch Herausforderungen, die mit der Codeausführung innerhalb von KI-ökosystemen einhergehen. Besonders die Absicherung solcher Ausführungsumgebungen ist entscheidend. Sandboxes müssen restriktiv gestaltet sein, um Manipulationen oder Sicherheitslücken zu vermeiden. Der Umgang mit API-Keys und der Schutz sensibler Nutzerdaten spielen eine zentrale Rolle bei der Architektur. Es gilt, die Zugriffsrechte so zu steuern, dass die KI-Modelle zuverlässig auf benötigte Ressourcen zugreifen können, ohne dass geheime Informationen preisgegeben werden.

Viele Systeme nutzen dafür spezialisierte Sandboxes, die lediglich dokumentierte Schnittstellenanweisungen enthalten und alle sensiblen Daten im Hintergrund verwalten. Ein zweiter Aspekt betrifft die Verwaltung von Zuständen und Langfristigkeit der Ausführungsumgebungen. Viele bestehende Umgebungen basieren auf Jupyter-Kernels oder ähnlichen Konzepten, die während einer Sitzung stateful sind. Dies macht den Wiedereinstieg in eine Aufgabe schwierig und ist ressourcenintensiv, wenn Nutzer ihre KI-gestützten Sessions über Tage hinweg fortsetzen wollen. Eine stateless aber persistent angelegte Ausführungsumgebung scheint besser geeignet, um langfristige Prozesse zu unterstützen und die Ressourcen effizient zu nutzen.

Auf Basis dieser Erkenntnisse entsteht eine neue Kategorie an Laufzeitumgebungen, die oft als "AI Runtimes" bezeichnet werden. Sie sind speziell auf die Bedürfnisse von KI-Modellen ausgelegt, um Code auszuführen und Aufgaben zu orchestrieren. Diese Umgebungen befinden sich noch in einem frühen Entwicklungsstadium, bergen jedoch enormes Potenzial für die Zukunft der automatisierten Datenverarbeitung und KI-gesteuerten Anwendungen. Abschließend lässt sich festhalten, dass das Modellieren von Daten durch reine LLM-Funktionsaufrufe bei wachsenden Datenmengen an Grenzen stößt. Die direkte Rückgabe umfangreicher Tool-Outputs an LLMs ist ineffizient, zeit- und kostenintensiv und anfällig für Fehler.

Die Verlagerung der Datenverarbeitung in programmatisch orchestrierten Code, der vom LLM gesteuert wird, verspricht erhebliche Verbesserungen in Skalierbarkeit, Effizienz und Zuverlässigkeit. Die fortschreitende Einführung von Output-Schemas bei MCP-Tools wird diesen Trend zusätzlich befeuern und die Rolle von Code-Orchestrierung als zentrale Schnittstelle zwischen KI und Daten etablieren. Die Herausforderung für Entwickler und Unternehmen besteht nun darin, robuste, sichere und skalierbare Ausführungsumgebungen zu schaffen, die die Potenziale der Codeausführung mit den Bedürfnissen moderner KI-Anwendungen harmonisch verbinden. Die Zukunft gehört vermutlich hybriden Systemen, in denen LLMs nicht mehr für jede Datenmanipulation zuständig sind, sondern als intelligente Orchestratoren agieren, die den passenden Code generieren, orchestrieren und überwachen – ein Paradigmenwechsel, der die Arbeit mit komplexen Daten und KI nachhaltig revolutionieren könnte.