本页只译了一部分
本页 27 段里还有 1 段没译成简体中文,没译的段落显示英文原文。智能家居助手演示
机器翻译译自英文(docs.typesafe.ai)本页 27 段里 1 段还没译
文档索引
在以下地址获取完整的文档索引:https://docs.typesafe.ai/llms.txt 使用此文件可以在进一步探索之前发现所有可用页面。
智能家居助手演示
演示代码:一个使用 TypeSafe 评估用户请求的智能家居助手。
查看实际操作
工作原理
投机性扇出
此处演示的核心模式是投机性扇出。每个用户请求都会针对一长串问题进行评估,其中包括许多对大多数请求而言最终都不相关的问题。
让我们考虑以下用户请求:
“关闭家里所有的灯”
这是一个非常简单的请求,我们的代码只需要考虑以下问题的答案:
- “这是一个什么类别的请求?”(智能家居命令)
- “这个请求针对什么领域?”(全屋)
- “这个请求针对什么类型的设备?”(灯光)
- “对灯光应采取什么操作?”(关闭)
请注意,最后一个问题是在假设用户正在向灯光发送命令的前提下提出的,而且我们在还不知道用户实际请求内容之前就提出了它。这被称为“投机性提问”——我们在尚不明确其相关性的情况下先行提问,使我们能够并行评估所有问题,并依靠代码在事后过滤掉不相关的结果。这是构建能够用一组问题处理广泛用户请求的系统的关键模式。
错误的方式:顺序 API 调用
错误的方法是将问题分离到多个 API 调用中,仅在确定需要答案时才提出这些问题:
- “这是一个什么类别的请求?”(智能家居命令)
接着,只有在你确定这是一个智能家居命令时:
- “此请求针对哪个领域?”(整个房子)
- “此请求针对哪种类型的设备?”(灯)
接着,只有在你确定它针对的是灯光时:
- “对灯光应采取什么操作?”(关闭)
这种方法旨在优化最少的问题数量,但其结果比将所有问题批量放在一次预先的 API 调用中要慢得多且成本更高。
TypeSafe 与 LLM 结合
此演示还展示了 TypeSafe 如何与 LLM 结合,以处理那些有时需要字符串生成步骤的系统:
拆分复合用户请求: 此演示中的一个问题是 Noul 类型问题,用于识别用户请求是否要求执行多个不同的操作。如果为真,系统将使用 LLM 将请求拆分为原子命令列表。拆分后的请求随后由 TypeSafe 单独评估。
回退到对话式 LLM: 当 TypeSafe 确定用户查询是对通用信息的请求或对话时,系统将调用 LLM 生成自由格式的响应。这使交互系统能够快速且经济高效地处理具有已知确定性行为的请求,同时在需要时保留生成式 LLM 提供的灵活性。初始的 TypeSafe 响应速度远比 LLM 响应快,因此对整体系统增加的延迟微乎其微。
亲自运行
此演示是一个简单的 Vite/React 单页应用,使用 TypeSafe API 来评估用户请求。完整源代码将在发布时于 GitHub 提供。其 README 包含在本地运行演示的说明,以及对源代码中与演示各部分相对应的代码片段的概述。