基于ElasticSearch8向量查询优化-二
方式一VS方式二VS方式三
上一篇文章说到,方式一查询向量时,一阵阵失灵,相同的文本输出,方式一的查询效果不如方式一好,于是就改成了方式二(欧氏距离),当系统运行一段时间后,数据量大了,方式二查询变得特别慢,因为方式二是暴力计算,准确度是有了,响应时间确变长了,于是又优化了一版方式三
方式三详情
bash
POST /indexName/_search?typed_keys=true
{
"query": {
"knn": {
"field": "embedding",
"query_vector": [
-0.0009937286,
0.011650085,
-0.02722168,
-0.0009188652,
-0.009391785,
-0.003255844,
-0.02809143,
0.046142578,
这里是1024个浮点小数
......
],
"num_candidates": 200,
"k": 10,
"filter": [
{
"bool": {
"minimum_should_match": "1",
"must": [
{
"term": {
"tenant_id": {
"value": "123456"
}
}
}
],
"should": [
{
"terms": {
"file_id": [
"5646",
"465",
"65465456"
]
}
}
]
}
}
]
}
},
"sort": [
{
"_score": {
"order": "desc"
}
}
]
}
方式二 vs 方式三
因为ES底层对knn查询做过专门的优化,方式三将过滤条件放在了knn查询里面,效率立马上来了,
方式一也是knn查询,那为啥不行呐,看一下方式一的查询
bash
POST /indexName/_search?typed_keys=true
{
"query": {
"bool": {
"filter": [
{
"term": {
"tenant_id": {
"value": "666"
}
}
},
{
"bool": {
"should": [
{
"terms": {
"file_id": [
"123456"
]
}
}
]
}
}
],
"must": [
{
"knn": {
"field": "embedding",
"query_vector": [
-0.0009937286,
0.011650085,
-0.02722168,
-0.0009188652,
-0.009391785,
.......
],
"num_candidates": 200,
"k": 10
}
}
]
}
},
"sort": [
{
"_score": {
"order": "desc"
}
}
]
}
方式一俗称"后过滤",是先用knn查询方式在图上找寻目标数据,等到找到num_candidates 条数后,然后再过滤条件,这样有极大的可能性将目标数据给过滤走了,这也是方式一查询"时令时不灵的原因所在"