Streaming von KI-Antworten: Fortschritt anzeigen, ohne Daten oder Aktionen vor einer gültigen Ausgabe auszuführen

Ein sichtbares Fragment ist nicht gleichbedeutend mit einer nutzbaren Ausgabe

Eine Oberfläche kann Text anzeigen, während er von einem Modell eintrifft, und dennoch eine strikte Grenze zwischen diesem Text und dem Systemzustand aufrechterhalten. Diese Grenze ist wichtig, weil ein Streaming-Delta lediglich mitteilt, dass ein Teil einer Generierung eingegangen ist. Es beweist weder, dass die Nachricht abgeschlossen ist, noch, dass sich ihre Bedeutung nicht mehr ändern wird, dass ein strukturiertes Objekt vollständig ist oder dass ein Tool-Aufruf gültige Argumente enthält.

Wahrgenommene Latenz und Gültigkeit sind unterschiedliche Eigenschaften. Streaming kann die Zeit bis zum ersten Fragment verkürzen und der Person nützliche Aktivitätssignale geben. Das Ergebnis, das einen Vorgang auslöst, muss jedoch weitere Anforderungen erfüllen: den Empfang eines eindeutigen Abschlusses, eine vollständige Zusammensetzung, syntaktische und semantische Validierung, die Zuordnung zu einer konkreten Generierung und – wenn das Risiko dies verlangt – eine menschliche Bestätigung. Eine Anwendung, die diese Ebenen verwechselt, kann unvollständige Datensätze erzeugen, zurückgenommene Behauptungen indexieren oder eine Aktion nach einer Unterbrechung zweimal ausführen.

Es ist sinnvoll, das während der Übertragung gerenderte Material als vorläufige Projektion zu behandeln. Es kann zum Lesen, Prüfen und Abbrechen nützlich sein, muss aber als Entwurf gekennzeichnet sein. Der Geschäftszustand hingegen sollte aus einer endgültigen Repräsentation hervorgehen, die vom Server oder einer vertrauenswürdigen Komponente kontrolliert wird. Diese Regel gilt sowohl für Konversationsassistenten als auch für Dokumentextraktion, Codegenerierung, administrative Automatisierung und Agenten mit Tools.

Nicht alle Anbieter-APIs verwenden dieselben Ereignisnamen oder geben exakt dieselben Garantien. Manche dokumentieren inkrementelle Ereignisse, Antwortkennungen und ein Abschlussereignis; andere beschreiben Ausführungszustände oder ein Ergebnissignal. Die Integration muss sich auf den konkreten Vertrag der ausgewählten API stützen und darf Vollständigkeit nicht daraus ableiten, dass einige Sekunden lang kein Datenverkehr mehr eintrifft.

Eine explizite Zustandsmaschine entwerfen

Der klarste Weg, um zu verhindern, dass die Oberfläche zu einem Ausführungspfad wird, besteht darin, den Lebenszyklus jeder Generierung zu modellieren. Die interne Kennung der Generierung sollte vor dem Öffnen der Verbindung erzeugt und, sofern vorhanden, mit der vom Anbieter zurückgegebenen Kennung verknüpft werden. Sie sollte außerdem mit der Sitzung, dem autorisierten Nutzer oder Principal, der verwendeten Prompt- oder Konfigurationsversion und dem angeforderten Geschäftsvorgang verbunden sein.

Der erste Zustand lautet empfangen: Ein Ereignis mit Transportmetadaten ist eingetroffen, sein Inhalt wurde jedoch noch nicht akzeptiert. Anschließend gelangt das Ereignis in einen vorläufigen Puffer, in dem es nach Sequenzreihenfolge oder nach der vom Protokoll festgelegten Position abgelegt wird. Der Client kann diesen Puffer lesen, um einen Entwurf zu rendern. Liefert der Ablauf Teile mehrerer Elemente – etwa Text, nicht angezeigtes Reasoning und Tool-Argumente –, müssen getrennte Puffer pro Element und Typ geführt werden.

Im Zustand Zusammensetzung wandelt der Consumer die Fragmente in eine vollständige Kandidatenrepräsentation um: finalen Text, ein strukturiertes Objekt oder eine Tool-Anfrage. Dieser Schritt ist keine Validierung. Dass sich eine Verkettung beispielsweise als JSON interpretieren lässt, beweist weder, dass sie nur erlaubte Felder enthält, noch, dass Werte in akzeptierten Bereichen liegen oder dass der Nutzer die daraus folgende Aktion autorisiert hat.

Eine Ausgabe wird erst dann validiert, wenn das dokumentierte Terminalereignis oder der finale Status, Reihenfolge und Integrität aller benötigten Ereignisse, das erwartete Schema und die Geschäftsregeln geprüft wurden. Bestätigtes Ergebnis bedeutet zusätzlich, dass das System die validierte Version unter einem stabilen Schlüssel persistiert und die Entscheidung aufgezeichnet hat. Aktion ausgeführt ist ein nachgelagerter Zustand und kein Synonym für validiert: Er verlangt eine Autorisierungsrichtlinie, einen Idempotenzschlüssel und einen Nachweis ihres Ergebnisses.

Auch alternative Endzustände verdienen eine eigene Behandlung. Abgebrochen bedeutet, dass der Nutzer oder das System die Erfahrung stoppen wollte; unvollständig bedeutet, dass ein notwendiger Teil fehlt oder der Anbieter einen nicht erfolgreichen Abschluss gemeldet hat; fehlgeschlagen steht für einen verarbeitbaren Fehler; abgelaufen bedeutet, dass eine Wiederaufnahme nicht mehr sicher ist. Keiner dieser Zustände darf den vorläufigen Puffer zum endgültigen Ergebnis befördern.

Entscheiden, was angezeigt, gespeichert, indexiert oder ausgeführt werden darf

Die Richtlinie sollte nicht nur davon abhängen, ob ein Inhalt plausibel wirkt. Sie muss von seinem Zustand und von der Klasse des Ablaufs abhängen. Ein informativer Chat verträgt, dass die Person einen als solchen markierten Entwurf sieht. Eine Extraktion, die eine Wissensdatenbank speist, verlangt vor der Indexierung eine endgültige Version. Ein Tool, das eine Reservierung erstellt, eine Nachricht versendet oder Berechtigungen ändert, benötigt zusätzliche Kontrollen, selbst wenn seine Argumente bereits ein Schema bestanden haben.

Das Speichern von Transporttelemetrie ist nicht dasselbe wie das Persistieren einer Ausgabe als Geschäftsinhalts. Es kann legitim sein, einen minimalen Datensatz eines empfangenen Ereignisses zur Fehlersuche bei Unterbrechungen und zur Sitzungsabstimmung aufzubewahren, sofern die geltenden Datenschutz- und Aufbewahrungsrichtlinien eingehalten werden. Dies muss klar vom Speichern eines Teiltexts als freigegebene Antwort unterschieden werden. Ebenso darf ein Log keine unkontrollierte Kopie von Geheimnissen, personenbezogenen Daten oder potenziell sensiblen Anweisungen erzeugen.

Die Indexierung verlangt eine besonders zurückhaltende Entscheidung. Teilfragmente können eine Zwischenfolgerung enthalten, die am Ende der Antwort verschwindet. Ihre Indexierung schafft künftige Retrieval-Treffer für unbestätigtes Material und erschwert die Erklärung, was eine Person gesehen hat und welche Version das System übernommen hat. Indexieren Sie die validierte Version mit ihrer Generierungs- und Versionskennung und ermöglichen Sie, diese Version nachvollziehbar zurückzuziehen oder zu ersetzen.

Den Transport konsumieren, ohne Pakete für Nachrichten zu halten

In einem Ablauf auf Basis servergesendeter Ereignisse definiert das Protokoll, wie Ereignisse gebildet werden, und berücksichtigt Wiederverbindungen. Der Transport verwendet UTF-8-kodierten Text, und die Grenze eines Netzwerkpakets ist nicht die Grenze eines Zeichens, einer Ereigniszeile oder eines JSON-Objekts. Daher muss der Consumer einen inkrementellen Decoder und einen Ereignisparser verwenden; er darf nicht jeden gelesenen Byte-Abschnitt unabhängig in einen String umwandeln und annehmen, dieser enthalte ein vollständiges Ereignis.

Nachdem ein Protokollereignis rekonstruiert wurde, muss der Vertrag der API weiterhin interpretiert werden. Text kann als Deltas eintreffen; Argumente eines Funktionsaufrufs können aufgeteilt sein; Ausgabeelemente können ineinander verschachtelt oder abwechselnd eintreffen. Der Consumer muss nach den dokumentierten Kennungen gruppieren, etwa Generierung, Element oder Ausgabeindex, und Sequenznummern verwenden, wenn sie verfügbar sind. Ein erneut eingetroffenes Ereignis darf weder Zeichen duplizieren noch zwei Objekte erzeugen oder eine zweite Ausführung verursachen.

Auch das Ende der Verbindung ist kein ausreichender Erfolgsnachweis. Die Verbindung kann wegen eines Abbruchs, eines Proxys, eines Timeouts oder eines Fehlers geschlossen werden. Nur das Signal und der Status, die der Anbieter dokumentiert, erlauben die Klassifikation einer Generierung als abgeschlossen, unvollständig oder fehlgeschlagen. Fehlt dieser Nachweis, ist der korrekte Zustand unsicher oder unvollständig; Beförderung und Ausführung bleiben gesperrt.

Nicht alle APIs stellen eine Prüfsumme, eine finale Version oder einen Mechanismus zur Wiederaufnahme bereit. Wenn eine Antwortkennung und ein Sequenzcursor vorhanden sind, bewahren Sie diese zusammen mit dem zuletzt akzeptierten Ereignis auf. Wenn dies nicht vorhanden ist, kann eine Wiederverbindung aus geschäftlicher Sicht die Anlage einer neuen Generierung erfordern. Es ist nicht sicher, zwei ähnliche Sequenzen allein aufgrund ihres Inhalts als dieselbe Antwort zu betrachten.

Tool Calling: Vollständig bedeutet nicht autorisiert

Tool-Aufrufe verdienen eine eigenständige Schranke, weil sie generierten Text in Auswirkungen außerhalb des Modells umwandeln. Dass ein Funktionsname oder ein Teil seiner Argumente erscheint, stellt noch keine ausführbare Anfrage dar. Die Argumente müssen bis zum zugehörigen Abschlusssignal gesammelt, in eine strukturierte Repräsentation überführt und gegen ein striktes Schema validiert werden. Unbekannte Felder, implizite Konvertierungen und Werte außerhalb der Richtlinie müssen abgelehnt werden oder eine erneute Interaktion erfordern.

Die Schemavalidierung ist notwendig, aber nicht ausreichend. Ein Überweisungstool kann einen korrekt formatierten Betrag erhalten, der dennoch ein Limit überschreitet, keine Autorisierung besitzt oder an einen nicht zulässigen Empfänger gerichtet ist. Geschäftsregeln müssen in dem Dienst ausgeführt werden, der die Aktion kontrolliert, nicht nur im Client, der die Unterhaltung rendert. Bei bedeutsamen Vorgängen sollte eine Nutzerbestätigung eine stabile Beschreibung der Aktion anzeigen, die aus bereits validierten Argumenten abgeleitet wurde.

Die Ausführung muss einen vom Server berechneten oder zugewiesenen Idempotenzschlüssel tragen. Dieser Schlüssel muss an die bestätigte Absicht gebunden sein, nicht an jeden Netzwerkwiederholungsversuch. Vor einem erneuten Versuch fragt der Executor das Operationsregister ab, um festzustellen, ob für diesen Schlüssel bereits ein Ergebnis vorliegt. Das ist relevant, weil HTTP davor warnt, einen nicht idempotenten Vorgang automatisch zu wiederholen, wenn nicht feststellbar ist, ob die ursprüngliche Anfrage bereits angewendet wurde.

Auch das Ergebnis des Tools benötigt Abstimmung. Akzeptiert der externe Anbieter den Vorgang, geht die Antwort aber verloren, ist der Status nicht „nicht ausgeführt“: Er ist unbekannt, bis eine Operationskennung abgefragt oder ein Kompensationsverfahren angewendet wird. Wer diesen Fall von Beginn an entwirft, verhindert, dass eine Wiederholungsschaltfläche zu einer doppelten Anweisung wird.

Unterbrechungen, Abbrüche, Wiederaufnahme und Produkterlebnis

Bei einer Unterbrechung muss die Anwendung die Unterscheidung zwischen Gesehenem und Bestätigtem bewahren. Sie kann den Entwurf mit einem Hinweis auf die Unterbrechung sichtbar lassen, einen Wiederholungsversuch anbieten oder eine Wiederaufnahme versuchen, wenn Protokoll und Anbieter dies unterstützen. Bei einer Wiederaufnahme darf sie nur Ereignisse nach dem zuletzt bestätigten Cursor anfordern oder verarbeiten und jede Wiederholung deduplizieren. Kann Kontinuität nicht nachgewiesen werden, ist es besser, eine neue Generierung zu starten und sie auch als solche zu kennzeichnen.

Der Abbruch durch den Nutzer erfordert zwei unterschiedliche Vorgänge: keine weiteren Inhalte mehr anzuzeigen oder anzufordern und zu entscheiden, was mit bereits begonnener Arbeit geschieht. Das Kündigen eines Abonnements bedeutet nicht zwingend, dass der Anbieter die Berechnung gestoppt hat. Das System muss die Abbruchanforderung erfassen, unerwünschte spätere Beförderungen verhindern und jedes danach eintreffende Ereignis nach einer festgelegten Richtlinie behandeln. Eine bereits versendete externe Aktion verlangt Abfrage oder Kompensation, nicht die Annahme, sie sei gestoppt worden, weil die Oberfläche geschlossen wurde.

Im Produkt sollten Indikatoren Aktivität vermitteln, ohne einen Abschluss zu versprechen. Ein Schreibcursor, ein Status wie „wird generiert“ und eine Stoppoption eignen sich für den Entwurf. Die Kennzeichnung „Ergebnis bereit“ sollte der validierten Ausgabe vorbehalten bleiben. Wenn sich der Entwurf bearbeiten lässt, muss die menschliche Bearbeitung einen eigenen Zweig oder eine eigene Version erzeugen: Sie darf nicht mit der vom System bestätigten Antwort verwechselt werden.

Die Wiederherstellung einer Sitzung muss erklären können, was geschehen ist. Bewahren Sie die Beziehung zwischen Generierung, akzeptierten Ereignissen, letztem Cursor, validierter Version und – falls vorhanden – externer Operation auf. Diese Nachvollziehbarkeit verlangt nicht, den gesamten Text unbegrenzt zu speichern; der Detaillierungsgrad sollte sich nach der Sensibilität der Daten und den Aufbewahrungspflichten richten.

Telemetrie und Tests vor dem Deployment

Metriken müssen wahrgenommene Geschwindigkeit und Korrektheit voneinander trennen. Erfassen Sie die Zeit bis zum ersten Fragment, die Zeit bis zum Abschluss, die Zeit bis zur Validierung und in Abläufen mit Tools die Zeit bis zur Bestätigung und Ausführung. Erfassen Sie außerdem Abbrüche, Stornierungen, Wiederverbindungen, wegen Duplikaten verworfene Ereignisse, unvollständige Generierungen und Abweichungen zwischen vorläufigem Inhalt und bestätigter Version. Diese Signale helfen zu erkennen, ob eine visuelle Verbesserung eine Verschlechterung der Vollständigkeit verdeckt.

Verwenden Sie nicht den vollständigen Text als einzige Grundlage der Beobachtbarkeit. Eine Generierungskennung, die Anbieterkennung – sofern vorhanden –, die Sequenz, der Ereignistyp, Zustandsübergänge und Ablehnungsgründe reichen häufig aus, um viele Vorfälle zu untersuchen. Wenn Inhalte für eine Prüfung aufbewahrt werden müssen, wenden Sie Zugriffskontrollen, Datenminimierung und eine explizite Aufbewahrungsrichtlinie an.

Chaos-Tests müssen an jeder Grenze eingreifen, nicht nur vor dem ersten Token eine Verbindung trennen. Simulieren Sie Unterbrechungen innerhalb eines Mehrbytezeichens, zwischen Ereigniszeilen, innerhalb von JSON, nach scheinbar vollständigen Tool-Argumenten und unmittelbar vor dem Terminalsignal. Simulieren Sie erneut gesendete Ereignisse, Reihenfolgeänderungen, wenn der Vertrag sie nicht ausschließt, Terminalantworten mit Fehlern, verspätete Abbrüche und den Verlust der Antwort eines externen Systems. Das wichtigste Kriterium lautet, dass kein Fall unvollständigen Inhalt in ein bestätigtes Ergebnis verwandelt und keine zweite Aktion für denselben Zweck verursacht.

Prüfen Sie vor dem Deployment, dass der Client keine Zugangsdaten besitzt, mit denen sensible Aktionen direkt ausgeführt werden können; dass die Validierung zentralisiert ist; dass der Idempotenzspeicher angemessene Neustarts übersteht; und dass Dashboards eine abgebrochene Generierung von einer bestätigten Aktion unterscheiden. Ziehen Sie außerdem die internen Bereiche Lernen, Vergleichen und Entdecken heran, um diese Integrationsentscheidung mit den Produktmustern und Fähigkeiten abzustimmen.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.