Logging feature scores
출처: 문서
본문
피처 점수 로깅
모델을 학습시키려면 피처 값을 로깅해야 해요. 이는 Learning to Rank 플러그인의 핵심 구성 요소예요---검색을 수행하면 피처 세트의 피처 값이 로깅되어 학습에 사용될 수 있어요. 이를 통해 해당 피처 세트를 사용해 관련성을 효과적으로 예측하는 모델을 찾아낼 수 있어요.
sltr 쿼리
sltr 쿼리는 피처를 실행하고 모델을 평가하는 기본적인 방법이에요. 로깅 시에는 sltr 쿼리를 사용해 각 피처 쿼리를 실행하고 피처 점수를 가져와요. hello-ltr 데모 스키마와 함께 작동하는 피처 세트 구조는 다음 예제 요청과 같아요:
PUT _ltr/_featureset/more_movie_features
{
"name": "more_movie_features",
"features": [
{
"name": "body_query",
"params": [
"keywords"
],
"template": {
"match": {
"overview": "{% raw %}{{keywords}}{% endraw %}"
}
}
},
{
"name": "title_query",
"params": [
"keywords"
],
"template": {
"match": {
"title": "{% raw %}{{keywords}}{% endraw %}"
}
}
}
]
}
{% include copy-curl.html %}
일반적인 사용 사례
피처 세트 로깅의 일반적인 사용 사례는 다음 섹션에서 설명해요.
판단 목록과 피처 값 조인하기
판단 목록이 이미 있다면, 각 키워드/문서 쌍에 대한 피처 값을 조인하여 완전한 학습 세트를 만들 수 있어요. 예를 들어 다음 판단 목록을 살펴보세요:
grade,keywords,docId
4,rambo,7555
3,rambo,1370
3,rambo,1369
4,rocky,4241
{% include copy-curl.html %}
각 검색어에 대해 판단이 있는 모든 문서의 피처 값을, 한 번에 하나의 검색어씩 가져와야 해요. 예를 들어 rambo 검색부터 시작해서, 해당 문서에 대한 필터를 다음과 같이 만들 수 있어요:
{
"filter": [
{"terms": {
"_id": ["7555", "1370", "1369"]
}}
]
}
{% include copy-curl.html %}
Learning to Rank 플러그인이 로깅할 피처를 가리키도록 해야 해요. 이를 위해 플러그인의 일부인 sltr 쿼리를 사용할 수 있어요. sltr 쿼리에는 이를 참조하는 데 사용되는 _name(named queries 기능)이 있고, 앞서 만든 피처 세트 more_movie_features를 참조하며, 검색 키워드 rambo와 그 밖의 필요한 파라미터를 전달해요. 다음 예제 쿼리와 같아요:
{
"sltr": {
"_name": "logged_featureset",
"featureset": "more_movie_features",
"params": {
"keywords": "rambo"
}
}
}
{% include copy-curl.html %}
Searching with LTR 문서는 모델을 실행할 때 사용하는 sltr 쿼리를 제공해요. 이 sltr 쿼리는 Learning to Rank 플러그인이 로깅이 필요한 피처 세트를 찾아가도록 안내하는 메커니즘으로 사용돼요.
{: .note}
점수에 영향을 주지 않기 위해 sltr 쿼리는 필터로 주입돼요. 다음 예제를 보세요:
{
"query": {
"bool": {
"filter": [
{
"terms": {
"_id": [
"7555",
"1370",
"1369"
]
}
},
{
"sltr": {
"_name": "logged_featureset",
"featureset": "more_movie_features",
"params": {
"keywords": "rambo"
}
}
}
]
}
}
}
{% include copy-curl.html %}
이 쿼리를 실행하면 예상했던 세 개의 히트가 반환돼요. 다음 단계는 로깅할 sltr 쿼리를 참조하도록 피처 로깅을 활성화하는 거예요.
로깅은 sltr 쿼리를 식별하고, 피처 세트의 쿼리를 실행하고, 각 문서에 점수를 매기고, 그 점수를 각 문서의 계산된 필드로 반환해요. 다음 예제 로깅 구조를 보세요:
"ext": {
"ltr_log": {
"log_specs": {
"name": "log_entry1",
"named_query": "logged_featureset"
}
}
}
{% include copy-curl.html %}
log 확장은 다음 인자를 지원해요:
name: 각 문서에서 가져올 로그 항목의 이름이에요.named_query:sltr쿼리에 해당하는 named query예요.rescore_index:sltr쿼리가 rescore 단계에 있다면, rescore 목록에서 해당 쿼리의 인덱스예요.missing_as_zero: 피처가 매칭되지 않아 없을 때0을 생성해요. 기본값은false예요.
로그가 일반 쿼리 단계에서든 rescore 단계에서든 sltr 쿼리를 찾을 수 있으려면 named_query 또는 rescore_index 중 하나를 반드시 설정해야 해요.
{: .note}
전체 예제 요청은 다음과 같아요:
POST tmdb/_search
{
"query": {
"bool": {
"filter": [
{
"terms": {
"_id": ["7555", "1370", "1369"]
}
},
{
"sltr": {
"_name": "logged_featureset",
"featureset": "more_movie_features",
"params": {
"keywords": "rambo"
}
}}
]
}
},
"ext": {
"ltr_log": {
"log_specs": {
"name": "log_entry1",
"named_query": "logged_featureset"
}
}
}
}
{% include copy-curl.html %}
이제 각 문서에 로그 항목이 포함돼요. 다음 예제를 보세요:
{
"_index": "tmdb",
"_type": "movie",
"_id": "1370",
"_score": 20.291,
"_source": {
...
},
"fields": {
"_ltrlog": [
{
"log_entry1": [
{"name": "title_query"
"value": 9.510193},
{"name": "body_query
"value": 10.7808075}
]
}
]
},
"matched_queries": [
"logged_featureset"
]
}
{% include copy-curl.html %}
판단 목록을 피처 값과 조인하여 학습 세트를 만들 수 있어요. 키워드 rambo에 대한 문서 1370에 해당하는 줄에는 다음을 추가할 수 있어요:
> 4 qid:1 1:9.510193 2:10.7808075
{% include copy-curl.html %}
모든 쿼리에 대해 이 과정을 반복하면 돼요.
판단 목록이 큰 경우에는 여러 쿼리에 대한 로그를 묶어서 처리하는 것이 좋아요. 이를 위해 multi-search 기능을 사용할 수 있어요. {: .note}
라이브 피처 세트에 대한 값 로깅
프로덕션에서 sltr 쿼리 내에서 모델을 실행하고 있다면, 라이브 모델은 다음 예제 요청과 비슷하게 보일 수 있어요:
POST tmdb/_search
{
"query": {
"match": {
"_all": "rambo"
}
},
"rescore": {
"query": {
"rescore_query": {
"sltr": {
"params": {
"keywords": "rambo"
},
"model": "my_model"
}
}
}
}
}
{% include copy-curl.html %}
모델 실행에 대한 정보는 Searching with LTR 문서를 참고하세요. {: .note}
쿼리에 대한 피처 값을 로깅하려면, sltr 쿼리를 참조하도록 적절한 logging spec을 적용하세요. 다음 예제를 보세요:
"ext": {
"ltr_log": {
"log_specs": {
"name": "log_entry1",
"rescore_index": 0
}
}
}
{% include copy-curl.html %}
이 예제는 응답에 피처를 로깅해서, 나중에 동일한 피처 세트로 모델을 재학습시킬 수 있게 해줘요.
기존 피처 세트 수정하고 로깅하기
피처 세트는 확장할 수 있어요. 예를 들어 다음 예제 요청에서처럼 user_rating 같은 새로운 피처를 포함해야 한다면, 기존 피처 세트 more_movie_features에 추가할 수 있어요:
PUT _ltr/_feature/user_rating/_addfeatures
{
"features": [
"name": "user_rating",
"params": [],
"template_language": "mustache",
"template" : {
"function_score": {
"functions": {
"field": "vote_average"
},
"query": {
"match_all": {}
}
}
}
]
}
{% include copy-curl.html %}
자세한 내용은 Working with features 문서를 참고하세요. {: .note}
로깅을 수행하면 새로운 피처가 출력에 포함돼요. 다음 예제를 보세요:
{
"log_entry1": [
{
"name": "title_query",
"value": 9.510193
},
{
"name": "body_query",
"value": 10.7808075
},
{
"name": "user_rating",
"value": 7.8
}
]
}
{% include copy-curl.html %}
제안된 피처 세트에 대한 값 로깅
실험 목적으로 완전히 새로운 피처 세트를 만들 수 있어요. 예를 들어 다음 예제 요청처럼 other_movie_features를 만들 수 있죠:
PUT _ltr/_featureset/other_movie_features
{
"name": "other_movie_features",
"features": [
{
"name": "cast_query",
"params": [
"keywords"
],
"template": {
"match": {
"cast.name": "{% raw %}{{keywords}}{% endraw %}"
}
}
},
{
"name": "genre_query",
"params": [
"keywords"
],
"template": {
"match": {
"genres.name": "{% raw %}{{keywords}}{% endraw %}"
}
}
}
]
}
{% include copy-curl.html %}
피처 세트 other_movie_features는 다른 필터로 추가함으로써 라이브 프로덕션 세트 more_movie_features와 함께 로깅할 수 있어요. 다음 예제 요청을 보세요:
POST tmdb/_search
{
"query": {
"bool": {
"filter": [
{ "sltr": {
"_name": "logged_featureset",
"featureset": "other_movie_features",
"params": {
"keywords": "rambo"
}
}},
{"match": {
"_all": "rambo"
}}
]
}
},
"rescore": {
"query": {
"rescore_query": {
"sltr": {
"params": {
"keywords": "rambo"
},
"model": "my_model"
}
}
}
}
}
{% include copy-curl.html %}
로깅에 필요한 만큼 피처 세트를 계속 추가할 수 있어요.
로깅 시나리오
기본 내용을 다 익혔다면, 실제 상황에서의 피처 로깅 시나리오를 몇 가지 생각해 볼 수 있어요.
첫째, 로깅은 사용자 분석 데이터로부터 판단 목록을 개발하는 데 사용돼요. 이를 통해 상호작용이 일어난 정확한 시점의 피처 값을 기록할 수 있어요. 예를 들어 사용자가 상호작용한 바로 그 시점의 recency, title score 같은 값을 알고 싶을 수 있죠. 이렇게 하면 학습할 때 어떤 피처나 요인이 관련성이 있었는지 분석하는 데 도움이 돼요. 이를 위해 향후 실험에 사용할 포괄적인 피처 세트를 만들어 둘 수 있어요.
둘째, 로깅은 이미 신뢰하고 있는 모델을 재학습시킬 때 사용할 수 있어요. 시간이 지나면 모델의 효과가 떨어질 수 있기 때문에, 변하는 인덱스에 맞춰 모델을 최신 상태로 유지하고 싶을 거예요. A/B 테스트를 운영 중이거나 비즈니스 지표를 모니터링하다가 모델 성능이 점진적으로 저하되는 것을 알아차릴 수도 있어요.
셋째, 로깅은 모델 개발 중에 사용돼요. 판단 목록은 있지만 OpenSearch 로컬 사본으로 많은 반복 작업을 하고 싶을 수 있어요. 이렇게 하면 새로운 피처를 폭넓게 실험하고, 필요에 따라 피처 세트에 추가하거나 제거할 수 있어요. 이 과정에서 라이브 인덱스와 약간 동기화가 어긋날 수 있지만, 목표는 만족스러운 모델 파라미터 집합에 도달하는 거예요. 일단 그렇게 되면, 프로덕션 데이터로 모델을 학습시켜 성능 수준이 여전히 허용 가능한지 확인할 수 있어요.
다음 단계
Uploading a trained model 문서에서 모델 학습에 대해 더 알아보세요.