-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Fix score count validation in reranker response #111212
Changes from 3 commits
a9805ae
fb5a671
7e3f153
7aa9a63
58a032c
c4d4d97
f30311d
4edc52e
6ea9eb7
7b91518
30ed86b
be485ac
ca032ee
71bc9bf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
pr: 111212 | ||
summary: Fix score count validation in reranker response | ||
area: Ranking | ||
type: bug | ||
issues: | ||
- 111202 |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,6 +37,20 @@ public class TextSimilarityRankTests extends ESSingleNodeTestCase { | |
*/ | ||
public static class InvalidInferenceResultCountProvidingTextSimilarityRankBuilder extends TextSimilarityRankBuilder { | ||
|
||
private boolean hasInvalidDocumentIndices = false; | ||
Mikep86 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
public InvalidInferenceResultCountProvidingTextSimilarityRankBuilder( | ||
String field, | ||
String inferenceId, | ||
String inferenceText, | ||
int rankWindowSize, | ||
Float minScore, | ||
boolean hasInvalidDocumentIndices | ||
) { | ||
this(field, inferenceId, inferenceText, rankWindowSize, minScore); | ||
this.hasInvalidDocumentIndices = hasInvalidDocumentIndices; | ||
} | ||
|
||
public InvalidInferenceResultCountProvidingTextSimilarityRankBuilder( | ||
String field, | ||
String inferenceId, | ||
|
@@ -65,7 +79,7 @@ protected InferenceAction.Request generateRequest(List<String> docFeatures) { | |
inferenceId, | ||
inferenceText, | ||
docFeatures, | ||
Map.of("invalidInferenceResultCount", true), | ||
Map.of("invalidInferenceResultCount", true, "invalidDocumentIndices", hasInvalidDocumentIndices), | ||
InputType.SEARCH, | ||
InferenceAction.Request.DEFAULT_TIMEOUT | ||
); | ||
|
@@ -151,11 +165,12 @@ public void testRerankInferenceFailure() { | |
); | ||
} | ||
|
||
public void testRerankInferenceResultMismatch() { | ||
public void testRerankInferenceResultCountMismatch() { | ||
ElasticsearchAssertions.assertFailures( | ||
// Execute search with text similarity reranking | ||
client.prepareSearch() | ||
.setRankBuilder( | ||
// Simulate reranker returning different number of results from input | ||
new InvalidInferenceResultCountProvidingTextSimilarityRankBuilder("text", "my-rerank-model", "my query", 100, 1.5f) | ||
) | ||
.setQuery(QueryBuilders.matchAllQuery()), | ||
|
@@ -164,6 +179,27 @@ public void testRerankInferenceResultMismatch() { | |
); | ||
} | ||
|
||
public void testRerankInvalidDocumentIndices() { | ||
Mikep86 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
ElasticsearchAssertions.assertFailures( | ||
// Execute search with text similarity reranking | ||
client.prepareSearch() | ||
.setRankBuilder( | ||
// Simulate reranker returning different number of results from input, also invalid document indices in results | ||
new InvalidInferenceResultCountProvidingTextSimilarityRankBuilder( | ||
"text", | ||
"my-rerank-model", | ||
"my query", | ||
100, | ||
1.5f, | ||
true | ||
) | ||
) | ||
.setQuery(QueryBuilders.matchAllQuery()), | ||
RestStatus.INTERNAL_SERVER_ERROR, | ||
containsString("Failed to execute phase [rank-feature], Computing updated ranks for results failed") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Two things here:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should work on making the HTTP response code configurable. 500 == rest suppressed errors == things to investigate during serverless on-call There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Update: there's no logic in ElasticsearchAssertions#assertFailures that we could call to check the cause of a search phase exception 🙁 (in this case There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that we could slightly rewrite this to capture the cause's message (as there won't be any response to decref).
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The status of the error is determined through the I think converting the |
||
); | ||
} | ||
|
||
private static void assertHitHasRankScoreAndText(SearchHit hit, int expectedRank, float expectedScore, String expectedText) { | ||
assertEquals(expectedRank, hit.getRank()); | ||
assertEquals(expectedScore, hit.getScore(), 0.0f); | ||
|
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.
Could we also add a test that throws this exception instead of the IOOB ?
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.
@benwtrent @pmpailis I added a test case for simulating invalid indices (7e3f153).
Note I don't think it actually covers the use case, because it's a sub-case of the reranker input/output count mismatch. With the bugfix this is now caught before the actual doc index assignment happens that would trigger the IOOB. (We do not have specific handling of N inputs -> N outputs -> index pointing outside 0..N-1, I'd consider that a reranker error.)
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.
@demjened AH, ok, is there a way to parse this
top_n
setting and validate that it matches the window size earlier in the request? That seems like we should return "Bad Request" in that scenario.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.
@benwtrent Not without issuing a GET call before each inference call to check the inference endpoint's configuration, I'm afraid. The rerank retriever framework only exposes hooks for creation and submission of an inference request, and parsing the results, but it doesn't know about the config.
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 need to fix this. If there are things that are invalid for a configuration & a search request, we need to fix this.
Calling a local GET to retrieve some minor documentation is way cheaper than calling some external service when the we know the request will fail. I would hold off on merging or progressing this until we can eagerly validate the search request as we know ahead of time that it won't work.
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.
@benwtrent @Mikep86 @pmpailis I'll summarize the latest changes here that accommodates all your suggestions (thanks for those):
task_settings.top_n < rank_window_size
and preemptively fail before running the inference, 2. the reranker actually returns <>N output on N inputs. These are tested intestRerankTopNConfigurationAndRankWindowSizeMismatch()
andtestRerankInputSizeAndInferenceResultsMismatch()
respectively.top_n
from the fetched inference endpoint config is vendor-specific. I'm not happy about this, but the emptyTaskSettings
interface doesn't give me much options to get the top N other than casting after a type check.my-inference-id-task-settings-top-3 -> top_n=3
). Again I'm not proud of this implementation, butGetInferenceModelAction
has a very limited interface to pass control parameters in in order to mock behavior in a test.Let me know if you feel there are still things to improve and must go in this PR; I want to timebox the remaining effort as the bug has been fixed and I want to make sure this gets merged by 8.15.0 BC5.
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.
Heads up that @demjened & I discussed offline yesterday and we're going to investigate doing the
task_settings.top_n < rank_window_size
check in ML codeThere 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.
@Mikep86 I've been thinking about this; while moving this logic to the ML code would make it cleaner and would remove coupling, I'm worried it's not a good idea from a product perspective.
For reference, here's the code you suggested that would replace the preemptive top_n check from the reranker:
The problem is we're invalidating a normal use case. It is a valid scenario that a rerank endpoint is configured to return a maximum of N hits for >N inputs. It's only an issue from the reranker retriever's perspective, where the a
model.top_k < retriever.rank_window_size
can lead to partial or incorrect results.So we have 3 options to implement the check:
XxxService
-s in ML code. Problem: invalidating valid use case.doInfer(..., inputSizeMustMatchTopN)
+ the code above? Problem: complex, requires refactoring of the interface and transport objects.WDYT?
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.
It is valid for the the reranker API to return fewer docs as that is the whole point of
topN
. Otherwise, why is it even configurable?The retriever also sets window size. For now, we should enforce that window size is <= topN. Maybe we can adjust this in the future, but for retrievers, this is a sane default & safe behavior.
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.
Got it, wasn't thinking of rerank endpoint usage outside of this context.