Skip to content

Allow updating inference_id of semantic_text fields#136120

Merged
dimitris-athanasiou merged 22 commits intoelastic:mainfrom
dimitris-athanasiou:allow-inference-id-updates-for-semantic_text
Oct 20, 2025
Merged

Allow updating inference_id of semantic_text fields#136120
dimitris-athanasiou merged 22 commits intoelastic:mainfrom
dimitris-athanasiou:allow-inference-id-updates-for-semantic_text

Conversation

@dimitris-athanasiou
Copy link
Contributor

Previously the inference_id of semantic_text fields was not updatable. This commit allows users to update the inference_id of a semantic_text field. This is particularly useful for scenarios where the user wants to switch to using the same model but from a different service.

There are two circumstances when the update is allowed.

  • No values have been written for the semantic_text field.

The inference endpoint can be changed freely as there is no need for compatibility between the current and the new endpoint.

  • The new inference endpoint is compatible with the previous one.

The model_settings of the new inference endpoint are compatible with those of the current endpoint, thus the update is allowed.

Previously the `inference_id` of `semantic_text` fields was not updatable.
This commit allows users to update the `inference_id` of a `semantic_text` field.
This is particularly useful for scenarios where the user wants to switch to using
the same model but from a different service.

There are two circumstances when the update is allowed.

  - No values have been written for the `semantic_text` field.

The inference endpoint can be changed freely as there is no need for
compatibility between the current and the new endpoint.

  - The new inference endpoint is compatible with the previous one.

The `model_settings` of the new inference endpoint are compatible
with those of the current endpoint, thus the update is allowed.
@dimitris-athanasiou dimitris-athanasiou added >enhancement :SearchOrg/Relevance Label for the Search (solution/org) Relevance team :Search Foundations/Search Catch all for Search Foundations v9.3.0 labels Oct 7, 2025
@elasticsearchmachine elasticsearchmachine added Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch Team:Search - Relevance The Search organization Search Relevance team labels Oct 7, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/search-relevance (Team:Search - Relevance)

@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search-foundations (Team:Search Foundations)

@elasticsearchmachine
Copy link
Collaborator

Hi @dimitris-athanasiou, I've created a changelog YAML for you.

@dimitris-athanasiou
Copy link
Contributor Author

PR is ready for review. However, I intend to add documentation changes soon.

@github-actions
Copy link
Contributor

github-actions bot commented Oct 8, 2025

@github-actions
Copy link
Contributor

github-actions bot commented Oct 8, 2025

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

Copy link
Contributor

@leemthompo leemthompo left a comment

Choose a reason for hiding this comment

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

Couple of very minor wording suggestions from me :)

dimitris-athanasiou and others added 2 commits October 8, 2025 18:47
Co-authored-by: Liam Thompson <leemthompo@gmail.com>
Co-authored-by: Liam Thompson <leemthompo@gmail.com>
Copy link
Member

@kderusso kderusso left a comment

Choose a reason for hiding this comment

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

Nice work! I've left a few comments but I think it's pretty close.

* @param modelSettings the new model settings. If null the mapper will be returned unchanged.
* @return A mapper with the copied settings applied
*/
private SemanticTextFieldMapper copyWithNewModelSettingsIfNotSet(
Copy link
Member

Choose a reason for hiding this comment

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

So we're doing a null check here before we copy the settings, but we silently ignore if that case happens. Should we throw if it's not null and this method is called?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It could be that it's not null because the update itself contains model_settings. In that case the explicitly set model_settings take precedence.

Copy link
Member

Choose a reason for hiding this comment

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

Didn't review this file, assume it's the same as the other yaml test

Copy link
Contributor

@Mikep86 Mikep86 left a comment

Choose a reason for hiding this comment

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

Partial review, didn't get to the tests. I'll pick it up next week.

Co-authored-by: Mike Pellegrini <mike.pellegrini@elastic.co>
Copy link
Contributor

@Mikep86 Mikep86 left a comment

Choose a reason for hiding this comment

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

Production code looks good! I left some comments about test adjustments, other than that we're good to go 🚀

@dimitris-athanasiou
Copy link
Contributor Author

@Mikep86 Thank you for the review! I have addressed all your feedback. I replied on replacing those tests with randomized testing that I'd prefer to keep it that way explaining my reasons. Let me know what you think. Otherwise, should be good to go now!

Copy link
Contributor

@Mikep86 Mikep86 left a comment

Choose a reason for hiding this comment

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

LGTM, I left one comment about how we could improve the assertions on the embeddings mappers

@dimitris-athanasiou dimitris-athanasiou merged commit df159ce into elastic:main Oct 20, 2025
34 checks passed
@dimitris-athanasiou dimitris-athanasiou deleted the allow-inference-id-updates-for-semantic_text branch October 20, 2025 13:05
chrisparrinello pushed a commit to chrisparrinello/elasticsearch that referenced this pull request Oct 24, 2025
Previously the `inference_id` of `semantic_text` fields was not updatable.
This commit allows users to update the `inference_id` of a `semantic_text` field.
This is particularly useful for scenarios where the user wants to switch to using
the same model but from a different service.

There are two circumstances when the update is allowed.

  - No values have been written for the `semantic_text` field.

The inference endpoint can be changed freely as there is no need for
compatibility between the current and the new endpoint.

  - The new inference endpoint is compatible with the previous one.

The `model_settings` of the new inference endpoint are compatible
with those of the current endpoint, thus the update is allowed.
fzowl pushed a commit to voyage-ai/elasticsearch that referenced this pull request Nov 3, 2025
Previously the `inference_id` of `semantic_text` fields was not updatable.
This commit allows users to update the `inference_id` of a `semantic_text` field.
This is particularly useful for scenarios where the user wants to switch to using
the same model but from a different service.

There are two circumstances when the update is allowed.

  - No values have been written for the `semantic_text` field.

The inference endpoint can be changed freely as there is no need for
compatibility between the current and the new endpoint.

  - The new inference endpoint is compatible with the previous one.

The `model_settings` of the new inference endpoint are compatible
with those of the current endpoint, thus the update is allowed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>enhancement :Search Foundations/Search Catch all for Search Foundations :SearchOrg/Relevance Label for the Search (solution/org) Relevance team Team:Search - Relevance The Search organization Search Relevance team Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v9.3.0

5 participants