Woher weiß ich, ob die Antwort besser geworden ist?
- Matt
Bei klassischem Code beantwortet ein Test die Frage, ob eine Änderung etwas kaputt gemacht hat. Bei einem Prompt gibt es diese Sicherheit nicht. Man formuliert um, probiert drei Fragen durch, findet die Antworten irgendwie besser und schiebt es live. Zwei Wochen später meldet jemand einen Fall, der vorher funktioniert hat.
Das gilt für einen einfachen Prompt genauso wie für eine Kette mit Tool Calling oder RAG. Microsoft.Extensions.AI.Evaluation versucht, daraus etwas Messbares zu machen. Der Ansatz: Ein zweites Modell bewertet die Antworten des ersten anhand fester Kriterien.
Aufbau
dotnet add package Microsoft.Extensions.AI.Evaluation
dotnet add package Microsoft.Extensions.AI.Evaluation.Quality
Bewertet wird gegen eine ChatConfiguration, also gegen das Modell, das die Rolle des Prüfers übernimmt:
using Microsoft.Extensions.AI.Evaluation;
using Microsoft.Extensions.AI.Evaluation.Quality;
var chatConfiguration = new ChatConfiguration(pruefClient);
IEvaluator bewerter = new RelevanceTruthAndCompletenessEvaluator();
EvaluationResult ergebnis = await bewerter.EvaluateAsync(
messages: verlauf,
modelResponse: antwort,
chatConfiguration: chatConfiguration);
foreach (var metrik in ergebnis.Metrics.Values)
{
Console.WriteLine($"{metrik.Name}: {metrik.Interpretation?.Rating}");
}
Der RelevanceTruthAndCompletenessEvaluator prüft drei Dinge auf einmal: Passt die Antwort zur Frage, stimmt sie inhaltlich, und ist sie vollständig. Daneben gibt es CoherenceEvaluator und FluencyEvaluator für die sprachliche Seite. Alle geben Werte auf einer Skala zurück, nicht bestanden oder durchgefallen.
Mit Options(includeReasoning: true) liefert der Bewerter zusätzlich eine Begründung. Die ist beim Entwickeln nützlicher als die Zahl, weil man daraus liest, woran sich das Prüfmodell gestört hat.
Als Test statt als Skript
Der eigentliche Nutzen entsteht, wenn das in der Testsuite landet. Man legt eine Handvoll Fragen fest, für die man weiß, wie die Antwort aussehen soll, und lässt sie bei jeder Prompt-Änderung durchlaufen. Für die Ablage gibt es DiskBasedReportingConfiguration, die Ergebnisse über mehrere Läufe hinweg speichert, sodass man den Verlauf sieht statt nur den aktuellen Stand.
Das ist der Punkt, an dem aus Bauchgefühl eine Aussage wird: Diese Umformulierung hat bei drei von zwanzig Fragen zu schlechteren Antworten geführt.
Was man dabei nicht vergessen darf
Der Prüfer ist selbst ein Sprachmodell. Er hat gute und schlechte Tage, er ist nicht deterministisch, und er ist bei manchen Fragen genauso ahnungslos wie der Kandidat. Zwei Läufe mit identischer Eingabe können unterschiedliche Werte liefern. Absolute Zahlen sind deshalb wertlos, es zählt der Vergleich zwischen zwei Ständen unter sonst gleichen Bedingungen.
Dazu kommt: Jede Bewertung ist ein weiterer Modellaufruf. Zwanzig Testfragen mal drei Bewerter sind sechzig zusätzliche Aufrufe pro Durchlauf. Das ist nichts, was bei jedem Commit laufen sollte, sondern eher vor einem Release oder nach einer größeren Prompt-Änderung.
Und die Paketdokumentation weist ausdrücklich darauf hin, dass die Bewerter auf Modelle der Güteklasse gpt-4o ausgelegt sind. Mit einem kleineren Prüfmodell bekommt man Zahlen, die zwar plausibel aussehen, aber nichts mehr aussagen. Der Prüfer muss besser sein als der Geprüfte, sonst misst man Rauschen.