Ich habe diesen Leitfaden als die Anleitung geschrieben, die ich mir vor meinem Wechsel in die Angewandte KI-Entwicklung gewünscht hätte.
Die Rolle überschneidet sich weitgehend mit der traditionellen Softwareentwicklung, fügt aber einige wichtige Konzepte hinzu, die die meisten Softwareentwickler erst beim Übergang lernen müssen. Ich empfehle dir, dies als eine Übersicht der Kernthemen zu nutzen, die du verstehen musst, und dann die verlinkten Ressourcen im Artikel zu vertiefen, wenn du tiefer eintauchen möchtest.
Am Ende solltest du ein viel klareres Verständnis davon haben, was Angewandte KI-Entwicklung ist, was der Job tatsächlich erfordert und wie er über die traditionelle Softwareentwicklung hinausgeht.
Wenn du daran interessiert bist, an einigen der spannendsten Probleme der Angewandten KI mit einem sehr talentierten Entwicklungsteam zu arbeiten, sind wir immer auf der Suche. Bewirb dich auf unserer Website unter varickagents.com oder empfiehl einen Kandidaten für eine Prämie von 20.000 $.
Der beste Weg, Angewandte KI-Entwicklung zu verstehen, ist jedoch, mit der Veränderung zu beginnen, wie du über die Entwicklung von Software denkst.
Softwareentwicklung vs. KI-Entwicklung
Der größte Unterschied zwischen einem SWE und einem KI-Ingenieur ist, dass traditionelle Softwareentwicklung dich lehrt, deterministisch zu denken, während angewandte KI dich zwingt, probabilistisch zu denken.
In der normalen Software schreibst du die Logik, bringst sie zum Laufen, und wenn etwas kaputt geht, kannst du es in der Regel zurückverfolgen – eine strukturierte Eingabe liefert deterministisch eine strukturierte Ausgabe.
Angewandte KI funktioniert nicht so. Du baust um einen nicht-deterministischen API-Aufruf an Intelligenz herum, was bedeutet, dass dieselbe Eingabe jedes Mal anders zurückkommen kann. Aus diesem Grund besteht der Job nicht mehr nur darin, die Software zu bauen, sondern zu messen, ob sich das System tatsächlich so verhält, wie es soll.
Das tun wir durch Evals, also werde ich aufschlüsseln, wie man eine Evaluierungssuite aufbaut, die sicherstellt, dass der von dir entwickelte Agent keine Fehler macht. Ich habe gelernt, dass dies eine der wichtigsten Fähigkeiten eines Angewandten KI-Entwicklers ist, angesichts der nicht-deterministischen Natur unserer Arbeit.
Der nächste Teil des Artikels behandelt die Entwicklung jedes Teils eines KI-Agenten (außer dem Modell selbst, natürlich), denn du kannst eine API eines Modells aufrufen, aber alles andere musst du selbst bauen. Dies wird als Harness-Engineering bezeichnet.
Und zuletzt werde ich behandeln, wie man von einem Agenten in der Produktion zu mehreren übergeht – und warum es ein Problem verteilter Systeme ist. Wenn du es bis zum Ende dieses Artikels schaffst, gibt es keinen Grund, warum du den Übergang zum Angewandten KI-Ingenieur nicht schaffen solltest.
Evals
Ein Angewandter KI-Ingenieur verwandelt Unsicherheit in gemessenes Vertrauen durch Evals. In der traditionellen Softwareentwicklung vertraust du dem System, weil du die Logik geschrieben und den Code getestet hast. In der angewandten KI kannst du dem System nicht auf diese Weise vertrauen, weil sich das Modell bei verschiedenen Durchläufen unterschiedlich verhalten kann. Der KI-Ingenieur muss also eine Messschicht um den Agenten herum aufbauen.
Ein Eval ist der Prozess, einem Agenten eine Aufgabe zu geben, ihn ausführen zu lassen und zu bewerten, was er getan hat. Das Ziel ist es, zwei Dinge zu beweisen: Der Agent hat die Arbeit korrekt erledigt, und der Agent hat sich innerhalb der ihm gesetzten Grenzen bewegt.
Der erste Schritt ist die Bewertung des Ergebnisses. Dies ist der einfachste Schritt des Eval-Prozesses. Für einen Rechnungsagenten, mit denen ich normalerweise arbeite, bedeutet das sicherzustellen, dass die Rechnung am richtigen Ort landet oder das Duplikat markiert wird. Du vergleichst einfach das Endergebnis mit dem, was hätte passieren sollen.
Der zweite Schritt ist die Bewertung der Trajektorie. Dies ist der Weg, den der Agent genommen hat, um zu diesem Ergebnis zu gelangen: die Tools, die er aufgerufen hat, die Felder, die er berührt hat, die Argumente, die er übergeben hat, und die Aktionen, die er auf dem Weg versucht hat. Dies ist wichtig, weil ein Agent die richtige endgültige Antwort erreichen kann, während er dabei trotzdem etwas Gefährliches tut. Er kann eine Rechnung korrekt klassifizieren, während er gleichzeitig Bankdaten ändert oder eine Zahlung vor der Genehmigung sendet.
Die Trajektorie selbst ist nur ein Log: eine geordnete Liste jedes Tools, das der Agent aufgerufen hat, und der Argumente, die er übergeben hat – sie zu bewerten bedeutet nur, Prüfungen gegen dieses Log zu schreiben.
Einige Prüfungen sind deterministisch – sicherzustellen, dass send_payment niemals vor einem Genehmigungsaufruf erscheint, zu überprüfen, dass die einzigen Felder, die beschrieben wurden, diejenigen waren, die der Agent beschreiben durfte. Andere sind Beurteilungs-Aufrufe – ob eine Eskalation angemessen war, ob die Begründung die Aktion rechtfertigte. Diese gehen an ein zweites Modell mit einem Bewertungsraster.
Das allgemeine Prinzip ist, dass deterministische Prüfungen in der Regel die Sicherheitsverstöße abfangen, während das Bewertungsmodell die Qualität bewertet.
Das Ergebnis sind zwei Noten pro Testfall: Hat der Agent die richtige Antwort bekommen und hat er sich dabei korrekt verhalten. Diese müssen getrennt gemeldet werden, denn ein Agent, der Rechnungen zu 95 % korrekt klassifiziert, aber in 4 % der Läufe ein verbotenes Feld berührt, sieht in einer gemischten Bewertung großartig aus, verursacht aber in der Produktion erhebliche geschäftliche Komplikationen.
Dieser Artikel dient als Einführung in Evals und alle anderen behandelten Themen, daher habe ich andere Ressourcen verlinkt, die dir helfen, tiefer einzusteigen. Einige, die mir geholfen haben, effektive Evals zu erstellen, sind:
Ich empfehle, jeden davon durchzuarbeiten, aber mit Lennys und Hamels zu beginnen, bevor du den Eval-Kurs (der etwas praktischer ist) durchgehst.
Aber ein Eval braucht immer noch einen Agenten zum Testen, und alles um das Modell herum muss von dir gebaut werden. Dieses umgebende System wird als Harness bezeichnet – der nächste Abschnitt behandelt, wie man über jeden Teil des Harness-Engineering-Prozesses denkt, vom Tool-Aufruf bis zur Kontextfenster-Optimierung.
Harness-Engineering
Ein Modell allein ist kein Agent. Ein Modell kann argumentieren, klassifizieren, schreiben und entscheiden, aber es kann nicht von selbst innerhalb eines Unternehmens operieren. Es kann sagen, welche Aktion durchgeführt werden sollte, aber es kann diese Aktion nicht sicher ausführen, es sei denn, du baust das System darum herum – und dieses System ist der Harness.
Der Harness ist alles um das Modell herum, das einen API-Aufruf in einen funktionierenden Agenten verwandelt: die Tools, die es verwenden kann, den Kontext, den es sieht, den Zustand, den es sich merkt, die Leitplanken, die es einschränken, und die Schleife, die es ihm ermöglicht, weiterzuarbeiten, bis die Aufgabe erledigt ist.
Der erste Teil des Harness ist die Tool-Ausführung.
Modelle lesen und schreiben nur Text. Wenn ein Modell also beschließt, etwas zu tun, führt es es nicht tatsächlich aus. Es gibt eine strukturierte Anfrage (einen JSON-String) aus, um einen Datensatz zu aktualisieren, eine E-Mail zu senden oder eine Datenbank zu durchsuchen.
Der Harness empfängt diese Anfrage, validiert sie, führt die eigentliche Operation aus und sendet das Ergebnis als Text an das Modell zurück.
Der zweite Teil ist das Kontextmanagement. Jede Anweisung, jedes Tool-Menü, jedes Tool-Ergebnis und jede vorherige Nachricht nimmt Platz im Kontextfenster des Modells ein. Der Harness muss entscheiden, was das Modell gerade sehen muss, was zusammengefasst werden sollte und was entfernt werden sollte. Ohne dies verlieren sich Agenten in irrelevanter Historie.
Ich werde einen umfassenderen Artikel schreiben, der tiefer auf jeden Teil des Harness-Entwicklungsprozesses eingeht, aber fürs Erste empfehle ich, diesen Vortrag eines Ingenieurs bei Arize, der kontinuierlichen Lernplattform für Agenten, anzuhören, der tief in ihren Gedankenprozess zum Kontextmanagement eintaucht.
Um mehr über die praktische Anwendung eines effektiven Kontextmanagements für deine Agenten zu erfahren, lies diese Blogs:
- OpenAIs Artikel zum Kontextmanagement
- Ein praktischer Leitfaden zum Kontextmanagement
- Anthropics Leitfaden zum Kontext-Engineering
Der dritte Teil im Harness-Engineering ist Zustand und Gedächtnis. Modelle sind zustandslos zwischen Aufrufen, also muss alles, woran sich der Agent erinnern muss, außerhalb des Modells leben (normalerweise in einer Datenbank, einem Dateispeicher oder einem Aufgabenprotokoll). Kontext ist das, was das Modell gerade ansieht. Zustand ist alles, was der Agent weiß, aber gerade nicht ansieht.
Der vierte Teil sind Leitplanken. Da das Modell die falsche Aktion mit derselben Zuversicht wie die richtige anfordern kann, muss der Harness Berechtigungen überprüfen, Eingaben validieren, unsichere Aktionen blockieren und risikoreiche Schritte an Menschen weiterleiten.
Schließlich wird all dies in der Agentenschleife zusammengeführt: Kontext aufbauen, Modell aufrufen, seine Antwort inspizieren, das Tool ausführen (falls erlaubt), das Ergebnis speichern, den Kontext aktualisieren und wiederholen, bis die Aufgabe erledigt ist.
Harness-Engineering macht den Großteil deiner Arbeit als Angewandter KI-Ingenieur aus, also nimm dir Zeit für diesen Abschnitt. Als Angewandter KI-Ingenieur besteht deine gesamte Aufgabe darin, die Betriebsumgebung zu schaffen, die es einem probabilistischen System ermöglicht, innerhalb deterministischer Software zu arbeiten.
Aber die Produktion hört normalerweise nicht bei einem Agenten auf.
Wenn der Workflow größer wird, ist der natürliche Instinkt, die Arbeit aufzuteilen. Aber sobald du einen zweiten Agenten hinzufügst, ändert sich das Systemdesign.
Bei einem Agenten liegt die meiste Komplexität innerhalb einer Schleife. Bei mehreren Agenten hast du jetzt mehrere Schleifen, die in derselben Umgebung agieren. Jeder Agent kann einen Zustand lesen, den ein anderer Agent gerade geändert hat, in einen Speicher schreiben, von dem ein anderer Agent abhängt, oder ein Tool aufrufen, dessen Ergebnis den gesamten Workflow beeinflusst.
An diesem Punkt ist der schwierige Teil nicht mehr nur Prompting, Evals oder Harness-Design. Es wird zu einem Problem verteilter Systeme: Wem gehört welcher Zustand, wer kann in den Speicher schreiben, welche Tools sind sicher zu wiederholen, und was passiert, wenn zwei vernünftige Agenten Aktionen in der falschen Reihenfolge ausführen.
Multi-Agenten-Bereitstellungen sind ein Problem verteilter Systeme
Wenn der erste Agent funktioniert und der Workflow größer wird, hat ein neuer Angewandter KI-Ingenieur natürlich den Instinkt, die Arbeit in Rollen aufzuteilen: Ein Agent recherchiert, einer plant, einer führt aus, einer überprüft.
Aber der zweite Agent ändert die Designeinheit vom Agenten zum System. Mehrere Schleifen agieren jetzt in derselben Umgebung – ein Agent kann den Kundenstatus aktualisieren, während ein anderer mitten in der Planung gegen den veralteten Status schreibt. Beide haben vernünftige Entscheidungen getroffen, aber das System ließ diese Entscheidungen in der falschen Reihenfolge interagieren.
Dies ist ein Problem verteilter Systeme. Die gute Nachricht ist, dass Ingenieure für verteilte Systeme diese Fehler vor Jahrzehnten gelöst haben. Deine Aufgabe ist es, sie auf Schleifen anzuwenden, die zufällig ein LLM enthalten. Unten ist eine Liste von Lösungen aus verteilten Systemen, die auf die KI-Entwicklung anwendbar sind:
Single-Writer-Prinzip. Jeder wichtige Zustand hat genau einen Agenten, der ihn schreiben kann – andere Agenten lesen daraus oder reichen Änderungsanfragen ein. Setze dies auf Tool-Ebene durch: Wenn der Ausführungsagent der einzige ist, der in das CRM schreiben kann, kann der Recherche-Agent das CRM nicht korrumpieren, egal wie schlecht er argumentiert.
Idempotenzschlüssel. Agenten wiederholen Tool-Aufrufe, wenn etwas fehlschlägt oder eine Zeitüberschreitung auftritt, aber Wiederholungen können gefährlich sein, wenn das Tool etwas in der realen Welt ändert. Du möchtest nicht, dass ein Agent dieselbe Zahlung zweimal sendet, nur weil die erste Anfrage wie ein Fehlschlag aussah. Die Lösung ist, jedem mutierenden Tool-Aufruf – also jeder Aktion, die Daten in einem externen System ändert – einen eindeutigen Schlüssel anzuhängen. Wenn das Tool denselben Schlüssel erneut sieht, sollte es das ursprüngliche Ergebnis zurückgeben, anstatt die Aktion ein zweites Mal auszuführen. Stripes API funktioniert so – und das überträgt sich auf die Agentenentwicklung, wenn es um Zahlungen, E-Mails usw. geht.
Vorbedingungen für Schreibvorgänge. Agenten handeln oft auf der Grundlage einer alten Sicht der Welt. Zwischen dem Zeitpunkt, an dem der Agent seinen Plan erstellt hat, und dem Zeitpunkt, an dem er versucht, ein externes System zu aktualisieren, kann sich etwas geändert haben. Um veraltete Schreibvorgänge zu verhindern, sollten mutierende Tools eine Bedingung erfordern, bevor sie die Änderung vornehmen. Zum Beispiel: „Setze den Status nur auf „Genehmigt“, wenn er noch „Ausstehend“ ist.“ Wenn sich der Status bereits geändert hat, sollte das Tool klar fehlschlagen, anstatt den neueren Zustand stillschweigend zu überschreiben.
Explizite Übergaben. Gib Arbeit als Nachrichten mit einem definierten Schema weiter, sequenziert durch einen Orchestrator. Ein Agent sollte seine Aufgabe erhalten, nicht entdecken.
Zusammenfassung
Dieser Artikel dient als Überblick über die wichtigsten Themen, die ich als Angewandter KI-Ingenieur gelernt habe: Evals, Harness-Engineering und Multi-Agenten-Systemdesign.
Wenn du etwas mitnimmst, dann dies – das Modell liefert die Intelligenz, aber alles, was es zuverlässig macht (die Messschicht, die Betriebsumgebung, die Koordinationsregeln), wird von dir entwickelt. Verstehe diese Dinge, und der Übergang von der Softwareentwicklung wird zu einer Erweiterung der Fähigkeiten, die du bereits hast.
Wenn du an dieser Art von Arbeit interessiert bist und einige der interessantesten Probleme der Angewandten KI mit einem sehr talentierten Entwicklungsteam angehen möchtest, sind wir immer auf der Suche. Bewirb dich auf unserer Website unter varickagents.com, und wir könnten dich so schnell wie möglich einstellen. Wenn du einen erfolgreichen Kandidaten empfiehlst, geben wir dir eine Prämie von 20.000 $.
