Ein KI-Modell für eine reale Anwendung auswählen

Anforderungen

Den Produktablauf in einen Vertrag für die Modellauswahl übersetzen

Am Anfang steht die kleinste Leistung, die das Produkt verspricht. Beschrieben werden reale Eingabe, Ausgabevertrag, handelnde Person oder System und die nötigen Nachweise. Auch der Weg um das Modell gehört dazu: Retrieval, Zusammenstellung des Kontexts, Werkzeuge, Validierung, menschliche Prüfung und nachgelagerte Schreibvorgänge. Ein Modell für isolierte Fragen kann sich anders verhalten, wenn es private Quellen belegen, ein Schema ausgeben und ein eingeschränktes Werkzeug nutzen muss. Ziel der Auswahl ist deshalb das zusammengesetzte Verhalten, nicht ein abstrakter Intelligenzwert.

Zwingende Grenzen müssen von verhandelbaren Präferenzen getrennt werden. Datenverarbeitung, Bereitstellungsraum, Lizenzverträglichkeit, eine nicht umkehrbare Fehlerklasse oder ein vertragliches Latenzlimit können einen Kandidaten ausschliessen. Ein kleiner Qualitätsvorsprung oder leichtere Anweisungsentwicklung kann dagegen gewichtet werden. Zu erfassen sind Betriebssprachen, Eingabelängen, Dokumentrauschen, erwartete Parallelität und Spitzen. Zudem braucht es Regeln für Enthaltung und Übersteuerung. Dieser Vertrag verhindert, dass sich die Bewertung bei jedem guten Einzelbeispiel verschiebt.

Belege

Kandidaten im selben repräsentativen System vergleichen

Der Prüfkorpus entsteht aus betriebsnahen Fällen und nicht aus vorzeigbaren Demonstrationen. Er umfasst Normalvolumen, schwierige Randfälle, unzulässige Anfragen, beschädigtes Material und Beispiele, bei denen ein selbstsicherer Fehler hohe Folgen hat. Fälle werden nach Sprache, Quelle, Komplexität, Nutzergruppe und Auswirkung gegliedert. Referenzurteile und Prüfanweisungen müssen eindeutig sein. Deterministische Tests kontrollieren Schema, Belegpflicht, Werkzeugrechte und verbotene Aktionen. Fachkundige Personen bewerten Nutzen und sachliche Richtigkeit. Ihre Übereinstimmung zeigt, ob das Urteil selbst stabil ist.

Jeder Kandidat läuft durch denselben versionierten Prüfaufbau. Systemanweisungen, Retrieval, Werkzeugschnittstellen, Zufallsparameter und Ausgabevalidierung bleiben gleich, sofern eine begründete Anpassung nicht dokumentiert wird. Erfasst wird mehr als die Endantwort: Wiederholungen, Ablehnung, Werkzeugwahl, Belegnutzung, Latenz und Korrektur. Nichtdeterministische Fälle werden wiederholt und unter realistischer Last geprüft. Ein kleines Modell kann bei enger Aufgabe mit gutem Retrieval gewinnen. Ein grosses kann nur für eine schwierige Route nötig sein. Der Vergleich soll eine Betriebsarchitektur ergeben und keinen allgemeinen Sieger küren.

• Betriebsnahe Fälle verwenden und schwierige Fehlschläge erhalten.
• Wichtige Segmente getrennt vom Gesamtwert bewerten.
• Den Anwendungsaufbau während des Vergleichs stabil halten.
• Schwankung, Zwischenschritte und Prüfaufwand erfassen.
• Routing und Rückfall testen, wenn kein Modell alle Fälle optimal erfüllt.

Betrieb

Datenweg, Dienstverhalten und Gesamtkosten bewerten

Nachzuverfolgen ist, was die Anwendung verlässt, wo es verarbeitet wird, was gespeichert werden darf und welche Betreiber oder Unterauftragnehmer beteiligt sind. Technische Kontrollen und vertragliche Zusagen sind unterschiedliche Belege und müssen für die geplante Bereitstellung getrennt geprüft werden. Bei selbst betriebenen oder offen gewichteten Modellen zählen Lizenz, Herkunft, Infrastruktur, Aktualisierung, Zugriffssteuerung, Überwachung und internes Fachwissen. Kontrolle hat Wert, verursacht aber Arbeit. Bei gehosteten Modellen zählen Dienstgrenzen, Versionspolitik, Beobachtbarkeit, Vorfallbehandlung und besondere Anbieterfunktionen.

Berechnet werden Kosten je akzeptiertem Ergebnis, nicht nur je Verarbeitungseinheit. Dazu gehören durch Retrieval vergrösserte Eingaben, wiederholte Aufrufe, Werkzeuge, Validierung, Rückfälle, Zwischenspeicher, menschliche Prüfung, laufende Bewertung und Unterstützung. Mittlere und hohe Latenzen unter realistischer Last zeigen, ob ein interaktiver Ablauf trägt. Ebenfalls zu quantifizieren sind falsche Annahme und unnötige Eskalation. Danach lässt sich Routing prüfen: ein kleines Modell für Routine, ein spezialisiertes für schwierige Fälle und ein deterministischer oder menschlicher Rückfall, wenn Sicherheit oder Richtlinie es verlangen.

Entscheidung

Eine umkehrbare Wahl treffen und Modelländerungen steuern

Die Entscheidungsakte nennt Kandidaten, Versionen, Datum, harte Ausschlüsse, gewichtete Kriterien, Segmentergebnisse, offene Risiken und abweichende Einschätzungen. Die Gewichtung folgt der Anwendungsfolge und erzeugt keine Scheingenauigkeit. Ein Grenzwert für schwere Fehler kann einen hohen Gesamtscore überstimmen. Gewählt wird das einfachste Portfolio, das den Vertrag erfüllt. Es wird festgehalten, wann eine andere Route greift. Im Pilot werden reale Nutzung, Korrektur, Latenz und Ausnahmen beobachtet. Rückkehrbedingungen stehen vorher fest, damit eine gute Vorführung nicht unbemerkt zum unumkehrbaren Betrieb wird.

Das Modell bleibt eine austauschbare Abhängigkeit, deren Verhalten sich verändern kann. Anbieteraufrufe liegen hinter einer Anwendungsschnittstelle, Anweisungen und Prüffälle stehen unter Versionskontrolle, Modellversionen werden protokolliert und vor geplanten Aktualisierungen laufen Regressionstests. Unangekündigte Veränderungen werden mit kleinen Kontrollgruppen und Stichproben erkannt. Eine Alternative richtet sich nach der Kritikalität: anderer Anbieter, offen gewichtete Bereitstellung, deterministischer Modus oder manuelle Warteschlange. Umkehrbarkeit verlangt keine künstliche Gleichbehandlung aller Anbieter, sondern Klarheit über bewusst gewählte Bindungen.

• Modell- und Konfigurationsversion mit den Auswahlbelegen festhalten.
• Grenzwerte für schwere Fehler über eine attraktive Gesamtpunktzahl stellen.
• Im Pilot Nutzerverhalten und Last statt nur Offline-Qualität beobachten.
• Anbieterspezifische Funktionen hinter bewussten Grenzen kapseln.
• Jede wesentliche Änderung an Modell, Anweisung, Retrieval oder Werkzeug regressionstesten.