Ein Notfallhandbuch für einen LLM-Service

Signale, die die klassische Überwachung verpasst

Latenz, Fehlerrate und Sättigung erfassen die Ausfälle, die wie Infrastruktur aussehen. Ein LLM-Service hat eine zweite Familie von Ausfällen, die keine Fehler und keine langsamen Anfragen produzieren.

• Qualitätsverfall. Eine monatliche Stichprobe von Bewertungsartikeln, die bewertet und trendet werden. Ohne sie wird der Verfall Wochen später von den Benutzern gemeldet, in Form von Misstrauen.
• Ablehnungsrate. Eine steigende Ablehnungsrate ist oft das erste sichtbare Zeichen eines Abruf- oder Parsing-Problems, und es ist billiger, sie zu untersuchen, als eine Beschwerde.
• Kontextgröße pro Anfrage. Sie wächst stillschweigend, wenn Korpora und Konversationsverlauf anhäufen, und sie verlagert Kosten und Latenz gleichzeitig.
• Ausgabetokenanzahl. Eine Verschiebung der Verteilung hier bedeutet normalerweise eine Änderung des Prompts oder des Modells, und sie zeigt sich auf der Rechnung, bevor sie sich irgendwo anders zeigt.
• Anbietergesundheit. Die Fehlerrate ist nur ein Signal von einem Anbieter; unerklärliche Latenzverschiebungen und Änderungen der Antwortform sind auch wichtig, und sie sind die Vorhut eines anbieterseitigen Vorfalls.

So schreiben, dass es um drei Uhr morgens noch verständlich ist

Ein Runbook-Eintrag besteht aus vier Teilen: dem Signal, der ersten Aktion, der Eskalationsbedingung und dem Fallback. Die erste Aktion muss mechanisch und spezifisch sein – nicht untersuchen, sondern: überprüfe diese Seite, vergleiche diese Zahl mit ihrem Wert von vor einer Woche und wenn die Differenz den aufgezeichneten Schwellenwert überschreitet, führe dies aus.

Fallbacks gehören in das Runbook, weil sie Entscheidungen und keine Improvisationen sind. Mögliche Fallbacks umfassen die Weiterleitung an einen anderen Anbieter, das Herunterstufen auf ein kleineres Modell, die Verkürzung des Kontexts, die Deaktivierung der Neubewertung und die vollständige Deaktivierung der Funktion. Jeder benötigt einen vorab vereinbarten Trigger und eine benannte Person, die ihn autorisieren kann.

Die abgespeckten Modi, die es wert sind

• Kürzerer Kontext. Weniger abgerufene Passagen, geringere Qualität, viel geringere Kosten und Latenz. Billig zu implementieren und normalerweise das Erste, was man in Anspruch nimmt.
• Kleineres Modell. Die Qualität sinkt ungleichmäßig über verschiedene Aufgabentypen; im Voraus wissen, welche Aufgaben akzeptabel abnehmen und welche lieber fehlschlagen, anstatt schlecht zu antworten.
• Nur Cache. Vorher berechnete Antworten servieren und alles Neue ablehnen. Selten anwendbar, aber entscheidend, wenn der Korpus hauptsächlich aus stabilen Fragen besteht.
• Funktion deaktivieren. Der letzte Ausweg, und der einzige, der immer verfügbar sein muss. Wenn das Deaktivieren der Funktion eine Bereitstellung erfordert, ist das Runbook nicht fertig.

Praxis, die eine Stunde pro Quartal kostet

Üben Sie die degradierten Pfade und den Feature-Switch während der Geschäftszeiten und zeichnen Sie auf, wie lange jeder davon dauert. Ungetestete Switches funktionieren nicht, wenn sie benötigt werden, und der Ausfall ist normalerweise trivial – eine Berechtigung, die nur das Deployment-System hat, oder eine Konfiguration, die in der Umgebung, in der sie wichtig ist, nie geübt wurde. Eine Stunde pro Quartal ist der gesamte Kostenfaktor, um die Antwort zu kennen.