Die Aufregung beim ersten funktionierenden Prototypen im Haus. Die Spannung beim Start in der Produktion für Kunden. Die Frustration, als es zunächst Schwierigkeiten gab, sich auf alle realen Szenarien zu verallgemeinern. Und schließlich der Stolz, als wir eine gewisse Basisstabilität und Leistung über verschiedene Datenquellen und Unternehmen hinweg erreicht haben. Der Bau von KI-Agenten im vergangenen Jahr war eine Achterbahnfahrt, und wir befinden uns zweifellos noch am Anfang dieser neuen Technologie-Welle. Hier ist eine kleine Übersicht über das, was ich bisher gelernt habe.
Definitionen
Zunächst sollte ich erklären, worüber ich spreche. Um die Worte eines Twitter-Nutzers zu übernehmen:
Was zum Teufel ist „Agent“?
Ich habe versucht, meine eigene so kurz wie mögliche Definition zu finden:
Meine Definition eines „KI-Agenten“ lautet:
-
Nimmt Anweisungen entgegen (d.h. vom Menschen vorgegebene Ziele)
-
Hat mehrere Tools zur Verfügung, die er nutzen kann (d.h. API-Aufrufe, Kontextabfragen usw.)
-
Entscheidet selbstständig, wie und wann er seine Tools einsetzt, um die Anweisungen auszuführen.
Diese Definition stimmt im Allgemeinen mit dem überein, was OpenAI als „GPTs“ in ChatGPT und „Assistants“ in ihrer API bezeichnet. Sie können jedoch einen Agenten mit jedem Modell erstellen, das in der Lage ist, zu schlussfolgern und Tool-Anrufe zu tätigen, einschließlich Claude von Anthropic, Command R+ von Cohere und vielen mehr.
Hinweis: „Tool-Anrufe“ sind eine Möglichkeit für ein Modell, auszudrücken, dass es eine bestimmte Aktion ausführen und eine Antwort zurückerhalten möchte, wie z.B. get_weather_forecast_info(seattle)
oder wikipedia_lookup(dealey plaza)
.
Um einen Agenten zu erstellen, benötigen Sie nur einige Zeilen Code, die einen Gesprächsbeginn mit einem Ziel und einer Agenten-Systemaufforderung, einen Modellaufruf für eine Fertigstellung, die Behandlung von Tool-Anrufen, die das Modell tätigen möchte, in einer Schleife ausführen und das Beenden, wenn es mit seiner Arbeit fertig ist.
Hier ist eine visuelle Darstellung, um den Ablauf zu erläutern:
Beschriftung: Über-vereinfachte visuelle Darstellung zum Erstellen eines Agenten
Beispiel für eine Agenten-Systemaufforderung
Du bist Rasgo, ein KI-Assistent und <rotaktig> mit Produktionszugriff auf die Datenbank des Benutzers. Dein Wissen ist sowohl umfassend als auch tiefgreifend. Du hilfst dem <rotaktig>-Team bei der Analyse ihrer Daten in <rotaktig>.
DEIN PROZESS
1. Du bist der Experte. Du hilfst dem Benutzer, seine Daten korrekt zu verstehen und zu analysieren. Sei proaktiv und antizipiere, was sie benötigen. Gib nicht nach deinem ersten Fehlschlag auf. Schlussfolgere und löse Probleme für sie.
2. Denke sorgfältig darüber nach, wie du dem Benutzer helfen kannst, sein Ziel zu erreichen. Führe deinen Plan autonom aus. Wenn du deinen Plan ändern musst, erkläre warum und teile den neuen Plan mit dem Benutzer.
3. <rotaktig
...
>
DEINE REGELN
1. Wenn du dir nicht sicher bist, welche Spalte / Tabelle / SQL zu verwenden ist, frage nach einer Klärung
2. Beurteile, ob die verfügbaren Daten verwendet werden können, um die Frage des Benutzers zu beantworten. Wenn nicht, stoppe und erkläre warum dem Benutzer
3. <rotaktig
...
>
Es ist auch wertvoll, hervorzuheben, was ein KI-Agent nicht ist:
- Skriptgesteuert: Agenten, nach meiner Definition, folgen keiner vorgegebenen Reihenfolge von Schritten oder Tool-Anrufen, da der Agent für die Auswahl des richtigen Tool-Anrufs verantwortlich ist.
- Künstliche Allgemeine Intelligenz (AGI): Agenten sind keine AGI, und eine AGI wird keine Agenten für bestimmte Arten von Arbeit benötigen, da sie eine einzelne Entität mit allen möglichen Eingaben, Ausgaben und Tools zur Verfügung hat (meine Meinung ist, dass keine der aktuellen Technologien auch nur in der Nähe davon ist).
- Black Box: Agenten können und sollten ihre Arbeit auf die gleiche Weise zeigen, wie ein Mensch es tun würde, wenn Sie ihm Aufgaben delegieren.
Kontext
Meine Erkenntnisse aus dem ersten Jahr der Arbeit an KI-Agenten stammen aus erster Hand von der Zusammenarbeit mit unseren Ingenieuren und UX-Designern, während wir an unserer gesamten Produkterfahrung gearbeitet haben. Unser Ziel: eine Plattform für Kunden, um unsere Standard-Datenanalyse-Agenten zu nutzen und benutzerdefinierte Agenten für bestimmte Aufgaben und Datenstrukturen zu erstellen, die für ihr Unternehmen relevant sind. Wir stellen Verbindungen zu Datenbanken (z.B. Snowflake, BigQuery, etc.) mit integrierter Sicherheit, Tool-Anrufe für RAG über eine Metadaten-Schicht, die den Inhalt der Datenbank beschreibt, und Tool-Anrufe für die Analyse der Daten über SQL, Python und Datenvisualisierung bereit.
Das Feedback darüber, was funktioniert hat und was nicht, stammt sowohl aus unseren eigenen Bewertungen als auch aus Kundenfeedback. Unsere Benutzer arbeiten für Fortune-500-Unternehmen und nutzen unsere Agenten jeden Tag, um ihre internen Daten zu analysieren.
Was ich über Agenten gelernt habe
1. Schlussfolgern ist wichtiger als Wissen
Dieses Zitat hallt mir seit den letzten 12 Monaten im Kopf herum:
Ich vermute, dass zu viel der Rechenleistung [von gpt] dafür verwendet wird, das Modell als Datenbank zu verwenden, anstatt es als Schlussfolgerungs-Engine zu nutzen.
— Sam Altman auf Lex Fridman’s Podcast
Agenten sind die angemessene Antwort darauf! Und ich würde diese Logik beim Bau eines Agenten wie folgt anwenden:
Konzentriere dich weniger darauf, was dein Agent „weiß“, und mehr auf seine Fähigkeit zu „denken“.
Nehmen wir zum Beispiel das Schreiben von SQL-Abfragen. SQL-Abfragen schlagen häufig fehl. In meiner Zeit als Data Scientist hatte ich sicherlich viel mehr Abfragen, die fehlschlugen, als solche, die erfolgreich waren. Wenn eine komplizierte SQL-Abfrage auf echten Daten, die Sie noch nie zuvor verwendet haben, beim ersten Mal funktioniert, sollte Ihre Reaktion „Oh Mist, etwas ist wahrscheinlich falsch“ sein, anstatt „Wow, ich hab’s geschafft“. Selbst auf einem Text-zu-SQL-Benchmark, der bewertet, wie gut Modelle eine einfache Frage in eine Abfrage übersetzen, erreicht es nur eine Genauigkeit von 80 %.
Wenn Sie also wissen, dass die Fähigkeit Ihres Modells, eine genaue SQL-Abfrage zu schreiben, einer B-minus entspricht, wie können Sie dann die Schlussfolgerung optimieren? Konzentrieren Sie sich darauf, dem Agenten Kontext zu geben und ihn „denken“ zu lassen, anstatt zu hoffen, dass er die Antwort beim ersten Mal richtig hat. Wir stellen sicher, dass wir alle SQL-Fehler zusammen mit so viel Kontext wie möglich zurück an den Agenten geben, wenn seine Abfrage fehlschlägt… was es dem Agenten ermöglicht, das Problem zu lösen und den Code zum Laufen zu bringen, in den meisten Fällen. Wir geben unserem Agenten auch eine Reihe von Tool-Anrufen, um Kontext über die Daten in der Datenbank abzurufen, ähnlich wie ein Mensch die Informationsschema studieren und die Daten auf Verteilungen und fehlende Werte profilieren würde, bevor er eine neue Abfrage schreibt.
2. Die beste Möglichkeit, die Leistung zu verbessern, besteht darin, die Agent-Computer-Schnittstelle (ACI) zu iterieren
Der Begriff ACI ist neu (eingeführt in dieser Forschung aus Princeton), aber die Konzentration auf die Perfektionierung war Teil unseres Alltags in den letzten 12 Monaten. Die ACI bezieht sich auf die genaue Syntax und Struktur der Tool-Anrufe des Agenten, einschließlich sowohl der Eingaben, die der Agent generiert, als auch der Ausgaben, die unsere API als Antwort darauf sendet. Dies sind die einzige Möglichkeit für den Agenten, mit den Daten zu interagieren, die er benötigt, um Fortschritte in Übereinstimmung mit seinen Anweisungen zu erzielen.
Da die zugrunde liegenden Modelle (gpt-4o, Claude Opus, etc.) unterschiedliches Verhalten aufweisen, funktioniert die ACI, die für eines gut funktioniert, nicht unbedingt für ein anderes. Dies bedeutet, dass eine großartige ACI so viel Kunst wie Wissenschaft erfordert… sie ist eher wie das Entwerfen einer großartigen Benutzererfahrung als das Schreiben von Quellcode, da sie sich ständig weiterentwickelt und kleine Änderungen sich zu einem 30-Autos-Unfall auswachsen können. Ich kann nicht genug betonen, wie wichtig die ACI ist… wir haben unsere Hunderte von Malen iteriert und massive Schwankungen in der Leistung unseres Agenten mit scheinbar kleinen Änderungen an den Namen, der Menge, dem Abstraktionsgrad, den Eingabeformaten und den Antwortreaktionen unserer Tools gesehen.
Hier ist ein kleines, spezifisches Beispiel, um zu veranschaulichen, wie kritisch und launisch Ihre ACI sein kann: Beim Testen unseres Agenten auf gpt-4-turbo kurz nach seiner Veröffentlichung haben wir ein Problem festgestellt, bei dem er die Existenz bestimmter Spalten, die wir versucht haben, ihm über einen Tool-Anruf mitzuteilen, vollständig ignorierte. Wir verwendeten ein Markdown-Format für diese Informationen, das direkt aus den OpenAI-Dokumenten zu diesem Zeitpunkt stammt und gut mit gpt-4–32k auf denselben Daten funktioniert hat. Wir haben einige Anpassungen an unserer Markdown-Struktur vorgenommen, um dem Agenten zu helfen, die Spalten zu erkennen, die er so tat, als ob sie nicht existieren, obwohl sie in der Antwort auf einen der Tool-Anrufe, die er tätigte, waren. Keine der Änderungen hat funktioniert, also mussten wir anfangen, mit ganz anderen Formaten für die Informationen zu experimentieren… und nach einer Überarbeitung, um mit JSON anstelle von Markdown (nur für OpenAI-Modelle) zu beginnen, funktionierte alles wieder großartig. Ironischerweise erforderte die JSON-strukturierte Antwort aufgrund aller Syntaxzeichen deutlich mehr Tokens, aber wir fanden heraus, dass sie notwendig und sogar entscheidend war, um dem Agenten zu helfen, die Antwort zu verstehen.
Die Iteration Ihrer ACI mag trivial erscheinen, aber es ist tatsächlich eine der besten Möglichkeiten, die Benutzererfahrung Ihres Agenten zu verbessern.
3. Agenten sind durch ihre Modell(e) begrenzt
Die zugrunde liegenden Modell(e), die Sie verwenden, sind das Gehirn des Körpers Ihres Agenten. Wenn das Modell schlecht darin ist, Entscheidungen zu treffen, werden alle guten Aussehen der Welt Ihre Benutzer nicht glücklich machen. Wir haben diese Einschränkung aus erster Hand erlebt, als wir unseren Agenten gleichzeitig auf gpt-3.5-turbo und gpt-4–32k getestet haben. Auf 3.5 hatten wir eine Reihe von Testfällen, die ungefähr so ausgesehen haben:
- Der Benutzer hat ein Ziel angegeben, z.B.: „Analysieren Sie die Korrelation zwischen Starbucks-Standorten und Hauspreisen nach Postleitzahl, um zu verstehen, ob sie miteinander zusammenhängen.“
- Der Agent hat angenommen, dass eine Tabelle mit einem Namen, den er sich ausgedacht hat, wie „HOME_PRICES“, und Spalten wie „ZIP_CODE“ und „PRICE“ in der Datenbank existiert, anstatt eine Suche durchzuführen, um die tatsächliche Tabelle zu finden.
- Der Agent hat eine SQL-Abfrage geschrieben, um den durchschnittlichen Preis nach Postleitzahl zu berechnen, die fehlgeschlagen ist, und eine Fehlermeldung erhalten, die besagt, dass die Tabelle nicht existiert.
- Der Agent hat sich daran erinnert, „oh ja, ich kann nach tatsächlichen Tabellen suchen…“ und hat eine Suche nach „Hauspreisen nach Postleitzahl“ durchgeführt, um eine echte Tabelle zu finden, die er verwenden kann.
- Der Agent hat seine Abfrage mit den richtigen Spalten aus einer echten Tabelle neu geschrieben, und sie hat funktioniert.
- Der Agent hat mit den Starbucks-Standortdaten fortgefahren und den gleichen Fehler noch einmal gemacht.
Die Ausführung des Agenten auf gpt-4 mit denselben Anweisungen war völlig anders. Statt sofort die falsche Aktion auszuführen und Zeit damit zu verbringen, es falsch zu machen, hat der Agent einen Plan mit der richtigen Reihenfolge von Tool-Anrufen erstellt und dann dem Plan gefolgt. Wie Sie sich vorstellen können, war die Leistungslücke zwischen den beiden Modellen bei komplexeren Aufgaben noch größer. So großartig die Geschwindigkeit von 3.5 auch war, unsere Benutzer bevorzugten eindeutig die stärkere Entscheidungsfindung und Analysefähigkeit von gpt-4.
Hinweis: Eine Sache, die wir aus diesen Tests gelernt haben, ist, sehr genau auf die Art und Weise zu achten, wie Ihr Agent halluziniert oder fehlschlägt, wenn es passiert. KI-Agenten sind faul (ich nehme an, dass menschliche Faulheit in den Trainingsdaten für die zugrunde liegenden Modelle gut repräsentiert ist) und werden keine Tool-Anrufe tätigen, die sie nicht für notwendig halten. Ähnlich, wenn sie einen Tool-Anruf tätigen, wenn sie die Argument-Anweisungen nicht gut verstehen, werden sie häufig Abkürzungen nehmen oder erforderliche Parameter vollständig ignorieren. In diesen Fehlermodi steckt viel Signal! Der Agent sagt Ihnen, was er will, dass die ACI ist, und wenn die Situation es zulässt, ist die einfachste Möglichkeit, dieses Problem zu lösen, die ACI zu ändern, um auf diese Weise zu funktionieren. Natürlich gibt es viele Fälle, in denen Sie gegen die Instinkte des Agenten kämpfen müssen, indem Sie Änderungen an der Systemaufforderung oder den Anweisungen für Tool-Anrufe vornehmen, aber für die Fälle, in denen Sie einfach die ACI ändern können, machen Sie sich das Leben viel einfacher.
4. Das Feintuning von Modellen zur Verbesserung der Leistung von Agenten ist eine Zeitverschwendung
Das Feintuning eines Modells ist eine Methode, um die Leistung des Modells bei einer bestimmten Anwendung zu verbessern, indem ihm Beispiele gezeigt werden, aus denen es lernen kann. Aktuelle Feintuning-Methoden sind nützlich, um einem Modell beizubringen, wie es eine bestimmte Aufgabe auf eine bestimmte Weise ausführt, sind aber nicht hilfreich, um die Schlussfolgerungsfähigkeit des Modells zu verbessern. In meiner Erfahrung führt die Verwendung eines feingetunten Modells zur Steuerung eines Agenten tatsächlich zu einer schlechteren Schlussfolgerungsfähigkeit, da der Agent dazu neigt, „seine Anweisungen zu betrügen“ – d.h. er geht davon aus, dass die Beispiele, mit denen er feingetuned wurde, immer den richtigen Ansatz und die richtige Reihenfolge von Tool-Anrufen darstellen, anstatt unabhängig über das Problem nachzudenken.
Hinweis: Feintuning kann immer noch ein sehr nützliches Werkzeug in Ihrem Schweizer Taschenmesser sein. Eine Herangehensweise, die gut funktioniert hat, ist die Verwendung eines feingetunten Modells, um bestimmte Tool-Anrufe zu bearbeiten, die der Agent tätigt. Stellen Sie sich vor, Sie haben ein Modell, das darauf feingetuned ist, SQL-Abfragen auf Ihren spezifischen Daten, in Ihrer Datenbank, auszuführen… Ihr Agent (der auf einem starken Schlussfolgerungsmodell läuft, ohne Feintuning) kann einen Tool-Anruf verwenden, um anzugeben, dass er eine SQL-Abfrage ausführen möchte, und Sie können dies in eine eigenständige Aufgabe übergeben, die von Ihrem Modell bearbeitet wird, das für SQL-Abfragen auf Ihren Daten feingetuned ist.
5. Wenn Sie ein Produkt erstellen, vermeiden Sie die Verwendung von Abstraktionen wie LangChain und LlamaIndex
Sie sollten jeden Aufruf an ein Modell vollständig besitzen, einschließlich dessen, was ein- und ausgeht. Wenn Sie dies an eine Bibliothek von Drittanbietern auslagern, werden Sie es bereuen, wenn es an der Zeit ist, Benutzer aufzunehmen, ein Problem zu beheben, auf mehr Benutzer zu skalieren, zu protokollieren, was der Agent tut, auf eine neue Version aufzurüsten oder zu verstehen, warum der Agent etwas getan hat.
Hinweis: Wenn Sie sich in reiner Prototyp-Phase befinden und nur versuchen, zu validieren, dass es für einen Agenten möglich ist, eine Aufgabe zu erledigen, wählen Sie ruhig Ihre Lieblingsabstraktion und machen Sie es live.
6. Ihr Agent ist nicht Ihr Graben
Die Automatisierung oder Ergänzung von menschlichem Wissen durch KI-Agenten ist eine riesige Chance, aber der Aufbau eines großartigen Agenten ist nicht genug. Die Produktivierung eines Agenten für Benutzer erfordert eine erhebliche Investition in eine Reihe von nicht-KI-Komponenten, die es dem Agenten ermöglichen, tatsächlich zu arbeiten… hier können Sie eine Wettbewerbsdifferenzierung schaffen:
- Sicherheit: KI-Agenten sollten nur mit der Zustimmung und Kontrolle des Benutzers, der sie leitet, ausgeführt werden. In der Praxis bedeutet dies, dass Sie sich durch einen Hüpfspiel von OAuth-Integrationen, Single-Sign-On-Anbietern, zwischengespeicherten Aktualisierungstoken und mehr bewegen müssen. Die gute Durchführung ist absolut ein Merkmal.
- Datenkonnektoren: KI-Agenten benötigen häufig Live-Daten von Quellsystemen, um zu funktionieren. Dies bedeutet die Integration mit APIs und anderen Verbindungsprotokollen, häufig sowohl für interne als auch für Drittanbietersysteme. Diese Integrationen erfordern eine anfängliche Erstellung und Pflege über die Zeit.
- Benutzeroberfläche: Benutzer werden einem KI-Agenten nicht vertrauen, es sei denn, sie können seinem Arbeitsprozess folgen und ihn überprüfen (normalerweise die ersten paar Male, die ein Benutzer mit einem Agenten interagiert, nehmen schnell ab). Es ist am besten, wenn jeder Tool-Anruf, den der Agent tätigt, über eine dedizierte, interaktive Oberfläche verfügt, damit der Benutzer der Arbeit des Agenten folgen und sogar mit ihm interagieren kann, um das Vertrauen in sein Schlussfolgerungsverhalten aufzubauen (z. B. Durchsuchen Sie die Inhalte jedes Elements, das in einem semantischen Suchergebnis zurückgegeben wird).
- Langzeitgedächtnis: KI-Agenten erinnern sich standardmäßig nur an den aktuellen Arbeitsablauf, bis zu einer maximalen Anzahl von Tokens. Das Langzeitgedächtnis über Arbeitsabläufe hinweg (und manchmal sogar über Benutzer hinweg) erfordert das Speichern von Informationen im Gedächtnis und das Abrufen über Tool-Anrufe oder das Injizieren von Erinnerungen in Aufforderungen. Ich habe festgestellt, dass Agenten nicht sehr gut darin sind, zu entscheiden, was gespeichert werden sollte, und sich auf die Bestätigung des Menschen verlassen, dass die Informationen gespeichert werden sollten. Je nach Anwendungsfall können Sie möglicherweise davonkommen, dem Agenten die Entscheidung zu überlassen, wann etwas im Gedächtnis gespeichert werden soll, wie z. B. ChatGPT.
- Evaluierung: Der Aufbau eines Rahmens zur Bewertung Ihres KI-Agenten ist eine frustrierend manuelle Aufgabe, die niemals wirklich abgeschlossen ist. Agenten sind absichtlich nichtdeterministisch, d.h. sie versuchen, basierend auf der angegebenen Richtung die beste Reihenfolge von Tool-Anrufen zu finden, um ihre Aufgabe zu erledigen, und schlussfolgern nach jedem Schritt wie ein Baby, das das Laufen lernt. Die Bewertung dieser Sequenzen erfolgt in zwei Formen: der Gesamterfolg des Arbeitsablaufs des Agenten bei der Erledigung der Aufgabe und die unabhängige Genauigkeit jedes Tool-Anrufs (z. B. Informationsabruf für die Suche; Genauigkeit für die Codeausführung; usw.). Die beste und einzige Möglichkeit, die ich gefunden habe, um die Leistung im Gesamt-Workflow zu quantifizieren, ist die Erstellung eines Satzes von Ziel/Fertigstellung-Paaren, wobei das Ziel die anfängliche Richtung ist, die dem Agenten gegeben wird, und die Fertigstellung der endgültige Tool-Anruf ist, der die Erledigung des Ziels darstellt. Das Erfassen der Zwischen-Tool-Anrufe und Gedanken des Agenten ist hilfreich, um ein Versagen zu verstehen oder nur eine Änderung in der Reihenfolge der Tool-Anrufe.
Hinweis: Betrachten Sie diesen Abschnitt als eine formelle Anfrage für Startups. Produkte rund um jeden dieser Punkte, wenn sie gut gemacht sind, können die Agenten der Zukunft unterstützen.
7. Setzen Sie nicht darauf, dass Modelle weiterhin verbessert werden
Während des Baus Ihres Agenten werden Sie ständig versucht sein, sich zu sehr an das primäre Modell anzupassen, mit dem Sie es aufbauen, und einige der Schlussfolgerungserwartungen, die Sie an Ihren Agenten haben, zu reduzieren. Widerstehen Sie dieser Versuchung! Modelle werden sich weiter verbessern, vielleicht nicht mit dem irren Tempo, mit dem wir uns derzeit bewegen, aber sicherlich mit einer höheren Geschwindigkeit als bei früheren Technologie-Wellen. Kunden werden Agenten wollen, die auf den Modellen ihres bevorzugten KI-Anbieters laufen. Und am wichtigsten ist, dass Benutzer erwarten werden, die neuesten und besten Modelle innerhalb Ihres Agenten nutzen zu können. Wenn gpt-4o veröffentlicht wurde, hatte ich es innerhalb von 15 Minuten nach der Verfügbarkeit in der OpenAI-API in einem Produktionskonto laufen. Die Anpassungsfähigkeit über verschiedene Modellanbieter hinweg ist ein Wettbewerbsvorteil!
8. Bonus-Lektionen
Dieser Artikel konzentrierte sich auf strategischere und produktorientierte Lektionen. Ich plane, in einem zukünftigen Artikel tiefer in einige Code- und Infrastruktur-Lektionen einzutauchen. Hier sind ein paar Vorgeschmacksstücke:
- Benötigen Sie eine Vektor-Ähnlichkeitssuche? Beginnen Sie mit pgvector in Postgres. Wechseln Sie nur zu einer Vektor-Datenbank, wenn Sie es wirklich müssen.
- Open-Source-Modelle schlussfolgern noch nicht gut.
- Die Assistants-API ist seltsam. Sie abstrahiert mehrere Dinge, die sich anfühlen, als ob sie unabhängig bleiben sollten (Flat-File RAG, Gesprächs-Token-Limits, Code-Interpreter, usw.). Bitte, OpenAI, mach den Code-Interpreter einfach zu einem optionalen Tool, das wir einschalten können, wenn wir eine Fertigstellung ausführen.
- Optimieren Sie nicht zu früh für die Kosten.
- Das Streaming von Tokens ist ein großartiger Kompromiss für Benutzer, wenn es darum geht, mit der Latenz der KI umzugehen.
- Agenten sind magisch! Sobald Sie den von VCs gesponserten Sessellift zur Spitze der überhöhten Erwartungen hinauffahren und den Abhang der Ernüchterung hinunterwedeln, werden Sie von der Hochebene der Produktivität begeistert sein.