Solr 8.5.2稠密向量检索实现技术咨询

针对你在Solr 8.5.2中实现稠密向量检索的需求，我来逐个解答你的疑问：

1. 向量字段类型的选择 #

带docValues的多值整数字段不是最优选择，原因有两点：

• 稠密向量通常是浮点型（float/double），用整数存储会丢失精度，直接影响后续相似度计算的准确性；
• 整数类型的向量无法很好适配Solr的dotProduct或cosinSimilarity函数对浮点运算的需求。

最优的方案是使用多值浮点型字段并开启docValues，具体配置示例如下：

<!-- 定义浮点向量字段类型 -->
<fieldType name="float_vector" class="solr.TrieFloatField" multiValued="true" docValues="true" />
<!-- 定义vectorForm字段 -->
<field name="vectorForm" type="float_vector" indexed="false" stored="true" />

这里设置indexed="false"是因为我们不需要对向量做传统的倒排索引，docValues="true"是为了让Solr能高效地读取向量值进行计算，避免全量加载文档存储内容带来的性能损耗。如果你的向量精度要求更高，可以把TrieFloatField换成TrieDoubleField。

2. 高效实现向量检索（降低延迟） #

由于Solr 8.5.2还没有内置近似最近邻（ANN）检索功能（该功能从8.6版本开始引入HNSW算法支持），所以当前只能基于全量计算优化，建议从以下几点入手：

• 先过滤再计算：如果查询有其他业务过滤条件（比如分类、时间范围），优先用这些条件缩小文档范围，减少需要计算向量相似度的文档数量；
• 确保docValues加载到内存：给Solr分配足够的堆内存，让向量字段的docValues能完全加载到内存中，这会大幅提升向量读取和计算的速度；
• 限制返回行数：你只需要前100条结果，一定要设置rows=100，Solr会在排序阶段提前终止不必要的计算；
• 向量归一化预处理：如果使用余弦相似度，提前对存储的向量和查询向量做归一化处理，这样余弦相似度的计算就等价于点积计算，减少一次除法运算的开销；
• 降低向量维度：在业务允许的前提下，尽量降低向量的维度，维度越少，单文档的计算耗时就越短。

如果你的数据量很大（比如百万级以上），全量计算的延迟可能还是无法满足需求，这种情况下建议升级到Solr 8.6+版本，借助HNSW的近似检索实现毫秒级的向量查询。

3. dotProduct和cosinSimilarity函数的使用 #

这两个函数完全可以满足你的需求，核心思路是：用函数实时计算每个文档的向量与查询向量的相似度，然后按相似度降序排序取前100条。

dotProduct（点积）示例查询 #

假设你的查询向量是[0.12, 0.34, 0.56, ..., 0.98]（维度要和vectorForm字段的向量维度一致），查询语句如下：

q=*:*
&fl=id,title,dotProduct(vectorForm, [0.12,0.34,0.56,...,0.98]) as similarity
&sort=similarity desc
&rows=100

• fl参数指定返回的字段，同时用dotProduct计算相似度并命名为similarity；
• sort=similarity desc表示按相似度从高到低排序；
• 如果有业务过滤条件，把q=*:*换成对应的查询语句即可（比如q=category:electronics）。

cosinSimilarity（余弦相似度）示例查询 #

如果需要用余弦相似度，只需把函数换成cosinSimilarity即可：

q=*:*
&fl=id,title,cosinSimilarity(vectorForm, [0.12,0.34,0.56,...,0.98]) as similarity
&sort=similarity desc
&rows=100

注意：如果你的向量没有做归一化，余弦相似度的计算会比点积多一步模长除法，耗时略高；如果已经归一化，两者的计算结果完全一致，排序效果也相同。

内容的提问来源于stack exchange，提问作者Aks