实际效果
工作原理
投机性扇出
这里演示的首要模式是投机性扇出。每个用户请求都会对照一长串问题进行评估，其中许多问题对大多数请求来说最终并不相关。
我们来看下面这个用户请求：
“把房子里所有的灯都关掉”
这是一个非常简单的请求，我们的代码只需要考虑以下问题的答案：
- “这是什么类别的请求？”（智能家居命令）
- “这个请求针对的是哪个域？”（整个房子）
- “这个请求针对的是哪种类型的设备？”（灯）
- “应该对灯执行什么操作？”（关闭）
请注意，最后一个问题的写法假定了用户正在对灯下达命令，而我们在尚不知道用户实际请求什么之前就提出了它。这就是我们所说的“投机性问题”——在还不确定它是否相关之前就提出，这让我们能够并行评估所有问题，再依靠代码在事后过滤掉无关的结果。这是构建系统的关键模式：用一组问题就能处理各种各样的用户请求。
错误做法：串行 API 调用
错误的做法是把这些问题拆分到多次 API 调用中，等到确定需要答案时才提问：
- “这是什么类别的请求？”（智能家居命令）
然后，只有在知道这是智能家居命令之后：
- “这个请求针对的是哪个域？”（整个房子）
- “这个请求针对的是哪种类型的设备？”（灯）
然后，只有在知道它针对的是灯之后：
- “应该对灯执行什么操作？”（关闭）
这种做法以最少的问题数量为优化目标，但最终比把所有问题打包进一次预先的 API 调用要慢得多、贵得多。
TypeSafe 与 LLM 配合使用
这个演示还展示了 TypeSafe 如何与 LLM 配合，来处理有时需要字符串生成步骤的系统：
**拆分复合用户请求：**这个演示中的一个问题是一个 Noul 问题，用于识别用户请求是否包含多个不同的动作。如果为真，系统会使用 LLM 把该请求拆分成一组原子命令。拆分后的请求再由 TypeSafe 逐一评估。
**回退到对话式 LLM：**当 TypeSafe 判定用户查询是在请求一般信息或对话时，系统会调用 LLM 生成自由格式的回复。这让交互式系统能够以快速且高性价比的方式处理具有已知确定性行为的请求，同时在需要时保留生成式 LLM 提供的灵活性。TypeSafe 的初始响应相比 LLM 响应快得多，给整个系统增加的延迟可以忽略不计。
自己动手运行
这个演示是一个简单的 Vite/React 单页应用，使用 TypeSafe API 来评估用户请求。完整源代码将在正式发布时提供在 GitHub 上。其 README 包含在本地运行该演示的说明，并概述了源代码中哪些部分负责演示的哪些功能。