Das neue Toolkit: LLMs, Prompts und grundlegende Interaktion mit dem Werkzeug

LLMs interagieren anders. Anstatt nur Daten anhand eines Schemas zu überprüfen, liest ein LLM eine Beschreibung in einfacher Sprache darüber, was ein Werkzeug oder ein anderes System tun kann. Als Entwickler muss ich die Informationen offenlegen, die ein aufrufender LLM lesen, konsumieren und letztendlich verwenden kann, um zu verstehen, wie meine Schnittstelle zu bedienen ist. Sie geben dem LLM kein striktes Schema. Stattdessen stellen Sie eine Beschreibung zur Verfügung, die den Zweck eines Werkzeugs, die Eingaben und die erwarteten Ergebnisse enthält.

Der LLM nutzt sein Sprachverständnis, um auf der Grundlage dieser Beschreibung herauszufinden, wie das Werkzeug zu verwenden ist. Es ist, als würde man von der Überprüfung eines starren Formulars zum Verstehen von verbalen Anweisungen übergehen. Dies ist flexibler, insbesondere bei weniger strukturierten Aufgaben, aber es bedeutet, dass die Interaktion von der Interpretation abhängt, die weniger vorhersehbar sein kann als strenge Formate. Diese Methodik wird in vielen Bereichen eingesetzt, vom Model Context Protocol (MCP) bis zum Open-Source Agent Development Kit von Google, wie ich in meinem letzten Blog erwähnt habe.

Prompts sind die neuen "API-Dokumente"

Für LLMs ist der "API-Vertrag" oder die Dokumentation also im Wesentlichen die Eingabeaufforderung, die Sie schreiben, um das Werkzeug oder die Fähigkeit zu beschreiben. Anstatt Code-Anmerkungen oder Schemadateien zu schreiben, verfassen Entwickler nun klare, detaillierte Beschreibungen, die dem LLM Auskunft geben:

• Was es tut: Die Hauptfunktion des Tools.
• Was es braucht: Die erforderlichen Eingaben, vielleicht mit Beispielen oder Hinweisen zum Format.
• Was sie zurückgibt: Die erwartete Ausgabe oder Aktion.
• Alle Regeln: Wichtige Beschränkungen oder Leitlinien.

Dies bedeutet, dass Prompt-Engineering zu einer entscheidenden Fähigkeit wird. Damit diese Systeme funktionieren, müssen die Entwicklungsteams in der Lage sein, Anweisungen zu schreiben, die von den LLM zuverlässig verstanden und umgesetzt werden können.

Einfaches Beispiel: Ein "Kalender-Assistent" für ein LLM

Stellen wir uns ein dynamischeres Werkzeug vor, wie einen Kalenderassistenten, und beschreiben wir es für einen LLM:

Allgemeine Beschreibung des Tools: "Dies ist ein Kalender-Assistent-Tool. Es kann neue Meetings planen und verfügbare Zeitfenster für eine Gruppe von Personen finden."

Funktion 1: CreateMeeting Aufforderung: Name des Werkzeugs: CreateMeeting. Beschreibung: Plant eine neue Besprechung im Kalender. Erforderliche Eingaben: attendees (eine Liste von E-Mail-Adressen), subject (Text für den Titel der Sitzung), startTime (Datum und Uhrzeit, zu der die Sitzung beginnen soll; versuchen Sie, relative Zeiten wie "morgen um 15 Uhr" oder "nächsten Montagmorgen" zu interpretieren), und duration (Text zur Beschreibung der Dauer, z. B. "1 Stunde", "30 Minuten"). Optionale Eingabe: Ort (Text, z. B. "Konferenzraum B" oder ein Videoanruf-Link). Antwortet mit einer Bestätigungsmeldung, die die endgültigen Besprechungsdetails enthält, oder mit einer Fehlermeldung, wenn die Planung fehlschlägt (z. B. Zeitkonflikt, ungültige Teilnehmer). Wenn die Startzeit oder Dauer nicht eindeutig ist, bitten Sie den Benutzer um eine Klarstellung, bevor Sie fortfahren. Sofern nicht anders angegeben, wird davon ausgegangen, dass die Zeiten in der lokalen Zeitzone des Benutzers liegen.

Wie das LLM es verwenden könnte (nach der Interpretation der Benutzeranfrage): CreateMeeting(attendees=["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")

Funktion 2: FindFreeTime Aufforderung: Name des Werkzeugs: FindFreeTime. Beschreibung: Findet gemeinsame verfügbare Zeitfenster für eine Gruppe von Personen innerhalb eines bestimmten Zeitrahmens. Erforderliche Eingaben: attendees (eine Liste von E-Mail-Adressen) und duration (Text, der die gewünschte Dauer der Besprechung beschreibt, z. B. "1 Stunde"). Optionale Eingabe: timeWindow (Text, der beschreibt, wann gesucht werden soll, z. B. "nächste Woche", "diesen Freitagnachmittag", "innerhalb der nächsten 3 Tage"; Standardwert ist die aktuelle Arbeitswoche, wenn nicht angegeben). Antwortet mit einer Liste der verfügbaren Startzeiten (Datum und Uhrzeit) oder einer Meldung, dass keine gemeinsamen Zeitfenster gefunden wurden. Geben Sie den zu durchsuchenden Datumsbereich genau an, wenn ein relatives Fenster wie "nächste Woche" verwendet wird. Geht davon aus, dass die Zeiten in der lokalen Zeitzone des Benutzers liegen, sofern nicht anders angegeben.

Wie das LLM es verwenden könnte (nach der Interpretation der Benutzeranfrage): FindFreeTime(attendees=["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")

Hier leiten die Eingabeaufforderungen den LLM an, wie er mit Listen umzugehen hat, wie er potenziell unscharfe Eingaben wie Datumsangaben und Zeiträume zu interpretieren hat und sogar, wann er um Klärung bitten muss. Dies ist näher daran, wie LLM-Werkzeug-Interaktionen in der realen Welt funktionieren.

Die Herausforderung: Zweideutigkeit und zeitnahe Präzision (Vorbereitung auf Teil 3 dieser Serie)

Wenn man als Entwickler zum ersten Mal ein solches Tool erstellt, denkt man sich: 'Das ist unglaublich! Diese Agenten zu schreiben ist ein Kinderspiel". Und dann, wie so oft im Leben eines Entwicklers, schlägt einem die Realität ins Gesicht...

Während die Eingabeaufforderungen des Kalender-Assistenten versuchen, mit einigen Unschärfen umzugehen (z. B. "morgen um 15 Uhr"), kann der Rückgriff auf Beschreibungen in natürlicher Sprache Ihrer Software neue und aufregende Möglichkeiten eröffnen, etwas zu tun, was Sie eigentlich nicht erwartet haben.

Betrachten Sie diese Beispiele:

• Widersprüchliche CreateMeeting-Anfrage:
  • Nutzer: "Buchen Sie für mich und Charlie ein zweistündiges Treffen am Freitagnachmittag, aber unbedingt vor 14 Uhr."
  • Problem: "Freitagnachmittag" bedeutet in der Regel eine Zeit nach 12 Uhr oder 13 Uhr. "Vor 14 Uhr" erzeugt einen potentiellen Konflikt oder ein sehr enges Zeitfenster (z.B. 13 bis 14 Uhr). Die Eingabeaufforderung sagt dem LLM nicht explizit, wie er mit widersprüchlichen Einschränkungen innerhalb eines einzelnen Parameters wie der Zeit umgehen soll. Soll er "Nachmittag" oder "vor 14 Uhr" bevorzugen? Soll er den Benutzer auf den Konflikt hinweisen?
• Vage FindFreeTime-Anfrage:
  • Benutzer: "Nehmen Sie sich nächste Woche Zeit für ein kurzes Gespräch mit Dave".
  • Problem: Was ist ein "schneller Chat"? Der Parameter für die Dauer muss etwas spezifischer sein, wie "15 Minuten" oder "30 Minuten". Die aktuelle Eingabeaufforderung erfordert eine Dauer und gibt keinen Standard an oder wie mit vagen Begriffen wie "Quick-Chat" umgegangen werden soll. Der LLM könnte scheitern oder muss raten.
• Implizite Annahmen in FindFreeTime:
  • Benutzer: "Finden Sie eine Stunde für die Teambesprechung am nächsten Mittwoch".
  • Problem: Wer ist "das Team"? Das LLM benötigt die Liste der Teilnehmer (E-Mail-Adressen). Die Eingabeaufforderung erfordert dies, aber die Benutzeranfrage beruht darauf, dass der LLM den Kontext von "das Team" kennt. Ein guter Interaktionsablauf könnte beinhalten, dass der LLM fragt: "Wer ist im Team?", wenn die Teilnehmerliste nicht zur Verfügung gestellt wird oder aus dem Gesprächsverlauf abgeleitet werden kann. An dieser Stelle könnte der anrufende Agent einen anderen Agenten anrufen, um herauszufinden, wer zum "Team" gehört.
• Nicht spezifizierte Zeitzonen:
  • Benutzer (in London): "Setzen Sie für morgen 9 Uhr ein Treffen mit Priya (in New York) an."
  • Problem: Ist das 9 Uhr Londoner Zeit oder 9 Uhr New Yorker Zeit? Die aktuellen Eingabeaufforderungen enthalten eine Grundannahme ("Wenn nicht anders angegeben, gelten die Zeiten in der lokalen Zeitzone des Benutzers"), aber die korrekte Handhabung von Zeitzonen ist komplex. Was ist, wenn der Benutzer keine Angaben macht und die Teilnehmer sich in verschiedenen Zeitzonen befinden? Das Tool benötigt entweder eine ausgeklügelte Backend-Logik zur Handhabung von Zeitzonen oder sehr viel explizitere Anweisungen in der Eingabeaufforderung, wie die Zeitzoneninformationen abzufragen und zu bestätigen sind, wenn mehrere Standorte beteiligt sind. Eine einfache Annahme könnte zu Fehlern bei der Planung führen.

Diese Beispiele zeigen, dass selbst bei guten Eingabeaufforderungen Mehrdeutigkeiten in den Benutzeranfragen, widersprüchliche Informationen oder unausgesprochene Annahmen (wie Zeitzonen) zu Fehlern, falschen Aktionen oder frustrierenden Klärungsschleifen führen können. Die Wirksamkeit der Interaktion zwischen LLM und API hängt direkt von der Qualität und Vollständigkeit der Eingabeaufforderung ab, die die Fähigkeiten und Grenzen des Tools beschreibt. Sie muss nicht nur den glücklichen Weg abdecken, sondern auch den Umgang mit Ungenauigkeiten, fehlenden Informationen, potenziellen Konflikten und kontextbezogenen Details wie Zeitzonen.

Komplexer werden: Wenn mehrere KI-Agenten miteinander sprechen (Übergang zu tieferen Themen)

Ein einzelnes Tool genau zu beschreiben ist eine Sache, aber es wird viel schwieriger, wenn mehrere KI-Agenten versuchen, zusammenzuarbeiten. Wie schreibt man Aufforderungen so, dass Agent A klar versteht, was Agent B tun kann und was nicht, einschließlich der Frage, wie Agent B mit Mehrdeutigkeit umgeht? Wie koordinieren sie sich? Wie stellt man sicher, dass sie zuverlässig zusammenarbeiten, ohne dass es zu unerwarteten Problemen kommt, weil sie die Anweisungen des jeweils anderen interpretieren? Eine große Herausforderung bei der Entwicklung dieser Systeme ist es, herauszufinden, wie diese Interaktionen klar und zuverlässig mit Hilfe der Sprache definiert werden können.

Erfahren Sie, wie Akamai Ihre KI-Workloads in großem Umfang unterstützen kann. Sprechen Sie noch heute mit unseren Experten.