📌 개요
- 지식 기반 추천 시스템은 아이템에 대한 사용자 요구 사항의 명시적 요청에 의존한다.
- 대화형 피드백을 사용해 사용자가 본질적으로 복잡한 제품 옵션을 탐색하고 다양한 옵션 간에 사용할 수 있는 장단점에 대해 알아볼 수 있도록 한다.
지식 기반 추천 시스템이 적합한 경우
1. 고객이 자신들의 요구 사항을 자세히 명시하려고 할 때이다.
2. 사용 가능한 항목 및 옵션의 유형 측면에서 도메인의 복잡성이 커서 특정 유형에 대한 평점을 얻기가 어려울 경우이다.
3. 평점이 시간에 민감한 경우이다.
입력 데이터의 차이
콘텐츠 기반 및 협업 시스템의 추천은 주로 기록 데이터를 기반으로 하는 반면,
지식 기반 시스템은 사용자가 직접 자신이 원하는 사항을 지정함이 추천의 기반이 된다.
지식 기반 추천 시스템의 두 가지 유형
1. 제약 조건 기반 추천 시스템 : 사용자는 일반적으로 항목 특성에 대한 요구 사항 또는 제약 조건을 지정한다.
2. 사례 기반 추천 시스템 : 사용자가 특정 사례를 타깃 또는 주요 포인트로 지정하면 유사도 메트릭은 이러한 타깃과 유사한 항목을 검색하기 위해 항목 특성에 정의된다.
- 두 경우 모두 시스템이 사용자가 지정된 요구 사항을 변경할 수 있도록 한다.
사용자와 추천 모델 간의 상호작용 방법
1. 대화형 시스템 : 사용자의 선호는 피드백 순환에서의 컨텍스트에서 결정된다.
2. 검색 기반 시스템 : 사전 설정된 질문 순서를 사용해 유도된다.
3. 네비게이션 기반 추천 : 사용자가 현재 추천되는 항목에 대해 여러 변경 요청을 지정한다.
📌 제약 조건 기반 추천 시스템
제약 조건 기반 추천 시스템은 사용자가 항목 특성에 대한 요구 사항 또는 제약 조건을 지정할 수 있도록 한다.
세가지 기본 입력 유형
- 사용자의 고유한 속성 및 특정한 제품 요구 사항을 설명하는 특성으로 이루어져야한다.
- 다양한 제품 속성에 고객 특성/요구 사항을 매핑하는 기술로 이루어진다.
- 매핑은 직접적 또는 간접적으로 달성될 수 있다.
- 직접적 : 고객 요구 사항과 제품 특성에 대한 엄격한 요구 사항과 관련이 있다.
Ex> 최소 침술 수 > 3 -> 가굑 >100,000
- 간접적 : 일반적으로 예상되는 제품 요구 사항과 고객 특성/요구 사항과 과련된다.
Ex> 가족 수 > 5 -> 최소 침실 수 > 3
- 제품 카탈로그에는 해당 항목 특성과 함께 모든 제품의 목록이 포함돼 있다.
Ex>
- 문제는 고객 요구 사항과 지식 자료의 규칙을 충족시키는 제품 목록을 결정하는 것
📖 관련 결과의 반환
- 관련 결과를 반환하는 문제는 카탈로그의 각 항목을 속성 관련 제약으로 취급하고 분리형 표준화의 방식으로 카탈로그를 표현하는 제약 조건 충족 문제의 사례로 볼 수 있다.
- 고객과 관련된 모든 요구 사항과 실현되는 규칙은 데이터베이스 선택 쿼리를 구성하는데 사용된다.
- 필터링 쿼리를 만드는 과정
- 사용자 인터페이스에서 고객이 지정한 각 요구 사항에 대해 기술 자료의 규칙 선례와 일치하는지 여부를 확인 후 일치하는 경우가 존재한다면 해당 규칙의 결과는 정당한 선택 조건으로 처리된다.
Ex> 부동산 관련해서 가족수 = 6은 다음의 규칙을 작동하는 원천으로 감지된다.
- 규칙 기준은 이렇게 확장된 요구 사항으로 다시 검사되며, 새로 추가 된 제약 조건 '최소 침실 수 >= 3'가 다음의 규칙을 작동시킨다.
- 이러한 확장된 요구 사항은 논리곱 표준형을 생성하는 데 사용된다.
이는 제품 카탈로그에 대한 다음의 제약 조건의 교차점을 계산하는 전통적인 데이터 베이스 선택 쿼리를 나타낸다.
- 이 접근법은 기본적으로 모든 고객 특성 제약 조건과 제품 영역 내의 요구 사항 속성 조건을 매핑한다.
- 이 선택 쿼리는 사용자 요구 사항과 관련된 카탈로그의 사례를 검색하는 데 사용된다.
- 다른 사용자가 동일한 입력을 지정하면 정확히 동일한 결과를 얻을 수 있다.
- 이 특성은 대부분의 지식 기반 시스템에 일반적이다.
📖 상호작용 방법론
- 사용자와 추천 시스템 간의 상호작용은 일반적으로 세 단계로 진행된다.
1. 대화형 인터페이스는 사용자가 초기 설정을 지정하기 위해 쓰인다.
2. 경우에 따라 사용자 요구 사항과 일치하는 항목이 없을 경우 어느 정도까지의 요구 사항 완화가 제안될 수 있다.
3. 사용자는 반환된 결과에 따라 자신의 요구 사항을 추가 또는 제거할 수 있다.
사용자가 모든 제품 특성에 대해 원하는 값을 지정할 수 없다.
1. 시스템은 다른 특성을 제한하지 않고 지정된 제약 조건만을 기반으로 결과를 검색할 수 있다.
2. 사용자에게 지침을 제공하기 위해 기본값을 제안할 수 있다.
📖 일치하는 아이템의 순위 매기기
- 사용자가 항목의 순위를 지정하는 기준으로 단일 숫자 특성을 지정할 수 있도록 하는 것이다.
- 단일 특성을 사용하면 다른 특성의 중요성이 감소된다는 단점이 있다.
- 일반적으로 일치하는 항목의 순위를 지정하기 위해 효용 함수를 사용한다.
- 일치하는 항목의 효용은 다음에 의해 제공된다.
- 효용 함수를 학습하기 위해서는 가중치 및 f() 의 값을 인스턴스화해야한다.
- 효과적인 효용성 함수를 디자인 하려면 도메인별 지식이나 과거 사용자 상호작용의 학습 데이터가 필요한 경우가 많다.
📖 허용되지 않는 결과 또는 공집합 처리
- 대부분 특정 쿼리는 빈 결과를 반환할 수 있으며 이러한 경우 사용자에게 두 가지 옵션이 있다.
1. 시작점에서 다시 시작하도록 선택할 수 있다.
2. 대화형 반응으로 제약 조건을 변경하거나 완화할 수 있다.
- 수리 제안 : 사용자에게 현재 요구 사항을 완화하는 방법에 대해 몇 가지 가이드를 제공하는 것
📖 제약 조건 추가
- 경우에 따라 반환되는 결과 수가 매우 커서 사용자에게 제약 조건을 제안해야 할 수도 있으며 이러한 경우 다양한 방법을 사영해 가능한 기본값과 함께 사용자에게 제약조건을 제안하도록 한다.
- 제약 조건에 대한 특성은 종종 기록 세션 로그를 마이닝해 인기 있는 제약 조건을 선택할 수 있다.
📌 사례 기반 추천
- 유사도 메트릭을 지정된 대상과 유사한 예제를 검색하는데 사용된다.
- 제약 조건 기반 추천 모델과 사례 기반 추천 간에는 결과를 구체화하는 방법에 대해 상당한 차이가 있다.
- 제약 조건 기반 시스템은 요구 사항 완화, 수정 및 체결을 사용해 결과를 구체화한다.
- 사례 기반 시스템은 적절한 솔루션을 찾을 때까지 사용자 쿼리 요구 사항을 반복적으로 수정해야 하며, 그 후 '비판'이라는 방법으로 사용자가 검색된 결과 중 하나 이상을 선택하고 다음 양식의 추가 쿼리를 지정할 수 있게 한다.
- 비판의 주요 목표는 사용자가 검색된 예제를 통해 사용할 수 있는 추가 옵션을 점차적으로 알게 되는 대화형 검색을 지원하는 것이다.
- 사례 기반 시스템은 일반적으로 한 주기에서 다음 주기로 넘어가면서 후보 수를 줄이는 반면, 제약 조건 기반 시스템은 그렇지 않다.
- 사례 기반 추천 시스템이 효과적으로 작동하려면 시스템적으로 두 가지 중요한 측면이 효과적으로 설계돼어야 한다.
1. 유사도 메트릭 : 시스템이 효과적으로 작동하려면 다양한 특징이 유사도 함수 내에 적절하게 녹아져야 한다.
2. 수정 방법 : 상품 후보군의 대화형 탐색은 수정 방법론을 사용해 활용 가능하다.
📖 유사도 메트릭
- 일반적으로 도메인 전문가가 매개변수를 설정하거나 학습 프로세스에 의해 조정할 수 있는 닫힌 형식의 유사도 함수를 개발하는 것이 바람직하다.
- d 특성으로 제품이 설명되는 앱이 있을 때 두 개의 d 차원 벡터 집합 간의 유사도 함수는 다음과 같이 정의한다.
- wi는 i 번째 특성의 가중치를 나타내며 해당 특성의 상대적 중요도를 조절한다.
1. 유사도 함수 결정
- 특성들은 정량적 또는 범주적 특성일 수 있으며, 더 높거나 낮은 관점에서 대칭 또는 비대칭일 수 있다.
- 이는 시스템의 이질성과 복잡성을 더욱 증가시킨다.
- 대칭 메트릭의 예는 다음과 같다.
- 여기서 maxi와 mini는 특성 i의 최대 혹은 최소 가능 값이다.
- 표준편차를 사용해 유사도 함수를 설정하기도 한다.
- 특성이 비대칭인 경우 대상 속성 값이 작거나 더 큰지 여부에 따라 비대칭 보상을 추가할 수 있으며 값이 더 클수록 좋은 특성의 경우 가능한 유사도 함수의 예는 다음과 같다.
- 더 작은 값이 더 나은 경우의 보상함수는 더 작은 값이 지시함수에 의해 보상된다는 점을 제외하면 비슷하다.
범주형 데이터
- 범주형 데이터의 경우 유사도 값을 결정하는 것이 더 어려운 경우가 많다.
- 도메인 계층 구조 내에서 서로 더 가까운 두 개체가 더 유사하다고 간주될 수 있다.
2. 상대적 중요도
1. 도메인 전문가가 경험을 통해 wi의 값을 직접 코딩하는 것이다.
2. 대상 개체 쌍을 사용자에게 표시할 수 있으며 사용자에게는 이러한 대상 개체가 얼마나 유사한지 평가하라는 메세지가 표시되는 것이다.
유사도 계산의 다양성 통합
- 다양성 부족의 문제는 사용자가 최고 수위 결과를 좋아하지 않는 경우 유사한 다른 결과를 좋아하지 않을 것이라는 말이다.
- 무작위 선택 전략 : 상위 b x k결과(b>1)를 검색한 다음 이 목록에서 k 항목을 임의로 선택하는 것이다.
- 탐욕 선택 전략 : 상단 b x k 케이스에서 타깃과 유사한 시점부터 시작하고 b x k 케이스에서 점차적으로 k 인스턴스를 다양하게 늘린다.
📖 수정 방법론
- 검색 결과가 유저에게 안내되면 일반적으로 수정을 통한 피드백을 받을 수 있다.
- 여러 수정이 순차적 추천 주기에 지정되면 선호도는 최근 수정으로 지정된다.
- 수정은 간단한 수정, 복합 수정, 동적 수정에 해당하는 세 가지 유형으로 분류할 수 있다.
1. 간단한 수정
사용자는 권장 항목 중 하나로 지정하게 된다.
- 방향성 수정 : 많은 시스템에서는 사용자가 하나를 지정해 수정하는 대신 특정 값을 늘리거나 줄일지 여부를 지정하는 대화형 인터페이스가 사용되는 경우가 많다.
- 장점
1. 사용자가 정확하게 특성 값을 지정하거나 변경할 필요 없이 자신의 기본 설정을 명시하고 후보군 안에서 탐색할 수 있다는 것이다.
2. 사용자에게 더 직관적이고 매력적일 수 있는 간단한 대화 스타일을 가지고 있다.
1. 권장 제품에 변경해야 하는 기능들이 많이 포함돼 있다면, 후속 수정이라는 긴 체인이 생기게 된다.
2. 기능 중 하나가 변경되면 추천 시스템은 항목 가용성에 따라 최소한 다른 가능 값 중 일부를 자동으로 변경해야 할 수도 있다.
2. 복합적 수정
사용자는 하나의 사이클에서 여러 피처 값을 수정할 수 있다.
- 장점 : 추천 사이클을 줄이는 데 유용하고 탐색 프로세스를 더욱 효과적으로 만드는데 유용하다.
- 단점 : 짧은 수정 사이클은 사용자가 제품의 기능 간에 서로 다른 장단점과 상관관계를 학습할 가능성을 줄인다.
3. 동적 수정
- 동적 수정이 의미상 복합 수정과 가까운 이유는 사용자에게 변화의 조합을 거의 다 보여주기 때문이다.
- 주요 차이점은 현재 검색된 결과에 따라 가장 관련성이 높은 집합만 표시되다는 것이다.
📖 수정에 대한 설명
- 수정 프로세스에 설명 내용을 구축하는 것은 사용자가 정보를 더 잘 이해하는 데 도움이 된다.
- 수정의 질을 향상시키는 데 사용되는 설명에는 몇 가지 형태가 있다.
- 간단한 수정에서 제품 후보에 내재된 트레이드 오프의 인식 부족으로 인해 사용자가 결실 없는 결과를 찾는 것은 흔하게 있는 일이다.
- 이러한 세션의 마지막 부분에서는 시스템의 결실 없는 세션을 초래한 트레이드 오프의 특성을 자동으로 결정하는 것이 바람직하다.
- 세션에서 동적 복합 수정의 설명이 어떻게 적용하는지 확인할 수 있다.
- 이렇게 하면 사용자가 수정을 하기 전에 자신이 선택할 수 있는 공간의 크기에 대한 감을 얻을 수 있다.
📌 지식 기반 시스템의 지속적인 개인화
- 사용자 상호작용 데이터를 사용할 수 있는 경우 지식 기반 시스템의 여러 단계를 개인화할 수 있다.
1. 효용/유사도 함수의 다양한 특성에 대한 학습은 제약 조건 기반 추천 모델과 사례 기반 추천 모델에 대해 모두 개인화할 수 있다.
2. 사용자에게 제약 조건을 제안하는 단계는 세션의 상당수를 사용할 수 있는 경우 개인화가 가능하다.
3. 관련 패턴을 결정하기 위해 해당 유저로부터 충분한 데이터를 사용할 수 있는 경우 사용자에 대한 동적 수정도 개인화가 가능하다.
- 가장 큰 문제는 일반적으로 특정 사용자에 대한 충분한 세션 데이터를 사용할 수 없다는 것이다.
- 지식 기반 시스템은 본질적으로 복잡한 도메인 공간에서의 고도화된 개인화 아이템을 위해 설계되기 때문에 개인화의 정도가 일반적으로 지식 기반 도메인에 제한되는 이유이다.
개발자로서 성장하는 데 큰 도움이 된 글이었습니다. 감사합니다.