Closed stevetracvc closed 10 months ago
I decided to try this with v2.2, and search appears to work fine. So this does seem like a bug in 2.3
for cosine metrics this is not supported. We will support it soon
/assgin @liliu-z
@xiaofan-luan oh wow, yes I think dropping the COSINE index and adding an IP index worked.
Is there any particular reason why? Anything I can do to help? I'm new to this software so I don't know the codebase at all, but if you have an idea of where I should look, I might be able to help.
@xiaofan-luan oh wow, yes I think dropping the COSINE index and adding an IP index worked.
Is there any particular reason why? Anything I can do to help? I'm new to this software so I don't know the codebase at all, but if you have an idea of where I should look, I might be able to help.
This is due to the implementation. We are targeting at support this feature soon in 2.3.2
close for now as comments above
keep it until done
/assign
Is this fixed in version 2.3.2 npm pacakge?
@chathushka1996 I thought they're only on a server release version of 2.3.0.
Either way, if your vectors are normalized, IP and cosine are the same thing. Inner Product is just the dot product, which is ||A|| ||B|| cos(theta). If your vectors are normalized then ||A|| == ||B|| == 1 (or very very close with floating point errors).
IP indexes work, cosine indexes don't. So if you can normalize your vectors (if they aren't already), then you can drop the cosine index and replace it with an IP index and everything should work fine.
@chathushka1996 Yes, this will be in 2.3.2
And thanks @stevetracvc for this explanation. After normalization, you can feel free to use either IP or L2 as distance to get correct Cosine topK. One more thing need to be careful is that normed-IP distance is exactly Cosine distance form numeric perspective but L2 is not. So IP is recommended to bypass this for now.
Does we have any mention to this limitation in the docs ? I didn’t found anything about it
Does we have any mention to this limitation in the docs ? I didn’t found anything about it
this is mentioned in knowhere release note. Again this shouldn't be happend and we already worked on fixing it
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Rotten issues close after 30d of inactivity. Reopen the issue with /reopen
.
mark
this was already supported, please try Milvus 2.3.12
Is there an existing issue for this?
Environment
Current Behavior
If I insert more than 40,000 records, then I can no longer query and request the embedding vectors. I instead get the following error in my python script:
RPC error: [query], <MilvusException: (code=1, message=failed to query: attempt #0: failed to search/query delegator 19 for channel by-dev-rootcoord-dml_8_444129503507318440v1: fail to Query, QueryNode ID = 19, reason=failed to query channel, err=worker(19) query failed: vector output fields for IVF_FLAT index is not allowed: attempt #1: no available shard delegator found: service unavailable)>, <Time:{'RPC start': '2023-09-09 07:45:03.329872', 'RPC error': '2023-09-09 07:45:04.449479'}> Traceback (most recent call last):
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/spyder_kernels/customize/spydercustomize.py:473 in exec_code exec_fun(compile(ast_code, filename, 'exec'), ns_globals, ns_locals)
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/spyder_kernels/py3compat.py:356 in compat_exec exec(code, globals, locals)
File /mnt/TRAC/TRAC-confidential-ML/machine-learning/PB-timeseries/industry_embeddings/milvus_test.py:94 res = collection.query(
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/orm/collection.py:912 in query return conn.query(
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:127 in handler raise e from e
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:123 in handler return func(*args, **kwargs)
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:162 in handler return func(self, *args, **kwargs)
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:102 in handler raise e from e
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:68 in handler return func(*args, **kwargs)
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/client/grpc_handler.py:1350 in query raise MilvusException(response.status.error_code, response.status.reason)
MilvusException: <MilvusException: (code=1, message=failed to query: attempt #0: failed to search/query delegator 19 for channel by-dev-rootcoord-dml_8_444129503507318440v1: fail to Query, QueryNode ID = 19, reason=failed to query channel, err=worker(19) query failed: vector output fields for IVF_FLAT index is not allowed: attempt #1: no available shard delegator found: service unavailable)>
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/spyder_kernels/py3compat.py:356 in compat_exec exec(code, globals, locals)
File /mnt/TRAC/TRAC-confidential-ML/machine-learning/PB-timeseries/industry_embeddings/milvus_test.py:94 res = collection.query(
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/orm/collection.py:912 in query return conn.query(
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:127 in handler raise e from e
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:123 in handler return func(*args, **kwargs)
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:162 in handler return func(self, *args, **kwargs)
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:102 in handler raise e from e
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/decorators.py:68 in handler return func(*args, **kwargs)
File ~/miniconda3/envs/milvus/lib/python3.9/site-packages/pymilvus/client/grpc_handler.py:1350 in query raise MilvusException(response.status.error_code, response.status.reason)
MilvusException: <MilvusException: (code=1, message=failed to query: attempt #0: failed to search/query delegator 19 for channel by-dev-rootcoord-dml_8_444129503507318440v1: fail to Query, QueryNode ID = 19, reason=failed to query channel, err=worker(19) query failed: vector output fields for IVF_FLAT index is not allowed: attempt #1: no available shard delegator found: service unavailable)>
Expected Behavior
Once I insert vectors, I should be able to retrieve them at a later date. Maybe I'm missing the point of how this software is supposed to work. I saw #24822 and #24409 which are both closed, but I don't understand the reasoning.
Currently, you cannot search the vectors without providing a vector. I've seen that you're working on allowing vector searches by primary key (ie, specify the primary key in the search rather than the query, so that the database will query the vector and then do the search, all on the server side). But this should imply that it currently is possible to retrieve a vector from the database (eg, query by primary key), then feed it back to the database for a vector search. Even the tutorials show that this is supposed to be possible, and indeed, it works until you insert too many records. https://milvus.io/docs/v2.0.x/query.md shows that boon_intro, a vector, can be retrieved.
Steps To Reproduce
the following code is pieced together from the official tutorial pages, my only change is increasing the number of records created and inserted. If you change the number of insert iterations to 2 in the insert_data section, then the final query works. If you put it at 3 or larger, it doesn't work. I've also tried with different numbers of shards and that doesn't seem to change anything.