本地 AI 应成为常态

# 本地 AI 应成为常态 来源：https://unix.foo/posts/local-ai-needs-to-be-norm/ 现代软件开发的一个当前趋势是，开发者为了在应用中实现某些功能，直接调用 OpenAI 或 Anthropic 的 API。对于这些功能是否真的为用户带来了价值，理智的人们或许可以争论一番，但我想要讨论的是这样一个根本性概念：为应用程序引入对云端托管 AI 模型的依赖。 这种偷懒的做法催生了一代脆弱、侵犯隐私且从根本上存在缺陷的软件。我们正在构建的应用程序，一旦服务器崩溃或信用卡过期，就会立即停止工作。 我们需要重拾一种习惯，让本地设备来完成工作。我们口袋里的芯片速度比十年前可用的设备快了令人难以置信的程度。它内置了专用的神经引擎，大部分时间处于闲置状态，而我们却在等待弗吉尼亚州服务器集群返回 JSON 响应。这简直荒谬。 即使你的初衷是纯粹的，但只要你将用户内容流式传输给第三方 AI 提供商，你就改变了产品的性质。你现在面临数据保留的问题，以及随之而来的所有包袱（同意权、审计、数据泄露、政府请求、训练数据等）。 除此之外，你还极大地复杂化了你的技术栈，因为你的功能现在依赖于网络状况、外部供应商的运行时间、速率限制、账户账单以及你自身后端的健康状况。 恭喜！你把一个用户体验功能变成了一个**耗费你金钱的分布式系统。** 如果该功能可以在本地完成，选择这种混乱局面无异于自讨苦吃。 “AI 无处不在”并不是目标。**有用的软件才是目标。** ## 具体案例：Brutalist Report 的设备端摘要 多年前，我启动了一个有趣的小项目，名为 The Brutalist Report（https://brutalist.report/），这是一个受 1990 年代风格网络启发的新闻聚合服务。 最近，我决定为它构建一个原生 iOS 客户端（https://apps.apple.com/app/brutalist-report/id6756546583），设计目标是确保它仍然是一种高密度的新闻阅读体验。标题以简洁的列表形式呈现，一种剥离了网络上那些“癌症般”元素的阅读器模式，以及（可选的）一个“智能”视图，用于生成文章摘要。 Brutalist iOS 主视图（https://apps.apple.com/app/brutalist-report/id6756546583）Brutalist iOS AI 视图（https://apps.apple.com/app/brutalist-report/id6756546583）Brutalist iOS AI 视图（https://apps.apple.com/app/brutalist-report/id6756546583） 但关键在于：摘要是**在设备端**使用 Apple 的本地模型 API 生成的。没有服务器中转。没有提示词或用户日志。没有供应商账户。不需要“我们将您的内容存储 30 天”之类的脚注。 对于很多人来说，任何 AI 的使用都在服务器端发生，这已经变得司空见惯。作为行业，我们需要付出很多努力来扭转这一局面。 我并非没有意识到，有时你遇到的使用场景确实需要只有云端托管模型才能提供的智能，但这并不适用于你试图解决的每一个使用场景。我们需要在这里深思熟虑。 我只能谈论 Apple 生态系统内可用的工具，因为这是我最初开发努力的重点。在过去的一年里，Apple 在这方面投入了大量资源，让开发者能够轻松利用内置的本地 AI 模型。 核心流程大致如下： ```swift import FoundationModels let model = SystemLanguageModel.default guard model.availability == .available else { return } let session = LanguageModelSession { """ 提供一个粗野主义风格的、信息密集的 Markdown 格式摘要。 - 对关键概念使用 **粗体**。 - 对事实使用项目符号。 - 没有废话。只有事实。 """ } let response = try await session.respond(options: .init(maximumResponseTokens: 1_000)) { articleText } let markdown = response.content ``` 对于较长的内容，我们可以将纯文本分块（每块约 10,000 个字符），为每块生成简洁的“仅限事实”笔记，然后运行第二遍将它们组合成最终摘要。 这正是本地模型**完美**胜任的工作类型。输入数据已经在设备上（因为用户正在阅读它）。输出轻量级。它快速且私密。即使它不是超级人类博士级别智能也没关系，因为它是在总结*你刚刚加载的页面*，而不是发明世界知识。 **当模型的任务是转换用户拥有的数据，而不是充当宇宙搜索引擎时，本地 AI 才会大放异彩。** 有很多人们*想要*但不*信任*的 AI 功能。总结电子邮件、从笔记中提取行动项目、对文档进行分类等。 通常的云端方法将每一项都变成了一场信任练习。“请将您的数据发送到我们的服务器。我们保证会处理好。” 本地 AI 改变了这一点。你的设备已经拥有数据。我们会在这里直接完成工作。 你不需要通过撰写 2,000 字的隐私政策来赢得用户的信任。你通过根本不需要隐私政策来赢得信任。 平台上可用的工具甚至走得更远。 Apple 最近采取的最佳举措之一，是将“AI 输出”从未结构化的文本块推向*类型化数据*。 不再是“向模型请求 JSON 然后祈祷”，更新且更好的模式是定义一个代表你想要的东西的 Swift `struct`。用自然语言为每个字段提供指导。要求模型生成该类型的实例。 就是这样。 概念上，它看起来像这样： ```swift import FoundationModels @Generable struct ArticleIntel { @Guide(description: "一句话。不夸大。") var tldr: String @Guide(description: "3–7 个项目符号。仅限事实。") var bullets: [String] @Guide(description: "逗号分隔的关键词。") var keywords: [String] } let session = LanguageModelSession() let response = try await session.respond( to: "从文章中提取结构化笔记。", generating: ArticleIntel.self ) { articleText } let intel = response.content ``` 现在，你的 UI 不必从 Markdown 中抓取项目符号，也不必指望模型记住你的 JSON 模式。你获得了一个具有真实字段的真实类型，并且可以一致地渲染它。它产生了你的应用可以实际使用的*结构化输出*。而且这一切都在本地运行！ 这不仅仅是更舒适的人机工程学。这是一种工程上的改进。 如果你正在构建一个以本地为先的应用，这就是“AI 作为新奇事物”与“AI 作为值得信赖的子系统”之间的区别。 ## “但是本地模型不够智能” 正确。 但这也无所谓。 大多数应用功能并不需要能够写莎士比亚作品、解释量子力学并通过律师资格考试的模型。它们需要一个能够可靠地执行以下操作之一的模型：总结、分类、提取、重写或规范化。 对于这些任务，本地模型可以非常出色。 如果你试图使用本地模型作为整个互联网的替代品，你会感到失望。如果你将其用作位于*应用内部*的“数据转换器”，你会惊讶于自己为何曾经将这些东西发送到服务器。 仅在真正必要时才使用云端模型。将用户的数据保留在属于它的地方。当你*确实*使用 AI 时，不要仅仅把它当作一个聊天框粘合在一起。将其用作具有类型化输出和可预测行为的真实子系统。 当你打算发布一个功能时，停止发布分布式系统。