lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avi Rosenschein <>
Subject Re: Relevancy Practices
Date Fri, 30 Apr 2010 12:00:06 GMT
On Thu, Apr 29, 2010 at 5:59 PM, Mark Bennett <> wrote:

> Hi Grant,
> You're welcome to use any of my slides (Dave's got them), with attribution
> of course.
> BUT....
> Have you considered a section something like "why the hell do you think
> Relevancy tweaking is gonna save you!?!?"

> Basically that, as a corpus grows exponentially, so do results list sizes,
> so ALL relevancy tweaks will eventually fail.  And FACETS (or other
> navigators) are the answer.  I've got slides on that as well.

The idea is to get the relevancy to fail on a smaller and smaller percent of
the queries, as the corpus grows larger. Facets can definitely help, but
they don't solve the basic problem of search, when there is no facet for the
particular way the user is looking for something. The strength of search is
that it can help the user to find things even when other forms of navigation

Of course relevancy matters.... but it's only ONE of perhaps a three pronged
> approach:
> 1: Organic Relevancy and top query suggetions
> 2: Results list Navigators, the best the system can support, and
> 3: Data quality (spidering, METADATA quality, source weighting, etc)

I would prefer to say that data quality can directly contribute to relevance
(besides being important for other reasons as well). Basically, search
relevancy is a combination of quality of data + quality of algorithm. In
general, they are both important, and data even has the potential to be more
important than algorithm, if you structure it right.

Also, tuning the algorithms to the users can be very important. For
instance, we have found that in a basic search functionality, the default
query parser operator OR works very well. But on a page for advanced users,
who want to very precisely tune their search results, a default of AND works

-- Avi

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message