3:marklogic relevance算法
这个是marklogic核心针对score/relevance的处理机制,它提供了5种不同的方案。你可以设置search option来限定你当下的search使用怎样的relevance算法。
A:logTF*logIDF
score-logtfidf
这个算法侧重词义的重要性。比如你查询:theMarklogic。这个phase中显而易见的the这个词的搜索并不重要,重要的是Marklogic在文档中出行的情况。而往往这样的case中the的出现频率远远高于Marklogic。因此如何在search结果集中保持marklogic这个关键词的出现文档维持高relevance。正是这个算法的目标。
B:logTF
score-logtf
直接只考虑TF(term frequency)。同时还考虑dcocument的size。
例如一个词在一片文章中出现了10次,而这个文章总共用1000个字。而在第二篇文章中出现了100次,而该文章的size为10000个字。那么第一篇的score将会高于第二篇。
相对
C: Simple Term Match Calculation
score-simple
这个很好理解,而且很直观简单。意思就是只要文章中出现了要找的词,那么就contribute一定数量的weight。它不考虑出现的频率。如:theMarklogic。 The在document中出现了100次,marklogic在文档中出现了5次。但是他们对relevance的贡献是一致的都是8(8是marklogic内部默认的权重值)
D: Random Score Calculation
score-random
这个东东的目的还真不知道!说是使用了这个option,那么每次runtime时会随机的为每个match的结果term赋予分值。因此在多次run这样的search时,并不会因为你的search term条件不变而结果集的显示sorting的顺序保持不变。
4:coding
说了这么多了,在整个marklogic的处理流程里,我们已经包含了:文档上传—〉数据库设置(机制的选择)--〉search:searchoption设置àcoding
看起来就差coding的支持了。我们知道其他三项都是属于application级别的,你架构设计文档结构(目录)制定权重,配置数据库设置满足common的一个算法需要,设置你的searchoption配置common的search效果。 而coding的方式是必须要提供的,它往往提供异常灵活的处理,对于特殊场景下的search做特定的relevence的处理。因此coding最灵活。
Marklogic coding方式relevence计算的体现就是你可以对每一个cts:query expression设置权重,进而来影响score/relevance。
Adding Weights to cts:query Expressions
可以这样理解,core的计算分为2大块,一块给予静态的index/fragment,权重信息要么已经定义,要么根据TF在fragment中的频度设置。一块基于动态的query expression,你可以runtime设置权重。
Scores arecalculated based on index data, and therefore based on unfiltered searches.That has
several implications to scores:
• Scores are fragment-based, so term frequency and document frequency are calculated
based on termfrequency per fragment and fragment frequency respectively.
• Scores are based on unfiltered searches, so they include false-positive results.