Ein Modell kann in einem Notebook gute Ergebnisse erzielen, während das Produkt dennoch unzureichende Antworten liefert. Die Produktionsanwendung kann die Frage umformulieren, einen anderen Anbieter auswählen, andere Textpassagen abrufen oder die Antwort nach der Generierung ablehnen.
Ich möchte, dass die Hauptbewertung über denselben Anwendungspfad erfolgt, den auch eine echte Anfrage nutzt. Andernfalls könnte eine Komponente zertifiziert werden, mit der der Kunde im isolierten Betrieb niemals in Berührung kommt.
Behalte zwei Bewertungsebenen bei
End-to-End-Tests zeigen mir, ob sich das Produkt korrekt verhält. Diagnosetests helfen dabei, festzustellen, warum dies nicht der Fall ist. Ich brauche beides.
Für einen Support-Mitarbeiter kann der gesamte Prozess den Umgang mit Mandantenrichtlinien, die Weiterleitung von Modellen, den Abruf, die Erstellung von Antworten, die Validierung von Nachweisen und die Übergabe umfassen. Eine Regression an einer dieser Schnittstellen sollte sich im Endergebnis widerspiegeln.
Diagnoseprüfungen untersuchen separat die abgerufenen Quellen, die umformulierten Abfragen, die extrahierten Aussagen und das Verhalten der Anbieteradapter. Sie sind für die Analyse nützlich, aber ich würde das Ergebnis auf Produktebene nicht durch eine Zusammenstellung der Erfolgsquoten der einzelnen Komponenten ersetzen.
Schreiben Sie Ihre Erwartungen auf, bevor Sie die Ausgabe lesen.
In jedem Bewertungsfall sollten die Absicht des Kunden, die vorliegenden Beweise, zulässige und unzulässige Behauptungen sowie die erwartete Maßnahme ermittelt werden. Einige Fälle sollten mit einer klärenden Frage oder einer Weiterleitung an einen Mitarbeiter enden.
Ich füge in die Dokumente gewöhnliche Fragen, unbegründete Fragen, mehrdeutige Verweise, veraltetes Material, sprachliche Änderungen und kontroverse Anweisungen ein. Die Verteilung sollte die Risiken des Produkts widerspiegeln, ohne den Anspruch zu erheben, eine perfekte Kopie des Live-Datenverkehrs zu sein.
Eine Fallbeschreibung wie „gute Antwort zum Thema Rückgaben“ lässt Raum für subjektive Bewertungen. „Muss fragen, welches Produkt bestellt wurde; darf keine Berechtigung versprechen“ gibt dem Prüfer eine Entscheidungsgrundlage, die er einheitlich anwenden kann.
Setzen Sie automatisierte Bewertungssysteme dort ein, wo sie hilfreich sind
Deterministische Prüfungen sind nützlich für exakte Identifikatoren, zulässige Verknüpfungen, unzulässige Aussagen und erforderliche strukturierte Felder. Die Überprüfung durch einen Menschen bleibt wichtig, um die semantische Korrektheit sicherzustellen und zu beurteilen, ob die Antwort dem Kunden weiterhilft.
Ein modellbasierter Bewerter kann den Überprüfungsaufwand verringern, doch ich betrachte seine Bewertung als eine weitere Messgröße, die kalibriert werden muss. Ich vergleiche sie mit den von Menschen vergebenen Bewertungen über relevante Falltypen hinweg und untersuche Abweichungen, anstatt lediglich die durchschnittliche Übereinstimmung zu messen.
Die Bewertungsrubrik sollte eine selbstbewusste, aber unbegründete Antwort abstrafen, selbst wenn der Text hervorragend formuliert ist. Außerdem sollte sie unnötige Verweigerungen als Systemversagen werten. Ein Juror, der Vorsicht ohne Nutzen belohnt, könnte ein System auswählen, das niemals eine Antwort gibt.
Schützen Sie das Testgerät vor wiederholter Abstimmung
Ich trenne die Beispiele, die zur Verbesserung der Pipeline dienen, von den Beispielen, die für eine spätere Überprüfung vorgesehen sind. Wenn jeder Fehler sofort in den Optimierungszyklus einfließt, verliert die Leistung bei denselben Beispielen an Aussagekraft.
Auch kleine Testdatensätze können wertvoll sein, doch sollten ihre Ergebnisse zusammen mit den Nennern und den Grenzen angegeben werden. Ein perfektes Ergebnis bei einer Handvoll negativer Fälle ist kein Beweis dafür, dass unbegründete Antworten ausgeschlossen wurden.
Wiederholte Durchläufe können Schwankungen dort aufdecken, wo es darauf ankommt. Ich muss nicht jede deterministische Randbedingung mehrfach neu berechnen, aber ein instabiles Erzeugungsverhalten verdient mehr als nur eine günstige Stichprobe.
Änderungen anhand derselben Belege vergleichen
Um eine Änderung bei der Datensuche zu überprüfen, vergleiche ich die alte und die vorgeschlagene Pipeline anhand derselben Fälle und desselben Quell-Snapshots. Dabei halte ich die Code-Version, die Prompt-Version, die Modellkonfiguration und die entsprechende Korpusversion fest.
Meine Auswertungsübersicht unterscheidet zwischen unterstützten Antworten, nicht unterstützten Antworten, unnötigen Enthaltungen, fehlgeschlagenen Übergaben, Latenzzeiten und Kosten. Eine zusammengefasste Gesamtbewertung kann einen nachteiligen Kompromiss zwischen diesen Dimensionen verschleiern.
In der Freigabeentscheidung sollte angegeben werden, welche Fehler die Bereitstellung blockieren. Eine mandantenübergreifende Offenlegung oder eine unbefugte Handlung erfordert eine andere Vorgehensweise als einen zwar umständlichen, aber korrekten Satz.
Nach der Bereitstellung wandle ich überprüfte Produktionsfehler in neue Fälle um und führe einen separaten Vorrat für zukünftige Änderungen. Die Bewertung wird so zu einer gepflegten Beschreibung der Anforderungen an das Produkt, die auf dem tatsächlichen Ablauf der Anwendung basiert.
Aktualisiert am 25. September 2026.