Redis metadata filtering and specification, index customization

[Spartee]

Description

The previous Redis implementation did not allow for the user to specify the index configuration (i.e. changing the underlying algorithm) or add additional metadata to use for querying (i.e. hybrid or "filtered" search).

This PR introduces the ability to specify custom index attributes and metadata attributes as well as use that metadata in filtered queries. Overall, more structure was introduced to the Redis implementation that should allow for easier maintainability moving forward.

Example data

Suppose we have the following sample data

metadata = [
    {
        "user": "john",
        "age": 18,
        "job": "engineer",
        "credit_score": "high",
    },
    {
        "user": "derrick",
        "age": 14,
        "job": "doctor",
        "credit_score": "low",
    },
    {
        "user": "nancy",
        "age": 94,
        "job": "doctor",
        "credit_score": "high",
    },
    {
        "user": "tyler",
        "age": 100,
        "job": "engineer",
        "credit_score": "high",
    },
    {
        "user": "tim",
        "age": 12,
        "job": "dermatologist",
        "credit_score": "high",
    },
    {
        "user": "taimur",
        "age": 15,
        "job": "CEO",
        "credit_score": "low",
    },
    {
        "user": "joe",
        "age": 35,
        "job": "dentist",
        "credit_score": "medium",
    },
]

texts = ["foo", "foo", "foo", "foo", "bar", "bar", "bar"]

New Features

The following features are now available with the Redis integration into Langchain

Index schema generation

The schema for the index will now be automatically generated if not specified by the user. For example, the data above has the multiple metadata categories. The the following example

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores.redis import Redis

embeddings = OpenAIEmbeddings()


rds, keys = Redis.from_texts_return_keys(
    texts,
    embeddings,
    metadatas=metadata,
    redis_url="redis://localhost:6379",
    index_name="users"
)

Loading the data in through this and the other from_documents and from_texts methods will now generate index schema in Redis like the following.

view index schema with the redisvl tool. link

$ rvl index info -i users

Index Information:

Index Name	Storage Type	Prefixes	Index Options	Indexing
users	HASH	['doc:users']	[]	0
Index Fields:
Name	Attribute	Type	Field Option	Option Value
----------------	----------------	---------	----------------	----------------
user	user	TEXT	WEIGHT	1
job	job	TEXT	WEIGHT	1
credit_score	credit_score	TEXT	WEIGHT	1
content	content	TEXT	WEIGHT	1
age	age	NUMERIC
content_vector	content_vector	VECTOR

Custom Metadata specification

The metadata schema generation has the following rules

1. All text fields are indexed as text fields.
2. All numeric fields are index as numeric fields.

If you would like to have a text field as a tag field, users can specify overrides like the following for the example data

# this can also be a path to a yaml file
index_schema = {
    "text": [{"name": "user"}, {"name": "job"}],
    "tag": [{"name": "credit_score"}],
    "numeric": [{"name": "age"}],
}

rds, keys = Redis.from_texts_return_keys(
    texts,
    embeddings,
    metadatas=metadata,
    redis_url="redis://localhost:6379",
    index_name="users"
)

This will change the index specification to

Index Information:

Index Name	Storage Type	Prefixes	Index Options	Indexing
users2	HASH	['doc:users2']	[]	0
Index Fields:
Name	Attribute	Type	Field Option	Option Value
----------------	----------------	---------	----------------	----------------
user	user	TEXT	WEIGHT	1
job	job	TEXT	WEIGHT	1
content	content	TEXT	WEIGHT	1
credit_score	credit_score	TAG	SEPARATOR	,
age	age	NUMERIC
content_vector	content_vector	VECTOR

and throw a warning to the user (log output) that the generated schema does not match the specified schema.

index_schema does not match generated schema from metadata.
index_schema: {'text': [{'name': 'user'}, {'name': 'job'}], 'tag': [{'name': 'credit_score'}], 'numeric': [{'name': 'age'}]}
generated_schema: {'text': [{'name': 'user'}, {'name': 'job'}, {'name': 'credit_score'}], 'numeric': [{'name': 'age'}]}

As long as this is on purpose, this is fine.

The schema can be defined as a yaml file or a dictionary

text:
  - name: user
  - name: job
tag:
  - name: credit_score
numeric:
  - name: age

and you pass in a path like

rds, keys = Redis.from_texts_return_keys(
    texts,
    embeddings,
    metadatas=metadata,
    redis_url="redis://localhost:6379",
    index_name="users3",
    index_schema=Path("sample1.yml").resolve()
)

Which will create the same schema as defined in the dictionary example

Index Information:

Index Name	Storage Type	Prefixes	Index Options	Indexing
users3	HASH	['doc:users3']	[]	0
Index Fields:
Name	Attribute	Type	Field Option	Option Value
----------------	----------------	---------	----------------	----------------
user	user	TEXT	WEIGHT	1
job	job	TEXT	WEIGHT	1
content	content	TEXT	WEIGHT	1
credit_score	credit_score	TAG	SEPARATOR	,
age	age	NUMERIC
content_vector	content_vector	VECTOR

Custom Vector Indexing Schema

Users with large use cases may want to change how they formulate the vector index created by Langchain

To utilize all the features of Redis for vector database use cases like this, you can now do the following to pass in index attribute modifiers like changing the indexing algorithm to HNSW.

vector_schema = {
    "algorithm": "HNSW"
}

rds, keys = Redis.from_texts_return_keys(
    texts,
    embeddings,
    metadatas=metadata,
    redis_url="redis://localhost:6379",
    index_name="users3",
    vector_schema=vector_schema
)

A more complex example may look like

vector_schema = {
    "algorithm": "HNSW",
    "ef_construction": 200,
    "ef_runtime": 20
}

rds, keys = Redis.from_texts_return_keys(
    texts,
    embeddings,
    metadatas=metadata,
    redis_url="redis://localhost:6379",
    index_name="users3",
    vector_schema=vector_schema
)

All names correspond to the arguments you would set if using Redis-py or RedisVL. (put in doc link later)

Better Querying

Both vector queries and Range (limit) queries are now available and metadata is returned by default. The outputs are shown.

>>> query = "foo"
>>> results = rds.similarity_search(query, k=1)
>>> print(results)
[Document(page_content='foo', metadata={'user': 'derrick', 'job': 'doctor', 'credit_score': 'low', 'age': '14', 'id': 'doc:users:657a47d7db8b447e88598b83da879b9d', 'score': '7.15255737305e-07'})]

>>> results = rds.similarity_search_with_score(query, k=1, return_metadata=False)
>>> print(results) # no metadata, but with scores
[(Document(page_content='foo', metadata={}), 7.15255737305e-07)]

>>> results = rds.similarity_search_limit_score(query, k=6, score_threshold=0.0001)
>>> print(len(results)) # range query (only above threshold even if k is higher)
4

Custom metadata filtering

A big advantage of Redis in this space is being able to do filtering on data stored alongside the vector itself. With the example above, the following is now possible in langchain. The equivalence operators are overridden to describe a new expression language that mimic that of redisvl. This allows for arbitrarily long sequences of filters that resemble SQL commands that can be used directly with vector queries and range queries.

There are two interfaces by which to do so and both are shown.

>>> from langchain.vectorstores.redis import RedisFilter, RedisNum, RedisText

>>> age_filter = RedisFilter.num("age") > 18
>>> age_filter = RedisNum("age") > 18 # equivalent
>>> results = rds.similarity_search(query, filter=age_filter)
>>> print(len(results))
3

>>> job_filter = RedisFilter.text("job") == "engineer" 
>>> job_filter = RedisText("job") == "engineer" # equivalent
>>> results = rds.similarity_search(query, filter=job_filter)
>>> print(len(results))
2

# fuzzy match text search
>>> job_filter = RedisFilter.text("job") % "eng*"
>>> results = rds.similarity_search(query, filter=job_filter)
>>> print(len(results))
2


# combined filters (AND)
>>> combined = age_filter & job_filter
>>> results = rds.similarity_search(query, filter=combined)
>>> print(len(results))
1

# combined filters (OR)
>>> combined = age_filter | job_filter
>>> results = rds.similarity_search(query, filter=combined)
>>> print(len(results))
4

All the above filter results can be checked against the data above.

TODO

• more tests
• docstrings
• docs

Other

• Issue: [Feature] Redis Vectorestore - similarity_search filter by metadata #3967
• Dependencies: No added dependencies
• Tag maintainer: @hwchase17 @baskaryan @rlancemartin
• Twitter handle: @sampartee

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
langchain	⬜️ Ignored (Inspect)	Visit Preview		Aug 26, 2023 0:19am

[tylerhutcherson]

nice -- left a few comments and questions

[baskaryan]

would be good to have someone from redis side review the redis-specific logic!

[baskaryan]

since we're already making breaking changes, i'd suggest we update this to be

Suggested change

	embedding_function: Callable,
	embedding: Embeddings,

which is interface all newer VectorStores have

[baskaryan]

fixed some of the lint issues here #9705 if you want to merge that into this pr

[tylerhutcherson]

still need to add .paging(0, k) here

Suggested change

	Query(base_query).return_fields(*return_fields).sort_by("score").dialect(2)
	Query(base_query)
	.return_fields(*return_fields)
	.sort_by("score")
	.paging(0, k)
	.dialect(2)

[alonre24]

Added a few RediSearch syntax-related comments

[alonre24]

Isn't it Redis.from_texts_return_keys... ?

[alonre24]

I'm not sure that LIKE represents what you meant it would be. The difference between @%s:"%s" and @%s:%s is that the first one allows you to find exact matches for phrases, while the last one also looks for exact matches but for each token separately. Also, using @%s:%s (without quotes) will support stemming by default.
To get a behavior that is more similar to SQL's LIKE operator, we can use prefix, infix or suffix matching (see query docs).

[alonre24]

One of the advantages of range queries is that you can get all the results that are within a given range (not just the top k ones), and in particular you can see how many results are within the range. To utilize this feature I would suggest having k as an optional argument (and perhaps using an upper bound such as 1000 for paging), if that makes sense to you.

[tylerhutcherson]

agreed -- was going to suggest using K as an optional upper bound. @alonre24 isn't paging a default param 0-10 though?

Maybe something like:

query = (
    Query(query_string)
    .return_fields(*return_fields)
    .sort_by("distance")
    .dialect(2)
)

if k:
    query = query.paging(0, k)

[alonre24]

Yes, the default paging is 10, that's why I suggest also choosing an upper bound, so we have:

query = query.paging(0, k if k else UPPER_BOUND)

[Spartee]

It's part of the higher level interface abstraction so it would have to be set. I've started this conversation the lc folks though. Most likely the best route is another method that exposes this feature better.

[alonre24]

why if not value is ok?

[Spartee]

same thing as saying len(value) == 0.

>>> x = []
>>> if not x:
...     print("it's like an emptiness check")
... 
it's like an emptiness check

looks cleaner than len check or try/except

[alonre24]

Note that if there are tag values within the list that contain a comma, they will be split when indexed in RediSearch. Consider validating that there are no such values, or allowing the user to specify a different separator (API allows it).

[Spartee]

So currently, they could specify it in the schema and clean up the data themselves beforehand, but for the automatically generated metadata (how most will use it because they just use the data loaders), it's defaulting to , right now. Been thinking I should have a default here anyway. Good call out.

[alonre24]

Suggested change

	>>> price_is_over_100 = RedisNum("price") < 100
	>>> price_is_under_100 = RedisNum("price") < 100

[meiravgri]

I know it was already merged but I had a few comments :)

[meiravgri]

I suggest to update the vector field attributes according to the embedding model
i.e
self._schema = self._get_schema_with_defaults(index_schema, vector_schema, embedding)

[meiravgri]

I wouldn't say that it defaults to None. I think that the default schema used if index_schema or/and vector_schema are not passed should be documented.

[meiravgri]

I wonder what was the idea behind indexing all the metadata fields? They are anyway stored and loaded from redis key space during the query.
Was it to allow the hybrid search?

[meiravgri]

If I understand correctly, having a field called "content" is mandatory.
Fix me if I'm wrong but the only location I found it might be a problem to give this field a user-defined name is in similarity_search_with_score where we return result.content
(in similarity_search() it is handled better IMO by using getattr(result, content_key) instead)
Another solution is to define the return fields as
Query().return_field(self.content_field, as_field="content")

Also, where is the field name enforced in from_existing_index()?

[meiravgri]

I'd add tests that create or connect to an existing index that doesn't include the default fields names