본문 바로가기
개발/ALGOLIA

알고리아 Managing Results(3-9)

by dev_caleb 2022. 3. 3.
728x90

 

Controlling Precision of Custom Ranking Metrics

https://www.algolia.com/doc/guides/managing-results/must-do/custom-ranking/how-to/controlling-custom-ranking-metrics-precision/

 

Control precision of your custom ranking | Algolia

Improve your custom ranking by reducing granularity, so that similar records are ranked equally.

www.algolia.com

 

When you rank records with business metrics, you want to make sure the difference between those values is significant. Sometimes, the difference is too small to be taken into account. Yet, when the engine performs tie-breaking between two records, it doesn’t make a difference whether you have 1,000 or 1,003 more views on a blog article. If one has more than the other, it goes first. Therefore, you want to make sure that the values you use for custom ranking are properly weighted to avoid false positives.

비즈니스 메트릭으로 레코드의 순위를 매길 때 이러한 값 간의 차이가 유의해야 합니다. 때때로, 그 차이는 고려되기엔 너무 작습니다. 그러나 엔진이 두 레코드 간에 타이브레이킹을 수행할 때 블로그 기사를 1,000번 더 보든 1,003번 보든 차이가 없습니다. 한 쪽이 다른 쪽보다 많으면, 그것이 먼저입니다. 따라서 잘못된 긍정을 방지하기 위해 사용자 정의 순위에 사용하는 값의 가중치를 적절하게 부여해야 합니다.

To fix that issue, what you can do is reduce precision. An example is when you have blog articles, ranked per different attributes like unique page views and number of comments. You may have two posts with a close number of unique page views (1,000 and 1,003). Therefore, you don’t want the engine to break the tie on this attribute. Instead, you want to move on to the next criteria to get better tie-breaking and more relevant results.

이 문제를 해결하기 위해 당신이 할 수 있는 일은 정밀도를 줄이는 것입니다. 예를 들어, 고유한 페이지 보기 및 주석 수와 같은 서로 다른 속성에 따라 순위가 매겨진 블로그 기사가 있는 경우입니다. 고유한 페이지 보기 수(1,000개 및 1,003)가 근접한 두 개의 게시물이 있을 수 있습니다. 따라서 엔진이 이 특성의 차이를 좁히지 않도록 해야 합니다. 대신 다음 기준으로 이동하여 관계를 개선하고 보다 관련성이 높은 결과를 얻으려고 합니다.

 

 

 

Modifying the data: an example#

Before#

Let’s say we’re adding search to a blog. Besides Algolia’s default ranking formula, we’ve set two custom ranking attributes: pageviews first, followed by comments. Here’s what the dataset would look like:

블로그에 검색을 추가한다고 가정해 보겠습니다. Algolia의 기본 순위 공식 외에도 페이지뷰가 먼저, 댓글이 뒤따르는 두 가지 사용자 지정 순위 속성을 설정했습니다. 데이터 세트의 모양은 다음과 같습니다.

 

[
  {
    "title": "Algolia + SeaUrchin.IO",
    "author": "Nicolas Dessaigne",
    "pageviews": 1023,
    "comments": 23
  },
  {
    "title": "Search Analytics: Gain Insights from User Search Data",
    "author": "Nicolas Baissas",
    "pageviews": 508,
    "comments": 42
  },
  {
    "title": "Algolia Vault – Bringing Physical & Digital Data Security to Search",
    "author": "Liam Boogar",
    "pageviews": 1022,
    "comments": 54
    }
]

And here’s the setting:

 

index.setSettings({
  customRanking: [
    'desc(pageviews)',
    'desc(comments)'
  ]
}).then(() => {
  // done
});

Because custom ranking applies it’s criteria sequentially, pageviews has more weight than comments. When we search for “algolia”, the “Algolia + SeaUrchin.IO” article comes before “Algolia Vault” only because it has one more unique pageview. However, this additional view is not meaningful. It doesn’t make the article more relevant. Nonetheless, the engine ignores the next custom ranking attribute because of it.

사용자 지정 순위는 순차적으로 기준을 적용하기 때문에, 페이지뷰는 comments보다 비중이 더 큽니다. 우리가 "알골리아"를 찾을 때, "알골리아 + 씨어친IO" 기사가 "알고리아 볼트" 앞에 오는 이유는 오직 고유한 페이지뷰가 하나 더 있기 때문이다. 그러나 이 추가적인 견해는 의미가 없다. 그렇다고 기사가 더 관련성이 있는 것은 아닙니다. 그럼에도 불구하고 엔진은 그것 때문에 다음 사용자 지정 순위 속성을 무시합니다.

For these two records, it would be better if the article with the most comments appeared first: namely, that “Algolia Vault” article should come first because it has significantly more comments.

But changing the order of the attributes in the customRanking parameter isn’t a good solution:

이 두 기록의 경우 댓글이 가장 많이 달린 기사, 즉 댓글이 월등히 많으니 '알고리아 볼트' 기사가 먼저 나와야 한다는 기사가 먼저 나왔으면 좋겠다.
그러나 customParting 매개 변수에서 특성 순서를 변경하는 것은 좋은 해결책이 아닙니다.

  • it doesn’t necessarily make sense business-wise (in our case, we generally care more about unique page views than number of comments),
  • we may face the same issue with number of comments, so we’re not solving anything.

-비즈니스 측면에서 반드시 말이 되는 것은 아닙니다(우리의 경우에는 일반적으로 주석 수보다 고유한 페이지 뷰에 더 신경을 씁니다).
-댓글 수가 많아서 똑같은 문제가 생길 수 있기 때문에 해결이 안 되고 있습니다.

 

For those reasons, we recommend that you reduce precision so you can effectively leverage tie-breaking.

이러한 이유로, 연결 고리를 효과적으로 활용할 수 있도록 정밀도를 낮추는 것이 좋습니다.

 

After#

We can solve the issue by adding a rounded_pageviews attribute where we reduce the precision of pageviews, and use it for custom ranking instead. In our case, one way of doing it could be to round page views to the nearest hundred.

우리는 페이지뷰의 정밀도를 낮추는 라운드_페이지뷰 속성을 추가하여 문제를 해결할 수 있고, 대신 사용자 지정 랭킹에 사용할 수 있습니다. 우리의 경우, 한 가지 방법은 페이지뷰를 가장 가까운 100개로 라운드하는 것입니다.

 

[
  {
    "title": "Algolia + SeaUrchin.IO",
    "author": "Nicolas Dessaigne",
    "pageviews": 1023,
    "rounded_pageviews": 1000,
    "comments": 23
  },
  {
    "title": "Search Analytics: Gain Insights from User Search Data",
    "author": "Nicolas Baissas",
    "pageviews": 508,
    "rounded_pageviews": 500,
    "comments": 42
  },
  {
    "title": "Algolia Vault – Bringing Physical & Digital Data Security to Search",
    "author": "Liam Boogar",
    "pageviews": 1022,
    "rounded_pageviews": 1000,
    "comments": 54
    }
]

Then, you would use the rounded_pageviews attribute for custom ranking instead of pageviews. Now, searching for “algolia” would return the “Algolia Vault” article first, based on the commentsattribute.

그런 다음 페이지뷰 대신 반올림된 페이지뷰 속성을 사용자 정의 순위에 사용합니다. 이제 "알골리아"를 검색하면 댓글 속성에 따라 "알골리아 볼트" 기사가 먼저 반환됩니다.

 

index.setSettings({
  customRanking: [
    'desc(rounded_pageviews)',
    'desc(comments)'
  ]
}).then(() => {
  // done
});

Note that we didn’t remove pageviews from the dataset; you might want to keep it for display purposes.

To know more on how to rank per custom attributes, check our guide.

페이지뷰는 데이터 집합에서 제거하지 않았습니다. 화면표시를 위해 유지하는 것이 좋습니다.
사용자 지정 특성별로 순위를 매기는 방법에 대한 자세한 내용은 가이드를 참조하십시오.

 

 

 

 

728x90

'개발 > ALGOLIA' 카테고리의 다른 글

알고리아 Managing Results(3-11)  (0) 2022.03.03
알고리아 Managing Results(3-10)  (0) 2022.03.03
알고리아 Managing Results(3-8)  (0) 2022.03.03
알고리아 Managing Results(3-7)  (0) 2022.03.03
알고리아 Managing Results(3-6)  (0) 2022.03.03