Also, would like to understand what are the ways to optimize for performance
at search time with LTR. Queries with terms (that fetch more results) lead
to very high latency with re-rank query even for reRankDocs=24.
Is there best practices to reduce the latency?
Can fv cache help?
Shou
Thanks ilayaraja,
I updated the PR today integrating your and Alan's comments. Now it works
also in distributed mode. Please let me know what do you think :)
Cheers
Diego
On Wed, May 2, 2018, 17:46 ilayaraja wrote:
> Figured out that offset is used as part of the grouping patch which I
> appli
Figured out that offset is used as part of the grouping patch which I applied
(SOLR-8776) :
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
+ if (query instanceof AbstractReRankQuery){
+topNGroups = cmd.getOffset() +
((AbstractReRankQuery)query).getReRankDocs()
*
"Top K shouldn't start from the "start" parameter, if it does, it is a bug.
"***
1. I clearly see that LTR do re-rank based on the start parameter.
2. When reRankDocs=24, pageSize=24, I still get the second page of results
re-ranked by ltr plugin when I query with start=24.
Alessandro Benedett
Are you using SolrCloud or any distributed search ?
If you are using just a single Solr instance, LTR should have no problem
with pagination.
The re-rank involves the top K and then you paginate.
So if a document from the original score page 1 ends up in page 3, you will
see it at page three.
have
Between, I have applied the patch on top of solr 7.2.1 and it worked well for
me though the Test Cases were failing, yet to see why.
On another note, LTR with reRankDocs>page_size seems to create issue. For
example, Say my page_size=24 and reRankDocs=48.
For first query with start=0, it returns
Between, I have applied the patch on top of solr 7.2.1 and it worked well for
me though the Test Cases were failing, yet to see why.
On another note, LTR with reRankDocs>page_size seems to create issue. For
example, Say my page_size=24 and reRankDocs=48.
For first query with start=0, it returns
de, but unit tests in non distribute mode works.
>
> Hope this helps,
> Diego
>
> From: solr-user@lucene.apache.org At: 04/15/18 03:37:54To:
> solr-user@lucene.apache.org
> Subject: Re: Learning to Rank (LTR) with grouping
>
> People sometimes fill in the Fix/Version field
I just updated the PR to upstream - I still have to fix some things in
distribute mode, but unit tests in non distribute mode works.
Hope this helps,
Diego
From: solr-user@lucene.apache.org At: 04/15/18 03:37:54To:
solr-user@lucene.apache.org
Subject: Re: Learning to Rank (LTR) with
Thanks for the response Shawn !
In relation to this :
"I feel fairly sure that most of them are unwilling to document their
skills.
If information like that is documented, it might saddle a committer with
an obligation to work on issues affecting those areas when they may not
have the free ti
On 4/17/2018 5:35 AM, Alessandro Benedetti wrote:
Apache Lucene/Solr is a big project, is there anywhere in the official
Apache Lucene/Solr website where each committer list the modules of
interest/expertise ?
No, there is no repository like that. Each committer knows what their
own expertise
Hi Erick,
I have a curiosity/suggestion regarding how to speed up pending( or
forgotten ) Jiras,
is there a way to find out the most suitable committer(s) for the task and
tag them ?
Apache Lucene/Solr is a big project, is there anywhere in the official
Apache Lucene/Solr website where each commit
People sometimes fill in the Fix/Version field when they're creating
the JIRA, since anyone can open a JIRA it's hard to control. I took
that out just now.
Basically if the "Resolution" field doesn't indicate it's fixed, you
should assume that it hasn't been addressed.
Patches welcome.
Best,
Eri
Thanks Roopa.
I was expecting that the issue has been fixed in solr 7.0 as per here
https://issues.apache.org/jira/browse/SOLR-8776.
Let me see why it is still not working on solr-ltr-7.2.1
-
--Ilay
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Hi Ilay,
I am still on Solr 6.6.0 and did not patch the grouping fix.
I implemented a temporary workaround solution to have 2 async request from
the web application 1st with grouping 2nd without grouping and merged the
results.
This solution worked for my case as we were getting grouping results f
Hi Roopa & Deigo,
I am facing same issue with grouping. Currently, am on Solr 7.2.1 but still
see that grouping with LTR is not working. Did you apply it as patch or the
latest solr version has the fix already?
Ilay
-
--Ilay
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f4720
wrote:
> Roopa, did you try collapsing instead of grouping? it would work with ltr..
>
> From: solr-user@lucene.apache.org At: 01/11/18 16:48:26To:
> solr-user@lucene.apache.org
> Subject: Re: Learning to Rank (LTR) with grouping
>
> Solution that I implemented currently is:
> S
Roopa, did you try collapsing instead of grouping? it would work with ltr..
From: solr-user@lucene.apache.org At: 01/11/18 16:48:26To:
solr-user@lucene.apache.org
Subject: Re: Learning to Rank (LTR) with grouping
Solution that I implemented currently is:
Since we have a web application which
> >>> Hi Roopa,
>>> >>>
>>> >>> If you look at the diff:
>>> >>>
>>> >>> https://github.com/apache/lucene-solr/pull/162/files
>>> >>>
>>> >>> I didn't change much in So
cher, you can try to skip the
>> file
>> >>> when applying the patch and redo the changes after.
>> >>>
>> >>> Alternatively, the feature branch is available here:
>> >>>
>> >>> https://github.com/bloomberg/lucene-so
; >>>
> >>> Alternatively, the feature branch is available here:
> >>>
> >>> https://github.com/bloomberg/lucene-solr/commits/master-solr-8776
> >>>
> >>> you could try to merge with that or cheery-pick my changes.
> >>>
applying the patch and redo the changes after.
>>>
>>> Alternatively, the feature branch is available here:
>>>
>>> https://github.com/bloomberg/lucene-solr/commits/master-solr-8776
>>>
>>> you could try to merge with that or cheery-pick my
groups or also in reranking the
>> documents inside each group?
>>
>> Cheers,
>> Diego
>>
>>
>> From: solr-user@lucene.apache.org At: 12/09/17 19:07:25To:
>> solr-user@lucene.apache.org
>> Subject: Re: Learning to Rank (LTR) with grouping
>
> From: solr-user@lucene.apache.org At: 12/09/17 19:07:25To:
> solr-user@lucene.apache.org
> Subject: Re: Learning to Rank (LTR) with grouping
>
> Hi I tried to apply this JIRA SOLR-8776 as a patch as this feature is
> critical.
>
> Here are the steps I took on my mac:
>
> On br
-user@lucene.apache.org
Subject: Re: Learning to Rank (LTR) with grouping
Hi I tried to apply this JIRA SOLR-8776 as a patch as this feature is
critical.
Here are the steps I took on my mac:
On branch branch_6_5
Your branch is up-to-date with 'origin/branch_6_5'
patch -p1 -i 162.patch --dry-run
Hi I tried to apply this JIRA SOLR-8776 as a patch as this feature is
critical.
Here are the steps I took on my mac:
On branch branch_6_5
Your branch is up-to-date with 'origin/branch_6_5'
patch -p1 -i 162.patch --dry-run
I am getting Failures for certain Hunks
Example:
patching file
solr/c
Hi Diego,
Thank you, I will look into this and see how I could patch this.
Thank you for your quick response,
Roopa
On Fri, Dec 8, 2017 at 5:44 PM, Diego Ceccarelli wrote:
> Hi Roopa,
>
> LTR is implemented using RankQuery, and at the moment grouping doens't
> support RankQuery.
> I opened a j
Hi Roopa,
LTR is implemented using RankQuery, and at the moment grouping doens't
support RankQuery.
I opened a jira item time ago
(https://issues.apache.org/jira/browse/SOLR-8776) and I would be happy
to receive feedback on that. You can find the code here
https://github.com/apache/lucene-solr/pu
28 matches
Mail list logo
