Fix #2459 allow overrides for "findAndRerank" command#2460
Conversation
Unit Test Coverage Report
|
📈 Integration Test Coverage Delta vs Main Branch (dse69-it)
|
Integration Test Coverage Report (dse69-it)
|
Integration Test Coverage Report (hcd-it)
|
📈 Integration Test Coverage Delta vs Main Branch (hcd-it)
|
| private boolean hasRerankOverride() { | ||
| var override = | ||
| getOrDefault(command.options(), FindAndRerankCommand.Options::rerankServiceOverride, null); | ||
| return override != null && (override.provider() != null || override.modelName() != null); |
There was a problem hiding this comment.
there is an isEmpty() on the record, the one on the create collection command is better. we should use that.
📈 Unit Test Coverage Delta vs Main Branch
|
|
Re-prompted: |
amorton
left a comment
There was a problem hiding this comment.
see comments, too much code duplication going on.
| * providers configuration. | ||
| */ | ||
| // package-private for unit testing | ||
| void validateRerankOverride( |
There was a problem hiding this comment.
-1 for this function, it is duplicating code and breaking encapsulation.
CollectionRerankDef.fromApiDesc() is the existing funciton we use to validate the reranking provided by the user. It is designed to be called when from create collection. It has parts we can re-use for vliadating the service description, the only difference is that we may use a different error code
e.g. INVALID_CREATE_COLLECTION_OPTIONS for create and RequestException.Code.INVALID_RERANK_OVERRIDE for findAndRerank.
AND theat we may have different rules for the model support.
When we do createCollection the model cannot be DEPRECATED or END_OF_LIFE
When we do findAndReRank using the model from the collection schema it cannot be END_OF_LIFE
when we do findAndRerank using an overload it cannot be DEPRECATED or END_OF_LIFE
Refactor CollectionRerankDef as needed so we can all it to create the CollectionRerankDef for the overridden service def, and centralize error throwing into it for checking the model has the correct support status. We should update all places we check model status to be in this class.
There was a problem hiding this comment.
Ok. Good clarification: I was not sure whether DEPRECATED should be allowed (like from defaults) for overrides or not -- could see either way being possible.
But decision is that overrides are not allowed to use DEPRECATED model.
There was a problem hiding this comment.
Refactored to reduce code duplication, centralize handling. Have a look if this makes sense, @amorton.
… against mutable state dup calls
| private CollectionRerankDef.RerankServiceDef resolveRerankServiceDef() { | ||
| var rerankOverride = | ||
| getOrDefault(command.options(), FindAndRerankCommand.Options::rerankServiceOverride, null); | ||
| boolean hasOverride = rerankOverride != null && !rerankOverride.isEmpty(); |
There was a problem hiding this comment.
NIT: I believe this would mean that:
"rerank": {"provider": null, "modelName": null}
Would be treated as hasOverride=FALSE (if i'm thinking of isEmpty() correctly). Just wondering if we want to be more explicit there - that's a case where (potentially) the client might want to provide an override, but made a mistake that led to nulls for the values. In which case, maybe we'd want to either document this, or reject these as invalid?
There was a problem hiding this comment.
Hmmmh. Good question. Let me see.
There was a problem hiding this comment.
Ok. Looks like it is rather difficult to both allow { } AND exclude {"provider": null, "modelName": null} -- especially when we are re-using (for better or worse) RerankingServiceDesc for both reranking definition (Collection creation) and for reranking overrides.
But I'll see if I can figure out something. :)
There was a problem hiding this comment.
@erichare Changed so that Overrides with both { } and {"provider": null, "modelName": null} will now fail: only explicit null (and missing override) are accepted as valid "no overrides".
erichare
left a comment
There was a problem hiding this comment.
LGTM @tatu-at-datastax ! One NIT that i found.
Aaron indicated review by Eric and/or Hazel sufficient to address concerns.
This has now been resolved: no more quiet ignoral of non-null overrides. |
What this PR does:
Adds ability to provide rerank provider/model overrides for findAndRerank; see #2459 for details.
Which issue(s) this PR fixes:
Fixes #2459
Checklist