Warum Einfacheres den Komplexeren in den heutigen AI-Agent-Architekturen übertrifft
Dieser Artikel untersucht drei Argumente aus dem Jahr 2024 gegen Vektordatenbanken, Hypergraph-Memory-Systeme sowie die Komplexität der Orchestrierung und zeigt, dass einfachere Systeme oft bessere Leistungen erbringen als aufwändige Agentenstacks.
Wenn man genügend Inhalte über KI-Agenten aus diesem Jahr liest, zeigt sich bereits vor jedem einzelnen Argument ein Muster. Fast alles, was vorgeschlagen wird, ist additiv: Man fügt eine Speicherschicht hinzu, einen Graphen, ein Orchestrierungsframework sowie einen Abrufprozess mit drei Stufen der Neubewertung. Zudem werden weitere Agenten hinzugefügt, deren Aufgabe es ist, die bereits erstellten Agenten zu überwachen. Im Grunde steht hinter all dem derselbe unausgesprochene Glaube: Dass Komplexität gleichbedeutend mit Fortschritt ist und dass man zurückfällt, wenn das eigene System nicht komplexer ist als noch vor einem halben Jahr.
Ein Team-Building-Agent hat vermutlich bereits Teile derselben Architektur zusammengestellt und damals einige dieser Entscheidungen gerechtfertigt. Als daher in diesem Jahr einige Argumente auftauchten, die das Gegenteil behaupteten – nämlich dass diese aufwändige Erweiterung vermutlich nicht den Aufwand wert war –, verdienten sie mehr Aufmerksamkeit, als es übliche Schlagzeilen wie „Dafür braucht man nichts“ bieten. Die meisten gegensätzlichen Technikartikel sind lediglich umgekehrte Werbetexte, genauso selbstsicher und genauso beweisarm. Diese drei Argumente waren anders. Jedes basiert auf etwas Überprüfbarem: einem Benchmark-Ergebnis, einem strukturellen Argument oder einer klaren Beschreibung davon, wie die Arbeit tatsächlich Tag für Tag abläuft. Das ist der Maßstab, den man hier anwenden sollte – und es ist auch der Maßstab, dem sich der Rest dieses Artikels unterwerfen wird.
Drei Beispiele folgen. In jedem Fall wurde auf eine umfangreichere Architektur zurückgegriffen, obwohl das eigentliche Problem weitaus weniger komplex war.
Fall eins: Ihr Agent benötigt vermutlich keine Vektordatenbank
Die Entscheidung, einen von einem Vektorlagern unterstützten Speicher für Agenten zu verwenden, fällt in der Regel innerhalb von Sekunden. Jemand formuliert die Anforderung: „Der Agent muss sich Dinge zwischen den Sitzungen merken“, und die automatische Reaktion lautet: Die Daten werden eingebettet, gespeichert und anhand der Ähnlichkeit abgerufen. Das ist die Standardlösung – nicht, weil jemand sie gegen Alternativen getestet hat, sondern weil alle Tutorials es so vorgeben.
Diese Annahme wird genau von einem Artikel dieses Jahres, Anubhavs „Your AI Agent Doesn’t Need a Vector Database“, auf die Probe gestellt. Das bemerkenswerte Ergebnis stammt vom LoCoMo-Benchmark: Eine Baseline, die lediglich aus einem Verzeichnis von Textdateien besteht und mit grep durchsucht wird, übertraf mehrere finanzierte, speziell entwickelte Speichersysteme – und zwar genau in dem Benchmark, gegen den diese Systeme gemessen wurden. Es handelte sich dabei nicht um einen manipulierten Vergleich, der dazu diente, bestimmte Ergebnisse zu erzielen. Selbst die anspruchsvolleren Systeme, bei denen Embeddings, Ähnlichkeitssuche und sogar grafisch strukturierter Speicher kombiniert wurden, verloren gegen Lösungen, die bereits an einem Nachmittag erstellt werden konnten.
Sobald dieses Ergebnis verstanden wird, wirkt die Erklärung nicht mehr überraschend. Vektorähnlichkeit ist eine Suchtechnik, keine Schlussfolgerungstechnik. Sie ist hervorragend darin, Texte zutage zu fördern, die semantisch einer Anfrage nahekommen. Bei den Aufgaben, die das Gedächtnis tatsächlich erfordert – wie zum Beispiel zu erkennen, dass eine vor drei Wochen aufgezeichnete Tatsache durch einen gestrigen Update überschrieben wurde, oder dass zwei gespeicherte Einträge sich völlig widersprechen und einer Vorrang haben muss – versagt sie. Ein Vektorindex verfügt weder über ein eingebautes Zeitverständnis noch über ein Konzept der Korrektur. Er gibt einfach das zurück, was im Embedding-Raum am nächsten liegt, und überlässt es dem Modell, selbst herauszufinden, warum zwei der fünf besten Ergebnisse nicht übereinstimmen.
Es gibt ein weiteres Ungleichgewicht, das weniger mit der reinen Fähigkeit zu tun hat und eher mit der Vertrautheit. Sprachmodelle haben enorme Mengen an Trainingsdaten verarbeitet, die sich auf die Arbeit mit Dateien konzentrieren: ihr Lesen, das Durchsuchen mit grep, ihre Bearbeitung, das Auflisten von Verzeichnissen sowie das Nachverfolgen von Importketten. Das ist kein Nebeneffekt, sondern liegt im Kern dessen, was einen großen Teil ihres Trainingskorpus ausmacht. Eine Schleife, die auf grep und dem Lesen von Dateien basiert, nutzt diese bereits vorhandene Geschicklichkeit direkt aus. Im Gegensatz dazu ist die Abfrageschnittstelle einer Vektordatenbank ein Werkzeug, mit dem das Modell innerhalb Ihres spezifischen Kontexts selbst herausfinden muss, wie es effektiv umgeht – ohne die tiefe vorherige Erfahrung mit Dateien. Letztendlich ersetzen Sie eine Fähigkeit, die das Modell bereits besitzt, durch eine, die es erst im Lauf der Zeit erlernen muss, und Sie zahlen dafür die Kosten für Embedding- sowie Abrufverzögerungen.
So könnte die Entscheidung nun grob formuliert werden, nachdem man sie tatsächlich durchdacht hat anstatt sich auf Gewohnheiten zu verlassen:
WHEN A FILESYSTEM + GREP BASELINE IS ENOUGH WHEN YOU ACTUALLY NEED A VECTOR STORE
------------------------------------------------ ------------------------------------------------
Single-agent or small-team memory Retrieval across a corpus too large to
fit or scan in context at all
Facts that change over time and need Cross-document semantic search where
correction, not just accumulation keyword overlap is genuinely weak
Memory the model itself writes, Centralized memory shared by many agents
manages, and re-reads in its own loop that needs access control and auditing
Debuggable state, plain text you can Multi-hop or relational reasoning across
open, diff, and edit by hand thousands of entities where similarity
search is doing real narrowing work
Der in diesem Text beschriebene Schreib-, Verwaltungs- und Lesezyklus sollte konkretisiert werden, denn der Satz „Einfach Dateien verwenden“ klingt zunächst vage, bis er als funktionierender Code dargestellt wird. Hier ist eine Version, die bereits heute ausgeführt werden kann, ohne dass ein gehosteter Dienst erforderlich ist:
import os
import subprocess
from datetime import datetime
MEMORY_DIR = "agent_memory"
def write_memory(topic: str, content: str) -> str:
os.makedirs(MEMORY_DIR, exist_ok=True)
path = os.path.join(MEMORY_DIR, f"{topic}.md")
timestamp = datetime.utcnow().isoformat()
with open(path, "a", encoding="utf-8") as f:
f.write(f"\n## {timestamp}\n{content}\n")
return path
def recall(query: str) -> str:
# ripgrep if you have it, grep -r works fine too
result = subprocess.run(
["rg", "-i", "-C", "2", query, MEMORY_DIR],
capture_output=True, text=True
)
return result.stdout or "no matches"
def list_topics() -> list[str]:
if not os.path.isdir(MEMORY_DIR):
return []
return [f[:-3] for f in os.listdir(MEMORY_DIR) if f.endswith(".md")]
Vernetzen Sie diese drei Funktionen als Werkzeuge, lassen Sie das Modell selbst entscheiden, wann eine Notiz geschrieben werden soll, wann gesucht werden muss und wann ein ganzes Thema-Datei in den Kontext geladen werden kann, da sie kurz genug ist, um hineinzupassen. Das Ergebnis ist ein Speichersystem ohne jegliche Einbettungskosten, ohne Vector-Datenbank, die gehostet oder bezahlt werden muss, und dessen Zustand direkt in einem Texteditor geöffnet werden kann, falls etwas schiefgeht. Wenn diese Konfiguration irgendwann nicht mehr ausreicht, wird der Grund offensichtlich sein – er zeigt sich als spezifischer Fehler: ein zu großes Korpus, das mit herkömmlichen Textwerkzeugen nicht schnell genug durchsucht werden kann, oder eine mehrstufige Frage, die mit einer Schlüsselwortsuche tatsächlich nicht beantwortet werden kann. Das ist eine weitaus bessere Begründung für die Einführung eines Vector-Speichers als einfach das Nachmachen dessen, was in einem Tutorial zur Demonstration gezeigt wurde.
Es wird nicht behauptet, dass Vektordatenbanken in der Welt keinen Platz haben. Der Punkt ist enger gefasst: Greifen Sie nicht sofort zu einer Vektordatenbank, bevor Sie tatsächlich ausgemessen haben, wie weit Sie mit der weniger attraktiven Grundlösung kommen. Versuchen Sie zunächst das Laden des vollständigen Kontexts sowie die Verwendung von Dateisystemen in Kombination mit Grep. Erst wenn eine kostenpflichtige Speichellösung diese Grundlösung um einen ausreichend großen Unterschied übertrifft, um den Preis – sowohl in finanzieller Hinsicht als auch hinsichtlich der eingeschränkten Fehlersuche – zu rechtfertigen, sollte sie eingesetzt werden. Die meisten Arbeitslasten im Bereich Agentenspeicher erreichen diese Hürde nie.
Fall zwei: Hypergraphen retten Ihr RAG-System auch nicht
Falls Vektordatenbanken die automatische Wahl des letzten Jahres waren, so ist RAG basierend auf Graphen die Wahl dieses Jahres – und Hypergraphen stellen die Weiterentwicklung dar, wenn ein Team feststellt, dass ein einfacher Wissensgraph nicht ausreichend expressiv ist. Auf den ersten Blick klingt das Konzept plausibel: Ein gewöhnlicher Graphenknoten verbindet genau zwei Knoten, doch viele reale Fakten beinhalten gleichzeitig mehr als zwei Beteiligte. Betrachten wir ein Szenario, in dem ein Mitarbeiter im Namen eines ganzen Teams für einen bestimmten Haushaltszyklus die Reisekosten eines Kollegen genehmigt – dieser eine Sachverhalt verknüpft dabei fünf verschiedene Beteiligte miteinander. Wenn man dies in Paarverbindungen umwandelt, bleibt nur die Wahl: Entweder verliert man das Gefühl, es handele sich um ein einziges Ereignis, oder man teilt es auf mehrere binäre Verbindungen auf, die dann zur Abfragezeit wieder zusammengefügt werden müssen. Ein Hyperknoten, der in der Lage ist, beliebig viele Knoten gleichzeitig zu verbinden, scheint die Lösung zu sein.
Eine zuverlässigere Methode, das zu modellieren. Daher entwickeln Teams Hypergraph-RAG-Systeme in der Annahme, dass diese erhöhte Genauigkeit zu einer besseren Informationsabrufung führen wird.Ein in diesem Jahr von einem Autor namens Dustin veröffentlichter Artikel mit dem Titel „Hypergraphs Won’t Make Your RAG System Better. Here’s What They Actually Change“ prüfte diese Annahme anhand der tatsächlichen Implementierung hinter einem Paper über hypergraphbasierte RAG-Systeme – und nicht nur deren Zusammenfassung. Das Ergebnis war fast komisch: HyperGraphRAG, ein System, dessen gesamte Grundidee darauf beruht, dass native Hyperkanten wichtig sind, speichert tatsächlich alles intern in einer herkömmlichen Graph-Datenbank unter Verwendung gewöhnlicher binärer Kanten. Noch aufschlussreicher ist, dass die Autoren des Papers selbst nachweisen, dass diese Umwandlung – bei der jede Hyperkante in eine kleine Gruppe binärer Kanten umgewandelt wird, die um einen als Ereignis repräsentierten Knoten herum angeordnet sind – nichts wegwirft. Nichts an der zugrundeliegenden Struktur geht bei dieser Konvertierung verloren. Sowohl die angeblich ehrlichere Darstellung mit Hypergraphen als auch die „langweilige“ Version mit binären Kanten können aus einander exakt rekonstruiert werden.
ly.Das ist keine unwichtige Anmerkung zur Implementierung – es untergräbt den gesamten Argumentationsaufbau. Wenn ein natives Hyperkante und ein durch Rollen reifizierter Cluster binärer Kanten dieselbe Inkidenzstruktur kodieren und jeweils trivial aus dem anderen wiederaufgebaut werden können, dann ist die Wahl zwischen beiden eigentlich keine Modellierungsentscheidung mit nachfolgenden Konsequenzen. Es handelt sich lediglich um eine Entscheidung bezüglich des Speicherformats. Ein Kommentator zu diesem Artikel, Felix Anderson, formulierte die relevanten mathematischen Zusammenhänge so klar wie möglich: Ein Hyperkante und ein durch Rollen reifizierter binärer Graph beschreiben dieselbe Inkidenzstruktur, und die Breite des Hypertrees ändert sich bei begrenzter Arität nur um einen konstanten Faktor. Die Breite des Hypertrees ist die eigentliche Komplexitätsmaßzahl, die bestimmt, wie aufwendig eine Abfrage zu bewerten ist – nicht die Anzahl der Schritte oder wie viele Teilnehmer in eine Kante gepresst werden. Wenn das Wechseln der Darstellung diese Zahl nur um einen Konstanten verschiebt, und jede Tatsache invol
Wenn es nur eine begrenzte Anzahl an Teilnehmern gibt (was für fast alle Realitätsfaktoren gilt – eine Handvoll Personen in einer Genehmigungskette, nicht Tausende), dann nützt all die Ingenieursarbeit, die in den Switch investiert wird, nichts in Bezug auf die Dimension, die tatsächlich den Abfragedurchsatz bestimmt.Es ist sinnvoll, fair zu betrachten, warum man so leicht in diesen Irrtum verfällt. Die Anzahl der Sprünge ist intuitiv: Je mehr Knoten zwischen einer Frage und ihrer Antwort liegen, desto schwieriger scheint die Abfrage zu sein. Die Breite des Hypertrees hingegen ist überhaupt nicht intuitiv – sie stammt aus der Theorie der Constraint-Befriedigung und Abfragkomplexität und kann sich auf Weise verändern, die durch die Anzahl der Sprünge niemals angedeutet wird, es sei denn, jemand prüft dies ausdrücklich. Es ist durchaus möglich, strukturelle Komplexität hinzuzufügen, die für eine sorgfältig ausgewählte Beispielabfrage die Anzahl der Sprünge verringert, während die zugrunde liegende Komplexitätsklasse unverändert bleibt – oder sie sogar leicht verschlechtert. Sorgfältig ausgewählte Beispiele in einem Paper können beeindruckend wirken, sagen aber nichts Wesentliches über den Allgemeinzustand aus.
Hier ist der Vergleich Seite an Seite, den man sich ansehen sollte, bevor man zwischen einem einfachen Graphen, einem reifizierten Graphen oder einem nativen Hypergraphenspeicher wählt:
REPRESENTATION WHAT IT ADDS WHAT IT ACTUALLY CHANGES
--------------------- ------------------------------- --------------------------------
Plain binary graph Simplest to build and query Baseline; loses atomicity of
with standard graph tooling multi-participant facts
Reified binary graph Recovers atomicity via an Same incidence structure as a
(event node + roles) explicit "event" node hyperedge; hypertree width
shifts by a constant only
Native hypergraph Hyperedges as first-class No reduction in query
store objects, arguably cleaner complexity class over a
to write against reified graph; new storage
engine to run and maintain
Nichts davon bedeutet, dass die Graphstruktur für RAG wertlos ist. Die mehrstufige relationale Suche profitiert tatsächlich von der Graphstruktur im Vergleich zur flachen Vektorsuche – daran besteht kein Zweifel. In Frage steht vielmehr der zusätzliche Schritt von einem gewöhnlichen Graphen zu einem Hypergraphen. Wenn man über die Verkaufspräsentation hinaus zur eigentlichen Begründung blickt, lautet das ehrliche Fazit, dass dieser Schritt zwar ein saubereres Datenmodell liefert, aber gleichzeitig eine neue Art von Infrastruktur erfordert, ohne die Geschwindigkeit der Abfragen zu beeinflussen. Wenn die Suchqualität das Problem ist, liegt die Lösung mit echten Belegen in der Regel in einer besseren Graphkonstruktionsmethode oder einer intelligenteren Suchstrategie für den bereits vorhandenen Graphen – nicht in einem exotischeren Kantentyp.
Fall drei: Das eigentliche Engpass war nie der Code selbst
Die ersten beiden Argumente betrafen die Abrufarchitektur, ein Thema, das sich voll und ganz im vertrauten Bereich bewegt. Das dritte Argument ist anders, denn es geht nicht darum, das richtige Werkzeug auszuwählen – es geht vielmehr darum, woraus die Arbeit eines Senior-Engineers tatsächlich besteht, und es berührte mich näher, als ich erwartet hatte.
Patrick Koss, ein Technologieleiter, der ein Team von fünf Entwicklern in einem Unternehmen mit über tausend Mitarbeitern führt, betitelte seinen Artikel „KI kann 95 Prozent meiner Arbeit nicht erledigen (und ich bin Softwareentwickler).“ Die anfängliche Behauptung klingt fast wie ein Schuldeingeständnis, bevor sie zu einer Argumentation wird: Das Schreiben von Code ist bei weitem der kleinste Teil seiner Arbeitszeit. Sein Team verfolgt ein „Du baust es, du betreibst es“-Konzept, was bedeutet, dass die Verantwortung für die Systeme, die sie betreuen, bei seinen eigenen Entwicklern liegt und nicht bei einer separaten Betriebsgruppe, die Produktionsprobleme als Problem anderer betrachten könnte. Seine Morgen beginnen gegen 8:30 Uhr mit der Überprüfung von Pull-Requests, und der Code in diesen PRs – größtenteils von KI-Agenten erstellt, die den Großteil der Erstellung übernehmen – ist deutlich besser als das, was er vor ein paar Jahren geprüft hat. Er stellt nicht in Frage, ob KI guten Code erstellen kann.
Tag. Er räumt diesen Punkt vollständig ein und stellt anschließend fest, dass dies kaum etwas an den tatsächlichen Anforderungen seines Jobs an ihn ändert.Das ist der Aspekt, bei dem man innehalten sollte, denn er untergräbt eine Annahme, die in vielen Überlegungen zum Agent-Stack verankert ist – einschließlich zahlreicher Argumente in diesem Bereich: die Vorstellung, dass Fähigkeiten die Automatisierung bestimmen. Die Logik lautet in der Regel, dass, sobald ein Modell korrekten Code schreiben kann, die Codeerstellung nicht mehr menschliche Arbeit ist, und daher der Anteil der „Arbeit“, der automatisiert wird, dem Anteil der Arbeit entsprechen sollte, bei der früher Code geschrieben werden musste. Koss’ Gegenargument ist, dass diese Gleichung bereits lange vor dem Erscheinen der KI fehlerhaft war – die KI macht den Fehler nur sichtbarer. Die Rolle eines Technologieleiters bestand niemals hauptsächlich darin, Code zu erstellen. Sie bestand stets in erster Linie aus Koordination: Entscheidungen darüber, was entwickelt wird und in welcher Reihenfolge, Verhandlungen über den Umfang unter Stakeholdern mit widersprüchlichen Prioritäten, Überprüfung und Unterstützung der technischen Entscheidungen anderer sowie Mentoring von weniger erfahrenen Mitarbeitern.
Es geht um die Abstimmung mit Ingenieuren sowie um die Übersetzung dessen, was eine Interessengruppe verlangt, in etwas, das das System realistisch ohne Ausfälle unterstützen kann. Das ist keine verkappte Programmierarbeit. Es handelt sich um organisatorische und zwischenmenschliche Aufgaben, bei denen zufällig Code entsteht – und zwar in hohem Maße automatisierbar –, eingebettet in ein weitaus umfassenderes Set an Verantwortlichkeiten, die gerade deshalb der Automatisierung widerstehen, weil es nicht darum geht, Artefakte zu erzeugen. Es geht vielmehr darum, Einigkeit, Kompromisse und Rechenschaftspflichten unter den Menschen herzustellen.Dies könnte die am meisten unterschätzte Beobachtung in den diesjährigen Diskussionen über KI-Assistenten sein – bedeutender als jede einzelne Vergleichszahl –, denn sie erklärt, warum bei vielen Senior-Entwicklern „das Modell beim Programmieren dramatisch besser wurde“ und „meine Arbeit dramatisch einfacher wurde“ nicht im Gleichschritt voranschreiten, selbst bei denen, die diese Tools aktiv nutzen und echten Nutzen daraus ziehen. Dass die SWE-bench-Werte innerhalb von ein paar Jahren von einstelligen Werten in die Siebziger steigen, bedeutet einen echten und erheblichen Fortschritt in den Fähigkeiten. Doch dieser Fortschritt führt nicht automatisch zu einer Arbeit, die zu 70 Prozent leichter ist – schließlich bestand die Arbeit von Anfang an nicht zu 70 Prozent aus Codeerstellung – besonders dann nicht, wenn man bereits senior genug ist, um auch für die Schichtdienste und den Entwicklungsplan verantwortlich zu sein, nicht nur für Pull Requests.
Die ehrliche Einschränkung ist, dass dieser Argument nicht so eindeutig allgemeingültig ist wie die ersten beiden. Behauptungen zu Vektordatenbanken und Hypergraphen sind technisch ausreichend detailliert, sodass man sie anhand von Benchmarks oder Beweisen überprüfen kann – und genau das wurde bereits zuvor getan. Die Frage, wie viel von der Arbeit eines Senior-Engineers auf Koordination und wie viel auf Programmierung entfällt, hängt von der Unternehmensgröße, der Reifegrad der Teammitglieder, davon ab, wie viel organisatorischer Aufwand tatsächlich notwendig ist und nicht nur zu Fehlfunktionen führt, sowie vom Erfahrungsgrad des Einzelnen ab. Ein Fünf-Personen-Team innerhalb eines tausendköpfigen Unternehmens, das nach dem Prinzip „Du baust es, du betreibst es“ arbeitet, stellt eine bestimmte Form der Arbeitsorganisation dar und ersetzt nicht alle ingenieurtechnischen Rollen. Dennoch scheint die zugrundeliegende Korrektur im Großen und Ganzen gültig zu sein: Die Fähigkeiten eines Agenten setzen eine Obergrenze dafür, wie viel von der Code-Schreib-Arbeit in einem Job theoretisch automatisiert werden könnte, aber sie geben keine genaue Angabe ab.
Man weiß fast nichts darüber, wie groß der Anteil der Koordinationsaufgabe sein kann, da dieser Anteil von Anfang an weder durch die Eingabegeschwindigkeit noch durch die Codequalität eingeschränkt war.Der gemeinsame Nenner
Wenn man diese drei Fälle nebeneinander stellt, hat die eigentliche Lektion nichts Spezifisches mit Vektordatenbanken, Hypergraphen oder den Fähigkeiten von Agenten zu tun. Sie betrifft vielmehr eine Diskrepanz zwischen der Annahme, wo die Schwierigkeit liege, und dem tatsächlichen Ort dieser Schwierigkeit.
CASE WHERE COMPLEXITY WAS ADDED WHERE THE REAL BOTTLENECK WAS
------------------ ---------------------------------- --------------------------------
Agent memory Vector embeddings, similarity Whether the model can use a
search, sometimes a graph layer retrieval method it already
on top of that has deep fluency with
RAG structure Native hyperedges, a new The complexity class governing
storage engine, more query cost, which the fancier
elaborate graph modeling structure barely touches
"How much of the An assumption that model Whether the job was ever
job gets automated" capability alone predicts mostly about the thing the
the automatable fraction model is good at
Aus den anspruchsvolleren Optionen ist keine per se eine schlechte Idee. Vektordatenbanken lösen in dem richtigen Kontext echte Probleme, Hypergraphen können in Situationen helfen, die hier nicht behandelt werden, und KI-Agenten beseitigen tatsächlich echte Routinearbeiten in ingenieurtechnischen Aufgaben – einen Punkt, den der Forscher hinter dem dritten Fall ausdrücklich betont. Der Fehler lag nicht darin, nach Komplexität zu streben, sondern darin, den Schritt auszulassen, zu überprüfen, ob die Komplexität tatsächlich das eigentliche Problem adressiert und nicht nur jenes, für dessen Lösung es am einfachsten ist, etwas Eindrucksvolles zu entwickeln.
Diese Gewohnheit zeigt sich auch weit über das Agenten-Engineering hinaus. Ein weiteres Layer hinzuzufügen ist fast immer einfacher, als innezuhalten und zu prüfen, ob die schlichte, unspektakuläre Grundlage jemals angemessen dagegen getestet wurde. Eine neue Abstraktion erscheint als sichtbarer Fortschritt – etwas, auf das man zeigen und als Upgrade bezeichnen kann. Zu überprüfen, ob grep bereits den Fall abdeckt, ob die Komplexität der Abfrage tatsächlich verbessert wurde oder ob das, was eine ganze Woche in Anspruch nimmt, wirklich das ist, wofür man es hielt – diese Arbeit ist langsamer und weitaus weniger zufriedenstellend, und sie kann mit dem Schluss enden, dass man aufhören sollte zu entwickeln anstatt weiterzumachen.
Hier ist eine gekürzte Version der Überprülliste, die vor dem Hinzufügen eines weiteren Layers zu jedem Stack angewendet werden sollte:
1. Have I benchmarked the boring baseline, not just assumed it loses?
(full-context, grep, a plain graph, a human doing the coordination)
2. Does the new structure change the metric that actually governs cost
or quality, or does it just look more sophisticated on a diagram?
3. Am I reaching for this because a benchmark or proof told me to,
or because it's what the tutorials and the funded products default to?
4. If I strip this layer back out, what specifically breaks?
If I can't name it precisely, I probably don't need the layer yet.
5. Am I solving the bottleneck I actually have, or the bottleneck
that's most interesting to build a sophisticated solution for?
Nichts davon spricht dafür, insgesamt weniger Ingenieurarbeit zu leisten. Es geht vielmehr darum, die ingenieurtechnischen Bemühungen darauf zu richten, herauszufinden, wo sich das eigentliche Engpassproblem befindet, bevor man eine aufwendige Lösung entwickelt, die voraussetzt, man kenne bereits die Antwort. Die hier vorgestellten drei Beispiele dienten nicht dem Effektzweck. Sie erhielten diese Bezeichnung, weil jemand die unattraktive Arbeit der Überprüfung durchführte und dabei feststellte, dass die Ergebnisse nicht mit der gängigen Annahme übereinstimmten. Das ist ein deutlich höheres Maßstab als eine schrille Schlagzeile zusammen mit einer starken Meinung – und genau dieser Maßstab sollte künftig bei der Bewertung eigener Systeme angewandt werden.
Weitere Literatur
- Verständnis von KI-Agenten: Ziele, Werkzeuge, Speicher und der Agentenzyklus — Eine für Anfänger geeignete Erklärung, wie sich KI-Agenten von Chatbots unterscheiden, mit Schwerpunkt auf den Kernkomponenten, dem Entscheidungszyklus, den Autonomiegraden sowie praktischen Anwendungsfällen.
- Verständnis der KI-Speicherfunktionen: Kontext, Embeddings, RAG und erklärte Modellgewichte — In diesem Artikel wird erklärt, wie KI-Systeme tatsächlich Informationen speichern, unter Berücksichtigung von Kontextfenstern, Embeddings, Vektordatenbanken, RAG sowie Modellparametern.