Microsoft Semantic Kernel中向量存储集合命名的演进与优化

在Microsoft Semantic Kernel项目的开发过程中，团队对向量数据存储(MEVD)模块的API命名进行了深入讨论和优化。本文将详细介绍这一演进过程及其背后的技术考量。

原始命名方案的问题

最初的设计采用了IVectorStoreRecordCollection作为核心接口名称，这种命名方式在实际使用中暴露出几个明显问题：

1. 名称冗长：特别是当与具体实现类结合时，如SqlServerVectorStoreRecordCollection，名称变得异常冗长，影响代码可读性。

2. 概念混淆：从命名上看，SomethingCollection通常表示"某物的集合"，但这里既没有IVectorStoreRecord类型，也没有VectorStoreRecord类型，导致概念上的不一致。

3. 使用不便：长名称增加了开发者的输入负担，特别是在需要频繁引用这些类型时。

命名方案的优化讨论

团队考虑了多种替代方案，每种方案都有其优缺点：

1. IVectorStoreCollection方案：

   • 优点：名称缩短，去除了冗余的"Record"
   • 缺点：可能被误解为"向量存储的集合"(即多个向量数据库)，而非"向量数据库中的集合"

2. IRecordCollection方案：

   • 优点：名称极短
   • 缺点：过于通用，无法体现与向量数据库的关联

3. IVectorRecordCollection方案：

   • 优点：长度适中，明确包含"向量"概念，准确表达"向量记录的集合"这一含义
   • 缺点：相比原始名称，概念表达略有变化

4. IVectorStoreRecords方案：

   • 优点：名称简洁
   • 缺点：使用复数形式作为类型名不符合.NET命名惯例

最终决策与技术实现

经过充分讨论，团队最终选择了IVectorRecordCollection作为最佳方案。这一决定基于以下技术考量：

1. 准确性：新名称准确反映了该接口表示的是"向量记录的集合"这一核心概念。

2. 一致性：符合.NET框架的命名规范和惯例。

3. 实用性：在保持概念清晰的同时，显著缩短了名称长度，提高了开发效率。

4. 兼容性：通过使用[Obsolete]属性标记旧类型，确保平滑过渡，同时提供清晰的迁移指引。

对开发体验的影响

这一变更与项目中的其他重大变更(如添加必需的Top参数、弃用VectorizedSearchAsync等)同步进行，将开发者的迁移成本降至最低。名称优化后：

• 类型名称更简洁，如CosmosMongoVectorStoreCollection比原来的AzureCosmosDBMongoDBVectorStoreRecordCollection更易读易写
• 概念层次更清晰，减少了命名带来的认知负担
• 与其他API变更一起处理，避免了多次迁移的需要

总结

Microsoft Semantic Kernel团队对向量存储集合命名的优化，体现了对API设计细节的严谨态度和对开发者体验的高度重视。通过平衡命名的准确性、简洁性和一致性，最终选择了IVectorRecordCollection这一既保持概念清晰又便于使用的方案，为开发者提供了更优质的编程体验。