Der Betrieb eines Systems, das auf einem großen Sprachmodell basiert, endet nicht damit, es verfügbar zu machen oder seine anfängliche Genauigkeit zu verbessern. Das System kann vollständig verfügbar bleiben und dennoch stillschweigend falsche Entscheidungen akzeptieren, das Budget schnell aufbrauchen oder bei Ausfällen auf ein Modell wechseln, dessen Qualität nicht getestet wurde. Daher konzentriert sich der fünfte Teil der Serie Running LLM systems in production auf die tägliche Betriebsfähigkeit als Schicht, die das System beobachtbar, steuerbar, abschaltbar und wiederherstellbar macht.
Überwache die Entscheidung, nicht nur den Dienst
Herkömmliche Dienstmetriken wie Anfrage- und Fehlerrate, Antwortzeit und CPU-Auslastung zeigen nicht, ob der Agent gute Entscheidungen trifft. Die Quelle schlägt vor, eine entscheidungsspezifische Überwachungsschicht hinzuzufügen, die die Anzahl der Entscheidungen, den Anteil automatisierter Ausführungen, die Verteilung der kombinierten Konfidenz, die Dauer jedes Knotens, Fälle der Blockierung durch Sicherheitskontrollen, den Tokenverbrauch und die Kosten, die Häufigkeit menschlicher Eingriffe sowie die Ergebnisse verdeckter Bewertungen von Stichproben aus dem Produktionsverkehr umfasst.
Die Quelle definiert vier Signalgruppen: Entscheidung, Sicherheit, Kosten und Leistung sowie Qualität. Wenn nicht alles gemessen werden kann, haben der Anteil automatisierter Ausführungen, Blockierungen durch Sicherheitskontrollen, die Gesamtkosten der Modelle und die Rate, mit der Menschen Systementscheidungen überstimmen, Vorrang.
Außerdem empfiehlt sie, die Protokolle in drei Schichten aufzuteilen: hochvolumige Betriebsdaten, Entscheidungsmetadaten innerhalb der Vertrauensgrenzen sowie Roh- oder strukturierte Daten, die einer Verschlüsselung und strengen Zugriffskontrolle unterliegen. Jede Entscheidung sollte eine stabile Kennung namens decision_id tragen, die Metriken, Protokolle, Traces und das Auditprotokoll miteinander verknüpft, sodass eine einzelne Entscheidung von Anfang bis Ende untersucht werden kann.
Mach Kosten messbar und begrenzbar
Modellaufrufe sollten nicht über verschiedene Teile der Codebasis verteilt werden, da sich die Kosten dadurch nur schwer zuordnen und kontrollieren lassen. Stattdessen schlägt die Quelle ein einziges Gateway vor, über das alle Aufrufe laufen. Es berechnet Tokens und Kosten nach Mandant, Fähigkeit und Modell und setzt zugleich Raten- und Budgetgrenzen durch.
Die Maßnahmen zur Kostensenkung kommen in folgender Reihenfolge: Das Modell nicht aufrufen, wenn eine deterministische Regel ausreicht; Elemente in einem einzigen Aufruf bündeln; deterministische Ergebnisse zwischenspeichern; für einfache Aufgaben ein kleineres Modell wählen; anschließend den Kontext und unnötige Anweisungen verkürzen. Außerdem sollten die voraussichtlichen Tokens vor dem Aufruf berechnet werden, anstatt jede Anfrage als eine Einheit zu zählen. Für die Plattform insgesamt sollten eine Obergrenze sowie Grenzen für Wiederholungsversuche und unbegrenzte Werkzeugschleifen festgelegt werden.
Weiterleitung, Fallback und Abschaltschalter
In der Praxis gibt es nicht ein einziges Modell für alle Aufgaben. Aufgaben mit geringem Risiko und hohem Volumen können an ein kleineres Modell weitergeleitet werden, während mehrdeutige oder sensible Fälle einem leistungsfähigeren Modell zugewiesen werden. Für das Bewertungsmodell kann eine andere Modellfamilie verwendet werden, damit die Modelle nicht dieselben Schwachstellen teilen. Jedes Modell, das in der Weiterleitungs- oder Fallback-Pipeline vorhanden ist, muss bewertet werden, da der Wechsel zu einem alternativen Modell die Qualität verändern kann.
Während eines Ausfalls eines Anbieters sollte eine festgelegte Fallback-Kette mit einem einzigen Gesamttimeout und einem Schutzintervall verwendet werden, das Aufrufe an einen bekanntermaßen ausgefallenen Anbieter verhindert. Idempotency-Schlüssel verhindern, dass eine Entscheidung zweimal verarbeitet wird, wenn der Aufruf nach seinem tatsächlichen Erfolg mit einem Timeout endet. Wenn die Alternative nicht akzeptabel ist, sollte die Entscheidung an einen Menschen weitergeleitet werden, statt die Verschlechterung zu verbergen.
Für den Abschaltschalter schlägt die Quelle vor, ihn als gemeinsamen Betriebszustand zu implementieren, der global oder für einen bestimmten Mandanten oder eine bestimmte Fähigkeit gelten kann. Die Zustände umfassen: Normalbetrieb, HUMAN_ONLY zum Beenden der automatisierten Ausführung bei gleichzeitiger Beibehaltung der Vorschläge für Menschen, sowie HALTED zum vollständigen Anhalten der Entscheidungsfindung. Wenn der Schalter nicht erreichbar ist, besteht das sichere Verhalten darin, in den Modus der menschlichen Prüfung zu wechseln und nicht im Normalbetrieb fortzufahren.
Die Architektur, die Chaos verhindert
Die Quelle verknüpft die Betriebsfähigkeit mit einer Architektur in sechs Richtungen, die die Fachlogik über eine Schnittstelle und Adapter-Gateways von den Paketen der Modellanbieter trennt. Dadurch kann der Anbieter gewechselt werden, ohne die Geschäftslogik neu zu schreiben, und der Fachbereich kann mit einem netzwerk- und kostenfreien Mock-Modell getestet werden.
Die grundlegende Architektur umfasst zustandslose Agentendienste, ein Modell-Gateway, einen append-only Audit-Speicher, einen gemeinsamen Speicher für Grenzen und den Abschaltschalter, einen Geheimnisspeicher sowie einen Objektspeicher für Eingaben und sensible Daten. Außerdem betont die Quelle eine unabhängige Identität für jeden Dienst, das Prinzip der geringstmöglichen Berechtigungen und die Überprüfung, dass die Identität des Mandanten bei jedem Hop mit der Anfrage übereinstimmt, insbesondere bei der Verwendung kurzlebiger Delegationsberechtigungen für verzögerte Aufgaben.
Warum ist diese Nachricht wichtig?
Der praktische Wert liegt hier nicht in der Hinzufügung einer neuen Komponente, sondern in der Bündelung der kritischen Kontrollpunkte an einem einzigen Zugang: Das Gateway, das den Modellwechsel ermöglicht, misst zugleich die Kosten, setzt Grenzen durch, verwaltet Weiterleitung und Fallback und aktiviert das Abschalten. Der Erfolg dieses Ansatzes bleibt jedoch davon abhängig, dass Fehlerszenarien tatsächlich getestet werden, etwa der Ausfall eines Modellanbieters, die Aktivierung des Abschalters, eine plötzliche Last und der Neustart eines Knotens während einer laufenden Entscheidung. Ohne diese Tests bleiben die Wiederherstellungsmechanismen unbestätigte Annahmen.