Kurz zusammengefasst
- Ein öffentliches Benchmark-Ergebnis ersetzt keine Evaluation mit eigenen Fällen und Sprachen.
- Modellqualität umfasst neben Richtigkeit auch Quellenbezug, Format, Laufzeit, Robustheit und Kosten.
- Anbieter und Modell sind getrennte Entscheidungen: Dasselbe Modell kann über verschiedene Betriebswege angeboten werden.
- Auswahlkriterien, Testdaten, Versionen und akzeptierte Kompromisse sollten nachvollziehbar dokumentiert werden.
Warum beginnt der Vergleich mit der Aufgabe?
Modelle sind je nach Sprache, Dokumentart, Tool-Nutzung und gewünschtem Ausgabeformat unterschiedlich geeignet. Eine allgemeine Frage wie 'Welches Modell ist das beste?' hat deshalb keine belastbare Antwort. Definieren Sie zunächst, was die Anwendung tun muss und welche Fehler nicht akzeptabel sind.
Ein Testset enthält typische Fälle, schwierige Ausnahmen, unvollständige Eingaben und Aufgaben, die das System ablehnen oder eskalieren soll. Alle Kandidaten erhalten denselben Anwendungskontext und werden mit derselben Bewertungsmethode geprüft.
- Eigene Fachsprache und tatsächlich verwendete Sprachen abdecken
- Standard-, Grenz-, Risiko- und Nicht-beantwortbar-Fälle einschliessen
- Modell, Prompt, Quellen und Tool-Konfiguration versionieren
- Mindestwerte und kritische Ausschlussfehler vor dem Test festlegen
Welche Qualitätsdimensionen sollten gemessen werden?
Eine durchschnittliche Gesamtnote kann relevante Schwächen verdecken. Messen Sie getrennt, ob die Lösung fachlich richtig, vollständig, belegt und im benötigten Format antwortet. Für produktive Nutzung zählen ebenso Laufzeit, Stabilität und Verhalten bei fehlendem Kontext.
Die folgenden Fallzahlen, Grenzwerte und Gewichte sind ein zusammenhängendes Beispiel für eine Dokumentenextraktion und keine universellen Standards. Sie müssen vor dem Test passend zu Prozess, Risiko, Sprache, Volumen und akzeptierbaren Fehlern festgelegt werden; die Modellgewichte ergeben in diesem Beispiel zusammen 100 Prozent.
| Modellkriterium | Messmethode | Beispiel-Mindestwert | Gewicht | Nachweis |
|---|---|---|---|---|
| Fachlicher Aufgabenerfolg | Blindprüfung von 180 repräsentativen Fällen | Mindestens 97 % korrekte Pflichtfelder; kein kritischer Fehlfall | 35 % | Versionierter Eval-Bericht mit Fehlerkategorien |
| Quellen und Zurückhaltung | Belege sowie bewusst unbeantwortbare Fälle prüfen | Mindestens 95 % korrekte Belege und 98 % richtige Eskalationen | 25 % | Fundstellen und Ablehnungsgründe pro Testfall |
| Format und Tool-Nutzung | Schema-Validierung und erlaubte Tool-Pfade | 99 % valides Format; keine unzulässige Aktion | 15 % | Automatisierte Testprotokolle und Tool-Logs |
| Robustheit | Umformulierungen, fehlende Angaben und Störungen wiederholen | Qualitätsabfall höchstens 5 Prozentpunkte | 10 % | Regressionstest über Varianten und Modellversionen |
| Laufzeit und Kosten | End-to-End-Messung pro erfolgreichem Fall | 95. Perzentil unter 8 Sekunden; unter CHF 0.20 | 15 % | Messdaten aus identischer Testumgebung |
Was muss neben dem Modell bewertet werden?
Der Anbieter bestimmt, in welchen Regionen und Betriebsformen das Modell verfügbar ist, wie Eingaben verarbeitet und gespeichert werden und welche Servicezusagen gelten. Auch Support, Änderungsankündigungen und Zugriff auf Protokolle beeinflussen den Betrieb.
Modell- und Anbieterbewertung bleiben zwei getrennte Ergebnisse. Nach bestandenen Muss-Kriterien ergeben die beiden gewichteten Anbieterkriterien in diesem Beispiel eine eigene Anbieterwertung von 100 Prozent; eine spätere Gesamtentscheidung muss beide Werte und allfällige Ausschlüsse sichtbar ausweisen.
| Anbieterkriterium | Prüfung | Muss-Kriterium oder Anbietergewicht | Erforderlicher Nachweis |
|---|---|---|---|
| Datenbedingungen | Dienst, Tarif, Region, Speicherung, Training, Löschung und Unterauftragnehmer abgleichen | Muss-Kriterium | Vertrag, Leistungsbeschreibung und dokumentierter Datenfluss stimmen überein |
| Identität und Sicherheit | SSO, Rollen, Netzwerk, Verschlüsselung, Logs und Incident-Meldung praktisch testen | Muss-Kriterium | Technischer Pilot plus gültige Sicherheits- und Auditnachweise |
| Betrieb und Änderung | Quoten, Verfügbarkeit, Modellversionen, Abschaltungen und Supportfall simulieren | 55 % der separaten Anbieterwertung | SLA, Änderungsfristen und protokollierter Supporttest |
| Kommerziell und Exit | Preisstaffeln, Mindestbezug, Haftung, Export und Kündigungsfolgen rechnen | 45 % der separaten Anbieterwertung | Dreijahresrechnung und erfolgreich getesteter Export |
Wie bleibt der Auswahlprozess nachvollziehbar?
Gewichten Sie Kriterien vor der Entscheidung und lassen Sie Fachbereich, IT, Sicherheit, Datenschutz und Betrieb ihre jeweiligen Mindestanforderungen festlegen. Ein Kandidat, der ein Ausschlusskriterium verletzt, wird nicht durch einen hohen Durchschnittswert gerettet.
- Kurze Liste geeigneter Kandidaten statt ungezielter Marktvergleich
- Blind oder zumindest einheitlich bewertete Testantworten
- Getrennte Bewertung von Modell, Bereitstellungsweg und Anbieter
- Wiederholbarer Test für spätere Modell- und Versionswechsel
Beispiel: Extraktion aus technischen Serviceberichten
Drei Modelle extrahieren Fehlercode, Bauteil und Massnahme aus 180 anonymisierten Berichten in Deutsch, Französisch und Englisch. Bewertet werden Feldgenauigkeit, korrekte Leerstelle bei fehlenden Angaben, Laufzeit und Kosten. Zwei Anbieter erfüllen die Qualität. Die endgültige Wahl fällt auf den Bereitstellungsweg, der vorhandene Identitäten, gewünschte Region und Versionskontrolle unterstützt. Das Testset bleibt als Regressionstest erhalten.
Was Sie mitnehmen sollten
Vergleichen Sie Kandidaten mit denselben echten Aufgaben und klaren Ausschlussgrenzen. Entscheiden Sie anschliessend über die gesamte Bereitstellung – nicht über eine Ranglistenposition oder einen Modellnamen.
Quellen und Vertiefung
Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.
Inhaltlich geprüft