You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For radial search, we added max_distance and min_score parameters to specify that we should fetch all results from the ANN index within that threshold. This is then limited by the size parameter for how many results are returned.
I think we should separate this functionality into its own query that looks something like:
For the k-NN query, we can keep the score/distance thresholds, but for these, the user would still need to specify k as the max number of neighbors and then we would do the distance filter after. So, k would just mean, return up to k results.
The reason I think that they should be separate queries is that they are separate problems with different solution requirements and keeping them under the same query type is misleading and potentially limiting from an implementation standpoint. Radial queries should be built to support a large number of potential matches, while k-NN queries have a hard limit on the total number of results to be returned. Thus, they should be housed under different query types.
The text was updated successfully, but these errors were encountered:
Description
For radial search, we added
max_distance
andmin_score
parameters to specify that we should fetch all results from the ANN index within that threshold. This is then limited by the size parameter for how many results are returned.I think we should separate this functionality into its own query that looks something like:
For the k-NN query, we can keep the score/distance thresholds, but for these, the user would still need to specify k as the max number of neighbors and then we would do the distance filter after. So, k would just mean, return up to k results.
The reason I think that they should be separate queries is that they are separate problems with different solution requirements and keeping them under the same query type is misleading and potentially limiting from an implementation standpoint. Radial queries should be built to support a large number of potential matches, while k-NN queries have a hard limit on the total number of results to be returned. Thus, they should be housed under different query types.
The text was updated successfully, but these errors were encountered: