Skip to content

Introduce filters in the chat completions #5710

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

Merged
merged 7 commits into from
Jul 15, 2025

Conversation

Kerollmops
Copy link
Member

@Kerollmops Kerollmops commented Jun 24, 2025

This PR adds filter support in the chat completions route. It is very basic and driven only by a small documentation of the filter syntax. I want to improve the support by adding a list of the filterable attributes and some example values.

To Do

@Kerollmops Kerollmops added this to the v1.16.0 milestone Jun 24, 2025
@Kerollmops Kerollmops added the no db change The database didn't change label Jun 24, 2025
@Kerollmops Kerollmops force-pushed the chat-route-support-filters branch from 78b7785 to 446ae0f Compare July 7, 2025 09:50
@Kerollmops Kerollmops force-pushed the chat-route-support-filters branch from 446ae0f to d76dcc8 Compare July 15, 2025 09:49
@Kerollmops Kerollmops changed the base branch from main to release-v1.16.0 July 15, 2025 09:50
@Kerollmops Kerollmops requested a review from ManyTheFish July 15, 2025 12:52
@Kerollmops Kerollmops marked this pull request as ready for review July 15, 2025 13:36
@Kerollmops Kerollmops requested review from irevoire and ManyTheFish and removed request for ManyTheFish July 15, 2025 13:57
@Kerollmops Kerollmops removed the request for review from irevoire July 15, 2025 15:13
Copy link
Member

@ManyTheFish ManyTheFish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines +305 to +308
Err(MeilisearchHttpError::Milli {
error: meilisearch_types::milli::Error::UserError(user_error),
index_name: _,
}) => Ok((rtxn, Err(user_error))),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This allows the LLM to get the error and correct the query, am I right?

@ManyTheFish ManyTheFish added this pull request to the merge queue Jul 15, 2025
Copy link
Member

@ManyTheFish ManyTheFish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some question before merging the PR ☺️

Comment on lines +853 to +858
let facets_distribution = index
.facets_distribution(rtxn)
.max_values_per_facet(max_values_per_facet)
.candidates(universe)
.facets(filterable_attributes)
.execute()?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is computing the facet count necessary ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's important to have the most important ones first in description.

Comment on lines +860 to +872
let mut output = String::new();
for (facet_name, entries) in facets_distribution {
let _ = write!(&mut output, "{}: ", facet_name);
let total_entries = entries.len();
for (i, (value, _count)) in entries.into_iter().enumerate() {
let _ = if total_entries.saturating_sub(1) == i {
write!(&mut output, "{value}.")
} else {
write!(&mut output, "{value}, ")
};
}
let _ = writeln!(&mut output);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to only retrieve the exhaustive list for facet string?
For facet number we may want to print the min and the max as we do in the facetStats

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For facet strings it could be too much for the LLM context.

And for the numbers, yes, you are absolutely right!

Merged via the queue into release-v1.16.0 with commit 634865f Jul 15, 2025
11 checks passed
@ManyTheFish ManyTheFish deleted the chat-route-support-filters branch July 15, 2025 16:59
@Kerollmops Kerollmops added db change A database was modified and removed no db change The database didn't change labels Jul 17, 2025
Copy link

Hello, I'm a bot 🤖

You are receiving this message because you declared that this PR make changes to the Meilisearch database.
Depending on the nature of the change, additional actions might be required on your part. The following sections detail the additional actions depending on the nature of the change, please copy the relevant section in the description of your PR, and make sure to perform the required actions.

Thank you for contributing to Meilisearch ❤️

This PR makes forward-compatible changes

Forward-compatible changes are changes to the database such that databases created in an older version of Meilisearch are still valid in the new version of Meilisearch. They usually represent additive changes, like adding a new optional attribute or setting.

  • Detail the change to the DB format and why they are forward compatible
  • Forward-compatibility: A database created before this PR and using the features touched by this PR was able to be opened by a Meilisearch produced by the code of this PR.

This PR makes breaking changes

Breaking changes are changes to the database such that databases created in an older version of Meilisearch need changes to remain valid in the new version of Meilisearch. This typically happens when the way to store the data changed (change of database, new required key, etc). This can also happen due to breaking changes in the API of an experimental feature. ⚠️ This kind of changes are more difficult to achieve safely, so proceed with caution and test dumpless upgrade right before merging the PR.

  • Detail the changes to the DB format,
    • which are compatible, and why
    • which are not compatible, why, and how they will be fixed up in the upgrade
  • /!\ Ensure all the read operations still work!
    • If the change happened in milli, you may need to check the version of the database before doing any read operation
    • If the change happened in the index-scheduler, make sure the new code can immediately read the old database
    • If the change happened in the meilisearch-auth database, reach out to the team; we don't know yet how to handle these changes
  • Write the code to go from the old database to the new one
    • If the change happened in milli, the upgrade function should be written and called here
    • If the change happened in the index-scheduler, we've never done it yet, but the right place to do it should be here
  • Write an integration test here ensuring you can read the old database, upgrade to the new database, and read the new database as expected

@meili-bot meili-bot added the v1.16.0 PRs/issues solved in v1.16.0 released on 2025-08-04 label Aug 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
db change A database was modified v1.16.0 PRs/issues solved in v1.16.0 released on 2025-08-04
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants