Document VADD EF option.

This commit is contained in:
antirez 2025-01-28 08:39:20 +01:00
parent 5c23f59ee3
commit 5c8097c2de
2 changed files with 5 additions and 3 deletions

View File

@ -24,6 +24,7 @@ The execute the tests with:
**VADD: add items into a vector set**
VADD key [REDUCE dim] FP32|VALUES vector element [CAS] [NOQUANT] [BIN]
[EF build-exploration-factor]
Add a new element into the vector set specified by the key.
The vector can be provided as FP32 blob of values, or as floating point
@ -43,9 +44,11 @@ The `NOQUANT` option forces the vector to be created (in the first VADD call to
The `BIN` option forces the vector to use binary quantization instead of int8. This is much faster and uses less memory, but has impacts on the recall quality.
The `EF` option plays a role in the effort made to find good candidates when connecting the new node to the existing HNSW graph. The default is 200. Using a larger value, may help to have a better recall. To improve the recall it is also possible to increase `EF` during `VSIM` searches.
**VSIM: return elements by vector similarity**
VSIM key [ELE|FP32|VALUES] <vector or element> [WITHSCORES] [COUNT num] [EF exploration-factor]
VSIM key [ELE|FP32|VALUES] <vector or element> [WITHSCORES] [COUNT num] [EF search-exploration-factor]
The command returns similar vectors, in the example instead of providing a vector using FP32 or VALUES (like in `VADD`), we will ask for elements associated with a vector similar to a given element already in the sorted set:

3
vset.c
View File

@ -1086,8 +1086,7 @@ size_t VectorSetMemUsage(const void *value) {
size += sizeof(*node) * vset->hnsw->node_count;
/* Vector storage. */
uint64_t vec_storage = vset->hnsw->vector_dim;
if (vset->hnsw->quant_type == HNSW_QUANT_NONE) vec_storage *= 4;
uint64_t vec_storage = hnsw_quants_bytes(vset->hnsw);
size += vec_storage * vset->hnsw->node_count;
/* Layers array. We use 1.33 as average nodes layers count. */