Sieben Optimierungen gemessen, keine behalten
Vier Tuning-Eingriffe und eine Vektordatenbank: alle plausibel, alle wieder ausgebaut. Was am Ende wirklich half, kostete keine Rechenzeit.
Am Ende des Tages lief unser Sprachmodell-Server exakt so wie am Morgen. Kein Parameter geändert, kein Update behalten, keine neue Datenbank. Sieben Eingriffe hatten wir vorbereitet, gemessen und wieder ausgebaut.
Es war trotzdem ein guter Tag — und der Grund dafür ist der eigentliche Inhalt dieses Berichts.
Die Vermutung, die sich gut anhörte
Ausgangspunkt war eine naheliegende Überlegung. Unser Assistent bekommt bei jeder Anfrage denselben Vorspann: Systemanweisung, Werkzeugbeschreibungen, Regeln. Das ist bei jedem Aufruf identisch — und wird, so die Annahme, jedes Mal neu verarbeitet. Es gibt eine Einstellung, die genau das vermeiden soll.
Wir haben sie eingeschaltet und gemessen. Das Ergebnis: 13 Prozent langsamer im Mittel, 21 Prozent im oberen Bereich, bei exakt gleicher Antwortqualität — dieselben Treffer, dieselben Fehler, Zeichen für Zeichen.
Die Annahme war schlicht falsch. Der Server behält identische Vorspänne ohnehin schon. Die zusätzliche Einstellung löst ein anderes Problem — Lücken mitten im Text — und bezahlt dafür mit Verwaltungsaufwand, den unsere Anfragen gar nicht brauchen. Wir haben sie noch am selben Vormittag wieder entfernt.
Wenn die Kennzahl steigt und das System langsamer wird
Der zweite Eingriff vergrößerte die Verarbeitungsblöcke beim Einlesen langer Texte. Die Kennzahl dafür schnellte hoch: bis zu 63 Prozent mehr Durchsatz beim Einlesen. Ein klarer Gewinn, sollte man meinen.
Nur: Die Zeit, die ein Nutzer tatsächlich auf eine Antwort wartet, blieb unverändert. Und die Trefferquote bei der Werkzeugwahl fiel von 98 auf 96 von 107 Fällen. Ein Kontrolllauf mit identischer Konfiguration lieferte exakt dieselben 96 — der Verlust war also systematisch, kein Zufall.
Beim dritten Eingriff, einer neueren Version der Modell-Laufzeit, wiederholte sich das Muster in verschärfter Form: 13 bis 22 Prozent mehr Token pro Sekunde — und trotzdem 15 bis 18 Prozent längere Antwortzeiten Ende zu Ende, bei buchstäblich identischen Ergebnissen.
Die Erklärung ist unspektakulär und übertragbar: Bei kurzen Anfragen dominieren die Fixkosten pro Aufruf, nicht die Verarbeitungsrate. Was an Durchsatz gewonnen wird, geht an Anlaufkosten wieder verloren.
Die Lehre daraus haben wir uns notiert: Immer die Größe messen, die der Nutzer erlebt. Interne Durchsatzzahlen sind Diagnose, nicht Urteil. Beides gehört gemessen — entschieden wird nach der Wartezeit.
Die Vektordatenbank, die keine wurde
Der zweite Teil des Tages galt einer echten Lücke: Unsere Notizsammlung — mehrere hundert Dokumente, Hunderttausende Wörter — war für die Assistenten nur Datei für Datei lesbar, ohne Suchindex.
Der Standardweg dafür heißt Vektordatenbank: Texte in Zahlenvektoren übersetzen, nach Bedeutungsähnlichkeit suchen. Wir haben ihn nicht als gesetzt genommen, sondern gegen die einfachste denkbare Alternative antreten lassen — eine klassische Stichwortsuche, wie sie in jeder Datenbank steckt.
Vorher haben wir eine Prüfliste gebaut: 85 Fragen an die eigene Sammlung, mit bekannten Antworten und hinterlegten Quellen, eingefroren und versioniert. Ohne Messlatte wäre die Entscheidung Geschmackssache geblieben.
Das Ergebnis war deutlich — zugunsten der einfachen Lösung:
| Verfahren | Treffer | Antwortzeit |
|---|---|---|
| Stichwortsuche | 94,4 % | 4 ms |
| Bedeutungssuche (Vektoren) | 88,7 % | 164 ms |
| Kombination aus beidem | 94,4 % | 168 ms |
Der Vergleich war dabei sogar zugunsten der Vektorsuche verzerrt: Sie musste nur einen sechsmal kleineren Textbestand durchsuchen, weil das Erzeugen der Vektoren auf unserer Hardware so lange dauerte, dass ein vollständiger Durchlauf über eine Stunde gebraucht hätte. Selbst mit diesem Vorsprung verlor sie.
Die Kombination aus beidem holte gegenüber der reinen Stichwortsuche exakt null Prozentpunkte — für die vierzigfache Antwortzeit. Entscheidung: keine Vektordatenbank, kein Nachsortierer, kein zusätzlicher Dienst. Der Index ist jetzt eine Datei und braucht 0,3 Sekunden zum Aufbau.
Was tatsächlich half
Die Verbesserungen des Tages kamen aus einer ganz anderen Ecke — und keine davon kostete Rechenzeit.
Zusammengesetzte Wörter zerlegen. Die Suche fand einen Störfallbericht nicht, weil die Frage den Namen mit Bindestrichen schrieb und die Notiz ohne. Kein Bedeutungsproblem, ein Schreibweisenproblem. Fünfzehn Zeilen, die Komposita zusätzlich in ihre Bestandteile zerlegen, hoben die Trefferquote von 81,7 auf 91,6 Prozent. Das ist mehr, als die Vektorsuche je geliefert hätte.
Jedem Fundstück sein Datum mitgeben. Vorher zitierte der Assistent einen zwei Monate alten Stand als aktuellen Zustand. Seit Datum und Archiv-Status an jedem Textausschnitt hängen, sagt er stattdessen „laut Stand vom …“ — oder enthält sich. Die falschen Antworten halbierten sich.
Und der dritte Ausgang. Das war der wertvollste Hinweis des Tages, und er kam nicht von uns.
„Bewusst nicht“ ist keine Wissenslücke
Unser System kannte zwei Antworten: die Auskunft und das ehrliche „weiß ich nicht“. Dass Enthaltung eine vollwertige Antwort ist, halten wir seit Langem für ein Feature und nicht für einen Mangel.
Auf die Frage „Nutzen wir eine Vektordatenbank?“ antwortete es jedoch: weiß ich nicht — obwohl die Entscheidung dagegen als Beleg an erster Stelle vor ihm lag. Es fand kein solches System und hielt das für Unwissen.
Der Unterschied ist alles andere als akademisch. Wir führen zu jedem verworfenen Vorschlag fest, warum er verworfen wurde — genau damit er nicht in sechs Monaten erneut auf dem Tisch liegt. Wer fragt und „weiß ich nicht“ hört, rollt die Frage neu auf. Die Messung dahinter war dann umsonst.
Der Fix war eine dritte Regel neben „antworte“ und „enthalte dich“: Zeigt ein Beleg, dass etwas geprüft und verworfen wurde, ist das die Antwort — mit Datum und Begründung. Enthaltung gilt nur, wenn die Unterlagen wirklich schweigen.
Die Wirkung, gemessen am identischen Fragensatz: Die Erledigungsquote stieg von 76,5 auf 80 Prozent, die falschen Antworten sanken von drei auf eine. Entscheidend war die Gegenprobe: Die Bereitschaft, sich bei echten Lücken zu enthalten, blieb unverändert. Das System wurde nicht geschwätziger — es unterscheidet nur sauberer.
Abgesichert haben wir das mit neun weiteren Prüffällen, darunter drei, deren richtige Antwort „ja“ lautet. Ohne die hätte die Prüfliste belohnt, auf jedes „Nutzen wir X?“ reflexhaft Nein zu sagen.
Was bleibt
Ein Tag, an dem sieben Eingriffe rückgängig gemacht wurden, sieht in einer Fortschrittsliste schlecht aus. Praktisch ist er einer der nützlicheren gewesen.
Erstens liegt jetzt eine Prüfliste vor, die künftige Vorschläge in Minuten entscheidbar macht statt in Meinungen. Zweitens sind vier Sackgassen mit Zahlen geschlossen — der eigentliche Wert ist nicht das Verwerfen, sondern dass sie nicht wiederkommen. Drittens wurden aus der Prüfung heraus drei veraltete Angaben in unserer eigenen Dokumentation gefunden und korrigiert; eine davon hatte ein Modell brav zitiert, weil sie eben dort stand.
Dieselbe Erfahrung hatten wir schon bei unserem Tool-Calling-Projekt, wo eine prüfbare Wissensbasis mehr brachte als ein dreimal größeres Modell: Grounding schlägt Gewichte. Es ist bemerkenswert, wie oft die teure Lösung verliert, sobald man sie gegen die billige antreten lässt — und wie selten man das tatsächlich tut.
Ein Tuning-Schalter, dessen Nutzen man sich aus dem Namen erschließt, ist eine Hypothese. Erst die Messung macht daraus eine Verbesserung. Oder, in vier von sieben Fällen: einen Rückbau.