← 返回日报
🌐 机器翻译 · DeepSeek · HN

Local AI needs to be the norm

注:自动提取正文(generic_extract),翻译可能不完整


本地 AI 应成为常态

现代软件的一个趋势是,开发者们为了在应用中加入某些功能,就草率地调用 OpenAI 或 Anthropic 的 API。理性的人可能会争论这些功能是否真的为用户带来了价值,但我想讨论的是,为应用程序引入对云端 AI 模型的依赖这一根本性问题。这种懒惰正在催生一代脆弱、侵犯隐私、且从根本上就有缺陷的软件。我们正在构建这样的应用:一旦服务器崩溃或信用卡过期,它们就会停止工作。我们需要回归到一种习惯,即构建由本地设备完成工作的软件。

我们口袋里的芯片,其速度之快,远超十年前的水平。它拥有一个专用的神经网络引擎,大部分时间都处于闲置状态,而我们却在等待弗吉尼亚州某个服务器集群返回 JSON 响应。这太荒谬了。

即使你的初衷是好的,一旦你将用户内容流式传输给第三方 AI 提供商,你就改变了产品的性质。你现在需要面对数据留存问题,以及随之而来的所有负担(同意、审计、泄露、政府请求、模型训练等)。除此之外,你还大大复杂化了你的技术栈,因为你的功能现在依赖于网络状况、外部供应商的可用性、速率限制、账户计费以及你自己的后端健康状态。恭喜你!你把一个用户体验功能变成了一个需要花钱的分布式系统。如果这个功能可以在本地完成,那么选择陷入这种混乱就是自讨苦吃。

“AI 无处不在”不是目标。有用的软件才是目标。

具体示例:Brutalist Report 的设备端摘要

几年前,我启动了一个名为 Brutalist Report 的有趣副项目,这是一个受 1990 年代风格网页启发的新闻聚合服务。最近,我决定为其构建一个原生 iOS 客户端,设计目标是确保它仍然能提供高密度的新闻阅读体验。标题以简洁的列表呈现,阅读模式能剥离那些已经侵蚀网络的“毒瘤”,并且(可选地)提供一个“智能”视图来生成文章摘要。

但关键在于:摘要是使用苹果的本地模型 API 在设备上生成的。没有服务器绕行。没有提示词或用户日志。没有供应商账户。不需要“我们将存储您的内容 30 天”的脚注。人们已经如此习惯于任何 AI 使用都发生在服务器端。作为一个行业,我们还有很多工作要做,才能扭转这种局面。我并非没有意识到,有时你的用例确实需要只有云端托管模型才能提供的智能,但这并非你试图解决的每一个用例的情况。我们需要深思熟虑。

可用的工具

我只能谈谈苹果生态系统中可用的工具,因为我最初的重点开发工作是在这个平台上。在过去的一年里,苹果在这方面投入了大量资源,使开发者能够轻松地利用内置的本地 AI 模型。核心流程大致如下:

import FoundationModels

let model = SystemLanguageModel.default
guard model.availability == .available else { return }

let session = LanguageModelSession {
    Provide a brutalist, information-dense summary in Markdown format.
    - Use **bold** for key concepts.
    - Use bullet points for facts.
    - No fluff. Just facts.
}

let response = try await session.respond(options: .init(maximumResponseTokens: 1_000)) { articleText }
let markdown = response.content

对于更长的内容,我们可以将纯文本分块(每块大约 10,000 个字符),为每块生成简洁的“仅事实”笔记,然后进行第二次传递,将它们合并成最终的摘要。这就是本地模型擅长的任务。输入数据已经在设备上(因为用户正在阅读它)。输出是轻量级的。它快速且私密。即使它没有超人般的博士级智能也没关系,因为它只是总结你刚刚加载的页面,而不是创造世界知识。当模型的任务是转换用户拥有的数据,而不是充当宇宙搜索引擎时,本地 AI 就能大放异彩。

有很多人们想要但又不信任的 AI 功能:总结电子邮件、从笔记中提取待办事项、对文档进行分类等等。通常的云端方法将每一个功能都变成了一次信任考验。“请将您的数据发送到我们的服务器。我们保证会妥善处理。”本地 AI 改变了这一点。你的设备上已经有数据了。我们就在这里完成工作。你不需要通过撰写一篇 2000 字的隐私政策来建立与用户的信任。你建立信任的方式是,从一开始就不需要它。

该平台上的工具甚至更进一步。苹果最近最好的举措之一,就是将“AI 输出”从非结构化的文本块推向类型化数据。与其“要求模型输出 JSON 并祈祷”,更新更好的模式是定义一个代表你想要的东西的 Swift 结构体。用自然语言为每个字段给模型提供指导。要求模型生成该类型的一个实例。就是这样。概念上,它看起来像这样:

import FoundationModels

@Generable
struct ArticleIntel {
    @Guide(description: "One sentence. No hype.")
    var tldr: String
    @Guide(description: "3–7 bullets. Facts only.")
    var bullets: [String]
    @Guide(description: "Comma-separated keywords.")
    var keywords: [String]
}

let session = LanguageModelSession()
let response = try await session.respond(to: "Extract structured notes from the article.", generating: ArticleIntel.self) { articleText }
let intel = response.content

现在,你的 UI 不必从 Markdown 中抓取要点,或者指望模型记住你的 JSON 模式。你得到一个具有真实字段的真实类型,并且可以一致地渲染它。它产生你的应用可以实际使用的结构化输出。而且这一切都在本地运行!这不仅仅是...

📖 阅读原文 →