Foundation Models 使用案例：通用模型與內容標記

Apple 的 SystemLanguageModel 文件從基礎模型談起，接著介紹使用案例，最後才是介面卡。SystemLanguageModel.default 是基礎模型；SystemLanguageModel.UseCase 記載了 general 與 contentTagging；自訂介面卡屬於開發者訓練路徑，另以專文說明。¹²³

先前關於 Tool 協定的文章，介紹了如何讓預設模型完成有用的工作。本文要回答的是下一個問題：何時透過提示與工具讓預設模型即可勝任，又何時 Apple 的 .contentTagging 使用案例值得一席之地？自訂介面卡的路徑另有專文討論；開發者管理的生命週期表面積太大，無法與決策準則共用同一篇文章。

TL;DR

• SystemLanguageModel.UseCase 是一個結構，含有兩個靜態屬性：.general 與 .contentTagging。³文件中並未記載其他使用案例。
• .general 是預設選擇。請優先採用。提示、指令、引導式生成與工具呼叫全都建構於 .general 之上；專業化是最後才該動用的槓桿。
• .contentTagging 屬於 Apple 的內容標記指南範疇：辨識輸入文字中的主題、動作、物件與情緒；當 Apple 明定的範疇不適用時,則回退至 .general。⁵
• 第三條軌道（自訂介面卡、Adapter 型別、權限、工具組）才是運作複雜度所在。另闢專文說明。

SystemLanguageModel 究竟是什麼

Apple 將 SystemLanguageModel 描述為用於文字生成任務的裝置端語言模型，而 default 是基礎模型。可用性屬於執行階段狀態：在應用程式顯示模型支援的 UI 之前，裝置資格、Apple Intelligence 設定及模型就緒狀態都必須納入考量。¹

Apple 文件列出了模型支援的平台（iOS、iPadOS、Mac Catalyst、macOS、visionOS，皆為 26.0 以上版本），以及目前的兩個模型版本：一個對應 OS 26.0–26.3 版本,另一個對應 26.4 版。Apple 會在例行的 OS 更新中持續更新裝置端模型。¹

可用性需於執行階段檢查。SystemLanguageModel.availability 是一個 Availability 列舉,其各種情況如 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 是便利取值器,只有當系統完全就緒時才會回傳 true。¹呼叫前請務必檢查。

第一條軌道：提示通用模型

Apple 的通用指南指出,裝置端模型可支援以下任務的文字生成與理解,其中包括「從文字生成標籤」。⁴

Apple 的避免清單則另列：基本數學、程式碼產生及邏輯推理。⁴

請注意,「從文字生成標籤」出現在通用模型的擅長表格中。這對於下文的專業化決策而言,是相當重要的脈絡。

通用軌道是 Apple 記載提示、指令、引導式生成、工具呼叫與生成選項的所在。⁴

系統模型的脈絡視窗為 4,096 個 token。⁴ Apple 指出,在英文、西班牙文或德文等語言中,一個 token 約對應三到四個字元;而日文、中文或韓文等語言則為每字元一個 token。指令、提示與輸出全都計入此上限。當工作階段超過上限時,框架會擲出 LanguageModelSession.GenerationError.exceededContextWindowSize(_:)。⁴

第二條軌道：.contentTagging

SystemLanguageModel.UseCase 在文件中載明為一個 struct（並非列舉）,含有兩個靜態屬性：³

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

文件中並未記載其他案例。若有文章提及第三種使用案例,該文章便是憑空捏造。

.contentTagging 與 .general 的形貌截然不同。Apple 指南將 contentTagging 模型描述為「辨識輸入文字中的主題、動作、物件與情緒」的模型,並產生「一至數個小寫單字」形式的標籤。⁵這個模型的設計目的是評估輸入,而非進行對話式回應：「它並非典型的語言模型,不會回應使用者的查詢,而是評估並歸類您所提供的輸入。」⁵

以 .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.
        """
)

文件中所載的便利初始化器為 init(useCase:guardrails:)。¹ Apple 的範例程式碼在呼叫時並未傳入 guardrails 引數,這暗示 guardrails 在呼叫端帶有預設值。

contentTagging 模型可整合 Generable,因此您可以定義一個 Swift 型別來描述所需的標籤形貌：

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

Apple 的行為註記：「對於極短的輸入查詢,主題與情緒標記指令能提供最佳結果。動作或物件清單會過於具體,而且可能重複查詢中的字詞。」⁵ contentTagging 模型也「即便沒有指令,也會遵循您所要求的輸出格式」,因此 Generable 形貌所承載的份量比冗長的系統提示更重。

決策樹（Apple 自己的話）

Apple 直接給出了決策規則。對於不屬於動作、物件、情緒或主題的標籤;主題標籤;工具呼叫的標記流程;以及超出 maximumCount 範圍的限制條件,皆應使用 .general。⁵

以下是 Apple contentTagging 指南中的四句原文：⁵

1. 「如果您要標記的內容不屬於動作、物件、情緒或主題,請改用 general。」
2. 「請使用通用模型來生成內容,例如社群媒體貼文的主題標籤（hashtag）。」
3. 「如果您採用工具呼叫 API 並想要產生標籤,請使用 general,並將 Tool 的輸出傳給內容標記模型。」
4. 「如果您對標記有複雜的限制條件,且超出標記模型的最大數量支援範圍,請改用 general。」

唯有當任務是將文字標記至 Apple 文件所載的四個類別,且輸出限制條件符合 maximumCount 時,才選擇 .contentTagging。若 .general 與 .contentTagging 皆不適用,自訂介面卡的決策請留待介面卡生命週期專文討論。⁵

Apple 尚未發布的內容

Apple 將 .contentTagging 記載為一個經過調適的內容標記模型,但並未公開其調適機制、基準差距或其他 UseCase 靜態屬性。在 developer.apple.com 正式發布之前,請將 general 與 contentTagging 之外的任何內容都視為未經驗證。³⁵

Apple 對版本控管的官方說法：「Apple 將在例行的 OS 更新中定期更新 SystemLanguageModel,以改善裝置端模型的能力與效能。」¹請將此介面視為帶有版本概念。

重點整理

1. 兩個有文件記載的使用案例。 Apple 的 UseCase 頁面載明 general 與 contentTagging;切勿假設存在第三個值。³
2. 預設使用 .general。 提示加上工具加上引導式生成,即可處理裝置端模型所設計支援的多數使用案例。專業化是最後的槓桿,而非首選。
3. 唯有當 Apple 文件記載的形貌符合時才選擇 .contentTagging。 主題、動作、物件、情緒。一至數字的小寫標籤。maximumCount 等級的限制條件。超出此範圍時,即應回退。
4. 請閱讀 Apple 的「請改用 general」規則。 它們是 contentTagging 指南中的四個具體句子。⁵每一句都是真實存在的邊界。
5. 自訂介面卡路徑屬於另一項決策。 表面積不同、生命週期不同、文章也不同。

完整的 Apple 生態系叢集：裝置端 LLM 與 Tool 協定介紹框架原語;代理工作流程的劃分區別應用程式內與開發者工具型 LLM；App Intents vs MCP涵蓋三者的路由問題。樞紐位於 Apple 生態系列。如需更廣泛的 iOS 結合 AI 代理脈絡,請參閱 iOS Agent Development guide。

常見問題

SystemLanguageModel.UseCase 共有多少個值？

依目前文件,共有兩個靜態屬性：.general 與 .contentTagging。³若您在教學文章或由 LLM 生成的回答中看到第三個值,在採用前請務必對照 developer.apple.com 加以驗證。

何時該選擇 .contentTagging,而非僅以提示驅動 .general？

當任務是辨識輸入文字中的主題、動作、物件或情緒,並回傳簡短的小寫標籤時,請使用 .contentTagging。Apple 指南列出了四種應改用 .general 的情境：不屬於這四種類別的標記、主題標籤生成、透過工具呼叫進行路由的標籤管線,以及比 maximumCount 更豐富的標記限制條件。⁵

contentTagging 模型像通用模型那樣接受任意指令嗎？

它確實接受指令,但該模型的設計目的是評估輸入,而非回應使用者風格的查詢。Apple 指南指出,contentTagging 模型「即便沒有指令,也會遵循您所要求的輸出格式」,因此承載限制的是帶有 @Guide 註解的 @Generable 形貌,而非冗長的提示。⁵

裝置端模型的脈絡視窗有多大？

系統模型為 4,096 個 token。⁴ token 對字元的比例,在英文/西班牙文/德文中約為每 token 三至四個字元,而在日文/中文/韓文中則為每字元一個 token。⁴當工作階段超過上限時,框架會擲出 LanguageModelSession.GenerationError.exceededContextWindowSize(_:)。⁴

為什麼 Apple 的範例程式碼呼叫 SystemLanguageModel(useCase:) 卻不帶 guardrails:？

Apple 文件記載了 init(useCase:guardrails:),並發布了呼叫 SystemLanguageModel(useCase: .contentTagging) 的內容標記範例程式碼。我並未透過編譯 iOS 26 SDK 來驗證 guardrails 參數的預設值。¹⁵

參考資料