ASP.NET Extensions项目中的AI评估缓存机制优化分析

在ASP.NET Extensions项目的AI评估模块中，开发团队最近发现了一个影响团队协作场景下缓存有效性的设计问题。这个问题涉及到MEAI.Evaluation.Reporting组件中缓存键的生成逻辑，特别是在分布式团队开发环境中的实际应用场景。

问题背景

在AI评估流程中，系统会缓存LLM（大语言模型）的调用结果以提高后续评估效率。原始实现中，缓存键包含了ChatClientMetadata.ProviderUri（提供者URI）作为组成部分。这种设计在单机开发环境下工作正常，但在团队协作场景中却带来了显著的不便。

团队开发场景的痛点

当开发团队希望将LLM调用缓存纳入版本控制系统时，包含提供者URI的缓存键会导致以下问题：

1. 每个开发者使用不同的Azure OpenAI部署端点，导致相同的查询会产生不同的缓存键
2. CI/CD流水线中可能根本不配置任何端点，导致完全无法利用缓存
3. 团队成员无法共享缓存结果，失去了版本控制缓存的核心价值

技术实现分析

在原始实现中，ReportingConfiguration.cs文件中的GetCachingKeysForChatClient方法显式地将ProviderUri包含在缓存键中。这种设计原本的考虑是确保当用户切换不同端点时，系统能够识别这一重大变更并丢弃旧的缓存条目。

然而，这种设计忽略了团队协作场景下的实际需求。开发者更希望的是：

• 基于代码变更而非基础设施差异来管理缓存有效性
• 能够在团队间共享缓存结果
• 在CI环境中完全不依赖实际LLM服务的情况下运行测试

解决方案演进

经过团队讨论，决定对缓存键生成逻辑进行以下优化：

1. 从默认缓存键中移除ProviderUri
2. 保留providerName和modelId作为缓存键组成部分
3. 通过现有的cachingKeys扩展机制，允许需要严格区分端点的场景自定义缓存键

这种改进方案既满足了团队开发的需求，又保持了足够的灵活性。需要特别注意端点差异的场景仍然可以通过自定义缓存键来实现特殊处理。

对开发实践的影响

这一变更将显著改善以下开发场景：

• 团队可以安全地将LLM调用缓存提交到版本控制系统
• CI/CD流水线可以在无AI服务凭证的情况下运行测试
• 开发者只需等待真正受代码变更影响的LLM调用
• 团队可以通过PR流程确保缓存与代码变更同步更新

最佳实践建议

基于这一改进，建议开发团队：

1. 将评估缓存目录纳入版本控制
2. 在CI配置中明确不设置AI服务凭证
3. 通过PR流程确保缓存更新与代码变更同步
4. 对于特殊需要区分端点的场景，使用自定义缓存键机制

这一改进体现了ASP.NET Extensions项目对实际开发场景的深入理解和对开发者体验的持续优化，将显著提升团队在AI集成开发中的效率。