Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend the test coverage of FaissIVFIndex #13300

Closed
wants to merge 1 commit into from

Conversation

ltamasi
Copy link
Contributor

@ltamasi ltamasi commented Jan 15, 2025

Summary: The patch adds a new unit test for FaissIVFIndex that compares its results with a regular in-memory FAISS index. Specifically, it trains two identical IVF indices using the same training vectors, passes the ownership of one to FaissIVFIndex, adds the same set of database vectors to both, and then queries them using the same query vectors (with a variety of values for number of neighbors and number of probes).

Differential Revision: D68233815

@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D68233815

Copy link
Contributor

@jaykorean jaykorean left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!


if (std::from_chars(key.data(), key.data() + key.size(), id).ec !=
std::errc()) {
return -1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: wondering if we would want to use a different value for this case

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our database vectors are numbered from 0 to 4095, so I think -1 works for signaling error for the purposes of the test, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry, I should have elaborated here little bit. What I meant is the following

The default value we set for ids vector below is -1. std::vector<faiss::idx_t> ids(neighbors, -1);

If ith query search in FAISS gets nothing. But for whatever reason, we somehow have a key in the DB for ith iteration, but std::from_chars() failed for that key to get the id.

In that case ASSERT_EQ(get_id(), ids[num_found]); will not throw. (This test would still fail for num_found comparison in this case I guess)

This is going to be a rare or nearly impossible scenario, but just wanted to explain what I meant by my nit comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That case would have been caught by ASSERT_EQ(num_found, num_found_cmp); with the earlier code but I added a couple more assertions to make this clearer

ltamasi added a commit to ltamasi/rocksdb that referenced this pull request Jan 16, 2025
Summary:

The patch adds a new unit test for `FaissIVFIndex` that compares its results with a regular in-memory FAISS index. Specifically, it trains two identical IVF indices using the same training vectors, passes the ownership of one to `FaissIVFIndex`, adds the same set of database vectors to both, and then queries them using the same query vectors (with a variety of values for number of neighbors and number of probes).

Reviewed By: jaykorean

Differential Revision: D68233815
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D68233815

Summary:

The patch adds a new unit test for `FaissIVFIndex` that compares its results with a regular in-memory FAISS index. Specifically, it trains two identical IVF indices using the same training vectors, passes the ownership of one to `FaissIVFIndex`, adds the same set of database vectors to both, and then queries them using the same query vectors (with a variety of values for number of neighbors and number of probes).

Reviewed By: jaykorean

Differential Revision: D68233815
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D68233815

@facebook-github-bot
Copy link
Contributor

This pull request has been merged in 77d4663.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants