Der Modellname ist keine Abnahme

Eine Agentur schlägt einen Modellwechsel vor, weil Antworten schneller, günstiger oder besser werden sollen. Diese Begründung ist ein sinnvoller Ausgangspunkt, aber noch kein Nachweis. Halten Sie zuerst fest, welches konkrete Problem der Wechsel lösen soll und welche bisher funktionierenden Eigenschaften erhalten bleiben müssen.

Bei einer Dokumentenanalyse könnten das korrekte Beträge und fehlende Werte sein. Bei einem Assistenten sind vielleicht Quellenangaben und die zuverlässige Ablehnung unbelegter Aussagen entscheidend. Eine angenehmere Formulierung gleicht einen Fehler bei einem solchen Kernmerkmal nicht aus.

Google Cloud behandelt Modellmigrationen ausdrücklich als Aufgabe, bei der neue Antworten wiederholt bewertet werden müssen. Die beschriebenen Herstellerverfahren sind keine Leistungsgarantie für Ihr Projekt. Für Ihre Beauftragung zählt der nachvollziehbare Vergleich im eigenen Anwendungsfall.

Einen festen Referenzstand sichern

Bevor jemand Konfigurationen ändert, sollte die Agentur den bisherigen Stand dokumentieren: Modellkennung, Promptversion, Suchkonfiguration, relevante Parameter, Werkzeuge und Testdaten. Nur so lässt sich erkennen, was beim Vergleich tatsächlich geändert wurde.

Wenn gleichzeitig neue Dokumente, andere Prompts und ein neues Modell eingeführt werden, lässt sich eine Verbesserung schwer zuordnen. Unser Vorschlag ist, den Modellwechsel zunächst isoliert zu prüfen. Zusätzliche Anpassungen können danach in einer eigenen Runde erfolgen und separat begründet werden.

Speichern Sie nicht einfach vertrauliche Produktivgespräche als Testbestand. Verwenden Sie freigegebene Fälle mit klaren erwarteten Eigenschaften. Der Test benötigt genug fachlichen Kontext, muss aber keine unnötigen Personen- oder Kundendaten enthalten.

Fallgruppen statt einer einzigen Gesamtnote

Stellen Sie den Prüfsatz aus häufigen Aufgaben und besonders folgenreichen Ausnahmen zusammen. Dazu gehören normale Eingaben, fehlende Informationen, widersprüchliche Quellen und Fälle, in denen das System keine automatische Aktion ausführen darf.

Die Google-Cloud-Anleitung für MLOps beschreibt neben dem Vergleich mit einer Baseline auch die Prüfung einzelner Datensegmente. Der Kontext ist maschinelles Lernen allgemein; für einen KI-Assistenten lässt sich daraus eine sinnvolle Prüfidee ableiten: Bewerten Sie Ihre wichtigen Aufgabengruppen getrennt.

Eine durchschnittliche Verbesserung kann sonst verdecken, dass beispielsweise französische Dokumente schlechter verarbeitet werden. Legen Sie deshalb vor dem Test fest, welche Fehler einen Wechsel blockieren und wo ein begrenzter Kompromiss vertretbar wäre.

Ein Vergleich mit fiktiven Ergebnissen

Ein KMU prüft beispielhaft 60 freigegebene Fälle einer Auftragsassistenz. 30 betreffen einfache Bestellungen, 15 unvollständige Anfragen und 15 widersprüchliche Angaben. Diese Anzahl ist ein redaktionelles Beispiel und kein ausreichender Stichprobenumfang für jedes Projekt.

Im erfundenen Ergebnis verarbeitet das neue Modell einfache Aufträge schneller. Bei drei unvollständigen Anfragen ergänzt es jedoch eine Lieferadresse, obwohl diese nicht belegt ist. Der bisherige Stand hatte diese Fälle korrekt zur Klärung weitergeleitet.

Die Freigabeentscheidung lautet daher nicht «insgesamt besser». Zuerst muss die unerlaubte Ergänzung behoben und erneut geprüft werden. Eine passende Bewertungskarte enthält:

• Fallkennung und zugehörige Aufgabenklasse.

• Erwartetes fachliches Verhalten, einschliesslich zulässiger Rückfragen.

• Ergebnis des bisherigen und des neuen Stands.

• Fehlerart und mögliche Auswirkung auf den Prozess.

• Bearbeitungszeit und gemessenen Verbrauch unter vergleichbaren Bedingungen.

• Entscheidung mit verantwortlicher Person und Begründung.

Kontrolliert einführen und Rückkehr prüfen

Nach bestandenem Vergleich empfehlen wir eine begrenzte Einführung für ausgewählte Aufgaben oder Nutzer. Beobachten Sie vorher vereinbarte Kennzahlen und Rückmeldungen. Ein kleiner Start ersetzt die Tests nicht, ergänzt sie aber um die Bedingungen des tatsächlichen Betriebs.

Eine Rückkehr zum alten Modell muss technisch und vertraglich möglich sein. Alte Versionen können vom Anbieter eingestellt werden; «wir schalten einfach zurück» ist deshalb keine dauerhafte Zusage. Lassen Sie den verfügbaren Rückkehrweg und gegebenenfalls einen manuellen Ersatzprozess dokumentieren.

Klärungsfälle aus dem Betrieb ergänzen später den Prüfsatz. Dadurch wächst eine eigene Qualitätssicherung, die beim nächsten Modellwechsel wiederverwendbar ist. Halten Sie Testfälle und Produktivdaten dabei kontrolliert auseinander und prüfen Sie, ob neue Fälle tatsächlich andere Fehler abdecken.

Für Wissensanwendungen ergänzt dieser Ablauf die Prüfung der RAG-Antwortqualität. Wenn Sie einen Wechsel beurteilen möchten, kann einclick als KI-Agentur aus Zürich daraus einen klar abgegrenzten Vergleich mit dokumentierter Freigabeentscheidung machen.