Currently the entire Store infrastructure is really coupled to Document and Vector - which made sense when thinking of "classic RAG", but we see more thing emerging right now:

• Hybrid queries, like [Store] Add HybridStore with BM25 ranking for PostgreSQL #783
• Vectorization internalized, like ChromaDB, also leading to plain text as input
• Additional filters

On top we aim to build up a high-level service called Retriever, that supports various RAG scenarios:

with pre query extensions like "language normalization" or "multi-query" and post query extensions like user-land reranking.

while discussing with @wachterjohannes and looking again at @ahmed-bhs PR, there was the idea of introducing some kind of QueryInterface or Query to open up the first parameter of Store::query() method.

1. QueryInterface

Store::query(QueryInterface $query, array $options = [])

could work with VectorQuery, TextQuery and HybridQuery, potentially combined with StoreInterface implementations signalling what they support - or just throwing on invalid arguments

2. Query

Store::query(Query $query, array $options = [])

could work with Query::fromVector() and Query::fromText() or Query->addVector() and Query->addText() - making hybrid implicit

the difference is not that huge tho, we should just decide

• do we want to go there?
• do we want to be graceful? like you can add text, but a store might just ignore it
• do we shift filter options into the query as well?

cc @Guikingone @OskarStark @wachterjohannes @ahmed-bhs