Cas d'usage des Foundation Models : general vs content tagging

La documentation Apple sur SystemLanguageModel commence par le modèle de base, puis les cas d’usage, puis les adaptateurs. SystemLanguageModel.default est le modèle de base ; SystemLanguageModel.UseCase documente general et contentTagging ; les adaptateurs personnalisés constituent la voie entraînée par le développeur, traitée séparément.¹²³

L’article précédent sur le protocole Tool expliquait comment faire effectuer un travail utile au modèle par défaut. La question à laquelle ce billet répond est la suivante : quand le modèle par défaut, avec prompting et tools, suffit-il, et quand le cas d’usage .contentTagging d’Apple mérite-t-il sa place ? La voie de l’adaptateur personnalisé fait l’objet d’un article distinct ; le cycle de vie géré par le développeur a une surface d’API trop importante pour être partagée avec ce barème de décision.

TL;DR

• SystemLanguageModel.UseCase est une struct comportant deux propriétés statiques : .general et .contentTagging.³ Aucun autre cas d’usage n’est documenté.
• .general est le choix par défaut. Tournez-vous vers lui en premier. Le prompting, les instructions, la guided generation et l’appel d’outils reposent tous sur .general ; la spécialisation est le dernier levier à actionner.
• .contentTagging relève du guide Apple sur le content tagging : identifier les sujets, les actions, les objets et les émotions dans un texte d’entrée, puis retomber sur .general lorsque les frontières énoncées par Apple ne correspondent pas.⁵
• Le troisième rail (adaptateurs personnalisés, type Adapter, entitlement, toolkit) concentre toute la complexité opérationnelle. Article distinct.

Ce qu’est réellement SystemLanguageModel

Apple décrit SystemLanguageModel comme le modèle de langage on-device pour les tâches de génération de texte, avec default comme modèle de base. La disponibilité est un état d’exécution : l’éligibilité de l’appareil, les paramètres Apple Intelligence et la disponibilité du modèle comptent tous avant qu’une application n’affiche une UI adossée au modèle.¹

La documentation Apple liste les plateformes de modèle (iOS, iPadOS, Mac Catalyst, macOS, visionOS, tous en 26.0+) et deux versions de modèle actuelles : une pour les versions 26.0–26.3 et une autre pour 26.4. Apple met à jour le modèle on-device dans le cadre des mises à jour OS habituelles.¹

La disponibilité est vérifiée à l’exécution. SystemLanguageModel.availability est une énumération Availability dont les cas, tels que documentés dans l’exemple de code Apple, sont les suivants :¹

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 est un getter de commodité qui ne renvoie true que lorsque le système est entièrement prêt.¹ Vérifiez toujours avant d’appeler.

Le premier rail : prompter le modèle general

Le guide général d’Apple indique que le modèle on-device prend en charge la génération et la compréhension de texte pour les tâches ci-dessous, y compris Generate tags from text.⁴

La liste des usages à éviter, distincte, comprend : les calculs élémentaires, la création de code et le raisonnement logique.⁴

Notez que « generate tags from text » figure dans le tableau des bonnes capacités du modèle general. C’est un élément de contexte important pour la décision de spécialisation ci-dessous.

Le rail general est celui où Apple documente les prompts, les instructions, la guided generation, l’appel d’outils et les options de génération.⁴

La fenêtre de contexte est de 4 096 tokens pour le modèle système.⁴ Apple précise qu’un token correspond à trois ou quatre caractères dans des langues comme l’anglais, l’espagnol ou l’allemand, et à un token par caractère dans des langues comme le japonais, le chinois ou le coréen. Les instructions, les prompts et les sorties comptent tous dans la limite. Lorsqu’une session la dépasse, le framework lève LanguageModelSession.GenerationError.exceededContextWindowSize(_:).⁴

Le deuxième rail : .contentTagging

SystemLanguageModel.UseCase est documenté comme une struct (et non une énumération) avec deux propriétés statiques :³

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

Aucun autre cas n’est documenté. Si un article cite un troisième cas d’usage, l’article l’invente.

.contentTagging a une forme différente de .general. Le guide Apple décrit le modèle contentTagging comme un modèle qui « identifie les sujets, les actions, les objets et les émotions dans un texte d’entrée » et qui produit des tags sous forme de « un à quelques mots en minuscules ».⁵ Le modèle est conçu pour évaluer une entrée plutôt que répondre de façon conversationnelle : « Ce n’est pas un modèle de langage classique qui répond à la requête d’une personne : il évalue et regroupe l’entrée que vous fournissez. »⁵

Charger le modèle avec .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.
        """
)

L’initialiseur de commodité documenté est init(useCase:guardrails:).¹ L’exemple de code Apple l’appelle sans l’argument guardrails, ce qui suggère que guardrails porte une valeur par défaut au site d’appel.

Le modèle contentTagging s’intègre à Generable, ce qui vous permet de définir un type Swift qui capture la forme des tags souhaités :

@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
)

Note comportementale d’Apple : « Pour des requêtes d’entrée très courtes, les instructions de tagging par sujet et émotion donnent les meilleurs résultats. Les listes d’actions ou d’objets seront trop spécifiques, et risquent de répéter les mots de la requête. »⁵ Le modèle contentTagging « respecte également le format de sortie souhaité, même en l’absence d’instructions », si bien que la forme Generable pèse davantage qu’un prompt système verbeux.

L’arbre de décision (selon Apple)

Apple donne directement la règle de décision. Utilisez .general pour les tags hors actions, objets, émotions ou sujets ; pour les hashtags ; pour les flux de tagging qui passent par des tool calls ; et pour les contraintes qui dépassent maximumCount.⁵

Les quatre phrases exactes du guide contentTagging d’Apple :⁵

1. « Si vous taguez du contenu qui n’est pas une action, un objet, une émotion ou un sujet, utilisez plutôt general. »
2. « Utilisez le modèle general pour générer du contenu comme des hashtags pour des publications sur les réseaux sociaux. »
3. « Si vous adoptez le tool calling API et que vous voulez générer des tags, utilisez general et passez la sortie de Tool au modèle content tagging. »
4. « Si vous avez un ensemble complexe de contraintes de tagging plus élaborées que la prise en charge de maximum count du modèle de tagging, utilisez plutôt general. »

Choisissez .contentTagging uniquement lorsque la tâche est un tagging de texte dans les quatre catégories documentées par Apple et que les contraintes de sortie tiennent dans maximumCount. Si ni .general ni .contentTagging ne convient, laissez la décision sur l’adaptateur personnalisé à l’article sur le cycle de vie de l’adaptateur.⁵

Ce qu’Apple n’a pas publié

Apple documente .contentTagging comme un modèle de content tagging adapté, mais ne publie ni le mécanisme d’adaptation, ni les écarts de benchmark, ni de propriétés statiques UseCase supplémentaires. Considérez tout ce qui dépasse general et contentTagging comme non vérifié tant que developer.apple.com ne le documente pas.³⁵

Le cadrage d’Apple sur le versioning : « Apple mettra périodiquement à jour SystemLanguageModel dans le cadre des mises à jour OS habituelles afin d’améliorer les capacités et les performances du modèle on-device. »¹ Considérez la surface d’API comme versionnée.

À retenir

1. Deux cas d’usage documentés. La page UseCase d’Apple documente general et contentTagging ; ne supposez pas qu’il en existe une troisième.³
2. Par défaut, .general. Le prompting + les tools + la guided generation couvrent la plupart des cas d’usage pour lesquels le modèle on-device est conçu. La spécialisation est le dernier levier, pas le premier.
3. Choisissez .contentTagging uniquement lorsque la forme documentée par Apple convient. Sujets, actions, objets, émotions. Tags d’un à quelques mots en minuscules. Contraintes au niveau de maximumCount. Au-delà, repli.
4. Lisez les règles « utilisez plutôt general » d’Apple. Ce sont quatre phrases concrètes du guide contentTagging.⁵ Chacune est une frontière réelle.
5. La voie de l’adaptateur personnalisé est une décision distincte. Surface d’API différente, cycle de vie différent, article différent.

L’ensemble du cluster Apple Ecosystem : le LLM on-device et le protocole Tool pour les primitives du framework ; la séparation des workflows agentic entre LLMs in-app et de developer tooling ; App Intents vs MCP pour la question du routage entre les trois. Le hub se trouve sur la page Apple Ecosystem Series. Pour un contexte plus large sur iOS avec des agents IA, consultez le guide iOS Agent Development.

FAQ

Combien existe-t-il de valeurs SystemLanguageModel.UseCase ?

Deux propriétés statiques telles que documentées actuellement : .general et .contentTagging.³ Si vous voyez une troisième valeur référencée dans un tutoriel ou une réponse générée par un LLM, vérifiez-la sur developer.apple.com avant de l’adopter.

Quand devrais-je utiliser .contentTagging plutôt que de simplement prompter .general ?

Utilisez .contentTagging lorsque la tâche consiste à identifier des sujets, des actions, des objets ou des émotions dans un texte d’entrée et à renvoyer de courts tags en minuscules. Le guide Apple liste quatre scénarios où .general est plutôt la bonne réponse : un tagging qui ne rentre pas dans ces quatre catégories, la génération de hashtags, les pipelines de tagging qui passent par des tool calls, et des contraintes de tagging plus riches que maximumCount.⁵

Le modèle contentTagging accepte-t-il des instructions arbitraires comme le modèle general ?

Il accepte les instructions, mais le modèle est conçu pour évaluer une entrée plutôt que répondre à des requêtes de style utilisateur. Le guide Apple note que le modèle contentTagging « respecte le format de sortie souhaité, même en l’absence d’instructions », si bien qu’une forme @Generable avec annotations @Guide porte la contrainte, plutôt qu’un long prompt.⁵

Quelle est la fenêtre de contexte du modèle on-device ?

4 096 tokens pour le modèle système.⁴ Le ratio token-caractère est d’environ trois à quatre caractères par token en anglais/espagnol/allemand et d’un token par caractère en japonais/chinois/coréen.⁴ Le framework lève LanguageModelSession.GenerationError.exceededContextWindowSize(_:) lorsque la session dépasse la limite.⁴

Pourquoi l’exemple de code Apple appelle-t-il SystemLanguageModel(useCase:) sans guardrails: ?

Apple documente init(useCase:guardrails:) et publie un exemple de code de content tagging qui appelle SystemLanguageModel(useCase: .contentTagging). Je n’ai pas vérifié le paramètre guardrails par défaut en compilant contre le SDK d’iOS 26.¹⁵

Références