Building AI Agents That Work - My Talk at Google NEXT

Ich sprach kürzlich auf der Google Next über funktionierende KI Agenten. Der Vortrag stieß auf großes Interesse, wurde aber nicht aufgezeichnet. Daher dachte ich mir, ich erstelle dieses Video und teile einige der Erkenntnisse, die ich in den letzten Jahren beim Aufbau von KI Systemen für Unternehmen und Start ups gewonnen habe. Hier sind nun ein paar Bilder von dem Vortrag. Eigentlich sollte es der letzte Vortrag des Tages sein, aber ich denke, die Beteiligung war trotzdem ziemlich gut und ich hatte nach dem Vortrag wirklich tolle Gespräche mit einigen der Teilnehmer. Daher dachte ich mir, ich stelle dieses Video zusammen. Es wird eine erweiterte Version, da ich keine zeitliche Begrenzung habe. OK, nur um die Bühne zu bereiten. Zunächst beschreiben wir, was Agenten sind, da es wirklich wichtig ist, eine konkrete Definition dafür zu haben, was ein Agent ist. Wenn Leute von Agenten sprechen, beziehen sie sich normalerweise auf verschiedene Dinge. In dem eigentlichen Vortrag hatte ich eine Fallstudie, die für dieses Video nicht relevant ist. Daher habe ich sie entfernt. Der Schwerpunkt dieses Videos liegt auf den gewonnenen Erkenntnissen. Ich habe in den letzten Jahren mit Unternehmen und Start ups zusammengearbeitet. Dies ist im Grunde eine Zusammenfassung einiger meiner Erfahrungen beim Aufbau von Agentensystemen. Ich denke, dass sich in der Branche insgesamt einige Best Practices herausbilden. Daher werden wir uns einige davon ansehen. OK. Zuerst möchte ich klären, was genau ein Agent ist und wie er definiert wird. Sie haben dieses Diagramm wahrscheinlich schon einmal in der einen oder anderen Form gesehen. Aber im Wesentlichen ist ein React Agent in der Lage, seine Aktionen zu planen. Den Kern des Agenten bildet ein umfangreiches Sprachmodell. Der Agent kann den Plan dann ausführen. Dazu benötigt er eine Orchestrierungsschicht. Außerdem muss er mit seiner Umgebung interagieren. Er verfügt also über die Tools oder Funktionsaufrufe, die er zur Interaktion mit der Umgebung verwenden kann. Außerdem beobachtet er die Ergebnisse seiner Aktionen und kann auf dieser Grundlage seine Pläne ändern oder aktualisieren. Richtig. Im Wesentlichen benötigt man also ein umfangreiches Sprachmodell mit Tools und eine Orchestrierungsschicht. Manchmal braucht man auch kurz oder langfristigen Speicher. Im Moment ist das meiner Meinung nach eine etwas kompliziertere Definition. Die Definition, die mir gefällt, ist Ein Agent ist eine key gesteuerte Anwendung, die ein Sprachmodell verwendet. Es kann sich auch um ein visuelles Sprachmodell handeln, das von einer Reihe von Anweisungen geleitet wird, die sein Verhalten formen. Die Anweisungen beschreiben im Wesentlichen den Plan des Agenten oder die Systembefehle, Design, Verhalten, Steuern. Außerdem hat er Zugriff auf zusätzliche Tools, die seine Fähigkeiten erweitern. All dies wird in einer dynamischen Laufzeitumgebung ausgeführt, die der Agent oder LLM steuern kann. Wenn man sich diese Definition ansieht, handelt es sich im Grunde genommen um einen LLM mit einem bestimmten Satz von Anweisungen, der Zugriff auf zusätzliche Tools hat, die er verwenden kann. Alles wird in einer dynamischen, agentenorientierten Laufzeitumgebung ausgeführt, die der LLM steuert. Richtig. Wenn er also beschließt, die Ausführung nicht zu stoppen, kann er das tun. Im Mittelpunkt des Vortrags standen diese gewonnenen Erkenntnisse. Brauchen Sie keinen Agenten, verwenden Sie ihn nicht. Lassen Sie mich das erläutern. Zuerst müssen Sie sich die Aufgabe, die Sie ausführen, oder das Problem, das Sie lösen möchten, ansehen. Ich empfehle Ihnen dringend, sich diese vier Fragen zu stellen. Sie helfen Ihnen nicht nur, Ihr Problem zu verstehen, sondern auch, ob Sie tatsächlich einen Agenten benötigen oder einfach nur Workflows verwenden können. Wir werden uns später im Video Beispiele für Workflows ansehen. OK. Die erste Frage ist die Vorhersehbarkeit. Wie vorhersehbar ist Ihre Aufgabenstruktur? Sie sollten sich also fragen, ob Sie alle erforderlichen Schritte im Voraus planen können oder ob der Prozess dynamische Entscheidungen erfordert. In den meisten Fällen, mit denen ich gearbeitet habe, können Sie sich die aktuelle Art und Weise ansehen, wie Sie ein Problem lösen und im Grunde einen schrittweisen Prozess entwerfen, der Ihnen bei der Bewältigung Ihrer Aufgabe hilft. Derzeit können Ihnen LLMs dabei helfen. Sie können entscheiden, brauchen aber meist keine dynamische Entscheidungsfindung. Sie folgen den Schritten. Wenn dies der Fall ist und Sie Vorhersehbarkeit in Ihren Prozessen wünschen, sollten Sie sich von agentenbasierten Systemen fernhalten. Der zweite Punkt ist Kontrolle. Und auch diese ist sehr Wie entscheidend sind Konsistenz und Kontrolle in Ihrer Anwendung? Die Frage ist also, ob Sie garantierte Verhaltensmuster benötigen oder ob Sie Flexibilität bei der Ausführung von Aufgaben zulassen können. Benötigen Sie konsistente Steuerung und volle Kontrolle? Depends on context. Wenn dies der Fall ist, empfehle ich nicht stochastische Agentensysteme zu verwenden, die eher einen stochastischen Entscheidungsprozess aufweisen. Im Moment ist dies von Branche zu Branche unterschiedlich. Aber selbst während Google Next, als ich mit Sam herumgelaufen bin, der einen ausgezeichneten YouTube Kanal hat, falls sie ihn noch nicht gesehen haben, kann ich Ihnen nur wärmstens empfehlen, haben wir uns auf der Messe umgesehen und es gab viele verschiedene Unternehmen, die unterschiedliche Versionen von Agentenräumen oder Agentensystemen präsentierten. Im Grunde genommen wollte der Benutzer bei jedem von ihnen Vorhersehbarkeit und Kontrolle haben. In diesen Fällen ist es also besser, sich eher mit Workflows als mit Agentensystemen zu befassen. Die dritte Frage, die Sie sich stellen sollten, sind Grenzen und Komplexität. Wie klar definiert sind Ihre Grenzen? Die Frage wäre also, ob man das Problem sauber in feste Teilaufgaben zerlegen kann oder ob das Problem offener ist und mehr adaptives Denken erfordert. Wenn man sein Problem also in feste Teilaufgaben zerlegen kann, sind diese in der Regel ein wirklich guter Kandidat für Workflows. In diesen Fällen möchte man keine stosstischen Agentensysteme mehr verwenden. Und der letzte Punkt, der oft bis zum Ende des Projekts ignoriert, sind Latenz und Kosten. Wie hoch ist Ihre Kosten und Latenztoleranz? Sind Sie also bereit, höhere Kosten und längere Verarbeitung für mehr Anpassungsfähigkeit in Kauf zu nehmen? Der Grund, warum Sie Kosten und Latenz berücksichtigen müssen, ist, dass der Agent in Agentenschleifen möglicherweise gerade mehrere Tool und LLM Aufrufe tätigt. Dies könnte möglicherweise Ihre Leistung verbessern, aber gleichzeitig haben Sie Aufgrund der mehreren Tool und LLM-Aufrufe eine höhere Latenz. Und höhere Kosten. Manche Anwendungen werden durch Kosten und besonders Latenz stark eingeschränkt. Sie können also in bestimmten Situationen nicht ein paar Sekunden warten. Richtig. Falls Sie also diese Einschränkung erfüllen müssen, sollten Sie besser keine agentenbasierten Systeme verwenden, wenn die Antwort auf diese vier Fragen Ihr System soll vorhersehbar sein, Sie wünschen viel Kontrolle und klar definierte Entscheidungsgrenzen zur Zerlegung der Aufgabe in Teilaufgaben und Sie haben Latenz und Kostenbeschränkungen, empfehle ich dringend workflows. Das sind LLMs mit Anweisungen und Zugriff auf Tools. In diesem Fall entwerfen Sie im Grunde einen Entscheidungsgraphen oder Entscheidungsbaum, den das System befolgen muss. An jedem Knoten kann das System oder LLM eine Entscheidung treffen. Es kann zwei oder drei Optionen geben, aber im Grunde geben Sie ihm an jedem Knoten die Möglichkeit, eine Entscheidung zu treffen. Es muss also nicht extrem starr sein. Es ist immer noch flexibel, aber das ist normalerweise viel besser als etwas wie ein autonomes, agentenbasiertes System. Noch Es hängt stark vom Problembereich ab. Workflows sind nicht immer optimal, doch in meiner Erfahrung lösen Sie in der Fälle das Problem, anstatt auf ein vollständiges Agentensystem zurückzugreifen. Zur Referenz. Das Konzept der Workflows wurde von Antropic in diesem Blogbeitrag Effektive Agenten erstellen eingeführt. Hier werden verschiedene Workflows und deren Einsatzmöglichkeiten erläutert. Ich kann Ihnen daher nur wärmstens empfehlen, sich das anzusehen. Ich habe auch ein ausführliches Video zu diesem Thema, das ich in der Videobeschreibung verlinken werde. Hier ist ein kurzes Beispiel für einen Workflow. Sie können verschiedene LLM Aufrufe verketten und so einen Entscheidungsschritt nach dem ersten LLM Aufruf einrichten. Sie als Benutzer können entscheiden, ob der Vorgang an die zweite Stufe weitergeleitet wird. Oder beendet wird, wenn diese Bedingung nicht erfüllt ist. Dies ist nur ein Beispiel. Hier sind einige weitere Beispiele, bei denen Sie ein Router LLM haben, das entscheidet, welches LLM mit einem bestimmten Satz von Anweisungen verwendet werden soll. Richtig. Ich werde sowohl den Link zum Blogbeitrag als auch zu dem Video, das ich dazu erstellt habe, einfügen und ich kann jedem, der sich für dieses Thema interessiert, nur wärmstens empfehlen, sich das anzusehen. OK, nun zurück zu den Folien. Eine weitere Frage, die mir oft gestellt wird, sind Frameworks. Welches Framework soll man verwenden, Ob man Frameworks verwenden soll oder nicht und wann? In diesem Abschnitt werde ich versuchen, einige dieser Dinge anzusprechen. Zunächst einmal habe ich nichts gegen Frameworks. Sie führen jedoch viele Abstraktionen ein. Sie eignen sich hervorragend für den schnellen Bau von PCs. Sie ermöglichen also ein schnelles Prototyping. Sie sind also ein guter Anfang nur für Machbarkeitsstudien. Es gibt einige wirklich großartige Frameworks und jedes einzelne hat seine eigenen Vor und Nachteile. Richtig. Da wäre zum Beispiel Landgraf Cruise. Vielleicht habe ich noch ein paar andere vergessen. Ich denke an Autogen Small Agents. Google hat sein eigenes Agent Development SDK oder Agent Development Kit. OpenAI hat sein eigenes Agent SDK. Richtig. Es gibt also viele Möglichkeiten, aber ich persönlich finde, dass sie sich sehr gut für schnelles Prototyping eignen. Warum denke ich nun, dass sie keine gute Option für die Entwicklung sind? Erstens haben die meisten dieser Frameworks viele versteckte Details. Damit sie funktionieren, gibt es viele versteckte Systemanweisungen. Sie verbergen also im Grunde ihre interne Funktionsweise. Die meisten davon sind Open Source. Sie können sich die Systemanweisungen also tatsächlich ansehen. Aber es werden trotzdem viele Abstraktionen hinzugefügt und sie geben im Wesentlichen viel Kontrolle an die internen Mechanismen ab, die diese Frameworks oder Abstraktionen verwenden. Deshalb sollten sie bei solchen Dingen vorsichtig sein. Zweitens gibt es aufgeschobene Entscheidungen. Normalerweise möchten sie bestimmte Einschränkungen in den Systemen identifizieren und die Ziele ihres Systems festlegen, das sie erstellen. Die Frameworks erzwingen jedoch Designentscheidungen, bevor sie die Einschränkungen in ihren Systemen überhaupt identifiziert haben. Das ist also ein großes Problem bei der Framework Wahl. Okay, Und der letzte Punkt ist, dass diese Frameworks und Abstraktionen für dein spezifisches Problem zu suboptimalen Systemen führen könnten. OK, eine Möglichkeit ist, mit einem schnellen Prototyp mit Hilfe eines Frameworks zu beginnen. Nehmen wir an, du entscheidest dich für langgraph oder CR. Dann wird es viele Abstraktionen und viele andere Dinge geben, die für deine spezifische Anwendung nicht benötigt werden. Idealerweise möchtest du an dieser Stelle alle Abstraktionen entfernen. Behalte nur die Teile, die für deine spezifische Anwendung funktionieren. Das könnten also einige interessante Abstraktionen oder Systemaufforderungen sein. Das wäre dann dein Ausgangspunkt. Danach möchtest du die Implementierung entsprechend deinen eigenen Anforderungen weiterentwickeln. Also baue einfach diesen Ausgangspunkt auf, nicht die endgültige Implementierung. So, das ist ein Weg, Frameworks oder Abstraktionen in deinen Systemen zu nutzen. Als nächstes schauen wir uns einige Ideen an, wie man diese Systeme erstellt. Der erste Schritt ist einfach anzufangen. Ich habe festgestellt, dass Leute versuchen, diese Systeme von Anfang an zu überkonstruieren. Zuerst sollte man einen einfachen Einzelagenten bauen. Selbst bei Systemen mit mehreren Agenten stellen sie sicher, dass ein einfacher Agent für ihre Anwendung geeignet ist und als Ausgangspunkt dient. Anschließend müssen sie, wie bei jedem anderen herkömmlichen maschinellen Lernsystem, das Verhalten ihres Systems beobachten. Welche Funktionalitäten müssen unterstützt werden? Das müssen sie verstehen und dann basierend auf ihren Beobachtungen iterieren. Richtig. Ein einfaches Beispiel wä Sie führen ein Update durch, beobachten es und verwenden für die Beobachtung einen Bewertungsdatensatz. Dieser muss nicht riesig sein. 10 bis 15 Beispiele für die Art von Verhalten, die Sie sehen möchten, reichen aus. Erstellen Sie zu Beginn einen Bewertungsdatensatz. Fangen Sie mit kleineren Daten an, sehen Sie, welche Funktionen funktionieren und welche nicht und versuchen Sie dann, die fehlenden Funktionen zu beheben. Gleichzeitig sollten Sie auch Ihren Bewertungsdatensatz iterieren. Fügen Sie immer mehr Beispiele hinzu und dann muss dieser Zyklus mehrmals wiederholt werden, bis Sie ein System erhalten, das gut genug für Ihre Anwendung ist. Der dritte Punkt ist die Funktionalität, also Funktionalität vor Komplexität. Entwickeln Sie einfach ein funktionierendes System. Priorisieren Sie die Nützlichkeit, vermeiden Sie anfängliche Überkonstruktionen und einige dieser Frameworks und Abstraktionen werden Sie tatsächlich dazu zwingen, Ihre Systeme zu überkonstruieren. Richtig. Deshalb empfehle ich dringend, einfach anzufangen und dann nach Bedarf immer mehr Komplexität hinzuzufügen. OK. Der letzte Teil ist die Eingabeaufforderung. An erster Stelle stehen Klarheit und Eingabeaufforderungen. Priorisieren Sie also Klarheit und Eingabeaufforderungen, die das Modell verstehen kann, und ich kann dies nicht genug betonen. Eines der größten Probleme, das ich in der Praxis sehe, ist, dass die Leute denken, dass diese Sprachmodelle magische Systeme sind. Wenn die Kapazität oder die Fähigkeiten dieser Sprachmodelle oder der generativen KI im Allgemeinen zunehmen, werden Sie unsere Eingabeaufforderungen irgendwie verstehen. Das ist nicht der Fall, insbesondere bei den Schlussfolgerungsmodellen. Sie müssen äußerst spezifisch sein und Sie möchten nicht, dass diese Modelle Annahmen über ihre Absicht oder ihr Problem treffen. Eine Möglichkeit, dies zu tun, besteht darin, dass Sie bei der Planung von Agenten wie das Modell denken und sich überlegen, wie die Aktionen für den Agenten aussehen werden. Versetzen Sie sich also in die Lage des Modells oder des Agenten und sehen Sie, wie verschiedene Aktionen für diesen Agenten aussehen werden. Die Idee wäre also, dass Sie in der Eingabeaufforderung so viel Klarheit wie möglich und so viele Hinweise wie möglich bereitstellen möchten, damit das System keine Annahmen trifft. Im Moment habe ich festgestellt, dass Viele Leute nur 5 bis 10 Zeilen Systemeingabeaufforderung schreiben. Das ist ein Rezept für eine Katastrophe. In Ihrer Systemeingabeaufforderung sollten Sie dem Modell alles mitteilen, was Sie tun möchten. Insbesondere sollten Sie viele kurze Beispiele für die Art des gewünschten Verhaltens hinzufügen. Richtig. Ich kann dies nicht oft genug betonen. Ich habe dies in der Praxis gesehen und es kann tatsächlich zu unerwünschtem Verhalten führen. Vergessen Sie nicht die Tools. In der Praxis habe ich gesehen, dass Leute in einigen Fällen recht gute Systemeingaben schreiben. Richtig. Aber wenn es um die Beschreibungen der Tools oder die Parameter geht, die an die Tools übergeben werden sollen, schreiben Sie keine guten Toolbeschreibungen. Richtig. Aber das Modell oder der Agent trifft Entscheidungen auf Grundlage der von Ihnen bereitgestellten Toolbeschreibung, basierend auf der Beschreibung der Eingabe Ausgabe. Daher sollten Sie dafür wirklich viel Zeit aufwenden. Eine Möglichkeit, dies zu tun, besteht darin, zunächst Ihre Tools oder einen kleinen Satz von Tools zu erstellen, dann einige Bewertungsaufforderungen auszuführen und zu prüfen, ob das Modell das richtige Tool auswählt oder nicht. Anschließend sollten Sie eine Fehleranalyse durchführen, um das Verhalten zu verstehen. Wenn nicht das richtige Tool ausgewählt wird, sollten Sie es untersuchen. OK. Ist die Toolbeschreibung mehrdeutig. Aus diesem Grund wird das Tool nicht ausgewählt oder die Modellfunktionen sind für dieses spezifische Problem nicht gut genug. Richtig. Daher sollten Sie bei der Erstellung dieser Systeme immer eine Menge Fehleranalysen durchführen. Der letzte Punkt, den ich betonen möchte, ist LLM Anwendungen oder Agentenanwendungen als Softwareentwicklungsprozesse zu behandeln. Genau wie bei der Softwareentwicklung sind Tests und Feedback entscheidend. Iterative Verfeinerung unerlässlich für jedes Agentensystem. Richtig. Und ich werde es noch einmal Das sind keine magischen Systeme. Glauben Sie nicht dem Hype, dass wir AGI oder ähnliches haben. Richtig. Das sind extrem fragile Systeme. Jeder, der schon einmal agentenbasierte Systeme erstellt und in Produktion genommen hat, weiß, wie fragil diese sind. Richtig. Sie sollten also wirklich gute Softwareentwicklungspraktiken anwenden. Iterative Verfeinerung anhand des Systemfeedbacks und notwendiger Weiterentwicklungen ist erforderlich. OK. Ich werde es also noch einmal wiederholen. Verwenden Sie keine Agenten, wenn Sie sie nicht benötigen. Frameworks eignen sich gut für erste PCs oder Proof of Concepts, doch danach sollte man sie zugunsten optimaler Systeme verlassen. Als nächstes fangen Sie einfach an. Versuchen Sie nicht von Anfang an zu viel zu entwickeln. Verstehen Sie Ihren Problembereich. Entwickeln Sie Ihre erste Lösung. Erhalten Sie Feedback basierend auf dem Bewertungs oder Testdatensatz. Und das letzte ist die Eingabeaufforderung. Die Eingabeaufforderung ist einer der wichtigsten Aspekte. Sie müssen wirklich auf die Anweisung achten, die Sie Ihrem LLM geben. Auch dies sind keine magischen Systeme und ich habe diese Erfahrung gemacht. Die Leute denken, dass diese Modelle unsere Absichten verstehen könnten. Das ist nicht der Fall. Selbst Wenn Sie sich OpenAI ansehen, das kürzlich seinen eigenen Leitfaden für Eingabeaufforderungen veröffentlicht hat, hat Google seinen eigenen Leitfaden für Eingabeaufforderungen. Entropic hat seinen eigenen Leitfaden für Eingabeaufforderungen. Richtig. Das Problem ist, wenn Sie ein LLM ändern, unterscheidet sich die Art und Weise, wie Sie ein LLM von Entropic anweisen, stark von der Art und Weise, wie Sie ein LLM von OpenAI anweisen. Daher ändert sich auch die Art der Anweisungen. Je nach Modell, schlussfolgernd oder nicht, unterscheidet es sich auch innerhalb desselben Unternehmens. Die Anleitung eines O Serie Modells unterscheidet sich stark von der eines GPT Serie Modells. Hier spielen die Eingabeaufforderungen eine sehr wichtige und entscheidende Rolle und Sie möchten sicherstellen, dass Ihre systemeingabeaufforderungen optimiert sind. Sie sollten sicherstellen, dass Ihre Toolbeschreibungen optimiert sind. Die Eingabe und Ausgabedaten dieser Tools sind optimiert. Sie möchten nicht, dass das LM mehrdeutige Entscheidungen trifft. Die Anzahl der Tools habe ich noch nicht erwähnt. Sie sollten also sicherstellen, dass Sie die Anzahl der Tools begrenzen. Selbst wenn Sie über viele Tools verfügen, könnten Übergaben zwischen den Agenten eine weitere Möglichkeit sein. MCP ist wahrscheinlich eine weitere Option. Wenn Sie jedoch ähnlich klingende Namen für Tools oder ähnliche Beschreibungen für die Tools haben, stellen Sie sicher, dass es genügend Differenzierung gibt, damit das Modell nicht verwirrt wird. OK, das war also der Vortrag, den ich als nächstes bei Google halte. Um genau zu sein. Ich habe jetzt auch eine Website. Sie ist noch in Arbeit, aber Sie können sie sich gerne ansehen. Außerdem biete ich meine Beratungsdienste für Start ups und Unternehmen an. Wenn Sie also agentenbasierte Systeme erstellen und Hilfe bei deren Optimierung benötigen, können Sie sich an mich wenden. Einzelheiten finden Sie in der Videobeschreibung oder auf der Website. Wie auch immer. Ich hoffe, Sie fanden dieses Video hilfreich. Danke fürs Zuschauen und wie immer bis zum nächsten Mal.