Foundation Models — przypadki użycia: kiedy specjalizować, a kiedy wystarczy prompt

Model działający na urządzeniu w Foundation Models nie jest jednolitym tworem. Apple dostarcza domyślny SystemLanguageModel do ogólnego promptowania oraz jedną zarządzaną przez Apple specjalizację do tagowania treści.¹ Framework pozwala również deweloperom trenować i ładować własne adaptery.² Trzy tory, jedno drzewo decyzyjne i strona dokumentacji, która wymienia dokładnie dwie wartości UseCase.

Wcześniejszy wpis o protokole Tool opisywał, jak skłonić domyślny model do wykonania użytecznej pracy. Pytanie, na które odpowiada ten wpis, jest kolejnym w kolejności: kiedy domyślny model z promptowaniem i narzędziami wystarczy, a kiedy przypadek użycia .contentTagging od Apple zasługuje na swoje miejsce? Ścieżka z własnymi adapterami to oddzielny wpis; cykl życia zarządzany przez dewelopera ma zbyt dużą powierzchnię, by dzielić ją z rubryką decyzyjną.

TL;DR

• SystemLanguageModel.UseCase to struktura z dwiema właściwościami statycznymi: .general i .contentTagging.³ Żadne inne przypadki użycia nie są udokumentowane.
• .general jest wartością domyślną. Warto sięgać po nią w pierwszej kolejności. Promptowanie, instrukcje, generowanie sterowane (guided generation) i wywołania narzędzi działają na bazie .general; specjalizacja jest ostatnią dźwignią, po którą się sięga.
• .contentTagging jest stworzone do jednego zadania: identyfikowania tematów, działań, obiektów i emocji w tekście wejściowym oraz zwracania tagów składających się z jednego do kilku słów pisanych małymi literami.⁴ Przewodnik Apple sam wskazuje, kiedy zamiast tego należy użyć .general.
• Trzeci tor (własne adaptery, typ Adapter, uprawnienie, zestaw narzędzi) to miejsce, w którym mieszka złożoność operacyjna. Inny wpis.

Czym tak naprawdę jest SystemLanguageModel

SystemLanguageModel to final class w frameworku FoundationModels, dostępny w iOS 26.0+, iPadOS 26.0+, Mac Catalyst 26.0+, macOS 26.0+ oraz visionOS 26.0+.¹ Apple opisuje go jako „duży model językowy działający na urządzeniu, zdolny do realizacji zadań generowania tekstu”.

Dwa fakty kształtują sposób korzystania z niego. Po pierwsze, SystemLanguageModel.default zwraca bazową wersję modelu.¹ To punkt wejścia dla wszystkiego, co nie jest specjalizowane. Po drugie, Apple aktualizuje model w aktualizacjach systemu: w momencie pisania dokumentacja Apple wymienia dwie wersje modelu — jedną dla iOS, iPadOS, macOS i visionOS 26.0–26.3 oraz drugą dla 26.4.¹ Aplikacje nie przypinają konkretnej wersji; framework zwraca ten model, który aktualnie działa w systemie.

Dostępność jest sprawdzana w czasie wykonania. SystemLanguageModel.availability to enum Availability z następującymi przypadkami, udokumentowanymi w przykładowym kodzie Apple:¹

struct GenerativeView: View {
    private var model = SystemLanguageModel.default

    var body: some View {
        switch model.availability {
        case .available:
            // Show your intelligence UI.
        case .unavailable(.deviceNotEligible):
            // Show an alternative UI.
        case .unavailable(.appleIntelligenceNotEnabled):
            // Ask the person to turn on Apple Intelligence.
        case .unavailable(.modelNotReady):
            // The model isn't ready because it's downloading or because
            // of other system reasons.
        case .unavailable(let other):
            // The model is unavailable for an unknown reason.
        }
    }
}

isAvailable to wygodny getter, który zwraca true tylko wtedy, gdy system jest w pełni gotowy.¹ Należy zawsze sprawdzić go przed wywołaniem.

Pierwszy tor: promptowanie modelu ogólnego

Apple przedstawia domyślny model jako właściwe narzędzie dla szerokiego spektrum zadań. Ogólny przewodnik frameworku wymienia możliwości, z którymi — jak twierdzi Apple — model na urządzeniu radzi sobie dobrze:⁴

Apple jasno mówi również, do czego model na urządzeniu nie jest przeznaczony:⁴

Warto zauważyć, że „generowanie tagów z tekstu” pojawia się w tabeli czego model dobrze sobie radzi dla modelu ogólnego. To istotny kontekst dla decyzji o specjalizacji omawianej poniżej.

Domyślny tor ma do dyspozycji cały zestaw narzędzi: instrukcje, prompty, generowanie sterowane przez Generable, wywołania narzędzi przez protokół Tool, opcje generowania takie jak temperature. Większość aplikacji adoptujących Foundation Models pozostanie na tym torze i nigdy nie sięgnie po wskaźnik przypadku użycia.

Okno kontekstowe dla modelu systemowego wynosi 4096 tokenów.⁴ Apple zauważa, że token odpowiada trzem lub czterem znakom w językach takich jak angielski, hiszpański czy niemiecki, oraz jednemu tokenowi na znak w językach takich jak japoński, chiński czy koreański. Instrukcje, prompty i wyjścia — wszystko liczy się do limitu. Gdy sesja go przekroczy, framework rzuca LanguageModelSession.GenerationError.exceededContextWindowSize(_:).⁴

Drugi tor: .contentTagging

SystemLanguageModel.UseCase jest udokumentowane jako struct (nie enum) z dwiema właściwościami statycznymi:³

static let general: SystemLanguageModel.UseCase
static let contentTagging: SystemLanguageModel.UseCase

Żadne inne udokumentowane przypadki nie istnieją. Jeśli jakiś tekst wymienia trzeci przypadek użycia, ten tekst go zmyśla.

.contentTagging ma inny kształt niż .general. Przewodnik Apple opisuje model contentTagging jako taki, który „identyfikuje tematy, działania, obiekty i emocje w tekście wejściowym” i wytwarza tagi w postaci „od jednego do kilku słów pisanych małymi literami”.⁵ Model został zbudowany do oceniania danych wejściowych, a nie do prowadzenia rozmowy: „Nie jest to typowy model językowy odpowiadający na zapytanie osoby: zamiast tego ocenia i grupuje dostarczone dane wejściowe”.⁵

Ładowanie modelu z .contentTagging:

let model = SystemLanguageModel(useCase: .contentTagging)
let session = LanguageModelSession(
    model: model,
    instructions: """
        Provide the two tags that are most significant in the context of topics.
        """
)

Udokumentowany inicjalizator wygodny to init(useCase:guardrails:).¹ Przykładowy kod Apple wywołuje go bez argumentu guardrails, co sugeruje, że guardrails ma wartość domyślną w miejscu wywołania.

Model contentTagging integruje się z Generable, dzięki czemu można zdefiniować typ Swift opisujący kształt oczekiwanych tagów:

@Generable
struct ContentTaggingResult {
    @Guide(
        description: "Most important actions in the input text.",
        .maximumCount(2)
    )
    let actions: [String]

    @Guide(
        description: "Most important emotions in the input text.",
        .maximumCount(3)
    )
    let emotions: [String]

    @Guide(
        description: "Most important objects in the input text.",
        .maximumCount(5)
    )
    let objects: [String]

    @Guide(
        description: "Most important topics in the input text.",
        .maximumCount(2)
    )
    let topics: [String]
}

let response = try await session.respond(
    to: prompt,
    generating: ContentTaggingResult.self
)

Przewodnik Apple zawiera użyteczną uwagę behawioralną: „W przypadku bardzo krótkich zapytań wejściowych instrukcje tagowania tematów i emocji dają najlepsze wyniki. Listy działań lub obiektów będą zbyt szczegółowe i mogą powtarzać słowa z zapytania”.⁵ Model contentTagging „respektuje również format wyjściowy, jakiego oczekujesz, nawet przy braku instrukcji”, więc kształt Generable ma większe znaczenie niż rozbudowany prompt systemowy.

Drzewo decyzyjne (słowami samego Apple)

Najciekawszą częścią API przypadków użycia jest to, że dokumentacja Apple wprost mówi, kiedy nie specjalizować. Z przewodnika contentTagging:⁵

1. „Jeśli tagujesz treść, która nie jest działaniem, obiektem, emocją ani tematem, użyj zamiast tego general”.
2. „Użyj modelu general do generowania treści takich jak hashtagi do postów w mediach społecznościowych”.
3. „Jeśli adoptujesz API wywoływania narzędzi i chcesz generować tagi, użyj general i przekaż wyjście Tool do modelu content tagging”.
4. „Jeśli masz złożony zestaw ograniczeń tagowania, bardziej skomplikowany niż wsparcie maximum count w modelu tagującym, użyj zamiast tego general”.

Trzeba czytać te cztery razem. Model contentTagging jest wąsko zakreślony: tematy, działania, obiekty, emocje. Wszystko inne (generowanie hashtagów, potoki tagujące, które obejmują wywołania narzędzi, wyjście tagów z ograniczeniami bogatszymi niż maximumCount) należy do modelu ogólnego.

Pragmatyczna rubryka decyzyjna dla aplikacji, która sądzi, że potrzebuje tagowania:

Domyślnie .general. Obsługuje szeroki zakres zadań generowania opisanych w tabeli Apple, w tym „generowanie tagów z tekstu”. Większość aplikacji zatrzyma się w tym miejscu.

Po .contentTagging należy sięgać tylko wtedy, gdy wejście ma postać tekstową, wyjście to mały zbiór tagów składających się z jednego lub kilku słów, mieszczących się czysto w czterech kategoriach Apple (tematy/działania/obiekty/emocje), a ograniczenia mieszczą się w maximumCount. Przykład Apple jest wzorcowy: aplikacja społecznościowa, która chce tagów dla każdego posta, by zasilić panel tematów, klient pocztowy z autoetykietowaniem, sklep z treścią, który chce zagregowanych sygnałów trendów.

Własny adapter wchodzi w grę dopiero, gdy żaden z torów nie pasuje, a przypadek użycia jest na tyle wartościowy, by udźwignąć koszt operacyjny trenowania i dostarczania adaptera związanego z konkretną wersją modelu systemowego. Ścieżka własnych adapterów jest udokumentowana oddzielnie; złożoność cyklu życia (wersja zestawu narzędzi, cykl ponownego trenowania, dystrybucja) zasługuje na osobne potraktowanie.

Czego Apple nie opublikowało

Kilka rzeczy, o których będą krążyły spekulacje, a których nie ma w udokumentowanej powierzchni:

• Mechanizm, którego Apple używa do specjalizacji modelu pod .contentTagging. Przewodnik Apple dotyczący contentTagging opisuje framework jako dostarczający „zaadaptowanego, działającego na urządzeniu systemowego modelu językowego, który specjalizuje się w tagowaniu treści”.⁵ Apple nie publikuje mechanizmu specjalizacji, a czasownika „adapted” w tym zdaniu nie należy mylić z zarządzanym przez dewelopera typem SystemLanguageModel.Adapter, który jest oddzielnym torem.
• Inne wartości przypadków użycia. Struktura ma dwie właściwości statyczne według aktualnej dokumentacji; każdy trzeci przypadek musiałby pojawić się w przyszłej aktualizacji systemu.
• Gwarancję, że .general i .contentTagging zawsze będą współistnieć. Apple mówi: „Apple będzie okresowo aktualizować SystemLanguageModel w rutynowych aktualizacjach systemu, aby poprawić możliwości i wydajność modelu na urządzeniu”.¹ Powierzchnię tę należy traktować jako wersjonowaną.
• Konkretne liczby jakościowe dla .contentTagging w porównaniu do .general na benchmarkach tagowania. Apple ujmuje wybór jako dopasowanie do zadania, a nie ranking jakości.

Jeśli jakiś wpis (ten albo dowolny inny) formułuje ilościowe twierdzenie o mechanice adapterów, którego nie ma na developer.apple.com, takie twierdzenie domyślnie należy traktować jako błędne.

Co tak naprawdę dają oba tory

Drugi tor nie polega na tym, że „model staje się lepszy”. Polega na tym, że „model jest zbudowany do jednego zadania, a Apple udokumentowało, kiedy go wybrać”. To zmienia ekonomię:

1. Mniejsza powierzchnia inżynierii promptów dla zadań tagujących. Model contentTagging „respektuje format wyjściowy, jakiego oczekujesz, nawet przy braku instrukcji”.⁵ Zamiast wieloakapitowego promptu, jakiego potrzebowałby model ogólny, można oprzeć się na @Generable i maximumCount.
2. Ograniczony kształt semantyczny. Model znajduje podobieństwa między terminami wejściowymi i wytwarza semantycznie spójne tagi (przykład Apple: dla wejść „hi”, „hello”, „yo” jako tag tematu wyłania się „greet”).⁵ Dokładnie to jest potrzebne w analityce zagregowanej nad treściami generowanymi przez użytkowników.
3. Udokumentowana rubryka decyzyjna. Apple mówi, kiedy ich specjalizacja pasuje, a kiedy należy się wycofać. Ta rubryka jest najcenniejszą częścią API przypadków użycia: to opiniotwórcza odpowiedź na pytanie, które deweloperzy aplikacji w przeciwnym razie rozstrzygaliby od podstaw.

Koszt jest również jasny: .contentTagging jest związane z jednym kształtem zadania. Wszystko poza tym kształtem wraca do .general i żyje lub umiera dzięki projektowi promptu i Generable.

Wnioski

1. Dwa tory dziś, być może więcej później. .general i .contentTagging to jedyne dwie statyczne właściwości UseCase, które Apple udokumentowało. Nie należy pisać kodu zakładającego inne.
2. Domyślnie .general. Promptowanie + narzędzia + generowanie sterowane obsługują większość przypadków użycia, do których przeznaczony jest model na urządzeniu. Specjalizacja jest ostatnią dźwignią, nie pierwszą.
3. .contentTagging należy wybierać tylko wtedy, gdy pasuje udokumentowany przez Apple kształt. Tematy, działania, obiekty, emocje. Tagi z jednego do kilku słów pisanych małymi literami. Ograniczenia na poziomie maximumCount. Cokolwiek więcej — wycofanie się.
4. Należy przeczytać reguły „use general instead” Apple. To cztery konkretne zdania w przewodniku contentTagging.⁵ Każde z nich wyznacza realną granicę.
5. Ścieżka własnych adapterów to oddzielna decyzja. Inna powierzchnia, inny cykl życia, inny wpis.

Pełny klaster Apple Ecosystem: model na urządzeniu i protokół Tool LLM dla prymitywów frameworku; podział agentowych workflow LLM między aplikacjami a LLMami narzędziowymi dla deweloperów; App Intents kontra MCP dla pytania o routing przez wszystkie trzy. Hub znajduje się w Apple Ecosystem Series. Szerszy kontekst iOS z agentami AI omawia iOS Agent Development guide.

FAQ

Ile wartości SystemLanguageModel.UseCase istnieje?

Dwie właściwości statyczne według aktualnej dokumentacji: .general i .contentTagging.³ Jeśli w samouczku lub odpowiedzi wygenerowanej przez LLM pojawi się trzecia wartość, należy zweryfikować ją w developer.apple.com przed adopcją.

Kiedy używać .contentTagging zamiast po prostu promptować .general?

.contentTagging należy używać, gdy zadaniem jest identyfikowanie tematów, działań, obiektów lub emocji w tekście wejściowym i zwracanie krótkich tagów pisanych małymi literami. Przewodnik Apple wymienia cztery scenariusze, w których właściwą odpowiedzią jest .general: tagowanie nieprzystające do tych czterech kategorii, generowanie hashtagów, potoki tagujące prowadzone przez wywołania narzędzi i ograniczenia tagowania bogatsze niż maximumCount.⁵

Czy model contentTagging przyjmuje dowolne instrukcje, tak jak model ogólny?

Przyjmuje instrukcje, ale jego konstrukcja polega na ocenianiu wejścia, a nie odpowiadaniu na zapytania w stylu rozmowy z użytkownikiem. Przewodnik Apple zauważa, że model contentTagging „respektuje format wyjściowy, jakiego oczekujesz, nawet przy braku instrukcji”, więc kształt @Generable z adnotacjami @Guide niesie ograniczenie, a nie długi prompt.⁵

Jakie jest okno kontekstowe modelu na urządzeniu?

4096 tokenów dla modelu systemowego.⁴ Stosunek token-do-znaku to z grubsza trzy do czterech znaków na token w angielskim/hiszpańskim/niemieckim oraz jeden token na znak w japońskim/chińskim/koreańskim. Framework rzuca LanguageModelSession.GenerationError.exceededContextWindowSize(_:), gdy sesja przekroczy limit.

Dlaczego przykładowy kod Apple wywołuje SystemLanguageModel(useCase:) bez guardrails:?

Udokumentowany inicjalizator wygodny to init(useCase:guardrails:).¹ Przewodnik contentTagging Apple wywołuje go bez argumentu guardrails, co sugeruje, że guardrails ma wartość domyślną w miejscu wywołania. Forma dwuargumentowa jest udokumentowaną powierzchnią; forma jednoargumentowa to ta, którą pokazuje opublikowany przykładowy kod Apple.

Bibliografia