[ https://issues.apache.org/jira/browse/SOLR-11386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175189#comment-16175189 ]
Christine Poerschke commented on SOLR-11386: -------------------------------------------- Hi Michael, Thanks for reporting this strange behaviour! Saw your post on the mailing list yesterday but was unable to try out the http://gss-test-fusion.usersys.redhat.com:8983 links you shared (and perhaps am not meant to be able to try them anyhow). Everyone is investigating things differently of course, but here's a few things I might try (and perhaps you've already tried them too), in more or less this order: * The gist for the broken scenario shows {code} ... ... efi.case_description=added couple of fiber channel efi.case_issue= ... ... {code} whereas the gist for the working scenario shows {code} ... ... efi.case_description=couple of fiber channel added efi.case_issue= ... ... {code} with the latter have an extra space before the {{efi.case_issue=}} - just curious if that might be relevant or not. * It seems that perhaps the {{efi.case_description}} being multi-term has something to do with it. ** If it's just one term does it work then (I'd guess so) and is it the addition of the second or subsequent terms that results in the strange behaviour? ** Do the terms matter maybe? I'd guess not but worth just trying out. ** The {{efi.case_description}} is accompanied by {{efi.case_summary}} and {{efi.case_issue}} and {{efi.case_environment}} - and that should work and the order should not matter - but it might be worth exploring if changing of the order ( or removing of the accompanying {{efi}} s) brings any insights. *** Specifically I'm wondering if the {{efi.case_description}} 'grabbed' the subsequent {{efi}} s (but did not grab them when there was the extra space) and then the subsequent {{efi}} s being missing causes the strange behavior. _(If that is so then obviously it would be helpful to receive a better error message or something from Solr.)_ * Could the example be transferred to and reproduced with Solr's techproducts example. https://lucene.apache.org/solr/guide/6_6/learning-to-rank.html#LearningToRank-QuickStartExample * Addition of a test case e.g. in TestExternalFeatures.java to reproduce the strange behavior. > Extracting learning to rank features fails when word ordering of EFI argument > changed. > -------------------------------------------------------------------------------------- > > Key: SOLR-11386 > URL: https://issues.apache.org/jira/browse/SOLR-11386 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR > Affects Versions: 6.5.1 > Reporter: Michael A. Alcorn > > I'm getting some extremely strange behavior when trying to extract features > for a learning to rank model. The following query incorrectly says all > features have zero values: > http://gss-test-fusion.usersys.redhat.com:8983/solr/access/query?q=added > couple of fiber channel&rq={!ltr model=redhat_efi_model reRankDocs=1 > efi.case_summary=the efi.case_description=added couple of fiber channel > efi.case_issue=the efi.case_environment=the}&fl=id,score,[features]&rows=10 > But this query, which simply moves the word "added" from the front of the > provided text to the back, properly fills in the feature values: > http://gss-test-fusion.usersys.redhat.com:8983/solr/access/query?q=couple of > fiber channel added&rq={!ltr model=redhat_efi_model reRankDocs=1 > efi.case_summary=the efi.case_description=couple of fiber channel added > efi.case_issue=the efi.case_environment=the}&fl=id,score,[features]&rows=10 > The explain output for the failing query can be found here: > https://gist.github.com/manisnesan/18a8f1804f29b1b62ebfae1211f38cc4 > and the explain output for the properly functioning query can be found here: > https://gist.github.com/manisnesan/47685a561605e2229434b38aed11cc65 -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org