Add a Redis based chat memory store extension

[sebastienblanc]

Replace the default InMemoryChatMemoryStore by using Redis instead.
I'm sure if I'm doing the best thing around the Codec since there is one in quarkus-langchain4j-core but I have no idea on how to use it.

[geoand]

Very nice! I'll review this carefully next week.

[geoand]

I think actually that the code could be a lot simpler, but I'll have to look closely and try stuff out next week.

[geoand]

I will push some changes to the PR shortly.

[geoand]

I pushed an update that now makes this PR complete.

However I have some comments about naming I would like @jmartisk to comment on as well

[sebastienblanc]

@geoand yeah naming is hard 😅 and thx for the updates on the PR !

[geoand]

🙏🏼

[jmartisk]

Looks nice!
I'm a little worried that now we will have two modules, quarkus-langchain4j-redis and quarkus-langchain4j-chatmemorystore-redis, it won't be very clear what the former is for.
The solution going forward would be to either merge the two extensions (but then it might get too big), or to adopt a new naming strategy, where each extension contains in its name what it actually provides, so quarkus-langchain4j-embedding-store-redis and quarkus-langchain4j-chat-memory-store-redis, for example.
We should decide on a reasonable strategy before it gets too late I think

[geoand]

going forward would be to either merge the two extensions

I don't think we should unless we really see in the real world that these two different concerns actually almost always met with the same Datastore.

We should decide on a reasonable strategy before it gets too late I think

+1

[geoand]

@cescoffier do you have any good suggestions on the naming of the Redis modules?

[cescoffier]

It depends the point of view. As developer/maintainer: quarkus-langchain4j-memory-store-redis is better because it groups all memory stores together.

From the user POV, I believe quarkus-langchain4j-redis-memory-store is easier to read, and once you select redis, the auto-completion will give you all the possibilities.

For the memory store, I would drop the 'chat', which is superfluous.

[geoand]

Good points!

[geoand]

I am in favor of Clement's proposals, WDYT @jmartisk @sebastienblanc ?

[sebastienblanc]

I agree with @cescoffier and for sure let's not merge it with the redis datastore because those are really 2 different things (like me I use pgvector for the datastore but Redis for the memory store)

[jmartisk]

So, let's sum it up:

• For AI model providers (chat model, embedding model, scoring model, image model, moderation model), we will clump all models provided from a provider into one extension and name it, say, quarkus-langchain4j-PROVIDER
• For embedding store providers, the extension will be named quarkus-langchain4j-embedding-store-PROVIDER
• For memory store providers, the extension will be named quarkus-langchain4j-memory-store-PROVIDER

Is this it?

From the user POV, I believe quarkus-langchain4j-redis-memory-store is easier to read, and once you select redis, the auto-completion will give you all the possibilities.

I think I'd prefer the "developer" PoV, typing memory-store will also get you auto-completion for all memory stores - and there will be lots of them, while typing redis will only give you two possibilities - memory store and embedding store.

[sebastienblanc]

I think I'd prefer the "developer" PoV, typing memory-store will also get you auto-completion for all memory stores - and there will be lots of them, while typing redis will only give you two possibilities - memory store and embedding store.

💯

[geoand]

So, let's sum it up:

• For AI model providers (chat model, embedding model, scoring model, image model, moderation model), we will clump all models provided from a provider into one extension and name it, say, quarkus-langchain4j-PROVIDER
• For embedding store providers, the extension will be named quarkus-langchain4j-embedding-store-PROVIDER
• For memory store providers, the extension will be named quarkus-langchain4j-memory-store-PROVIDER

Is this it?

From the user POV, I believe quarkus-langchain4j-redis-memory-store is easier to read, and once you select redis, the auto-completion will give you all the possibilities.

I think I'd prefer the "developer" PoV, typing memory-store will also get you auto-completion for all memory stores - and there will be lots of them, while typing redis will only give you two possibilities - memory store and embedding store.

@cescoffier do you agree with this proposal?

[sebastienblanc]

Should we decide on one of the naming conventions ?

[geoand]

cc @cescoffier

[sebastienblanc]

Just bumping this up ! (Really selfish agenda : I would like to release a video/blogpost on this feature) Le mar. 9 avr. 2024 à 15:46, Georgios Andrianakis ***@***.***> a écrit :

…

cc @cescoffier <https://github.com/cescoffier> — Reply to this email directly, view it on GitHub <#429 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACR2HMBCK4EJ3FFAQHHIPTY4PWLPAVCNFSM6AAAAABFOM2UAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBVGIYTQNBYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[geoand]

Clement is on PTO, so let's wait until Monday before moving forward

[geoand]

@cescoffier any preferences on the naming or should we move forward with this?

[cescoffier]

Yes, let's use the "Developer" approach - it's inlined with what we do in Quarkus.

[geoand]

@sebastienblanc would you like to update the PR?

[sebastienblanc]

@geoand I've been messing up with my branches 😅 but yeah let me find some time today to try to fix it and do renaming.

[geoand]

🙏🏼

[sebastienblanc]

Renamed, Rebased and squashed commits ! Let me know if it is all good

[geoand]

Thanks!

[adriens]

🥳 🍾