Adds support for ef_search query parameter in FAISS engine #1707

shatejas · 2024-05-16T20:24:06Z

Description

This introduces ef_search as a query parameter for search based on hnsw algorithm. This PR has changes for FAISS engine. Support for other engines will be added in consecutive PRs. Radial search support for FAISS will also be added in consecutive PRs. These changes are focused on k based queries.

Issues Resolved

#1537

Local testing

curl -XGET "http://localhost:9200/faiss-hnsw-index/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "knn": {
      "faiss_vector": {
        "vector": [2, 3, 5],
        "k": 2,
        "method_parameters": {
           "ef_search" : 5

          }
        }
      }
    }
  }'

{
  "took": 69,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 0.11918951,
    "hits": [
      {
        "_index": "faiss-hnsw-index",
        "_id": "3",
        "_score": 0.11918951,
        "_source": {
          "faiss_vector": [
            3.5,
            4.5,
            3.3
          ],
          "price": 12.9
        }
      },
      {
        "_index": "faiss-hnsw-index",
        "_id": "2",
        "_score": 0.10706638,
        "_source": {
          "faiss_vector": [
            2.5,
            3.5,
            2.2
          ],
          "price": 7.1
        }
      }
    ]
  }
}

Check List

New functionality includes testing.
- All tests pass
New functionality has been documented. - pending documentation
- [] New functionality has javadoc added - added wherever I felt required. open to feedback and I can add it
Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: Tejas Shah <[email protected]>

jni/src/faiss_wrapper.cpp

src/main/java/org/opensearch/knn/index/query/KNNQueryBuilder.java

jni/include/faiss_wrapper.h

Vikasht34 · 2024-05-16T22:26:12Z

jni/src/faiss_wrapper.cpp

-            hnswParams.efSearch = hnswReader->hnsw.efSearch;
-            idGrouper = buildIDGrouperBitmap(jniUtil, env, parentIdsJ, &idGrouperBitmap);
-            hnswParams.grp = idGrouper.get();
+        if(hnswReader!= nullptr) {


Did we test with cases what happnes when hnswReader is not null and parentIdsJ is Null and vice versa , I feel earlier condition was fine to check both not null. And Can we add test case for all Corner cased like when one is null and other is not , just to make sure it works , Since we are removing one condition from Top If Statment.

With the earlier condition efSearch was not getting updated and it was using the default value of 16 with the combination of filter and parent filter being null. I will let others evaluate this

As mentioned, still working on the unit test

src/main/java/org/opensearch/knn/index/query/KNNQuery.java

src/main/java/org/opensearch/knn/index/query/KNNQueryBuilder.java

src/main/java/org/opensearch/knn/jni/FaissService.java

src/main/java/org/opensearch/knn/jni/JNIService.java

src/main/java/org/opensearch/knn/index/query/KNNQueryFactory.java

methods This unit test specifically focuses on the changes related to ef_search Detailed assertions related to grouper and selector can be picked up later. Tests related to any other methods are not added Signed-off-by: Tejas Shah <[email protected]>

compatibility during upgrades Signed-off-by: Tejas Shah <[email protected]>

Signed-off-by: Tejas Shah <[email protected]>

state Customers are not expected use the query with new parameters unless its fully upgraded. Signed-off-by: Tejas Shah <[email protected]>

This makes sure that bwc passes in the PR. will be changed to 2.15 to once this is merged to 2.x Signed-off-by: Tejas Shah <[email protected]>

Signed-off-by: Tejas Shah <[email protected]>

src/main/java/org/opensearch/knn/common/KNNConstants.java

qa/rolling-upgrade/src/test/java/org/opensearch/knn/bwc/QueryANNIT.java

Signed-off-by: Tejas Shah <[email protected]>

jmazanec15 · 2024-05-30T14:43:59Z

I don't think I would prefer a string to object map, a typed structure is easy to work with. Moreover the primary objective was to not have the parameters cluttered. This encapsulation makes sure of that, the map introduces a possibility of getting abused in the future.

Right, Im on the fence about this - mainly because it leads to more complex interactions with objects from the C++ layer. But, Im good with this approach for now.

For separation of responsibilites, I meant delegate handling of parsing to the method in the engine. For instance, do something like Faiss.parseSearchParameters(KNNMethodContext, ThingToParse) -> return SearchParameters and pass it down the chain of abstractions.

This way, we can encapsulate the search time parameters with the engine/method combo. Some day, we may pull the engines out and make them pluggable/more extendable. So, Im thinking that it would be better to have this logic encapsulated there. In the end, the KNNMethod is the right place to define the search time parameters. Thats where other parameters are already defined.

navneet1v

Completed my first pass on the src files. There are some good abstractions that have been added. I am seeing intensive use of streams and optionals. I personally feel we can avoid those things as search path of k-NN is very sensitive and these smaller abstractions of optional and stream adds latencies when called enough number of times doesn't matter from where they get called from.

navneet1v · 2024-05-16T23:33:38Z

src/test/java/org/opensearch/knn/index/FaissHNSWFlatE2EIT.java

+import static org.opensearch.knn.common.KNNConstants.*;
+
+@AllArgsConstructor
+public class FaissHNSWFlatE2EIT extends KNNRestTestCase {


why we need another IT class?

To make it parametrized. I really hate copy pasting tests - one change can potentially fail many tests and as side effect we need to change all the tests.

Since the plugin is not on junit 5 combined with the use of carrot search we can't use the same class to have parametrized tests. we need a separate class per test but we can add multiple test cases in there

navneet1v · 2024-05-31T00:58:53Z

src/main/java/org/opensearch/knn/index/query/parser/KNNXParserUtil.java

+import static org.opensearch.knn.common.KNNConstants.METHOD_PARAMETER_EF_SEARCH;
+import static org.opensearch.knn.index.query.KNNQueryBuilder.NAME;
+
+public final class KNNXParserUtil {


This is a good abstraction. I like this.

navneet1v · 2024-05-31T00:59:28Z

src/main/java/org/opensearch/knn/common/KNNConstants.java

@@ -25,6 +25,7 @@ public class KNNConstants {
    public static final String VECTOR = "vector";
    public static final String K = "k";
    public static final String TYPE_KNN_VECTOR = "knn_vector";
+    public static final String METHOD_PARAMETER = "method_parameter";


if this constant is getting used only once, please move this to the file where it is getting used.

navneet1v · 2024-05-31T01:01:20Z

src/main/java/org/opensearch/knn/index/query/parser/MethodParametersParser.java

+
+    private static final Set<String> VALID_METHOD_PARAMETERS = ImmutableSet.of(METHOD_PARAMETER_EF_SEARCH);
+
+    @SneakyThrows(IOException.class)


We don't add SneakyThrows in src code. Better to remove these annotations. You can use it in UTs and ITs.

Even with specific exceptions?....will remove

navneet1v · 2024-05-31T01:03:55Z

src/main/java/org/opensearch/knn/index/query/parser/MethodParametersParser.java

+    private static final Set<String> VALID_METHOD_PARAMETERS = ImmutableSet.of(METHOD_PARAMETER_EF_SEARCH);
+
+    @SneakyThrows(IOException.class)
+    public static AlgoQueryParameters streamInMethodParameters(StreamInput in) {


Here is an interesting choice of naming, we are calling function as streamInMethodParameters and rather then returning method parameters it is returning a class named as AlgoQueryParameters. We should be consistent in terms of what parameters these are. Are they algo related parameters or they are method related parameters. If you think algo and method is same thing, so use consistent naming.

So the thought process was to make sure nothing other than algoquery parameters are there in this. From method parameters discussion things like overscorer can potential fit in method_params but they shouldn't be clubbed and be added under algo params. The naming was chosen keeping in mind that. If something else get added in method params we should think about where to put it rather than using algo params as default. I can take a look at the structure again to see if I can make it more obvious

navneet1v · 2024-05-31T01:10:09Z

src/main/java/org/opensearch/knn/index/query/parser/MethodParametersParser.java

+            }
+        }
+
+        return Optional.ofNullable((Integer) parameters.get(METHOD_PARAMETER_EF_SEARCH))


This good for 1 single attribute. But we might have to add more validations once we have more attributes that are getting parsed. I would recommend adding a todo here to handle that condition.

Yeah the intention is to build on this when nProbs is added

navneet1v · 2024-05-31T01:13:44Z

src/main/java/org/opensearch/knn/index/query/parser/MethodParametersParser.java

+        }
+
+        return Optional.ofNullable((Integer) parameters.get(METHOD_PARAMETER_EF_SEARCH))
+            .filter(ef -> EF_SEARCH_FIELD.match(METHOD_PARAMETER_EF_SEARCH, parser.getDeprecationHandler()))


should we have some checks to ensure that ef_Search is a +ve value. my worry is if some once gives a value which is out of int range we typecasting it to int will lead to negative value. or someone my pass -ve values. So lets ensure we are throwing right exceptions in those cases.

should we have some checks to ensure that ef_Search is a +ve value

+ve check is present here. Overall I would want to decouple parsing and validations moving forward and I have tried to reflect that with ef_search

navneet1v · 2024-05-31T01:14:23Z

src/main/java/org/opensearch/knn/index/query/model/AlgoQueryParameters.java

+ * Functional Interface for algorithm specific parameters.
+ * These parameters are passed to the algorithm implementation while processing a query
+ */
+public interface AlgoQueryParameters {}


Should this be an interface or abstract class? I see this as an abstract class rather than interface.

Abstract classes open up possibility of abusing it for code reuse. Inheritance should only be used to enforce behavior, Composition should be used for code reuse. So default is interface. Abstract classes have limited use cases and they should be used sparingly.

Functional interfaces like these are generally used to have bounds on the type of objects passed and that helps not have type Object in the function signature which can be easily abused.

jni/include/org_opensearch_knn_jni_FaissService.h

navneet1v · 2024-05-31T01:19:22Z

.github/workflows/backwards_compatibility_tests_workflow.yml

@@ -15,7 +15,7 @@ jobs:
      matrix:
        java: [ 11, 17 ]
        os: [ubuntu-latest]
-        bwc_version : [ "2.0.1", "2.1.0", "2.2.1", "2.3.0", "2.4.1", "2.5.0", "2.6.0", "2.7.0", "2.8.0", "2.9.0", "2.10.0", "2.11.0", "2.12.0", "2.13.0", "2.14.0-SNAPSHOT"]
+        bwc_version : [ "2.0.1", "2.1.0", "2.2.1", "2.3.0", "2.4.1", "2.5.0", "2.6.0", "2.7.0", "2.8.0", "2.9.0", "2.10.0", "2.11.0", "2.12.0", "2.13.0", "2.14.0", "2.15.0-SNAPSHOT"]


this could have been added in a different PR. I have raised a PR for this: #1724

This will be removed when I sync my branch

navneet1v · 2024-05-31T01:26:24Z

For separation of responsibilites, I meant delegate handling of parsing to the method in the engine. For instance, do something like Faiss.parseSearchParameters(KNNMethodContext, ThingToParse) -> return SearchParameters and pass it down the chain of abstractions.

I haven't read the whole conversation. But I kind of agree on this part only, its good that we are building an algorithm specific abstraction. But once we have that abstraction we can pass it through 1 more level of check from Engines to see if they don't support a specific parameters they can fail the search call.

Now, should we allow Engines to parse the parameters I would say no. We should give them a parsed object and let them validate it. This will ensure that k-NN plugin controls the interface and engines just do the validation, rather than just giving engines control to define the interface.

shatejas · 2024-05-31T02:15:40Z

Completed my first pass on the src files. There are some good abstractions that have been added. I am seeing intensive use of streams and optionals. I personally feel we can avoid those things as search path of k-NN is very sensitive and these smaller abstractions of optional and stream adds latencies when called enough number of times doesn't matter from where they get called from.

streams I have tried to avoid might have missed it, will take another pass. Optionals are a surprise honestly as they are pretty light weight. I like them because they help avoid branching. Will remove them

Signed-off-by: Tejas Shah <[email protected]>

src/main/java/org/opensearch/knn/index/query/KNNQueryBuilder.java

Signed-off-by: Tejas Shah <[email protected]>

src/test/java/org/opensearch/knn/index/FaissHNSWFlatE2EIT.java

jmazanec15 · 2024-06-05T17:31:06Z

src/main/java/org/opensearch/knn/engine/method/EngineSpecificMethodContext.java

+import java.util.Map;
+
+/**
+ * Holds context related to a method for a particular engine


Currently, this information is stored in a map in the engines. Is the idea to migrate those maps to this abstraction?

Its still a map (see usage in native library) but not declared as a static to better structure and hold all context in one place

Is the idea to migrate those maps to this abstraction?

Yes the intent is that so we can have just one map instead of having multiple maps in knnengine instance. Did not want to club the refactor with this feature. We can build on it and needs a separate PR.

jmazanec15 · 2024-06-05T17:33:35Z

src/main/java/org/opensearch/knn/engine/method/EngineSpecificMethodContext.java

+ *
+ * TODO: Move KnnMethod in here
+ */
+public interface EngineSpecificMethodContext {


What do you think about name MethodImplementationContext?

I really like having "engine/nativelibrary" and "method" both in there to clearly indicate that it shouldn't be used stand alone ideally (this can only be enforced through PRs). Any other suggestions?

I really like having "engine/nativelibrary" and "method" both in there to clearly indicate that it shouldn't be used stand alone ideally

What do you mean by stand alone here?

For instance, I can see someone using it to get HNSW method parameters in universal fashion and plug it somewhere other than engine.

src/main/java/org/opensearch/knn/engine/method/HnswContext.java

src/main/java/org/opensearch/knn/index/query/BaseQueryFactory.java

- Changes HnswContext to DefaultHnswContext - corrects * imports Signed-off-by: Tejas Shah <[email protected]>

Signed-off-by: Tejas Shah <[email protected]>

jmazanec15

From a functionality perspective, I think it looks good. I want to understand a little bit more on where method abstraction refactor is going - it seems partially complete in this PR (which is okay for feature branch). I just want to understand what it will look like in the end. A couple questions:

How will we eventually define supported methods for each engine? Is the plan to move away from current mechanism to new paths.
Will we be moving everything in index.util package to the new engine package?

jmazanec15 · 2024-06-06T02:26:04Z

src/main/java/org/opensearch/knn/index/query/parser/KNNXParserUtil.java

+
+public final class KNNXParserUtil {
+
+    public static Map<String, Object> parseJsonObject(XContentParser parser) throws IOException {


Do we need this if XContentParser has map() method? https://github.com/opensearch-project/OpenSearch/blob/main/libs/core/src/main/java/org/opensearch/core/xcontent/XContentParser.java#L166

Wasn't aware of the map, it pretty much does the same thing except the initial start object check. I will switch to that and delete this file

Making this a part of another PR. Will be done before merging into main

shatejas · 2024-06-06T03:18:32Z

How will we eventually define supported methods for each engine? Is the plan to move away from current mechanism to new paths.

The KNNengine enum which defines the instance is fine, The native library has deep hierarchies which can turn problematic but for now I wouldn't want to remove it. What I would like to see us move away from is giant static maps that are defined in each engine class. Those aren't maintainable and hard to follow. I am trying to structure it in a way that these are more manageable at the same time easy to use. I will give psuedocode for FAISS maybe on how the final structure would look like

class FAISS extends NativeLibrary {

     // singleton
     Map<String, EngineSpecificeMethodContext> methodContext = Map.of("hnsw", new FaissHnswContext(), "ivf", new FaissIVFContext());

//other engine specific stuff
}

FaissHnswContext.java

class FaissHnswContext implements EngineSpecificMethodContext {

      //singleton
      KNNMethod supportedMethodComponents();
      Map<String, Parameter> supportedMethodParameters();
      //anything that is unique to engine and method specific that comes around maybe supportedQuantization() ? I know its encapsulated in knnmethod but just to give you an idea

}

ofcourse for reusability we can have something like DefaultHNSWContext. Again this is not set in stone and have tried to structure with the limited context I have. I am open to suggestions here.

Will we be moving everything in index.util package to the new engine package?

The package structure isn't intuitive right now and sure if it makes more sense we can move it

jmazanec15 · 2024-06-06T14:56:29Z

What I would like to see us move away from is giant static maps that are defined in each engine class.

+1 want to remove this. I would like to move these to classes eventually.

The package structure isn't intuitive right now and sure if it makes more sense we can move it

Right, this is overdue for refactor.

I think the long term potential goal is to encapsulate this information in a strong interface so that backend method/implementation can be easily extended by a third-party.

…h-project#1707) * Adds support for ef_search as a query parameter in faiss engine Signed-off-by: Tejas Shah <[email protected]> * Fixing checkstyle Signed-off-by: Tejas Shah <[email protected]> * Corrects imports Signed-off-by: Tejas Shah <[email protected]> * Adds unit test for faiss_wrapper for queryIndex and queryIndexWithFilter methods This unit test specifically focuses on the changes related to ef_search Detailed assertions related to grouper and selector can be picked up later. Tests related to any other methods are not added Signed-off-by: Tejas Shah <[email protected]> * Gates efSearch behind 2.15 version to make sure there is backward compatibility during upgrades Signed-off-by: Tejas Shah <[email protected]> * Adds faiss_wrapper_unit_test.cpp in CmakeList Signed-off-by: Tejas Shah <[email protected]> * Adds change log Signed-off-by: Tejas Shah <[email protected]> * Adds BWC tests for efSearch Signed-off-by: Tejas Shah <[email protected]> * Removes EfSearch validation from rolling upgrade test for Mixed cluster state Customers are not expected use the query with new parameters unless its fully upgraded. Signed-off-by: Tejas Shah <[email protected]> * Changing minimum version required for efSearch to be 3.0.0 This makes sure that bwc passes in the PR. will be changed to 2.15 to once this is merged to 2.x Signed-off-by: Tejas Shah <[email protected]> * Fixes the checkstyle failure Signed-off-by: Tejas Shah <[email protected]> * Adds method_parameter in knn search request. method_parameters will be used to hold shard level algorithm parameters Signed-off-by: Tejas Shah <[email protected]> * Updates the documentation for faiss wrapper Signed-off-by: Tejas Shah <[email protected]> * Stubs out method parameter parsing logic into its own class Signed-off-by: Tejas Shah <[email protected]> * Adds method parameters and validates against engine specific parameters Signed-off-by: Tejas Shah <[email protected]> * Removes engine and method functions from EngineSpecificMethodContext Signed-off-by: Tejas Shah <[email protected]> * - Does not throw in case of illegal state exception if method is null - Changes HnswContext to DefaultHnswContext - corrects * imports Signed-off-by: Tejas Shah <[email protected]> --------- Signed-off-by: Tejas Shah <[email protected]>

shatejas added 3 commits May 16, 2024 12:18

Adds support for ef_search as a query parameter in faiss engine

9cc3437

Signed-off-by: Tejas Shah <[email protected]>

Fixing checkstyle

2bf0d9f

Signed-off-by: Tejas Shah <[email protected]>

Corrects imports

49c88ba

Signed-off-by: Tejas Shah <[email protected]>

shatejas requested review from heemin32, navneet1v, VijayanB, vamshin, jmazanec15, naveentatikonda, junqiu-lei, martin-gaievski, ryanbogan and luyuncheng as code owners May 16, 2024 20:24

shatejas commented May 16, 2024

View reviewed changes

jni/src/faiss_wrapper.cpp Show resolved Hide resolved

junqiu-lei reviewed May 16, 2024

View reviewed changes

jni/src/faiss_wrapper.cpp Show resolved Hide resolved

junqiu-lei reviewed May 16, 2024

View reviewed changes

src/main/java/org/opensearch/knn/index/query/KNNQueryBuilder.java Outdated Show resolved Hide resolved

junqiu-lei reviewed May 16, 2024

View reviewed changes

src/main/java/org/opensearch/knn/index/query/KNNQueryBuilder.java Outdated Show resolved Hide resolved

Vikasht34 reviewed May 16, 2024

View reviewed changes

src/main/java/org/opensearch/knn/jni/FaissService.java Outdated Show resolved Hide resolved

src/main/java/org/opensearch/knn/jni/JNIService.java Outdated Show resolved Hide resolved

src/main/java/org/opensearch/knn/index/query/KNNQueryFactory.java Show resolved Hide resolved

shatejas added 8 commits May 19, 2024 16:27

Gates efSearch behind 2.15 version to make sure there is backward

5065709

compatibility during upgrades Signed-off-by: Tejas Shah <[email protected]>

Adds faiss_wrapper_unit_test.cpp in CmakeList

55c6870

Signed-off-by: Tejas Shah <[email protected]>

Adds change log

4423df4

Signed-off-by: Tejas Shah <[email protected]>

Adds BWC tests for efSearch

e041a98

Signed-off-by: Tejas Shah <[email protected]>

Removes EfSearch validation from rolling upgrade test for Mixed cluster

2a0af55

state Customers are not expected use the query with new parameters unless its fully upgraded. Signed-off-by: Tejas Shah <[email protected]>

Changing minimum version required for efSearch to be 3.0.0

d7ce682

This makes sure that bwc passes in the PR. will be changed to 2.15 to once this is merged to 2.x Signed-off-by: Tejas Shah <[email protected]>

Fixes the checkstyle failure

4e6f886

Signed-off-by: Tejas Shah <[email protected]>

shatejas force-pushed the main branch from efdcaf1 to 4e6f886 Compare May 21, 2024 22:15

VijayanB reviewed May 22, 2024

View reviewed changes

src/main/java/org/opensearch/knn/common/KNNConstants.java Outdated Show resolved Hide resolved

VijayanB reviewed May 22, 2024

View reviewed changes

qa/rolling-upgrade/src/test/java/org/opensearch/knn/bwc/QueryANNIT.java Show resolved Hide resolved

Stubs out method parameter parsing logic into its own class

d7bc3ad

Signed-off-by: Tejas Shah <[email protected]>

shatejas requested a review from jmazanec15 May 30, 2024 01:05

navneet1v requested changes May 31, 2024

View reviewed changes

Adds method parameters and validates against engine specific parameters

d663640

Signed-off-by: Tejas Shah <[email protected]>

shatejas force-pushed the main branch from 13161e1 to d663640 Compare June 5, 2024 02:10

shatejas commented Jun 5, 2024

View reviewed changes

src/main/java/org/opensearch/knn/index/query/KNNQueryBuilder.java Outdated Show resolved Hide resolved

shatejas commented Jun 5, 2024

View reviewed changes

src/main/java/org/opensearch/knn/index/query/KNNQueryBuilder.java Outdated Show resolved Hide resolved

shatejas requested review from junqiu-lei and navneet1v June 5, 2024 02:19

Removes engine and method functions from EngineSpecificMethodContext

b726f40

Signed-off-by: Tejas Shah <[email protected]>

ryanbogan reviewed Jun 5, 2024

View reviewed changes

src/test/java/org/opensearch/knn/index/FaissHNSWFlatE2EIT.java Outdated Show resolved Hide resolved

jmazanec15 reviewed Jun 5, 2024

View reviewed changes

src/main/java/org/opensearch/knn/engine/method/HnswContext.java Outdated Show resolved Hide resolved

jmazanec15 reviewed Jun 5, 2024

View reviewed changes

src/main/java/org/opensearch/knn/index/query/BaseQueryFactory.java Show resolved Hide resolved

shatejas added 2 commits June 5, 2024 12:23

- Does not throw in case of illegal state exception if method is null

48c9a6f

- Changes HnswContext to DefaultHnswContext - corrects * imports Signed-off-by: Tejas Shah <[email protected]>

Merge branch 'feature/ef-search' into main

986706b

Signed-off-by: Tejas Shah <[email protected]>

jmazanec15 reviewed Jun 6, 2024

View reviewed changes

jmazanec15 approved these changes Jun 6, 2024

View reviewed changes

jmazanec15 merged commit 5a57a0d into opensearch-project:feature/ef-search Jun 6, 2024
5 of 51 checks passed

This was referenced Jun 7, 2024

Removes KNNXparser and uses map instead #1731

Merged

Adds method_parameters in neural search query to support ef_search opensearch-project/neural-search#787

Merged

heemin32 mentioned this pull request Jun 24, 2024

[FEATURE] Support of dynamic efsearch and nprobs value during search for binary index #1769

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adds support for ef_search query parameter in FAISS engine #1707

Adds support for ef_search query parameter in FAISS engine #1707

shatejas commented May 16, 2024 •

edited

Loading

Vikasht34 May 16, 2024

shatejas May 17, 2024 •

edited

Loading

jmazanec15 commented May 30, 2024

navneet1v left a comment

navneet1v May 16, 2024

shatejas May 31, 2024

navneet1v May 31, 2024

navneet1v May 31, 2024

navneet1v May 31, 2024

shatejas May 31, 2024

navneet1v May 31, 2024

shatejas May 31, 2024 •

edited

Loading

navneet1v May 31, 2024

shatejas May 31, 2024

navneet1v May 31, 2024

shatejas May 31, 2024

navneet1v May 31, 2024

shatejas May 31, 2024

navneet1v May 31, 2024

shatejas Jun 5, 2024

navneet1v commented May 31, 2024

shatejas commented May 31, 2024

jmazanec15 Jun 5, 2024

shatejas Jun 5, 2024

jmazanec15 Jun 5, 2024

shatejas Jun 5, 2024 •

edited

Loading

jmazanec15 Jun 5, 2024

shatejas Jun 5, 2024 •

edited

Loading

jmazanec15 left a comment •

edited

Loading

jmazanec15 Jun 6, 2024

shatejas Jun 6, 2024

shatejas Jun 6, 2024 •

edited

Loading

shatejas commented Jun 6, 2024

jmazanec15 commented Jun 6, 2024


		private static final Set<String> VALID_METHOD_PARAMETERS = ImmutableSet.of(METHOD_PARAMETER_EF_SEARCH);

		@SneakyThrows(IOException.class)


		public final class KNNXParserUtil {

		public static Map<String, Object> parseJsonObject(XContentParser parser) throws IOException {

Adds support for ef_search query parameter in FAISS engine #1707

Adds support for ef_search query parameter in FAISS engine #1707

Conversation

shatejas commented May 16, 2024 • edited Loading

Description

Issues Resolved

Local testing

Check List

Choose a reason for hiding this comment

shatejas May 17, 2024 • edited Loading

Choose a reason for hiding this comment

jmazanec15 commented May 30, 2024

navneet1v left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shatejas May 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

navneet1v commented May 31, 2024

shatejas commented May 31, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shatejas Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shatejas Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

jmazanec15 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shatejas Jun 6, 2024 • edited Loading

Choose a reason for hiding this comment

shatejas commented Jun 6, 2024

jmazanec15 commented Jun 6, 2024

shatejas commented May 16, 2024 •

edited

Loading

shatejas May 17, 2024 •

edited

Loading

shatejas May 31, 2024 •

edited

Loading

shatejas Jun 5, 2024 •

edited

Loading

shatejas Jun 5, 2024 •

edited

Loading

jmazanec15 left a comment •

edited

Loading

shatejas Jun 6, 2024 •

edited

Loading