Elasticsearch scoring detailed explanation

【Elasticsearch】打分策略详解与explain手把手计算 Elasticsearch打分公式的计算,ES的打分与Lucene的不同之处,如何跟explain的计算对照上,手把手教你如何手算explain分数 阅读详情

Score computation mechanism

I am learning Elasticsearch these days, so I’m really curious about how Elasticsearch compute the score of retrieved documents.

在Elasticsearch的官方文档中,给出了文档score的计算的公式,但是其中有个queryNorm官方给出的解释非常的不清晰,但是我又很想知道在做查询的时候针对不同的field的query-time boosting 是如何添加到score 的计算过程中的,所以花了一些时间特别的研究了一下每一步的score的计算方式。下面会详细给出queryNorm的计算过程。

文本主要参考 Lucene’s Practical Scoring Function 中给出的score计算公式。

Important backgroud to keep in Mind

一定要记住,在Elasticsearch计算每个document score的时候,是以shard为单位的,也就是说计算 tf,idf,norm的时候,不是以index为基本单位,而是以shard为基本单位,这就涉及到了Elasticsearch建立索引的内部机制, 因为Elasticsearch的每一个索引可以分为多个shard,每个shard有可能分布在不同的服务器上,所以以shard为基本单位计算score是合理的,如果一个index包含多个shard,那个搜索会在每个shard上进行,然后计算每个shard内找到的文档的score,最终将所有的shard的结果根据score进行重新排序。

同时,还要注意一点,就是即使以shard为单位,其实在真正计算score的时候,是分别在一篇文档的每个field上进行计算,然后将不同的field上的score的加起来作为整个文档的最终score。(其实Elasticsearch每个field都分别建立了一个索引)

Score Equation

Lucene’s Practical Scoring Function 中给出的score计算公式如下:

score(q,d)=queryNorm(q)⋅coord(q,d)⋅∑(tf(tind)⋅idf(t)²⋅t.getBoost()⋅norm(t,d))(tinq) (1)

上面的公式中,大部分都是比较简单好理解的,最复杂的部分在queryNorm,接下来会给出queryNorm的详细计算过程。

score(q,d) 是在每个field上分别计算的,然后求和(也取决于你是如何让Elasticsearch计算的)。

  • Term frequency
    tf(t in d) = √frequency
    The term frequency (tf) for term t in document d is the square root of the number of times the term appears in the document.
    其实tf是在field中进行统计的。

  • Inverse document frequency
    idf(t) = 1 + log ( numDocs / (docFreq + 1))

    The inverse document frequency (idf) of term t is the logarithm of the number of documents in the index, divided by the number of documents that contain the term.
    IDF也是在field中进行计算的。

  • Field-length norm
    norm(d) = 1 / √numTerms

    The field-length norm (norm) is the inverse square root of the number of terms in the field.

上面的这三个特征是在文本检索中最常用的,在Elasticsearch中把他们三个相乘获得token的一个特征: tf * idf * norm

Elasticsearch并没有采用Vector Space Model, 因为计算文档的向量比较费时间,而是采用了结合Boolean Model, TF/IDF Model 和Vector Space Model三种相结合的方式进行score计算。

在公式(1)中可以看到,针对query中的每个token都计算了该token的每个field的score, 然后将每个token的分数加起来,乘上queryNorm(q) 和coord(q,d) 就是最终的score。

要特别注意,虽然Elasticsearch官方给出的公式在计算每个token的 score的时候乘上了 t.getBoost(),但是实际在操作的时候并不是这样进行的。实际计算的时候是把 t.getBoost() 放到了queryNorm(q) 计算中,并且queryNorm(q) 的计算也结合了 query-time boosting.
t.getBoost()的官方解释:t.getBoost()
In fact, reading the explain output is a little more complex than that. You won’t see the boost value or t.getBoost() mentioned in the explanation at all. Instead, the boost is rolled into the queryNorm that is applied to a particular term. Although we said that the queryNorm is the same for every term, you will see that the queryNorm for a boosted term is higher than the queryNorm for an unboosted term.

所以,实际的计算过程,在每个token的每篇文档的得分只有: tf*idf*norm.
并且,这个公式中的 idf(t)² 也是不对的,根据elasticsearch给出的文档得分解释,应该是idf(t),而不是idf(t)² .

特别强调: 每个token的tf, idf, norm的计算都是以field为基础的。

Query Coordination

公式中的coord(q,d)比较好理解,大体意思就是说,如果query中有三个单词,那么在查找到的文档中,这三个单词出现的个数越多,则这个文档的相关性越大。
例如,我查询“oracle database setup”
在查找到的doc1的title field 中,只出现了两个单词“oracle database”,那么这篇文档的field的coord(q,d)=2/3.

The coordination factor (coord) is used to reward documents that contain a higher percentage of the query terms. The more query terms that appear in the document, the greater the chances that the document is a good match for the query.

Imagine that we have a query for quick brown fox, and that the weight for each term is 1.5. Without the coordination factor, the score would just be the sum of the weights of the terms in a document. For instance:

Document with fox → score: 1.5
Document with quick fox → score: 3.0
Document with quick brown fox → score: 4.5
The coordination factor multiplies the score by the number of matching terms in the document, and divides it by the total number of terms in the query. With the coordination factor, the scores would be as follows:

Document with fox → score: 1.5 * 1 / 3 = 0.5
Document with quick fox → score: 3.0 * 2 / 3 = 2.0
Document with quick brown fox → score: 4.5 * 3 / 3 = 4.5
The coordination factor results in the document that contains all three terms being much more relevant than the document that contains just two of them.

Query Normalization Factor

最后就剩下最难的queryNorm(q)啦,官方给出的解释稀里糊涂的,如下:
The query normalization factor (queryNorm) is an attempt to normalize a query so that the results from one query may be compared with the results of another.
queryNorm(q)的好处是使得不同的查询的结果的得分在同一个空间中,这个即使是不同的查询的结果也可以直接比较。

Even though the intent of the query norm is to make results from different queries comparable, it doesn’t work very well. The only purpose of the relevance _score is to sort the results of the current query in the correct order. You should not try to compare the relevance scores from different queries.

This factor is calculated at the beginning of the query. The actual calculation depends on the queries involved, but a typical implementation is as follows:
queryNorm = 1 / √sumOfSquaredWeights
The sumOfSquaredWeights is calculated by adding together the IDF of each term in the query, squared.
The same query normalization factor is applied to every document, and you have no way of changing it. For all intents and purposes, it can be ignored.

按照官方的这个说法,根本计算不出来在elasticsearch explain中的queryNorm。所以,咱们再看看lucene中是怎么定义的?

queryNorm in Lucene

TFIDFSimilarity中,对于queryNorm的定义如下:

queryNorm(q)=queryNorm(sumOfSquaredWeights)=1sumOfSquaredWeights1/2

sumOfSquaredWeights=q.getBoost()2⋅∑(idf(t)⋅t.getBoost())2(t in q)

恩,这下子比较明白了,但是,q.getBoost()和t.getBoost()怎么得到?貌似就没有下文了。
Lucene只有下面的解释:
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().
这个解释基本上没有什么帮助。

针对我之前的问题,我主要是想弄明白在给不同的field不同的boost之后,boost信息是如何整合到queryNorm(q)中的。
然后,经过一段非常痛苦的调查,我弄明白了boost信息是如何计算到queryNorm(q)里的。

例如:我们要在elasticsearch中做如下查询:

GET /test/news/_search?explain
{
  "query": {
    "multi_match": {
      "query": "apple iphone6",
      "fields": ["title^3", "body^2"],
      "type": "most_fields"
    }
  }
}

这里,我的文档有”title”,”body”等字段,我想在“title”“body”两个字段上查询,并且给title field 一个3的boost, body field一个2的boost,并且我希望将每个字段上的得分加起来最为整个文档得得分(”type”: “most_fields”)。

这里我们可以理解为q.getBoost()在title字段得到3, 在body字段得到2,t.getBoost()在title字段得到3,body字段得到2.
按照上面的sumOfSquaredWeights的计算公式,并不能得到elasticseach给出的explain中得queryNorm值。

根据这个具体得例子,在某个field中的真实的queryNorm的真实的计算公式为:

sumOfSquaredWeights=(1fieldBoost)2⋅∑t inq(∑((idf(t)⋅t.getBoost())2)(field in searchFields))

真心搞了了好久才弄明白是通过这个公式计算sumOfSquaredWeights的,那些再非法转载的,诅咒点什么好呢。
通过这个公式,可以清楚的看出field boost以及其他的boost的信息使如何整合到queryNorm中的。

好了,公式都搞明白了。通过一个实例计算下看看。

实例计算

首先,需要设置一下index, 让我们得index只有一个shard, 这样score看起来比较简单一些。在有多个shard的情况下,会根据doc id进行hash运算,然后决定把doc放入哪个shard,那种情况下我们不能清楚得知道shard中包含哪些文档,不能清楚的计算得到tf,idf,nrom.

PUT /test
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

再做个简单的mapping

PUT /test/_mapping/news
{
  "properties": {
    "title": {
      "type": "string",
      "analyzer": "english"
    },
    "body": {
      "type": "string",
      "analyzer": "english"
    },
    "version": {
      "type": "string",
      "analyzer": "english"
    }
  }
}

然后,index两个文章,

PUT /test/news/1
{
  "title": "apple released iphone",
  "body": "last day, apple company has released their latest product iphone 6, which is the biggest ihpone in histroy"
}

PUT /test/news/2
{
  "title": "microsoft suied apple",
  "body": "microsoft told that apple has used many of their patents, apple need to pay for these patents for 12 billion"
}

好啦,搜索来啦:

GET /test/news/_search?explain
{
  "query": {
    "multi_match": {
      "query": "apple iphone",
      "fields": ["title^8", "body^3"],
      "type": "most_fields"
    }
  }
}

JSON的检索结果比较多,所以就不全部给出了。给出部分跟我们计算相关得:
1. 首先是apple在文档1的title中的计算得分:

{
                                 "value": 0.14224225,
                                 "description": "score(doc=0,freq=1.0), product of:",
                                 "details": [
                                    {
                                       "value": 0.4784993,
                                       "description": "queryWeight, product of:",
                                       "details": [
                                          {
                                             "value": 0.5945349,
                                             "description": "idf(docFreq=2, maxDocs=2)"
                                          },
                                          {
                                             "value": 0.80482966,
                                             "description": "queryNorm"
                                          }
                                       ]
                                    },
                                    {
                                       "value": 0.29726744,
                                       "description": "fieldWeight in 0, product of:",
                                       "details": [
                                          {
                                             "value": 1,
                                             "description": "tf(freq=1.0), with freq of:",
                                             "details": [
                                                {
                                                   "value": 1,
                                                   "description": "termFreq=1.0"
                                                }
                                             ]
                                          },
                                          {
                                             "value": 0.5945349,
                                             "description": "idf(docFreq=2, maxDocs=2)"
                                          },
                                          {
                                             "value": 0.5,
                                             "description": "fieldNorm(doc=0)"
                                          }
                                       ]
                                    }
                                 ]
                              }

我们可以自己计算,apple 的tf = 1, idf = 1+Math.log(maxDocs=2/ (1+1)) = 0.5945349,
field norm = 1 / √3 = 0.5773502691896258, 但是由于elasticsearch只采用了一个字节保存这个norm值,所以精度丢失,变成了0.5。

然后,到了最关键得计算queryNorm啦:
定义:
apple 在title的 idf 为 idf1: idf1 = 0.5945349
apple 在body的 idf 为 idf2: idf2 = 0.5945349
apple在title,body两个字段都在两个文档中出现过,所以idf1=idf2=1+log(2/3)
iphone 在title的 idf 为 idf3: idf3 = 1 = 1 + log(2/2)
iphone 在body的 idf 为 idf4: idf4 = 1
iphone在title, body两个字段都只在一个文档中出现,所以idf1=idf2 = 1 + log(2/2)

然后计算sumOfSquaredWeights:
这个query在title中的sumOfSquaredWeights:
1/8 * 1/8 * (idf1 * idf1 * 8 * 8 + idf2 * idf2 * 3 * 3 + idf3 * idf3 * 8 * 8 + idf4 * idf4 * 3 * 3) = 1.543803711784605
queryNorm = 1/Math.sqrt(1.543803711784605) = 0.8048296354648813

可以看到,这个query在title的queryNorm和elasticsearch给出的解释中的queryNorm完全一样。

这个query在body中的sumOfSquaredWeights:
1/3 * 1/3 * (idf1 * idf1 * 8 * 8 + idf2 * idf2 * 3 * 3 + idf3 * idf3 * 8 * 8 + idf4 * idf4 * 3 * 3)

queryNorm compare

当给定field boosting后,可以观察到,不同的field的queryNorm的比是和field boosting的比相等得。
本例中,
field boost 比为 8/3
queryNorm 比为 0.80482966/0.30181113 = 8/3

O(∩_∩)O哈哈~ COOL!

下面给出了这个query的所有explain结果,有兴趣的朋友可以自己算算:

{
   "took": 1,
   "timed_out": false,
   "_shards": {
      "total": 1,
      "successful": 1,
      "failed": 0
   },
   "hits": {
      "total": 2,
      "max_score": 0.6467803,
      "hits": [
         {
            "_shard": 0,
            "_node": "hwVl0ucyS_6Ps9-xQ2Ihbw",
            "_index": "test",
            "_type": "news",
            "_id": "1",
            "_score": 0.6467803,
            "_source": {
               "title": "apple released iphone",
               "body": "last day, apple company has released their latest product iphone 6, which is the biggest ihpone in histroy"
            },
            "_explanation": {
               "value": 0.6467803,
               "description": "sum of:",
               "details": [
                  {
                     "value": 0.5446571,
                     "description": "sum of:",
                     "details": [ { "value": 0.14224225, "description": "weight(title:appl in 0) [PerFieldSimilarity], result of:", "details": [ { "value": 0.14224225, "description": "score(doc=0,freq=1.0), product of:", "details": [ { "value": 0.4784993, "description": "queryWeight, product of:", "details": [ { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.80482966, "description": "queryNorm" } ] }, { "value": 0.29726744, "description": "fieldWeight in 0, product of:", "details": [ { "value": 1, "description": "tf(freq=1.0), with freq of:", "details": [ { "value": 1, "description": "termFreq=1.0" } ] }, { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.5, "description": "fieldNorm(doc=0)" } ] } ] } ] }, { "value": 0.40241483, "description": "weight(title:iphon in 0) [PerFieldSimilarity], result of:", "details": [ { "value": 0.40241483, "description": "score(doc=0,freq=1.0), product of:", "details": [ { "value": 0.80482966, "description": "queryWeight, product of:", "details": [ { "value": 1, "description": "idf(docFreq=1, maxDocs=2)" }, { "value": 0.80482966, "description": "queryNorm" } ] }, { "value": 0.5, "description": "fieldWeight in 0, product of:", "details": [ { "value": 1, "description": "tf(freq=1.0), with freq of:", "details": [ { "value": 1, "description": "termFreq=1.0" } ] }, { "value": 1, "description": "idf(docFreq=1, maxDocs=2)" }, { "value": 0.5, "description": "fieldNorm(doc=0)" } ] } ] } ] } ] },
                  {
                     "value": 0.10212321,
                     "description": "sum of:",
                     "details": [ { "value": 0.026670424, "description": "weight(body:appl in 0) [PerFieldSimilarity], result of:", "details": [ { "value": 0.026670424, "description": "score(doc=0,freq=1.0), product of:", "details": [ { "value": 0.17943723, "description": "queryWeight, product of:", "details": [ { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.30181113, "description": "queryNorm" } ] }, { "value": 0.14863372, "description": "fieldWeight in 0, product of:", "details": [ { "value": 1, "description": "tf(freq=1.0), with freq of:", "details": [ { "value": 1, "description": "termFreq=1.0" } ] }, { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.25, "description": "fieldNorm(doc=0)" } ] } ] } ] }, { "value": 0.07545278, "description": "weight(body:iphon in 0) [PerFieldSimilarity], result of:", "details": [ { "value": 0.07545278, "description": "score(doc=0,freq=1.0), product of:", "details": [ { "value": 0.30181113, "description": "queryWeight, product of:", "details": [ { "value": 1, "description": "idf(docFreq=1, maxDocs=2)" }, { "value": 0.30181113, "description": "queryNorm" } ] }, { "value": 0.25, "description": "fieldWeight in 0, product of:", "details": [ { "value": 1, "description": "tf(freq=1.0), with freq of:", "details": [ { "value": 1, "description": "termFreq=1.0" } ] }, { "value": 1, "description": "idf(docFreq=1, maxDocs=2)" }, { "value": 0.25, "description": "fieldNorm(doc=0)" } ] } ] } ] } ] }
               ]
            }
         },
         {
            "_shard": 0,
            "_node": "hwVl0ucyS_6Ps9-xQ2Ihbw",
            "_index": "test",
            "_type": "news",
            "_id": "2",
            "_score": 0.08997996,
            "_source": {
               "title": "microsoft suied apple",
               "body": "microsoft told that apple has used many of their patents, apple need to pay for these patents for 12 billion"
            },
            "_explanation": {
               "value": 0.08997996,
               "description": "sum of:",
               "details": [
                  {
                     "value": 0.07112113,
                     "description": "product of:",
                     "details": [ { "value": 0.14224225, "description": "sum of:", "details": [ { "value": 0.14224225, "description": "weight(title:appl in 0) [PerFieldSimilarity], result of:", "details": [ { "value": 0.14224225, "description": "score(doc=0,freq=1.0), product of:", "details": [ { "value": 0.4784993, "description": "queryWeight, product of:", "details": [ { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.80482966, "description": "queryNorm" } ] }, { "value": 0.29726744, "description": "fieldWeight in 0, product of:", "details": [ { "value": 1, "description": "tf(freq=1.0), with freq of:", "details": [ { "value": 1, "description": "termFreq=1.0" } ] }, { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.5, "description": "fieldNorm(doc=0)" } ] } ] } ] } ] }, { "value": 0.5, "description": "coord(1/2)" } ] },
                  {
                     "value": 0.018858837,
                     "description": "product of:",
                     "details": [ { "value": 0.037717674, "description": "sum of:", "details": [ { "value": 0.037717674, "description": "weight(body:appl in 0) [PerFieldSimilarity], result of:", "details": [ { "value": 0.037717674, "description": "score(doc=0,freq=2.0), product of:", "details": [ { "value": 0.17943723, "description": "queryWeight, product of:", "details": [ { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.30181113, "description": "queryNorm" } ] }, { "value": 0.21019982, "description": "fieldWeight in 0, product of:", "details": [ { "value": 1.4142135, "description": "tf(freq=2.0), with freq of:", "details": [ { "value": 2, "description": "termFreq=2.0" } ] }, { "value": 0.5945349, "description": "idf(docFreq=2, maxDocs=2)" }, { "value": 0.25, "description": "fieldNorm(doc=0)" } ] } ] } ] } ] }, { "value": 0.5, "description": "coord(1/2)" } ] }
               ]
            }
         }
      ]
   }
}
ElasticSearch 源码分析20 Explain 二、_explain 以上是对查询和分析过程进行说明,对于解释查询部分(好像和mysql挺像的),我们可以使用_explain向ElasticSearch询问庆于该文档是如何匹配(或者没有匹配上)的解释信息。例如,该文档能否在给定的查询中被检索到?如果找到了,ElasticSearch将返回分值计算的详细悠 ,以解释为什么该文档会匹配成功。 1.获取上下文context 2.然后根据请求的type和id,获取uidTerm 3.从上下文获取索引的分片indexShard,然后调用Get获取结果 阅读详情

相关推荐

ElasticSearch7.3学习(二十四)----相关度评分机制详解

relevance score(相关性分数) 算法,简单来说,就是计算出,一个索引中的文本,与搜索文本,他们之间的关联匹配程度。Elasticsearch使用的是 term frequency/inverse document frequency算法,简称为TF/IDF算法。TF词频(Term Frequency),IDF逆向文件频率(Inverse Document Frequency)搜索文本中的各个词条在field文本中出现了多少次,出现次数越多,就越相关。数学公司并不重要,看下面例子就清楚了。

1062

elasticsearch explain详解

es默认大多数及常用数据字段类型就是索引的,这也是es职责之所在,但是有时会有部分字段只是做存储,不做检索,这也会提高es性能。将index设置为false,则不索引,即不能对其检索。 属性store默认false,当某个数据字段很大,我们可以指定其它字段store为true,这样就不用从_source中取数据。 store 的意思是,是否在 _source 之外在独立存储一份,这里要说一下 _s

MCN的博客 2629

【Elasticsearch】 es 排查问题 explain 使用 内容解释

背景介绍 排查问题时需要分析问题成因,设置explain为true,打开分数打印后,公式虽然大差不离的看得懂,但是却忘了几个参数什么意思,在这里记录一下。 样例分析 首先任意选取一次explain的结果 图中很明显是在做tf和idf的计算,几个比较迷惑人的地方 542是什么意思 weight(topic_name:周杰伦 in 542) [PerFieldSimilarity], result of: 这里面的542一开始我误以为是docCount,后来发现不是…542是lucene文档内部的id,和外.

九师兄 3561

[ElasticSearch] explain使用方式与结果解析

例如上方我们对搜索进行我们搜索"文明",分词器为strandard,可以看到details将该词分解为'文','明'的两部分评分详情并描述了对其。ElasticSearch根据版本或配置会使用不同的评分方式,所以explain Api的explanation信息公式会有不同;这样对每项的计算都被包含在explain中,可以依据此对评分进行清晰的排查和计算。在此例中,我们可以看weight对应的details即为所的评分的详情信息;而每层对应所需的指标都嵌套在其details属性中;

weixin_42484190的博客 2560

elasticsearch-vector-scoring:对与ES具有纯点积余弦相似度的文档进行评分

用于Elasticsearch的矢量计分插件 注意:此插件的大多数功能现已在ES中本机支持: : 另请参阅 。 该插件不再维护 使用此插件,您可以使用点积或余弦相似度,根据任意原始向量对文档进行评分。 发行版 Master分支的目标是Elasticsearch 5.4。 请注意,不支持5.5+版本,因为Elasticsearch更改了其插件机制。 5.5+的更新将很快开发(欢迎PR)。 以Elasticsearch 2.4.x为目标 概述 该插件的目的是对基于矢量的模型,尤其是基于因子的推荐模型进行实时评分。 在这种情况下,将使用对用户和项目因子向量进行索引,例如将向量[1.2, 0.1, 0.4, -0.2, 0.3]索引为字符串: 0|1.2 1|0.1 2|0.4 3|-0.2 4|0.3 。 这将向量索引存储为“项”,将向量值存储为“有效载荷”。 计分 该插件提供了本

elasticsearch-vector-scoring

快速Elasticsearch向量计分 使用此插件,您可以使用点积或余弦相似度根据嵌入向量对Elasticsearch文档进行评分。 一般的 ES 6.1的更新版本 余弦线支持已删除。 这个插件的灵感来自和,使处理速度比原始快10倍。 lior-k通过直接使用lucene指数获得了显着的速度改进 lior-k为他们的工作场所开发了它,该工作场所需要从一组〜4M的向量中选择KNN。 他们当前的ES设置能够在约80ms内回答此问题 Elasticsearch版本 当前为Elasticsearch 6.1.2设计。 设置 为了安装此插件,您需要先通过运行以下命令创建一个zip发行版 gradle clean assemble 这将在build/distributions生成一个zip文件。 建立zip档案后,您可以像这样安装 elasticsearch-plugin install fi

elasticsearch之explain的使用

explain查看怎么计算得分的,format将json格式结果转为yaml展示 POST tlsmz/_search?format=yaml { "explain": true, "query": { "bool": { "must": [ { "term": { "fz.keyword": { "value": "南昌西" } }

种一颗十年前的树 7642

实战指南:基于华为Ascend NPU的大模型W8A8量化调优与精度提升

本文提供了一份基于华为Ascend NPU进行大模型W8A8量化的实战调优指南。详细介绍了从环境搭建、使用msmodelslim框架进行基础量化,到通过离群值抑制、校准集优化和量化回退等关键技术提升精度的全流程。旨在帮助开发者在华为NPU硬件上实现模型推理的显著加速,同时有效控制精度损失。

weixin_29227425的博客 271

ElasticSearch7.3学习(二十一)----Filter与Query对比、使用explain关键字分析语法

filter,不需要计算相关度分数,不需要按照相关度分数进行排序,同时还有内置的自动cache最常使用filter的数据。在实际的应用过程中,需要查询的逻辑一般比较复杂,那当语句冗长的时候,这时候显然不太可能通过直接执行语句来调试语法正确与否,这个时候就可以通过explain来验证语句的正确性。说明在使用query查询的过程中,影响到了相关度(score)的排序,在使用filter进行查询,并不会影响相关度(score)的计算。query,相反,要计算相关度分数,按照分数进行排序,而且无法cache结果。

639

使用模拟工具Modbus poll 和PLC 通讯

使用模拟工具Modbus poll 和PLC 通讯 简介 Modbus Poll 是一个模拟Modbus 主站的工具。不用在现场调试,在家也能使用,方便快捷的调试验证程序。使用它可以和PLC进行Modbus TCP /RTU 通讯等功能,接下来为大家介绍使用Modbus Poll 和 PLC 进行 Modbus TCP 通讯。 组态PLC PLC作为我们的从站和Modbus Poll 通讯,那我们组态一个PLC。 创建通信DB 创建一个DB块,在数据类型处输入:TCON_IP_V4

weixin_61398412的博客 1万+

WPF窗口定位技巧:从基础到高级的三种实现方法

本文详细解析WPF窗口定位的三种核心方法:屏幕居中(CenterScreen)、父窗口居中(CenterOwner)和手动定位(Manual)。通过对比其适用场景、实现代码与注意事项,帮助开发者根据实际需求选择最佳方案,从而提升WPF应用程序的用户体验与专业度。

weixin_29224309的博客 272

在Elasticsearch中使用脚本插件修改打分

在Elasticsearch中使用脚本插件修改打分

weixin_36340771的博客 1713

freeswitch系列二 kamailio 5.0安装及实现kamailio集成freeswitch

kamailio是个纯粹的SIP服务器。本文介绍先如何在debian8下安装debian5.0,然后详细介绍如何实现使用kamailio做freeswitch均衡负载。kamailio同时实现做为代理服务器、注册服务器、重定向服务器。

不积跬步无以至千里; 不积小流无以成江海 1万+

elasticsearch数据建模

类似于mysql数据库主外键,三范式 ,先根据条件查询到主键,再根据主键查询到对应的数据 PUT /website/users/1 { "name" : "小鱼儿", "email" : "1690780260@QQ.com", "birthday" : "1997-08-03" } PUT /website/blog/1 { "title"

紫一 533

使用DrissionPage和自动化技术实现得物鞋子信息爬取

本文介绍了一个基于DrissionPage技术的得物鞋子信息采集系统,能自动化采集商品图片、价格等数据并保存为Excel。系统采用浏览器模拟技术处理动态加载内容,通过XPath定位元素,实现智能交互和完整数据采集。关键技术包括:图片URL提取与下载、Excel数据集成与图片嵌入、文件名安全处理等。项目适用于市场分析和学术研究,强调必须遵守法律法规和平台规则,仅用于非商业用途。与API爬虫相比,浏览器自动化能更好处理现代Web应用,但需注意知识产权保护。

那些看似不起波澜的日复一日,会在某天让你看到坚持的意义 1666

UWB:FiRa Consortium UCI Generic Technical Specification v1.1.0(1)- UCI架构和通用数据包头

如果大家学习过WiFi的SPEC,比如从我的资源里面下载 IEEE 802.11-2007,应该很容易发现,FiRa的spec定义实在是太差了。有现成的好例子不学,非得自己来一套,搞一堆新的名词,其实都是一个意思。比如GID,OID等,而且GID、OID是最先出现的,但是对应表格 还得去附件的最后一项去找。 FiRa是UWB联盟,希望跟WIFi联盟学习一下,把UWB做大做强,而不是自成一派,自命不凡。

Ankie资深技术项目经理 2434

Elasticsearch - 理解字段分析过程(_analyze与_explain)

我们常常会遇到问题,为什么指定的文档没有被搜索到。很多情况下, 这都归因于映射的定义和分析例程配置存在问题。针对分析过程的调试,ElasticSearch提供了专用的REST API。_analyze, _explain是Elasticsearch提供的辅助API,经常不为人所知和所用。_explain 用来帮助分析文档的relevance score是如何计算出来的,而_analyze是Elas

上善若水,水善利万物而不争。 2万+

第 8 篇:TMC2240 电机正反转实现|DIR 引脚控制 + 代码优化(稳定不抖动)

本文详细介绍了TMC2240电机驱动芯片的正反转实现方法,重点解决方向切换时的抖动和冲击问题。文章首先明确了硬件连接、基础配置和使能状态三个前提条件,然后阐述了DIR引脚电平控制方向的核心原理,提供了STM32的GPIO配置代码。针对方向切换时的电流冲击问题,作者提出了"停止-延迟-切换-启动"的平滑切换逻辑,并给出了包含方向枚举、转速控制和方向切换函数的完整代码实现方案。通过这种优化方法,可以有效避免电机在正反转切换时产生的抖动、冲击声和发热问题,实现稳定的双向控制。文章还提示了后续可

BackCatK Chen的博客 2076

Elasticsearch Vector Scoring 使用教程

Elasticsearch Vector Scoring 使用教程 项目介绍 Elasticsearch Vector Scoring 是一个开源项目,旨在为 Elasticsearch 添加向量评分功能。通过这个插件,用户可以在 Elasticsearch 中使用向量相似度进行查询和评分,这在处理自然语言处理(NLP)和机器学习(ML)任务时非常有用。该项目基于 Elasticsearch 的插...

gitblog_01180的博客 649

Git救援:如何从误操作中恢复未提交的更改

摘要:本文探讨了误操作git reset --hard导致未提交更改丢失后的恢复方法。首先分析git reflog的局限性,随后介绍利用IDE本地历史记录(如IntelliJ IDEA和VS Code)进行文件恢复的具体步骤。最后建议使用文件系统恢复工具(如Linux的extundelete或Windows的Recuva)作为备选方案。文章强调定期提交的重要性,同时提供了意外发生时可行的恢复策略,帮助开发者尽可能挽回丢失的工作内容。(149字)

2501_90323865的博客 129

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

Elasticsearch 中的向量搜索:设计背后的基本原理

你是否有兴趣了解 Elasticsearch 用于向量搜索的特性以及设计是什么样子?一如既往,设计决策有利有弊。本博客旨在详细介绍我们如何选择在 Elasticsearch 中构建向量搜索。

Elastic 中国社区官方博客 3143

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

ElasticSearch评分分析 explian 解释和一些查询理解

ElasticSearch评分分析 explian 解释和一些查询理解 按照es-ik分析器安装了ik分词器。创建索引:PUT /index_ik_test。索引包含2个字段:content和nick,如下: GET index_ik_test/_mapping { "index_ik_test": { "mappings": { "fulltext": { ...

weixin_34161083的博客 407

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面,电脑运行连游戏界面都一样大小,很怀旧,很真实,(英文版)强烈推荐,很小的文件,很难才找到的。

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

[Elasticsearch] 控制相关度 (一) - 相关度分值计算背后的理论

本章翻译自Elasticsearch官方指南的Controlling Relevance一章。 控制相关度(Controlling Relevance) 对于仅处理结构化数据(比如日期,数值和字符枚举值)的数据库,它们只需要检查一份文档(在关系数据库中是一行)是否匹配查询即可。 尽管布尔类型的YES|NO匹配也是全文搜索的一个必要组成,它们本身是不够的。我们还需要

不忘初心,好好沉淀 2万+

Elasticsearch:Explain API - 如何计算分数

你想了解你的文档为何获得该分数吗?本文详细描述如何通过 BM25 来计算 Elasticsearch 搜索的分数。

Elastic 中国社区官方博客 2690

使用向量评分插件增强Elasticsearch的搜索体验

使用向量评分插件增强Elasticsearch的搜索体验 提示:本文档提及的插件不再维护,但其功能已被Elasticsearch原生支持。 向量评分插件是针对Elasticsearch的一款强大工具,它允许您基于任意原始向量进行文档评分,利用点乘或余弦相似度来实现。尽管此项目已不被积极维护,但它提供了一种创新的方式,让您可以将向量模型实时应用于搜索评分,尤其是在因子基推荐系统中。 项目简介 向量...

gitblog_00084的博客 460

3.10 Elasticsearch-结果可解释性:explain=true 与 Lucene explain 日志

掌握“value-description”速读法,配合慢日志批量审计,就能把“为什么 A 排在 B 前面”翻译成“idf 低、tf 高、boost 小”这类可量化指标,进而把调排序从玄学变成工程。explain 机制就是把 Lucene 的打分中间结果原样透出,让工程师、产品经理甚至运营都能一眼看出“这一分是怎么丢的、那一分是怎么加的”,从而把“调排序”变成“调特征”,而不是“调感觉”。如果没有量化依据,只能靠“BM25 公式就是这样”来搪塞,很快就会被要求“把公式改掉”。

IT老农民的博客 969
上一篇: Chinese Segmentation Introduction
下一篇: Similarity in Elasticsearch: A Brief Introduction to the Similarity Models Available
watkins
博客等级 码龄18年 1277粉丝 246原创
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值