-
Notifications
You must be signed in to change notification settings - Fork 238
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
Vector search reference #2824
Vector search reference #2824
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:ai-search-reference-parameter Credentials to access the page are in the company's password manager as "Docs deploy preview". |
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.
Thank you for putting this reference together, that's a lot of work ☀️ There are some missing pieces, see inline comments
Thanks for the review, @dureuill! I have updated the Also, I'm not convinced about the documentation for the |
I agree! I'm thinking of a better way of achieving this, here's what I get:
Maybe for clarity we could rename these to Or these could be What do you think? Do you think it would make things clearer? |
Sure, To send the embedding request, Meilisearch performs two steps:
For example, to implement the OpenAI embedder API, the final request needs to be: {
"input": "TEXT TO EMBED",
"model": "text-embedding-ada-002",
"encoding_format": "float"
} in this example, the {
"model": "text-embedding-ada-002",
"encoding_format": "float",
} However the Final embedder configuration would be: {
"url": "https://api.openai.com/v1/embeddings",
"apiKey": "OPENAI_APIKEY",
"query": {
"model": "text-embedding-ada-002",
"encoding_format": "float",
},
"inputField": ["input"],
// omitting "inputType", "pathToEmbeddings" and "embeddingObject"
} Similarly, an ollama request looks like: {
"model": "nomic-embed-text",
"prompt": "TEXT TO EMBED"
} So you'd have |
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.
Ok for code samples
@dureuill, Regarding the API, I think Possibly stupid idea: would we gain anything from creating two main fields, {
"default": {
"source": "",
"input": {
"apiKey": "",
"model": "",
"revision": "",
"dimensions": 123,
"inputType": "",
"pathToInput": [],
"query": {}
},
"response": {
"pathToEmbeddingArray": [],
"pathToEmbeddingData": [],
"distribution": {}
},
}
} I was also thinking about Regarding |
Hey @guimachiavelli
Nice we might consider changing the name of these parameters then :-)
I like the idea, but I'm not sure we could implement it. The fields are shared between all embedders, and the fields in Also, as much as I love nesting, we should avoid it as much as possible, because it becomes very unwieldy when using the API (the previous API had the parameters nested under the source, which was easier from an implementation perspective, but harder to input).
Not really, it determines if multiple texts can be sent as input, which allows for better performance.
We could, but we might have to come with some sort of smart naming 🤔
That is because the model is a first-class concept for openAi, huggingFace and ollama, but not for REST. The REST embedder configuration is just a way to tell Meilisearch how to send POST request with a JSON body where the text to embed is injected. You could imagine some embedders with a REST API not exposing the model at all. For instance, Hugging Face inference endpoints are created with the model already selected, so one does not pass the model every request. For a HF inference endpoint, the REST configuration could be something like: {
"url": "https://l2skjfwp9punv393.us-east-1.aws.endpoints.huggingface.cloud",
"apiKey": "YOUR_TOKEN",
"query": {
"truncate": true
},
"inputField": ["inputs"],
"inputType": "textArray",
"pathToEmbeddings": [] // no idea what the answer looks like would have to test,
"embeddingObject": [] // same
} |
Ok, thanks for the answers, @dureuill. I'm curious on how the API will evolve before we stabilise it, especially if we manage to get more direct feedback from users (perhaps organising a poll or a couple of interviews?). A lot of my concerns might end up being fairly academic and mostly unimportant for the majority of people who are actually using vector search. In any case, I think this PR is ready for an official review. I don't think you need to re-read everything, just the new section describing each embedder option in more detail: https://github.com/meilisearch/documentation/pull/2824/files#diff-a88efc3f5697059650c8e14b221124b09e9c2eb12aadc2290bb87a71456fd64aR1999-R2193 |
reference/api/settings.mdx
Outdated
|
||
Other models, such as those provided by Ollama and REST embedders may also be compatible with Meilisearch. | ||
|
||
This field is mandatory for `openAi`, `huggingFace`, and `Ollama` embedders. |
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 field has default values for openAi
and huggingFace
, so it is only mandatory for ollama
embedders.
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.
What are the default values for openAi
and huggingFace
? text-embedding-3-small
and BAAI/bge-base-en-v1.5
?
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.
BAAI/bge-base-en-v1.5 for hf and the ada one for openai
Ah, I also think it would be nice to have a list of the embedder with the allowed/mandatory parameter per 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.
Thank you for this huge addition 🎈 🎉
4815: Rest embedder api mk2 r=ManyTheFish a=dureuill # Pull Request ## Related issue Fixes #4756 - [x] [REST API parameter names and behavior are unclear](meilisearch/documentation#2824 (comment)) - unclear names are removed. There remain only two parameters: `request`, a template of what Meilisearch's request to the embedding server should be, and `response`, a template of what the embedding server's response to Meilisearch should look like - [x] [Bad error message or bad default value when we don't specify the `query` parameter](https://github.com/meilisearch/meilisearch/blob/85d8455c11bfa0a5c2ba70d15554c974b003d666/meilisearch/tests/vector/rest.rs#L105-L140) - The replacement for `query`, which is `request`, is now a mandatory parameter. Omitting it will result in the following error message : "`.embedders.rest`: Missing field `request` (note: this field is mandatory for source rest)", which is clear - [x] [Bad error message when both `pathToEmbeddings` and `embeddingObject` are missing](https://github.com/meilisearch/meilisearch/blob/2141cb3b69f52ca6fcf18d0b89df1d8601a22f85/meilisearch/tests/vector/rest.rs#L142-L178) - These parameters no longer exist. Now, the point of extraction is given directly by the location of an `{{embedding}}` placeholder in the `response` parameter. - [x] [Unexpected error when we don't specify both `pathToEmbeddings` and `embeddingObject` (only once should be required)](https://github.com/meilisearch/meilisearch/blob/2141cb3b69f52ca6fcf18d0b89df1d8601a22f85/meilisearch/tests/vector/rest.rs#L180-L260) - These parameters no longer exist. Now, the point of extraction is given directly by the location of an `{{embedding}}` placeholder in the `response` parameter. - [x] [Should not panic when the dimensions specified do not work with the model](https://github.com/meilisearch/meilisearch/blob/2141cb3b69f52ca6fcf18d0b89df1d8601a22f85/meilisearch/tests/vector/rest.rs#L262-L299) - This no longer panics, instead returns "While embedding documents for embedder `rest`: runtime error: was expecting embeddings of dimension `2`, got embeddings of dimensions `3`" - [x] [Be more flexible on the type of data that is accepted](#4757 (comment)) - [x] Always accept arrays of embeddings even if `inputType` is set to `text` - This is controlled by the repeat placeholder `"{..}"`, an array of embeddings can be configured even if the input is not in an array. - [x] Accept arrays of result at the root level and texts/array of text at the root level. - doable with `request: "{{text}}"` and `response: "{{embedding}}"` or `response: ["{{embedding}}"]` (see test `vector::rest::server_raw`) ## What does this PR do? - [See public usage](https://meilisearch.notion.site/v1-10-AI-search-changes-737c9d7d010d4dd685582bf5dab579e2#8de842673ffa4a139210094a89c1ec3e) - Add new `milli::vector::json_template` module to parse JSON templates with an injection placeholder and a repeat placeholder - Change rest embedder to use two JSON templates - Change ollama and openai embedders to use the new rest embedder - Update settings - Update and add tests ## Breaking change > [!CAUTION] > This PR is a breaking change to the REST embedder. > Importing a dump containing a REST embedder configuration will fail in v1.10 with an error: "Error: unknown field `query`, expected one of `source`, `model`, `revision`, `apiKey`, `dimensions`, `documentTemplate`, `url`, `request`, `response`, `distribution` at line 1 column 752". Upgrade procedure: 1. Remove any embedder with source "rest" 2. Create a dump 3. Import that dump in a v1.10 4. Re-add any removed embedder, using the new settings. Co-authored-by: Louis Dureuil <[email protected]> Co-authored-by: Louis Dureuil <[email protected]> Co-authored-by: Tamo <[email protected]>
This PR adds an initial base reference for:
hybrid
andvector
search parametersembedders
index setting