Foundation Models 使用案例：何時專用化、何時直接提示

Foundation Models 中的裝置端模型並非單一事物。Apple 為一般提示提供了預設的SystemLanguageModel,並提供一個由 Apple 管理的內容標記專用化版本。¹此框架還允許開發者訓練並載入自己的 adapter。²三條軌道、一棵決策樹,以及一份僅明確列出兩個UseCase值的文件頁面。

先前關於 Tool protocol 的文章涵蓋了如何讓預設模型發揮實用價值。本文要回答的是下一個問題:何時搭配提示與工具使用預設模型就已足夠?何時 Apple 的.contentTagging使用案例才值得佔據其位置?自訂 adapter 路徑屬於另一篇文章;由開發者管理的生命週期所涉及的範疇太廣,不適合與這份決策準則一起討論。

TL;DR

• SystemLanguageModel.UseCase是一個 struct,具有兩個靜態屬性:.general和.contentTagging。³沒有其他文件記載的使用案例。
• .general是預設值。請先選擇它。提示、指令、引導式生成以及工具呼叫都建立在.general之上;專用化是最後才動用的槓桿。
• .contentTagging是為單一工作而打造:在輸入文字中識別主題、動作、物件與情緒,並回傳一到數個小寫單字的標籤。⁴ Apple 自己的指南會告訴您何時改用.general。
• 第三條軌道(自訂 adapter、Adapter型別、entitlement、工具組)是操作複雜度的所在之處。改日另文討論。

SystemLanguageModel究竟是什麼

SystemLanguageModel是 FoundationModels 框架中的final class,可在 iOS 26.0+、iPadOS 26.0+、Mac Catalyst 26.0+、macOS 26.0+ 與 visionOS 26.0+ 上使用。¹ Apple 將其描述為「能執行文字生成任務的裝置端大型語言模型」。

有兩項事實會形塑使用方式。首先,SystemLanguageModel.default會回傳模型的基本版本。¹這是所有未經專用化用途的入口點。其次,Apple 會在 OS 更新中持續更新模型:截至撰寫本文時,Apple 的文件列出兩個模型版本,一個用於 iOS、iPadOS、macOS 與 visionOS 26.0–26.3,另一個則用於 26.4。¹ App 不會綁定特定版本;框架會回傳目前 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是一個便利的 getter,只有當系統完全就緒時才會回傳true。¹呼叫前務必先檢查。

第一條軌道:對 General 模型下提示

Apple 將預設模型定位為適用於廣泛任務的合適工具。框架的一般指南列舉了 Apple 表示裝置端模型擅長處理的能力:⁴

Apple 也明確指出裝置端模型不適合的用途:⁴

請注意「從文字產生標籤」出現在一般模型的「擅長」表格中。這對於下方的專用化決策來說是重要的脈絡。

預設軌道擁有完整的工具組:指令、提示、透過Generable進行引導式生成、透過Tool協定進行工具呼叫,以及 temperature 等生成選項。大多數採用 Foundation Models 的 App 都會落在這條軌道上,從不需碰觸使用案例指定符。

系統模型的上下文視窗為 4,096 個 token。⁴ Apple 指出,在英文、西班牙文或德文等語言中,一個 token 對應三到四個字元;而在日文、中文或韓文等語言中,則是每個字元一個 token。指令、提示與輸出皆會計入上限。當 session 超出限制時,框架會擲出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 自己的說法)

使用案例 API 中有趣的部分在於,Apple 的文件明確說明何時不要專用化。摘自 contentTagging 指南:⁵

1. 「如果您要標記的內容不是動作、物件、情緒或主題,請改用 general。」
2. 「請使用 general 模型來產生像是社群媒體貼文 hashtag 這類的內容。」
3. 「如果您採用工具呼叫 API,並想要產生標籤,請使用 general 並將 Tool 輸出傳遞至內容標記模型。」
4. 「如果您對標記有一組複雜的限制,且該限制比標記模型支援的最大數量更為複雜,請改用 general。」

請將這四點一起閱讀。contentTagging 模型範圍極窄:主題、動作、物件、情緒。其他一切(hashtag 產生、涉及工具呼叫的標記管線、限制比maximumCount更豐富的標籤輸出)都應交給一般模型處理。

對於認為自己需要標記功能的 App,務實的決策準則如下:

預設使用.general。它能處理 Apple 表格中描述的廣泛生成任務,包括「從文字產生標籤」。多數 App 到此就停下了。

只有在以下情況才動用.contentTagging:輸入是文字形態,輸出是一小組單字或數個單字的標籤,並能整齊地落入 Apple 的四大類別(主題/動作/物件/情緒),且限制可由maximumCount處理。Apple 給出的範例就是典型模式:一個希望透過每篇貼文標籤來驅動主題儀表板的社群 App、一個希望進行自動標籤的電子郵件用戶端,或一個希望取得彙總趨勢訊號的內容商店。

僅在兩條軌道都不適用,且使用案例足夠高價值,能夠吸納訓練與發布綁定特定系統模型版本之 adapter 的營運成本時,才退讓至自訂 adapter。自訂 adapter 路徑另有專門文件記載;其生命週期複雜度(工具組版本、再訓練週期、發布)值得專文探討。

Apple 尚未公開的內容

以下是您會看到有人臆測、但實際上不在文件記載範圍內的事項:

• Apple 用於將模型專用化為.contentTagging的機制。Apple 的 contentTagging 指南將框架描述為提供「一個經過調適、專門用於內容標記的裝置端系統語言模型」。⁵ Apple 並未公布專用化機制,而該句中的動詞「調適(adapted)」不應與由開發者管理的SystemLanguageModel.Adapter型別混淆,後者屬於另一條獨立軌道。
• 其他使用案例值。截至目前的文件,該 struct 具有兩個靜態屬性;任何第三個案例都需要在未來的 OS 更新中發布。
• .general與.contentTagging將永遠並存的保證。Apple 表示「Apple 將會在例行性的 OS 更新中定期更新 SystemLanguageModel,以提升裝置端模型的能力與效能」。¹請將此介面視為有版本之分。
• .contentTagging相較於.general在標記基準測試上的具體品質數字。Apple 將此選擇定位為「適合該任務」,而非品質排行榜。

如果某篇文章(無論是這篇或任何其他)針對 adapter 機制做出量化主張,而該主張並未出現在 developer.apple.com 上,請預設視為錯誤。

這兩條軌道實際上能換來什麼

第二條軌道並非「模型變得更好」,而是「模型專為一項工作打造,且 Apple 已記載了何時應選擇它」。這改變了相關的權衡:

1. 降低標記任務的提示工程介面。 contentTagging 模型「即使在沒有指令的情況下,也會遵循您所要求的輸出格式」。⁵您可以倚賴@Generable與maximumCount,而非一段一般模型才需要的多段落提示。
2. 受限的語意形態。該模型會在輸入詞語間找出相似性,並產生語意一致的標籤(Apple 的範例:「greet」會作為「hi」、「hello」、「yo」的主題標籤浮現)。⁵這正是針對使用者產生內容做彙總分析時所需要的特性。
3. 一份已記載的決策準則。 Apple 會告訴您他們的專用化何時適用、何時應退回。這份準則正是使用案例 API 最有價值的部分:這是針對一個 App 開發者原本得從第一原理逐項辯論的問題,所給出的明確意見。

成本也很清楚:.contentTagging綁定於單一任務形態。任何超出此形態的需求都會回到.general,並取決於提示與Generable的設計品質。

重點整理

1. 目前兩條軌道,未來可能更多。 .general與.contentTagging是 Apple 唯二記載的UseCase靜態屬性。請勿撰寫假設存在其他屬性的程式碼。
2. 預設使用.general。提示 + 工具 + 引導式生成可處理裝置端模型所設計用於的多數使用案例。專用化是最後一項槓桿,而非首選。
3. 僅在 Apple 記載的形態適用時才選擇.contentTagging。主題、動作、物件、情緒。一到數個小寫單字的標籤。maximumCount等級的限制。一旦超過這些範圍,就退回。
4. 請閱讀 Apple 的「請改用 general」規則。這是 contentTagging 指南中的四個具體句子。⁵每一條都是真實的邊界。
5. 自訂 adapter 路徑是另一個獨立決策。不同的介面範疇、不同的生命週期、不同的文章。

完整的 Apple Ecosystem 系列:裝置端 LLM 與 Tool protocol 介紹框架的基本元件;agentic 工作流程切分 探討 in-app 與開發者工具 LLM 之間的劃分;App Intents vs MCP 探討跨三者的路由問題。系列彙整頁面位於 Apple Ecosystem Series。如需更廣泛的 iOS 結合 AI 代理脈絡,請參閱 iOS Agent Development guide。

FAQ

究竟有多少個SystemLanguageModel.UseCase值?

依目前文件記載為兩個靜態屬性:.general與.contentTagging。³如果您在某篇教學或 LLM 產生的回答中看到提到第三個值,請先在 developer.apple.com 上加以驗證後再採用。

何時應使用.contentTagging,而非僅對.general下提示?

當任務是要在輸入文字中識別主題、動作、物件或情緒,並回傳簡短小寫標籤時,請使用.contentTagging。Apple 的指南列出四種應改用.general的情境:不符合那四個類別的標記、hashtag 產生、會經過工具呼叫路由的標籤管線,以及比maximumCount更豐富的標記限制。⁵

contentTagging 模型是否像一般模型那樣接受任意指令?

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

裝置端模型的上下文視窗有多大?

系統模型為 4,096 個 token。⁴在英文/西班牙文/德文中,token 對字元的比例大致為三到四個字元一個 token;在日文/中文/韓文中則是每個字元一個 token。當 session 超出限制時,框架會擲出LanguageModelSession.GenerationError.exceededContextWindowSize(_:)。

為什麼 Apple 的範例程式碼在呼叫SystemLanguageModel(useCase:)時不傳guardrails:?

文件記載的便利初始化器是init(useCase:guardrails:)。¹ Apple 的 contentTagging 指南在呼叫時並未傳入 guardrails 參數,這顯示guardrails在呼叫處帶有預設值。雙引數形式是文件記載的介面;單引數形式則是 Apple 公布的範例程式碼所呈現的樣貌。

References