ASP.NET Extensions项目中Ollama GetResponseAsync空对象问题解析

背景介绍

在ASP.NET Extensions项目的AI功能模块中，开发者从OpenAIClient切换到OllamaChatClient时遇到了一个典型问题：GetResponseAsync方法返回的对象属性为空，尽管服务器返回了看似有效的JSON数据。这个问题揭示了本地AI模型与云端服务在JSON响应处理上的重要差异。

问题本质

当使用Ollama本地模型（如llama3.2或phi4）时，模型返回的JSON结构往往包含两部分内容：

1. JSON Schema定义
2. 实际数据值

这与标准的API响应格式不同，导致.NET的反序列化机制无法正确识别和提取数据部分。例如，一个典型的响应可能如下：

{
  "$schema": "...",
  "type": "object",
  "properties": {
    "fluency": {"type": "number", "value": 80},
    // 其他属性定义...
  },
  // 实际数据值
  "fluency": 80,
  // 其他数据...
}

技术分析

1. 模型行为差异

本地小型AI模型（如Ollama运行的模型）与大型云端模型（如OpenAI）在JSON生成能力上存在显著差异：

• 小型模型往往不能严格遵循JSON Schema规范
• 响应中可能混合Schema定义和实际数据
• 生成的结构可能不符合标准JSON格式

2. 反序列化机制

ASP.NET Extensions的默认反序列化器期望的是纯净的JSON数据对象，而不是混合了Schema定义的复合结构。当遇到这种非标准响应时，反序列化过程会失败，导致返回空对象。

解决方案

1. 使用原生结构化输出

ASP.NET Extensions 9.3.0及以上版本提供了原生结构化输出支持：

var response = await client.GetResponseAsync<T>(prompt, useNativeJsonSchema: true);

这种方法指示Ollama约束token生成器只产生符合Schema的token，可以显著提高JSON生成的准确性。

2. 改进提示工程

对于小型模型，可以通过优化提示词来提高JSON生成的可靠性：

• 在提示中包含JSON结构示例
• 明确要求模型只返回数据部分
• 使用更简单的JSON结构

3. 后处理验证

实现自定义的反序列化逻辑，处理模型可能返回的非标准JSON：

try 
{
    return JsonSerializer.Deserialize<T>(response);
}
catch
{
    // 尝试提取实际数据部分
    var dataPart = ExtractDataFromMixedJson(response);
    return JsonSerializer.Deserialize<T>(dataPart);
}

最佳实践建议

1. 模型选择：对于需要严格JSON输出的场景，优先考虑使用更大的模型
2. 错误处理：总是对AI模型的响应进行验证和错误处理
3. 渐进增强：从简单结构开始，逐步增加复杂度
4. 监控日志：记录完整的请求和响应，便于问题诊断
5. 超时设置：为本地模型调用配置合理的超时时间

总结

ASP.NET Extensions项目中的AI功能为开发者提供了强大的模型集成能力，但在使用本地小型模型时需要注意JSON生成的差异性。通过理解模型行为、优化提示工程和合理使用结构化输出功能，可以显著提高AI集成的可靠性。开发者应当根据应用场景选择合适的模型规模，并实现健壮的错误处理机制来应对AI模型的不确定性输出。