시작
Kore.ai 대화형 플랫폼
챗봇 개요
자연어 처리(NLP)
봇 개념 및 용어들
빠른 시작 가이드
봇 빌더 접근 방법
사용 고지 사항 (영어)
Kore.ai 봇 빌더로 작업하기
봇 구축 시작하기
릴리스 정보
현재 버전 (영어)
이전 버전 (영어)

개념
디자인
스토리보드
대화 작업
개요
Using the Dialog Builder Tool
노드 유형
사용자 의도 노드
대화 노드
엔티티 노드
양식 노드
확인 노드
서비스 노드
봇 조치 노드
Service Node
WebHook 노드
스크립트 노드
노드 그룹화하기
Agent Transfer Node
사용자 프롬프트
음성 통화 속성
대화 관리
노드 및 전환
구성 요소 전환
컨텍스트 개체
이벤트 기반 봇 조치
지식 그래프
소개
지식 추출
지식 그래프 생성
봇에 지식 그래프 추가
그래프 생성
지식 그래프 작성
FAQ 추가
작업 실행
기존 소스에서 FAQ 구축
특성, 동의어 및 불용어
변수 네임스페이스 관리
수정
용어 편집 및 삭제
용어 편집 및 삭제
질문과 응답 편집
Knowledge Graph Training
지식 그래프 분석
봇 온톨로지 가져오기 및 내보내기
지식 그래프 가져오기
지식 그래프 내보내기
지식 그래프 생성
CSV 파일에서
JSON 파일
지식 그래프 생성
경고 작업
스몰 토크
Digital Skills
디지털 양식
Views
Digital Views
Panels
Widgets
기차
봇 성능 향상 – NLP 최적화
기계 학습
소개
모델 검증
기초 의미
지식 그래프 학습
특성
순위 및 해결
고급 NLP 설정
NLP 설정 및 지침
봇 인텔리전스
소개
컨텍스트 관리
컨텍스트 관리
대화 관리
다중 – 의도 탐지
엔티티 수정
기본 대화
정서 관리
어조 분석
Test & Debug
봇과 대화
발화 테스트
배치 테스트하기
대화 테스트
배포
채널 활성화
봇 게시
분석
봇 분석하기
Conversations Dashboard
Performance Dashboard
사용자 정의 대시보드
소개
맞춤형 메타 태그
사용자 정의 대시보드 생성 방법
Conversation Flows
NLP 지표
Containment Metrics
사용량 지표
스마트 봇
소개
범용 봇
소개
범용 봇 정의
범용 봇 생성
범용 봇 학습
범용 봇 커스터마이징
범용 봇용 추가 언어 활성화
스토어
Manage Assistant
플랜 및 사용량
Overview
Usage Plans
Support Plans
플랜 관리
봇 인증
다국어 봇
개인 식별 정보 삭제하기
봇 변수 사용
IVR 통합
일반 설정
봇 관리

방법
간단한 봇 생성하기
Design Conversation Skills
뱅킹 봇 생성
뱅킹 봇 – 자금 이체
뱅킹 봇 – 잔액 업데이트
Knowledge Graph (KG) 구축
스마트 경고를 예약하는 방법
Design Digital Skills
디지털 양식 설정 방법
디지털 보기 설정 방법
데이터 테이블에 데이터를 추가하는 방법
데이터 테이블 내 데이터 업데이트 방법
UI 양식에서 데이터 테이블에 데이터를 추가하는 방법
Train the Assistant
특성 사용 방법
의도와 엔티티에 대한 패턴 사용 방법
컨텍스트 전환 관리 방법
Deploy the Assistant
상담사 전환을 설정하는 방법
봇 기능 사용 방법
콘텐츠 변수 사용 방법
전역 변수 사용 방법
Kore.ai 웹 SDK 튜토리얼
Kore.ai 위젯 SDK 튜토리얼
Analyze the Assistant
사용자 정의 대시보드 생성 방법
사용자 지정 태그를 사용하여 봇 메트릭을 필터링하는 방법

API 및 SDK
API 참조
Kore.ai API 사용
API 목록
API 컬렉션
koreUtil Libraries
SDK 참조
상담사 전환을 설정하는 방법
봇 기능 사용 방법
콘텐츠 변수 사용 방법
전역 변수 사용 방법
소개
Kore.ai 웹 SDK 튜토리얼
Kore.ai 위젯 SDK 튜토리얼

관리
소개
봇 관리자 콘솔
대시보드
사용자 관리
사용자 관리
그룹 관리
역할 관리
봇 관리 모듈
등록
사용자 초대
사용자 등록을 위한 대량 초대 보내기
사용자 및 사용자 데이터 가져오기
Active Directory에서 사용자 동기화
보안 및 준수
싱글 사인 온 사용
보안 설정
Kore.ai 커넥터
봇 관리자용 분석
Billing (지원하지 않음)
  1. Docs
  2. Virtual Assistants
  3. How Tos
  4. Travel Planing Assistant
  5. Travel VA: Using Patterns for Intents & Entities

Travel VA: Using Patterns for Intents & Entities

Using patterns can help to improve NLP interpreter accuracy.

In this document, we will elaborate on the various pattern syntax and how they can be used in intent detection and entity extraction.

Important Notes:

  • Patterns are to be used as a last resort, only for cases where the ML engine cannot be used. Examples of such cases would be to train the VA in recognising idiomatic utterances, command like utterances.
  • Patterns are evaluated in the order of their listing. Once a match is found the rest of the patterns are not evaluated. So ensure when adding patterns to add in the order of most restrictive to least restrictive.
  • Only one wildcard (*) is allowed in a pattern.
  • While most of the features are supported in all languages, there are some exceptions, see here for more details.

Pattern Creation Guidelines

The following are some general guideline for creating intent patterns:

  • Use a minimum of 3 words.
  • Use words in their canonical forms (i.e. infinitive verbs, singular nouns).
  • Use lowercase both for words and their synonyms.
  • Use the US spelling of words (i.e. normalize instead of normalize).
  • Avoid using determiners and pronouns (the, a, my, that).
  • Avoid using digits.
  • Avoid using entity values in defining a task pattern.
  • Don’t use elision (i.e. what’s ).
  • Don’t use special characters such as () & / \ $ [ ] + *.
  • Don’t use punctuation such as – , . ! ? ‘ “.

Patterns for Intent Detection

Following is a list of pattern syntax, along with examples, that can be configured for intent detection.

PATTERN

DESCRIPTION

PATTERN EXAMPLES

word1 word2 … wordn

This mandates all the words defined to be available in the user utterance in the same consecutive order with upto 3 (language specific) additional words allowed between any two consecutive words mentioned in the pattern and infinite number of words before and after those specified set of words.

Sample Pattern

Book flight

Utterance Match

– “can you please book a flight for me?

– “I want to book a flight

– “Book flight

Utterance not Matching

– “i want to book

– “Can I make a flight booking?

word1_word2

Enforce phrase, no additional words allowed in between word1 and word2. This is to ensure a sequence of tokens are read as a phrase. Usage restricted to words, concepts not allowed.

Note: There should be no space between the word1, word2 and _. Also be aware that “_word1” is to ensure that the word1 in the user utterance is not marked as Used Up by the Platform and is to be considered for entity extraction. This is useful when entity words are used in the intent pattern.

Sample Pattern

check_in

Utterance Match

Can you help me check in?

Utterance not Matching

Can you please check me in for my flight?

word1 * word2

0 to infinite number of additional words between the specified words/phrases

Sample Pattern

Book * flight *

Utterance Match

– “can you please book me a flight?

– “Can you help me book tomorrow’s flight to London?

Utterance not Matching

i want to book

word1 *n word2

Exactly n number of additional words between the specified words/phrases

Sample Pattern

Book *2 flight *2 fund

Utterance Match

– “Can you help me book an economy flight?“

Utterance not Matching

– “i want to book

– “Can you please book me a first class flight?

word1 *0 word2

To disable wildcards between two tokens. Similar to the underscore between two words but can be used between two concepts or within [  ], {  } groups.

(available 7.1 onwards)

Sample Pattern

Check *0 in

Utterance Match

– “Can you please show me how to check in?

– “Can you help me check in?

Utterance not Matching

Can you check me in for my flight?

word1 < word2

Indicates that the match for word2 should start from the beginning of a sentence. It is useful especially when the word2 appears in the middle of the utterance.

Add a space after the angular bracket

Sample Pattern

Change < seat t

Utterance Match

– “want to change seat

– “I want a seat change.

Utterance not Matching

i want another seat

word1 > word2

Indicates the end of the sentence and no words are allowed after it.

Add a space before closing the angular bracket

Sample Pattern

Book * flight > 

Utterance Match

– “book flight

– “book a flight

Utterance not Matching

Book flight for tomorrow

!abc

Indicates the word/concept “abc” should not exist anywhere in the user utterance after this token

No space between ! and word/concept

Sample Pattern

– “!status check in

– “check  !status in

– “check in !status

Utterance Match

i want to check in

Utterance not Matching

– “what is the status of my check in

– “i want to find my check in status

!!abc

The very next word/concept should not be “abc”

No space between !! and word/concept

Sample Pattern

Flight booking !!status

Utterance Match

– “i want to make a flight booking

– “What is the status of my flight booking?

I made a flight booking yesterday and I want to know the status.

Utterance not Matching

I want to check my flight booking status.

[ … ]

Used to define a group of words/concepts and the match should be against exactly one of the groups declared in [ ]. Be aware that when a match is found the rest of the group is ignored, so order the words accordingly.

Note: the parentheses should not be clubbed with the word, i.e maintain a space between the parenthesis and the adjacent word.

Due to the difficulty in maintaining and tracking, it is recommended you use concept instead of this pattern. This pattern also has a detrimental effect on the VA’s performance.

Sample Pattern

Book [flight ticket seat]”  

Utterance Match

– “book flight

– “Can I book a ticket?

– “I want to book a seat.

Utterance not Matching

Book a trip

{ … }

Used to define an optional group or words/concepts and the match would be against zero or one of the words/patterns declared in { }. Be aware that when a match is found, the rest of the group is ignored, so order the words accordingly.

Note: the parentheses should not be clubbed with the word, i.e maintain a space between the parenthesis and the adjacent word.

Sample Pattern

Check { the a my } flight status.“

Utterance Match

– “How do I check the flight status?

– “I need to check a flight status.”

– “Can I check my flight status?

Utterance not Matching

I want my flight status.

( … )

Contain a pattern – i.e when a pattern or part of a pattern is enclosed in these parentheses, we treat it as a pattern unlike [ ] and { }.

This is the default setting i.e. when a pattern word1 word2 it is treated as ( word1 word2 )

Commonly used explicitly to define sub pattern inside [ ] or { }

Sample Pattern

( check in )

Utterance Match

Check in for my flight.

Utterance not Matching

Can you check me in for my flight?

<< … >>

Used to find words in any order

Due to the risk of running into false positives, you are advised not to use this pattern.

Sample Pattern

<< change seat  >>

Utterance Match

– “change seat for my flight

– “I would like to make a seat change.

Utterance not Matching

i want another seat

‘word1

If you quote words or use words that are not in canonical form, the system will restrict itself to what you used in the pattern

Sample Pattern

Like to book a flight.

Utterance Match

I would like to book a flight.

Utterance not Matching

I really liked how easy it was to book a flight in your app.

word1~concept2

~concept1~concept2

(from ver8.0)

A word (word1) or concept (concept1) can be matched only if it is also a member of another concept (concept2). The most common usage of this is through the system concepts that are dynamically added for each POS tag.

Sample Pattern

book~verb

Utterance Match

Book a flight

Utterance not Matching

Can I bring a book on board?

Pattern Operators

  • AND: ( X Y ): An ordered relationship of words in sequence. This is the default setting. i.e. when you specify a pattern as cancel order it is the same as (cancel order).
    For example, (Cancel Booking) matches Cancel my flight booking but doesn’t match I have a pending booking for flight can I cancel?. The XO Platform uses patterns with increasing numbers of wildcards between words (up to 3 for an intent). So a pattern of Cancel Order can match:
    • cancel order
    • cancel my order
    • cancel that last order
    • cancel last weeks big order
  • OR: [X Y Z]: Any of these can be interchangeably used in the user utterance. For example, ([get make] me [food drink dessert]) will match any of the below utterances:
    • Get me food
    • Make me a drink
    • Get me a drink
    • Get me a dessert
    • Make me some quick food
  • NOT: !X: Words that should not appear in the user utterance for an intent match. For example, (!forecast) is marked as a pattern for an intent named Get current weather and the assistant supports another intent called Get 3-day weather forecast.
    • will not match Get current weather
    • will match Get 3-day weather forecast

      Note that the !word means not after this point. So (!forecast the weather) and (get the weather !forecast) are different. The utterance Get the forecast for the weather matches the second but not the first.

    • User utterance: Planning a trip to California get me the forecast
  • Optional: {X}: For example, {phone} If the user utterance is Get me a phone number or get me a number the Platform will treat it equally.
  • Enforce Phrase: X_Y: To enforce occurrence of the phrase as is in the user utterance, without any words in between. For example,check_in. The utterance check in  or I want to check in will match but not Can you check me in for my flight? 
  • Concepts: ~: The Platform has a large set of inbuilt concepts that developers can use to define a pattern. For example, (I [like love] ~world_country) will match
    • I like India
    • I love traveling to Australia
    • I would like to visit an African country
  • Unordered: <<, >>: Used to find words in any order. For example, <<Cancel Booking>> matches Cancel my flight booking and also I have a pending booking for a flight, can I cancel
  • Start/End of Statement: <, >: For example, ( check in > ) will match I want to check in, but will not match I want to check in now..
  • Quote: ‘ –: If you quote words or use words that are not in canonical form, the system will restrict itself to what you used in the pattern. For example, (like to book a flight) This matches I would like to book a flight, but not I really liked how easy it was to book a flight on your app.

Negative Patterns

Negative Patterns can be used to eliminate intents detected in the presence of a phrase. This will help filter the matched intents for false positives.

User Utterance: “I was booking a flight  when I got network failure error”

Intent Detected: Book a flight

Intended Intent: Issue Resolution

Add a Negative Pattern (network failure) (error) (technical issue) for the intent Book a Flight. 

User Utterance: “I was booking a flight when I got network failure error”

or “I was booking a flight when I faced a technical issue”

or “I got an error while booking a flight.”

Intent Rejected: Book a Flight

Intent Triggered: Issue Resolution

Patterns for Entity Extraction

Patterns can be used to identify the values for entities in user utterance based upon their position and occurrence in user utterance.

Intent patterns operators like {…}, […], !, ~concepts can be used for entity extraction. The following are some use cases where patterns can be applied.

Every entity pattern has to include a * (of some form) to represent where the Platform should look for an entity value.

Continuing with the Travel Planning Assistant example with the Book Flight intent. This intent needs two entities – DepartureCity and ArrivalCity. We will see how to achieve this.

 

Pattern 1: word1 * word2

This can be used as a positional wildcard that indicates the expected position of the entity.

Pattern for ArrivalCity entity: to * from

User Utterance: Book a flight to London..

Entity Extracted: ArrivalCity = London

User Utterance not resulting in entity extraction: “Book a flight for London”

Pattern 2: word1 *n

This can be used as a positional wildcard * that indicates the expected position of the entity based upon the number of words after the specified word1. That is, n words after the word1 are to be considered for the entity, if n words are not present then look for the next occurence of word1.

Pattern for DepartureCity entity: from *2

User Utterance: Book flight from Paris.

Entity Extracted: DepartureCity = Paris

User Utterance not resulting in entity extraction: “Book flight flying from Paris towards London”

Extension to Pattern 2: word1 *~n

Similar to above (pattern 2) but extracts up to n number, if that number of words are available.

Note that entities need to extract something so *~1 is really the same as *1.

 

Pattern 3: a combination of word1 * word2 and word3 *n

This can be used as a combination of patterns for the likely location in the user utterance that the entity value could be found and the number of words contributing to the entity.

Pattern for ArrivalCity entity: “to * from” and “from to *1”

Pattern for DepartureCity entity: “from * to” and “to from *2”

User Utterance: Book flight to London from Paris.

                       or Book flight from Paris to London.

Entity Extracted: ArrivalCity = London and DepartureCity = Paris

User Utterance not resulting in entity extraction: “book flight for London from Paris.

 

Pattern 4: [ word1 word2 ] *

This can be for patterns using a group of words or concepts of which at least one should be present in the utterance. The order within the group is important (see above in intent detection for details).

Pattern for ArrivalCity entity: “to * [ from ]” and “[ from ] to *1”

Pattern for DepartureCity entity: “[ from ] * to” and “to [ from ] *”

User Utterance: Book flight to London from Paris

                       or Book flight from London to Paris.

Entity Extracted: ArrivalCity = London, DepartureCity = Paris

User Utterance not resulting in entity extraction: “Book flight for London from Paris.

 

Pattern 5: ~CustomConcept *

This can be for using concepts. You can create your own custom concepts and use them to define patterns.

Pattern for ArrivalCityentity: “to * from” and “from to *”

Pattern for DepartureCity entity: “~in * to” and “to ~in *”

Custom Concept: ~in(from)

User Utterance: Book flight landing in London and taking off from Paris .

                       or Book flight with takeoff from Paris and landing in London

Entity Extracted: ArrivalCity = London, DepartureCity = Paris

User Utterance not resulting in entity extraction: “book flight landing in London taking off in Paris.

 

Pattern 6: ~intent

Useful in entity patterns and custom entities

Words that are used in the intent identification are dynamically marked with the ~intent concept. This can then be used as an anchor or reference point for some entity patterns.

Sample Pattern: “~intent~trip~plural“

User Utterance not resulting in entity extraction: show my trips.

User Utterance might mark the entity: “Show me the Trip of a Lifetime in-flight magazine.

 

Pattern 7: $currentEntity

Useful in delaying the evaluation of a pattern until the entity is actually processed. Normally entity patterns are evaluated when a dialog starts and on new input to see if any words need to be protected until that entity is processed. This might not always be desirable, especially for strings.

Pattern: “$currentEntity=TaskTitle ‘called *“

The above rule will result in evaluating the pattern when the dialog flow has reached the TaskTitle node.

Travel VA: Using Patterns for Intents & Entities

Using patterns can help to improve NLP interpreter accuracy.

In this document, we will elaborate on the various pattern syntax and how they can be used in intent detection and entity extraction.

Important Notes:

  • Patterns are to be used as a last resort, only for cases where the ML engine cannot be used. Examples of such cases would be to train the VA in recognising idiomatic utterances, command like utterances.
  • Patterns are evaluated in the order of their listing. Once a match is found the rest of the patterns are not evaluated. So ensure when adding patterns to add in the order of most restrictive to least restrictive.
  • Only one wildcard (*) is allowed in a pattern.
  • While most of the features are supported in all languages, there are some exceptions, see here for more details.

Pattern Creation Guidelines

The following are some general guideline for creating intent patterns:

  • Use a minimum of 3 words.
  • Use words in their canonical forms (i.e. infinitive verbs, singular nouns).
  • Use lowercase both for words and their synonyms.
  • Use the US spelling of words (i.e. normalize instead of normalize).
  • Avoid using determiners and pronouns (the, a, my, that).
  • Avoid using digits.
  • Avoid using entity values in defining a task pattern.
  • Don’t use elision (i.e. what’s ).
  • Don’t use special characters such as () & / \ $ [ ] + *.
  • Don’t use punctuation such as – , . ! ? ‘ “.

Patterns for Intent Detection

Following is a list of pattern syntax, along with examples, that can be configured for intent detection.

PATTERN

DESCRIPTION

PATTERN EXAMPLES

word1 word2 … wordn

This mandates all the words defined to be available in the user utterance in the same consecutive order with upto 3 (language specific) additional words allowed between any two consecutive words mentioned in the pattern and infinite number of words before and after those specified set of words.

Sample Pattern

Book flight

Utterance Match

– “can you please book a flight for me?

– “I want to book a flight

– “Book flight

Utterance not Matching

– “i want to book

– “Can I make a flight booking?

word1_word2

Enforce phrase, no additional words allowed in between word1 and word2. This is to ensure a sequence of tokens are read as a phrase. Usage restricted to words, concepts not allowed.

Note: There should be no space between the word1, word2 and _. Also be aware that “_word1” is to ensure that the word1 in the user utterance is not marked as Used Up by the Platform and is to be considered for entity extraction. This is useful when entity words are used in the intent pattern.

Sample Pattern

check_in

Utterance Match

Can you help me check in?

Utterance not Matching

Can you please check me in for my flight?

word1 * word2

0 to infinite number of additional words between the specified words/phrases

Sample Pattern

Book * flight *

Utterance Match

– “can you please book me a flight?

– “Can you help me book tomorrow’s flight to London?

Utterance not Matching

i want to book

word1 *n word2

Exactly n number of additional words between the specified words/phrases

Sample Pattern

Book *2 flight *2 fund

Utterance Match

– “Can you help me book an economy flight?“

Utterance not Matching

– “i want to book

– “Can you please book me a first class flight?

word1 *0 word2

To disable wildcards between two tokens. Similar to the underscore between two words but can be used between two concepts or within [  ], {  } groups.

(available 7.1 onwards)

Sample Pattern

Check *0 in

Utterance Match

– “Can you please show me how to check in?

– “Can you help me check in?

Utterance not Matching

Can you check me in for my flight?

word1 < word2

Indicates that the match for word2 should start from the beginning of a sentence. It is useful especially when the word2 appears in the middle of the utterance.

Add a space after the angular bracket

Sample Pattern

Change < seat t

Utterance Match

– “want to change seat

– “I want a seat change.

Utterance not Matching

i want another seat

word1 > word2

Indicates the end of the sentence and no words are allowed after it.

Add a space before closing the angular bracket

Sample Pattern

Book * flight > 

Utterance Match

– “book flight

– “book a flight

Utterance not Matching

Book flight for tomorrow

!abc

Indicates the word/concept “abc” should not exist anywhere in the user utterance after this token

No space between ! and word/concept

Sample Pattern

– “!status check in

– “check  !status in

– “check in !status

Utterance Match

i want to check in

Utterance not Matching

– “what is the status of my check in

– “i want to find my check in status

!!abc

The very next word/concept should not be “abc”

No space between !! and word/concept

Sample Pattern

Flight booking !!status

Utterance Match

– “i want to make a flight booking

– “What is the status of my flight booking?

I made a flight booking yesterday and I want to know the status.

Utterance not Matching

I want to check my flight booking status.

[ … ]

Used to define a group of words/concepts and the match should be against exactly one of the groups declared in [ ]. Be aware that when a match is found the rest of the group is ignored, so order the words accordingly.

Note: the parentheses should not be clubbed with the word, i.e maintain a space between the parenthesis and the adjacent word.

Due to the difficulty in maintaining and tracking, it is recommended you use concept instead of this pattern. This pattern also has a detrimental effect on the VA’s performance.

Sample Pattern

Book [flight ticket seat]”  

Utterance Match

– “book flight

– “Can I book a ticket?

– “I want to book a seat.

Utterance not Matching

Book a trip

{ … }

Used to define an optional group or words/concepts and the match would be against zero or one of the words/patterns declared in { }. Be aware that when a match is found, the rest of the group is ignored, so order the words accordingly.

Note: the parentheses should not be clubbed with the word, i.e maintain a space between the parenthesis and the adjacent word.

Sample Pattern

Check { the a my } flight status.“

Utterance Match

– “How do I check the flight status?

– “I need to check a flight status.”

– “Can I check my flight status?

Utterance not Matching

I want my flight status.

( … )

Contain a pattern – i.e when a pattern or part of a pattern is enclosed in these parentheses, we treat it as a pattern unlike [ ] and { }.

This is the default setting i.e. when a pattern word1 word2 it is treated as ( word1 word2 )

Commonly used explicitly to define sub pattern inside [ ] or { }

Sample Pattern

( check in )

Utterance Match

Check in for my flight.

Utterance not Matching

Can you check me in for my flight?

<< … >>

Used to find words in any order

Due to the risk of running into false positives, you are advised not to use this pattern.

Sample Pattern

<< change seat  >>

Utterance Match

– “change seat for my flight

– “I would like to make a seat change.

Utterance not Matching

i want another seat

‘word1

If you quote words or use words that are not in canonical form, the system will restrict itself to what you used in the pattern

Sample Pattern

Like to book a flight.

Utterance Match

I would like to book a flight.

Utterance not Matching

I really liked how easy it was to book a flight in your app.

word1~concept2

~concept1~concept2

(from ver8.0)

A word (word1) or concept (concept1) can be matched only if it is also a member of another concept (concept2). The most common usage of this is through the system concepts that are dynamically added for each POS tag.

Sample Pattern

book~verb

Utterance Match

Book a flight

Utterance not Matching

Can I bring a book on board?

Pattern Operators

  • AND: ( X Y ): An ordered relationship of words in sequence. This is the default setting. i.e. when you specify a pattern as cancel order it is the same as (cancel order).
    For example, (Cancel Booking) matches Cancel my flight booking but doesn’t match I have a pending booking for flight can I cancel?. The XO Platform uses patterns with increasing numbers of wildcards between words (up to 3 for an intent). So a pattern of Cancel Order can match:
    • cancel order
    • cancel my order
    • cancel that last order
    • cancel last weeks big order
  • OR: [X Y Z]: Any of these can be interchangeably used in the user utterance. For example, ([get make] me [food drink dessert]) will match any of the below utterances:
    • Get me food
    • Make me a drink
    • Get me a drink
    • Get me a dessert
    • Make me some quick food
  • NOT: !X: Words that should not appear in the user utterance for an intent match. For example, (!forecast) is marked as a pattern for an intent named Get current weather and the assistant supports another intent called Get 3-day weather forecast.
    • will not match Get current weather
    • will match Get 3-day weather forecast

      Note that the !word means not after this point. So (!forecast the weather) and (get the weather !forecast) are different. The utterance Get the forecast for the weather matches the second but not the first.

    • User utterance: Planning a trip to California get me the forecast
  • Optional: {X}: For example, {phone} If the user utterance is Get me a phone number or get me a number the Platform will treat it equally.
  • Enforce Phrase: X_Y: To enforce occurrence of the phrase as is in the user utterance, without any words in between. For example,check_in. The utterance check in  or I want to check in will match but not Can you check me in for my flight? 
  • Concepts: ~: The Platform has a large set of inbuilt concepts that developers can use to define a pattern. For example, (I [like love] ~world_country) will match
    • I like India
    • I love traveling to Australia
    • I would like to visit an African country
  • Unordered: <<, >>: Used to find words in any order. For example, <<Cancel Booking>> matches Cancel my flight booking and also I have a pending booking for a flight, can I cancel
  • Start/End of Statement: <, >: For example, ( check in > ) will match I want to check in, but will not match I want to check in now..
  • Quote: ‘ –: If you quote words or use words that are not in canonical form, the system will restrict itself to what you used in the pattern. For example, (like to book a flight) This matches I would like to book a flight, but not I really liked how easy it was to book a flight on your app.

Negative Patterns

Negative Patterns can be used to eliminate intents detected in the presence of a phrase. This will help filter the matched intents for false positives.

User Utterance: “I was booking a flight  when I got network failure error”

Intent Detected: Book a flight

Intended Intent: Issue Resolution

Add a Negative Pattern (network failure) (error) (technical issue) for the intent Book a Flight. 

User Utterance: “I was booking a flight when I got network failure error”

or “I was booking a flight when I faced a technical issue”

or “I got an error while booking a flight.”

Intent Rejected: Book a Flight

Intent Triggered: Issue Resolution

Patterns for Entity Extraction

Patterns can be used to identify the values for entities in user utterance based upon their position and occurrence in user utterance.

Intent patterns operators like {…}, […], !, ~concepts can be used for entity extraction. The following are some use cases where patterns can be applied.

Every entity pattern has to include a * (of some form) to represent where the Platform should look for an entity value.

Continuing with the Travel Planning Assistant example with the Book Flight intent. This intent needs two entities – DepartureCity and ArrivalCity. We will see how to achieve this.

 

Pattern 1: word1 * word2

This can be used as a positional wildcard that indicates the expected position of the entity.

Pattern for ArrivalCity entity: to * from

User Utterance: Book a flight to London..

Entity Extracted: ArrivalCity = London

User Utterance not resulting in entity extraction: “Book a flight for London”

Pattern 2: word1 *n

This can be used as a positional wildcard * that indicates the expected position of the entity based upon the number of words after the specified word1. That is, n words after the word1 are to be considered for the entity, if n words are not present then look for the next occurence of word1.

Pattern for DepartureCity entity: from *2

User Utterance: Book flight from Paris.

Entity Extracted: DepartureCity = Paris

User Utterance not resulting in entity extraction: “Book flight flying from Paris towards London”

Extension to Pattern 2: word1 *~n

Similar to above (pattern 2) but extracts up to n number, if that number of words are available.

Note that entities need to extract something so *~1 is really the same as *1.

 

Pattern 3: a combination of word1 * word2 and word3 *n

This can be used as a combination of patterns for the likely location in the user utterance that the entity value could be found and the number of words contributing to the entity.

Pattern for ArrivalCity entity: “to * from” and “from to *1”

Pattern for DepartureCity entity: “from * to” and “to from *2”

User Utterance: Book flight to London from Paris.

                       or Book flight from Paris to London.

Entity Extracted: ArrivalCity = London and DepartureCity = Paris

User Utterance not resulting in entity extraction: “book flight for London from Paris.

 

Pattern 4: [ word1 word2 ] *

This can be for patterns using a group of words or concepts of which at least one should be present in the utterance. The order within the group is important (see above in intent detection for details).

Pattern for ArrivalCity entity: “to * [ from ]” and “[ from ] to *1”

Pattern for DepartureCity entity: “[ from ] * to” and “to [ from ] *”

User Utterance: Book flight to London from Paris

                       or Book flight from London to Paris.

Entity Extracted: ArrivalCity = London, DepartureCity = Paris

User Utterance not resulting in entity extraction: “Book flight for London from Paris.

 

Pattern 5: ~CustomConcept *

This can be for using concepts. You can create your own custom concepts and use them to define patterns.

Pattern for ArrivalCityentity: “to * from” and “from to *”

Pattern for DepartureCity entity: “~in * to” and “to ~in *”

Custom Concept: ~in(from)

User Utterance: Book flight landing in London and taking off from Paris .

                       or Book flight with takeoff from Paris and landing in London

Entity Extracted: ArrivalCity = London, DepartureCity = Paris

User Utterance not resulting in entity extraction: “book flight landing in London taking off in Paris.

 

Pattern 6: ~intent

Useful in entity patterns and custom entities

Words that are used in the intent identification are dynamically marked with the ~intent concept. This can then be used as an anchor or reference point for some entity patterns.

Sample Pattern: “~intent~trip~plural“

User Utterance not resulting in entity extraction: show my trips.

User Utterance might mark the entity: “Show me the Trip of a Lifetime in-flight magazine.

 

Pattern 7: $currentEntity

Useful in delaying the evaluation of a pattern until the entity is actually processed. Normally entity patterns are evaluated when a dialog starts and on new input to see if any words need to be protected until that entity is processed. This might not always be desirable, especially for strings.

Pattern: “$currentEntity=TaskTitle ‘called *“

The above rule will result in evaluating the pattern when the dialog flow has reached the TaskTitle node.

메뉴