-
Notifications
You must be signed in to change notification settings - Fork 126
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
Retriever Naming #319
Comments
Hi @bilgeyucel, I'm working on this
|
Some material for thinking about Sparse Embedding Retrieval (to choose the right names): |
Hi @sahusiddharth, we're still working on this issue so it's on hold at the moment. Feel free to pick another issue from "Contributions Wanted" list :) |
We decided for this naming convention: Dense Embeddings Retriever → EmbeddingRetriever Examples:
|
Done! Docs will be improved according to the new Naming: #6976 |
The receivers' names should refer to the retrieval method instead of the input type. This allows us to have specific retrievers for document stores (e.g. Chroma has
ChromaQueryRetriever
that refers to Chroma'squery
API, not Haystack's query input).Things to pay attention
Even if there's only one retrieval method that the document store supports, let's try to state the method in the retriever's name. e.g:
QdrantRetriever
❌QdrantEmbeddingRetriever
✅Some future retriever examples according to this convention
QdrantSpladeRetriever
-> "Splade" is not totally clear for Haystack users but aligns with Qdrant quite wellQdrantSparseRetriever
-> clearer for Haystack users but sounds like a quite general term, might create confusion if there are multiple sparse vector methods that cannot be supported with the same RetrieverWeaviateHybridRetriever
-> This component might taketext
as input (not embeddings) and return retrieved documents by using Weaviate's built-in hybrid search functionalityTasks
QdrantRetriever
+/retrievers
folder #134The text was updated successfully, but these errors were encountered: