跟着视频学编程：使用 Foundation Models 框架将设备端 AI 引入你的 App

大家好 我叫 Naomy 让我们一起来深入探索 SwiftUI 和设备端智能技术的世界 在这个跟随编程讲座中 我们将探讨 如何使用 Foundation Models 框架 为你的 App 添加精彩的新功能 我将通过分步骤演示带你了解 我如何创建一个 规划旅行行程的 App 通过 Foundation Models 框架 你能够直接访问 Apple 的 设备端大语言模型 从而开启无限创作可能性！ 由于一切都在设备端运行 因此用户的数据可以保持私密 模型处于离线状态 并且已嵌入到操作系统中 它不会增加 App 占用的容量 借助这个框架 我们可以在 macOS、 iPadOS、iOS 和 visionOS 上 创建强大、私密且高效的功能 我和我的朋友想去旅行 但我们需要一些灵感来决定 去哪里、做什么 规划行程可能很困难 但使用 Foundation Models 框架却很容易 让我们用它创建一个 App 替我们完成所有行程规划！ 下面是我们今天要构建的内容 在我的 App 中 着陆页显示了一些可供浏览的 精选地标 噢 那些树看起来很有趣！ 让我们选择“约书亚树国家公园” 轻点“生成”按钮 模型就会帮助我们进行规划！ 它将创建一个行程 在这个过程中它还会使用工具调用 自主为我们的地标选择最佳兴趣点 我的朋友一定会喜欢这个 App 让我们开始构建吧！ 我们今天将介绍 使用这个框架的几个步骤 这一切都始于提示工程 我将为大家展示如何使用 Xcode 的 Playground 来完善提示 我们将使用工具调用来完善模型 让它与外部来源进行通信 为我们的地标获取兴趣点 然后我们将流式传输输出 在模型生成行程的过程中 就开始显示行程内容 为了进一步完善 我们将分析 App 并应用优化 以通过 Foundation Models 框架 获得出色的效果 好的提示是获得出色结果的关键 提示通常是一项繁琐的任务 需要大量迭代 我需要运行 App、检查输出、 更改提示 然后从头重新运行 不断重复这一操作 但那样我一整天就得耗在这里 就没时间去旅行了！ 幸好 Xcode 更新的 Playground 功能能帮上忙 首先 请确保画布已启用

这看上去就像 SwiftUI 的预览一样 但它会对任何 Swift 代码 提供实时反馈 现在 在项目的任意文件中 我可以导入 Playground

然后编写一个 #Playground 来迭代我的代码

先从最基础的着手 我将导入 Foundation Models

创建会话

并提出请求

我在提示中说：“创建一个行程” 在我输入的同时它就会自动执行 我们可以在画布中看到结果

我的提示似乎不太明确 是吧？ 让我先添加一个地点

这样的提示清晰多了 这次我们得到了一个行程 我对这个结果感到满意 而且我可以随时回来调整提示语 我们刚刚了解了上手使用 Foundation Models 框架有多简单 只需给出提示并接收字符串输出 但对于我的行程 我真的很想实现更结构化的输出 我想使用自己的数据结构来表示结果 但又不想费心来解析模型的输出 引导式生成能让模型 自动创建我想要的数据结构 前提是我要将它们注解为可生成 我们来实际操作一下 这里有一个 我想让模型生成的行程结构 我们先导入 Foundation Models

并添加 Generable 注解

可生成类型的唯一要求 是你的属性类型也是可生成的 幸好字符串这样的常见类型 是立即可用的可生成类型 如果你有嵌套类型 比如这里的 DayPlan 你也可以把它们变成可生成类型 现在我们有了一个完全可生成的 类型层次结构 接下来就可以 让模型生成行程结构作为响应 如果你想更好地控制输出 你可以使用 Guide 宏 来对属性的值设置约束 例如 你可以添加带描述的 Guide 就像我在这里对标题的处理

我们还可以将属性 限制为已知的值子集

我可以添加一个计数

来确保我的 Days 数组 始终包含三个元素 甚至对一个属性使用多个 Guide 接下来我将为属性再添加几个 Guide

Guide 描述实际上是 提示模型的另一种方式 强烈建议大家观看“深入探讨”视频 Louis 在其中与大家分享了 有关引导式生成的一切 现在我们编写好了提示 和可生成类型 就可以将它们结合起来了

这里是我们的行程规划 将存储我们 所有的 Foundation Models 逻辑

让我们继续创建一个会话

并给它添加指示 我可以在这里使用构建器 API 轻松创建指令 在这个闭包中 我可以传入多个字符串 甚至是可生成类型的实例 指令是一种更高层次的提示形式 在这里 我将定义模型的任务是什么

我们想要一个行程 我会为模型提供 有关所选地标的一些信息

最好包含一个示例 因为示例可以让模型更清楚地了解 我想要的响应类型

我可以传入 Itinerary 结构体实例 下方使用日本的旅程 对实例进行定义

由于 Itinerary 结构体是可生成的 所以 Foundation Models 会自动 将它转换为模型可以理解的文本 现在我们已准备好发出请求 并将我们的可生成类型作为输出

在提示中 我们将 显式要求模型提供行程

为了将一切关联在一起 让我们将行程设置为来自模型的响应

最后一步是在 UI 中显示行程 让我们将 ItineraryPlanner 设为 Observable 这样当行程生成时 UI 中就会显示

接下来将它作为状态属性 添加到 LandmarkTripView 中 这样视图就会 随着规划内容的变化而更新

如果我们在这里初始化 即使视图没有出现在屏幕上 它也会不必要地重新创建 这会带来不必要的性能开销 最好使用任务修饰符延迟对象的创建 那么我们在这里添加一个任务 并初始化规划

这样就只会在视图显示时调用一次 在从模型收到行程时 我们就可以显示它

我将在这里使用另一个视图 名为 ItineraryView 我将在其中显示标题

然后添加一些样式

我将对描述进行相同的处理

接下来是逻辑依据

我将使用其他视图以类似的方式 显示剩余的行程属性 这是一个不错的开端 模型将使用指令中 提供的描述来生成基本行程 让我们更进一步 这个框架提供一个灵活的 tool 协议 使模型能够在响应中 包含外部信息 你可以尽情发挥创意 添加手机通讯录里的联系人 日历中的日程 甚至是在线内容 模型会自主决定何时调用你的工具 以及多久调用一次 为了让我的规划 App 更专业 我将创建一个工具 用来调用 MapKit 以获取地标的最佳兴趣点 要创建工具 你需要遵循 tool 协议

这包括用于标识工具的唯一名称、 关于何时调用工具的自然语言描述 以及一个调用函数 即模型使用你自己定义的参数 来调用工具的方式 我们开始编写工具 我将导入 Foundation Models

和 MapKit

我有一个遵从 tool 协议的数据结构

包含名称

和描述

框架会自动将这些字符串放入指令中 以便模型可以理解工具的作用 并决定何时调用它 工具还可以获取用户的输入 例如他们选择的地标

我们希望工具能够获取 不同类型的兴趣点 所以来添加一个枚举

模型将利用它的世界知识 来决定哪些类别 最有可能适用于某个地标 例如 在大堡礁找到码头的可能性 比在约书亚树国家公园 这样干燥的沙漠地区 找到码头的可能性更大 模型将生成这个枚举 因此它必须是可生成类型

然后我们将定义 Arguments 结构体 这个结构体会将枚举 和自然语言查询结合使用

对于实现 使用调用方法

模型决定调用工具时 就会通过这个方法调用 我先前编写了一些 MapKit 逻辑

它们会向 MapKit 发出请求

通过使用模型生成的 自然语言查询作为输入 同时使用模型选择的类别 并获取我的地标坐标 20 公里范围内的兴趣点

我们将使用请求的约束进行搜索

并返回结果

然后就可以实现调用方法 让我们与 MapKit 建立通信

筛选结果

然后返回输出

这就是定义从 MapKit 获取信息的工具所需的全部操作 要连接它 让我们回到 ItineraryPlanner

这是我们之前创建的会话 我们将使用用户选择的地标作为输入 来创建工具的实例

然后就可以将工具 传递到会话构造器中

这足以让模型调用工具 但如果希望工具被更频繁地调用 我们还可以进行额外的提示 我们可以显式要求模型 使用我们的工具和类别

这就可以了 我们准备好进行测试了！ 实际上 如果手头 没有测试设备也没关系 如果你的开发机器运行的是 最新版 macOS 而且已启用 Apple 智能且就绪 就可以方便地 在 iPhone 和 visionPro 模拟器中 运行测试 让我们选择约书亚树国家公园 并生成行程

现在 你可能会注意到 需要一些时间才会返回结果 这是因为模型会一次性返回所有输出 因此我们要等到 所有活动生成后才能收到结果 不用担心 稍后我会 告诉大家如何加快这个过程！ 好了 我们收到了一个有趣的行程！

不过我们实际上忘记了 一件非常重要的事情 我们假设设备端的 Foundation Model 始终可用 但情况并非总是如此 模型的可用性 取决于 Apple 智能的可用性 而 Apple 智能在特定设备上可能 不受支持、未启用或未就绪 因此务必要检查模型的状态 并在 UI 中进行相应的处理 现在 我们无需再依赖实体设备测试 更不必为了测试 而禁用 Apple 智能 只需使用 Xcode 中的一个便捷的方案选项

在这个方案中 可以看到 Foundation Models 可用性覆盖 当前它是关闭的 但前三个选项都是导致模型在设备上 不可用的原因 我们选择一项 然后尝试生成一个行程 看看 App 中会发生什么

糟糕 这可不是我们想要的效果 这里只会显示错误提示 而且也不可操作 我需要重新考虑 如何将可用性整合到 App 中 考虑一下之前显示的三种情况 若设备不符合 使用 Apple 智能的条件 那显示生成行程按钮就没有意义 选择地标时 只需使用 App 中的离线数据 让用户看到地标的简短描述即可 在第二种情况下 设备可以选择采用 但尚未采用 Apple 智能 我们应该让用户知道这就是 行程规划不可用的原因 他们可以自行决定是否选择 采用并访问这个功能 最后 模型未就绪仅意味着 需要更多时间让模型完成下载 我们只需告诉用户稍后再试 因为功能马上就能用

设计好了 App 行为 我们可以利用可用性 API 来确定设备当前的可用状态 在我的视图中 我将为 正在使用的模型添加一个新变量 在这个示例中就是系统语言模型

然后我们可以打开可用性状态

如果模型可用 则可以 继续之前相同的行为

如果 Apple 智能未启用 就告知用户

如果模型尚未就绪 就请用户稍后再试

如果不可用 我们将隐藏行程按钮 并仅展示地标相关知识

我已经将方案中的 Foundation Models 覆盖 设置为“设备不符合条件” 再来看看这种情况

看上去好多了 现在 我们会看到地标相关知识 而且“生成行程”按钮已被移除 以防止用户 进入设备不支持的功能 前面提到 App 会等待整个行程生成后 再在 UI 中显示行程 但如果在模型生成行程时 流式传输行程 我们就可以立即查看推荐行程！ 要使用流式传输 应更改调用的响应方法

我们得到的不是完整的行程 而是部分版本 我们可以使用自动创建的 PartiallyGenerated 数据结构 这是你的可生成结构体 但所有属性都设为了可选 因此我将更改预期的行程类型

现在 结果将是一个以 PartiallyGenerated 类型作为输出的 新异步序列

流中的每个元素 都是行程逐步更新后的版本 例如 第一个元素可能有一个标题 但其他行程属性将为空 然后第二个元素可能有标题和描述等 直到我们收到完整生成的行程 现在 我需要在视图中解包这些属性 在这里 也需要考虑一下哪些属性 可以单独展示 在我的示例中 行程有标题、描述 然后是每天的规划 这个顺序也是合理的 因此 我会将行程设置为部分生成

然后解包标题、

描述

以及逻辑依据

然后是日期列表

我还需要显示部分生成的每日规划 最棒的是 PartiallyGenerable 结构体 可自动识别 因此我不必自行管理 ID 我只需将 Swift UI 的 forEach 与部分生成结构一起使用

就是这么简单 让我们根据行程添加一个动画

并添加一些内容过渡到属性中

这样结果就能顺畅地流入视图

接下来我将对所有其他属性进行解包 我们现在距离最终产品 已经非常接近了 让我们在手机上测试一下！ 提出与之前相同的请求

这一次 我们会在 UI 中 立即看到流式输出！ 作为用户 我可以在内容生成的同时 阅读第一天的行程

不过 你可能已经注意到 在第一个字段出现在屏幕上之前 存在一些延迟 要解决这个问题 了解背后的机制 会很有帮助

这正是使用全新的 Foundation Models Instrument 来更深入地了解 影响 App 表现的因素的好时机 让我们看看 通过分析 App 会发现什么 我们之前谈到了 如何在模拟器上运行 App 这能有效用于测试功能 但可能无法产生 准确的表现结果 例如 模拟器在 M4 Mac 上可能会比 在旧款 iPhone 上更快地生成结果 在查看表现时 重要的是 将这些差异牢记在心 我将在实体 iPhone 上进行分析

首先在 Mac 上打开 “Instruments”App 并连接手机

然后添加新的 Foundation Models Instrument

然后开始录制并创建一个行程

素材加载轨道显示了 加载模型所花费的时间 加载内容包括默认系统语言模型 和安全防护措施 推理轨道也以蓝色显示

最后 紫色条状表示了 工具调用花费的时间 我们可以跟踪 生成行程所花费的总时间 还有输入令牌数量 这与指令和提示大小成正比 一开始的这部分延迟 是加载系统语言模型 花费的时间 有几种方法可以加快这一过程 我们刚刚观察到部分的初始反应时间 被记录在了素材加载轨道中 设备端语言模型由操作系统管理 如果系统正在提供其他关键功能 或者模型已经有一段时间未使用 则可能不会保存在内存中 当我调用 session.respond 时 如果模型还不在内存中 操作系统将加载模型 预热可以通过 在你发出请求之前加载模型 让会话在一开始就能顺畅调用 最好在 App 相对空闲而且用户 给出明确信号表明将使用这个会话时 进行预热 一个很好的预热时机是在用户 刚开始在会触发提示的文本字段中 键入内容时 在我们的 App 中 当用户轻点地标时 他们很可能即将提出请求 我们可以在他们 按下“生成路线”按钮之前预热 以主动加载模型 等他们读完描述后 模型就准备就绪了！

第二个优化可以在请求时添加 还记得响应函数的生成参数吗？ 我们在这里使用了 Itinerary 当然 框架会自动将 数据结构的生成架构 插入到你的提示中 但这会添加更多令牌 从而增加反应时间和上下文大小 如果模型在发出请求之前 已完全了解响应格式 我们就可以将 IncludeSchemaInPrompt 设为 false 并获得一些效果提升

我们何时可以应用这项优化？ 第一种情况是 你在多轮次对话中发出后续的 相同类型请求时 会话中的第一个请求已经通过 在提示中包含架构 来为引导式生成提供了上下文 因此我们不需要对会话中的后续请求 执行这个操作 第二种情况是 指令包含架构的完整示例时 还记得我们是如何在指令中 传入示例行程的吗？ 在这个示例中 这已经足够了 因为我们的行程结构不包含可选属性

如果你的架构中包含可选属性 那么你需要提供包含具体值和为空的 所有可选属性的示例 最后一个考虑因素： IncludeSchemaInPrompt 设为 false 意味着我们会丢失 添加到 Guide 中的描述 不过 如果你使用了一个详尽的示例 这应该不是问题 我们来测试一下这些优化！ 我们在请求中将 IncludeSchemaInPrompt 选项 设为 false 我们还会在用户访问 地标描述页面时预热会话 让我们快速创建一个包装器

然后在我们的会话中调用它

现在来看看结果！ 我再次录制了这个过程 来看看效果 素材载入轨道在我轻点生成按钮之前 已经有一些活动 我们可以看到输入令牌数量大幅减少 现在总响应时间更短了！ 考虑到通过这些优化节省的时间 我们一定会准时赶上航班 现在 我已经准备好启程了！

但在我离开之前 这里还有一些 你可能会感兴趣的其他讲座 如果你还没有观看 请务必观看“了解”讲座 全面了解这个框架 请观看“深入探讨”视频以深入了解 如需了解更多关于提示的最佳实践 请观看“提示设计与安全”讲座 谢谢观看！