lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuki Yano (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11250) Add new LTR model which loads the model definition from the external resource
Date Sat, 04 Nov 2017 13:23:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-11250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239005#comment-16239005
] 

Yuki Yano commented on SOLR-11250:
----------------------------------

Hi [~cpoerschke],

Thank you for revising the patch!

bq. In the TestWrapperModel class the WrapperModel equals and hashCode methods previously
had been excluded from the "this method must be overridden" check but I struggled to justify
that exclusion to myself and so added overridden WrapperModel equals and hashCode methods.
What do you think? We could go back to "not overridden" and add the reason (which i could
not find) re: why the methods must not be overridden.

Actually, both are OK for me. I follow your decision.
I didn't add overridden {{equals}} and {{hashCode}} because I thought wrapper model should
be same as wrapped model due to its behavior (or, maybe, I just followed the way of other
{{Model}} classes).

bq. Following on from that I wondered, is there a use case where model name and/or feature
store name could usefully be different between the wrapper model and the wrapped model?

I think feature store name cannot be different because wrapper model doesn't use own feature
store for scoring. Thus, I agree with your modification.

On the other hand, I think name could be different because the name of wrapper model can be
used as the alias of the wrapped model. With the example of {{largeExternallyStoredModel.json}},
if we fix the name of wrapper model (like "prodModel"), users can always use same rerankModel
(i.e, "prodModel") even if the version of wrapped model was changed (like "20171103" to "20171206").
I think this feature is useful because we can avoid the influence of updating models to users
(in other words, we can develop front-end and back-end separately).


> Add new LTR model which loads the model definition from the external resource
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-11250
>                 URL: https://issues.apache.org/jira/browse/SOLR-11250
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: contrib - LTR
>            Reporter: Yuki Yano
>            Assignee: Christine Poerschke
>            Priority: Minor
>         Attachments: SOLR-11250.patch, SOLR-11250.patch, SOLR-11250.patch, SOLR-11250_master.patch,
SOLR-11250_master_v2.patch, SOLR-11250_master_v3.patch, SOLR-11250_master_v4.patch
>
>
> We add new model which contains only the location of the external model and loads it
during the initialization.
> By this procedure, large models which are difficult to upload to ZooKeeper can be available.
> The new model works as the wrapper of existing models, and deligates APIs to them.
> We add two classes by this patch:
> * {{ExternalModel}} : a base class for models with external resources.
> * {{URIExternalModel}} : an implementation of {{ExternalModel}} which loads the external
model from specified URI (ex. file:, http:, etc.).
> For example, if you have a model on the local disk "file:///var/models/myModel.json",
the definition of {{URIExternalModel}} will be like the following.
> {code}
> {
>   "class" : "org.apache.solr.ltr.model.URIExternalModel",
>   "name" : "myURIExternalModel",
>   "features" : [],
>   "params" : {
>     "uri" : "file:///var/models/myModel.json"
>   }
> }
> {code}
> If you use LTR with {{model=myURIExternalModel}}, the model of {{myModel.json}} will
be used for scoring documents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message