Bevor wir den Ablauf verändert haben, wurde die Laufzeit in Phasen zerlegt.
Das Problem: Jeder Schritt kostet Zeit
Planung, Werkzeugaufrufe und Antwortprüfung können sich addieren. Eine zusätzliche Prüfung bei jeder harmlosen Schätzung hilft nicht automatisch. Entscheidend ist, ob noch ein wesentlicher Widerspruch oder ungeklärter Zustand besteht.
Die Änderung: Prüfaufwand nach Bedarf
Das Profil balanced nutzt für gewöhnliche Antworten und Reviews mittleren Reasoning-Aufwand. Tiefe Analysen und kritische Konsistenzprüfungen behalten den höheren Aufwand. Die Antwortprüfung bleibt erhalten; eine separate Konsistenzrunde richtet sich auf wesentlich ungeklärte Zustände. Das bevorzugte Profil wird gespeichert.
Was tatsächlich gemessen wurde
Die Notizen nennen für denselben Planungsfall 48,4 statt 92,7 Sekunden. Eine reale Kalenderprüfung wurde mit 24,6 statt 32,5 Sekunden gemessen. Das sind einzelne dokumentierte Vergleiche, keine allgemeine Geschwindigkeitsgarantie. Die Laufzeiten schwanken weiterhin.
Geschwindigkeit braucht neue Gegenproben
Zusätzliche Qualitätsfälle wurden laut Entwicklungsprotokoll erfolgreich geprüft. Außerdem wurde eine Verwechslung zwischen Bearbeitungs- und Ausführungsfähigkeiten korrigiert. Eine schnellere Antwort muss weiterhin richtig darstellen, welche Aktion sie tatsächlich ausführen kann.
Die praktische Lehre
Leistung lässt sich verbessern, indem der Aufwand zu Aufgabe und Unsicherheit passt. Für kritische Entscheidungen bleiben gründliche Prüfungen sinnvoll. Für die Bewertung zählen sowohl frische Qualitätsfälle als auch nachvollziehbar gemessene Laufzeiten.
Wo die Wartezeit tatsächlich lag
Bevor wir den Ablauf verändert haben, wurde die Laufzeit in Phasen zerlegt. Die gemessenen CLI-Starts lagen ungefähr zwischen 0,1 und 0,8 Sekunden; nach dem Turn kamen etwa 0,5 bis 0,7 Sekunden Aufräumzeit hinzu. Der größte Teil der Wartezeit lag innerhalb des Modellturns. Dieser Abschnitt enthält allerdings auch Netzwerk- und Providerwartezeit. Er ist kein reines Maß für Inferenz. Einen Prozess warmzuhalten hätte somit nur einen kleinen Teil des beobachteten Problems adressiert. Die Änderung musste beim Aufwand der normalen Antwort- und Prüfturns ansetzen, ohne kritische Prüfungen pauschal abzuschalten.
Der Reviewer darf eine zusätzliche Prüfung gezielt auslösen
Im ausgewogenen Profil bleibt die Antwortprüfung bestehen. Ihr Ergebnis enthält ein validiertes Boolean, das eine zusätzliche Konsistenzrunde anfordern kann, wenn ein wesentlicher Zustand ungeklärt ist oder konkurrierende Interpretationen bestehen. Eine bereits deklarierte Schätzung soll nicht automatisch eine weitere Generation starten. Fehlt die Entscheidung, bleibt der konservative Weg erhalten. Ein ungültiger Wert darf nicht als Freigabe zum Überspringen gelten. Das Codefenster zeigt die Entscheidungsregel als reduziertes Python-Beispiel; es ist keine neue Implementierung eines täglichen Ablaufplans.
def needs_consistency_pass(review: dict) -> bool:
# Reduziertes Beispiel der konservativen Entscheidungsregel.
flag = review.get("requires_consistency")
if flag is None:
return True
if type(flag) is not bool:
raise ValueError("Review flag must be a boolean")
return flag
ordinary_reasoning = "medium"
critical_consistency_reasoning = "high"Warum wir Gegenproben statt nur dieselbe Anfrage genutzt haben
Eine Geschwindigkeitsänderung kann einen bekannten Test bestehen und dennoch bei leicht anderer Formulierung scheitern. Deshalb kamen frische Fälle hinzu: ein geänderter Trainingsplan, eine Anfrage nach bloßem Entwurf und eine Situation mit unlesbarem Zustand eines bestehenden Timers. Beim Timer musste die Fähigkeit erhalten bleiben, eine native Anfrage vorzubereiten, ohne einen doppelten Timer auszulösen. Dieser Fall brauchte weiterhin eine unabhängige gründliche Prüfung und dauerte 57,429 Sekunden. Das ist kein Ausreißer, den wir wegoptimieren: Die offene Zustandsfrage rechtfertigt mehr Aufwand.
Technische Referenz: Python: Laufzeiten messen.
Die Messwerte richtig lesen
Der Planungsvergleich sank von 92,677 auf 48,433 Sekunden. Die Kalenderprüfung sank von 32,45 auf 24,632 Sekunden. Im Planungstest waren Kalender und Routen Fixture-Integrationen; die Verfügbarkeitsprüfung nutzte den realen Kalender. Es sind einzelne Beobachtungen, keine kontrollierten Durchschnittswerte. Für den Betrieb bleiben deshalb Qualität, zusätzliche Modellaufrufe und Phasenzeiten getrennte Größen. Im Profil Gründlich können Actor und Erstprüfung weiterhin mit höherem Aufwand arbeiten. Wer eine langsame Antwort untersucht, sollte außerdem den Transport prüfen: Ein blockierter Ausgabekanal sieht aus Nutzersicht ebenfalls wie langsames Denken aus.
Weiterlesen: Wenn der Modellprozess läuft, aber keine Antwort ankommt.