ASP.NET Extensions 项目中结构化输出模式生成对数值类型的处理问题

在 ASP.NET Extensions 项目中，当使用结构化输出模式（Structured Output Schema）生成 JSON 模式时，对于 decimal、double 和 float 等数值类型的处理存在一个潜在问题，可能导致 JSON 解析失败。

问题背景

当开发者定义一个包含数值类型的记录（record）时，例如：

public record Product(int Name, decimal Price);

然后尝试通过聊天客户端完成请求并期望返回该类型的实例：

var response = await chatClient.CompleteAsync<Product>(
    "Extract info about the following: we sell eggs for fifty dollars");
if (response.TryGetResult(out var product))
{
    Console.WriteLine($"{product.Name} costs {product.Price:c}");
}

开发者期望这段代码能够可靠地工作，但实际上经常会遇到 JSON 解析失败的情况。

根本原因分析

问题的根源在于当前生成的 JSON 模式中，对于数值类型的属性（如 Price）允许两种类型：

"price": {
    "type": ["string", "number"]
}

这种宽松的类型定义会导致语言模型（LLM）有时会选择返回字符串形式的数值，例如：

{ "Name": "Eggs", "Price": "$50" }

或者更糟糕的情况：

{ "Name": "eggs", "Price": "fifty dollars" }

这些格式都无法被正确地反序列化为 Product 类型的实例，因为 Price 字段被定义为 decimal 类型，而返回的却是字符串。

技术影响

这个问题在以下几个方面产生负面影响：

1. 可靠性降低：由于语言模型可能会选择返回字符串格式的数值，导致解析失败的概率增加。

2. 类型安全破坏：原本期望的强类型系统在这种情况下会被破坏，因为返回的数据类型与预期不符。

3. 用户体验下降：开发者需要处理更多的异常情况，增加了代码复杂度。

解决方案建议

针对这个问题，可以考虑以下改进方向：

1. 严格类型约束：对于明确声明为数值类型（decimal/double/float）的字段，JSON 模式生成器应该只允许 "number" 类型，而不应该包含 "string" 类型。

2. 格式规范：可以为数值类型添加额外的格式规范，指导语言模型返回符合预期的数值格式。

3. 类型转换处理：在客户端增加对返回值的预处理逻辑，尝试将字符串形式的数值转换为对应的数值类型。

最佳实践

开发者在处理类似场景时，可以采取以下预防措施：

1. 明确类型声明：确保数据模型的类型定义准确反映业务需求。

2. 输入验证：在接收和处理数据时，增加严格的输入验证逻辑。

3. 错误处理：为可能的解析失败情况准备完善的错误处理机制。

4. 测试覆盖：编写充分的测试用例，覆盖各种可能的输入格式。

总结

这个问题的解决将提高 ASP.NET Extensions 项目中结构化输出模式的可靠性和一致性。通过更严格的类型约束，可以确保语言模型返回的数据格式与开发者期望的类型定义保持一致，从而减少运行时错误，提高整体系统的稳定性。