Casos de uso de Foundation Models: cuándo especializar y cuándo solo usar prompts

El modelo en el dispositivo de Foundation Models no es una sola cosa. Apple incluye un SystemLanguageModel predeterminado para prompts generales y una especialización gestionada por Apple para etiquetado de contenido.¹ El framework también permite a los desarrolladores entrenar y cargar sus propios adaptadores.² Tres vías, un árbol de decisiones y una página de documentación que nombra exactamente dos valores de UseCase.

La publicación anterior sobre el protocolo Tool cubrió cómo hacer que el modelo predeterminado realice trabajo útil. La pregunta que responde esta publicación es la siguiente: ¿cuándo basta con el modelo predeterminado más prompting y herramientas, y cuándo se gana su lugar el caso de uso .contentTagging de Apple? La vía de adaptadores personalizados es una publicación aparte; el ciclo de vida gestionado por el desarrollador tiene demasiada superficie como para compartirla con la rúbrica de decisión.

TL;DR

• SystemLanguageModel.UseCase es un struct con dos propiedades estáticas: .general y .contentTagging.³ No hay otros casos de uso documentados.
• .general es el predeterminado. Recurre a él primero. Prompting, instrucciones, generación guiada y llamadas a herramientas viven todos sobre .general; la especialización es la última palanca que tirar.
• .contentTagging está hecho a medida para una tarea: identificar temas, acciones, objetos y emociones en el texto de entrada y devolver etiquetas en minúsculas de una a unas pocas palabras.⁴ La propia guía de Apple te dice cuándo usar .general en su lugar.
• La tercera vía (adaptadores personalizados, el tipo Adapter, el entitlement, el toolkit) es donde reside la complejidad operativa. Otra publicación.

Qué es realmente SystemLanguageModel

SystemLanguageModel es una final class en el framework FoundationModels, disponible en iOS 26.0+, iPadOS 26.0+, Mac Catalyst 26.0+, macOS 26.0+ y visionOS 26.0+.¹ Apple lo describe como “un modelo de lenguaje grande en el dispositivo capaz de realizar tareas de generación de texto.”

Dos hechos determinan cómo usarlo. Primero, SystemLanguageModel.default devuelve la versión base del modelo.¹ Ese es el punto de entrada para todo lo no especializado. Segundo, Apple actualiza el modelo en las actualizaciones del SO: al momento de escribir esto, la documentación de Apple lista dos versiones del modelo, una para iOS, iPadOS, macOS y visionOS 26.0–26.3 y otra para 26.4.¹ Las apps no fijan una versión específica; el framework devuelve el modelo que el SO esté ejecutando en ese momento.

La disponibilidad se verifica en tiempo de ejecución. SystemLanguageModel.availability es un enum Availability con los siguientes casos según se documentan en el código de ejemplo de 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 es un getter de conveniencia que devuelve true solo cuando el sistema está completamente listo.¹ Verifica siempre antes de llamar.

La primera vía: aplicar prompts al modelo general

Apple plantea el modelo predeterminado como la herramienta adecuada para una amplia variedad de tareas. La guía general del framework enumera capacidades que Apple dice que el modelo en el dispositivo maneja bien:⁴

Apple también es explícito sobre para qué no sirve el modelo en el dispositivo:⁴

Observa que “generar etiquetas a partir de texto” aparece en la tabla de cosas en las que es bueno para el modelo general. Ese es un contexto importante para la decisión de especialización que veremos a continuación.

La vía predeterminada tiene disponible el conjunto completo de herramientas: instrucciones, prompts, generación guiada vía Generable, llamadas a herramientas vía el protocolo Tool, opciones de generación como temperature. La mayoría de las apps que adopten Foundation Models vivirán en esta vía y nunca tocarán un especificador de caso de uso.

La ventana de contexto es de 4.096 tokens para el modelo del sistema.⁴ Apple señala que un token corresponde a tres o cuatro caracteres en idiomas como inglés, español o alemán, y un token por carácter en idiomas como japonés, chino o coreano. Las instrucciones, los prompts y las salidas cuentan todos contra el límite. Cuando una sesión lo excede, el framework lanza LanguageModelSession.GenerationError.exceededContextWindowSize(_:).⁴

La segunda vía: .contentTagging

SystemLanguageModel.UseCase está documentado como un struct (no un enum) con dos propiedades estáticas:³

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

No hay otros casos documentados. Si un artículo nombra un tercer caso de uso, ese artículo se lo está inventando.

.contentTagging tiene una forma diferente a .general. La guía de Apple describe el modelo contentTagging como uno que “identifica temas, acciones, objetos y emociones en el texto de entrada” y produce etiquetas como “una a unas pocas palabras en minúscula.”⁵ El modelo está construido para evaluar entrada en lugar de responder de forma conversacional: “No es un modelo de lenguaje típico que responde a una consulta de una persona: en cambio, evalúa y agrupa la entrada que proporcionas.”⁵

Cargar el modelo con .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.
        """
)

El inicializador de conveniencia documentado es init(useCase:guardrails:).¹ El código de ejemplo de Apple lo llama sin el argumento guardrails, lo que sugiere que guardrails lleva un valor predeterminado en el sitio de la llamada.

El modelo contentTagging se integra con Generable, así que puedes definir un tipo Swift que capture la forma de las etiquetas que quieres:

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

La guía de Apple incluye una nota útil sobre el comportamiento: “Para consultas de entrada muy cortas, las instrucciones de etiquetado de temas y emociones proporcionan los mejores resultados. Las listas de acciones u objetos serán demasiado específicas y pueden repetir las palabras de la consulta.”⁵ El modelo contentTagging también “respeta el formato de salida que quieres, incluso en ausencia de instrucciones”, así que la forma Generable lleva más peso del que llevaría un prompt de sistema verboso.

El árbol de decisiones (en palabras de Apple)

La parte interesante de la API de casos de uso es que la documentación de Apple es explícita sobre cuándo no especializar. De la guía de contentTagging:⁵

1. “Si estás etiquetando contenido que no es una acción, objeto, emoción o tema, usa general en su lugar.”
2. “Usa el modelo general para generar contenido como hashtags para publicaciones en redes sociales.”
3. “Si adoptas la API de llamadas a herramientas y quieres generar etiquetas, usa general y pasa la salida de Tool al modelo de etiquetado de contenido.”
4. “Si tienes un conjunto complejo de restricciones sobre el etiquetado que son más complicadas que el soporte de cantidad máxima del modelo de etiquetado, usa general en su lugar.”

Léelas las cuatro juntas. El modelo contentTagging tiene un alcance estrecho: temas, acciones, objetos, emociones. Todo lo demás (generación de hashtags, pipelines de etiquetado que involucran llamadas a herramientas, salida de etiquetas con restricciones más ricas que maximumCount) pertenece al modelo general.

La rúbrica pragmática de decisión para una app que cree que quiere etiquetado:

Por defecto, usa .general. Maneja el amplio rango de tareas de generación que describe la tabla de Apple, incluyendo “generar etiquetas a partir de texto.” La mayoría de las apps se detiene aquí.

Recurre a .contentTagging solo cuando la entrada tiene forma de texto, la salida es un conjunto pequeño de etiquetas de una o pocas palabras que caen limpiamente en las cuatro categorías de Apple (temas/acciones/objetos/emociones), y las restricciones encajan en maximumCount. El ejemplo que da Apple es el patrón: una app social que quiere etiquetas por publicación para impulsar un panel de temas, un cliente de email que quiere autoetiquetado, una tienda de contenido que quiere señales agregadas de tendencias.

Recurre a un adaptador personalizado solo cuando ninguna de las dos vías encaja y el caso de uso tiene suficiente valor como para absorber el costo operativo de entrenar y enviar un adaptador atado a una versión específica del modelo del sistema. La vía de adaptadores personalizados está documentada por separado; la complejidad del ciclo de vida (versión del toolkit, ciclo de reentrenamiento, distribución) merece su propio tratamiento.

Lo que Apple no ha publicado

Algunas cosas que verás especuladas que no están en la superficie documentada:

• El mecanismo que Apple usa para especializar el modelo para .contentTagging. La guía de contentTagging de Apple describe el framework como uno que provee “un modelo de lenguaje del sistema en el dispositivo adaptado que se especializa en etiquetado de contenido.”⁵ Apple no publica el mecanismo de especialización, y el verbo “adaptado” en esa frase no debe confundirse con el tipo SystemLanguageModel.Adapter gestionado por el desarrollador, que es una vía aparte.
• Otros valores de caso de uso. El struct tiene dos propiedades estáticas según la documentación actual; cualquier tercer caso tendría que llegar en una futura actualización del SO.
• Una garantía de que .general y .contentTagging siempre coexistirán. Apple dice “Apple actualizará periódicamente SystemLanguageModel en actualizaciones rutinarias del SO para mejorar las habilidades y el rendimiento del modelo en el dispositivo.”¹ Trata la superficie como versionada.
• Cifras específicas de calidad para .contentTagging frente a .general en benchmarks de etiquetado. Apple plantea la elección como adecuación a la tarea, no como una tabla de calidad.

Si una publicación (esta o cualquier otra) hace una afirmación cuantitativa sobre la mecánica del adaptador que no esté en developer.apple.com, considera la afirmación incorrecta por defecto.

Lo que las dos vías realmente te dan

La segunda vía no es “el modelo se vuelve mejor.” Es “el modelo está construido para una tarea y Apple ha documentado cuándo elegirlo.” Eso cambia la economía:

1. Menor superficie de prompt-engineering para tareas de etiquetado. El modelo contentTagging “respeta el formato de salida que quieres, incluso en ausencia de instrucciones.”⁵ Puedes apoyarte en @Generable y maximumCount en lugar de un prompt de varios párrafos que necesitaría el modelo general.
2. Forma semántica restringida. El modelo encuentra similitud entre términos de entrada y produce etiquetas semánticamente consistentes (ejemplo de Apple: “greet” emerge como la etiqueta de tema para “hi”, “hello”, “yo”).⁵ Eso es exactamente lo que necesita el análisis agregado sobre contenido generado por usuarios.
3. Una rúbrica de decisión documentada. Apple te dice cuándo encaja su especialización y cuándo recurrir a la alternativa. Esa rúbrica es la parte más valiosa de la API de casos de uso: es una respuesta con criterio a una pregunta que los desarrolladores de apps de otro modo litigarían desde primeros principios.

El costo también es claro: .contentTagging está atado a una sola forma de tarea. Cualquier cosa fuera de esa forma vuelve a .general y vive o muere por el diseño del prompt y de Generable.

Conclusiones

1. Dos vías hoy, posiblemente más después. .general y .contentTagging son las únicas dos propiedades estáticas de UseCase que Apple ha documentado. No escribas código que asuma otras.
2. Por defecto, usa .general. Prompting + herramientas + generación guiada manejan la mayoría de los casos de uso para los que está diseñado el modelo en el dispositivo. La especialización es la última palanca, no la primera.
3. Elige .contentTagging solo cuando encaja la forma documentada por Apple. Temas, acciones, objetos, emociones. Etiquetas en minúsculas de una a unas pocas palabras. Restricciones a nivel de maximumCount. Cualquier cosa más, vuelve atrás.
4. Lee las reglas “usa general en su lugar” de Apple. Son cuatro frases concretas en la guía de contentTagging.⁵ Cada una es un límite real.
5. La vía de adaptadores personalizados es una decisión aparte. Superficie distinta, ciclo de vida distinto, publicación distinta.

El cluster completo del Ecosistema Apple: el LLM en el dispositivo y el protocolo Tool para los primitivos del framework; la división del flujo de trabajo agéntico entre LLMs en la app y de tooling para desarrolladores; App Intents vs MCP para la pregunta de enrutamiento entre las tres. El hub está en la Serie del Ecosistema Apple. Para un contexto más amplio sobre iOS con agentes de IA, consulta la guía de Desarrollo de Agentes en iOS.

Preguntas frecuentes

¿Cuántos valores de SystemLanguageModel.UseCase hay?

Dos propiedades estáticas según la documentación actual: .general y .contentTagging.³ Si ves un tercer valor referenciado en un tutorial o en una respuesta generada por LLM, verifícalo contra developer.apple.com antes de adoptarlo.

¿Cuándo debo usar .contentTagging en lugar de simplemente aplicar prompts a .general?

Usa .contentTagging cuando la tarea es identificar temas, acciones, objetos o emociones en el texto de entrada y devolver etiquetas cortas en minúsculas. La guía de Apple lista cuatro escenarios donde .general es la respuesta correcta en su lugar: etiquetado que no encaja en esas cuatro categorías, generación de hashtags, pipelines de etiquetado que pasan por llamadas a herramientas y restricciones de etiquetado más ricas que maximumCount.⁵

¿Acepta el modelo contentTagging instrucciones arbitrarias como lo hace el modelo general?

Acepta instrucciones, pero el diseño del modelo es evaluar entrada en lugar de responder a consultas estilo usuario. La guía de Apple señala que el modelo contentTagging “respeta el formato de salida que quieres, incluso en ausencia de instrucciones”, así que una forma @Generable con anotaciones @Guide lleva la restricción, no un prompt largo.⁵

¿Cuál es la ventana de contexto para el modelo en el dispositivo?

4.096 tokens para el modelo del sistema.⁴ La proporción token-a-carácter es aproximadamente de tres a cuatro caracteres por token en inglés/español/alemán y un token por carácter en japonés/chino/coreano. El framework lanza LanguageModelSession.GenerationError.exceededContextWindowSize(_:) cuando la sesión excede el límite.

¿Por qué el código de ejemplo de Apple llama a SystemLanguageModel(useCase:) sin guardrails:?

El inicializador de conveniencia documentado es init(useCase:guardrails:).¹ La guía de contentTagging de Apple lo llama sin el argumento guardrails, lo que sugiere que guardrails lleva un valor predeterminado en el sitio de la llamada. La forma de dos argumentos es la superficie documentada; la forma de un argumento es lo que muestra el código de ejemplo publicado por Apple.

Referencias