Microsoft.Extensions.AI.OpenAI 中 IChatClient 忽略 ChatOptions 模型设置的解决方案

在开发基于大语言模型的应用时，开发者通常会使用不同的模型来处理不同的任务。Microsoft.Extensions.AI 项目提供了便捷的依赖注入方式来集成AI服务，但在使用过程中发现了一个值得注意的行为差异。

问题现象

当开发者使用 Microsoft.Extensions.AI.OpenAI 库时，通过以下两种方式设置模型ID会出现预期之外的行为：

1. 在注册服务时通过 AddChatClient 方法设置默认模型ID
2. 在运行时通过 ChatOptions 参数或 ConfigureOptions 配置模型ID

测试表明，运行时设置的模型ID会被忽略，系统始终使用注册时设置的默认模型ID。这与 AzureAIInference 库的行为形成鲜明对比，后者会正确识别并优先使用运行时指定的模型ID。

技术原理分析

深入代码实现可以发现，这两个库采用了不同的处理逻辑：

OpenAI 客户端库的实现中，ChatOptions 的 ModelId 属性没有被映射到实际的请求参数中。查看 OpenAIModelMapper.ChatCompletion.cs 文件中的转换逻辑，确实缺少对 ModelId 的映射处理。

相比之下，AzureAIInference 客户端库明确实现了模型ID的优先级逻辑：运行时 ChatOptions 中的 ModelId 会覆盖注册时设置的默认值。这通过条件判断和参数传递的机制实现，确保了灵活性。

解决方案建议

对于需要动态切换模型的应用场景，推荐采用以下方案：

1. 优先考虑使用 Microsoft.Extensions.AI.AzureAIInference 库，它提供了完整的模型ID覆盖支持
2. 如果必须使用 OpenAI 库，可以通过创建多个 IChatClient 实例来实现不同模型的调用
3. 对于自定义需求，可以考虑实现自己的 IChatClient 包装器，添加模型切换逻辑

最佳实践

在实际项目开发中，建议：

• 明确区分基础模型和业务逻辑的配置层级
• 对于生产环境，建立模型版本管理的规范流程
• 在单元测试中验证模型切换行为是否符合预期
• 考虑使用策略模式来封装不同模型的调用逻辑

总结

这个案例展示了不同AI服务客户端库在实现细节上的差异。理解这些差异有助于开发者做出更合理的技术选型，并设计出更健壮的应用架构。随着AI技术的快速发展，保持对底层实现的关注将帮助开发者更好地应对各种业务场景需求。