Software frisst die Welt – und dieses Mal ist es wirklich wahr
Das Divine Translation Bureau ist ein Übersetzungsteam von 36Kr, das sich auf Technologie, Geschäft, Arbeitswelt, Lebensstil und andere Bereiche konzentriert und vor allem auf neue Technologien, neue Ansichten und neue Trends aus dem Ausland eingeht.
Herausgeberhinweis: Hör auf, KI nur als Chat-Tool zu nutzen. Agenten übernehmen reales Arbeitsvolumen, indem sie wild Tokens verbrauchen, und eine Billionen-Dollar-„Inferenz-Welle“ hat sich stumm entfacht. Dieser Artikel ist eine Übersetzung.
Im Jahr 2011 hat Software die Welt verschlungen. Zumindest hat uns Marc Andreessen das so erzählt. Aber wenn das stimmt, warum existiert die San Francisco Bay Area immer noch? Wenn Software wirklich alles verschlungen hätte, sollten wir uns jetzt doch alle nach New York oder Miami umziehen, oder?
Tatsächlich mal sehen, was Software denn nun verschlungen hat: Banken haben Apps, der Einzelhandel hat Websites, Krankenhäuser haben elektronische Gesundheitsakten (EHR) eingeführt, und Taxen können mit wenigen Klicks auf dem Bildschirm bestellt werden, anstatt dass man um zwei Uhr morgens, wenn man sich selbst nicht einmal mehr sicher ist, wo man sich befindet, telefonieren muss.
Software hat die Benutzeroberflächen verschlungen, aber was ist mit der eigentlichen Arbeit? Der Großteil wird immer noch von Menschen erledigt.
Wenn ein Kunde wegen einer Rechnungsstreitigkeit anruft, übernimmt die Software die Telefonumleitung, bringt das Kontofenster auf den Bildschirm und protokolliert das Ergebnis nach der Bearbeitung. Aber im gesamten Prozess ist es immer noch der Mensch, der zuhört, entscheidet, ob eine Rückerstattungspolitik anwendbar ist, beschließt, wie gehandhabt werden soll und tatsächlich mit dem Kunden kommuniziert. Wenn ein Kreditbeamter einen Kreditantrag prüft, zeigt die Software die Kreditbewertung an und ruft die Dokumente auf dem Bildschirm auf, aber es ist der Kreditbeamter selbst, der diese Dokumente liest und die endgültige Entscheidung trifft. In den letzten 15 Jahren war Software sehr gut darin, die Rolle eines „Rohrs“ zu spielen, während die eigentliche Kernarbeit immer noch von Menschen übernommen wurde.
Jetzt kann KI tatsächlich diese Arbeiten erledigen! Ein Kundenservice-Anruf wird zu einer Agentenschleife: Das System verarbeitet die Spracherkennung, fragt über eine API das Konto ab, ruft die relevanten Richtlinien ab, schließt aus, ob der Kunde in Anspruch kommt, löst eine Rückerstattung aus und gibt die Antwort mithilfe von Text-zu-Sprache (TTS) aus. Ein Versicherungsfall wird zu einer Dokumenteneingabe, gefolgt von einer Deckungsprüfung, einer Betrugsmarkierung, einer Rückstellungskalkulation und einem Abrechnungsprozess, allesamt automatisch als Code ausgeführt. Eine Programmieraufgabe kann 30 Runden von Dateilesen, Codeänderungen, Testläufen und Optimierungen umfassen, ohne dass dabei menschliche Intervention erforderlich ist.
Jede dieser Arbeitsabläufe ist im Wesentlichen ein Stück Software, das in einer Schleife Werkzeugaufrufe (tool calls) ausführt. Wenn Sie ein Inferenzdienstleister sind, der Logs analysiert, werden Sie feststellen, dass der Kundenservice-Agent für die Bearbeitung von Rechnungsstreitigkeiten und der Programmieragent für die Behebung von Bugs nicht viel voneinander unterscheiden. Sie sind beide Code.
Also beginnt Software erneut, die Welt zu verschlingen, und diesmal verschlingt Inferenz tatsächlich die Arbeit. Die verschlungenen Arbeitslasten sind im Wesentlichen nur „Zustandsübergänge“ und „Ausnahmebehandlungen“ in menschlicher Hülle: Kundenservice-Anrufe, Versicherungsfälle, Kreditprüfungen, medizinische Verwaltung, juristische Analysen. Jede Aufgabe verbraucht in ihren Dutzenden von Schritten Tausende von Tokens, und oft laufen mehrere Modelle gleichzeitig. Der gesamte Inferenzmarkt verarbeitet bereits täglich Billionen von Tokens, und die Zahl wächst exponentiell: Es gibt immer mehr Benutzer, mehr Arbeitsabläufe werden in Code umgewandelt, und mit der Verbesserung der Modellfähigkeiten steigt auch der Tokenverbrauch pro Aufgabe sprunghaft an.
Welche Arbeitslasten werden verschlungen?
Wenn eine Arbeit im Wesentlichen nur aus Zustandsübergängen und Ausnahmebehandlungen besteht, wird sie vom Code absorbiert. Die Personen, die diese Arbeit ausführen, tragen möglicherweise die Titel „Schadensregler“, „Kreditprüfer“ oder „Einnahmenzyklus-Experte“, aber wenn man sich ansieht, was sie den ganzen Tag tun, geht es im Grunde um Folgendes: Eingaben prüfen, anhand einer Regelmenge vergleichen, entscheiden, in welche Kategorie sie fällt, Aktionen ausführen, seltsame Sonderfälle behandeln und dann zum nächsten Schritt gehen. Wenn die Eingaben als Text, Sprache oder Dokumente erfasst werden können, die Zwischenzustände in einer Datenbank gespeichert werden und die Ausgabe etwas wie „Diesen Datensatz aktualisieren“, „Diese Nachricht senden“ oder „Diesen API-Aufruf auslösen“ ist, dann kann und wird der gesamte Prozess ganz bestimmt als Agentenschleife laufen.
Ein weiterer Schlüsselbestimmungsfaktor für die Tiefe dieser Schleife ist die Verifikation. Bei der Programmierung kann ein Agent 30 oder mehr Schritte autonom in einer Schleife ausführen, weil die Verifikation sofort und kostenlos ist. Ein Test schlägt entweder fehl oder nicht.
Aber in Bereichen wie der Neuentwicklung von Arzneimitteln erfordert die echte Verifikation Wochen oder Monate in einem Wet-Labor; oder im Bereich der Robotik ist die Lücke zwischen Simulation und Realität immer noch ein Engpass, und die Agentenschleife stößt auf Probleme. Im Laufe der Zeit werden diese Bereiche mehr Inferenzleistung verbrauchen, aber es gibt eine Obergrenze für die Dauer der Schleife, weil sie auf die physische Welt warten muss.
Wenn ein Kundenservice-Agent ein Ticket löst, lautet das Verifikationskriterium: „War der API-Aufruf erfolgreich? Wurde der Datensatz aktualisiert?“ Oder sogar: „Ist der Benutzer mit der Antwort zufrieden?“ Wenn ein Kreditprüfungs-Agent einen Antrag bearbeitet, lautet das Verifikationskriterium: „Erfüllt dieses Dokument die Anforderungen? Ist die Compliance-Prüfung bestanden?“
Ich denke, die meisten Menschen unterschätzen stark, wie viel Inferenzleistung diese transformierten Arbeitsabläufe tatsächlich verbrauchen, weil sie sich vorstellen, dass es immer noch ein Modell, ein Aufruf und eine Antwort ist, möglicherweise begleitet von einigen Halluzinationen. Aber die Realität sieht ganz anders aus.
Nehmen wir als Beispiel einen Sprach-Kundenservice-Agenten, der eine scheinbar einfache, aber reale Geschäftsanfrage bearbeitet, wie etwa die Neuerstellung eines Arzttermines. Für den Kunden fühlt sich das wie ein normaler Gesprächseinsatz an. Aber auf der unteren Ebene ist es ein kleines autonomes System, das ständig läuft. Wenn der Anrufer spricht, transkribiert das Spracherkennungsmodell das Audio in Echtzeit. Dann führt ein Orchestrierungsmodell eine Inferenz auf der transkribierten Ausgabe durch, ruft das Patientenprofil ab, prüft die Zeitbeschränkungen, fragt die Verfügbarkeit des Arztes ab, entscheidet, was als nächstes gefragt werden soll, und ruft die relevanten Werkzeuge auf. Sobald genug Informationen vorliegen, werden die Ergebnisse in die Antwort integriert, und das Text-zu-Sprache-Modell wandelt sie in natürliche Sprache um. Gleichzeitig können andere Modelle möglicherweise die Stimmung überwachen, Compliance-Prüfungen durchführen oder entscheiden, ob der Anruf an einen menschlichen Kundenservice weitergeleitet werden muss.
Das System übernimmt alle Aufgaben selbst: Hören, Suchen, Entscheiden, Werkzeuge aufrufen, Verifizieren und in der Schleife reagieren. Ein 8-minütiger Anruf kann nur etwa 3.000 Tokens an ursprünglicher transkribierter Text enthalten, aber wenn man die wiederholten Inferenzen auf der sich ständig verlängernden Gesprächsausgabe, den gesuchten Kontext und die Werkzeugausgaben hinzunimmt, sowie die kontinuierliche ASR (Spracherkennung) und TTS (Text-zu-Sprache)-Inferenz während des gesamten Anrufs miteinbezieht, kann die Orchestrierungsebene leicht etwa 40.000 Tokens verbrauchen. Ein „KI-Telefonanruf“ ist tatsächlich ein ständig laufender Mehr-Modell-Inferenzstapel.
Welche Bereiche sind auf dem Vormarsch?
Die oben genannten Kategorien haben bereits produktionsreife Umsetzungen und praktische Anwendungen, und die Arbeitsabläufe sind bereits deutlich vom Code ersetzt worden. Aber es gibt auch einen zweiten Marktgradienten, in dem die gleichen Dynamiken beginnen zu erscheinen, nur befinden sie sich auf der Entwicklungskurve noch in einem früheren Stadium.
Der juristische Bereich ist ein gutes Beispiel. Die erste Welle der juristischen KI beschränkte sich hauptsächlich auf die Suchschicht: das Finden relevanter Fälle, das Identifizieren von Risikoklauseln, das Zusammenfassen von Verträgen. Dies ist sehr nützlich, aber aus Inferenzsicht relativ oberflächlich. Die jetzt aufkommenden Agentenarbeiten sind jedoch viel aufwändiger. Stellen Sie sich einen Due-Diligence-Agenten für Unternehmenszusammenschlüsse (M&A) vor, der alle Dokumente eines gesamten Datenraums lesen kann, Kaufverträge mit Offenlegungsschemas und Due-Diligence-Materialien vergleichen kann, Unstimmigkeiten finden kann, Risikomemoranden mit Quellenangaben verfassen kann und Änderungsvorschläge machen kann. Dieser neue juristische Agent ist ein langfristiger Arbeitsablauf, der auf einem riesigen Korpus von Texten läuft, und er liefert ein echtes Arbeitsergebnis, das ein junger Anwalt sonst Tage brauchen würde, um es zusammenzustellen. Diese Veränderung geht von „Hilfe beim Finden von Informationen für Menschen“ zu „Eigenständige Analyse“ über, wodurch die Aufgabe von einigen leichten Suchaufrufen zu einer tiefen, mehrstufigen Schleife wird.
Finanzwesen, Rechnungswesen, Lieferkette, Regierungsgeschäfte und Beschaffung haben ähnliche Merkmale: eine große Anzahl von Dokumenten, eine große Anzahl von Ausnahmebehandlungen, eine große Anzahl von Zwischenentscheidungen und eine komplexere Verifikation, als man sich vorstellen kann. Dies sind die Kategorien, die in den nächsten Jahren am engsten beobachtet werden sollten, weil sie sich an der Schwelle der Modellfähigkeiten befinden. Mit der zunehmenden Länge der Aufgabenhorizonte wird dieser Mittelbereich immer mehr vom Code verschlungen werden.
Die Token-Leiter
Öffnen Sie Claude Code in einer echten Quellcodebasis und lassen Sie es einen Bug beheben, etwa: „Es gibt eine Race Condition im Authentifizierungsprozess, die nur unter hoher Last auftritt.“ Bevor der Agent etwas wirklich Nützliches tun kann, muss er lesen: die relevanten Quellcode-Dateien, Testfälle, Konfiguration und möglicherweise einige Logs. Dies kann leicht zu einem Kontext von etwa 60.000 Tokens am Anfang führen.
Dann geht er in die Schleife. Er liest die fehlgeschlagenen Tests, prüft das Authentifizierungsmodul, stellt Hypothesen auf, ändert die Sperrlogik, führt die Tests mit dem neuen Code aus, bekommt einen neuen Fehler (das ist Fortschritt!), korrigiert die Hypothese und wiederholt es. Manchmal kann diese Reparatur sogar etwas im Oberbereich zerstören, und der Agent muss eine Abhängigkeit, die er zuvor berührt hat, erneut lesen. Er wiederholt diesen Vorgang immer wieder: Lesen, Ändern, Ausführen, Prüfen, Korrigieren. Nach 30 Iterationen schlägt der Test endlich fehl, die Code-Differenzen werden bereinigt, und der gesamte Testsuite wird noch einmal ausgeführt.
Dies hat 3 Minuten in Anspruch genommen, und Sie haben möglicherweise etwa 900.000 Tokens verbraucht.
Erstaunlicherweise ist die sichtbare Ausgabe minimal. Es sind möglicherweise nur etwa 500 Tokens an eigentlichem Code und eine Erklärung. Die restlichen etwa 899.500 Tokens sind alle Verbrauch der Schleifenmechanik: das Wiedergabe des akkumulierten Kontexts, die Aufnahme der neuesten Werkzeugausgabe, die Inferenz darüber, was als nächstes versucht werden soll, und die Übertragung aller erforderlichen historischen Aufzeichnungen, um die Kohärenz aufrechtzuerhalten. Die Antwort ist kompakt, die Arbeit ist teuer.
Vergleichen Sie dies mit der Situation vor der Agenten-Ära, als dasselbe Modell eine direkte Frage beantwortete, etwa: „Was ist der Unterschied zwischen Optimistic Locking und Pessimistic Locking?“ Dies würde insgesamt nur etwa 900 Tokens erfordern.
Die Agentenschleife kann den Inferenzbedarf um etwa drei Größenordnungen erhöhen. Ich sehe es als eine „Token-Leiter“ an, und jede Aufgabe in der Wirtschaft befindet sich an einem bestimmten Punkt auf dieser Leiter.
Unten ist der normale Dialog: eine Frage, eine Antwort, ohne Werkzeuge, etwa 900 Tokens.
Eine Stufe höher ist die Suche: Das Modell durchsucht einige Dokumente, liest sie und schreibt eine zusammenfassende Übersicht. Jetzt verbraucht es fast 7.500 Tokens. Der Großteil der Kosten liegt nicht in der Antwort selbst, sondern in der Lektüre und Wiedergabe des gesuchten Kontexts durch das Modell.
Noch höher ist der Kundenservice. Ein einfacher FAQ-Roboter kann relativ leichtgewichtig bleiben. Ein agentenbasierter Kundenservice-System hinter den Kulissen, das Ihr Konto prüfen, die relevanten Richtlinien abrufen, die Zulässigkeit ableiten und tatsächlich Aktionen ausführen kann, ist viel aufwändiger. Die Oberfläche der Interaktion sieht gleich aus, aber das Inferenzprofil ist völlig anders.
Dann kommt die Programmierung, die sich nahe der Spitze der Leiter befindet. Ein begrenzter Bugfix kann auf Hunderttausende von Tokens steigen. Eine echte Debugging- oder Funktionsentwicklungssitzung kann fast eine Million Tokens verbrauchen. Die Claude Code-Dokumentation von Anthropic besagt, dass ein aktiver Entwickler täglich etwa 13 Dollar an Inferenzleistung verbrauchen kann, was je nach Modellkombination und Caching etwa 1,5 bis 3 Millionen Tokens pro Tag entspricht. Einige komplexe Programmieraufgaben können mehr Inferenzleistung verbrauchen als tausend Dialoge.
Das zugrunde liegende Muster ist einfach: Anzahl der Tokens pro Aufgabe = Anfangskontext + (Anzahl der Schritte × Anzahl der Tokens pro Schritt)
Am untersten Ende der Leiter gibt es nur einen Schritt, fast keinen Kontext und keine Werkzeuge. An der Spitze gibt es dagegen Dutzende von Schritten. Jeder Schritt wiederholt den sich ständig vergrößernden historischen Kontext, führt die neuesten Werkzeugausgaben ein und führt eine Inferenz darauf aus, um schließlich nur eine winzige Menge an sichtbarem Arbeitsergebnis auszugeben. Deshalb ist der Abstand zwischen den Stufen so groß.
