技术

本文档定义了使用 TypeChat 的技术。

模式工程

TypeChat 用模式工程取代了提示工程：您无需编写非结构化的自然语言提示来描述所需输出的格式，而是编写 TypeScript 类型定义。这些 TypeScript 模式不一定是您的应用程序用于处理和存储数据的确切类型。相反，它们是通过控制和约束大型语言模型 (LLM) 响应的方式，在自然语言和应用程序逻辑之间建立桥梁的类型，以对您的应用程序有意义的方式。

打个比方，在模型-视图-视图模型 (MVVM) 用户界面设计模式中，视图模型在用户界面和应用程序逻辑之间建立桥梁，但它不是应用程序用于处理和存储信息的模型。您为 TypeChat 设计的模式就像视图模型，但可能更恰当地称为响应模型。

为了最大程度地提高 TypeChat 的成功率，我们建议在定义响应模型类型时遵循以下最佳实践：

• 保持简单（基本类型、数组和对象）。
• 只使用可表示为 JSON 的类型（即不使用类）。
• 使数据结构尽可能扁平化和规范化。
• 在类型和属性上添加注释，用自然语言描述意图。
• 限制泛型的使用。
• 避免深度继承层次结构。
• 不要使用条件类型、映射类型和索引访问类型。
• 允许 LLM 稍作发挥（例如，使用 string 而不是字面量类型）。
• 包含一个“逃生舱口”以抑制幻觉。

最后一点值得进一步阐述。我们发现，当响应模型试图将用户请求限制在没有回旋余地的狭窄模式中时，LLM 可能会对超出其领域的用户请求产生幻觉。例如，如果您向您的咖啡店机器人询问“两棵高大的树”，在没有其他选择的情况下，它很可能会将其转换为两杯高大的拿铁（而不会告知您它这样做了）。

然而，当您在模式中包含一个“未知”类别的逃生舱口时，LLM 会很乐意将非领域请求路由到该类别中。这不仅极大地抑制了幻觉，还为您提供了一种便捷的方式，让用户知道请求的哪些部分未被理解。TypeChat 仓库中的所有示例都使用了这种技术。