Evaluations: XCTest dla jakości modeli (iOS 27)

Zwykły test jednostkowy stwierdza, że add(2, 2) zwraca 4, a jeśli tak nie jest, kompilacja świeci się na czerwono. Funkcja AI łamie ten kontrakt już w pierwszej linijce, ponieważ ten sam prompt może przy każdym uruchomieniu wytworzyć inne zdanie, a „inne” nie znaczy „błędne”. Wobec modelu nie da się napisać #expect(summary == "the expected summary"), bo nie istnieje jeden oczekiwany ciąg znaków. Zmierzyć można natomiast to, czy wynik jest wystarczająco dobry, wystarczająco często, względem kryteriów, które sami zdefiniujemy. Nowy framework Evaluations od Apple daje właśnie takie narzędzie pomiarowe, z bezpiecznymi typowo interfejsami API w języku Swift, które działają jako część procesu programistycznego¹. Jest nowością w wydaniu 27 i dostępny na wszystkich platformach Apple (iOS, iPadOS, macOS, visionOS oraz watchOS): to narzędzie deweloperskie uruchamiane na etapie testów, zazwyczaj na Macu, a nie funkcja działająca w czasie wykonania, dostarczana wewnątrz aplikacji¹.

Jeśli pisało się już testy, ta struktura wyda się znajoma. Definiuje się zbiór danych, generuje odpowiedzi modelu, stosuje metryki i agreguje wyniki, a następnie odczytuje, które podejście wypadło najlepiej i gdzie poszczególne odpowiedzi nie spełniły oczekiwań¹. Modelem mentalnym jest tu XCTest dla jakości modeli: ta sama pętla (przygotować przypadek, uruchomić go, coś stwierdzić), tylko inna asercja (oceniana metryka zamiast równości).

W sesji 298 Apple ujmuje główny problem tak: funkcje generatywnej AI łamią kontrakt fundamentalny dla testowania oprogramowania, ponieważ to samo wejście może wytworzyć różne wyjścia, co sprawia, że testy jednostkowe są niewystarczające²⁵.

TL;DR / Najważniejsze wnioski

• Framework Evaluations to nowość w wydaniu 27 na wszystkich platformach Apple (iOS, iPadOS, macOS, visionOS, watchOS) — warstwa narzędzi deweloperskich do mierzenia funkcji wykorzystujących inteligencję, uruchamiana jako część procesu testowania (zazwyczaj na Macu)¹.
• Evaluator to oparty na domknięciu ewaluator, który pisze się w linii; protokół Evaluation to typ, który implementuje się, aby uruchomić testowany system na zbiorze danych i zastosować ewaluatory²³.
• Metric przenosi nazwany wynik za pośrednictwem metod fabrycznych (passing, failing, scoring, ignore), a ScoreDimension nadaje nazwę ocenianej osi dla ewaluatora typu model-sędzia⁴⁵.
• ModelSample to próbka ewaluacyjna ogólnego przeznaczenia; SampleGenerator to aktor, który generuje próbki z modelu językowego w postaci strumienia asynchronicznego; wyniki trafiają do struktury DataFrame z typowanymi kolumnami, w tym responseColumn⁶⁷⁸.
• ToolCallEvaluator weryfikuje agentowe wywołania narzędzi względem TrajectoryExpectation, a ArgumentMatcher definiuje sposób walidacji każdego argumentu⁹¹⁰¹¹.
• EvaluationTrait uruchamia ewaluację wewnątrz testu i zapisuje wynik jako załączniki, co stanowi pomost do uruchomienia w Swift Testing¹².

Artykuł przechodzi przez powierzchnię API, wyjaśnia, dlaczego istnieje każdy z elementów, i wiąże to z pracą nad tool-callingiem w Foundation Models, którą framework ocenia. Tam, gdzie pokazuję wywołanie, którego dokładnej sygnatury Apple nie opublikowało, oznaczam je jako poglądowe i zachęcam do potwierdzenia w dokumentacji.

Model ewaluatora

Głównym pytaniem frameworka jest „jak dobre było to wyjście”, a odpowiada na nie niewielkim słownictwem: ewaluator rozstrzyga, metryka zapisuje, wymiar oceny ocenia, a wynik agreguje.

Protokół Evaluation to typ, który implementuje się, aby zdefiniować ewaluację uruchamiającą testowany system na zbiorze danych i stosującą ewaluatory do pomiaru wydajności³. Deklaracja jest minimalna:

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

Protokół jest Sendable, ponieważ ewaluacja to praca współbieżna: wiele próbek uruchamianych równolegle, tak samo jak Swift Testing domyślnie uruchamia przypadki testowe równolegle¹³. Protokół implementuje się wtedy, gdy potrzebna jest ewaluacja wielokrotnego użytku, opatrzona nazwą. Gdy potrzeba czegoś szybkiego, sięga się zamiast tego po Evaluator, który Apple opisuje jako oparty na domknięciu ewaluator do użytku w linii, bez definiowania własnego typu²:

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

Omówienie Apple precyzuje, że domknięcie otrzymuje próbkę wejściową oraz odpowiedź, z dostępem zarówno do .value, jak i do .transcript². .value to typowane wyjście modelu; .transcript to zapis tego, jak do niego doszło. Ewaluator w linii jest jak jednowierszowy blok #expect dla jakości modelu: bez podklasy, sam osąd zapisany jako domknięcie. Poniższa postać wywołania jest poglądowa; inicjalizator należy potwierdzić w dokumentacji Apple:

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()
}

To, co zwraca domknięcie, jest typu Metric. Apple opisuje Metric jako nazwaną metrykę, która przenosi wartość wyniku, i wprost wymienia metody fabryczne: passing, failing, scoring oraz ignore zwracają nowy Metric z wynikiem zapisanym wewnątrz⁴:

// 27.0 beta (all Apple platforms)
struct Metric

Cztery fabryki odpowiadają rodzajom osądu, których potrzebuje funkcja AI. Streszczacz albo zawiera wymagany fakt, albo nie, więc otrzymuje passing lub failing. Rubryka oceniająca ton biegnie od 1 do 5, więc otrzymuje scoring. Próbka, którą chce się wyłączyć z agregatu (zniekształcone wejście, znana wadliwa fikstura), otrzymuje ignore, co pozostawia wiersz w zbiorze danych, nie zanieczyszczając statystyk. Rozpiętość od passing po oceniane scoring to dokładnie to, co framework obiecuje: od prostych sprawdzeń typu zdał/nie zdał aż po szczegółowe ocenianie ze wzorcami typu model-sędzia¹.

Oceniany kraniec tej rozpiętości to miejsce, w którym ScoreDimension zdobywa swoją rację bytu. Apple definiuje go jako nazwany wymiar oceny dla ewaluatora typu model-sędzia, gdzie każdy wymiar definiuje nazwę (używaną jako kolumna DataFrame), opcjonalny opis oraz określenie, co oznacza każda ocena⁵:

// 27.0 beta (all Apple platforms)
struct ScoreDimension

Pojedyncze wyjście może być dobre na jednej osi, a złe na innej. Sporządzony e-mail może być poprawny faktograficznie, a błędny pod względem tonu. ScoreDimension pozwala oceniać te osie osobno (poprawność, ton, zwięzłość), tak by agregat mówił, który wymiar spadł, a nie tylko że spadła jakość ogólna. Nazwa wymiaru staje się kolumną, co oznacza, że oceny trafiają do uporządkowanej tabeli, którą można sortować i porównywać, a nie do ściany prozy.

Tą tabelą jest EvaluationResult. Apple opisuje go jako wyniki uruchomienia ewaluacji modelu, czyli strukturę zawierającą podsumowanie oraz szczegółowe wyniki przebiegu ewaluacji¹⁴:

// 27.0 beta (all Apple platforms)
struct EvaluationResult

To właśnie dwupoziomowa postać (podsumowanie plus szczegóły) sprawia, że ewaluacje nadają się do działania. Podsumowanie odpowiada na pytanie „czy ten prompt wypadł lepiej od poprzedniego”. Szczegóły odpowiadają na pytanie „które próbki nie spełniły oczekiwań”, abyś mógł otworzyć najgorsze wiersze i odczytać, co wytworzył model¹.

Próbki i generowanie

Ewaluacja potrzebuje przypadków, na których się uruchomi, a jednostką przypadku we frameworku jest próbka. ModelSample to ta ogólnego przeznaczenia. Apple opisuje ją jako próbkę ewaluacyjną modelu językowego ogólnego przeznaczenia, która przyjmuje prompty i instrukcje oparte na ciągach znaków⁶:

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

Generyczny ExpectedValue to typowane oczekiwanie: ciąg znaków dla zadania z tekstem swobodnym, ustrukturyzowany typ Codable dla zadania ze znaną odpowiedzią. Ograniczenia Codable oraz Sendable odpowiadają Input.ExpectedValue z Evaluator, ponieważ oczekiwanie musi zostać zserializowane do tabeli wyników i przekroczyć granice współbieżności podczas przebiegu równoległego. W przypadku promptów multimodalnych Apple zaznacza, że tworzy się własną zgodność lub korzysta z inicjalizatora z gotowym promptem⁶.

Ręczne pisanie każdej próbki nie skaluje się, dlatego istnieje SampleGenerator — aktor, który generuje próbki ewaluacyjne przy użyciu modelu językowego⁷:

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

Jest to actor, ponieważ posiada zmienny stan generowania (próbki przyjęte i odrzucone), który modyfikuje asynchroniczna iteracja, a izolacja aktora to zabezpieczenie Swifta przed wyścigami danych na tym stanie. Przebieg pracy według Apple: utworzyć generator, skonfigurować jego właściwości, a następnie wywołać go, aby wytworzył nowe próbki w postaci strumienia asynchronicznego; po iteracji uzyskuje się dostęp do wszystkich wygenerowanych próbek lub do tych, które walidator odrzucił⁷. Wart zatrzymania się jest właśnie zbiór odrzuconych. Generator, który po cichu odrzucałby wadliwe próbki, ukryłby własny współczynnik niepowodzeń; ujawnienie odrzutów pozwala audytować zbiór danych tak, jak audytuje się fikstury pisane ręcznie.

Po uruchomieniu próbek odpowiedzi trafiają do struktury DataFrame z typowanymi deskryptorami kolumn, więc tabelę odczytuje się bez wyszukiwań opartych na ciągach znaków. Apple nazywa kolumnę odpowiedzi dokładnie: responseColumn, czyli typowany deskryptor kolumny dla odpowiedzi modelu w szczegółowej strukturze DataFrame⁸:

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

To generyczny ResultColumn<Value> sprawia, że kolumna jest typowana: deskryptor kolumny DataFrame, sparametryzowany wartością, którą przechowuje¹⁵. Obok responseColumn framework udostępnia inputColumn dla próbek wejściowych oraz expectedColumn dla wartości oczekiwanych, każda jako typowany ResultColumn¹⁶¹⁷. Typowane kolumny to ten sam odruch co przechwytywanie wyrażeń w Swift Testing: zamiast wyciągać wartość z nietypowanego worka i liczyć, że rzutowanie się powiedzie, odczytuje się ją przez deskryptor, który zna swój typ. Gdy podaje się wyniki do MetricsAggregator w celu wyliczenia średniej, mediany i odchylenia standardowego, to właśnie kolumny są sposobem na adresowanie danych bez zgadywania kluczy¹⁸.

Sprawdzanie narzędzi i trajektorii

Najtrudniejszą do przetestowania funkcją AI jest funkcja agentowa, ponieważ poprawność nie jest ciągiem znaków, lecz sekwencją działań. Gdy sesja Foundation Models wywołuje OCRTool, następnie BarcodeReaderTool, a potem twoje własne wyszukiwanie w katalogu, pytanie nie brzmi „czy zdanie końcowe się zgadzało”, lecz „czy model obrał właściwą ścieżkę”¹⁹. ToolCallEvaluator ocenia tę ścieżkę bezpośrednio. Apple opisuje go jako ewaluator, który weryfikuje agentowe wywołania narzędzi względem oczekiwanej trajektorii⁹:

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

Klauzula where jest częścią nośną: oczekiwanie wejścia musi być typu TrajectoryExpectation. Apple opisuje ten typ jako oczekiwany wzorzec wywołań narzędzi dla ewaluacji, określany wzdłuż trzech osi¹⁰:

// 27.0 beta (all Apple platforms)
struct TrajectoryExpectation

Apple podaje, że ToolCallEvaluator obsługuje sekwencje uporządkowane, oczekiwania nieuporządkowane, sprawdzenia narzędzi zabronionych oraz kroki grupowe i z jednego przebiegu ewaluacji wytwarza zarówno wynik ścisły, jak i częściowy⁹. Każde z nich odpowiada rzeczywistej porażce agenta. Sekwencje uporządkowane wychwytują model, który wywołuje właściwe narzędzia w niewłaściwej kolejności. Oczekiwania nieuporządkowane mówią „te wywołania muszą nastąpić, niezależnie od kolejności”. Sprawdzenia narzędzi zabronionych wychwytują model, który sięga po narzędzie, którego nigdy nie powinien dotykać (przypadek bezpieczeństwa: agent wywołujący narzędzie destrukcyjne, gdy powinien pozostać tylko do odczytu). Kroki grupowe wyrażają „dowolne jedno z tych”, dla rozgałęzień, w których dopuszczalna jest więcej niż jedna ścieżka.

Para ścisły-plus-częściowy pasuje do tego, jak jakość agentowa faktycznie się degraduje. Nowy prompt rzadko przeprowadza funkcję od doskonałej do zepsutej; przeprowadza ją od „właściwej trajektorii za każdym razem” do „właściwej trajektorii przez większość czasu, z jednym wywołaniem poza kolejnością”. Wynik wyłącznie ścisły zgłasza to jako jednolitą porażkę i nie mówi nic o tym, jak blisko był model. Wynik częściowy kwantyfikuje te niemal-trafienia, czyli sygnał, względem którego się stroi.

Poprawność każdego wywołania mieści się o poziom niżej, w argumentach. Model może wywołać właściwe narzędzie z niewłaściwymi wartościami, a ArgumentMatcher definiuje sposób walidacji każdego argumentu. Apple opisuje go jako wartości, które definiują, jak walidować argument wywołania narzędzia¹¹:

// 27.0 beta (all Apple platforms)
enum ArgumentMatcher

Omówienie Apple wymienia reguły walidacji: wymagać dokładnych wartości, weryfikować obecność klucza, sprawdzać zakresy, dopasowywać wzorce lub użyć modelu językowego do dopasowania semantycznego¹¹. Przypadek dopasowania semantycznego to ten, którego zwykła asercja równości nie potrafi wyrazić. Jeśli argument narzędzia jest zapytaniem w tekście swobodnym, dwa różne ciągi znaków mogą być jednakowo poprawne, a zwykłe == odrzuciłoby całkowicie dobre wywołanie. Oddanie tego argumentu dopasowaniu typu model-sędzia to ta sama furtka, którą ScoreDimension zapewnia na poziomie wyjścia, zastosowana na poziomie argumentu. Pisownia przypadków pochodzi z wyliczenia Apple; poniższe jest poglądowe, więc należy potwierdzić je w dokumentacji:

import Evaluations

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

Pętla agentowa, o której tu mowa, to ta sama, którą artykuł o tool-callingu w Foundation Models opisuje od strony czasu wykonania. Tam GenerationOptions.ToolCallingMode rządzi tym, jak agresywnie model działający na urządzeniu sięga po narzędzia, a framework może przełączyć tryb po pierwszym wywołaniu, by ograniczyć aktywność narzędziową żądania¹⁹. ToolCallEvaluator to pomiarowa strona tego samego zachowania: ustawia się postawę wywoływania w czasie wykonania, a następnie ocenia trajektorię na etapie testów, by potwierdzić, że ta postawa wytworzyła zamierzoną ścieżkę. Pokrętło czasu wykonania i ewaluator etapu testów to dwa końce jednej funkcji.

Jak to wpasowuje się w proces pracy

Ewaluacje nie są osobnym rytuałem przeprowadzanym co kwartał. Ich miejsce jest obok testów, w tej samej pętli, uruchamiane na tym samym Macu. Pomostem frameworka do tej pętli jest EvaluationTrait. Apple opisuje go jako trait testowy, który uruchamia ewaluację i zapisuje wynik jako załączniki¹²:

// 27.0 beta (all Apple platforms)
struct EvaluationTrait

Słowo „trait” jest celowe. Cały model konfiguracji Swift Testing opiera się na traitach stosowanych do deklaracji @Test i @Suite: .enabled(if:), .disabled(_:), .tags(...) i pozostałych¹³. EvaluationTrait wpasowuje ewaluację w to słownictwo, więc ewaluacja działa tak, jak działa test, w ramach tego samego wywołania swift test, z tą samą równoległością. Zapisanie wyniku jako załączników ponownie wykorzystuje mechanizm, który Swift Testing ma już do załączników niestandardowych, dzięki czemu szczegółowy wynik ewaluacji wędruje wraz z raportem testów i artefaktami CI, które zbierasz¹³. Framework udostępnia też EvaluationContext, aby kod w zasięgu testu mógł odczytać wynik po zakończeniu ewaluacji²⁰.

Ten trait odpowiada na pytanie „gdzie żyją ewaluacje”. Żyją w twoim celu testowym, obok testów jednostkowych, bramkowane przez te same traity. Adnotacja .tags(.evals) uruchamia wyłącznie sprawdzenia jakości modelu po zmianie promptu, tak jak .tags(.regression) zawęża przebieg regresji¹³. Szybkie testy w stylu jednostkowym pozostają zielone przy każdej edycji; wolniejsze ewaluacje sterowane modelem uruchamiają się na promptach i definicjach narzędzi, które dotykają modelu.

Podział na ewaluacje i testy odzwierciedla podział na czas wykonania i narzędzia z artykułu o procesie agentowym, który kreśli granicę między modelem na urządzeniu, dostarczanym przez aplikację, a modelem narzędziowym, który deweloper uruchamia, by napisać aplikację²¹. Evaluations sytuuje się po stronie kompilacji tej granicy: narzędzie deweloperskie cyklu 27, uruchamiane podczas iteracji, które mierzy, czy dostarczana funkcja czasu wykonania jest wystarczająco dobra¹. Frameworka Evaluations nie dostarcza się użytkownikom, tak samo jak nie dostarcza się XCTest. Dostarcza się pewność, którą on wytwarza.

Framework pozostaje też otwarty co do tego, który model się ocenia. Apple zaznacza, że działa on z dowolnym modelem dostępnym dla twojego kodu, a strona zbioru danych zasilana jest przez Loader — protokół dla typów, które dostarczają zbiór danych, z wbudowanymi typami konkretnymi lub własną zgodnością dla twoich źródeł¹²². Przy ocenianiu typu model-sędzia ModelJudgeEvaluator wysyła zapytanie, odpowiedź oraz opcjonalne dane referencyjne do modelu sędziego, który zwraca oceny dla jednego lub wielu wymiarów²³, przy czym prompt sędziego konfiguruje się przez ModelJudgePrompt, który łączy instrukcje, sposób prezentacji odpowiedzi oraz wstrzykiwanie danych referencyjnych w jedną komponowalną wartość²⁴. Użyj Claude przez własną ścieżkę kodu jako sędziego, jeśli to model, któremu twój stos już ufa; framework nie przywiązuje cię do jednego.

FAQ

Czym jest framework Evaluations i na jakiej platformie działa?

Framework Evaluations mierzy jakość funkcji twojej aplikacji wykorzystujących inteligencję za pomocą bezpiecznych typowo interfejsów API w języku Swift, które integrują się z twoim procesem programistycznym¹. Jest nowością w wydaniu 27 na iOS, iPadOS, macOS, visionOS i watchOS: to framework narzędzi deweloperskich uruchamiany na etapie testów (zazwyczaj na Macu), a nie funkcja czasu wykonania dostarczana wewnątrz aplikacji¹. Definiuje się zbiory danych, generuje odpowiedzi modelu, stosuje metryki i agreguje wyniki, a następnie odczytuje, które podejście wypadło najlepiej i gdzie poszczególne odpowiedzi nie spełniły oczekiwań¹.

Dlaczego nie mogę użyć asercji równości z XCTest lub Swift Testing dla funkcji AI?

Asercja równości potrzebuje jednej oczekiwanej wartości, a niedeterministyczny model jej nie ma: ten sam prompt może przy każdym uruchomieniu wytworzyć inne poprawne wyjście. Evaluations zastępuje równość ocenianym osądem. Metric zapisuje wynik passing, failing, scoring lub ignore, a ScoreDimension ocenia wyjście na nazwanej osi⁴⁵. Ewaluacje wciąż uruchamia się wewnątrz testu, przez EvaluationTrait, więc żyją w tym samym celu i tej samej pętli swift test co pozostałe testy¹².

Jak framework ocenia agentowe zachowanie tool-callingu?

Za pośrednictwem ToolCallEvaluator, który weryfikuje agentowe wywołania narzędzi względem oczekiwanej trajektorii⁹. Ścieżkę opisuje się jako TrajectoryExpectation wzdłuż trzech osi; ewaluator obsługuje sekwencje uporządkowane, oczekiwania nieuporządkowane, sprawdzenia narzędzi zabronionych oraz kroki grupowe, wytwarzając z jednego przebiegu wyniki ścisłe i częściowe⁹¹⁰. Walidacja poszczególnych argumentów korzysta z ArgumentMatcher (dokładne wartości, obecność klucza, zakresy, wzorce lub dopasowanie semantyczne oparte na modelu)¹¹.

Jaka jest różnica między Evaluator a protokołem Evaluation?

Evaluator to oparty na domknięciu ewaluator do użytku w linii, bez definiowania własnego typu; jego domknięcie otrzymuje próbkę wejściową oraz odpowiedź, z dostępem do .value i .transcript². Protokół Evaluation to typ, który implementuje się, aby zdefiniować ewaluację wielokrotnego użytku, opatrzoną nazwą, uruchamiającą testowany system na zbiorze danych i stosującą ewaluatory³. Po Evaluator sięga się dla szybkiego sprawdzenia w linii, a po protokół Evaluation dla sprawdzenia ustrukturyzowanego i powtarzalnego.

Gdzie żyją wygenerowane próbki i wyniki?

SampleGenerator to aktor, który wytwarza próbki z modelu językowego w postaci strumienia asynchronicznego; po iteracji odczytuje się próbki przyjęte lub te, które walidator odrzucił⁷. Wyniki trafiają do struktury DataFrame z typowanymi deskryptorami ResultColumn: responseColumn, inputColumn oraz expectedColumn^8161715. MetricsAggregator wylicza dla tych danych średnią, medianę i odchylenie standardowe¹⁸.

Pełny klaster Apple Ecosystem: objaśnienie frameworka Foundation Models; rozróżnienie między LLM czasu wykonania a LLM narzędziowym; kontrola tool-callingu w iOS 27, którą ten framework ocenia; oraz Swift Testing kontra XCTest, do którego modelu traitów wpina się EvaluationTrait. Centrum znajduje się w serii Apple Ecosystem. Szerszy kontekst iOS z agentami AI znajdziesz w przewodniku iOS Agent Development.