Cas d'usage des Foundation Models : quand spécialiser et quand simplement utiliser un prompt

Le modèle on-device de Foundation Models n’est pas une chose unique. Apple livre un SystemLanguageModel par défaut pour le prompting général et une spécialisation gérée par Apple pour le content tagging.¹ Le framework permet également aux développeurs d’entraîner et de charger leurs propres adaptateurs.² Trois rails, un arbre de décision, et une page de documentation qui nomme exactement deux valeurs UseCase.

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

TL;DR

• SystemLanguageModel.UseCase est une struct avec deux propriétés statiques : .general et .contentTagging.³ Aucun autre cas d’usage n’est documenté.
• .general est la valeur par défaut. Tournez-vous vers elle en premier. Le prompting, les instructions, la generation guidée et les appels d’outils s’appuient tous sur .general ; la spécialisation est le dernier levier à actionner.
• .contentTagging est conçu spécifiquement pour une tâche : identifier des sujets, actions, objets et émotions dans un texte d’entrée et retourner des tags en minuscules d’un à quelques mots.⁴ Le guide d’Apple lui-même vous indique quand utiliser .general à la place.
• Le troisième rail (adaptateurs personnalisés, le type Adapter, l’entitlement, le toolkit) est l’endroit où réside la complexité opérationnelle. Article différent.

Ce qu’est réellement SystemLanguageModel

SystemLanguageModel est une final class du framework FoundationModels, disponible sur iOS 26.0+, iPadOS 26.0+, Mac Catalyst 26.0+, macOS 26.0+ et visionOS 26.0+.¹ Apple le décrit comme « un grand modèle de langage on-device capable de tâches de génération de texte ».

Deux faits façonnent son utilisation. Premièrement, SystemLanguageModel.default retourne la version de base du modèle.¹ C’est le point d’entrée pour tout ce qui n’est pas spécialisé. Deuxièmement, Apple met à jour le modèle dans les mises à jour de l’OS : à l’heure où ces lignes sont écrites, la documentation d’Apple liste deux versions du modèle, l’une pour iOS, iPadOS, macOS et visionOS 26.0–26.3 et une autre pour 26.4.¹ Les applications n’épinglent pas une version spécifique ; le framework retourne le modèle que l’OS exécute actuellement.

La disponibilité est vérifiée à l’exécution. SystemLanguageModel.availability est une énumération Availability avec les cas suivants tels que documentés dans l’exemple de code d’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 est un getter de commodité qui retourne true uniquement lorsque le système est entièrement prêt.¹ Vérifiez toujours avant d’appeler.

Le premier rail : utiliser le modèle général via prompt

Apple présente le modèle par défaut comme le bon outil pour un large éventail de tâches. Le guide général du framework énumère les capacités qu’Apple affirme que le modèle on-device gère bien :⁴

Apple est également explicite sur ce pour quoi le modèle on-device n’est pas conçu :⁴

Notez que « générer des tags à partir de texte » figure dans le tableau des points forts du modèle général. C’est un contexte important pour la décision de spécialisation ci-dessous.

Le rail par défaut dispose de la boîte à outils complète : instructions, prompts, génération guidée via Generable, appels d’outils via le protocole Tool, options de génération comme la température. La plupart des applications qui adoptent Foundation Models vivront sur ce rail et ne toucheront jamais à un spécificateur de cas d’usage.

La fenêtre de contexte est de 4 096 tokens pour le modèle système.⁴ Apple note 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, prompts et 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 enum) 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 nomme un troisième cas d’usage, l’article l’invente.

.contentTagging a une forme différente de .general. Le guide d’Apple décrit le modèle contentTagging comme un modèle qui « identifie des sujets, actions, objets et émotions dans un texte d’entrée » et produit des tags sous forme « d’un à quelques mots en minuscules ».⁵ Le modèle est conçu pour évaluer une entrée plutôt que pour répondre de manière conversationnelle : « Ce n’est pas un modèle de langage typique qui répond à une 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 d’Apple l’appelle sans l’argument guardrails, ce qui suggère que guardrails porte une valeur par défaut sur le site d’appel.

Le modèle contentTagging s’intègre avec Generable, vous pouvez donc 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
)

Le guide d’Apple inclut une note comportementale utile : « Pour des requêtes d’entrée très courtes, les instructions de tagging de sujets et d’émotions donnent les meilleurs résultats. Les listes d’actions ou d’objets seront trop spécifiques et peuvent 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 », donc la forme Generable pèse plus qu’un prompt système verbeux.

L’arbre de décision (selon Apple)

La partie intéressante du API de cas d’usage est que la documentation d’Apple est explicite sur quand ne pas spécialiser. D’après le guide contentTagging :⁵

1. « Si vous taguez du contenu qui n’est ni une action, ni un objet, ni une émotion, ni un sujet, utilisez general à la place. »
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 API d’appel d’outils et souhaitez générer des tags, utilisez general et passez la sortie de Tool au modèle de content tagging. »
4. « Si vous avez un ensemble complexe de contraintes sur le tagging plus compliquées que le support de maximum count du modèle de tagging, utilisez general à la place. »

Lisez ces quatre points ensemble. Le modèle contentTagging a une portée étroite : sujets, actions, objets, émotions. Tout le reste (génération de hashtags, pipelines de tags impliquant des appels d’outils, sortie de tags avec des contraintes plus riches que maximumCount) appartient au modèle general.

La grille de décision pragmatique pour une application qui pense vouloir du tagging :

Par défaut, optez pour .general. Il gère le large éventail de tâches de génération que décrit le tableau d’Apple, y compris « générer des tags à partir de texte ». La plupart des applications s’arrêtent là.

Tournez-vous vers .contentTagging uniquement lorsque l’entrée a la forme d’un texte, la sortie est un petit ensemble de tags d’un seul ou de quelques mots tombant proprement dans les quatre catégories d’Apple (sujets/actions/objets/émotions), et les contraintes correspondent à maximumCount. L’exemple donné par Apple est le pattern : une application sociale qui veut des tags par publication pour alimenter un tableau de bord de sujets, un client e-mail qui veut un étiquetage automatique, une boutique de contenu qui veut des signaux de tendances agrégés.

Reportez-vous à un adaptateur personnalisé uniquement lorsque ni l’un ni l’autre rail ne convient et que le cas d’usage est suffisamment précieux pour absorber le coût opérationnel de l’entraînement et de la livraison d’un adaptateur lié à une version spécifique du modèle système. Le chemin de l’adaptateur personnalisé est documenté séparément ; la complexité du cycle de vie (version du toolkit, cycle de réentraînement, distribution) mérite son propre traitement.

Ce qu’Apple n’a pas publié

Quelques éléments que vous verrez spéculer mais qui ne figurent pas dans la surface documentée :

• Le mécanisme qu’Apple utilise pour spécialiser le modèle pour .contentTagging. Le guide contentTagging d’Apple décrit le framework comme fournissant « un modèle de langage système on-device adapté qui se spécialise dans le content tagging ».⁵ Apple ne publie pas le mécanisme de spécialisation, et le verbe « adapté » dans cette phrase ne doit pas être confondu avec le type SystemLanguageModel.Adapter géré par le développeur, qui est un rail distinct.
• D’autres valeurs de cas d’usage. La struct comporte deux propriétés statiques selon la documentation actuelle ; tout troisième cas devrait être livré dans une future mise à jour de l’OS.
• Une garantie que .general et .contentTagging coexisteront toujours. Apple dit : « Apple mettra périodiquement à jour SystemLanguageModel dans les mises à jour de routine de l’OS pour améliorer les capacités et les performances du modèle on-device. »¹ Traitez la surface comme versionnée.
• Des chiffres de qualité spécifiques pour .contentTagging versus .general sur des benchmarks de tagging. Apple présente le choix comme une adéquation à la tâche, pas comme un classement de qualité.

Si un article (celui-ci ou n’importe quel autre) avance une affirmation quantitative sur la mécanique des adaptateurs qui ne figure pas sur developer.apple.com, considérez par défaut que cette affirmation est fausse.

Ce que les deux rails vous apportent réellement

Le deuxième rail n’est pas « le modèle devient meilleur ». C’est « le modèle est conçu pour une tâche et Apple a documenté quand le choisir ». Cela change l’économie :

1. Surface réduite d’ingénierie de prompts pour les tâches de tagging. Le modèle contentTagging « respecte le format de sortie souhaité, même en l’absence d’instructions ».⁵ Vous pouvez vous appuyer sur @Generable et maximumCount plutôt que sur un prompt de plusieurs paragraphes que le modèle general nécessiterait.
2. Forme sémantique contrainte. Le modèle trouve des similarités entre les termes d’entrée et produit des tags sémantiquement cohérents (exemple d’Apple : « greet » émerge comme tag de sujet pour « hi », « hello », « yo »).⁵ C’est exactement ce dont une analytique agrégée sur du contenu généré par les utilisateurs a besoin.
3. Une grille de décision documentée. Apple vous indique quand leur spécialisation convient et quand revenir en arrière. Cette grille est la partie la plus précieuse du API de cas d’usage : c’est une réponse opinionée à une question que les développeurs d’applications litigieraient autrement à partir des premiers principes.

Le coût est aussi clair : .contentTagging est lié à une seule forme de tâche. Tout ce qui sort de cette forme retourne à .general et vit ou meurt selon la conception du prompt et de Generable.

À retenir

1. Deux rails aujourd’hui, peut-être davantage plus tard. .general et .contentTagging sont les deux seules propriétés statiques UseCase qu’Apple a documentées. N’écrivez pas de code qui en suppose d’autres.
2. Par défaut, optez pour .general. Prompting + outils + génération guidée gère 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 en minuscules d’un à quelques mots. Contraintes au niveau de maximumCount. Au-delà, repliez-vous.
4. Lisez les règles « utilisez general à la place » d’Apple. Ce sont quatre phrases concrètes dans le guide contentTagging.⁵ Chacune est une véritable frontière.
5. Le chemin de l’adaptateur personnalisé est une décision distincte. Surface différente, cycle de vie différent, article différent.

Le cluster complet de l’écosystème Apple : le LLM on-device et protocole Tool pour les primitives du framework ; la séparation du workflow agentique entre LLMs in-app et de tooling développeur ; App Intents vs MCP pour la question de routage entre les trois. Le hub se trouve sur la Apple Ecosystem Series. Pour un contexte plus large iOS-avec-agents-IA, consultez le guide iOS Agent Development.

FAQ

Combien y a-t-il de valeurs SystemLanguageModel.UseCase ?

Deux propriétés statiques selon la documentation actuelle : .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 au lieu de simplement utiliser .general via prompt ?

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

Le modèle contentTagging accepte-t-il des instructions arbitraires comme le modèle général ?

Il accepte des instructions, mais la conception du modèle est d’évaluer une entrée plutôt que de répondre à des requêtes de style utilisateur. Le guide d’Apple note que le modèle contentTagging « respecte le format de sortie souhaité, même en l’absence d’instructions », donc une forme @Generable avec des annotations @Guide porte la contrainte, pas 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 d’Apple appelle-t-il SystemLanguageModel(useCase:) sans guardrails: ?

L’initialiseur de commodité documenté est init(useCase:guardrails:).¹ Le guide contentTagging d’Apple l’appelle sans l’argument guardrails, ce qui suggère que guardrails porte une valeur par défaut sur le site d’appel. La forme à deux arguments est la surface documentée ; la forme à un argument est ce que montre l’exemple de code publié par Apple.

Références