Training 제약사항, 기본 원칙

자연어 학습 방법 소개 부분에서 Bixby가 자연어를 이해할 수 있도록 자연어 발화들를 어떻게 학습하는지를 배웠습니다. 이 가이드에서는 학습에 대한 제약 사항들, 그리고 효율적인 학습을 위한 기본 원칙과 best practice를 제공합니다.

플랫폼과 학습 제약 사항들

Bixby는 강하고 고유한 tool입니다. 하지만 일부 제약이 있습니다.

Bixby는 누구라도 학습시킬 수 있습니다. 하지만 정교한 결과를 만들고 싶어하는 NL 전문가가 미세하게 수정한다거나 할 수는 없습니다.
Bixby는 소량의 깨끗한(small and clean) 데이터에서 가장 잘 동작합니다. 대량의 지저분한 (big and messy) 데이터에는 제대로 동작하지 않을 수도 있습니다.
Bixby는 한 가지 기능을 deep하게 보다는 다양한 기능을 확장하는데 더 잘 동작하도록 만들어졌습니다.

이런 제약 안에서 어떻게 잘 학습할 수 있지 궁금하실 겁니다. 우선적으로 여러번 반복해서 테스트 해보는 것이 중요합니다. Trial and error가 가장 좋은 방법입니다.

Training의 원칙

아래와 같은 원칙들을 권장합니다.

Tightly-Scoped: 한 capsule이 너무 다양한 기능을 가지기 보다는 scope을 줄이더라도 유용한 것으로 지원하는 것이 좋습니다.
Well-Discriminated: 지원하는 발화들이 다른 capsule과 잘 구분되어 나의 capsule에 잘 매칭될 수 있도록 만드는 것이 중요합니다. 모호하지 않고 capsule을 나타내는 대표 키워드들을 가지는 것이 좋습니다.
Obviously-Tagged: Signal(parameters)는 간단하고 명확하게 태깅 되도록 합니다.

"Big Data"를 사용하면 많은 자연어 문제를 해결할 수 있지만, Bixby 플랫폼의 경우 위 세가지 원칙을 잘 따르는 작고 대표적인 "스마트"한 데이터 만으로도 충분히 잘 동작합니다.

Tightly-Scoped

지원하는 범위를 최소화합니다.

Capsule이 지원하는 도메인의 범위를 최소화해야 합니다. NL과 연관된 기능들이 추가되면 될 수록 더 많은 양의 학습 데이터가 필요합니다. 가능한 한 최소한으로 모델링하고 학습하지만 그 기능을 잘 지원할 수 있도록 튼튼한 기반을 다져 여전히 우수한 사용자 경험을 제공하도록 합니다.

Capsule의 지원하는 도메인 범위를 벗어나면 다음과 같은 문제가 생길 수 있습니다.

query, goal 및 signal을 분류하는 것이 더 어려워집니다.
일관된 결과가 나오지 않기 때문에, 실 사용시의 사용자 경험을 예측하기 어렵게 됩니다.
음성 인식 오류, 예기치 않은 단어 및 out of vocabulary signal에 대한 동작이 보장되지 않을 수 있습니다.
사용자에게 비현실적인 기대치를 갖게 할 수 있습니다. Capsule이 지원하는 기능의 depth가 유사하지 않으면 사용자는 실제 사용하기 전에는 어떤 기능을 제공하는지 예측하기가 어렵습니다.

즉, 지속적으로 사용할 수 있는 capsule을 디자인하고 제작해야 합니다. Capsule은 견고하게 잘 만들어야 합니다. 그래야 그 capsule을 신뢰할 수 있고 (무엇을 하는 capsule인지 예측 할 수 있습니다) 이해할 수 있습니다. (capsule이 어떻게 작동하는지 예측할 수 있습니다.) 한 capsule서 상이한 여러 use case를 지원하는 것 보다는 새로운 capsule을 만드는 것이 좋습니다. 예를 들어, 레시피를 찾아주는 capsule은 그 지원 범위를 최소로 하고, 레시피 검색이 아닌 음식에 관한 질문 및 답변은 이를 위한 별도의 capsule을 만들면 됩니다. (예를 들어, 요구르트에 칼로리가 얼마야?). 이렇게 함으로서 use case 자체는 제한하지 않으면서 Bixby에게 더 많은 것을 가르칠 수 있습니다.

Well-Discriminated

지원하는 발화들이 명확해야 합니다.

다른 assistant와 달리 항상 capsule name을(named dispatch를 통해서) 호출하지 않아도 되기 때문에 사용자의 query에 적합한 capsule을 찾는 것이 때로는 어려울 수 있습니다. Capsule의 모든 query가 명백하게 해당 capsule에 매핑되는 경우 well-discriminated된 capsule이라고 부를 수 있습니다. 그렇지 않은 경우 다양하게 실패하게 되고 이를 극복하기 위해 더 많은 학습 데이터를 필요로 하게 됩니다.

일반적으로 다음 두 가지 권장 사항을 따라 모호성을 줄여야 합니다.

구체적인 training query 만들기

가능한 경우, non-signal 텍스트만으로 학습 예제가 구분되도록 합니다. 이것이 Bixby가 capsule을 잘 분류하고 음성 인식에 가장 잘 동작할 수 있도록 하는 방법입니다. 발화에 모든 signal들을 삭제하더라도 해당 발화가 잘 분류될지를 확인해봅니다. 아래 예제에서 보듯이 signal text(대괄호 안의 text)를 삭제해도 "레시피", "항공편", "동영상" 이란 키워드들이 있기 때문에 해당 발화가 어느 capsule에 속하는지 쉽게 파악할 수 있습니다.

[아보카도 샐러드]의 레시피 알려줘
[AA] [1530] 항공편 현재 상태 보여줘
[쇼미더머니] 동영상 찾아줘

Don’t

[쇼미더머니] 찾아줘

잘 구분되는 vocabulary 만들기

Vocabulary를 만들 때 다른 vocab과 중복되거나 일반적인 단어들은 포함하지 않는 것이 좋습니다. 아래의 예에서 vocabulary는 모호하고 혼동 되는 것들은 삭제되고 명확한 것으로만 정의되어 있습니다.

SFO 찾아줘 [~~FOR~~, SFO, SJC, ~~THE~~, LAX]
AA 1530 찾아줘 [AA, NO, UA, B6, OF, WN]
안시성 검색해줘 [오늘, 안시성, 창궐, 암수살인, 근처, … ]

위와 같은 THE 또는 NO와 같이 다른 단어와 혼동될 수 있는 항공사 코드는 out-of-vocab으로 학습을 추가합니다. Non signal로도 잘 구분될 수 있는 학습 예제들을 추가하면 Bixby는 이러한 단어가 공항이나 식당과 같은 것을 의미 하는 경우와 그렇지 않은 경우를 구분해 낼 수 있습니다.

어휘 사용에 대한 자세한 내용은 자연어 학습 방법 소개 가이드의 Vocabulary로 학습 확장하기 항목을 참조하십시오.

Obviously tagged

명확한 signal을 사용합니다.

음성 인식 오류나 새로운 단어나 문구를 인식하기 위해서는 signal labeling이 명확하게 되는 것이 좋습니다.

명확히 tagging되지 않은 예시

예제 1: 팁 계산기

(서울) [v:geo.LocalityName] (날씨) [v:Weather] 알려줘 
내일 (부산) [v:geo.LocalityName] 날씨 보여줘

이 예제에는 "날씨" 가 일관되게 태깅 되지 않았습니다. 한 domain안에서 동일 단어는 일관된 의미로 사용되어야 합니다.

예시 2: 날씨

오늘 (우산이 필요해)[v:WeatherCondition:rain]? 
오늘 (비)[v:WeatherCondition:rain] 와?

이 예제에는 아래와 같은 주요 문제점이 있습니다.

enum을 무분별하게 사용하는 것입니다. Vocabulary에 있는 단어와 정확히 일치되지 않는 경우에는 enum을 사용하지 않습니다.
동사에 태깅하지 않습니다. 동사를 태깅하는 것은 좋은 방법이 아니며, 동사는 goal에 매핑되도록 합니다.
명확한 경우에만 태깅을 하도록 합니다. 위 예제에서는 어디에 태깅할 지가 명확하지 않습니다. 구체적으로 보면 “우산이”, “우산이 필요”, “우산이 필요해”가 다 가능할 것 같아 보이는데 어디서부터 어디까지 태깅해야할 지 명확하지 않습니다 사람이 사람이 판단하기에도 어려운 것은 Bixby도 마찬가지입니다.

예제 3: 레시피

(닭고기) [v:IngredientName] 레시피 알려줘 
(닭볶음탕) [v:FoodName] 레시피 알려줘

이 예시에서는 context 이슈를 보실 수 있습니다. "닭고기"는 IngredientName이고 "닭볶음탕”은 FoodName이라는 것을 vocabulary가 없으면 구분하기가 어렵습니다. 또한 다음 사항에 유의하십시오.

Vocabulary에 없는 Name을 signal로 태깅했다면 Bixby가 IngredientName인지 FoodName인지를 알 수는 없습니다.
Vocabulary를 작성할 때는 clean하고 complete하게 작성할 수 있어야 합니다. 예를 들어 모든 IngredientName 항목을 나열하는 것은 현실적으로 불가능합니다.
근본적으로 Ingredient와 Food의 구분 자체가 명확하지는 않습니다. “닭고기 레시피”라는 것이 닭고기 요리의 레시피인지 닭고기를 이용한 레시피인지 알기가 어렵습니다.

이 모호함을 해결하기 위해서는 IngredientName과 FoodName을 모두 FoodName 하나로 모델링하고, out-of-vocabulary도 FoodName으로 태깅합니다. 그리고 “닭고기를 이용한”처럼 명확한 경우에는 Role을 이용하여 IngredientName으로 구분합니다.

Structure concept이 아닌 primitive concept을 태깅합니다.

학습을 할 때에는 structure concept이 아닌 primitive concept을 태깅해야합니다. “$40 보다 싼 티셔츠 찾아줘” 라는 발화 내에서 CurrencySymbol 및 CurrencyValue가 포함 된 Currency structure를 가질 수 있습니다. "$40"을 통화로 태그 지정하는 대신, "$"를 CurrencySymbol로, "40"을 CurrencyValue로 태깅합니다.

($) [v : CurrencySymbol] (40) [v : CurrencyValue] 보다 싼 셔츠 찾아줘

capsule에서는 이 두 primitive concepts을 structure concept으로 통합하는 action을 제공합니다. 그러면 Bixby는 실제 수행 시 필요할 때 이 action을 사용하게 됩니다.

위 Structure concepts에 대한 규칙이 예외 적용되는 경우는 viv.time.DateTimeExpression처럼 patterns로 학습되어 있는 경우입니다. Patterns은 structure concepts에 대한 vocabulary를 가질 수 있기 때문에 NL training에서 structure concepts을 직접 사용할 수 있습니다.

General Recommendations and Best Practices

학습 예제가 많다고 좋은 것은 아닙니다. 개수는 적지만 좋은 예제가 있어야 합니다. Bixby가 가능한 한 많은 일을 하도록 하십시오. Goal을 설정하고, value를 태깅하고 plan을 확인합니다.

다음은 몇 가지 모범 사례입니다.

Do:

의도적으로 capsule을 디자인하고 학습하세요.
Capsule을 디자인 할 때는 use case에 중점을 두어야 합니다. 일반적으로 모든 사용자 요청을 만족시키기 보다는 중요한 use case에 집중하는 것이 좋습니다. 모델링 뿐 아니라 학습할 떄도 동일합니다.
사용자에게 가장 유용한 goal을 선택하세요.
때로는 사용자가 요청하는 것 이상을 제공해야 하는 경우도 있습니다. 예를 들어, 사용자가 "근처에 멕시코 음식점 있어?"라고 묻는다면, "예" 또는 "아니오"라고 답하는 것은 별로 도움이 되지 않습니다. 이 경우에 Goal은 restaurant로 설정해서 단순 대답보다는 어떤 멕시코 음식점이 있는지를 알려주는 것이 좋습니다. 또 다른 예로, 사용자가 "내일 우산 필요해?"라고 묻는다면 질문에 대한 대답과 함께 내일의 일기 예보도 추가로 보여주는 goal을 만드는 것이 좋습니다.
Action보다는 concept을 goal로 사용하세요.
Concept을 goal로 잡는 것이 일반적으로 더 유연합니다. 예외적인 케이스로 제품을 주문하거나 서비스를 예약하는 경우에는 action을goal로 사용하는 것이 더 적합합니다.
되도록이면 명사를 태깅하세요. 동사 태깅은 지양합니다.
동사를 signal로 태깅해서 처리해야 하는 경우가 있다면, 새로운 goal을 만들어서 처리하거나 문장 전체를 flag로 태깅하는 방법을 고려해보는 것이 좋습니다.
명백히 드러난 사용자의 의도만 태깅합니다.
사용자의 의도가 명백히 드러나는 경우에만 concept이나 action으로 태깅합니다. 예를 들어, sort signal은 사용자가 "제일 가까운 음식점 찾아줘"이라고 한 경우에는 추가하지만, 단순히 “음식점 찾아줘” 라고 한 경우에는 추가하지 않습니다.
지원되는 각 언어에 대해 학습 예제를 별도로 생성하세요.
capsule이나 학습 데이터를 localization하는 방법은 How to Localize Your Capsule을 참고하세요.
해당 domain 내에서 주어진 발화가 어떻게 태깅되어야 하는지 누군가에게 설명하는 것이 쉬운지를 스스로 확인해봅니다.
만약 답이 "아니오"라면 modeling을 변경하는 것이 좋습니다.

Open text를 학습하는 경우 open text에 포함되는 단어들의 길이도 다양하게, 단어(숫자, 영문, 주요 키워드)도 다양하게 섞어서 학습합니다.

Do	Don't
피자 맛있는 음식점 추천해줘 수원 갈비 파는 맛집 찾아줘 알리오 올리오 스파게티 잘 하는 집 알려줘 지금 갈게라고 메시지 보내줘 홍길동에게 길동아 내일 강남역 6시에 만나자 늦지말고 와 라고 문자 좀 보내줘	피자 맛있는 음식점 추천해줘 스파게티 맛있는 음식점 추천해줘 냉면 맛있는 음식점 추천해줘 오케이라고 메시지 보내줘 갈게라고 메시지 보내줘

특히 한국어 학습의 경우 다양한 조사와 용언을 활용하여 학습합니다. 예) 을/를/이/가 맛집 찾아줘, 찾아, 찾아주세요, 찾아봐, ..

Do	Don't
근처 맛집 찾아줘 근처에 유명한 식당을 찾아주세요 대구에 있는 음식점들 보여줄래 빅오븐에서 수원 갈비 파는 맛집 검색해줘 곱창 부리또 판매하는 음식점 찾아봐	근처 맛집 찾아줘 근처 맛집을 찾아줘 근처 맛집 찾아줘 근처 맛집 보여줘 근처 맛집을 보여줘

Submission reports의 Training Evaluation 섹션을 확인하고 Not Learned 학습은 없도록 만듭니다.
Not Learned 학습 예제들은 vocabulary가 누락되었거나, 일관되지 않게 태깅이된 학습 예제가 있다거나 primitive type을 잘 못 사용한다거나 하는 중요한 문제가 있는 경우입니다. Submission이 성공했다고 하더라도 Not Learned 학습 예제는 무시하지 마시고 꼭 확인하도록 합니다. Capsule의 학습 예제는 거의 항상 100% Learned여야 합니다.

Don't:

동일 단어만 계속 반복하지 않습니다.

Do	Don't
카카오톡 알림 지워줘 인스타그램 알림 온거 읽어줘 화면 캡쳐해서 텀블러로 공유해줘	카카오톡 알림 지워줘 카카오톡 알림 온거 읽어줘 화면 캡쳐해서 카카오톡으로 공유해줘

원하는 동작을 수행하기 위해 억지로 태깅하지 않도록 합니다.
이렇게 강제로 학습된 예제는 딱 그 발화에 대해서는 동작 할 수도 있지만, 그 유형의 모든 쿼리의 동작을 보장하지는 않습니다. 기능을 동작시키기 위해서 학습을 의도에 맞지 않게 강제로 태깅하지 말아야 합니다.
어휘를 과장하지 마라!
특히 다음 tip을 기억하십시오.
- Closed-type의 vocabulary는 아주 조심스럽게 학습합니다! Symbol value가 태깅한 text와 유사하거나 대체하여도 문제가 없는 경우에만 enum을 학습합니다. Route signal은 절대 사용하지 않도록 합니다.
- Open-vocab input type은 적게 유지합니다. 한 발화 내에서 하나 이상을 사용하게 될 경우, 각 단어의 의미가 잘 구분되는지를 꼭 확인합니다.

Articles in this section