Skip to content

SemanticCache with filterable_fields - consider extra metadata for creating the cache entry key #220

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

Closed
gacerioni opened this issue Sep 16, 2024 · 1 comment · Fixed by #224
Assignees
Labels
bug Something isn't working

Comments

@gacerioni
Copy link

gacerioni commented Sep 16, 2024

They @tylerhutcherson and @justin-cechmanek - Hope you are doing well!

As we discussed:

When I try to store some semantic caches with filterable_fields (as in the docs example):

private_cache = SemanticCache(
    name="private_cache",                     # underlying search index name
    redis_url="redis://default:blabla@redis-16962.c11.us-east-1-2.ec2.cloud.redislabs.com:16962",  # redis connection url string
    distance_threshold=0.1,               # semantic cache distance threshold
    filterable_fields=[{"name": "user_id", "type": "tag"}]
)

private_cache.store(
    prompt="What is the phone number linked to my account?",
    response="The number on file is 123-555-0000",
    filters={"user_id": "gabs"},
)

private_cache.store(
    prompt="What's the phone number linked in my account?",
    response="The number on file is 123-555-9999",
    filters={"user_id": "cerioni"},
)

private_cache.store(
    prompt="What's the phone number linked in my account?",
    response="The number on file is 123-555-1111",
    filters={"user_id": "bart"},
)

It only stores the 1st and last items (gabs and bart) - keeping this cap of 2 items.
Is there a way to override this limit?

Or, as discussed: utilize a purely random UUID for the key (if this is possible).

Thanks!

@justin-cechmanek justin-cechmanek self-assigned this Sep 16, 2024
@justin-cechmanek justin-cechmanek added the bug Something isn't working label Sep 16, 2024
@justin-cechmanek justin-cechmanek linked a pull request Sep 25, 2024 that will close this issue
@justin-cechmanek justin-cechmanek linked a pull request Sep 25, 2024 that will close this issue
@justin-cechmanek
Copy link
Collaborator

Hi @gacerioni. We've merged a fix to address this. Cache entries should no longer overwrite each other unless both the prompt and all metadata are identical.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants