Skip to content

GA chunk_rescorer in text_similarity_reranker - #139830

Merged
kderusso merged 2 commits into
elastic:mainfrom
kderusso:kderusso/update-chunk-rescorer-api-docs
Dec 19, 2025
Merged

kderusso merged 2 commits into
elastic:mainfrom
kderusso:kderusso/update-chunk-rescorer-api-docs

Conversation

@kderusso

Copy link
Copy Markdown
Member

GA's chunk rescorer and adds warnings about usage.

@kderusso kderusso added >enhancement :SearchOrg/Relevance Label for the Search (solution/org) Relevance team v9.4.0 labels Dec 19, 2025
`chunking_settings`
: (Optional, `object`)

Settings for chunking text into smaller passages for scoring and reranking. {applies_to}`stack: beta 9.2` By default, chunking settings are configured to fit within the token window of the model associated with the `inference_id`. Refer to the [Inference API documentation](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-inference-put#operation-inference-put-body-application-json-chunking_settings) for valid values for `chunking_settings`.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@mridula-s109 removed this as the tag is at the top

@elasticsearchmachine elasticsearchmachine added the Team:Search - Relevance The Search organization Search Relevance team label Dec 19, 2025
@elasticsearchmachine

Copy link
Copy Markdown
Collaborator

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

@elasticsearchmachine

Copy link
Copy Markdown
Collaborator

Hi @kderusso, I've created a changelog YAML for you.

@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

ℹ️ 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?

@kderusso
kderusso requested review from a team and leemthompo December 19, 2025 16:30

@leemthompo leemthompo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

lgtm!

@kderusso
kderusso merged commit 58de211 into elastic:main Dec 19, 2025
12 checks passed
elasticsearchmachine pushed a commit that referenced this pull request Apr 24, 2026
…#147371)

## Summary Reverts #147297.

The new single-file caching path calls
`object.lastModified().toEpochMilli()` in
`ExternalSourceResolver#resolveSource`, but
`StorageObject.lastModified()` returns `null` for the GCS and Azure
fixtures exercised by `external-basic.csv-spec`, causing an NPE that
cascades to 2,300–2,900 test failures per affected run.

The failure is deterministic — every PR rebased onto `main` after
#147297 merged has been failing `part-5` identically for ~8 hours.
Confirmed across 6+ unrelated PRs including the author's own pre-merge
CI build
([#139830](https://buildkite.com/elastic/elasticsearch-pull-request/builds/139830),
both initial run and smart retry).

Reverting to unblock the merge queue. Re-land after null-guarding
`lastModified()` (or gating on
`StorageProvider#supportsStableMetadata()` for the cache path as the PR
intended — currently `isCacheable()` checks `supportsStableMetadata()`
but all non-HTTP providers return the default `true`, which doesn't
match reality for the GCS/Azure fixtures).

## Test plan - [ ] `:x-pack:plugin:esql-datasource-csv:qa:javaRestTest`
— `external-basic` subset green. - [ ]
`:x-pack:plugin:esql:qa:server:multi-node:javaRestTest` —
`ExternalDistributedSpecIT.external-basic.*` green. - [ ] Full `part-5`
recovers on CI.
dnhatn pushed a commit to dnhatn/elasticsearch that referenced this pull request Apr 24, 2026
…47297)" (elastic#147371)

## Summary Reverts elastic#147297.

The new single-file caching path calls
`object.lastModified().toEpochMilli()` in
`ExternalSourceResolver#resolveSource`, but
`StorageObject.lastModified()` returns `null` for the GCS and Azure
fixtures exercised by `external-basic.csv-spec`, causing an NPE that
cascades to 2,300–2,900 test failures per affected run.

The failure is deterministic — every PR rebased onto `main` after
elastic#147297 merged has been failing `part-5` identically for ~8 hours.
Confirmed across 6+ unrelated PRs including the author's own pre-merge
CI build
([elastic#139830](https://buildkite.com/elastic/elasticsearch-pull-request/builds/139830),
both initial run and smart retry).

Reverting to unblock the merge queue. Re-land after null-guarding
`lastModified()` (or gating on
`StorageProvider#supportsStableMetadata()` for the cache path as the PR
intended — currently `isCacheable()` checks `supportsStableMetadata()`
but all non-HTTP providers return the default `true`, which doesn't
match reality for the GCS/Azure fixtures).

## Test plan - [ ] `:x-pack:plugin:esql-datasource-csv:qa:javaRestTest`
— `external-basic` subset green. - [ ]
`:x-pack:plugin:esql:qa:server:multi-node:javaRestTest` —
`ExternalDistributedSpecIT.external-basic.*` green. - [ ] Full `part-5`
recovers on CI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>enhancement :SearchOrg/Relevance Label for the Search (solution/org) Relevance team Team:Search - Relevance The Search organization Search Relevance team v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants