]> git.evergreen-ils.org Git - working/Evergreen.git/commit
Improvements to search tuning
authormiker <miker@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Mon, 18 Apr 2011 19:57:01 +0000 (19:57 +0000)
committermiker <miker@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Mon, 18 Apr 2011 19:57:01 +0000 (19:57 +0000)
commit307a43715f7a4657336cc2d8a09e88e2efbf0977
treed9e8e90ab7f19c34d724e5e848c90a02867cbc9d
parent5ce74846e53108e4188cfb6c44881048c10e459e
Improvements to search tuning

 * Move to in-core fts function, instead of the compat wrapper provided by the tsearch2 contrib
 * Provide default cover density tuning (config file)
 * Move default preferred language settings from storage to search, where they make more sense

More on the CD tuning:

  Evergreen uses a cover density algorithm for calculating relative ranking of matches.  There
  are several tuning parameters and options available.  By default, no document length normalization
  is applied.  From the Postgres documentation on ts_rank_cd() (the function used by Evergreen):

      Since a longer document has a greater chance of containing a query term it is reasonable
      to take into account document size, e.g., a hundred-word document with five instances of
      a search word is probably more relevant than a thousand-word document with five instances.
      Both ranking functions take an integer normalization option that specifies whether and how
      a document's length should impact its rank. The integer option controls several behaviors,
      so it is a bit mask: you can specify one or more behaviors using | (for example, 2|4).

          0 (the default) ignores the document length

          1 divides the rank by 1 + the logarithm of the document length

          2 divides the rank by the document length

          4 divides the rank by the mean harmonic distance between extents (this is implemented only by ts_rank_cd)

          8 divides the rank by the number of unique words in document

          16 divides the rank by 1 + the logarithm of the number of unique words in document

          32 divides the rank by itself + 1

      If more than one flag bit is specified, the transformations are applied in the order listed.

      It is important to note that the ranking functions do not use any global information, so it
      is impossible to produce a fair normalization to 1% or 100% as sometimes desired. Normalization
      option 32 (rank/(rank+1)) can be applied to scale all ranks into the range zero to one, but of
      course this is just a cosmetic change; it will not affect the ordering of the search results.

  In Evergreen, these options are set via search modifiers.  The modifiers are mapped in the
  following way:

      * #CD_logDocumentLength  => 1  :: rank / (1 + LOG(total_word_count))   :: Longer documents slightly less relevant
      * #CD_documentLength     => 2  :: rank / total_word_count              :: Longer documents much less relevant
      * #CD_meanHarmonic       => 4  :: Word Proximity                       :: Greater matched-word distance is less relevant
      * #CD_uniqueWords        => 8  :: rank / unique_word_count             :: Documents with repeated words much less relevant
      * #CD_logUniqueWords     => 16 :: rank / (1 + LOG(unique_word_count))  :: Documents with repeated words slightly less relevant
      * #CD_selfPlusOne        => 32 :: rank / (1 + rank)                    :: Cosmetic normalization of rank value between 0 and 1

  Adding one or more of these to the default_CD_modifiers list will cause all searches that use QueryParser to apply them.

git-svn-id: svn://svn.open-ils.org/ILS/trunk@20180 dcc99617-32d9-48b4-a31d-7c20da2025e4
Open-ILS/examples/opensrf.xml.example
Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm
Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/fts.pm
Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/metabib.pm