Wie testet man Foundation Models Evaluations? iOS-Tutorial 2026

Ein klassischer Unit-Test kann zuverlässig prüfen, ob eine Funktion bei einer bestimmten Eingabe einen Wert zurückgibt, einen Fehler behandelt oder eine definierte Verzweigung ausführt. Bei generierten Inhalten reicht diese Art von Assertion nicht aus: Eine Antwort kann formal gültig sein und trotzdem am Produktziel vorbeigehen. Umgekehrt ist ein leicht anderer Wortlaut nicht automatisch ein Fehler.

Apple beschreibt Evaluations als Framework, mit dem sich die Qualität intelligenter Funktionen messen lässt. Die Dokumentation zu Evaluations erläutert die Bausteine: Datensätze mit Beispielen, Metriken, Evaluatoren und zusammengefasste Ergebnisse. Im WWDC26-Video zu Evaluations wird der Zweck des Frameworks ebenfalls im Zusammenhang mit dem Prüfen intelligenter Funktionen dargestellt.

Für Ihre Tests sollten Sie daher drei Fragen getrennt beantworten:

• Funktioniert der Programmablauf? Das prüfen deterministische Unit-Tests und gewöhnliche Assertions.
• Erfüllt die generierte Antwort die Produktanforderung? Das prüfen Evaluations anhand Ihrer Beispiele und Bewertungsregeln.
• Bleibt die Qualität über mehrere Änderungen hinweg ausreichend? Dafür vergleichen Sie nachvollziehbar festgehaltene Ergebnisse über Versionen, Prompts oder Konfigurationen hinweg.

Eine Evaluation ist keine Garantie, dass jede Antwort in der späteren Nutzung richtig ist. Sie zeigt, wie sich Ihr System auf dem geprüften Datensatz unter der festgelegten Bewertungslogik verhält. Der Umfang und die Qualität dieser Aussage hängen deshalb an Ihren Beispielen und Ihrer Definition von „gut“.

Wie prüfen Sie, ob ein neuer Prompt die Qualität verbessert? Lassen Sie die bisherige und die geänderte Variante mit denselben Eingaben und derselben Bewertungslogik laufen. Erst dann können Sie die Ergebnisse sinnvoll gegenüberstellen.

Behalten Sie beim Vergleich mindestens diese Bedingungen konstant:

• dieselben repräsentativen Eingaben und erwarteten Eigenschaften;
• dieselbe Metrik und derselbe Evaluator;
• dieselbe Testumgebung und dokumentierte Konfiguration;
• dieselbe Regel dafür, welche Ergebnisse manuell nachgeprüft werden.

Apple führt Evaluations als Möglichkeit an, unterschiedliche Strategien zu vergleichen und Qualitätsveränderungen zu verfolgen. Das ist jedoch kein Freibrief, aus einem einzelnen abweichenden Ergebnis eine allgemeine Aussage über ein Modell abzuleiten. Dokumentieren Sie, welche Änderung Sie geprüft haben, welche Beispiele betroffen waren und ob der Unterschied bei einer Einzelprobe oder im aggregierten Resultat sichtbar wurde.

Wie kontrollieren Sie eine Qualitätsregression nach einer Prompt- oder Modelländerung? Speichern Sie die Eingaben, die Bewertungsregeln und die Ergebnisübersicht der vorherigen Variante. Führen Sie anschließend beide Varianten unter vergleichbaren Bedingungen aus. Prüfen Sie, ob sich einzelne Fälle verschlechtern, ob sich das Gesamtbild verändert und ob die Veränderung für Ihre Produktanforderung relevant ist. Ein Aggregat allein kann einen kritischen Einzelfall verdecken.

Ändern Sie nicht gleichzeitig Prompt, Beispieldatensatz und Bewertungsregel, wenn Sie die Ursache eines Ergebnisses nachvollziehen müssen. Trennen Sie Änderungen oder halten Sie jede Änderung so fest, dass die Vergleichsbedingungen sichtbar bleiben.

Eine kleine, bequeme Beispielsammlung kann ein überzeugendes Resultat erzeugen, ohne schwierige Nutzung abzudecken. Erfassen Sie deshalb nicht nur ideale, kurze Eingaben. Berücksichtigen Sie die in Ihrem Produkt zu erwartenden Unterschiede: unvollständige Angaben, unterschiedliche Formulierungen, Mehrdeutigkeit sowie Fälle, in denen die Funktion keine sichere oder passende Antwort liefern sollte.

Die Apple-Anleitung zur Gestaltung von Evaluationsdatensätzen ist hierfür die maßgebliche Referenz. Sie unterstützt die Planung von Datensätzen, aber die Verantwortung für die Repräsentativität Ihrer konkreten Beispiele bleibt bei Ihnen. Fragen Sie bei jeder Stichprobe: Welche reale Nutzung soll dieser Fall repräsentieren, und welche Fehlentscheidung würde die Evaluation übersehen, wenn dieser Fall fehlt?

Apple dokumentiert außerdem einen SampleGenerator im Zusammenhang mit der Erstellung von Evaluationsdaten. Behandeln Sie erzeugte Beispiele als Entwürfe, nicht als automatisch bestätigte Nutzungsfälle. Prüfen Sie, ob die Eingaben plausibel sind, ob die erwarteten Verhaltensweisen tatsächlich zu Ihrem Produkt passen und ob die Sammlung auch schwierige Fälle enthält. Ein Generator kann beim Erstellen helfen; er kann nicht für Sie entscheiden, was Ihre Nutzer erwarten oder welche Fehler für Ihre App schwerwiegend sind.

Wie erkennen Sie, ob eine Metrik für Ihr Produkt taugt? Leiten Sie sie aus einer konkreten Produktanforderung ab und prüfen Sie an Beispielen, ob ein gutes Ergebnis tatsächlich eine hilfreiche Antwort kennzeichnet. Eine Metrik, die nur sprachliche Ähnlichkeit belohnt, kann etwa eine sinngleiche, aber anders formulierte Antwort ungünstig bewerten. Eine breit formulierte Bewertungsregel kann dagegen einen wichtigen fachlichen Fehler übersehen.

Verwenden Sie für heikle oder mehrdeutige Fälle eine zusätzliche manuelle Prüfung. Sie müssen nicht jede Bewertung menschlich wiederholen; wählen Sie gezielt Beispiele aus, bei denen der Evaluator besonders wahrscheinlich irrt oder die Folgen einer Fehlbewertung relevant wären. Das Ergebnis bleibt eine Kombination aus Messung und fachlicher Beurteilung, nicht ein universeller Gütestempel.

Bei einer Funktion mit Tool-Aufrufen reicht es nicht, nur den abschließenden Antworttext zu bewerten. Ein Agent kann eine plausibel klingende Antwort liefern, obwohl er das falsche Werkzeug ausgewählt, notwendige Eingaben ausgelassen oder einen unpassenden Ablauf ausgeführt hat. Umgekehrt kann ein korrekter Werkzeugaufruf zu einer Antwort führen, die für Nutzende nicht verständlich ist.

Die Apple-Dokumentation zur Bewertung des Tool-Aufrufverhaltens behandelt diese zusätzliche Prüfdimension. Formulieren Sie in Ihren Beispielen daher nicht nur, welche Endantwort Sie erwarten. Halten Sie auch fest, welches Verhalten im Ablauf geprüft werden soll: zum Beispiel, ob ein Werkzeug passend gewählt wurde und ob das endgültige Ergebnis zur ausgeführten Handlung passt.

Diese Beispiele sind Prüffragen, keine universell gültigen Schwellenwerte. Legen Sie für Ihre App fest, welche Abweichung tolerierbar ist und welche einen Fehler darstellt. Lassen Sie kritische Tool-Aufruf-Fälle von einer fachkundigen Person gegenprüfen, bevor Sie aus einem Evaluationsbericht eine Freigabe ableiten.

Wie führen Sie Foundation Models Evaluations zusammen mit Swift Testing aus? Prüfen Sie zunächst die offizielle Integrationsdokumentation und fügen Sie die Evaluation in den zu Ihrer App passenden Testablauf ein. Apple dokumentiert die Integration mit Swift Testing; die Beschreibung von EvaluationTrait ist dabei für die Einordnung der Evaluations im Testkontext relevant.

Gehen Sie kontrolliert vor:

1. Prüfen Sie die Xcode- und Systemanforderungen. Gleichen Sie die für Ihr Projekt benötigte Umgebung mit Apples Systemanforderungen für Xcode ab. Dass Xcode 27.1 veröffentlicht wurde, bestätigt die Veröffentlichungsnotiz vom 15.10.2026; es ersetzt nicht die Prüfung, ob Ihre konkrete Zielumgebung und Ihr Projekt unterstützt werden.
2. Trennen Sie deterministische Tests von Qualitätsprüfungen. Testen Sie feste Logik, Datenumwandlung und Fehlerbehandlung weiterhin mit normalen Assertions. Legen Sie Evaluationen dort an, wo die Qualität variierender Modellantworten beurteilt werden soll.
3. Erstellen Sie einen kleinen, bewusst ausgewählten Datensatz. Nehmen Sie typische Fälle, schwierige Eingaben und Fälle auf, in denen die Funktion Grenzen einhalten muss. Prüfen Sie jeden Fall auf fachliche Relevanz.
4. Definieren Sie Metrik und Evaluator. Schreiben Sie auf, welche Eigenschaft Sie messen und was als akzeptables Verhalten gilt. Vermeiden Sie Regeln, deren Bewertung nicht mit Ihren Produktanforderungen zusammenhängt.
5. Führen Sie die Tests im passenden Xcode-Testziel aus. Folgen Sie der aktuellen Apple-Dokumentation für die konkrete Einbindung. Verlassen Sie sich nicht auf eine angenommene Projektkonfiguration, wenn Sie sie nicht in Ihrem eigenen Projekt verifiziert haben.
6. Prüfen Sie Einzelproben und aggregierte Ergebnisse. Untersuchen Sie auffällige Fälle separat. Nutzen Sie Zusammenfassungen, um Veränderungen über den Datensatz zu erkennen, aber nicht als Ersatz für die Prüfung relevanter Einzelfälle.
7. Halten Sie Vergleichsbedingungen fest. Dokumentieren Sie Datensatz, Prompt- oder Konfigurationsstand, Testumgebung und Ergebnis, damit ein späterer Lauf nachvollziehbar bleibt.

Ein Evaluationsbericht beantwortet, wie die geprüften Beispiele nach Ihrer festgelegten Bewertungslogik ausgefallen sind. Ein Aggregat fasst diese Resultate zusammen. Eine gewöhnliche Assertion belegt dagegen eine konkrete deterministische Bedingung. Diese Nachweise ergänzen einander, sind aber nicht austauschbar.

Setzen Sie keinen allgemeinen Grenzwert für alle Apps fest. Ein Assistent für freie Formulierungen und eine Funktion, die eine strukturierte Handlung ausführt, haben unterschiedliche Risiken. Legen Sie den Freigabemaßstab aus Ihren Produktanforderungen fest und prüfen Sie besonders die Fälle, bei denen ein falsch positives Ergebnis spürbare Folgen hätte.

Eine Evaluation lässt sich nur sinnvoll vergleichen, wenn die Ausführung nachvollziehbar ist. Prüfen Sie deshalb vor einem lokalen oder entfernten Lauf, ob Xcode und das Zielsystem zusammenpassen, ob das Testziel in der vorgesehenen Umgebung ausgeführt werden kann und ob Eingaben sowie Resultate dokumentiert werden. Die Kompatibilität ist anhand der aktuellen Xcode-Systemanforderungen und der Anforderungen Ihres Projekts zu verifizieren.

Wann ist ein Remote Mac für die Evaluation sinnvoll? Wenn Ihr lokaler Mac die benötigte Xcode-Umgebung bereits zuverlässig bereitstellt und Sie nur gelegentlich testen, ist ein zusätzlicher Rechner möglicherweise unnötig. Eine entfernte macOS-Umgebung ist eher dann eine Option, wenn Sie Tests wiederholt ausführen, eine dauerhaft erreichbare Umgebung benötigen oder lokale Ressourcen und Arbeitsabläufe getrennt halten möchten.

Prüfen Sie vor einer Entscheidung praktisch, ob Ihr Projekt in der vorgesehenen Umgebung geöffnet und das Testziel gestartet werden kann. Vergleichen Sie außerdem die Zugriffsrechte, die Verwaltung von Projektdateien und die Nachvollziehbarkeit der Testergebnisse. Für datenschutzrelevante Projekte sollten Sie vorab klären, welche Testdaten übertragen oder gespeichert werden dürfen und wie Ihr Ablauf die Anforderungen der DSGVO erfüllt. Verlassen Sie sich nicht auf eine pauschale Zusicherung: Entscheidend sind Ihre Daten, Ihre Zugriffsregeln und Ihre konkrete Konfiguration.

Wenn Sie die Kosten einer zeitweiligen Umgebung gegen den Betrieb eines eigenen Rechners abwägen, können Sie die CALMVPS-Preisübersicht als Entscheidungsgrundlage prüfen. Technische Eignung sollten Sie davon getrennt bewerten. Ohne einen tatsächlich ausgeführten Test Ihres Projekts lässt sich keine Aussage versprechen, dass Ihre Evaluations auf einer bestimmten Remote-Konfiguration laufen oder ein bestimmtes Ergebnis liefern.

Nutzen Sie diese Checkliste, bevor Sie einen Evaluationslauf als Entscheidungsgrundlage heranziehen:

• [ ] Die Stichprobe enthält typische, schwierige und produktkritische Eingaben.
• [ ] Für jeden Fall ist erkennbar, welches gewünschte Verhalten geprüft wird.
• [ ] Metrik und Evaluator entsprechen einer konkreten Produktanforderung.
• [ ] Tool-Aufrufe werden nach Bedarf getrennt von der abschließenden Antwort bewertet.
• [ ] Prompt- oder Konfigurationsvarianten verwenden dieselben Vergleichsbedingungen.
• [ ] Einzelne auffällige Fälle lassen sich im Bericht wiederfinden und fachlich prüfen.
• [ ] Aggregierte Resultate werden nicht als Beweis für alle denkbaren Nutzereingaben behandelt.
• [ ] Xcode- und Systemkompatibilität sowie die Ausführbarkeit des Testziels wurden in der vorgesehenen Umgebung geprüft.
• [ ] Eingaben, Konfigurationen und Ergebnisse sind so dokumentiert, dass ein späterer Lauf nachvollziehbar bleibt.

Für einen ersten reproduzierbaren Durchlauf genügt es, eine überschaubare, geprüfte Stichprobe und eine klar begründete Bewertungsregel aufzusetzen. Erweitern Sie den Datensatz, wenn reale Nutzung neue Fehlerarten sichtbar macht. So wird der Evaluationslauf zu einem überprüfbaren Qualitätswerkzeug statt zu einer einmaligen Demo.

Aktualisiert am 16.10.2026; geprüft anhand der Apple-Dokumentation zu Evaluations, Foundation Models, Xcode-Systemanforderungen, der Xcode-Veröffentlichungsnotiz und der WWDC26-Einführung.

Wenn Sie Evaluations nur gelegentlich lokal ausführen, bleiben Sie zunächst bei Ihrer bestehenden macOS-Umgebung. Ein eigener Mac bietet direkten Zugriff auf lokale Ressourcen und vermeidet laufende Mietkosten, bindet aber Kapital, benötigt Pflege und ist bei getrennten oder wiederkehrenden Builds nicht automatisch die bequemste Wahl. Eine entfernte Umgebung kann diese Aufgaben auslagern, bringt jedoch zusätzliche Fragen zu Zugriff, Datenverwaltung und Projektkompatibilität mit. Wenn Ihr lokaler Rechner für wiederholte Xcode-Tests nicht ausreicht, prüfen Sie die konkrete Eignung eines Remote Mac anhand Ihres Projekts und Ihrer Anforderungen; die verfügbaren Optionen finden Sie bei CALMVPS.