[
https://issues.apache.org/jira/browse/SOLR-11597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262511#comment-16262511
]
Christine Poerschke commented on SOLR-11597:
--------------------------------------------
Thanks for extending the pull request, [~malcorn_redhat].
Having the structured numeric weights instead of the {{[
"1,2,3\n4,5,6\n7,8,9\n10,11,12", ... ]}} style string array really helps with
understanding the javadocs example and the code I think.
Once it's converted from the params.weights JSON into a {{ArrayList<float[][]>
weightMatrices}} class member, then looking at how the matrices are used I
struggled a little a couple of times with {{\[row\]\[column\]}} vs.
{{\[column\]\[row\]}} and the {{\[matrixCols - 1\]}} being not a weight but a
bias and the last layer for some reason not having the non-linearity applied to
it ... so i explored representational separation of weights and biases (the
first commit on
https://github.com/cpoerschke/lucene-solr/tree/master-solr-11597).
With the representations and calculations then being easier to understand, for
me at least, after a little while 'the penny dropped' and the _"Can {{score()}}
directly feed its argument to the neural network?"_ question arose and because
the answer seems to be _"no"_ in the second commit on
https://github.com/cpoerschke/lucene-solr/tree/master-solr-11597 i separated
out the inputs and the output from the layers in representational terms, this
also conveniently removes the 'no non-linearity for the last layer' special
case and the need to validate that the last layer contains exactly one node.
The third commit on
https://github.com/cpoerschke/lucene-solr/tree/master-solr-11597 is strictly
speaking unrelated to the first two commits, it explores a functor-style
non-linearity implementation so that no string comparisons are needed when
calculating scores plus deriving classes could be created to support additional
custom non-linearities.
https://github.com/airalcorn2/lucene-solr/compare/ranknet...cpoerschke:master-solr-11597
is the combination of the three commits - what do you think? Could an approach
like this work too or might the extra structure(s) result in an unacceptable
incremental performance dent for the {{score()}} method which will be run many
times for each model (whereas the setters and the validate method run
essentially just once)?
> Implement RankNet.
> ------------------
>
> Key: SOLR-11597
> URL: https://issues.apache.org/jira/browse/SOLR-11597
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
> Reporter: Michael A. Alcorn
>
> Implement RankNet as described in [this
> tutorial|https://github.com/airalcorn2/Solr-LTR].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
