이 문서에서는 Dialogflow CX 사용의 기본사항을 설명하며, 가장 중요한 개념의 개요를 제공합니다.
에이전트
Dialogflow CX 에이전트는 최종 사용자와의 동시 실행 대화를 처리하는 가상 에이전트입니다. 이는 인간 언어의 미묘한 차이를 이해하는 자연어 이해 모듈입니다. Dialogflow는 대화로 이루어진 최종 사용자의 텍스트 또는 오디오를 앱과 서비스가 이해할 수 있는 구조화된 데이터로 변환합니다. 시스템에 필요한 대화 유형을 처리하도록 Dialogflow 에이전트를 직접 설계하고 빌드할 수 있습니다.
Dialogflow 에이전트는 콜센터 상담원과 유사합니다. 둘 다 예상되는 대화 시나리오를 처리하도록 학습해야 하며, 학습이 지나치게 명시적일 필요는 없습니다.
흐름
복잡한 대화상자에는 여러 가지 대화 주제가 포함되는 경우가 많습니다. 예를 들어 피자 배달 에이전트는 음식 주문, 고객 정보, 확인을 별도의 주제로 가질 수 있습니다. 각 주제마다 에이전트가 최종 사용자로부터 관련 정보를 얻기 위해 여러 차례 대화를 해야 합니다.
흐름은 이러한 주제와 연결된 대화 경로를 정의하는 데 사용됩니다. 모든 에이전트에는 기본 시작 흐름이라는 흐름이 있습니다. 간단한 에이전트에는 이 단일 흐름만 필요할 수 있습니다. 보다 복잡한 에이전트에 추가 흐름이 필요할 수 있으며, 다른 개발팀이 이러한 흐름을 빌드하고 유지관리할 수 있습니다. 예를 들어 피자 배달 에이전트의 흐름은 다음과 같습니다.
Dialogflow CX 흐름은 Dialogflow ES 메가 에이전트의 하위 에이전트와 비슷한 용도로 사용됩니다. 흐름은 더 나은 대화 제어를 제공하며, 추가 비용이 발생하지 않습니다.
페이지
Dialogflow CX 대화(세션)를 상태 머신으로 설명하고 시각화할 수 있습니다. CX 세션의 상태는 페이지로 표시됩니다.
각 흐름에 대해 여러 페이지를 정의하면 조합된 페이지에서 흐름이 설계된 주제에 대한 완전한 대화를 처리할 수 있습니다. 특정 시점에 정확히 하나의 페이지는 현재 페이지이고, 현재 페이지는 활성 페이지로 간주되며, 해당 페이지와 연결된 흐름은 활성으로 간주됩니다. 모든 흐름에는 특수한 시작 페이지가 있습니다. 처음에 흐름이 활성화되면 시작 페이지가 현재 페이지가 됩니다. 각 대화 차례에서 현재 페이지는 동일하게 유지되거나 다른 페이지로 전환됩니다.
페이지가 나타내는 대화 상태와 관련된 정보를 최종 사용자로부터 수집하도록 각 페이지를 구성합니다. 예를 들어 아래의 다이어그램에서 피자 배달 에이전트의 음식 주문 흐름을 위한 파란색 페이지를 만들 수 있습니다. 다이어그램의 시작 노드는 음식 주문 흐름의 시작 페이지를 나타냅니다. 흐름이 완료되면 확인 흐름으로 전환됩니다.
항목 유형
항목 유형은 최종 사용자 입력에서 데이터를 추출 방법을 제어하는 데 사용됩니다. CX 항목 유형은 ES 항목 유형과 매우 유사합니다.Dialogflow는 여러 일반적인 데이터 유형과 일치할 수 있는 사전 정의된 시스템 항목을 제공합니다. 예를 들어 날짜, 시간, 색상, 이메일 주소 등을 일치시키는 시스템 항목이 있습니다. 커스텀 데이터와 일치시킬 커스텀 항목을 직접 만들 수도 있습니다. 예를 들어 식료품 가게 에이전트를 통해 구매 가능한 야채의 유형과 일치할 수 있는 야채 항목을 정의할 수 있습니다.
매개변수
매개변수는 세션 중에 최종 사용자가 제공한 값을 캡처하고 참조하는 데 사용됩니다. 각 매개변수에는 이름과 항목 유형이 있습니다. 원시 최종 사용자 입력과 달리 매개변수는 일부 로직을 수행하거나 응답을 생성하는 데 간편하게 사용할 수 있는 구조화된 데이터입니다.CX 매개변수는 ES 매개변수와 유사하지만 유틸리티 및 범위가 확장되었으며 참조 매개변수 구문이 변경되었습니다.
설문지
페이지마다 최종 사용자로부터 수집해야 하는 매개변수의 목록인 양식을 정의합니다. 에이전트는 페이지 매개변수라고도 하는 모든 필수 양식 매개변수를 수집할 때까지 여러 대화 차례에 걸쳐 최종 사용자와 상호작용합니다. 에이전트는 페이지에 정의된 순서대로 이러한 매개변수를 수집합니다. 또한 각 필수 양식 매개변수에 대해 에이전트가 최종 사용자에게 해당 정보를 요청하는 데 사용하는 프롬프트를 제공합니다. 이 프로세스를 양식 작성이라고 합니다.
예를 들어 Collect Customer Info 페이지에 대해 최종 사용자 이름과 전화번호를 수집하는 양식을 만들 수 있습니다.
CX 양식 채우기는 ES 슬롯 채우기와 유사합니다.
인텐트
인텐트는 1회 대화 차례에 대하여 최종 사용자의 의도를 분류합니다. ES 인텐트에 비해, CX 인텐트는 재사용이 더욱 용이한 리소스로 단순화되었습니다.
인텐트에는 다음 데이터가 포함됩니다.
| 용어 | 정의 |
|---|---|
| 표시 이름 | 콘솔에 표시되는 인텐트의 이름입니다. |
| 라벨 | 인텐트 분류를 도와주는 라벨입니다. 예를 들면 헤드 인텐트입니다. |
| 학습 문구 | 학습 문구는 최종 사용자가 입력하거나 말할 수 있는 예시 문구로, 최종 사용자 입력이라고 합니다. 최종 사용자 입력이 이러한 문구 중 하나와 유사한 경우 Dialogflow는 인텐트를 일치시킵니다. Dialogflow의 기본 제공 머신러닝이 다른 비슷한 문구로 목록을 확장하므로 가능한 모든 예시를 정의할 필요는 없습니다. |
| 매개변수 | 최종 사용자 입력의 특정 부분에서 값을 추출하기 위해 매개변수를 사용하도록 학습 문구를 정의합니다. |
| DTMF 패턴 | 전화 통합용 DTMF를 참조하세요. |
웹훅
웹훅은 비즈니스 로직을 호스팅하거나 다른 서비스를 호출하는 서비스입니다. 세션 중에 웹훅을 사용하면 Dialogflow의 자연어 처리에서 추출한 데이터를 사용하여 동적 응답을 생성하거나, 수집된 데이터를 검증하거나, 백엔드에서 작업을 트리거할 수 있습니다.웹훅은 표준 웹훅 또는 가변형 웹훅일 수 있습니다. 표준 웹훅을 사용하면 요청 및 응답 필드가 Dialogflow에서 정의됩니다. 가변형 웹훅을 사용하면 요청 및 응답 필드를 정의할 수 있습니다.
처리
에이전트의 대화 차례인 경우 에이전트는 질문에 대한 답변, 정보 쿼리 또는 세션 종료를 통해 최종 사용자에게 응답해야 합니다. 또한 에이전트가 서비스에 문의하여 동적 응답을 생성하거나 차례를 위해 조치를 취해야 할 수도 있습니다. fulfillment는 이 모든 작업을 완료하는 데 사용됩니다.
fulfillment에는 다음 중 하나가 포함될 수 있습니다.
- 정적 응답 메시지
- 웹훅은 동적 응답 또는 조치를 취해 달라는 요청
- 매개변수 값을 설정하거나 재정의할 매개변수 사전 설정
에이전트의 차례에는 여러 개의 fulfillment를 호출할 수 있으며(호출하는 것이 바람직한 경우도 있음), 각 fulfillment는 응답 메시지를 생성할 수 있습니다. Dialogflow는 이러한 응답을 응답 큐에 유지합니다. 에이전트의 차례가 끝나면 Dialogflow는 순서가 지정된 응답을 최종 사용자에게 전송합니다.
ES fulfillment는 웹훅 서비스 연결로 제한됩니다. CX에서 fulfillment 범위가 확장되었으므로 이제 모든 유형의 프롬프트, 응답을 다룹니다.
상태 핸들러
단순히 핸들러라고도 하는 상태 핸들러는 최종 사용자를 위한 응답을 만들거나 현재 페이지를 전환하여 대화를 제어하는 데 사용됩니다. 각 대화 차례에서 핸들러가 평가되어 세션에 영향을 줄 수 있습니다. 핸들러에는 세 가지 일반적인 유형의 데이터가 있습니다.| 용어 | 정의 |
|---|---|
| 핸들러 요구사항 | 핸들러가 세션에 영향을 미치기 위해 충족해야 하는 요구사항입니다. 핸들러가 요구사항을 충족하여 어떤 방식으로든 세션에 영향을 줄 때 호출된다고 칭합니다. |
| 핸들러 fulfillment | 핸들러가 호출되면 최종 사용자의 응답을 만들기 위해 선택적 fulfillment가 사용됩니다. 이러한 응답은 정적 에이전트 데이터에 정의되거나 웹훅 서비스에서 동적으로 검색됩니다. |
| 핸들러 전환 타겟 | 핸들러가 호출되면 선택적 전환 타겟이 현재 페이지를 변경하는 데 사용됩니다. 다음 페이지는 흐름 시작 페이지이거나 현재 활성화된 흐름 내의 페이지일 수 있습니다. |
핸들러 요구사항이 다른 두 가지 유형의 상태 핸들러가 있습니다.
| 용어 | 정의 |
|---|---|
| 경로 | 경로는 최종 사용자 입력이 인텐트 또는 세션 상태의 일부 조건과 일치하면 호출됩니다. 인텐트 요구사항이 있는 경로를 인텐트 경로라고도 합니다. 조건 요구사항만 있는 경로를 조건 경로라고도 합니다. |
| 이벤트 핸들러 | 이벤트 핸들러는 이벤트 호출 시 호출됩니다. 일부 기본 제공 이벤트는 예기치 않은 최종 사용자 입력이 수신되거나 웹훅 오류가 발생할 때 트리거됩니다. 또한 대화 외부에서 발생하는 상황에서 호출하는 커스텀 이벤트를 정의할 수 있습니다. |
상태 핸들러를 처리하는 세 가지 단계가 있습니다.
| 용어 | 정의 |
|---|---|
| 1. 범위 | 핸들러가 세션에 영향을 주려면 범위에 있어야 합니다. 범위는 핸들러가 흐름, 페이지 또는 양식 매개변수에 적용되는지와 연결된 흐름이 활성 상태인지, 연결된 페이지가 활성 상태인지 또는 현재 에이전트가 연결된 양식 매개변수를 채우려고 하는지에 따라 결정됩니다. |
| 2. 평가 | 범위의 각 핸들러는 순서대로 평가됩니다. 핸들러 요구사항이 충족되면 평가를 통과합니다. |
| 3. 판정 | 핸들러가 범위 내에 있고 평가를 통과하면 핸들러가 호출됩니다. 연결된 fulfillment가 호출되고, 연결된 전환 타겟이 세션에 적용됩니다. |
리전화 및 위치 설정
에이전트를 만들 때 리전을 에이전트의 위치로 지정해야 합니다. 에이전트로 전송된 요청은 이 리전의 Google 서비스로 처리되며 Dialogflow가 저장 데이터를 실제로 지리적인 리전 또는 위치 내에 유지합니다. 최상의 성능을 위해서는 서비스 및 최종 사용자와 가까운 리전을 선택해야 합니다.
에이전트를 만든 후에는 위치를 변경할 수 없습니다. 에이전트 위치를 변경하려면 다른 위치의 새 에이전트로 내보내기 및 복원해야 합니다.
각 위치에는 프로젝트 전체에 적용되는 관련 설정이 있습니다. 대부분의 경우 이러한 위치 설정을 수정할 필요가 없으며 기본 설정이 적합합니다. 시스템에 고객 관리 암호화 키(주로 정부 기관 또는 규제가 적용되는 업계에 필요)가 필요한 경우 위치 설정에 대해 자세히 알아보세요.
Console
Dialogflow는 Dialogflow CX 콘솔이라는 웹 사용자 인터페이스를 제공합니다(문서 참조, 콘솔 열기). 이 콘솔을 사용하여 CX 에이전트를 만들고 빌드하고 테스트합니다. CX 콘솔은 ES 콘솔과 용도가 비슷하지만 CX 콘솔 사용자 인터페이스가 훨씬 시각적입니다. 각 흐름을 대화 상태 머신 다이어그램으로 표시하여 복잡한 에이전트를 더 쉽게 설계하고 이해할 수 있습니다.
Dialogflow CX 콘솔은 Google Cloud Platform(GCP) Console과 다릅니다(문서 보기, 콘솔 열기). Dialogflow CX 콘솔은 Dialogflow CX 에이전트를 관리하는 데 사용되지만, GCP Console은 GCP 관련 Dialogflow CX 설정(예: 결제) 및 기타 GCP 리소스를 관리하는 데 사용됩니다.
대부분의 경우 Dialogflow CX 콘솔을 사용하여 에이전트를 빌드하지만 Dialogflow CX API를 사용하여 고급 시나리오의 에이전트를 빌드할 수도 있습니다.
통합
Dialogflow CX는 현재 다른 대화 플랫폼과 몇 가지 기본 통합을 제공합니다. 이러한 통합은 최종 사용자에게 사용자 인터페이스를 제공하고 Dialogflow API를 호출합니다. 에이전트를 빌드하고 필요한 경우 웹훅 서비스를 구현하기만 하면 됩니다. 각 통합이 상호작용을 처리하는 방법은 플랫폼별로 다르므로 자세한 내용은 특정 통합 문서를 참조하세요.
상호작용
대화 차례마다 상호작용이 발생합니다. 상호작용 중에 최종 사용자가 Dialogflow에 입력을 보내고 Dialogflow가 응답을 보냅니다. 시스템을 구현할 때에는 API를 사용하거나 통합을 사용하는 두 가지의 상호작용 처리 옵션이 있습니다.
API를 사용할 때는 시스템에서 다음을 처리해야 합니다.
- 에이전트 빌드
- 최종 사용자를 위한 사용자 인터페이스를 제공합니다.
- 대화 차례마다 Dialogflow API를 호출하여 최종 사용자 입력을 API로 보냅니다.
- 에이전트 응답이 완전히 정적인 경우(일반적이지 않음)를 제외하고 웹훅 사용 fulfillment를 처리하려면 웹훅 서비스를 호스팅해야 합니다.
통합을 사용하는 경우 시스템에서 다음을 처리하기만 하면 됩니다.
- 에이전트 빌드
- 필요한 경우 웹훅 서비스를 구현합니다.
다음 다이어그램은 세션에서 한 개의 대화 차례 동안 진행되는 단계를 보여줍니다.
- 최종 사용자가 내용을 입력하거나 말합니다. 이를 최종 사용자 입력이라고 합니다.
- 사용자 인터페이스 또는 통합 시스템이 입력을 수신하여 인텐트 인식 요청에서 Dialogflow API로 전달합니다.
- Dialogflow API가 인텐트 인식 요청을 수신합니다. 입력을 인텐트 또는 양식 매개변수와 일치시키고, 필요에 따라 매개변수를 설정하며, 세션 상태를 업데이트합니다. 웹훅 사용 fulfillment를 호출해야 하는 경우 웹훅 서비스에 웹훅 요청을 보냅니다. 그 이외의 경우 6단계로 이동합니다.
- 웹훅 서비스가 웹훅 요청을 수신합니다. 이 서비스는 외부 API 호출, 데이터베이스 쿼리 또는 업데이트 등 필요한 작업을 수행합니다.
- 웹훅 서비스가 응답을 빌드하고 Dialogflow 응답을 다시 Dialogflow로 보냅니다.
- Dialogflow가 인텐트 인식 응답을 만듭니다. 웹훅이 호출된 경우 웹훅 응답에 제공된 응답을 사용합니다. 웹훅이 호출되지 않은 경우 에이전트에 정의된 정적 응답을 사용합니다. Dialogflow가 인텐트 인식 응답을 사용자 인터페이스 또는 통합 시스템에 보냅니다.
- 사용자 인터페이스 또는 통합 시스템은 인텐트 인식 응답을 수신하고 텍스트 또는 오디오 응답을 최종 사용자에게 전달합니다.
- 최종 사용자가 응답을 보거나 듣습니다.