Microsoft Semantic Kernel中向量存储接口向抽象基类的演进

在Microsoft Semantic Kernel项目的开发过程中，团队正在考虑将MEVD(Managed Extensions for Vector Data)模块中的两个核心类型——IVectorStore和IVectorStoreRecordCollection——从接口(interface)改为抽象基类(abstract base class)。这一架构调整反映了.NET生态系统中API设计的最佳实践演进。

设计变更的背景与动机

最初的设计采用接口主要是为了支持某些连接器实现多次实现同一接口的场景。例如QdrantVectorStoreRecordCollection曾经需要同时实现IVectorStoreRecordCollection两次，分别针对Guid和ulong两种键类型。但随着项目发展，团队转向了更优雅的解决方案——使用泛型类型参数，这使得接口的多重实现不再必要。

更重要的考虑是长期API设计的灵活性。抽象基类相比接口有几个显著优势：

1. 版本兼容性：抽象基类允许在未来添加带有默认实现的新方法，而不会破坏现有实现。这一点在System.Data命名空间的演变中已经得到验证——最初基于接口(IDbConnection等)，后来转向抽象基类(DbConnection等)。

2. 默认实现：基类可以提供一些方法的默认实现，例如CreateCollectionIfExists可以基于存在性检查和创建操作的组合来实现。

3. 未来扩展：特别是对于NativeAOT/trimming场景，团队预见需要添加新的API来安全地实例化集合，这可能需要接受源生成(source-generated)的构件。抽象基类为这种尚未完全确定形态的API提供了更灵活的扩展点。

技术实现的考量

在具体实现上，团队已经解决了最初导致接口设计的多重实现问题。现在的QdrantVectorStoreRecordCollection采用泛型设计，键类型作为类型参数，无效键会在运行时抛出错误而非编译时。这种设计不仅支持动态场景(object键)，还改善了开发体验——之前的多重接口实现需要显式接口实现，增加了代码复杂度。

对开发者生态的影响

这一变更对现有代码的影响相对可控，因为：

1. 大多数消费代码通过工厂方法或依赖注入获取实例，不直接依赖具体实现

2. 抽象基类可以保持与接口相同的公共契约，只是改变了类型层次结构

3. 对于需要自定义实现的场景，从继承抽象基类而非实现接口的转换是机械性的

这种设计演进体现了Microsoft Semantic Kernel团队对长期API稳定性和开发者体验的重视，遵循了.NET生态系统中经过验证的模式，为向量数据管理功能奠定了更可持续的基础。