What makes prompts a graph: necessary and sufficient conditions for prompt graph engineering
Dieses Paper schlägt eine konstitutive Definition und einen operativen Rahmen für „Prompt Graph Engineering“ vor, um moderne Prompt-Systeme formal als explizite, ausführbare Graphen zu charakterisieren und damit notwendige Bedingungen, ein gemeinsames Vokabular sowie eine Forschungsagenda für eine Praxis zu etablieren, die in der Industrie derzeit allgegenwärtig, aber mangels präziser theoretischer Definition noch unzureichend definiert ist.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie versuchen, einem superintelligenten Roboter beizubringen, wie man ein Rätsel löst. Zu Beginn haben Sie einfach einen einzigen, riesigen, perfekten Brief an den Roboter geschrieben, in der Hoffnung, dass er durch diese eine Nachricht alles herausfinden würde. Das war der alte Weg: ein Prompt, eine Antwort. Aber als die Roboter klüger und die Rätsel schwieriger wurden, reichte dieser einzelne Brief nicht mehr aus. Ingenieure erkannten, dass sie das Problem aufteilen mussten. Sie begannen damit, den Roboter einen Plan schreiben zu lassen, dann seine Arbeit überprüfen zu lassen, ihn dann einen Spezialisten um Hilfe bitten zu lassen und schließlich über die beste Antwort abzustimmen. Plötzlich war der „Prompt“ nicht mehr nur ein Brief; es war ein ganzes Team von Robotern, die in einer bestimmten Reihenfolge zusammenarbeiteten.
Hier wird es knifflig. Wenn man ein Team von Robotern hat, die sich gegenseitig Zettel zuwerfen, braucht man eine Karte, die zeigt, wer mit wem spricht, wer auf wen wartet und wer die endgültige Entscheidung trifft. In der Welt der Informatik wird diese Karte als Graph bezeichnet. Stellen Sie sich einen Graphen wie einen U-Bahn-Plan vor: Die Stationen sind die Schritte (wie „Hinweis lesen“ oder „Experten rufen“) und die Gleise sind die Anweisungen, die dem Roboter sagen, wohin er als Nächstes gehen soll. Einige Gleise führen zurück, wenn ein Fehler gemacht wird; andere teilen sich gleichzeitig in zwei Pfade auf. Die große Frage für Wissenschaftler und Ingenieure ist derzeit: Wann wird eine ungeordnete Sammlung von Roboteranweisungen zu einem echten, offiziellen „Graphen“, den wir studieren, reparieren und verbessern können? Wenn wir uns nicht darauf einigen können, was ein Graph eigentlich ist, können wir keine besseren Werkzeuge entwickeln, um diese Roboterteams zu steuern.
Diese Arbeit, geschrieben von Sandeco Macedo, ist wie ein Detektiv, der versucht, die offizielle Grenzlinie für dieses neue Feld zu ziehen. Der Autor argumentiert, dass wir das Wort „Graph“ zu locker verwenden. Manchmal benutzen Menschen es, um zu beschreiben, wie ein Roboter innerhalb seines eigenen Kopfes denkt, und manchmal benutzen sie es, um eine Karte zu beschreiben, die ein Ingenieur gezeichnet hat, um den Roboter zu steuern. Die Arbeit legt nahe, dass etwas nur dann als „Prompt Graph Engineering“ zählen kann, wenn es eine spezifische Art von konstruierter Karte ist und nicht nur ein zufälliges Gespräch oder ein Gedankengang.
Der Autor schlägt einen strengen vierstufigen Test vor, um zu entscheiden, ob ein System ein echter „Prompt-Graph“ ist. Erstens muss die Karte explizit sein: Man muss die Stationen und Gleise auf Papier (oder in Code) sehen können, noch bevor der Roboter überhaupt losläuft. Zweitens muss die Karte von den Notizen getrennt sein: Man sollte in der Lage sein, die Anweisungen auf den Gleisen (die Struktur) zu ändern, ohne die Briefe, die der Roboter liest (den Inhalt), umschreiben zu müssen, und umgekehrt. Drittens muss die Karte ausführbar sein: Es ist nicht nur eine Zeichnung; ein Computer muss sie tatsächlich ausführen und entscheiden, welche Station als Nächstes besucht wird, basierend auf den Regeln. Und viertens muss die Karte ein reales Objekt sein: Sie muss als Datei oder Design existieren, das gespeichert, versioniert und verbessert werden kann, genau wie ein Bauplan für ein Haus.
Mit diesem Test sortiert die Arbeit die echten Werkzeuge von den Imitatoren aus. Sie bestätigt, dass Systeme wie LangGraph und DSPy echte Prompt-Graphen sind, weil sie klare Karten, getrennte Strukturen und Laufzeiten haben, die sie ausführen. Sie schließt jedoch einige populäre Multi-Agenten-Systeme aus, bei denen die Roboter einfach frei chatten und der Pfad, den sie nehmen, erst nach Abschluss des Gesprächs entdeckt wird; das sind „emergente“ Abläufe, keine konstruierten Graphen. Die Arbeit stellt auch klar, dass „Gedanken-Topologien“ (bei denen ein Roboter einen Baum von Ideen generiert) zwar wie Graphen aussehen, aber nicht dasselbe sind, da der Roboter und nicht der Ingenieur die Karte zeichnet.
Letztendlich deutet die Arbeit darauf hin, dass wir an einem Wendepunkt stehen. Wir sind vom Schreiben einzelner Briefe zum Konstruieren komplexer, schleifender und verzweigender Systeme übergegangen. Indem der Autor genau definiert, was ein „Prompt-Graph“ ist, gibt er Ingenieuren ein gemeinsames Vokabular und eine Checkliste. Dies löst nicht alle Probleme, aber es verhindert, dass wir ein chaotisches Gespräch als „Graphen“ bezeichnen, und hilft uns, uns darauf zu konzentrieren, Systeme zu bauen, in denen die Struktur selbst inspiziert, getestet und optimiert werden kann. Die Arbeit kommt zu dem Schluss, dass die Praxis des Erstellens dieser Karten in Laboren und Unternehmen bereits stattfindet, aber eine klare Definition der notwendige erste Schritt ist, um zu messen, wie sehr diese Karten unsere KI-Systeme tatsächlich verbessern.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.