Initial Hybrid Search (FT.HYBRID) bindings #454
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
tasks:
primary API is new
HybridSearchResult ISearchCommands.HybridSearch((string indexName, HybridSearchQuery query, IReadOnlyDictionary<string, object>? parameters)API (andAsynctwin).Note that because
FT.HYBRIDsupports parameterization in both the queries and the filters, I have deviated from the pattern forFT.SEARCH, in that the parameters are specified separately to the query. This means that a single query instance can be created and stored, then reused repeatedly with different values. To avoid concurrency concerns, "popsicle immutability" is used in the query object, becoming automatically frozen when issued. For convenience, a secondary type-based API is presented to allow parameters from, for example, anonymous types.HybridSearchQueryacts as a builder, so:However, a full API for the supported server features is available, for example:
To complement this, we introduce some additional additional types; the types specific to hybrid-search are mostly inside
NRedisStack.Search.HybridSearchQuery; the types that are also conceptually wider to all of search are inNRedisStack.Search.NRedisStack.Search.ApplyExpression- immutable readonly struct tuple ofstring expressionandstring? alias-NRedisStack.Search.Scorer- immutable class, private subtypes forTFIDF,BM25STD, etc from https://redis.io/docs/latest/develop/ai/search-and-query/advanced-concepts/scoring/NRedisStack.Search.VectorData- abstracts over ways of representing vector data; readonly structNRedisStack.Search.HybridSearchQuery- the new builder APINRedisStack.Search.HybridSearchQuery- the new result APINRedisStack.Search.HybridSearchQuery.Combiner- immutable class, private subtypes for RRD and linear combinersNRedisStack.Search.HybridSearchQuery.SearchConfig- immutable readonly struct describing a text search with scorer and aliasNRedisStack.Search.HybridSearchQuery.VectorSearchConfig- immutable readonly struct describing a vector search with method, filter, aliasNRedisStack.Search.VectorSearchMethod- immutable class, private subtypes for "nearest neighbour", "range", etcNRedisStack.Search.Parameters- allows objects to be used as parameter sourcesAt the moment
VectorDataonly supportsROM<float>(float[]), in line with SE.Redis VSIM support, but we can extend this as necessary.The new APIs are marked
[Experimental], pointing people to (when merged) a portal with the contents from https://github.com/redis/NRedisStack/blob/9548d539ff72ac370c7c0706e8e9c53b8492f1b3/docs/exp/NRS001.mdAPI note: the significance of
With*in theVectorSearchConfigandSearchConfigis that these are "withers", i.e. while it is a fluent API, the underlying type is immutable, so this returns a different instance (in this case, of a value-type). This contrasts with theHybridSearchQuerywhich pairs withSearchQueryin exposing a mutable fluent API, where each method endsreturn this.Note that this also includes a fix for #453