Spring Data Elasticsearch中KNN查询与搜索的参数分离与重构

在Elasticsearch的Java客户端中，KNN（K-Nearest Neighbors）功能通过两种不同的API实现：KnnSearch和KnnQuery。这两种API分别对应不同的查询场景，但在Spring Data Elasticsearch的当前实现中，它们的参数和功能被混合在一起，最终都被转换为KnnSearch。这种设计可能导致使用上的混淆和功能限制。

KnnSearch与KnnQuery的本质区别

KnnSearch是Elasticsearch请求中的顶层knn查询，它直接作用于整个搜索请求。而KnnQuery则是query子句内部的knn查询，它们有不同的参数和不同的Java类表示。这种区分在Elasticsearch官方文档中有明确说明。

当前实现的问题

在Spring Data Elasticsearch中，这两种查询被统一处理，都转换为KnnSearch。这种设计存在几个问题：

1. 功能边界模糊：将两种不同用途的查询混为一谈，可能导致开发者在使用时产生困惑
2. 参数处理混乱：两种查询有不同的参数集，合并处理可能导致参数传递错误
3. 灵活性受限：开发者无法精确控制查询的构建方式

改进方案

针对这些问题，建议进行以下改进：

1. 移除NativeQuery中的KnnQuery：这部分查询应该由开发者在co.elastic.clients.elasticsearch._types.query_dsl.Query中手动构建
2. 在NativeQueryBuilder中添加withKnnSearches方法：提供构建KnnSearch的标准方式
3. 添加Elasticsearch 8中的knn搜索映射参数：保持与最新版本的兼容性

技术实现考量

这种重构需要考虑几个技术细节：

1. 向后兼容性：确保现有代码不会因为API变更而失效
2. 参数验证：对knn搜索和查询的不同参数集进行正确验证
3. 文档更新：清晰说明两种查询的使用场景和区别

对开发者的影响

这种改进将使API设计更加清晰，让开发者能够：

1. 更精确地控制查询类型
2. 更容易理解不同查询的适用场景
3. 更灵活地构建复杂的搜索请求

总结

通过分离KNN搜索和查询的参数处理，Spring Data Elasticsearch可以提供更符合Elasticsearch原生API的设计，同时提高代码的清晰度和灵活性。这种改进将有助于开发者构建更精确、高效的搜索功能，特别是在需要复杂向量搜索的场景中。