本地人工智能需要成为常态

unix.foo 发布菜单本地人工智能需要成为常态。现代软件当前的趋势之一是开发人员通过 API 调用 OpenAI 或 Anthropic 来获取应用程序中的功能。理智的人可能会质疑这些功能是否真正为用户带来了价值，但我想讨论的是应用程序依赖于云托管人工智能模型的基本概念。这种懒惰正在创造出一代脆弱、侵犯您隐私并且从根本上被破坏的软件。我们正在构建在服务器崩溃或信用卡过期时停止工作的应用程序。我们需要恢复在本地设备上构建软件的习惯。我们口袋里的硅片比十年前的速度快得令人难以置信。当我们等待来自弗吉尼亚州服务器场的 JSON 响应时，它有一个专用的神经引擎，大部分时间都处于闲置状态。这太荒谬了。即使您的意图是纯粹的，当您将用户内容流式传输到第三方人工智能提供商时，您就已经改变了产品的性质。您现在面临数据保留问题以及随之而来的所有负担（同意、审计、违规、政府请求、培训等）。最重要的是，您还大大复杂化了堆栈，因为您的功能现在取决于网络条件、外部供应商正常运行时间、速率限制、帐户计费和您自己的后端运行状况。恭喜！您采用了用户体验功能并将其转变为需要花钱的分布式系统。如果该功能可以在本地完成，那么选择陷入这种混乱状态就是自我造成的伤害。 “人工智能无处不在”并不是目标。有用的软件是目标。具体示例：Brutalist Report 的设备上摘要 几年前，我启动了一个有趣的业余项目，名为 The Brutalist Report，这是一项受 20 世纪 90 年代风格网络启发的新闻聚合服务。最近，我决定为其构建一个原生 iOS 客户端，设计目标是确保它保持高密度的新闻阅读体验。鲜明列表中的标题、消除网络毒瘤的阅读器模式，以及（可选）生成文章摘要的“情报”视图。但关键点是：摘要是使用 Apple 的本地模型 API 在设备上生成的。不走服务器弯路。无提示或用户日志。没有供应商帐户。无需“我们将您的内容存储 30 天”脚注。对于人们来说，任何人工智能的使用都发生在服务器端已经变得很平常。作为一个行业，我们还有很多工作要做来扭转这一局面。我并没有忘记，有时您拥有的用例需要只有云托管模型才能提供的智能，但并非您尝试解决的每个用例都是如此。这里我们需要深思熟虑。可用工具 我只能谈论 Apple 生态系统中可用的工具，因为这是我最初开发工作的重点。去年，苹果在这里投入了大量资金，让开发者能够轻松使用内置的本地人工智能模型。核心流程大致如下： import FoundationModels let model = SystemLanguageModel 。默认守卫模型。可用性==。 available else { return } let session = LanguageModelSession { """ 以 Markdown 格式提供粗暴、信息密集的摘要。 - 对关键概念使用**粗体 **。 - 对事实使用要点。 - 没有废话。只是事实。 """ } let response = try wait session 。响应（选项：.init（maximumResponseTokens：1_000））{articleText}让markdown =响应。对于较长的内容，我们可以将纯文本分块（每个块大约 10k 个字符），为每个块生成简洁的“仅事实”注释，然后运行第二遍将它们组合成最终摘要。这是当地模特最适合的工作。输入数据已经在设备上（因为用户正在读取它）。输出是轻量级的。它快速且私密。如果它不是超人博士级别的智能也没关系，因为它是在总结你刚刚加载的页面，而不是发明世界知识。当模型的工作是转换用户拥有的数据，而不是充当宇宙的搜索引擎时，本地人工智能就会大放异彩。有很多人工智能功能是人们想要但不信任的。总结电子邮件、从笔记中提取操作项、对文档进行分类等。通常的云方法将其中每一项都转变为信任练习。 “请将您的数据发送到我们的服务器。我们保证对此保持冷静。”本地人工智能改变了这一点。您的设备已经有数据。我们将在这里完成工作。通过编写 2,000 字的隐私政策并不能与用户建立信任。您从一开始就不需要信任来建立信任。该平台上可用的工具更进一步。苹果最近采取的最佳举措之一是将“人工智能输出”从非结构化文本块转向键入数据。更新更好的模式不是“向模型询问 JSON 并祈祷”，而是定义一个 Swift 结构来表示