Evaluations: XCTest für Modellqualität (iOS 27)

Ein gewöhnlicher Unit-Test stellt sicher, dass add(2, 2) den Wert 4 zurückgibt, und schlägt der Build fehl, wird er rot. Eine KI-Funktion bricht diesen Vertrag schon in der ersten Zeile, denn derselbe Prompt kann bei jedem Durchlauf einen anderen Satz erzeugen, und „anders” ist nicht „falsch”. Sie können kein #expect(summary == "die erwartete Zusammenfassung") gegen ein Modell schreiben, weil es keine einzelne erwartete Zeichenkette gibt. Messen lässt sich hingegen, ob die Ausgabe gut genug ist, und zwar oft genug, gemessen an Kriterien, die Sie selbst festlegen. Apples neues Evaluations-Framework liefert Ihnen genau diese Mess-Infrastruktur, mit typsicheren Swift-APIs, die als Teil Ihres Entwicklungs-Workflows laufen¹. Es ist neu im 27er-Release und auf allen Apple-Plattformen verfügbar (iOS, iPadOS, macOS, visionOS und watchOS): ein Entwicklerwerkzeug, das Sie zur Testzeit ausführen, typischerweise auf Ihrem Mac, keine Laufzeitfunktion, die Sie in einer App ausliefern¹.

Die Struktur wird Ihnen vertraut vorkommen, wenn Sie schon einmal Tests geschrieben haben. Sie definieren einen Datensatz, erzeugen Modellantworten, wenden Metriken an und aggregieren Ergebnisse; danach lesen Sie ab, welcher Ansatz am besten abgeschnitten hat und wo einzelne Antworten zurückblieben¹. Das mentale Modell ist XCTest für Modellqualität: dieselbe Schleife (einen Fall vorbereiten, ausführen, etwas zusichern), nur mit einer anderen Zusicherung (eine bewertete Metrik statt Gleichheit).

In Session 298 formuliert Apple das Kernproblem so: Generative-KI-Funktionen brechen einen für das Softwaretesten grundlegenden Vertrag, weil dieselbe Eingabe unterschiedliche Ausgaben erzeugen kann, was Unit-Tests unzureichend macht²⁵.

TL;DR / Die wichtigsten Erkenntnisse

• Das Evaluations-Framework ist neu im 27er-Release auf allen Apple-Plattformen (iOS, iPadOS, macOS, visionOS, watchOS), eine Entwicklerwerkzeug-Schicht zum Messen intelligenzgestützter Funktionen, ausgeführt als Teil Ihres Test-Workflows (typischerweise auf einem Mac)¹.
• Evaluator ist ein closure-basierter Evaluator, den Sie inline schreiben; das Evaluation-Protokoll ist der Typ, den Sie implementieren, um ein zu testendes System gegen einen Datensatz laufen zu lassen und Evaluatoren anzuwenden²³.
• Metric trägt ein benanntes Ergebnis über Factory-Methoden (passing, failing, scoring, ignore), und ScoreDimension benennt eine bewertete Achse für einen Model-as-Judge-Evaluator⁴⁵.
• ModelSample ist ein universell einsetzbares Evaluations-Sample; SampleGenerator ist ein Actor, der Samples aus einem Sprachmodell als asynchronen Stream erzeugt; die Ergebnisse landen in einem DataFrame mit typisierten Spalten, darunter eine responseColumn⁶⁷⁸.
• ToolCallEvaluator überprüft agentische Tool-Aufrufe gegen eine TrajectoryExpectation, wobei der ArgumentMatcher festlegt, wie jedes Argument validiert wird⁹¹⁰¹¹.
• EvaluationTrait führt eine Evaluation innerhalb eines Tests aus und protokolliert das Ergebnis als Attachments, was die Brücke in einen Swift-Testing-Lauf darstellt¹².

Der Beitrag arbeitet die API-Oberfläche durch, erklärt, warum es jeden Baustein gibt, und bindet alles an die Foundation-Models-Tool-Aufrufe zurück, die das Framework bewertet. Wo ich einen Aufruf zeige, dessen exakte Signatur Apple noch nicht veröffentlicht hat, kennzeichne ich ihn als illustrativ und weise Sie an, ihn gegen die Dokumentation zu prüfen.

Das Evaluator-Modell

Die Kernfrage des Frameworks lautet „wie gut war diese Ausgabe”, und es beantwortet sie mit einem kleinen Vokabular: ein Evaluator entscheidet, eine Metrik protokolliert, eine Score-Dimension bewertet, und ein Ergebnis aggregiert.

Das Evaluation-Protokoll ist der Typ, den Sie implementieren, um eine Evaluation zu definieren, die Ihr zu testendes System gegen einen Datensatz laufen lässt und Evaluatoren anwendet, um die Leistung zu messen³. Die Deklaration ist minimal:

// 27.0 beta (all Apple platforms)
protocol Evaluation : Sendable

Das Protokoll ist Sendable, weil Evaluation nebenläufige Arbeit ist: viele Samples, parallel ausgeführt, genauso wie Swift Testing Testfälle standardmäßig parallel ausführt¹³. Sie implementieren das Protokoll, wenn Sie eine wiederverwendbare, benannte Evaluation möchten. Wenn es schnell gehen soll, greifen Sie stattdessen zu Evaluator, den Apple als closure-basierten Evaluator für den Inline-Einsatz ohne Definition eines eigenen Typs beschreibt²:

// 27.0 beta (all Apple platforms)
struct Evaluator<Input> where Input : SampleProtocol,
    Input.ExpectedValue : Decodable,
    Input.ExpectedValue : Encodable,
    Input.ExpectedValue : Sendable

Apples Erläuterung besagt, dass die Closure das Eingabe-Sample und die Antwort erhält, mit Zugriff sowohl auf .value als auch auf .transcript². Der .value ist die typisierte Ausgabe des Modells; das .transcript ist die Aufzeichnung, wie es dorthin gelangt ist. Ein Inline-Evaluator ist ein einzeiliger #expect-Block für Modellqualität: keine Unterklasse, nur das Urteil als Closure. Die folgende Aufrufform ist illustrativ; prüfen Sie den Initializer gegen Apples Dokumentation:

import Evaluations

// Illustrative call shape — confirm against Apple's docs.
let nonEmpty = Evaluator<ModelSample<String>> { input, response in
    response.value.isEmpty ? .failing("empty output") : .passing()
}

Was die Closure zurückgibt, ist eine Metric. Apple beschreibt Metric als benannte Metrik, die einen Ergebniswert trägt, und benennt die Factory-Methoden ausdrücklich: passing, failing, scoring und ignore geben jeweils eine neue Metric zurück, in der das Ergebnis gespeichert ist⁴:

// 27.0 beta (all Apple platforms)
struct Metric

Die vier Factories bilden die Arten von Urteilen ab, die eine KI-Funktion braucht. Eine Zusammenfassung enthält die geforderte Tatsache entweder oder nicht, also bekommt sie passing oder failing. Eine Tonalitätsbewertung reicht von 1 bis 5, also bekommt sie scoring. Ein Sample, das Sie aus der Aggregation heraushalten möchten (fehlerhafte Eingabe, ein bekanntermaßen schlechtes Fixture), bekommt ignore, was die Zeile im Datensatz belässt, ohne die Statistik zu verfälschen. Genau die Spanne von passing bis zum bewerteten scoring ist es, was das Framework verspricht: von einfachen Bestanden-oder-Durchgefallen-Prüfungen bis hin zu detaillierter Bewertung mit Model-as-Judge-Mustern¹.

Am bewerteten Ende dieser Spanne verdient sich ScoreDimension seinen Platz. Apple definiert es als benannte Bewertungsdimension für einen Model-Judge-Evaluator, wobei jede Dimension einen Namen (der als DataFrame-Spalte dient), eine optionale Beschreibung und eine Definition dessen festlegt, was jeder Score bedeutet⁵:

// 27.0 beta (all Apple platforms)
struct ScoreDimension

Eine einzelne Ausgabe kann auf der einen Achse gut und auf einer anderen schlecht sein. Eine entworfene E-Mail kann sachlich korrekt und tonal verfehlt sein. ScoreDimension lässt Sie diese Achsen getrennt bewerten (Korrektheit, Tonalität, Prägnanz), sodass die Aggregation Ihnen verrät, welche Dimension eingebrochen ist, und nicht nur, dass die Gesamtqualität gesunken ist. Der Dimensionsname wird zur Spalte, was bedeutet, dass die Scores in einer strukturierten Tabelle landen, die Sie sortieren und vergleichen können, statt einer Wand aus Prosa.

Diese Tabelle ist ein EvaluationResult. Apple beschreibt es als das Ergebnis einer durchgeführten Modell-Evaluation, eine Struktur, die die Zusammenfassung und die detaillierten Ergebnisse eines Evaluationslaufs enthält¹⁴:

// 27.0 beta (all Apple platforms)
struct EvaluationResult

Die zweistufige Form (Zusammenfassung plus Detail) ist es, was Evals umsetzbar macht. Die Zusammenfassung beantwortet „hat dieser Prompt besser abgeschnitten als der vorherige”. Das Detail beantwortet „welche Samples blieben zurück”, sodass Sie die schlechtesten Zeilen öffnen und lesen können, was das Modell produziert hat¹.

Samples und Generierung

Eine Evaluation braucht Fälle, gegen die sie läuft, und die Einheit eines Falls ist im Framework ein Sample. ModelSample ist das universell einsetzbare. Apple beschreibt es als universell einsetzbares Sprachmodell-Evaluations-Sample, das zeichenkettenbasierte Prompts und Anweisungen entgegennimmt⁶:

// 27.0 beta (all Apple platforms)
struct ModelSample<ExpectedValue> where ExpectedValue : Decodable,
    ExpectedValue : Encodable,
    ExpectedValue : Sendable

Der generische ExpectedValue ist die typisierte Erwartung: eine Zeichenkette für eine Freitext-Aufgabe, ein strukturierter Codable-Typ für eine mit bekannter Antwort. Die Constraints Codable plus Sendable decken sich mit Evaluators Input.ExpectedValue, denn die Erwartung muss in die Ergebnistabelle serialisiert werden und während eines parallelen Laufs Nebenläufigkeitsgrenzen überschreiten. Für multimodale Prompts merkt Apple an, dass Sie eine eigene Konformität erstellen oder einen Initializer mit einem vorgefertigten Prompt verwenden⁶.

Jedes Sample von Hand zu schreiben skaliert nicht, weshalb es SampleGenerator gibt, einen Actor, der Evaluations-Samples mithilfe eines Sprachmodells erzeugt⁷:

// 27.0 beta (all Apple platforms)
actor SampleGenerator<SampleType> where SampleType : ModelSampleProtocol

Es ist ein actor, weil er veränderlichen Generierungszustand besitzt (akzeptierte und abgelehnte Samples), den die asynchrone Iteration verändert, und die Actor-Isolation ist Swifts Schutzmechanismus gegen Data Races auf diesem Zustand. Apples Workflow: Sie erstellen einen Generator, konfigurieren seine Eigenschaften und rufen ihn dann auf, um neue Samples als asynchronen Stream zu erzeugen; nach der Iteration greifen Sie auf alle generierten Samples zu oder auf jene, die der Validator abgelehnt hat⁷. Der Ablehnungs-Topf ist das Detail, bei dem es sich zu verweilen lohnt. Ein Generator, der schlechte Samples stillschweigend verwirft, würde seine eigene Fehlerquote verbergen; das Offenlegen der Ablehnungen erlaubt Ihnen, den Datensatz so zu prüfen, wie Sie handgeschriebene Fixtures prüfen würden.

Sobald die Samples gelaufen sind, landen die Antworten in einem DataFrame mit typisierten Spaltenbeschreibungen, sodass Sie die Tabelle ohne stringbasierte Lookups lesen. Apple benennt die Antwortspalte exakt: responseColumn, ein typisierter Spaltenbeschreiber für die Modellantworten im detaillierten DataFrame⁸:

// 27.0 beta (all Apple platforms)
var responseColumn: ResultColumn<Self.Subject> { get }

Der generische ResultColumn<Value> ist es, was die Spalte typisiert macht: ein Beschreiber für eine DataFrame-Spalte, parametrisiert über den Wert, den sie enthält¹⁵. Neben responseColumn stellt das Framework eine inputColumn für die Eingabe-Samples und eine expectedColumn für die erwarteten Werte bereit, jeweils eine typisierte ResultColumn¹⁶¹⁷. Typisierte Spalten folgen demselben Instinkt wie Swift Testings Ausdrucks-Erfassung: Statt einen Wert aus einem untypisierten Beutel zu ziehen und zu hoffen, dass der Cast hält, lesen Sie ihn über einen Beschreiber, der seinen Typ kennt. Wenn Sie die Ergebnisse für Mittelwert, Median und Standardabweichung in den MetricsAggregator einspeisen, sind die Spalten der Weg, über den Sie die Daten adressieren, ohne bei den Schlüsseln zu raten¹⁸.

Tool- und Trajektorienprüfung

Die KI-Funktion, die am schwersten zu testen ist, ist die agentische, denn Korrektheit ist keine Zeichenkette, sondern eine Folge von Aktionen. Wenn eine Foundation-Models-Session OCRTool aufruft, dann BarcodeReaderTool, dann Ihren eigenen Katalog-Lookup, lautet die Frage nicht „stimmte der finale Satz überein”, sondern „ist das Modell den richtigen Weg gegangen”¹⁹. ToolCallEvaluator bewertet diesen Weg direkt. Apple beschreibt es als Evaluator, der agentische Tool-Aufrufe gegen eine erwartete Trajektorie überprüft⁹:

// 27.0 beta (all Apple platforms)
struct ToolCallEvaluator<Input> where Input : ModelSampleProtocol,
    Input.Expectation == TrajectoryExpectation

Die where-Klausel ist der tragende Teil: Die Erwartung der Eingabe muss eine TrajectoryExpectation sein. Apple beschreibt diesen Typ als das erwartete Muster von Tool-Aufrufen für eine Evaluation, festgelegt über drei Achsen¹⁰:

// 27.0 beta (all Apple platforms)
struct TrajectoryExpectation

Apple gibt an, dass ToolCallEvaluator geordnete Sequenzen, ungeordnete Erwartungen, Prüfungen auf unzulässige Tools und Gruppenschritte unterstützt und aus einem einzigen Evaluationsdurchlauf sowohl ein striktes als auch ein partielles Ergebnis erzeugt⁹. Jedes davon entspricht einem realen Agenten-Fehler. Geordnete Sequenzen ertappen ein Modell, das die richtigen Tools in der falschen Reihenfolge aufruft. Ungeordnete Erwartungen sagen „diese Aufrufe müssen stattfinden, Reihenfolge egal”. Prüfungen auf unzulässige Tools ertappen ein Modell, das nach einem Tool greift, das es nie anrühren sollte (der Sicherheitsfall: ein Agent, der ein destruktives Tool aufruft, obwohl er nur lesend hätte bleiben sollen). Gruppenschritte drücken „eines von diesen” aus, für Verzweigungen, bei denen mehr als ein Weg akzeptabel ist.

Das Paar aus strikt und partiell passt dazu, wie agentische Qualität tatsächlich nachlässt. Ein neuer Prompt bringt eine Funktion selten von perfekt zu kaputt; er bringt sie von „jedes Mal die richtige Trajektorie” zu „meistens die richtige Trajektorie, mit einem Aufruf in falscher Reihenfolge”. Ein nur striktes Ergebnis meldet das als glatten Fehlschlag und sagt Ihnen nichts darüber, wie nah das Modell gekommen ist. Das partielle Ergebnis quantifiziert die Beinahe-Treffer, und genau das ist das Signal, gegen das Sie justieren.

Die Korrektheit pro Aufruf liegt eine Ebene tiefer, in den Argumenten. Ein Modell kann das richtige Tool mit den falschen Werten aufrufen, und der ArgumentMatcher legt fest, wie jedes Argument validiert wird. Apple beschreibt es als die Werte, die festlegen, wie ein Tool-Aufruf-Argument zu validieren ist¹¹:

// 27.0 beta (all Apple platforms)
enum ArgumentMatcher

Apples Erläuterung listet die Validierungsregeln auf: exakte Werte verlangen, das Vorhandensein eines Schlüssels prüfen, Bereiche kontrollieren, Muster abgleichen oder ein Sprachmodell für semantisches Matching verwenden¹¹. Der Fall des semantischen Matchings ist derjenige, den eine schlichte Gleichheitszusicherung nicht ausdrücken kann. Ist ein Tool-Argument eine Freitext-Abfrage, können zwei verschiedene Zeichenketten gleichermaßen korrekt sein, und ein gewöhnliches == würde einen völlig guten Aufruf durchfallen lassen. Dieses Argument einem Model-as-Judge-Abgleich zu überlassen, ist dieselbe Notluke, die ScoreDimension auf Ausgabeebene bietet, nur auf Argumentebene angewandt. Die Schreibweisen der Fälle stammen aus Apples Enumeration; das Folgende ist illustrativ, prüfen Sie es also gegen die Dokumentation:

import Evaluations

// Illustrative — confirm shapes against Apple's docs.
let expectation = TrajectoryExpectation(/* ordered / unordered / disallowed steps */)
let evaluator = ToolCallEvaluator<ModelSample<String>>(/* expectation */)

Die agentische Schleife hier ist dieselbe, die der Beitrag zum Foundation-Models-Tool-Aufruf von der Laufzeitseite beschreibt. Dort steuert GenerationOptions.ToolCallingMode, wie aggressiv das On-Device-Modell nach Tools greift, und das Framework kann den Modus nach dem ersten Aufruf umstellen, um die Tool-Aktivität einer Anfrage zu begrenzen¹⁹. ToolCallEvaluator ist die Messseite genau dieses Verhaltens: Sie legen die Aufruf-Haltung zur Laufzeit fest und bewerten dann die Trajektorie zur Testzeit, um zu bestätigen, dass die Haltung den beabsichtigten Weg hervorgebracht hat. Der Laufzeit-Regler und der Test-Evaluator sind zwei Enden ein und derselben Funktion.

Wie sich das in einen Workflow einfügt

Evals sind kein gesondertes Ritual, das Sie vierteljährlich durchführen. Sie gehören neben Ihre Tests, in dieselbe Schleife, ausgeführt auf demselben Mac. Die Brücke des Frameworks in diese Schleife ist EvaluationTrait. Apple beschreibt es als Test-Trait, der eine Evaluation ausführt und das Ergebnis als Attachments protokolliert¹²:

// 27.0 beta (all Apple platforms)
struct EvaluationTrait

Das Wort „Trait” ist bewusst gewählt. Swift Testings gesamtes Konfigurationsmodell besteht aus Traits, die auf @Test- und @Suite-Deklarationen angewendet werden: .enabled(if:), .disabled(_:), .tags(...) und der Rest¹³. EvaluationTrait fügt eine Evaluation in dieses Vokabular ein, sodass ein Eval so läuft, wie ein Test läuft, unter demselben swift test-Aufruf, mit derselben Parallelität. Das Protokollieren des Ergebnisses als Attachments verwendet denselben Mechanismus, den Swift Testing bereits für eigene Attachments besitzt, sodass das detaillierte Ergebnis eines Evals im Testbericht und in den CI-Artefakten mitreist, die Sie einsammeln¹³. Das Framework stellt außerdem einen EvaluationContext bereit, damit Code innerhalb des Test-Scopes das Ergebnis lesen kann, nachdem die Evaluation abgeschlossen ist²⁰.

Dieser Trait beantwortet „wo leben Evals”. Sie leben in Ihrem Test-Target, neben Ihren Unit-Tests, gesteuert von denselben Traits. Eine .tags(.evals)-Annotation führt nach einer Prompt-Änderung nur die Modellqualitätsprüfungen aus, so wie .tags(.regression) einen Regressionslauf eingrenzt¹³. Schnelle, unit-artige Tests bleiben bei jeder Bearbeitung grün; die langsameren, modellgetriebenen Evals laufen auf den Prompts und Tool-Definitionen, die das Modell berühren.

Die Trennung von Eval und Test spiegelt die Trennung von Laufzeit und Werkzeug aus dem Beitrag zum agentischen Workflow wider, der die Grenze zwischen dem On-Device-Modell, das die App ausliefert, und dem Werkzeug-Modell, das der Entwickler zum Schreiben der App betreibt, zieht²¹. Evaluations steht auf der Build-Seite dieser Grenze: ein Entwicklerwerkzeug des 27er-Zyklus, ausgeführt während der Iteration, das misst, ob die Laufzeitfunktion, die Sie ausliefern, gut genug ist¹. Sie liefern das Evaluations-Framework ebenso wenig an Nutzer aus wie XCTest. Sie liefern das Vertrauen aus, das es erzeugt.

Das Framework bleibt zudem offen dafür, welches Modell Sie bewerten. Apple merkt an, dass es mit jedem Modell funktioniert, das Ihrem Code zur Verfügung steht, und die Datensatzseite wird über einen Loader gespeist, ein Protokoll für Typen, die einen Datensatz liefern, mit eingebauten konkreten Typen oder einer eigenen Konformität für Ihre eigenen Quellen¹²². Für die Model-as-Judge-Bewertung sendet ModelJudgeEvaluator die Abfrage, die Antwort und optionale Referenzdaten an ein Judge-Modell, das Scores für eine oder mehrere Dimensionen zurückgibt²³, wobei der Judge-Prompt über ModelJudgePrompt konfigurierbar ist, der Anweisungen, Antwortdarstellung und Referenzdaten-Einspeisung zu einem komponierbaren Wert bündelt²⁴. Verwenden Sie Claude über Ihren eigenen Code-Pfad als Judge, wenn das das Modell ist, dem Ihr Stack ohnehin vertraut; das Framework bindet Sie nicht an ein einziges.

FAQ

Was ist das Evaluations-Framework, und auf welcher Plattform läuft es?

Das Evaluations-Framework misst die Qualität der intelligenzgestützten Funktionen Ihrer App mithilfe typsicherer Swift-APIs, die sich in Ihren Entwicklungs-Workflow integrieren¹. Es ist neu im 27er-Release auf iOS, iPadOS, macOS, visionOS und watchOS: ein Entwicklerwerkzeug-Framework, das Sie zur Testzeit ausführen (typischerweise auf einem Mac), keine Laufzeitfunktion, die in einer App ausgeliefert wird¹. Sie definieren Datensätze, erzeugen Modellantworten, wenden Metriken an und aggregieren Ergebnisse; danach lesen Sie ab, welcher Ansatz am besten abgeschnitten hat und wo einzelne Antworten zurückblieben¹.

Warum kann ich für KI-Funktionen keine Gleichheitszusicherungen von XCTest oder Swift Testing verwenden?

Eine Gleichheitszusicherung braucht einen einzelnen erwarteten Wert, und ein nichtdeterministisches Modell hat keinen: derselbe Prompt kann bei jedem Durchlauf eine andere gültige Ausgabe erzeugen. Evaluations ersetzt Gleichheit durch bewertetes Urteil. Eine Metric protokolliert ein Ergebnis als passing, failing, scoring oder ignore, und eine ScoreDimension bewertet eine Ausgabe auf einer benannten Achse⁴⁵. Sie führen die Evals weiterhin innerhalb eines Tests aus, über EvaluationTrait, sodass sie im selben Target und in derselben swift test-Schleife leben wie Ihre übrigen Tests¹².

Wie bewertet das Framework agentisches Tool-Aufruf-Verhalten?

Über ToolCallEvaluator, der agentische Tool-Aufrufe gegen eine erwartete Trajektorie überprüft⁹. Sie beschreiben den Weg als TrajectoryExpectation über drei Achsen; der Evaluator unterstützt geordnete Sequenzen, ungeordnete Erwartungen, Prüfungen auf unzulässige Tools und Gruppenschritte und erzeugt aus einem Durchlauf sowohl strikte als auch partielle Ergebnisse⁹¹⁰. Die Validierung pro Argument verwendet ArgumentMatcher (exakte Werte, Vorhandensein eines Schlüssels, Bereiche, Muster oder modellbasiertes semantisches Matching)¹¹.

Was ist der Unterschied zwischen einem Evaluator und dem Evaluation-Protokoll?

Evaluator ist ein closure-basierter Evaluator für den Inline-Einsatz ohne Definition eines eigenen Typs; seine Closure erhält das Eingabe-Sample und die Antwort, mit Zugriff auf .value und .transcript². Das Evaluation-Protokoll ist der Typ, den Sie implementieren, um eine wiederverwendbare, benannte Evaluation zu definieren, die Ihr zu testendes System gegen einen Datensatz laufen lässt und Evaluatoren anwendet³. Greifen Sie zu Evaluator für eine schnelle Inline-Prüfung und zum Evaluation-Protokoll für eine strukturierte, wiederholbare.

Wo leben generierte Samples und Ergebnisse?

SampleGenerator ist ein Actor, der Samples aus einem Sprachmodell als asynchronen Stream erzeugt; nach der Iteration lesen Sie die akzeptierten Samples oder jene, die der Validator abgelehnt hat⁷. Die Ergebnisse landen in einem DataFrame mit typisierten ResultColumn-Beschreibern: responseColumn, inputColumn und expectedColumn^8161715. MetricsAggregator berechnet Mittelwert, Median und Standardabweichung über diese Daten¹⁸.

Das vollständige Apple-Ecosystem-Cluster: die Erklärung zum Foundation-Models-Framework; die Unterscheidung zwischen Laufzeit- und Werkzeug-LLM; die iOS-27-Tool-Aufruf-Steuerung, die dieses Framework bewertet; und Swift Testing vs. XCTest, in dessen Trait-Modell sich EvaluationTrait einklinkt. Der Hub befindet sich bei der Apple-Ecosystem-Serie. Für einen breiteren Kontext zu iOS mit KI-Agenten siehe den Leitfaden zur iOS-Agentenentwicklung.