Closed simwijs-evolante closed 1 year ago
Is this still the case? I'm about to re-upsert our vectors to include sparse-dense vectors now, and would love to know if I need to implement @simwijs-evolante's workaround.
This issue isn't resolved so not sure if the maintainers have seen/acknowledged/fixed it. Though there have been 3 new versions since I reported it, it could be fixed, but haven't tested it. I'll comment again if I test it, but the workaround works fine so I'm not very inclined to jump in right away
Is this still the case? I'm about to re-upsert our vectors to include sparse-dense vectors now, and would love to know if I need to implement @simwijs-evolante's workaround.
Is this still the case? I'm about to re-upsert our vectors to include sparse-dense vectors now, and would love to know if I need to implement @simwijs-evolante's workaround.
I looked through the changes in the code from the releases and can't see a test that goes through this edge case I am referring to. Since the upserting sparse values test only checks that it returns matches, and not that the result actually returns sparse values (proving that the sparse values actually are upserted). So this case is not covered by a test as I suggest in the issue.
THe test I am referring to
it('should be able to upsert a vector with sparse values', async () => {
const index = client.Index(indexName)
const upsertRequest: UpsertRequest = {
vectors: vectorsWithSparseValues,
namespace
}
await index.upsert({ upsertRequest }) // <--- this works even though the vectors are not accepting the sparse values
const randomVector = getRandomVector(vectors)
const queryRequest: QueryRequest = {
topK: 1,
vector: randomVector.values,
sparseVector: randomVector.sparseValues,
namespace
}
const queryResponse = await index.query({ queryRequest }) // <--- this also works even though the vectors are not accepting the sparse values
expect(queryResponse?.matches?.length).toBeGreaterThan(0) // <------ here you see it only tests for matches, which goes through, even if the sparse values are not there
})
I just tried on v0.1.6
, seems to work as advertised for me now.
So it seems it's been fixed in one of the versions now. Sweet!
Seems like a previous release resolved this problem so I will mark this issue closed.
You might be interested in checking out the new v1 client for more improvements. Check out the release notes and v1 migration guide to get started using the new client.
Is this a new bug?
Current Behavior
When upserting using
sparseValues
or querying usingsparseVector
according to the docs, the results are not using the sparse values for either endpoint.I noticed the tests simply test if the request is OK, and not actually checking that the values give some sort of different value, which would be more appropriate to check that the sparse values have an effect (which they do). When testing the python client, both upserting and querying works, but the API in this javascript client don't work for either request. I looked through the docs here and tried to find a reason to it in your source code to no avail
Using the Python API (the top 5 vectors have upserted sparse values)
Using the same query using the node API results in a different result (due to it not respecting the sparse values in the query request). See especially the first entry and compare it to the above python output.
Query request in this javascript API is
Upsert request is (unmodified this works fine using REST)
I also tried different naming such as
sparse_vector
orsparse_values
with no success.I made my own workaround for now using REST API using Axios, which works great. I'm using the same request object as I am using in the javascript API here, and the REST API works as expected just as with python.
Expected Behavior
API should respect sparse values in both upsert and query endpoints.
I suggest creating a test to check that the score returned is different when using sparseVector in query vs not using it.
Steps To Reproduce
sparseValues
sparseVector
Steps 3-4 work Steps 2 and 5 don't give the same output as with the python client
Relevant log output
No response
Environment
Additional Context
Awesome library otherwise! It seems to have got quite the traction, so I hope this issue helps. Let me know if you need more context that can help you debug!