Aman Khan argues AI agents need metrics, not gut feelings. He breaks down agent architecture, introduces Drive Coding as a metric-driven approach, and uses a travel-agent example to show how consistency beats subjective vibe checks when building systems that scale.
Wie geht es euch allen? Gut, Super cool. Also legen wir los. M Mein Name ist Aman. Wie Jeff erwähnt hat, haben wir einen Kurs mit Deep Learning AI zur Evaluierung von KI Agenten gemacht. Ich arbeite bei Arise. Wir unterstützen einige der größten Technologieunternehmen bei der Entwicklung von KI Agenten, verstehen die Funktionsweise ihrer Anwendungen und Agenten und unterstützen sie bei der Ausführung von Evaluierungsagenten. Die Tools, über die wir heute sprechen, sind alle Open Source. Wir haben beispielsweise ein Open Source Tool namens Fenix. Einige davon werden Sie auf späteren Folien sehen. Ich entschuldige mich schon mal, weil wir die erste Hälfte der Folien etwas schnell durchgehen. Die gute Nachricht ist, dass ein Großteil der ersten Hälfte aus unserem Kurs zu Deep Learning I stammt. Das Das schafft sozusagen den Kontext dafür, wie die Entwicklung und Evaluierung eines Agenten aussieht. Im zweiten Teil sprechen wir über die Optimierung von Eingabeaufforderungen für EV Ventile und wie man robuste Eingabeaufforderungen erstellt. Es wird praxisnah. Wenn Sie also Ihre Laptops dabei haben, finden Sie Links, über die Sie mitmachen können. Super. Und damit legen wir los. Wir haben das alle schon erlebt, oder? Wir alle kennen diesen Typen oder diese Person, die gerade einen KI Agenten steuert, um etwas auszuliefern und man sieht ihm an, dass er sich einfach nicht gut fühlt. Das ist übrigens ein echtes Imagejuwel. Googles neues Imagemodell wirklich gut. Und ich denke, das Konzept hier ist Jeder versucht schnell etwas auf den Markt zu bringen. Es ist also sinnvoll, sich ein paar Beispiele anzusehen, während Sie gerade einen Chatbot oder einen Agenten ausliefern und es sieht gut aus oder gefällt mir, Es ist in Ordnung. Ich möchte heute einen Begriff vorstellen, den wir immer häufiger verwenden. Habt Geduld. Ich stelle ihn euch vor. Was wäre, wenn wir statt mit Vibes Drive Coding betreiben würden? Ihr seht, diese Person wirkt deutlich zufriedener. Das liegt daran, dass sie Kennzahlen auf dem Bildschirm hat. Sie sieht sich Daten an, während sie Code schreibt und Entscheidungen trifft. Ich denke, es ist an der Zeit, vom V Coding zum Drive Coding zu wechseln. Das ist meine Meinung. V es ja erst letzte Woche. Also cool. Was ist also der Unterschied zwischen diesen beiden Dingen? Ich denke tatsächlich, dass man beim Coden Vype Coding betreibt. Es geht um den Übergang von subjektiv zu empirisch. Das bedeutet, was für mich gut aussieht zu etwas, das aus Metrik Sicht etwas robuster ist. Man möchte auch mehr Daten verwenden, denn wenn man etwas ausliefert, eine Key App für Freunde oder sich selbst, sehen fünf bis zehn Datenzeilen vielleicht gut aus. Aber was passiert, wenn morgen 100 Nutzer die App nutzen? Wie baut man also ein System, das aus Evaluierungssicht mitwächst? Und dann will man Konsistenz statt Subjektivität. Das sind also die drei Prinzipien, über die wir sprechen werden. Die Beispiele, die ich durchgehen werde, sind für einen allgemeinen KI Agenten gedacht. Man kann sich also einige der Frameworks und Tools, die wir verwenden, vorstellen und diese auch für seine eigenen Anwendungsfälle interpolieren. Verlieren Sie sich also nicht zu sehr in einem konkreten Beispiel. OK, nehmen wir also ein erstes Beispiel. Nehmen wir den neuen Reiseagenten. Wie sieht es also aus, in dieser neuen Welt ein Reisebüro zu nutzen? Dieser Agent nimmt möglicherweise Benutzereingaben entgegen, beispielsweise über eine Chat Schnittstelle. Der Benutzer erhält möglicherweise Eingabeaufforderungen, um ein personalisiertes Erlebnis zu schaffen, und der Agent kann dann tatsächlich Maßnahmen ergreifen. Das sind die drei Komponenten, die wir bei Agenten berücksicht Eingabe Schnittstelle, Eingabeaufforderung, Argumentation oder Gedächtnis. Und dann gibt es Tool und API Aufrufe. Wir werden dies weiter in die drei Komponenten unterteilen, die wir bei der Bewertung von KI Agenten berücksichtigen. Die erste ist der Router. Er ist die Komponente, die den Großteil der Argumentation übernimmt, um anhand einer Frage zu entscheiden, was zu tun ist. Ein Benutzer möchte beispielsweise einen Flug nach San Francisco buchen. Die erste Frage Wann möchte ich diesen Flug buchen? Muss ich weitere Informationen anfordern oder habe ich die benötigten Informationen bereits? Hier sitzt die Reasoning Komponente und entscheidet, was als nächstes zu tun ist. Als Nächstes gibt es Skills bzw. Ausführung und Verzweigungen. Das ist die Logikkette, die im Wesentlichen fragt, ob eine bestimmte API aufgerufen oder ein API Aufruf erstellt werden muss. Und dann ist da noch der Speicherzustand, also die eigentlichen Daten, die in das System eingegeben werden. Benötige ich also bestimmte Informationen vom Benutzer, die ich möglicherweise bereits im Verlauf meiner Konversation gespeichert habe. Wenn wir also über die Komponenten des Agenten nachdenken, würde ich das so Der Router bestimmt im Wesentlichen, welche Skills als nächstes verwendet werden. Ganz Er bestimmt, welche Skills basierend auf der Benutzeranfrage verwendet werden. Sobald Sie herausgefunden haben, welche Fähigkeiten Sie benötigen, könnten beispielsweise mehrere API Aufrufe erforderlich sein. Diese können entweder in einer Schleife oder in einer Graph Schnittstelle aufgerufen werden, in einer Art Graph Format. Die Ausgestaltung liegt ganz bei Ihnen, nicht wahr? Ein Großteil der Logikstruktur ist sozusagen das Geheimnis Ihres Agenten. Wie soll auf diese Tools zugegriffen werden? Gibt es LLM Aufrufe? Gibt es API Aufrufe? Gibt es anwendungsspezifischen Code?
