-
Notifications
You must be signed in to change notification settings - Fork 252
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
Add new article on how to choose embedder type #3058
base: main
Are you sure you want to change the base?
Conversation
How to see the preview of this PR?Go to this URL: https://website-git-deploy-preview-mei-16-meili.vercel.app/docs/branch:3040-choose-embedder-guide Credentials to access the page are in the company's password manager as "Docs deploy preview". |
|
||
In these cases, you will have to supply your own embedder. | ||
|
||
## Only choose Hugging Face when self-hosting small static datasets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was initially advice for Cloud users using HF embedders because we were generating the embeddings locally (running on our Cloud infra). This is no longer the case, we removed the option on the Cloud and we've replaced it with the Hugging Face Inference points using the REST embedder option.
Self-hosted users can still use HuggingFace as an embedder option, as they can tweak their infrastructure to fit their specific needs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can either remove this section, or point users in the direction of how to set a HF embedder using the REST option (for Cloud) and the API reference (for self hosted)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there may be something a bit confusing about how we handle hugging face right now.
We have a huggingFace
embedder source, but it works very differently from all other built-in embedders in that it must run locally. At the same time, if I understand correctly, there's HF's inference points, which instead work more or less exactly like open AI and ollama. So we end up treating hugging face as a monolithic choice due to it having its dedicated source, which may not be ideal for users who must use hugging face but don't want to run it locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be my ignorance speaking, but it almost seems as if our official hugging face source gives the worst of the two available options for existing HF users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I see how it gets a bit confusing. I'll try to describe the options clearly and we can go from there.
Options available on Cloud:
- OpenAI
- Custom (user-provided)
- REST: used to set up HF inference points, ollama, Cloudflare, or any embedder running on a third-party that supports REST format
Options available for self-hosted:
- OpenAI
- user-provided
- REST: set up any embedder running on a third-party that supports REST
- huggingface: set up a local HF model of choice that will run locally
- ollama: similar to REST but specific to ollama config
|
||
OpenAI returns relevant search results across different subjects and datasets. It is suited for the majority of applications and Meilisearch actively supports and improves OpenAI functionality with every new release. | ||
|
||
In the majority of cases, and especially if this is your first time working with LLMs and AI-powered search, choose OpenAI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Feel free to ignore this one as it might be just me) I wonder if this doesn't sound a bit too biased towards OpenAI, making it sound like it's our provider of choice over others. Maybe we can phrase it around "ease of config" or "easiest for beginners" as it only requires pasting the OpenAI key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm working off @dureuill's comments on #3040 for this. It is very biased, and I do feel a bit uncomfortable with pushing a third-party service so hard when documenting such a strategic feature.
At the same time, it seems this really is the best guidance we can give from a technical perspective: if you don't have any strong preference or aren't already working with another service, choose OpenAI.
|
||
If you are already using a specific model from a compatible embedder, choose Meilisearch's REST embedder. This ensures you continue building upon tooling and workflows already in place with minimal configuration necessary. | ||
|
||
## If dealing with non-textual content, choose the user-provided embedder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## If dealing with non-textual content, choose the user-provided embedder | |
## If dealing with non-textual content, choose the Custom (user-provided) embedder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want parentheses in the heading, but I'll include "custom embedder" somewhere in the section body.
|
||
## If dealing with non-textual content, choose the user-provided embedder | ||
|
||
Meilisearch does not support searching images, audio, or any other content not presented as text. This limitation applies to both queries and documents. For example, Meilisearch's built-in embedder sources cannot search using an image instead of text. They also cannot use text to search for images without attached textual metadata. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pinging @dureuill as I'm not 100% sure about this one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes that is correct. We may want to specify that, by supplying the embeddings generated using their own embedder, the user can indeed achieve these use cases.
Co-authored-by: macraig <[email protected]>
Closes #3040