일반 에이전트 설계 권장사항

이 가이드에서는 모든 유형의 에이전트를 설계하는 일반적인 권장사항을 제공합니다.

특히 음성 에이전트 설계에 대해 다룬 음성 에이전트 설계 가이드와 Dialogflow 서비스 사용에 대한 권장사항 가이드도 참조하세요.

일반 도움말

반복적으로 에이전트 제작

에이전트가 크거나 복잡하다면 먼저 최상위 요청만 처리하는 대화를 만듭니다. 기본적인 구조가 완성되면 대화 경로를 반복 실행하면서 최종 사용자가 선택할 수 있는 가능한 모든 경로를 감안했는지 확인하세요.

에이전트가 발전하는 과정에서 테스트 기반 개발에 테스트 사례 기능을 사용하는 것이 좋습니다.

사전 빌드된 에이전트

Dialogflow에서는 시작하는 데 도움이 되는 에이전트 템플릿을 제공합니다. 사전 제작된 에이전트는 금융 서비스, 전자통신, 여행과 같은 일반적인 사용 사례를 다룹니다. 이러한 에이전트에는 가장 일반적인 사용자 쿼리를 처리하기 위한 인텐트와 항목이 함께 제공됩니다. 내 비즈니스와 관련된 경로와 fulfillment를 추가하면 유용한 에이전트를 신속하게 만들 수 있습니다.

통합 및 서비스 연결

Dialogflow 에이전트와 통합하는 방법에는 여러 가지가 있습니다. 이 섹션에서는 통합 방법을 선택하기 위한 권장사항을 제공합니다.

통합

Dialogflow 통합에서는 에이전트에 바로 사용할 수 있는 사용자 인터페이스를 제공합니다. 통합을 사용하는 경우 통합에서 자동으로 처리하므로 Dialogflow API를 직접 호출할 필요가 없습니다. 통합에서 웹사이트에 삽입할 수 있는 텍스트 에이전트를 제공하거나 다른 메시징 플랫폼에 연결하거나 전화 인터페이스를 제공할 수 있습니다.

Dialogflow API

즉시 사용할 수 있는 통합 중 적합한 것이 없거나 시스템에 맞게 인터페이스를 맞춤설정하려는 경우 Dialogflow API를 직접 사용하면 됩니다. 이 접근 방식을 사용하려면 에이전트에 사용자 인터페이스를 구현하거나 기존 사용자 인터페이스를 사용해야 합니다.

웹훅

에이전트를 정적 데이터로 완전히 정의할 수 없다면 웹훅을 사용하여 서비스를 연결하고 동적 시나리오를 처리할 수 있는 에이전트를 제공해야 합니다. 이는 통합과 Dialogflow API 중 무엇을 사용하는지에 따라 적용됩니다.

에이전트 리소스

Dialogflow 에이전트 리소스를 다양한 방법으로 사용하여 원하는 결과를 얻을 수 있습니다. 이 섹션에서는 시나리오에 적합한 리소스를 선택하기 위한 조언을 제공합니다.

흐름 및 페이지

흐름과 페이지는 에이전트에 구조를 제공합니다. 페이지는 상태 머신의 노드로, 흐름은 관련 페이지 그룹으로 생각하면 됩니다. 인텐트가 일치되거나, 조건이 충족되거나, 이벤트가 호출될 때 호출되는 상태 핸들러를 통해 노드 간 전환을 제어합니다.

간단한 에이전트는 단일 흐름으로도 원활하게 작동할 수 있지만 복잡한 에이전트는 주로 여러 흐름을 사용해야 제대로 설계됩니다. 각 흐름은 에이전트의 상위 주제를 나타내야 합니다. 여기서 흐름과 연결된 각 페이지가 주제를 처리하는 데 도움이 됩니다. 또한 각 흐름은 자체 설정을 사용할 수 있으며, 팀 구성원의 하위 집합에서 소유할 수 있어 대규모 에이전트를 설계할 때 업무를 분할하는 데 유용합니다.

크고 복잡한 에이전트를 설계할 때는 '에이전트당 흐름' 및 '흐름당 페이지 수' 한도를 고려해야 합니다. 이러한 한도는 에이전트의 성능을 유지하는 데 도움이 됩니다.

에이전트 설계에 에이전트당 흐름이 너무 많으면 관련 주제를 단일 흐름으로 결합합니다. 예를 들어 다음 주제를 단일 '균형 잡기' 흐름으로 결합할 수 있습니다.

  • 잔액 확인
  • 잔액 절감
  • 주택담보대출 받기
  • 크레딧 잔액 받기

에이전트 설계에 흐름당 페이지가 너무 많으면 관련 페이지를 결합하여 페이지당 여러 경로를 사용합니다.

흐름 및 페이지 한도에 여전히 문제가 있는 경우 에이전트 자체에 너무 많은 비즈니스 로직이 내장되어 있기 때문일 수 있습니다. 이 로직을 웹훅으로 이동하는 것이 좋습니다.

다음은 에이전트 리소스의 대화 제어 세부사항을 세분화된 순서로 나열한 것입니다.

  1. 에이전트(한 에이전트가 모든 대화를 처리)
  2. 흐름(흐름 한 개가 관련 대화 주제를 하나 이상 처리)
  3. 페이지(한 페이지에서 하나 이상의 관련 대화 차례 처리)
  4. 경로(하나의 경로는 사용자 인텐트 또는 조건 확인을 처리)

인텐트 매개변수와 양식 매개변수 비교

시스템이 최종 사용자로부터 구조화된 데이터를 가져오는 주된 방법은 매개변수를 사용하는 것입니다. 인텐트(인텐트 매개변수) 또는 페이지(양식 매개변수) 중 하나의 매개변수를 사용할 수 있습니다.

일부 페이지는 최종 사용자로부터 특정 정보를 수집하는 것이 주된 목적입니다. 예를 들어 최종 사용자의 연락처 정보를 수집하도록 설계된 페이지가 있을 수 있습니다. 이러한 경우 항상 양식 매개변수를 사용하여 이 정보를 수집해야 합니다.

경우에 따라 한 페이지에서 다른 페이지로 전환하는 동안 최종 사용자 정보를 캡처하려고 할 수 있습니다. 예를 들어 대화 시작 시 최종 사용자가 특정 제품을 요청하는 경우 적절한 주문 페이지로 전환하는 동안 원하는 제품을 캡처하려 합니다. 이 경우 인텐트 경로의 일부로 인텐트 매개변수를 사용합니다.

또한 인텐트 매개변수와 양식 매개변수를 모두 사용하는 것이 적합한 상황도 있습니다. 예를 들어 최종 사용자가 대화 시작 시 작은 셔츠를 요청하는 경우 셔츠 주문 페이지로 전환하는 동안 원하는 사이즈 매개변수(스몰)를 캡처하려 합니다. 셔츠 주문 페이지에서 원하는 색상과 같은 추가 정보를 요청할 수 있습니다. 셔츠 주문 페이지에는 사이즈 및 색상에 대한 양식 매개변수가 있어야 합니다. 이 예시에서는 크기 매개변수가 이미 제공되었고 전파되었으므로 에이전트가 색상만 요청합니다. 그러나 최종 사용자가 셔츠 주문 페이지가 활성화될 때 원하는 크기를 제공받지 않은 최종 사용자의 경우 대화는 다른 경로를 따를 수 있습니다. 이 매개변수를 두 가지 방법으로 정의하면 에이전트가 정보를 추출하는 방법이 더 유연해집니다.

경로 및 경로 그룹

다른 페이지로 전환하려는 경우 인텐트가 대응할 때 응답 메시지를 큐에 추가하거나 웹훅을 호출합니다. 또는조건이 충족되면 경로를 사용합니다.

여러 페이지에서 동일한 경로 집합을 사용하려는 경우에는 경로 그룹을 사용합니다. 그러면 에이전트 설계에서 불필요한 중복을 막을 수 있습니다.

인텐트 재사용

비슷한 학습 문구로 여러 인텐트를 정의하는 경우 여러 페이지에서 인텐트를 재사용하는 것이 좋습니다. 이상적으로는 여러 페이지에서 사용되는 범용 인텐트와 단일 페이지에서만 사용되는 특정 인텐트를 정의해야 합니다. 그러면 에이전트 설계에서 불필요한 중복을 막을 수 있습니다.

예를 들어 확인 인텐트는 일반적으로 재사용 가능한 인텐트로 가장 잘 정의됩니다. confirmation.yes 인텐트에는 다음과 같은 학습 문구가 있을 수 있습니다.

  • 예
  • 네
  • 그렇습니다
  • 확인
  • 맞습니다
  • 당연하지요
  • 물론입니다
  • 좋습니다

confirmation.no 인텐트에는 다음과 같은 학습 문구가 있을 수 있습니다.

  • 아니요
  • nah
  • 아니요
  • 싫습니다
  • 관심 없음
  • 전혀 그렇지 않습니다
  • 나중에

이러한 재사용 가능한 확인 인텐트는 에이전트의 여러 시나리오에서 사용할 수 있습니다.

경우에 따라서는 특수한 확인 인텐트도 만들어야 합니다. 예를 들어 주문을 확인할 때 다음과 같은 학습 문구를 사용하여 특수한 order.confirmation.yes 인텐트를 만들 수 있습니다.

  • 주문이 마음에 듭니다
  • 이 주문을 수락합니다

또한 다음과 같은 학습 문구가 포함된 특수한 order.confirmation.no 인텐트도 있습니다.

  • 이 주문을 원하지 않습니다
  • 이 주문을 수락하지 않겠습니다

주문 확인 페이지가 활성 상태인 경우 4가지 인텐트 모두의 인텐트 경로가 범위 내에 있어야 합니다. 그러면 최종 사용자의 일반적인 확인 또는 특정 확인이 적절하게 처리됩니다.

기본 제외 인텐트

기본 제외 인텐트는 최종 사용자가 언급할 수 있지만 에이전트의 인텐트에 대응하지 않는 문구로 채워야 합니다.

처리

다양한 옵션으로 fulfillment를 사용하여 최종 사용자에게 응답할 수 있습니다. 대화 차례 동안 에이전트는 응답 큐에 여러 메시지를 추가할 수 있으며 연결된 큐는 대화 차례가 끝날 때 최종 사용자에게 전송됩니다. 이 섹션에서는 개별 메시지를 만들기 위한 각 옵션을 설명합니다.

  • 페이지 항목 fulfillment: 이 fulfillment는 페이지가 처음 활성화될 때 호출됩니다. 이는 페이지의 목적을 설명하는 메시지를 필요로 할 때 유용하며 페이지가 활성화된 상태에서 메시지를 한 번만 전달해야 합니다. 예를 들면 다음과 같습니다.
    • 입출금 계좌에 대한 무엇이 궁금하세요?
    • 어떤 유형의 제품을 구매하고 싶으세요?
    • 주문하시려는 셔츠에 대한 정보를 수집해야 합니다.
  • 경로: 이 fulfillment는 fulfillment가 있는 인텐트 경로 또는 조건 경로가 호출될 때 호출됩니다. 이는 인텐트 일치, 충족 조건(양식 작성 완료 조건일 수 있음) 또는 전환에 대해 최종 사용자에게 응답하는 메시지를 필요로 하는 경우에 유용합니다. 예를 들면 다음과 같습니다.
    • 예, 해외 요금제에는 일본이 포함됩니다. (인텐트 일치)
    • 셔츠 300개를 구매하시겠어요? (비교 조건 충족)
    • 예, 내일 오전 7시로 예약되어 있습니다. (양식 작성 완료)
    • 이제 aardvarks에 대해 알아보겠습니다. (전환)
  • 이벤트 핸들러: 이 fulfillment는 이벤트가 호출될 때 호출됩니다. 이는 이벤트에 응답하는 메시지를 필요로 할 때 유용합니다. 예를 들면 다음과 같습니다.
    • 구매를 고려 중인 주식의 주가가 10% 증가했습니다. (커스텀 이벤트)
    • 다른 표현을 사용해 말씀해 주시겠어요? (일치 항목 없음 이벤트)
  • 양식용 최초 프롬프트: 이 fulfillment는 에이전트가 양식 채우기를 수행할 때 호출됩니다. 이 메시지에서는 최종 사용자에게 구체적인 질문을 해야 합니다. 각 양식 매개변수마다 고유한 최초 프롬프트 fulfillment가 있습니다. 예를 들면 다음과 같습니다.
    • 어떤 사이즈의 셔츠를 원하세요?
    • 어떤 색상의 셔츠를 원하세요?
  • 양식 재요청 핸들러: 이 fulfillment는 에이전트가 양식 채우기를 수행할 때 호출되며, 현재 매개변수의 최종 사용자 선택을 이해하지 못합니다. 이 fulfillment는 재요청 메시지가 최초 프롬프트 메시지와 달라야 할 경우에만 필요합니다. 재요청 핸들러가 없으면 에이전트가 최초 프롬프트를 재요청 메시지로 사용합니다. 예를 들면 다음과 같습니다.
    • 이해하지 못했습니다. 셔츠에 유효한 색상을 입력하시겠어요?

이름 지정

이 섹션에서는 에이전트 리소스 이름을 지정하는 방법에 대한 조언을 제공합니다.

인텐트 이름 지정

에이전트에 인텐트가 많은 경우 체계적으로 유지하는 데 도움이 되는 이름 지정 스킴을 고려해야 합니다. 구두점으로 인텐트 이름을 구분하는 것이 일반적이며, 특수성은 왼쪽에서 오른쪽으로 증가합니다. 또한 인텐트 이름은 대화 차례에 대한 최종 사용자의 의도를 반영해야 합니다.

적절한 명명 체계가 많지만 다음이 한 가지 예시입니다.

  • phone-service.order.cancel
  • phone-service.order.create
  • phone-service.order.change
  • tv-service.order.cancel
  • tv-service.order.create
  • tv-service.order.change
  • account.balance.get
  • account.balance.pay
  • account.address.get
  • account.address.update

전환

상태 핸들러에 정의된 전환은 활성 페이지를 변경하여 대화의 제어를 제공합니다. 이 섹션에서는 에이전트 전환을 구성하는 방법에 대한 조언을 제공합니다.

보완 전환

전환을 트리거하는 경로를 정의할 때 보완 또는 역방향 경로가 있을 수 있음을 고려하세요.

예를 들면 다음과 같습니다.

  • confirmation.yes에 대한 인텐트 경로가 있으면 confirmation.no에 대한 다른 경로도 정의하는 것이 좋습니다.
  • 부울 = 연산자로 조건 경로를 정의하는 경우 !=을 사용하는 다른 경로도 정의하는 것이 좋습니다.

최종 사용자 입력 처리

이 섹션에서는 에이전트가 최종 사용자 입력을 최적으로 처리할 수 있도록 인텐트 및 학습 문구에 대한 가이드라인을 제공합니다.

학습 문구 최소 20개 이상 정의

인텐트마다 최소 20개의 학습 문구가 있어야 합니다. 그렇지 않으면 NLU 모델에 인텐트와 적절하게 일치하는 정보가 충분하지 않을 수 있습니다. 이는 최소한의 가이드라인입니다. 이상적으로는 더 정의해야 하며, 약 50개가 적합한 대형 에이전트의 헤드 인텐트의 경우 특히 더 그렇습니다.

인텐트 편향 유의

다른 인텐트보다 학습 문구가 훨씬 더 많은 인텐트가 하나 이상 있을 경우 불균형 데이터로 인해 NLU 모델에서 더 큰 인텐트를 선호합니다. 이러한 인텐트 편향은 학습 문구의 양이 한 자릿수 이상 차이가 날 경우 발생할 수 있습니다.

이러한 동작이 선호되는 경우도 있습니다. 실시간 트래픽에서 자주 관찰되는 최종 사용자 입력에 해당하여 다른 인텐트보다 더 자주 대응되어야 할 인텐트를 정의할 수 있습니다.

큰 인텐트에 대한 편향을 원하지 않을 경우에는 이러한 동작이 바람직하지 않을 수 있습니다. 이러한 경우 큰 인텐트의 학습 문구 수를 다른 인텐트와 동일한 자릿수로 줄입니다. 예를 들면 다음과 같습니다.

인텐트 A 학습 문구 인텐트 B 학습 문구 인텐트 B의 편향
20 50 아니요
20 200 경계
20 2000 예

항목 사용 및 학습 문구 수량

인텐트에 사용되는 모든 항목 유형의 경우:

  • 항목 유형의 모든 예시에 주석을 추가합니다.
  • 각 항목 유형에 대해 주석 처리된 예시가 포함된 5개 이상의 학습 문구를 제공합니다.
  • 개체 유형보다 최소 3배 더 많은 학습 문구를 제공합니다. 예를 들어 인텐트에서 주석에 대한 서로 다른 항목 유형을 10개 사용한다면 학습 문구는 30개 이상이어야 합니다.

자연스러운 학습 문구

학습 문구는 대화형이며 자연스러워야 합니다. 즉, 사람들이 실제로 사용하는 말과 일치해야 합니다. 가능하다면 프로덕션에서 발생한 최종 사용자 입력을 학습 데이터로 사용하고 가장 공통적인 입력에 각별한 주의를 기울이세요.

필요한 학습 문구 변형

문구가 폭넓은 요청을 포괄하도록 질문, 명령, 동사의 변형, 보통명사의 동의어를 포함하세요.

'청구서 결제'와 같은 짧은 문구와 '청구서 잔액을 지불해야 한다는 내용의 메일을 받았습니다'와 같은 긴 문구 및 문장을 포함하는 것이 좋습니다. 짧은 문구와 긴 구문에 권장되는 비율은 없지만 프로덕션에서 에이전트에 전송된 실제 최종 사용자 입력을 기반으로 해야 합니다.

길이, 문구, 문장 구조가 다양한 학습 문구를 정의해야 에이전트가 충분히 학습할 수 있습니다. 다양성을 위해 변형을 추가할 필요는 없지만 NLU 모델이 광범위한 최종 사용자 입력에서 최종 사용자의 인텐트를 성공적으로 감지할 수 있을 만큼 변형을 충분히 제공해야 합니다. 충분한 변형이 없으면 과적합이 발생할 위험이 있습니다. 즉, 자신이 제공한 특정 예시와 모델의 관련성이 너무 커서 모델이 다른 예시로 충분히 일반화되지 않을 위험이 있습니다.

대문자 사용(영문) 다양성

드물지만 대문자만 다른 학습 문구를 추가해야 할 수 있습니다. 이는 일반적으로 최종 사용자가 전체 대문자 텍스트 입력을 제공할 것으로 예상되는 상황에 적용됩니다.

다음이 대안이 될 수 있습니다.

  • ML 분류 임곗값 낮추기
  • Dialogflow로 전송하기 전에 최종 사용자 입력 소문자화

불필요한 학습 문구 변형

학습 문구의 사소한 변형은 NLU 모델에 중복된 정보를 제공하므로 피해야 합니다. 예를 들어 다음의 차이점만 있는 변이는 포함하지 마세요.

  • 대문자 사용(영문)(드문 사례 제외): 'Order a ticket' 및 'order a ticket'을 예로 들 수 있습니다.
  • 필러 단어: 예: '예, 티켓 주문' 및 '티켓 주문'
  • 구두점: 예: '도와주시겠어요?' 및 '도와주세요!?'

주석 일관성

주석으로 선택되는 학습 문구 부분에는 항목 대응에 필요한 텍스트가 모두 포함되어야 하지만 그 이상은 포함되면 안 됩니다. 또한 전체 인텐트에서 학습 문구의 유사한 부분에 주석이 추가되었는지 확인합니다.

예를 들어 다음 표는 @sys.date 시스템 항목에 주석을 추가하는 바람직한 방법과 잘못된 방법을 보여줍니다.

제품 잘못됨
9월 7일 출발 9월 7일 출발
7월 4일에 출발 7월 4일에 출발

시스템 항목에 시맨틱상 유의미한 주석 사용

주석에 대해 선택된 학습 문구 부분의 시맨틱 의미는 학습 문구의 나머지 텍스트로부터 영향을 받을 수 있습니다. 예를 들면 다음과 같습니다.

주석 처리된 학습 문구 주석 처리된 텍스트의 시맨틱 의미
나는 7세입니다. 사람의 연령
계약은 7년 동안 유효합니다. 지속 시간

Dialogflow의 머신러닝 모델은 시스템 항목 일치 시 시맨틱 의미를 고려합니다. 학습 문구 부분의 시맨틱 의미는 시스템 항목의 의도된 시맨틱 의미와 일치해야 합니다.

예를 들어 위의 첫 번째 '7년'에 @sys.duration 시스템 항목을 주석으로 사용하지 마세요. '7년'의 시맨틱 의미는 단순 기간과 일치하지 않습니다. 대신 주석에 대해 '7'을 선택하고 @sys.number 시스템 항목을 사용해야 합니다.

미준수 양식 작성 답변 처리를 위한 인텐트 정의

미준수 양식 작성 답변을 처리하기 위한 인텐트를 정의하는 것이 좋습니다. 예를 들어 에이전트가 '여행 날짜가 언제인가요?'라고 질문했을 때 최종 사용자가 '아직 모릅니다.'라고 응답할 수 있습니다. 이 응답은 양식 매개변수 프롬프트를 충족하지 않지만 에이전트에 이 응답과 대응할 수 있는 범위의 인텐트 경로가 있는 경우 에이전트가 이 상황을 잘 처리할 수 있습니다.

@sys.any 피하기

@sys.any 시스템 항목 유형을 사용하지 마세요. 커스텀 항목 빌드를 포함한 모든 경로를 완전히 소진한 경우에만 사용해야 합니다. 이 항목 유형은 매우 광범위하며 원치 않는 동작을 유발할 수 있습니다.

이 항목 유형을 사용하는 경우 이 항목 유형으로 단일 학습 문구의 여러 부분에 주석을 추가하지 마세요. 이 경우 모호성이 발생하며 에이전트 동작이 정의되지 않습니다.

양식 매개변수를 요청할 때는 에이전트가 특정 정보를 예상하므로 양식 매개변수와 함께 @sys.any를 사용하면 위험성이 줄어듭니다.

주석에 다양한 항목 값 포함

주석 처리된 학습 문구를 정의할 때는 문구에 다양한 항목 값 예시를 사용해야 합니다. 주석에 동일한 항목 예시를 일관적으로 사용해서는 안 됩니다. 다음 예시에서는 제품 항목 유형에 대한 올바른 주석과 잘못된 주석을 보여줍니다.

제품 잘못됨
셔츠를 사고 싶습니다 셔츠를 사고 싶습니다
새 모자 주문 새 셔츠 주문
장바구니에 시계 추가 장바구니에 셔츠 추가

커스텀 항목에 변형 포함

커스텀 항목은 광범위한 예시 범위를 포괄해야 합니다. NLU 모델은 다양한 문법적 형식을 제공하지만 가능한 모든 항목을 포함해야 합니다.

적극적 대응 항목 피하기

거의 모든 항목과 일치하는 항목을 정의하지 마세요. 그렇게 하면 ML의 성능과 품질이 저하됩니다. 모든 학습 문구의 거의 모든 항목이 가능한 대응 항목으로 평가되기 때문입니다.

매핑 및 목록 항목은 고유한 값에 집중

매핑 및 목록 항목 유형에는 한 가지 유형의 정보에 대한 고유한 값을 캡처하는 제한된 범위가 있어야 합니다 항목은 핵심적이고 짧고 단순하게 유지하세요.

항목 값이 복잡하면 인텐트 학습 문구가 더 적합하기 때문일 수 있습니다. 예를 들어 다음과 같은 최종 사용자 입력을 고려합니다.

  • '요금제 A로 국제 전화를 거는 방법은 무엇인가요?'
  • '요금제 B로 국제 데이터 로밍 사용'

다음과 같은 작업 및 요금제 항목 유형을 만들지 마세요.

작업 항목 유형 요금제 항목 유형
'국제 전화를 거는 방법은 무엇인가요?' '요금제 A'
'국제 데이터 로밍 사용' '요금제 B'

대신 학습 문구 및 인텐트를 사용하여 작업을 캡처하고 항목을 사용하여 요금제를 캡처해야 합니다.

정규 표현식 항목을 사용한 비단어 식별자 캡처

비단어 식별자를 포함하는 최종 사용자 입력을 캡처할 때는 정규 표현식 개체를 사용해야 합니다. 예를 들어 'AA-256' 또는 'AC-436'과 같은 제품 ID를 캡처하려면 '[AZ]{2}-\d{3}'과 같은 정규 표현식 항목을 사용합니다.

복합 항목 중첩 피하기

복합 항목에서 두 개 이상의 중첩 수준을 사용하지 마세요. 각 중첩 수준마다 품질이 크게 저하됩니다.

비슷한 인텐트 피하기

각 인텐트는 최종 사용자의 의도를 포착해야 합니다. 비슷한 학습 문구로 서로 다른 인텐트를 정의하는 경우 NLU 모델이 충분한 확신을 갖고 어떤 인텐트를 대응시킬지 결정할 수 없으므로 대응이 불안정할 수 있습니다.

두 학습 문구가 동일한 의도를 나타내는 경우 동일한 인텐트에 속해야 합니다. 예를 들어 '현재 청구서 기한 변경'과 '결제 기간 연장'은 모두 기한 변경을 요청하므로 동일한 인텐트에 속해야 합니다. 그러나 '요금제 A로 국제 전화를 걸 수 있나요?'와 '요금제 A로 국제 데이터 로밍을 사용할 수 있나요?'는 각 문구에서 최종 사용자가 원하는 것이 다르므로 다른 인텐트에 속할 수 있습니다.

비슷한 항목 유형 피하기

NLU 모델의 모호성을 가져올 수 있으므로 비슷한 항목 유형이 있는 항목 유형을 여러 개 정의하면 안 됩니다.

프로덕션에서 일치 항목 없음 이벤트를 사용하여 인텐트 개선

프로덕션에서 에이전트를 실행하면 일부 최종 사용자 입력에서 일치 항목 없음 이벤트가 발생할 수밖에 없습니다. 다음 3가지 방법 중 하나로 에이전트를 개선할 수 있습니다.

  • 원하는 인텐트에 최종 사용자 입력을 학습 문구로 추가합니다. 하지만 이것이 항상 최적의 옵션은 아닙니다. 인텐트에 대해 이 작업을 여러 번 수행하면 인텐트 편향이 발생할 수 있습니다.
  • 모든 학습 문구에 의도가 정확히 반영되도록 원하는 인텐트의 학습 문구를 정리합니다. 경우에 따라 다른 학습 문구의 인텐트가 원하는 인텐트의 대응을 막을 수 있습니다.
  • 최종 사용자 입력과 대응하면 안 되는 인텐트에 최종 사용자 입력과 대응할 수 있는 학습 문구가 있는 경우 이러한 학습 문구를 삭제합니다.

특수문자 피하기

학습 문구의 특수문자({, _, #, [ 등)는 무시됩니다. 예상대로 작동하는 이모티콘은 예외입니다.

필러 단어 피하기

필러 단어는 무시해도 텍스트를 이해할 수 있는 단어입니다. 예를 들면 다음과 같습니다.

  • 부탁해
  • 부디
  • 흠
  • 그렇다면

학습 문구에 필러 단어를 사용하는 것은 불필요하지만 NLU 모델에서 무시되기 때문에 해가 되지는 않습니다. 하지만 필러 단어로만 변형되는 학습 문구를 정의해서는 안 됩니다.

필러 단어로 구성된 항목을 정의하지 마세요.

ML 설정 실험

ML 설정을 사용하여 최종 사용자 입력이 처리되는 방법을 조정할 수 있습니다. 대부분의 경우 기본 설정이 적합합니다. 하지만 에이전트 성능을 개선하기 위해 설정을 세부적으로 조정하려고 할 수 있습니다.

최종 사용자에게 응답

이 섹션에서는 fulfillment를 사용하여 최종 사용자에게 응답하는 방법에 대한 가이드라인을 제공합니다.

최종 사용자 시작 메시지

새로 생성된 에이전트에는 시작 인텐트에 대해 자동으로 생성된 인텐트 경로가 있습니다. 최종 사용자를 환영하는 fulfillment 메시지를 포함하도록 이 경로를 수정해야 합니다. 이 메시지는 에이전트를 설명하고 최종 사용자에게 가능한 작업에 대한 정보를 제공해야 합니다.

최종 사용자 정보 확인

응답 시 최종 사용자가 제공한 정보를 반복하는 것이 좋은 경우가 많습니다. 이렇게 하면 에이전트가 요청을 이해하고 있음을 최종 사용자가 알 수 있습니다.

인텐트가 대응되고 전환이 발생하면 최종 사용자에게 요청에 따라 대화가 진행 중임을 알려야 합니다. 예를 들면 다음과 같습니다.

대화상자 설명
최종 사용자: 입출금 계좌에 대해 궁금한 점이 있습니다.
에이전트: 입출금 계좌에 대한 무엇이 궁금하세요?		 최종 사용자 입력에서 인텐트 대응이 발생했고, fulfillment 메시지와 계정 확인 질문을 처리하는 페이지로의 전환을 포함한 경로가 이어졌습니다. 최종 사용자가 입출금 계좌에 대해 알고 싶다는 내용을 에이전트가 확인합니다.

양식 작성이 완료되면 최종 사용자가 제공한 데이터를 반복합니다. 예를 들면 다음과 같습니다.

대화상자 설명
최종 사용자: 내일
에이전트: 내일 오후 7시에 이발을 예약했습니다. 다른 문제와 관련해 도움이 필요하신가요?		 최종 사용자가 활성 페이지의 마지막 양식 매개변수인 날짜 양식 매개변수를 제공했습니다. 에이전트가 예약된 이발의 시간과 날짜를 확인했습니다.

대화 안내

에이전트는 항상 최종 사용자와의 대화를 안내해야 합니다. 이렇게 하려면 각 응답을 다음과 같은 질문으로 끝내면 됩니다.

  • 다른 문제와 관련해 도움이 필요하신가요?
  • 비글에 대한 무엇이 궁금하세요?
  • 주문을 취소하거나 제출하시겠어요?
  • 무엇을 도와드릴까요?
  • 혼자 여행하시나요? 아니면 일행이 있나요?

이러한 질문을 정의할 때는 다음과 같이 여러 개의 질문을 하지 않도록 주의하세요.

  • 아직 계신가요? 어떤 서비스에 관해 문의하려고 하시나요?
  • 여전히 주문을 진행할 의사가 있으신가요? 다른 상품을 더 추가하시겠어요?

최종 사용자가 질문 중 하나에만 답할 수 있으며 에이전트가 해당 상황을 올바르게 처리하지 못할 수 있습니다.

오류 및 예기치 않은 최종 사용자 입력 처리

이 섹션에서는 오류 및 예기치 않은 최종 사용자 입력 처리에 대한 조언을 제공합니다.

기본 제공 이벤트의 이벤트 핸들러 만들기

해당하는 경우 기본 제공 이벤트에 대한 이벤트 핸들러를 만들어야 합니다. 이러한 이벤트를 처리하는 것은 소프트웨어 프로그래밍에서 예외를 포착하는 것과 유사합니다. 상황에 따라 매개변수별 이벤트 핸들러, 페이지별 이벤트 핸들러, 흐름별 이벤트 핸들러를 사용하여 이벤트를 처리하려고 할 수 있습니다.

웹훅 오류 처리

웹훅 서비스가 실패하면 에이전트가 오류를 정상적으로 처리할 수 있어야 합니다. 이를 위해 웹훅 관련 기본 제공 이벤트에 대한 이벤트 핸들러를 정의합니다. 다음은 웹훅 오류를 처리하는 데 권장되는 방법입니다.

  • 웹훅 호출을 트리거하는 상태 핸들러에서 전환 대상을 제공하지 마세요. 그렇게 되면 웹훅 오류 이벤트 핸들러가 호출되지 않습니다. 대신 웹훅 서비스의 웹훅 응답에서 전환 대상을 설정하세요.

  • 오류 카운터를 0으로 초기화할 수 있는 페이지를 선택합니다. 이 페이지는 웹훅 호출을 트리거하는 페이지 전에 활성화되어야 합니다. 이 페이지의 항목 fulfillment는 fulfillment 매개변수 사전 설정을 사용하여 오류 카운터를 0로 초기화해야 합니다. 예를 들면 다음과 같습니다.

    매개변수 값
    webhook-error-count 0

  • 웹훅 오류 이벤트를 처리하는 웹훅 오류 페이지를 만듭니다.

    • 항목 fulfillment는 최종 사용자의 실패를 확인해야 하고 fulfillment 매개변수 사전 설정을 사용하여 오류 카운터 세션 매개변수를 증분해야 합니다. 예를 들면 다음과 같습니다.

      매개변수 값
      webhook-error-count $sys.func.ADD($session.params.webhook-error-count, 1)

    • 오류 수가 허용되는 최댓값보다 낮은 조건이 있는 조건 경로를 정의합니다. (예: $session.params.webhook-error-count <= 3). 이 경로에는 에이전트가 재시도할 최종 사용자에게 알리는 fulfillment가 있어야 합니다. 이 경로에는 PREVIOUS_Page로 설정된 전환 타겟 또는 웹훅을 다시 호출할 수 있는 다른 페이지로 설정되어 있어야 합니다.

    • 오류 수가 허용되는 최댓값보다 큰 조건이 있는 조건 경로를 정의하세요(예: $session.params.webhook-error-count > 3). 이 경로에는 에이전트가 더 이상 재시도하지 않을 것이라고 최종 사용자에게 알리는 fulfillment가 있어야 합니다. 이 경로에는 웹훅 재시도를 트리거하지 않는 페이지로 설정된 전환 타겟이 있어야 합니다.

  • 웹훅 이벤트 핸들러에는 웹훅 오류 페이지로 전환되는 전환 타겟이 있어야 합니다.

도구

이 섹션에서는 에이전트 설계를 개선하는 도구 사용에 대한 조언을 제공합니다.

검증 도구 사용

항상 검증 도구를 사용해 에이전트를 확인해야 합니다. 검증 도구는 이 가이드에서 설명한 문제 중 일부를 찾습니다.

테스트 사례 기능 사용

항상 에이전트의 테스트 사례를 정의해야 합니다. 테스트 사례는 에이전트가 더 많은 시나리오를 처리하도록 발전하는 동안 회귀를 막는 데 도움이 될 수 있습니다.

이전
서비스 사용 권장사항
다음
음성 에이전트 설계 권장사항