[Platform] Meilisearch message store

[Guikingone]

Q	A
Bug fix?	no
New feature?	yes
Docs?	no
Issues	None
License	MIT

Hi 👋🏻

Here's a small POC to store message bags outside of memory (for long term agents), the implementation is built around MS but the main interfaces are defined (Redis, Doctrine, etc, any bridge can use it) for any bridge (and heavily inspired by the Store package).

Let me know if the idea is interesting, if not, feel free to close the PR 🙂

[OskarStark]

Wouldn't it be more related to Chat and the MessageStore?

[Guikingone]

Ah yes, I wasn't sure about the interface to use, I'll check the store one.

[OskarStark]

PR title and body would need an update please

[Guikingone]

Yes, I need to finish the test in the same time, I'll push the updated version once it's done 🙂

[chr-hertel]

Great idea, thanks! added some minor comments.

I wonder tho if we should move that feature into the store component - WDYT?

[chr-hertel]

Suggested change

	$chat->submit(Message::ofUser('My name is Christopher.'));
	$chat->submit(Message::ofUser('My name is Guillaume.'));

😆

[chr-hertel]

(feel free to omit this one - it's friday and my brain is already half way gone)

[Guikingone]

@chr-hertel I agree, the Store component should contains everything related to storing messages, vectors and more, this way, we can easily "update" the API without forcing the release of Agent, plus, we can easily share the API thanks to interfaces.

Maybe we can move the classes/interfaces after this PR to prevent any bloating of it?

[chr-hertel]

Maybe we can move the classes/interfaces after this PR to prevent any bloating of it?

Agreed 👍

[OskarStark]

What about a dedicated MessageStore component? or too much?

[Guikingone]

@OskarStark Well, here's my humble opinion (I don't know how this package was initially designed and what are the "rules" that it must follow to comply with Symfony approach):

The Store package is enough, its description along with the documentation must be updated to inform that it "store" more than just vectors and is not "only designed" for RAG, this approach would allow to keep the current packages and add new features (like graph databases and more) without compromising the overall developer experience (too much packages tend to complicate the developer experience, you're using X namespaces, you don't know which one do what, etc)

Maybe we could find a new "way" to split the Store package (new sub namespaces and more, let's say Bridge then two namespaces VectorStore then MessageStore, simple examples to gave the idea) to keep it coherent and "open" for future modifications but IMO, it's enough for the "storage" part of the AI initiative.

[chr-hertel]

One thing I wonder is about having multiple conversations happening in parallel. Let's say per user. How would that work with this implementation? separate index?

[Guikingone]

Actually, yes, multiple index.

Another solution might be to use a "session" per agent, the session is initiated by the agent (constructor call, maybe an UUID?) then sent to the message store to "lock" messages per agent.

I don't see a big technical bottleneck but IMO, this refactoring must be brought via another PR (I can work on it if you want).