`
Tonyguxu
  • 浏览: 279746 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

lucene.search.Similarity

 
阅读更多

Similarity defines the components of Lucene scoring. Overriding computation of these components is a convenient way to alter Lucene scoring.

Suggested reading: Introduction To Information Retrieval, Chapter 6 .

The following describes how Lucene scoring evolves from underlying information retrieval models to (efficient) implementation. We first brief on VSM Score , then derive from it Lucene's Conceptual Scoring Formula , from which, finally, evolves Lucene's Practical Scoring Function (the latter is connected directly with Lucene classes and methods).

Lucene combines Boolean model (BM) of Information Retrieval with Vector Space Model (VSM) of Information Retrieval - documents "approved" by BM are scored by VSM. 注:研究下booleanQuery

In VSM, documents and queries are represented as weighted vectors(加权向量) in a multi-dimensional space(注:维怎么来定?), where each distinct index term is a dimension , and weights are Tf-idf values.

VSM does not require weights to be Tf-idf values , but Tf-idf values are believed to produce search results of high quality, (查询品质)and so Lucene is using Tf-idf . Tf and Idf are described in more detail below, but for now, for completion, let's just say that for given term t and document (or query) x , Tf(t,x) varies with the number of occurrences of term t in x (when one increases so does the other) and idf(t) similarly varies with the inverse of the number of index documents containing term t .

VSM score of document d for query q is the Cosine Similarity of the weighted query vectors V(q) and V(d) :

cosine-similarity(q,d)   =  
V(q) · V(d)
–––––––––
|V(q)| |V(d)|
VSM Score


 
Where V(q) · V(d) is the dot product of the weighted vectors, and |V(q)| and |V(d)| are their Euclidean norms .

Note: the above equation can be viewed as the dot product of the normalized(归一化) weighted vectors , in the sense that dividing V(q) by its euclidean norm is normalizing it to a unit vector.

Lucene refines VSM score for both search quality and usability:

  • Normalizing V(d) to the unit vector is known to be problematic in that it removes all document length information . For some documents removing this info is probably ok, e.g. a document made by duplicating a certain paragraph 10 times, especially if that paragraph is made of distinct terms. But for a document which contains no duplicated paragraphs, this might be wrong. To avoid this problem, a different document length normalization factor is used, which normalizes to a vector equal to or larger than the unit vector: doc-len-norm(d) .
  • At indexing, users can specify that certain documents are more important than others, by assigning a document boost. For this, the score of each document is also multiplied by its boost value doc-boost(d) .注: document boost
  • Lucene is field based, hence each query term applies to a single field, document length normalization is by the length of the certain field, and in addition to document boost there are also document fields boosts .
  • The same field can be added to a document during indexing several times, and so the boost of that field is the multiplication of the boosts of the separate additions (or parts) of that field within the document.
  • At search time users can specify boosts to each query, sub-query, and each query term, hence the contribution of a query term to the score of a document is multiplied by the boost of that query term query-boost(q) .
  • A document may match a multi term query without containing all the terms of that query (this is correct for some of the queries), and users can further reward documents matching more query terms through a coordination factor , which is usually larger when more terms are matched: coord-factor(q,d)

Under the simplifying assumption of a single field in the index, we get Lucene's Conceptual scoring formula :

score(q,d)   =   coord-factor(q,d) ·   query-boost(q) ·  
V(q) · V(d)
–––––––––
|V(q)|
  ·   doc-len-norm(d)   ·   doc-boost(d)
Lucene Conceptual Scoring Formula

 

The conceptual formula is a simplification in the sense that (1) terms and documents are fielded and (2) boosts are usually per query term rather than per query.

We now describe how Lucene implements this conceptual scoring formula, and derive from it Lucene's Practical Scoring Function . (Lucene Conceptual Scoring Formula VS Lucene's Practical Scoring Function .)

For efficient score computation some scoring components are computed and aggregated in advance:

  • Query-boost for the query (actually for each query term) is known when search starts.
  • Query Euclidean norm |V(q)| can be computed when search starts, as it is independent of the document being scored. From search optimization perspective, it is a valid question why bother to normalize the query at all, because all scored documents will be multiplied by the same |V(q)| , and hence documents ranks (their order by score) will not be affected by this normalization. There are two good reasons to keep this normalization:
    • Recall that Cosine Similarity can be used find how similar two documents are. One can use Lucene for e.g. clustering, and use a document as a query to compute its similarity to other documents. In this use case it is important that the score of document d3 for query d1 is comparable to the score of document d3 for query d2 . In other words, scores of a document for two distinct queries should be comparable. There are other applications that may require this. And this is exactly what normalizing the query vector V(q) provides: comparability (to a certain extent) of two or more queries.
    • Applying query normalization on the scores helps to keep the scores around the unit vector, hence preventing loss of score data because of floating point precision limitations.
  • Document length norm doc-len-norm(d) and document boost doc-boost(d) are known at indexing time. They are computed in advance and their multiplication is saved as a single value in the index: norm(d) . (In the equations below, norm(t in d) means norm(field(t) in doc d) where  field(t) is the field associated with term t .)

Lucene's Practical Scoring Function is derived from the above. The color codes demonstrate how it relates to those of the conceptual formula:

 

score(q,d)   =   coord(q,d)  ·  queryNorm(q)  ·  ( tf(t in d)  ·  idf(t) 2  ·  t.getBoost()  ·  norm(t,d) )

t in q
Lucene Practical Scoring Function

where

  1. tf(t in d) correlates to the term's frequency , defined as the number of times term t appears in the currently scored document d . Documents that have more occurrences of a given term receive a higher score. Note that tf(t in q) is assumed to be 1 and therefore it does not appear in this equation, However if a query contains twice the same term, there will be two term-queries with that same term and hence the computation would still be correct (although not very efficient). The default computation for tf(t in d) in DefaultSimilarity is:
     
    tf(t in d)   =   frequency½

     
  2. idf(t) stands for Inverse Document Frequency. This value correlates to the inverse of docFreq (the number of documents in which the term t appears). This means rarer terms give higher contribution to the total score. (注:好比是人都有很多特征,如果某个特征大家都有,那么根据这个特征就不容易区分人,针对一次查询,所有结果里idf值是一样的)idf(t) appears for t in both the query and the document, hence it is squared in the equation. The default computation for idf(t) in DefaultSimilarity is:
     
    idf(t)   =   1 + log (
    numDocs
    –––––––––
    docFreq+1
    )
     the inverse of docFreq
    docFreq越小,对total score的贡献越大idf越大,由公式表示docFreq越小,对total score的贡献越大 。
     
  3. coord(q,d) is a score factor based on how many of the query terms are found in the specified document(完全匹配部分匹配??). Typically, a document that contains more of the query's terms will receive a higher score than another document with fewer query terms. This is a search time factor computed in coord(q,d) by the Similarity in effect at search time.

     
    //DefaultSimilarity里实现
    @Override
      public float coord(int overlap, int maxOverlap) {
        return overlap / (float)maxOverlap;
     }
     
     
  4. queryNorm(q) is a normalizing factor used to make scores between queries comparable. This factor does not affect document ranking (since all ranked documents are multiplied by the same factor), but rather just attempts to make scores from different queries (or even different indexes) comparable. This is a search time factor computed by the Similarity in effect at search time. The default computation in DefaultSimilarity produces a Euclidean norm :
     
    queryNorm(q)   =   queryNorm(sumOfSquaredWeights)   =  
    1
    ––––––––––––––
    sumOfSquaredWeights½

     
    The sum of squared weights (of the query terms) is computed by the query Weight object. For example, a BooleanQuery computes this value as:
     
    sumOfSquaredWeights   =   q.getBoost() 2  ·  ( idf(t)  ·  t.getBoost() ) 2

    t in q


  5. t.getBoost() is a search time boost of term t in the query q as specified in the query text (see query syntax ), or as set by application calls to setBoost() . Notice that there is really no direct API for accessing a boost of one term in a multi term query, but rather multi terms are represented in a query as multi TermQuery objects, and so the boost of a term in the query is accessible by calling the sub-query getBoost() .

     写道
    这里的t.getBoost为查询时设定的某个term的boost。
    下面norm(t,d)里Document boost和Field boost为索引时设定的boost。

    关于如何在index/search时设定boost,参考
    http://nemogu.iteye.com/admin/blogs/1452831
     
     
  6. norm(t,d) encapsulates a few (indexing time) boost and length factors:
    • Document boost - set by calling doc.setBoost() before adding the document to the index.
    • Field boost - set by calling field.setBoost() before adding the field to a document.
    • lengthNorm - computed when the document is added to the index in accordance with(与。。一致) the number of tokens of this field in the document, so that shorter fields contribute more to the score. LengthNorm is computed by the Similarity class in effect at indexing.

       写道
      疑问:在使用IndexSearcher.explain(query,document)获得的Explaination.toString()里有
      0.1875 = fieldNorm(field=content, doc=18137) ,fieldNorm与这里的lengthNorm有什么区别?

      fieldNorm是怎么计算的?为什么小于1呢?
      lengthNorm是表示在一个document里某field里token的数目么?如果是的话应该是大于1的啊?

       

    The computeNorm(java.lang.String, org.apache.lucene.index.FieldInvertState) method is responsible for combining all of these factors into a single float.
     写道
    》》Similarity的computeNorm

    public abstract float computeNorm(String field,FieldInvertState state)

    Computes the normalization value for a field, given the accumulated state of term processing for this field (see FieldInvertState).
    Implementations should calculate a float value based on the field state and then return that value.

    Matches in longer fields are less precise, so implementations of this method usually return smaller values when state.getLength() is large, and larger values when state.getLength() is small.
    该方法的实现方法里应该按照:state.getLength() (document里某field的term数目)越大,返回的值越小。

    Note that the return values are computed under IndexWriter.addDocument(org.apache.lucene.document.Document) and then stored using encodeNormValue(float). Thus they have limited precision, and documents must be re-indexed if this method is altered.

    For backward compatibility this method by default calls lengthNorm(String, int) passing FieldInvertState.getLength() as the second argument, and then multiplies this value by FieldInvertState.getBoost().

    》》DefaultSimilarity的computeNorm
    Implemented as state.getBoost()*lengthNorm(numTerms), where numTerms is FieldInvertState.getLength() if setDiscountOverlaps(boolean) is false, else it's FieldInvertState.getLength() - FieldInvertState.getNumOverlap().
    代码如下:
    @Override
    public float computeNorm(String field, FieldInvertState state) {
    final int numTerms;
    if (discountOverlaps)
    numTerms = state.getLength() - state.getNumOverlap();
    else
    numTerms = state.getLength();
    return state.getBoost() * ((float) (1.0 / Math.sqrt(numTerms)));
    }

     
      DefaultSimilarity 里 lengthNorm 的计算公式
    lengthNorm = (float) (1.0 / Math.sqrt(numTerms))
     
     如果想要改变lengthNorm的计算公式或者忽略lengthNorm(lengthNorm=1),该如何做?
    在自定义的CustomSimilarity实现类中重写Similarity抽象类中定义的
    public float computeNorm(String field, FieldInvertState state)

    如果想忽略lengthNorm可以这样写

    @Override
    public float computeNorm(String field, FieldInvertState state) {
    final int numTerms = 1;
    return state.getBoost() * numTerms;
    }

    还需要告诉IndexWriter使用自定义的CustomSimilarity
    indexWriter.setSimilarity(Similarity similarity)
    在3.4版本中该方法是过时的,可以在IndexWriterConfig setSimilarity(Similarity similarity)

     

    When a document is added to the index, all the above factors are multiplied. If the document has multiple fields with the same name, all their boosts are multiplied together:

    norm(t,d)   =   doc.getBoost()  ·  lengthNorm  ·  f.getBoost ()

    field f in d named as t

     
    However the resulted norm value is encoded as a single byte before being stored. At search time, the norm byte value is read from the index directory and decoded back to a float norm value. This encoding/decoding, while reducing index size, comes with the price of precision loss - it is not guaranteed that decode(encode(x)) = x . For instance, decode(encode(0.89)) = 0.75 .
     
    Compression of norm values to a single byte saves memory at search time, because once a field is referenced at search time, its norms - for all documents - are maintained in memory.
     
    The rationale supporting such lossy compression of norm values is that given the difficulty (and inaccuracy) of users to express their true information need by a query, only big differences matter.
     
    Last, note that search time is too late to modify this norm part of scoring, e.g. by using a different Similarity for search.
     

 

 

See Also:
setDefault(Similarity) , IndexWriter.setSimilarity(Similarity) , Searcher.setSimilarity(Similarity) , Serialized Form
分享到:
评论

相关推荐

    Lucene实战源码

    `org.apache.lucene.search.Scorer`和`org.apache.lucene.search.similarity.Similarity`类参与评分计算。 6. **更新与删除**:Lucene支持对索引进行修改,`IndexWriter`类提供了添加、删除和更新文档的方法。 7. ...

    Annotated Lucene 中文版 Lucene源码剖析

    - `org.apache.lucene.search.Similarity`接口定义了如何计算文档与查询之间的相关度评分。 - 常见的实现包括`ClassicSimilarity`和`BM25Similarity`等,它们采用了不同的算法来评估文档的重要性。 通过对上述...

    Linux源码剖析

    - **`org.apache.lucene.search.Similarity`**:定义了文档评分的标准接口。 - **Similarity 评分公式**:Lucene 默认使用 BM25 评分算法来计算文档的相关度得分。BM25 是一种基于概率的评分模型,考虑到了文档长度...

    lucene 自定义评分

    在 Lucene 中,我们可以创建一个继承自 `org.apache.lucene.search.Similarity` 类的子类,重写其中的方法来实现自定义的评分逻辑。`Similarity` 类是 Lucene 中用于计算评分的核心接口,包含了诸如 `lengthNorm`...

    lucene.rar

    但其API设计灵活,可与其他框架(如Spring、Hibernate)集成,也可以配合Solr或Elasticsearch等扩展工具,构建分布式、高性能的搜索引擎。 7. **多语言支持**:Lucene不仅支持英文,还提供了对多种语言(如中文、...

    lucene源码

    `org.apache.lucene.search` 包中的 `IndexSearcher` 类执行搜索操作,而 `ScoreDoc` 和 `TopDocs` 分别用于存储搜索结果的排名和分数。 **2. Lucene 的工作流程** - **创建索引**:首先,通过 `Analyzer` 对文本...

    lucene实战源码.rar

    7. **分布式搜索**:如果你深入到高级部分,可能会看到关于Solr或Elasticsearch(基于Lucene的分布式搜索平台)的示例,它们展示了如何在分布式环境中使用Lucene。 8. **实时搜索**:Lucene提供了实时索引能力,即...

    官方最新完整版lucene-6.6.0.zip

    在实际项目中,开发者通常会结合Lucene与其他框架,如Spring、Solr或Elasticsearch,来构建更复杂的搜索引擎。例如,通过Spring集成Lucene,可以轻松地在Web应用中实现全文搜索功能。 五、优化与维护 1. **内存管理...

    lucene-4.2.1-src.tgz

    10. **分布式搜索**:虽然单个Lucene实例可以处理大量数据,但当数据量更大时,可以通过Solr或Elasticsearch等基于Lucene的项目实现分布式搜索。 通过研究`lucene-4.2.1-src.tgz`中的源代码,开发者不仅可以理解...

    Lucene索引搜索简介以及入门实例源码.rar

    5. **相似性(Similarity)**:调整评分算法,根据文档的相关性对结果排序。 6. **复杂查询语法**:支持布尔逻辑、短语查询、范围查询等多种复杂的查询表达式。 这个压缩包中的源码很可能是演示了如何构建和使用...

    lucene高级应用

    1. Solr或Elasticsearch:这两个基于Lucene的高级框架提供了分布式搜索能力,可以处理大规模数据并实现负载均衡。 通过上述高级应用,开发者可以充分利用Lucene的强大功能,构建出满足复杂需求的搜索引擎。无论是...

    Lucene全文搜索_LuceneJava全文搜索_

    此外,Lucene还提供了近似度评分(Similarity Scoring),根据查询词在文档中的出现频率和位置给出相关性分数,帮助用户找到最相关的搜索结果。 智能查询则涉及到更复杂的查询构造,如前缀查询(Prefix Query)、...

    lucene包,lucene实现核心代码

    - Lucene允许开发者自定义Analyzer、Similarity、Filter等,以满足特定的搜索需求。 7. **多语言支持**: - Lucene提供对多种语言的文本处理支持,如中文、法文、德文等,通过选择合适的Analyzer。 8. **内存和...

    lucene-2.9.0-src.tar.gz

    Lucene社区活跃,不断有新的改进和扩展,如Solr和Elasticsearch,它们基于Lucene提供更高级的服务,如分布式搜索、集群管理和数据分析。 总结,通过对“lucene-2.9.0-src.tar.gz”的研究,我们可以深入学习全文检索...

    lucene-constant-tf-similarity:Lucene和Elasticsearch的恒定tf相似性

    在深入探讨“lucene-constant-tf-similarity”这个主题之前,我们首先需要理解Lucene和Elasticsearch的基本概念。Lucene是一个开源的全文搜索引擎库,由Java编写,提供了强大的文本分析和索引功能。而Elasticsearch...

    lucene jar包

    - **评分器(Similarity)**:定义了如何根据文档的相关性对搜索结果进行排序,可以自定义实现以适应特定需求。 3. **高级特性** - **多字段搜索**:允许在多个字段上进行查询,通过设定字段权重来调整不同字段的...

    Lucene5学习之评分Scoring

    在`org.apache.lucene.search`包下,`Similarity`类是评分的基础,提供了默认的TF-IDF实现。你可以根据需求自定义子类,覆盖其方法来改变评分行为。同时,`Weight`和`ScoreDoc`接口提供了关于查询和评分的具体实现...

    lucene API文档

    4. **Near Real-time Search**: Lucene支持近乎实时的搜索,即添加或更新文档后,几乎立即可以在搜索结果中看到变化。 总之,Lucene 2.1 API提供了强大的文本搜索功能,虽然版本较老,但其设计理念和核心API对理解...

Global site tag (gtag.js) - Google Analytics