Solr and PhraseQuery – phrase bonus in query stage

Rafał Kuć Solr , , , , , , , , 0 Comment

In the majority of system implementations I dealt with, sooner or later, there was a problem – search results tunning. One of the simplest ways to improve the search results quality was phrase boosting. Having the three most popular query parsers in Solr and the variety of parameters to control them I though it will be a good idea to check how they behave and how they affect performance.

In the current trunk of Solr we have three query parsers:

  • Standard Solr Query Parser – default parser for Solr based on Lucene query parser
  • DisMax Query Parser
  • Extended DisMax Query Parser

Each of the mentioned query parsers have it`s own capabilities in case of phrase boosting on query stage. I won`t mention index time term proximity in this post – I`ll get back to it some other time. So, about the parsers now.

Standard Solr Query Parser

Parser based on Standard Lucene Query Parser and enhancing it`s parent capabilities. When it comes to phrase boosting, we don`t have much choice. Lets say, that our system is a search system for large Internet library, where users can rate books, leave comments and discuss books in the library forums. Our goal is to index all the data generated by the users and our suppliers and then represent this data in our search results. When user search for “Java design patterns”  we want to show him the books that have those words in a document. No problem, lets make a Solr query like this:

q=java+design+patterns

So we get the results and we can say that our search engine is behaving well and we don`t want to improve search quality. But I would add another part to the query – part that would favor document which have a phrase (words given to the query are next to each other in the document) in the search-able fields. It`s an easy step, our modified query would look like this:

q=java+design+patterns+OR+"java+design+patterns"^30

By adding that additional query part (+OR+”java+design+patterns”^30) we modified our search results – by adding that part, on the first position in our result we now have books which have the exact phrase in the search fields. Lucene query generated by the parser look like that: 

<str name="parsedquery">name:java name:design name:patterns PhraseQuery(name:"java design patterns"^30.0)</str>
<str name="parsedquery_toString">name:java name:design name:patterns name:"java design patterns"^30.0</str>

Search results for above query as follows: 

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
   <int name="status">0</int>
   <int name="QTime">0</int>
   <lst name="params">
      <str name="q">java design patterns OR "java design patterns"^30</str>
      <str name="fl">score,id,name</str>
   </lst>
</lst>
<result name="response" numFound="5" start="0" maxScore="1.2399161">
   <doc>
      <float name="score">1.2399161</float>
      <str name="id">1</str>
      <str name="name">Java design patterns</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">2</str>
      <str name="name">Design patterns java</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">3</str>
      <str name="name">Design java patterns</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">4</str>
      <str name="name">Patterns design java</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">5</str>
      <str name="name">Patterns java design</str>
   </doc>
</result>
</response>

DisMax Query Parser

In addition to constructing queries in such a manner as described above, we can use the parameter pf and modify its behavior by using the ps parameter. Pf parameter provide information about the fields in which phrases will be identified. Pf parameter is often used in a manner analogous to the parameter qf specifying a list of search-able fields. In addition to that, we must specify the boost parameter for the phrase otherwise the default boost will be taken into consideration. The query using DisMax would look like that:

q=java+design+patterns&defType=dismax&qf=name&pf=name^30&ps=0

While the query passed to Lucene looks as follows: 

<str name="parsedquery">+((DisjunctionMaxQuery((name:java)) DisjunctionMaxQuery((name:design)) DisjunctionMaxQuery((name:patterns)))~3) DisjunctionMaxQuery((name:"java design patterns"^30.0))</str>
<str name="parsedquery_toString">+(((name:java) (name:design) (name:patterns))~3) (name:"java design patterns"^30.0)</str>

The results for the query thus constructed are as follows: 

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
   <int name="status">0</int>
   <int name="QTime">0</int>
   <lst name="params">
      <str name="pf">name^30</str>
      <str name="fl">id,name,score</str>
      <str name="q">java design patterns</str>
      <str name="qf">name</str>
      <str name="defType">dismax</str>
      <str name="ps">0</str>
   </lst>
</lst>
<result name="response" numFound="5" start="0" maxScore="1.2399161">
   <doc>
      <float name="score">1.2399161</float>
      <str name="id">1</str>
      <str name="name">Java design patterns</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">2</str>
      <str name="name">Design patterns java</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">3</str>
      <str name="name">Design java patterns</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">4</str>
      <str name="name">Patterns design java</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">5</str>
      <str name="name">Patterns java design</str>
   </doc>
</result>
</response>

It is noteworthy that the order of results for both methods is the same. This follows from the fact, that the phrase has been identified only in the document with the id of 1.Look that there is no difference in the value of score for the first document in both methods. Of course the other documents, located on positions from 2 to 5, are in both cases on the same positions, but have different score values because of the difference in query passed to Lucene.

But, I used the ps parameter (set to 0) and didn`t mention why I did it. When You use the pf (and pf2, but more on that later) parameter, the ps parameter mean Phrase Slop – a maximum distance of words from each other to form a phrase. For instance, ps=2 will mean that the words can be a maximum of two places from each other to form a phrase. Note, however, that despite the fact that both the “Java sample design patterns” and “Java design patterns” will create a phrase, but the document entitled “Java design patterns” will have a bigger score value, despite the settings ps=2, because of terms located closer together.

Extended DisMax Query Parser

Unfortunately without the use of trunk You can not use eDisMax. But, anyway, the query using eDisMax Enhanced Term Proximity Boosting would look like that:

q=java+design+patterns&defType=edismax&qf=name&pf2=name^30&ps=0

The above query creates the following query to Lucene: 

<str name="parsedquery">+(DisjunctionMaxQuery((name:java)) DisjunctionMaxQuery((name:design)) DisjunctionMaxQuery((name:patterns))) (DisjunctionMaxQuery((name:"java design"^30.0)) DisjunctionMaxQuery((name:"design patterns"^30.0)))</str>
<str name="parsedquery_toString">+((name:java) (name:design) (name:patterns)) ((name:"java design"^30.0) (name:"design patterns"^30.0))</str>

As seen, in addition to the standard DisjunctionMaxQuery produced by DisMax (and this its expanded version), extended DisMax parser also produced two additional queries – the ones responsible for enhanced term proximity boosting.  The additional queries boosts pair of word created from the terms in the user query. In the presented case the created test pairs were “java design” and “design patterns”. As you can guess the most significant documents in the results list, documents will be generated by having both pairs, the next document will have one of the pair, and another will not have any. As proof I present the result of the above query send to Solr: 

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
   <int name="status">0</int>
   <int name="QTime">0</int>
   <lst name="params">
      <str name="fl">id,name,score</str>
      <str name="q">java design patterns</str>
      <str name="qf">name</str>
      <str name="pf2">name^30</str>
      <str name="defType">edismax</str>
      <str name="ps">0</str>
   </lst>
</lst>
<result name="response" numFound="5" start="0" maxScore="1.1705827">
   <doc>
      <float name="score">1.1705827</float>
      <str name="id">1</str>
      <str name="name">Java design patterns</str>
   </doc>
   <doc>
      <float name="score">0.3034844</float>
      <str name="id">2</str>
      <str name="name">Design patterns java</str>
   </doc>
   <doc>
      <float name="score">0.3034844</float>
      <str name="id">5</str>
      <str name="name">Patterns java design</str>
   </doc>
   <doc>
      <float name="score">0.014451639</float>
      <str name="id">3</str>
      <str name="name">Design java patterns</str>
   </doc>
   <doc>
      <float name="score">0.014451639</float>
      <str name="id">4</str>
      <str name="name">Patterns design java</str>
   </doc>
</result>
</response>

As you can see the first document has not changed its position. The second and third place are the documents that have one of the pairs generated by the parser. As a result documents with id 2 and 5 have the same coefficient score value. The result list is closed by the documents with only terms present in the search-able fields.

Performance

In any case, it must be taken into account that individual features will affect the performance of applications based on Solr. I thought I`ll do a simple performance test. The assumptions of the test are quite simple – index data from wikipedia and for each phrase boost method create five queries – each of the queries assembled from two to six tokens. Solr cache disabled, restart of Solr after each query. The result is the arithmetic mean of 10 repetitions of each test. Before the test results, a few words about the index:

  • Number of documents in the index: 1,177,239
  • Number of segments: 1
  • Number of terms: 18.506.646
  • Number of term/document pairs: 230.297.212
  • Number of tokens: 418.135.268
  • The size of the index: 4.6GB (optimized)
  • Lucene version used to build the index: 4.0-dev 964000

Phrases that were selected for each iteration of the test:

  • Iteration I: “Great Peter”
  • Iteration II: “World War Two”
  • Iteration III: “World War Two Germany”
  • Iteration IV: “Move Time Eastern Poland Reformation”
  • Iteration V: “Change Winter Cloths To Summer Cloths Now”

The results were as follows:

[table “1” not found /]

Please note that the reported results concern only the issue of performance and are not suggesting a method of phrase boosting. The choice of method is a matter of requirements and implementation. As for the results, you can see that the DisMax method is the quickest one.

Leave a Reply

Your email address will not be published. Required fields are marked *

We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.
Cookies settings
Accept
Privacy & Cookie policy
Privacy & Cookies policy
Cookies list
Cookie name Active

Privacy Policy

What information do we collect?

We collect information from you when you register on our site or place an order. When ordering or registering on our site, as appropriate, you may be asked to enter your: name, e-mail address or mailing address.

What do we use your information for?

Any of the information we collect from you may be used in one of the following ways: To personalize your experience (your information helps us to better respond to your individual needs) To improve our website (we continually strive to improve our website offerings based on the information and feedback we receive from you) To improve customer service (your information helps us to more effectively respond to your customer service requests and support needs) To process transactions Your information, whether public or private, will not be sold, exchanged, transferred, or given to any other company for any reason whatsoever, without your consent, other than for the express purpose of delivering the purchased product or service requested. To administer a contest, promotion, survey or other site feature To send periodic emails The email address you provide for order processing, will only be used to send you information and updates pertaining to your order.

How do we protect your information?

We implement a variety of security measures to maintain the safety of your personal information when you place an order or enter, submit, or access your personal information. We offer the use of a secure server. All supplied sensitive/credit information is transmitted via Secure Socket Layer (SSL) technology and then encrypted into our Payment gateway providers database only to be accessible by those authorized with special access rights to such systems, and are required to?keep the information confidential. After a transaction, your private information (credit cards, social security numbers, financials, etc.) will not be kept on file for more than 60 days.

Do we use cookies?

Yes (Cookies are small files that a site or its service provider transfers to your computers hard drive through your Web browser (if you allow) that enables the sites or service providers systems to recognize your browser and capture and remember certain information We use cookies to help us remember and process the items in your shopping cart, understand and save your preferences for future visits, keep track of advertisements and compile aggregate data about site traffic and site interaction so that we can offer better site experiences and tools in the future. We may contract with third-party service providers to assist us in better understanding our site visitors. These service providers are not permitted to use the information collected on our behalf except to help us conduct and improve our business. If you prefer, you can choose to have your computer warn you each time a cookie is being sent, or you can choose to turn off all cookies via your browser settings. Like most websites, if you turn your cookies off, some of our services may not function properly. However, you can still place orders by contacting customer service. Google Analytics We use Google Analytics on our sites for anonymous reporting of site usage and for advertising on the site. If you would like to opt-out of Google Analytics monitoring your behaviour on our sites please use this link (https://tools.google.com/dlpage/gaoptout/)

Do we disclose any information to outside parties?

We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our website, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety. However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses.

Registration

The minimum information we need to register you is your name, email address and a password. We will ask you more questions for different services, including sales promotions. Unless we say otherwise, you have to answer all the registration questions. We may also ask some other, voluntary questions during registration for certain services (for example, professional networks) so we can gain a clearer understanding of who you are. This also allows us to personalise services for you. To assist us in our marketing, in addition to the data that you provide to us if you register, we may also obtain data from trusted third parties to help us understand what you might be interested in. This ‘profiling’ information is produced from a variety of sources, including publicly available data (such as the electoral roll) or from sources such as surveys and polls where you have given your permission for your data to be shared. You can choose not to have such data shared with the Guardian from these sources by logging into your account and changing the settings in the privacy section. After you have registered, and with your permission, we may send you emails we think may interest you. Newsletters may be personalised based on what you have been reading on theguardian.com. At any time you can decide not to receive these emails and will be able to ‘unsubscribe’. Logging in using social networking credentials If you log-in to our sites using a Facebook log-in, you are granting permission to Facebook to share your user details with us. This will include your name, email address, date of birth and location which will then be used to form a Guardian identity. You can also use your picture from Facebook as part of your profile. This will also allow us and Facebook to share your, networks, user ID and any other information you choose to share according to your Facebook account settings. If you remove the Guardian app from your Facebook settings, we will no longer have access to this information. If you log-in to our sites using a Google log-in, you grant permission to Google to share your user details with us. This will include your name, email address, date of birth, sex and location which we will then use to form a Guardian identity. You may use your picture from Google as part of your profile. This also allows us to share your networks, user ID and any other information you choose to share according to your Google account settings. If you remove the Guardian from your Google settings, we will no longer have access to this information. If you log-in to our sites using a twitter log-in, we receive your avatar (the small picture that appears next to your tweets) and twitter username.

Children’s Online Privacy Protection Act Compliance

We are in compliance with the requirements of COPPA (Childrens Online Privacy Protection Act), we do not collect any information from anyone under 13 years of age. Our website, products and services are all directed to people who are at least 13 years old or older.

Updating your personal information

We offer a ‘My details’ page (also known as Dashboard), where you can update your personal information at any time, and change your marketing preferences. You can get to this page from most pages on the site – simply click on the ‘My details’ link at the top of the screen when you are signed in.

Online Privacy Policy Only

This online privacy policy applies only to information collected through our website and not to information collected offline.

Your Consent

By using our site, you consent to our privacy policy.

Changes to our Privacy Policy

If we decide to change our privacy policy, we will post those changes on this page.
Save settings
Cookies settings