지원 종료 공지: 2025년 9월 15 AWS 일에는 Amazon Lex V1에 대한 지원을 중단할 예정입니다. 2025년 9월 15일 이후에는 Amazon Lex V1 콘솔 또는 Amazon Lex V1 리소스에 더 이상 액세스할 수 없습니다. Amazon Lex V2를 사용하는 경우 대신 [Amazon Lex V2 가이드를](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html) 참조하세요.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Lex: 작동 방식
Amazon Lex 를 통해 Amazon Alexa 와 동일한 기술로 구동되는 음성 또는 텍스트 인터페이스를 사용하여 애플리케이션을 구축할 수 있습니다. 다음은 Amazon Lex 사용할 때 수행하는 일반적인 몇 가지 단계입니다.
1. 봇을 생성한 후 지원하고 싶은 하나 이상의 의도로 이를 구성합니다. 사용자의 목표(의도)를 이해하고 사용자와의 대화에 참여하여 정보를 유도하며 사용자의 의도를 이행하도록 봇을 구성합니다.
1. 봇 테스트. Amazon Lex 콘솔에서 제공하는 테스트 창 클라이언트를 사용할 수 있습니다.
1. 버전을 게시하고 별칭을 만듭니다.
1. 봇을 배포합니다. 모바일 애플리케이션 등의 플랫폼이나 Facebook Messenger 등의 메시징 플랫폼에 봇을 배포할 수 있습니다.
시작하기 전에 다음과 같은 Amazon Lex 의 핵심 개념 및 용어를 익힙니다.
+ **봇** - 봇은 피자 주문, 호텔 예약, 꽃 주문 등과 같은 자동화 작업을 수행합니다. Amazon Lex 봇은 자동 음성 인식(ASR)및 자연어 이해(NLU) 기능으로 구동됩니다. 각 데이터 스트림은 계정 내에서 고유한 이름을 가져야 합니다.
Amazon Lex 봇은 텍스트나 음성으로 제공된 사용자 입력을 이해하고 자연 언어로 대화할 수 있습니다. Lambda 함수 를 만들고 이를 사용자의 의도 구성에 코드 후크로 추가하여, 사용자의 데이터 검증 및 이행 작업을 수행할 수 있습니다.
+ **의도** – 의도는 사용자가 수행하고자 하는 작업을 나타냅니다. 하나 이상의 관련 의도를 지원하도록 봇을 생성합니다. 예를 들어, 피자 및 음료를 주문하는 봇을 만들 수 있습니다. 각 의도에 대해 다음 필수 정보를 제공합니다.
+ **의도 이름**– 의도를 설명하는 이름입니다. 예를 들어 **OrderPizza**입니다. 의도 이름은 계정 내에서 고유해야 합니다.
+ **샘플 표현** – 사용자가 의도를 전달하는 방식입니다. 예를 들어, 사용자는 "피자 주문할 수 있나요" 또는 "피자 주문하고 싶어요"라고 말할 수 있습니다.
+ **의도 이행 방법** - 사용자가 필수 정보를 제공한 후 의도를 이행하는 방법입니다(예: 동네 피자 가게에서 주문). Lambda 함수 를 생성하여 의도를 이행하는 것을 권장합니다.
Amazon Lex 에서 간단히 클라이언트 애플리케이션에 정보를 반환하여 필요한 이행을 수행하도록 의도를 선택적으로 구성할 수 있습니다.
Amazon Lex 는 피자 주문과 같은 사용자 지정 의도 외에도 봇을 빠르게 설정할 수 있도록 내장 의도도 제공합니다. 자세한 내용은 [기본 제공 의도 및 슬롯 유형](howitworks-builtins.md)을 참조하세요.
+ **슬롯** – 의도에는 0개 이상의 슬롯 또는 파라미터가 필요할 수 있습니다. 의도 구성의 일부로 슬롯을 추가합니다. 런타임 시에는 Amazon Lex 는 사용자에게 특정 슬롯 값을 묻습니다. 사용자가 모든 *필수* 슬롯의 값을 제공해야 Amazon Lex 가 의도를 이행할 수 있습니다.
예를 들어, `OrderPizza` 의도에는 피자 크기, 크러스트 유형 및 피자 개수와 같은 슬롯이 필요합니다. 의도 구성에 이러한 슬롯을 추가합니다. 각 슬롯에 대해 슬롯 유형 및 Amazon Lex 가 사용자로부터 데이터를 유도하도록 클라이언트에 보내는 프롬프트를 제공합니다. 사용자는 "라지로 부탁해요" 또는 "스몰 사이즈가 좋아요."와 같은 추가 단어가 포함된 슬롯 값으로 응답할 수 있습니다. Amazon Lex 는 여전히 의도한 슬롯 값을 이해할 수 있습니다.
+ **슬롯 유형** – 각 슬롯에는 유형이 있습니다. 사용자 지정 슬롯 유형을 생성하거나 내장 슬롯 유형을 사용할 수 있습니다. 각 슬롯 유형은 계정 내에서 고유한 이름을 가져야 합니다. 예를 들어, `OrderPizza` 의도에 대한 다음과 같은 슬롯 유형을 만들고 사용할 수 있습니다.
+ 사이즈 – 열거 값은 `Small`, `Medium` 및 `Large`입니다.
+ 크러스트 – 열거 값은 `Thick` 및 `Thin`입니다.
Amazon Lex 는 내장 슬롯 유형도 제공합니다. 예를 들어 `AMAZON.NUMBER` 는 주문한 피자의 개수로 사용할 수 있는 내장 슬롯 유형입니다. 자세한 내용은 [기본 제공 의도 및 슬롯 유형](howitworks-builtins.md)을 참조하세요.
현재 Amazon Lex 사용 가능한 모든 AWS 리전 목록은 *Amazon Web Services 일반 참조*의 [AWS 리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#lex_region) 를 참조하세요.
다음 주제에서는 추가 정보를 제공합니다. 이를 순서대로 검토한 다음 [Amazon Lex 시작하기](getting-started.md) 연습을 수행하는 것이 좋습니다.
**Topics**
+ [Amazon Lex에서 지원되는 언어](how-it-works-language.md)
+ [프로그래밍 모델](programming-model.md)
+ [메시지 관리](howitworks-manage-prompts.md)
+ [대화 컨텍스트 관리](context-mgmt.md)
+ [신뢰도 점수 사용](confidence-scores.md)
+ [대화 로그](conversation-logs.md)
+ [Amazon Lex API로 세션 관리](how-session-api.md)
+ [봇 배포 옵션](chatbot-service.md)
+ [기본 제공 의도 및 슬롯 유형](howitworks-builtins.md)
+ [사용자 지정 슬롯 유형](howitworks-custom-slots.md)
+ [슬롯 난독화](how-obfuscate.md)
+ [감정 분석](sentiment-analysis.md)
+ [Amazon Lex 리소스 태그 지정](how-it-works-tags.md)
# Amazon Lex에서 지원되는 언어
Amazon Lex V1은 다양한 언어와 로캘을 지원합니다. 지원되는 언어와 이를 지원하는 기능은 다음 표에 나열되어 있습니다.
Amazon Lex V2는 추가 언어를 지원합니다. [Amazon Lex V2에서 지원되는 언어](https://docs.aws.amazon.com/lexv2/latest/dg/how-languages.html)를 참조하십시오.
## 지원되는 언어 및 로캘
Amazon Lex V1은 다음 언어 및 로캘을 지원합니다.
| 코드 | 언어 및 로캘 |
| --- | --- |
| de-DE | 독일어(독일) |
| en-AU | 영어(호주) |
| en-GB | 영어(영국) |
| en-IN | 영어(인도) |
| en-US | 영어(미국) |
| es-419 | 스페인어(라틴 아메리카) |
| es-ES | 스페인어(스페인) |
| es-US | 스페인어(미국) |
| fr-CA | 프랑스어(캐나다) |
| fr-FR | 프랑스어(프랑스) |
| it-IT | 이탈리아어(이탈리아) |
| ja-JP | 일본어(일본) |
| ko-KR | 한국어(한국) |
## Amazon Lex 기능에서 지원하는 언어 및 로캘
모든 Amazon Lex 기능은 이 표에 나열된 경우를 제외하고 모든 언어 및 로캘에서 지원됩니다.
| 기능 | 지원되는 언어 및 로캘 |
| --- | --- |
| [의도 컨텍스트 설정](context-mgmt-active-context.md) | 영어(미국)(en-US) |
# 프로그래밍 모델
*봇*은 Amazon Lex 의 기본 리소스 유형입니다. Amazon Lex 의 기타 리소스 유형은 *의도*, *슬롯 유형*, *별칭* 및 *봇 채널 연결*입니다.
Amazon Lex 콘솔 또는 모델 구축 API를 사용하여 봇을 생성합니다. 콘솔은 애플리케이션을 위해 프로덕션용으로 사용할 준비가 된 봇을 구축할 때 사용하는 그래픽 사용자 인터페이스를 제공합니다. 원하는 경우 AWS CLI 또는 자체 사용자 지정 프로그램을 통해 모델 구축 API를 사용하여 봇을 생성할 수 있습니다.
봇을 생성한 후 [지원되는 플랫폼](https://docs.aws.amazon.com/lex/latest/dg/chatbot-service.html) 중 하나에 이를 배포하거나 자체 애플리케이션에 통합할 수 있습니다. 사용자가 봇과 상호 작용하는 경우 클라이언트 애플리케이션은 Amazon Lex 런타임 API를 사용하여 봇에 요청을 보냅니다. 예를 들어, 사용자가 "피자 주문하고 싶어요"라고 말하면, 클라이언트는 런타임 API 작업 중 하나를 사용하여 Amazon Lex 에 이 입력을 보냅니다. 사용자는 입력을 음성이나 텍스트로 제공할 수 있습니다.
또한 Lambda 함수 를 생성하여 의도에 사용할 수 있습니다. 이러한 Lambda 함수 코드 후크를 사용하여 초기화, 사용자 입력 검증, 의도 이행 등과 같은 런타임 활동을 수행합니다. 다음 섹션에서 추가 정보를 제공합니다.
**Topics**
+ [모델 구축 API 작업](#programming-model-build-time-api)
+ [런타임 API 작업](#programming-model-runtime-api)
+ [코드 후크로서의 Lambda 함수](#prog-model-lambda)
## 모델 구축 API 작업
봇, 의도 및 슬롯 유형을 프로그래밍 방식으로 생성하려면 모델 구축 API 작업을 사용합니다. 또한 모델 구축 API를 사용하여 봇에 대한 리소스를 관리, 업데이트 및 삭제할 수 있습니다. 모델 구축 API 작업은 다음과 같습니다.
+ [PutBot](API_PutBot.md), [PutBotAlias](API_PutBotAlias.md), [PutIntent](API_PutIntent.md) 및 [PutSlotType](API_PutSlotType.md) - 각각 봇, 봇 별칭, 의도 및 슬롯 유형을 생성 및 업데이트합니다.
+ [CreateBotVersion](API_CreateBotVersion.md), [CreateIntentVersion](API_CreateIntentVersion.md) 및 [CreateSlotTypeVersion](API_CreateSlotTypeVersion.md)- 각각 봇, 의도 및 슬롯 유형의 버전을 생성 및 게시합니다.
+ [GetBot](API_GetBot.md) 및 [GetBots](API_GetBots.md) - 각각 생성한 특정 봇 또는 봇 목록을 가져옵니다.
+ [GetIntent](API_GetIntent.md) 및 [GetIntents](API_GetIntents.md)- 각각 생성한 특정 의도 또는 의도 목록을 가져옵니다.
+ [GetSlotType](API_GetSlotType.md) 및 [GetSlotTypes](API_GetSlotTypes.md)- 각각 생성한 특정 슬롯 유형 또는 슬롯 유형 목록을 가져옵니다.
+ [GetBuiltinIntent](API_GetBuiltinIntent.md), [GetBuiltinIntents](API_GetBuiltinIntents.md) 및 [GetBuiltinSlotTypes](API_GetBuiltinSlotTypes.md) - 각각 봇에서 사용할 수 있는 Amazon Lex 내장 의도, Amazon Lex 내장 의도 목록 또는 내장 슬롯 유형 목록을 가져옵니다.
+ [GetBotChannelAssociation](API_GetBotChannelAssociation.md) 및 [GetBotChannelAssociations](API_GetBotChannelAssociations.md) - 각각 봇과 메시징 플랫폼 간의 연결 또는 이러한 연결 목록을 가져옵니다.
+ [DeleteBot](API_DeleteBot.md), [DeleteBotAlias](API_DeleteBotAlias.md), [DeleteBotChannelAssociation](API_DeleteBotChannelAssociation.md), [DeleteIntent](API_DeleteIntent.md) 및 [DeleteSlotType](API_DeleteSlotType.md)- 계정에서 불필요한 리소스를 제거합니다.
모델 구축 API를 사용하면 Amazon Lex 리소스를 관리하기 위한 사용자 지정 도구를 생성할 수 있습니다. 예를 들어 봇, 의도 및 슬롯 유형에 대해 각각 100개의 버전 한도가 있습니다. 모델 구축 API를 사용하여 봇이 이 한도에 근접하면 오래된 버전을 자동으로 삭제하는 도구를 구축할 수 있습니다.
한 번에 하나의 작업만 리소스를 업데이트하도록 하기 위해 Amazon Lex는 체크섬을 사용합니다. `Put` API 작업 ([PutBot](API_PutBot.md), [PutBotAlias](API_PutBotAlias.md), [PutIntent](API_PutIntent.md) 또는 [PutSlotType](API_PutSlotType.md))을 사용하여 리소스를 업데이트하는 경우 요청에서 리소스의 현재 체크섬을 전달해야 합니다. 도구 두 개가 동시에 리소스를 업데이트하려고 하면 둘 다 동일한 현재 체크섬을 제공합니다. Amazon Lex 에 도달한 첫 번째 요청이 리소스의 현재 체크섬과 일치합니다. 두 번째 요청이 도착할 때, 체크섬은 다릅니다. 두 번째 도구는 `PreconditionFailedException` 예외를 수신하고 업데이트가 종료됩니다.
`Get` 작업 ([GetBot](API_GetBot.md), [GetIntent](API_GetIntent.md), 및 [GetSlotType](API_GetSlotType.md))은 결국에는 일관성을 유지하게 됩니다. `Put` 작업 중 하나를 사용하여 리소스를 생성 또는 수정한 직후에 `Get` 작업을 사용하면 변경 사항이 반환되지 않을 수 있습니다. `Get` 작업이 최신 업데이트를 반환하면 리소스가 다시 수정될 때까지 항상 업데이트된 리소스를 반환합니다. 체크섬을 확인해 업데이트된 리소스가 반환되었는지 확인할 수 있습니다.
## 런타임 API 작업
클라이언트 애플리케이션은 다음과 같은 런타임 API 작업을 사용하여 Amazon Lex와 통신합니다.
+ [PostContent](API_runtime_PostContent.md) – 음성 또는 텍스트 입력을 받아들여 의도 정보와 사용자에게 전달할 텍스트 또는 음성 메시지를 반환합니다. Amazon Lex 는 현재 다음 오디오 형식을 지원합니다.
입력 오디오 형식 - LPCM 및 Opus
출력 오디오 형식 - MPEG, OGG, PCM
`PostContent` 작업은 8kHz 및 16kHz에서 오디오 입력을 지원합니다. 최종 사용자가 전화를 통해 Amazon Lex 와 대화하는 애플리케이션(예: 자동화된 콜 센터)은 8kHz 오디오를 직접 전달할 수 있습니다.
+ [PostText](API_runtime_PostText.md) – 텍스트 입력을 받아들여 의도 정보와 사용자에게 전달할 텍스트 메시지를 반환합니다.
클라이언트 애플리케이션은 런타임 API를 사용하여 특정 Amazon Lex 봇을 직접 호출하여 표현(사용자 텍스트 또는 음성 입력)을 처리합니다. 예를 들어, 사용자가 "피자가 필요해"라고 말한다고 가정하겠습니다. 클라이언트는 Amazon Lex 런타임 API 작업 중 하나를 사용하여 봇에 이 사용자 입력을 보냅니다. 사용자 입력으로부터, Amazon Lex 는 사용자 요청이 봇에서 정의된 `OrderPizza` 의도에 대한 것임을 인식합니다. Amazon Lex 는 사용자를 대화에 참여시켜 피자 크기, 토핑, 피자 수와 같은 필수 정보 또는 슬롯 데이터를 수집합니다. 사용자가 필수 슬롯 데이터를 모두 제공하면 Amazon Lex는 Lambda 함수 코드 후크를 간접 호출하여 의도를 이행하거나 의도 구성 방법에 따라 클라이언트에 의도 데이터를 반환합니다.
봇에서 음성 입력을 사용하는 경우 [PostContent](API_runtime_PostContent.md) 작업을 사용합니다. 예를 들어, 자동화된 콜 센터 애플리케이션은 상담원 대신에 Amazon Lex 봇에 음성을 보내서 고객 문의를 처리할 수 있습니다. 8kHz 오디오 형식을 사용하여 전화에서 Amazon Lex 로 직접 오디오를 보낼 수 있습니다.
Amazon Lex 콘솔의 테스트 창에서는 [PostContent](API_runtime_PostContent.md) API를 사용하여 텍스트 및 음성 요청을 Amazon Lex 에 보냅니다. [Amazon Lex 시작하기](getting-started.md) 연습에서 이 테스트 창을 사용합니다.
## 코드 후크로서의 Lambda 함수
Lambda 함수를 코드 후크로 간접 호출하도록 Amazon Lex 봇을 구성할 수 있습니다. 코드 후크는 다음과 같이 여러 가지 용도로 사용할 수 있습니다.
+ 사용자 상호 작용을 사용자 지정합니다. 예를 들어 Joe가 사용 가능한 피자 토핑을 요청하면 Joe의 선택에 대한 사전 지식을 활용하여 토핑의 하위 집합을 표시할 수 있습니다.
+ 사용자 입력 검증 - Jen이 몇 시간 후에 꽃을 찾아가고 싶어 한다고 가정하겠습니다. Jen이 적절한 응답을 입력하고 전송하는 시간을 검증할 수 있습니다.
+ 사용자의 의도 이행 - Joe가 피자 주문에 필요한 모든 정보를 제공하면, Amazon Lex는 동네 피자 전문점에서 주문할 수 있는 Lambda 함수를 간접 호출하도록 구성할 수 있습니다.
의도를 구성할 때 다음 위치에서 Lambda 함수 를 코드 후크로 지정합니다.
+ 대화 코드 후크(초기화 및 검증) - 이 Lambda 함수 는 각 사용자 입력에 대해 간접 호출됩니다(Amazon Lex가 사용자 의도를 올바르게 이해하고 있다고 가정).
+ 이행 코드 후크 - 이 Lambda 함수 는 사용자가 의도를 이행하는 데 필요한 모든 슬롯 데이터를 제공한 후 간접 호출됩니다.
아래 예제 스크린샷에 표시된 것처럼 Amazon Lex 콘솔에서 의도를 선택하고 이러한 코드 후크를 설정할 수 있습니다.
![\[Lambda 함수 코드 후크를 보여 주는 Amazon Lex 콘솔.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/how-works-10.png)
또한 [PutIntent](API_PutIntent.md) 작업의 `dialogCodeHook` 및 `fulfillmentActivity` 필드를 사용하여 코드 후크를 설정할 수도 있습니다.
하나의 Lambda 함수 가 초기화, 검증 및 이행을 수행할 수 있습니다. Lambda 함수 가 수신하는 이벤트 데이터에는 호출자를 대화 또는 이행 코드 후크로 식별하는 필드가 있습니다. 이러한 정보를 사용하여 적절한 코드 부분을 실행할 수 있습니다.
Lambda 함수 를 사용하여 복잡한 대화를 탐색할 수 있는 봇을 구축할 수 있습니다. Lambda 함수 응답에서 `dialogAction` 필드를 사용하여 Amazon Lex 에 특정 조치를 취하라고 지시할 수 있습니다. 예를 들어 `ElicitSlot` 대화 작업을 사용하여 Amazon Lex 에 사용자에게 필요 없는 슬롯 값을 묻도록 지시할 수 있습니다. 확인 프롬프트가 정의되어 있는 경우에는 사용자가 이전 의도를 마치면 `ElicitIntent` 대화 작업을 사용하여 새 의도를 유도할 수 있습니다.
자세한 내용은 [Lambda 함수 사용](using-lambda.md)을 참조하세요.
# 메시지 관리
**Topics**
+ [메시지 유형](#msg-prompts-msg-types)
+ [메시지 구성을 위한 컨텍스트](#msg-prompts-context-for-msgs)
+ [지원되는 메시지 형식](#msg-prompts-formats)
+ [메시지 그룹](#message-groups)
+ [응답 카드](#msg-prompts-resp-card)
봇을 생성할 때 봇에서 클라이언트로 보낼 설명 또는 정보 제공용 메시지를 구성할 수 있습니다. 다음 예제를 살펴보세요.
+ 다음의 설명 프롬프트를 사용하여 봇을 구성할 수 있습니다.
```
I don't understand. What would you like to do?
```
Amazon Lex 가 사용자의 의도를 이해하지 못한 경우 클라이언트에 이 메시지를 보냅니다.
+ `OrderPizza`이라는 이름의 의도를 지원하는 봇을 생성한다고 가정하겠습니다. 피자 주문의 경우 사용자가 피자 크기, 토핑, 크러스트 유형과 같은 정보를 제공하도록 해야 합니다. 다음 프롬프트를 구성할 수 있습니다.
```
What size pizza do you want?
What toppings do you want?
Do you want thick or thin crust?
```
Amazon Lex 는 피자 주문이라는 사용자의 의도를 확인한 후, 클라이언트에 이러한 메시지를 보내 사용자로부터 정보를 얻습니다.
이 섹션에서는 봇 구성에서 사용자 상호 작용을 설계하는 작업에 관해 설명합니다.
## 메시지 유형
메시지는 프롬프트 또는 문장일 수 있습니다.
+ *프롬프트*는 일반적으로 질문으로 사용자 응답을 기대합니다.
+ *문장*은 정보를 제공합니다. 응답을 기대하지 않습니다.
메시지에는 슬롯, 세션 속성 및 요청 속성에 대한 참조가 포함될 수 있습니다. 런타임 실행 시 Amazon Lex 는 이러한 참조를 실제 값으로 대체합니다.
설정된 슬롯 값을 참조하려면 다음 구문을 사용합니다.
```
{SlotName}
```
세션 속성을 참조하려면 다음 구문을 사용합니다.
```
[SessionAttributeName]
```
요청 속성을 참조하려면 다음 구문을 사용합니다.
```
((RequestAttributeName))
```
메시지에는 슬롯 값, 세션 속성 및 요청 속성이 모두 포함될 수 있습니다.
예를 들어, 봇의 OrderPizza 의도에서 다음과 같은 메시지를 구성한다고 가정하겠습니다.
```
"Hey [FirstName], your {PizzaTopping} pizza will arrive in [DeliveryTime] minutes."
```
이 메시지는 슬롯(`PizzaTopping`)과 세션 속성(`FirstName` 및 `DeliveryTime`)을 모두 참조합니다. 런타임 실행 시 Amazon Lex 는 이러한 자리 표시자를 값으로 바꾸고, 클라이언트에 다음 메시지를 반환합니다.
```
"Hey John, your cheese pizza will arrive in 30 minutes."
```
메시지 안에 대괄호([]) 또는 중괄호(\$1\$1)를 포함하려면 백슬래시(\$1) 이스케이프 문자를 사용합니다. 예를 들면 다음 메시지에는 중괄호와 대괄호가 포함됩니다.
```
\{Text\} \[Text\]
```
클라이언트 애플리케이션으로 반환된 텍스트는 다음과 비슷합니다.
```
{Text} [Text]
```
세션 속성에 대한 자세한 내용은 런타임 API 작업([PostText](API_runtime_PostText.md) 및 [PostContent](API_runtime_PostContent.md))을 참조하십시오. 예제는 [여행 예약](ex-book-trip.md) 섹션을 참조하세요.
또한 Lambda 함수 는 메시지를 생성하고 이를 Amazon Lex 에 반환하여 사용자에게 보낼 수 있습니다. 의도 구성 시 Lambda 함수 를 추가하는 경우 메시지를 동적으로 생성할 수 있습니다. 봇을 구성하는 동안 메시지를 제공하면 Lambda 함수 에서 프롬프트를 구성할 필요가 없습니다.
## 메시지 구성을 위한 컨텍스트
봇을 생성하려는 경우 봇의 설명 프롬프트, 슬롯 값 프롬프트 및 의도의 메시지 등 다양한 컨텍스트에서 메시지를 생성할 수 있습니다. Amazon Lex 는 각 컨텍스트에서 사용자에게 반환할 적절한 메시지를 선택합니다. 각 컨텍스트에 대한 메시지 그룹을 제공할 수 있습니다. 메시지 그룹을 제공할 경우 Amazon Lex 는 그룹에서 메시지 하나를 임의로 선택합니다. 또한 메시지의 형식을 지정하거나 메시지를 함께 그룹화할 수도 있습니다. 자세한 내용은 [지원되는 메시지 형식](#msg-prompts-formats)을 참조하세요.
의도와 연결된 Lambda 함수 가 있는 경우 빌드 시에 구성한 메시지 중 하나를 재정의할 수 있습니다. 하지만 이러한 메시지를 사용하는 데는 Lambda 함수 가 필요하지 않습니다.
### 봇 메시지
설명 프롬프트와 세션 종료 메시지로 봇을 구성할 수 있습니다. 런타임 실행 시 Amazon Lex 가 ** 사용자의 의도를 이해하지 못한 경우 설명 프롬프트를 사용합니다. Amazon Lex 가 세션 종료 메시지를 보내기 전에 설명을 요청하는 횟수를 구성할 수 있습니다. Amazon Lex 콘솔의 **오류 처리** 섹션에서 다음 이미지와 같이 봇 수준 메시지를 구성합니다.
![\[콘솔의 편집기 탭에 있는 오류 처리 섹션. 설명 프롬프트와 끊기 문구를 지정할 수 있습니다.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/how-works-20.png)
API를 사용하면 [PutBot](API_PutBot.md) 작업에서 `clarificationPrompt` 및 `abortStatement`필드를 설정하여 메시지를 구성할 수 있습니다.
의도와 함께 Lambda 함수 를 사용하는 경우 Lambda 함수 는 응답을 반환하여 Amazon Lex 에 사용자의 의도를 묻도록 지정할 수도 있습니다. Lambda 함수 에서 이러한 메시지를 제공하지 않는 경우 Amazon Lex 는 설명 프롬프트를 사용합니다.
### 슬롯 프롬프트
의도에는 각각의 필요한 슬롯에 대해 한 개 이상의 프롬프트 메시지를 지정해야 합니다. 런타임 실행 시 Amazon Lex 는 이러한 메시지 중 하나를 사용하여 사용자에게 이 슬롯의 값을 입력하라는 메시지를 표시합니다. 예를 들어 `cityName` 슬롯에 대해 유효한 프롬프트는 다음과 같습니다.
```
Which city would you like to fly to?
```
콘솔을 사용하여 각 슬롯에 대해 하나 이상의 프롬프트를 설정할 수 있습니다. 또한 [PutIntent](API_PutIntent.md) 작업을 사용하여 프롬프트 그룹을 생성할 수도 있습니다. 자세한 내용은 [메시지 그룹](#message-groups)을 참조하세요.
### 응답
콘솔에서 **응답** 섹션을 사용하여 봇에 대한 동적 참여 대화를 구축합니다. 응답에 대해 하나 이상의 메시지 그룹을 생성할 수 있습니다. 런타임 시에 Amazon Lex 는 각 메시지 그룹에서 메시지 하나를 선택하여 응답을 빌드합니다. 메시지 그룹에 대한 자세한 내용은 [메시지 그룹](#message-groups) 섹션을 참조하십시오.
예를 들면 첫 번째 메시지 그룹에는 "안녕하세요", "안녕" 및 "반가워" 같은 다양한 인사말이 포함될 수 있습니다. 두 번째 메시지 그룹에는 "저는 예약 봇입니다" 및 "예약 봇입니다" 같은 다양한 형태의 소개말이 포함될 수 있습니다. 세 번째 메시지 그룹은 "저는 자동차 렌탈과 호텔 예약을 도울 수 있습니다", "자동차 렌탈과 호텔 예약을 할 수 있습니다", "자동차 렌탈과 호텔 예약을 하도록 도울 수 있습니다" 등 봇의 기능을 전달할 수 있습니다.
Lex는 각 메시지 그룹의 메시지를 사용하여 대화의 응답을 동적으로 빌드합니다. 예를 들면 다음과 같은 대화가 있을 수 있습니다.
![\[봇과 가능한 대화 중 하나입니다.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/default-response-10b.png)
다른 하나는 다음과 같을 수 있습니다.
![\[봇과 가능한 대화 중 또 다른 하나입니다.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/default-response-20c.png)
둘 중 어느 경우든, 사용자는 `BookCar` 또는 `BookHotel` 의도와 같이 새 의도로 응답할 수 있습니다.
응답에서 후속 질문을 하도록 봇을 설정할 수 있습니다. 예를 들면, 이전 대화의 경우 "자동차 렌탈과 호텔 예약을 도와드릴까요?", "예약을 하고 싶으신가요?" 및 "제가 도울 수 있을까요?" 같은 질문을 사용하여 네 번째 메시지 그룹을 만들 수 있습니다. "아니요"를 응답으로 포함하는 메시지의 경우 후속 프롬프트를 만들 수 있습니다. 다음은 예제를 제공합니다.
![\[봇과의 대화에서 후속 조치 메시지.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/default-response-25a.png)
후속 프롬프트를 만들려면 **사용자 응답 대기**를 선택합니다. 그 다음 사용자가 "아니요"라고 말할 때 보낼 메시지를 입력합니다. 후속 프롬프트로 사용할 응답을 만드는 경우 설명문에 대한 응답이 "아니요"일 때에 적합한 설명문도 지정해야 합니다. 다음 이미지를 예시로 참조하세요.
![\[사용자가 “아니요”라고 말할 때를 위한 메시지 구성.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/default-response-30b.png)
API를 사용하여 의도에 응답을 추가하려면 `PutIntent` 작업을 사용합니다. 응답을 지정하려면 `PutIntent` 요청에서 `conclusionStatement` 필드를 설정합니다. 후속 프롬프트를 설정하려면 `followUpPrompt` 필드를 설정하고 사용자가 "아니요"라고 말할 때 보낼 문장을 포함시킵니다. 동일한 의도에 대해 `conclusionStatement` 필드와 `followUpPrompt` 필드를 둘 다 설정할 수는 없습니다.
## 지원되는 메시지 형식
[PostText](API_runtime_PostText.md) 작업을 사용하거나 `Accept` 헤더가 `text/plain;charset=utf8`로 설정된 [PostContent](API_runtime_PostContent.md) 작업을 사용하는 경우 Amazon Lex 는 다음 형식의 메시지를 지원합니다.
+ `PlainText`—메시지에 일반 UTF-8 텍스트가 포함됩니다.
+ `SSML`—메시지에 음성 출력용으로 서식이 지정된 텍스트가 포함됩니다.
+ `CustomPayload`—메시지에 클라이언트용으로 생성한 사용자 지정 형식이 포함됩니다. 애플리케이션의 요건을 이행하도록 페이로드를 정의할 수 있습니다.
+ `Composite`—메시지는 각 메시지 그룹에서 하나씩 있는 메시지 모음입니다. 메시지 그룹에 대한 자세한 내용은 [메시지 그룹](#message-groups) 섹션을 참조하십시오.
기본적으로 Amazon Lex 는 특정 프롬프트에 대해 정의된 메시지 중 하나를 반환합니다. 예를 들어 슬롯 값을 유도하기 위한 다섯 개 메시지를 정의하는 경우 Amazon Lex 는 메시지 중 하나를 임의로 선택하여 클라이언트에게 반환합니다.
Amazon Lex 가 런타임 요청 시 클라이언트에 특정 메시지 유형을 반환하도록 하려면 `x-amzn-lex:accept-content-types` 요청 파라미터를 설정합니다. 응답이 요청한 유형으로 제한됩니다. 지정한 유형의 메시지가 두 개 이상인 경우 Amazon Lex 는 임의로 하나를 반환합니다. `x-amz-lex:accept-content-types` 헤더에 대한 자세한 내용은 [응답 유형 설정](context-mgmt-request-attribs.md#special-response) 섹션을 참조하십시오.
## 메시지 그룹
*메시지 그룹*은 특정 프롬프트에 대한 적절한 응답 집합입니다. 봇이 대화에서 응답을 동적으로 빌드하도록 하려면 메시지 그룹을 사용합니다. Amazon Lex 는 클라이언트 애플리케이션에 응답을 반환할 때 각 그룹에서 메시지 하나를 임의로 선택합니다. 각 응답마다 최대 다섯 개 메시지 그룹을 만들 수 있습니다. 각 그룹에는 최대 다섯 개 메시지가 포함될 수 있습니다. 콘솔에서 메시지 그룹을 생성하는 예는 [응답](#msg-prompts-response) 섹션을 참조하십시오.
메시지 그룹을 만들려는 경우 콘솔을 사용하거나 [PutBot](API_PutBot.md), [PutIntent](API_PutIntent.md) 또는 [PutSlotType](API_PutSlotType.md) 작업을 사용하여 그룹 번호를 메시지에 할당할 수 있습니다. 메시지 그룹을 만들지 않는 경우 또는 메시지 그룹을 하나만 만드는 경우 Amazon Lex 는 `Message` 필드에 메시지를 보냅니다. 클라이언트 애플리케이션은 콘솔에서 두 개 이상의 메시지 그룹을 만든 경우 또는 [PutIntent](API_PutIntent.md) 작업을 사용하여 의도를 생성하거나 업데이트할 때 두 개 이상의 메시지 그룹을 생성하는 경우 응답 하나를 통해 여러 메시지를 가져옵니다.
Amazon Lex 가 그룹에서 메시지를 보낼 때에는, 응답의 `Message` 필드는 메시지를 포함하는 이스케이프된 JSON 객체를 포함합니다. 다음 예제는 여러 메시지를 포함하는 `Message` 필드의 내용을 보여 줍니다.
**참고**
이 예제는 쉽게 읽을 수 있도록 서식이 지정되었습니다. 응답에는 캐리지 리턴(CR)이 포함되지 않습니다.
```
{\"messages\":[
{\"type\":\"PlainText\",\"group\":0,\"value\":\"Plain text\"},
{\"type\":\"SSML\",\"group\":1,\"value\":\"SSML text\"},
{\"type\":\"CustomPayload\",\"group\":2,\"value\":\"Custom payload\"}
]}
```
메시지의 형식을 설정할 수 있습니다. 형식은 다음 중 하나일 수 있습니다.
+ PlainText - 메시지가 일반 UTF-8 텍스트로 표시됩니다.
+ SSML—음성 합성 마크업 언어 형식의 메시지입니다.
+ CustomPayload - 사용자가 지정한 사용자 정의 형식의 메시지입니다.
`PostContent` 및 `PostText` 작업이 `Message` 필드에 반환하는 메시지 형식을 제어하려면 `x-amz-lex:accept-content-types` 요청 속성을 설정합니다. 예를 들면 헤더를 다음으로 설정하는 경우 응답으로 일반 텍스트와 SSML 메시지만 받게 됩니다.
```
x-amz-lex:accept-content-types: PlainText,SSML
```
특정 메시지 형식을 요청했지만 메시지 그룹에 해당 형식의 메시지가 포함되지 않은 경우, `NoUsableMessageException` 예외가 발생합니다. 메시지 그룹을 사용하여 유형별로 메시지를 그룹화하는 경우 `x-amz-lex:accept-content-types` 헤더를 사용하지 마십시오.
`x-amz-lex:accept-content-types` 헤더에 대한 자세한 내용은 [응답 유형 설정](context-mgmt-request-attribs.md#special-response) 섹션을 참조하십시오.
## 응답 카드
**참고**
Amazon Connect 채팅에서는 응답 카드를 사용할 수 없습니다. 하지만 비슷한 기능에 대해서는 [채팅에 대화형 메시지 추가](https://docs.aws.amazon.com/connect/latest/adminguide/interactive-messages.html)를 참조하십시오.
*응답 카드*에는 프롬프트에 적절한 응답 세트가 들어 있습니다. 응답 카드를 사용하여 사용자의 상호 작용을 간소화하고 텍스트 상호 작용 시 오타를 줄여 봇의 정확도를 높입니다. Amazon Lex 가 클라이언트 애플리케이션에 보내는 각 프롬프트에 대한 응답 카드를 보낼 수 있습니다. Facebook Messenger, Slack, Twilio 및 자체 클라이언트 애플리케이션에서 응답 카드를 사용할 수 있습니다.
예를 들어, 택시 애플리케이션의 경우 "집"에 대한 응답 카드에서 옵션을 구성할 수 있는데 그 값을 사용자의 집 주소로 설정할 수 있습니다. 사용자가 이 옵션을 선택하면 Amazon Lex 는 전체 주소를 입력 텍스트로 받아들입니다. 다음 이미지를 참조하세요.
![\[응답 카드 예시.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/resp-console-5.png)
다음 프롬프트에 대한 응답 카드를 정의할 수 있습니다.
+ 결론 문장
+ 확인 프롬프트
+ 후속 프롬프트
+ 거부 문장
+ 슬롯 유형 표현
각 프롬프트에 대해 응답 카드는 하나만 정의할 수 있습니다.
의도를 생성할 때 응답 카드를 구성합니다. 콘솔 또는 [PutIntent](API_PutIntent.md) 작업을 사용하여 빌드 시에 정적 응답 카드를 정의할 수 있습니다. 또는 런타임 시 Lambda 함수 에서 동적 응답 카드를 정의할 수 있습니다. 정적 및 동적 응답 카드를 모두 정의하면, 동적 응답 카드가 우선 적용됩니다.
Amazon Lex 는 클라이언트가 이해할 수 있는 형식으로 응답 카드를 보냅니다. Facebook Messenger, Slack, Twilio에 맞춰 응답 카드를 변환합니다. 다른 클라이언트의 경우 Amazon Lex 는 [PostText](API_runtime_PostText.md) 응답에 JSON 구조를 보냅니다. 예를 들어, 클라이언트가 Facebook Messenger인 경우 Amazon Lex 는 응답 카드를 일반 템플릿으로 변환합니다. Facebook Messenger 일반 템플릿에 대한 자세한 내용은 Facebook 웹 사이트의 [일반 템플릿](https://developers.facebook.com/docs/messenger-platform/send-api-reference/generic-template)을 참조하십시오. JSON 구조에 대한 예는 [동적 응답 카드 생성](#msg-prompts-resp-card-dynamic) 섹션을 참조하십시오.
[PostText](API_runtime_PostText.md) 작업에서만 응답 카드를 사용할 수 있습니다. [PostContent](API_runtime_PostContent.md) 작업에서는 응답 카드를 사용할 수 없습니다.
### 정적 응답 카드 정의
의도를 생성할 때 [PutBot](API_PutBot.md) 작업 또는 Amazon Lex 콘솔을 사용하여 정적 응답 카드를 정의합니다. 정적 응답 카드는 의도와 동시에 정의됩니다. 응답이 고정된 경우 정적 응답 카드를 사용합니다. 맛에 대한 슬롯이 있는 의도를 사용해 봇을 생성한다고 가정하겠습니다. 다음 콘솔 스크린샷에 나와 있듯이 맛 슬롯을 정의할 때 프롬프트를 지정합니다.
![\[콘솔의 의도 편집기.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/resp-console-10a.png)
다음 예제에 나와 있듯이 프롬프트를 정의할 때 선택적으로 응답 카드를 연결하고 [PutBot](API_PutBot.md) 작업을 사용하거나 Amazon Lex 콘솔에서 세부 정보를 정의할 수도 있습니다.
![\[응답 카드 편집기가 표시된 콘솔.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/resp-console-20a.png)
이제 봇을 Facebook Messenger와 통합했다고 가정하겠습니다. 사용자는 버튼을 클릭하여 다음 그림과 같이 맛을 선택할 수 있습니다.
![\[Facebook Messenger의 응답 카드.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/resp-fb-exampleA.png)
응답 카드의 내용을 사용자 지정하기 위해 세션 속성을 참조할 수 있습니다. 런타임 시에 Amazon Lex 는 이러한 참조를 세션 속성의 해당 값으로 대체합니다. 자세한 내용은 [Setting Session Attributes](context-mgmt-session-attribs.md)을 참조하세요. 예제는 [응답 카드 사용](ex-resp-card.md) 섹션을 참조하세요.
### 동적 응답 카드 생성
런타임 시 응답 카드를 동적인 방식으로 생성하려면 의도에 초기화 및 검증 Lambda 함수 를 사용합니다. 동적 응답 카드는 런타임 시 Lambda 함수 에서 응답이 결정되는 경우 사용합니다. 사용자 입력에 대한 응답으로 Lambda 함수 는 응답 카드를 생성하고 응답의 `dialogAction` 섹션에서 해당 응답 카드를 반환합니다. 자세한 내용은 [응답 형식](lambda-input-response-format.md#using-lambda-response-format)을 참조하세요.
다음은 `responseCard` 요소를 보여 주는 Lambda 함수 의 부분 응답입니다. 이 응답은 이전 섹션에 표시된 것과 유사한 사용자 환경을 생성합니다.
```
responseCard: {
"version": 1,
"contentType": "application/vnd.amazonaws.card.generic",
"genericAttachments": [
{
"title": "What Flavor?",
"subtitle": "What flavor do you want?",
"imageUrl": "Link to image",
"attachmentLinkUrl": "Link to attachment",
"buttons": [
{
"text": "Lemon",
"value": "lemon"
},
{
"text": "Raspberry",
"value": "raspberry"
},
{
"text": "Plain",
"value": "plain"
}
]
}
]
}
```
예제는 [스케쥴 예약](ex1-sch-appt.md) 섹션을 참조하세요.
# 대화 컨텍스트 관리
*대화 컨텍스트*는 사용자, 애플리케이션 또는 Lambda 함수가 의도를 이행하기 위해 Amazon Lex 봇에 제공하는 정보입니다. 대화 컨텍스트에는 사용자가 제공하는 슬롯 데이터, 클라이언트 애플리케이션에서 설정한 요청 속성, 클라이언트 애플리케이션과 Lambda 함수가 생성하는 세션 속성이 포함됩니다.
**Topics**
+ [의도 컨텍스트 설정](context-mgmt-active-context.md)
+ [기본 슬롯 값 사용](context-mgmt-default.md)
+ [Setting Session Attributes](context-mgmt-session-attribs.md)
+ [Setting Request Attributes](context-mgmt-request-attribs.md)
+ [세션 시간 제한 설정](context-mgmt-session-timeout.md)
+ [의도 간 정보 공유](context-mgmt-cross-intent.md)
+ [복합 속성 설정](context-mgmt-complex-attributes.md)
# 의도 컨텍스트 설정
Amazon Lex가 *컨텍스트* 기반으로 의도를 트리거하도록 할 수 있습니다. *컨텍스트*는 봇을 정의할 때 인텐트와 연결할 수 있는 상태 변수입니다.
콘솔이나 [PutIntent](API_PutIntent.md) 작업을 사용하여 의도를 만들 때 의도의 컨텍스트를 구성합니다. 영어 (미국) (en-US) 로케일의 컨텍스트만 사용할 수 있으며,[PutBot](API_PutBot.md) 작업을 통해 봇을 만들`true`때 `enableModelImprovements` 파라미터를 로 설정한 경우에만 사용할 수 있습니다.
컨텍스트에는 출력 컨텍스트와 입력 컨텍스트라는 두 가지 유형의 관계가 있습니다. 관련 의도가 수행되면 *출력 컨텍스트*가 활성화됩니다. 출력 컨텍스트는 [PostText](API_runtime_PostText.md) 또는 [PostContent](API_runtime_PostContent.md) 작업의 응답으로 애플리케이션에 반환되며, 이 컨텍스트는 현재 세션에 맞게 설정됩니다. 컨텍스트가 활성화된 후에는 컨텍스트가 정의될 때 구성된 턴 수 또는 시간 제한 동안 활성 상태를 유지합니다.
*입력 컨텍스트*는 의도를 인식할 수 있는 조건을 지정합니다. 의도는 모든 입력 컨텍스트가 활성화된 경우에만 대화 중에 인식될 수 있습니다. 입력 컨텍스트가 없는 의도는 항상 인식될 수 있습니다.
Amazon Lex는 출력 컨텍스트로 의도를 수행하여 활성화되는 컨텍스트의 수명 주기를 자동으로 관리합니다. `PostContent` 또는 `PostText` 작업에 대한 직접 호출에서 활성 컨텍스트를 설정할 수도 있습니다.
또한 의도에 대한 Lambda 함수를 사용하여 대화의 컨텍스트를 설정할 수 있습니다. Amazon Lex의 출력 컨텍스트는 Lambda 함수 입력 이벤트로 전송됩니다. Lambda 함수는 응답으로 컨텍스트를 전송할 수 있습니다. 자세한 내용은 [Lambda 함수 입력 이벤트 및 응답 형식](lambda-input-response-format.md)을 참조하세요.
예를 들어, "book\$1car\$1fulfilled"라는 출력 컨텍스트를 반환하도록 구성된 렌터카를 예약하려는 의도가 있다고 가정해 보겠습니다. 의도가 이행되면 Amazon Lex는 출력 컨텍스트 변수 "book\$1car\$1fulfilled"를 설정합니다. "book\$1car\$1fulfilled"는 활성 컨텍스트이므로 "book\$1car\$1fulfilled" 컨텍스트가 입력 컨텍스트로 설정된 의도는 이제 인식 대상으로 간주됩니다. 단, 사용자 표현이 해당 의도를 이끌어내려는 시도로 인식되어야 합니다. 영수증을 이메일로 보내거나 예약을 수정하는 등 차량 예약 이후에만 의미가 있는 의도에 이 방법을 사용할 수 있습니다.
## 출력 컨텍스트
Amazon Lex는 의도가 이행되면 의도의 출력 컨텍스트를 활성화합니다. 출력 컨텍스트를 사용하여 현재 의도의 후속 조치로 적합한 의도를 제어할 수 있습니다.
각 컨텍스트에는 세션에서 유지 관리되는 파라미터 목록이 있습니다. 파라미터는 수행된 의도의 슬롯 값입니다. 이 매개변수를 사용하여 다른 의도의 슬롯 값을 미리 채울 수 있습니다. 자세한 내용은 [기본 슬롯 값 사용](context-mgmt-default.md)을 참조하세요.
콘솔이나 [PutIntent](API_PutIntent.md) 작업을 사용하여 의도를 생성할 때 출력 컨텍스트를 구성합니다. 둘 이상의 출력 컨텍스트로 의도를 구성할 수 있습니다. 의도가 이행되면 모든 출력 컨텍스트가 활성화되고 [PostText](API_runtime_PostText.md) 또는 [PostContent](API_runtime_PostContent.md) 응답에 반환됩니다.
다음은 콘솔을 사용하여 의도에 출력 컨텍스트를 할당하는 방법입니다.
![\[출력 태그에는 order_complete라는 라벨이 붙어 있으며, 유효 시간은 5턴 또는 90초입니다.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/context-output.png)
출력 컨텍스트를 정의할 때는 *TTL(Time to Live)* 즉, 컨텍스트가 Amazon Lex의 응답에 포함되는 시간 길이 또는 턴 수 또한 정의합니다. *턴*은 애플리케이션에서 Amazon Lex로 보내는 한 번의 요청입니다. 턴 수 또는 시간이 만료되면 컨텍스트는 더 이상 활성화되지 않습니다.
애플리케이션은 필요에 따라 출력 컨텍스트를 사용할 수 있습니다. 예를 들어, 애플리케이션은 출력 컨텍스트를 사용하여 다음을 수행할 수 있습니다.
+ 컨텍스트를 기반으로 응용 프로그램의 동작을 변경합니다. 예를 들어 여행 애플리케이션은 "book\$1car\$1fulfilled" 컨텍스트에서 "rental\$1hotel\$1fulfilled"와는 다른 작업을 수행할 수 있습니다.
+ 출력 컨텍스트를 Amazon Lex에 다음 표현의 입력 컨텍스트로 반환합니다. Amazon Lex가 표현을 의도를 이끌어내려는 시도로 인식하면 반환될 수 있는 의도를 특정 컨텍스트를 가진 의도로 제한합니다.
## 컨텍스트 입력
대화에서 의도가 인식되는 지점을 제한하도록 입력 컨텍스트를 설정합니다. 입력 컨텍스트가 없는 의도는 항상 인식될 수 있습니다.
콘솔이나 `PutIntent` 작업을 사용하여 의도가 응답하는 입력 컨텍스트를 설정합니다. 의도에는 입력 컨텍스트가 둘 이상 있을 수 있습니다. 다음은 콘솔을 사용하여 의도에 입력 컨텍스트를 할당하는 방법을 보여줍니다.
![\[order_complete라는 레이블이 붙은 입력 태그.\]](http://docs.aws.amazon.com/ko_kr/lex/latest/dg/images/context-input.png)
입력 컨텍스트가 두 개 이상인 의도의 경우 의도를 트리거하려면 모든 컨텍스트가 활성 상태여야 합니다. [PostText](API_runtime_PostText.md), [PostContent](API_runtime_PostContent.md) 또는 [PutSession](API_runtime_PutSession.md) 작업을 호출할 때 입력 컨텍스트를 설정할 수 있습니다.
현재 활성 컨텍스트에서 기본값을 가져오도록 의도에서 슬롯을 구성할 수 있습니다. Amazon Lex가 새 의도를 인식하지만 슬롯 값을 받지 못할 때 기본값이 사용됩니다. 슬롯을 정의할 때 컨텍스트 이름과 슬롯 이름을 `#context-name.parameter-name` 형식으로 지정합니다. 자세한 내용은 [기본 슬롯 값 사용](context-mgmt-default.md) 단원을 참조하십시오.
# 기본 슬롯 값 사용
기본값을 사용하는 경우 사용자 입력으로 슬롯이 제공되지 않을 때 새 의도에 맞게 채워질 슬롯 값의 소스를 지정합니다. 이 소스는 이전 대화상자, 요청 또는 세션 속성이거나 빌드 시 설정한 고정 값일 수 있습니다.
다음을 기본값의 소스로 사용할 수 있습니다.
+ 이전 대화 상자(컨텍스트) – \$1context -name.parameter-name
+ 세션 속성 – [attribute-name]
+ 요청 속성 –
+ 고정 값 – 이전 값과 일치하지 않는 모든 값
[PutIntent](API_PutIntent.md) 작업을 사용하여 의도에 슬롯을 추가할 때 기본값 목록을 추가할 수 있습니다. 기본값은 나열된 순서대로 사용됩니다. 예를 들어 다음과 같은 정의의 슬롯이 있는 의도를 가정합니다.
```
"slots": [
{
"name": "reservation-start-date",
"defaultValueSpec": {
"defaultValueList": [
{
"defaultValue": "#book-car-fulfilled.startDate"
},
{
"defaultValue": "[reservationStartDate]"
}
]
},
Other slot configuration settings
}
]
```
의도가 인식되면 이름이 "reservation-start-date"라는 슬롯의 값은 다음 중 하나로 설정됩니다.
1. "book-car-fulfilled" 컨텍스트가 활성화된 경우 "startDate" 매개 변수의 값이 기본값으로 사용됩니다.
1. "book-car-fulfilled" 컨텍스트가 비활성화된 경우 또는 "startDate" 매개 변수가 설정되지 않은 경우, "reservationStartDate"의 세션 속성의 값이 기본값으로 사용됩니다.
1. 처음 두 기본값을 모두 사용하지 않으면 슬롯에 기본값이 없으며 Amazon Lex는 평소와 같이 값을 가져옵니다.
슬롯에 기본값을 사용하면 필요한 경우에도 슬롯이 추출되지 않습니다.
# Setting Session Attributes
*세션 속성*에는 세션 중에 봇과 클라이언트 애플리케이션 간에 전달되는 애플리케이션별 정보가 포함됩니다. Amazon Lex는 봇에 대해 구성된 모든 Lambda 함수에 세션 속성을 전달합니다. Lambda 함수가 세션 속성을 추가 또는 업데이트하는 경우 Amazon Lex는 새로운 정보를 클라이언트 애플리케이션에 다시 전달합니다. 예제:
+ [연습 1: 청사진을 사용하여 Amazon Lex 봇 생성(콘솔)](gs-bp.md)에서 예제 봇은 `price` 세션 속성을 사용하여 꽃 가격을 유지합니다. Lambda 함수는 주문한 꽃 유형에 따라 이 속성을 설정합니다. 자세한 내용은 [5단계(선택 사항): 정보 흐름의 세부 정보 검토(콘솔)](gs-bp-details-after-lambda.md) 단원을 참조하십시오.
+ [여행 예약](ex-book-trip.md)에서 예제 봇은 대화 중에 `currentReservation` 세션 속성을 사용하여 슬롯 유형 데이터의 사본을 유지 관리하여 호텔을 예약하거나 렌터카를 예약합니다. 자세한 내용은 [정보 흐름의 세부 정보](book-trip-detail-flow.md) 단원을 참조하십시오.
Lambda 함수의 세션 속성을 사용하여 봇을 초기화하고 프롬프트 및 응답 카드를 사용자 지정합니다. 예제:
+ 초기화 — 피자 주문 봇에서 클라이언트 애플리케이션은 [PostContent](API_runtime_PostContent.md) 또는 [PostText](API_runtime_PostText.md) 작업에 대한 첫 번째 호출 시 사용자의 위치를 세션 속성으로 전달합니다. 예를 들어 `"Location": "111 Maple Street"`입니다. Lambda 함수는 이 정보를 사용하여 주문할 수 있는 가장 가까운 피자 가게를 찾습니다.
+ 프롬프트 개인화 - 세션 속성을 참조하도록 프롬프트와 응답 카드를 구성합니다. 예를 들어, "[FirstName]님, 어떤 토핑을 드시겠어요?" 사용자의 이름을 세션 속성(`{"FirstName": "Jo"}`)으로 전달하면 Amazon Lex가 자리 표시자를 이름으로 대체합니다. 그런 다음 사용자에게 "Jo님, 어떤 토핑을 원하세요?"라는 맞춤형 프롬프트를 보냅니다.
세션 속성은 세션 기간 동안 암호화된 저장소에서 지속됩니다. Amazon Lex는 세션이 종료될 때까지 이를 암호화된 데이터 스토어에 저장합니다. 클라이언트는 `sessionAttributes` 필드가 값으로 설정된 상태에서 [PostContent](API_runtime_PostContent.md) 또는 [PostText](API_runtime_PostText.md) 작업을 호출하여 요청에 세션 속성을 생성할 수 있습니다. Lambda 함수는 응답에 세션 속성을 생성할 수 있습니다. 클라이언트 또는 Lambda 함수가 세션 속성을 생성한 후, 저장된 속성 값은 클라이언트 애플리케이션이 Amazon Lex에 대한 요청에 `sessionAttribute` 필드를 포함하지 않을 때마다 사용됩니다.
예를 들어, 다음과 같은 두 개의 세션 속성 `{"x": "1", "y": "2"}`이 있다고 가정하겠습니다. 클라이언트가 `sessionAttributes` 필드를 지정하지 않고 `PostContent` or `PostText` 작업을 직접적으로 호출하면 Amazon Lex는 저장된 세션 속성 (`{"x": 1, "y": 2}`)와 함께 Lambda 함수를 직접적으로 호출합니다. Lambda 함수가 세션 속성을 반환하지 않는 경우 Amazon Lex는 저장된 세션 속성을 클라이언트 애플리케이션에 반환합니다.
클라이언트 애플리케이션 또는 Lambda 함수가 세션 속성을 전달한 경우, Amazon Lex는 저장된 세션 속성 업데이트합니다. ` {"x": 2}`과 같은 기존 값을 전달하면 저장된 값이 업데이트됩니다. 새 세션 속성 세트(예를 들어, `{"z": 3}`) 를 전달하면 기존 값은 제거되고 새 값만 유지됩니다. 빈 맵 `{}`가 전달되면 저장된 값이 지워집니다.
세션 속성을 Amazon Lex로 전송하려면 속성의 string-to-string 맵을 생성합니다. 다음은 세션 속성을 매핑하는 방법을 보여줍니다.
```
{
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostText` 작업의 경우 다음과 같이 `sessionAttributes` 필드를 사용하여 요청 본문에 맵을 삽입합니다.
```
"sessionAttributes": {
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostContent` 작업의 경우, 맵을 base64로 인코딩한 다음 `x-amz-lex-session-attributes` 헤더로 전송합니다.
세션 속성으로 이진수 또는 구조화된 데이터를 보내는 경우 먼저 데이터를 단순 문자열로 변환해야 합니다. 자세한 내용은 [복합 속성 설정](context-mgmt-complex-attributes.md) 단원을 참조하십시오.
# Setting Request Attributes
*요청 속성*은 요청 관련 정보를 포함하고 있고 현재 요청에만 적용됩니다. 클라이언트 애플리케이션은 이 정보를 Amazon Lex로 전송합니다. 전체 세션에서 유지할 필요가 없는 정보를 전달하려면 요청 속성을 사용합니다. 요청 속성을 직접 생성할 수도 있고 사전 정의된 속성을 사용할 수도 있습니다. 요청 속성을 보내려면 [PostText](API_runtime_PostText.md) 요청에 포함된 [PostContent](API_runtime_PostContent.md) 또는 `requestAttributes` 필드 안의 `x-amz-lex-request-attributes` 헤더를 사용합니다. 요청 속성은 세션 속성처럼 요청 전체에 지속되지 않기 때문에 요청 속성은 `PostContent` 또는 `PostText` 응답에서 반환되지 않습니다.
**참고**
요청 간에 유지되는 정보를 보내려면 세션 속성을 사용하십시오.
네임스페이스 `x-amz-lex:`는 사전 정의된 요청 속성용으로 보류되어 있습니다. `x-amz-lex:` 접두사를 사용하여 요청 속성을 생성하지 마세요.
## 사전 정의된 요청 속성 설정
Amazon Lex는 봇으로 전송된 정보를 처리하는 방식을 관리하기 위해 사전 정의된 요청 속성을 제공합니다. 속성은 전체 세션 동안 지속되지 않으므로 각 요청에서 사전 정의된 속성을 전송해야 합니다. 사전 정의된 모든 속성은 `x-amz-lex:` 네임스페이스에 있습니다.
Amazon Lex는 다음과 같은 사전 정의된 속성 외에도 메시징 플랫폼을 위한 사전 정의된 속성을 제공합니다. 이러한 속성의 목록은 [메시징 플랫폼에 Amazon Lex 봇 배포하기](example1.md)을 참조하십시오.
### 응답 유형 설정
기능이 다른 두 개의 클라이언트 애플리케이션을 사용하는 경우 응답의 메시지 형식을 제한해야 할 수 있습니다. 예를 들어 웹 클라이언트에 보내는 메시지는 일반 텍스트로 제한하고 모바일 클라이언트는 일반 텍스트와 음성 합성 마크업 언(SSML)를 모두 사용할 수 있도록 할 수 있습니다. [PostContent](API_runtime_PostContent.md) 및 [PostText](API_runtime_PostText.md) 작업이 필드에 반환하는 메시지 형식을 제어하려면 `x-amz-lex:accept-content-types"` 요청 속성을 사용합니다.
다음 메시지 유형의 모든 조합으로 속성을 설정할 수 있습니다.
+ `PlainText`—메시지에 일반 UTF-8 텍스트가 포함됩니다.
+ `SSML`—메시지에 음성 출력용으로 서식이 지정된 텍스트가 포함됩니다.
+ `CustomPayload`—메시지에 클라이언트용으로 생성한 사용자 지정 형식이 포함됩니다. 애플리케이션의 요건을 이행하도록 페이로드를 정의할 수 있습니다.
Amazon Lex는 응답 `Message` 필드에 지정된 유형의 메시지만 반환합니다. 값을 쉼표로 구분하여 둘 이상의 값을 설정할 수 있습니다. 메시지 그룹을 사용하는 경우 모든 메시지 그룹에는 지정된 유형의 메시지가 하나 이상 포함되어야 합니다. 그러지 않을 경우 `NoUsableMessageException` 오류가 발생합니다. 자세한 내용은 [메시지 그룹](howitworks-manage-prompts.md#message-groups) 단원을 참조하십시오.
**참고**
`x-amz-lex:accept-content-types` 요청 속성은 HTML 본문의 내용에 영향을 주지 않습니다. `PostText` 작업 응답의 내용은 항상 일반 UTF-8 텍스트입니다. `PostContent` 작업 응답 본문에는 요청 안에 있는 `Accept` 헤더에서 설정된 형식의 데이터가 포함됩니다.
### 선호 시간대 설정
날짜를 확인하는 데 사용되는 시간대를 사용자의 시간대를 기준으로 설정하려면 `x-amz-lex:time-zone` 요청 속성을 사용하십시오. `x-amz-lex:time-zone` 속성에 시간대를 지정하지 않는 경우 기본값은 봇에 사용하는 지역에 따라 달라집니다.
| 지역 | 기본 설정 시간대 |
| --- | --- |
| 미국 동부(버지니아 북부) | America/New\$1York |
| 미국 서부(오레곤) | America/Los\$1Angeles |
| 아시아 태평양(싱가포르) | Asia/Singapore |
| 아시아 태평양(시드니) | Australia/Sydney |
| 아시아 태평양(도쿄) | Asia/Tokyo |
| 유럽(프랑크푸르트) | Europe/Berlin |
| 유럽(아일랜드) | Europe/Dublin |
| 유럽(런던) | Europe/London |
예를 들어, 사용자가 "패키지를 어느 날짜에 배송하시겠습니까?" 라는 프롬프트에 `tomorrow` 응답하는 경우. 패키지가 배송되는 실제 *날짜*는 사용자의 시간대에 따라 다릅니다. 예를 들어 뉴욕의 경우 9월 16일 01:00이고 로스앤젤레스의 경우 9월 15일 22:00입니다. 서비스가 미국 동부 (버지니아 북부) 지역에서 운영되고 있고 로스앤젤레스에 있는 사람이 기본 시간대를 사용하여 "내일"에 배송되도록 패키지를 주문하는 경우 패키지는 16일이 아닌 17일에 배송됩니다. 하지만 `x-amz-lex:time-zone` 요청 속성을 `America/Los_Angeles`로 설정하면 패키지는 16일에 배달됩니다.
속성을 원하는 인터넷 지정 번호 기관(IANA) 시간대 이름으로 설정할 수 있습니다. 시간대 이름 목록은 Wikipedia의 [tz 데이터베이스 시간대 목록](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)을 참조하십시오.
## 사용자-정의 요청 속성 설정
*사용자-정의 요청 속성*은 각 요청에서 봇에 보내는 데이터입니다. `PostContent` 요청의 `amz-lex-request-attributes` 헤더나 `PostText` 요청의 `requestAttributes` 필드에 정보를 전송합니다.
세션 속성을 Amazon Lex로 전송하려면 속성의 string-to-string 맵을 생성합니다. 다음은 세션 속성을 매핑하는 방법을 보여줍니다.
```
{
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostText` 작업의 경우 다음과 같이 `requestAttributes` 필드를 사용하여 요청 본문에 맵을 삽입합니다.
```
"requestAttributes": {
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostContent` 작업의 경우, 맵을 base64로 인코딩한 다음 `x-amz-lex-request-attributes` 헤더로 전송합니다.
세션 속성으로 이진수 또는 구조화된 데이터를 보내는 경우 먼저 데이터를 단순 문자열로 변환해야 합니다. 자세한 내용은 [복합 속성 설정](context-mgmt-complex-attributes.md) 단원을 참조하세요.
# 세션 시간 제한 설정
Amazon Lex는 대화 세션이 종료될 때까지 슬롯 데이터 및 세션 속성과 같은 컨텍스트 정보를 유지합니다. 봇의 세션 지속 시간을 제어하려면 세션 제한 시간을 설정하세요. 기본적으로 세션 기간은 5분이지만 0\$11,440분(24시간) 사이의 기간을 지정할 수 있습니다.
예를 들어, `OrderShoes` 및 `GetOrderStatus` 와 같은 의도를 지원하는 `ShoeOrdering` 봇을 생성한다고 가정해 보겠습니다. Amazon Lex는 사용자의 의도가 신발을 주문하는 것임을 감지하면 슬롯 데이터를 요청합니다. 예를 들어 신발 사이즈, 색상, 브랜드 등을 묻습니다. 사용자가 일부 슬롯 데이터를 제공했지만 신발 구매를 완료하지 않은 경우 Amazon Lex는 전체 세션의 슬롯 데이터와 세션 속성을 모두 기억합니다. 사용자가 세션이 만료되기 전에 세션으로 돌아오면 나머지 슬롯 데이터를 제공하고 구매를 완료할 수 있습니다.
Amazon Lex 콘솔에서는 봇을 생성할 때 세션 제한 시간을 설정합니다. AWS Command Line Interface(AWS CLI) 또는 API에서는 [idleSessionTTLInSeconds](https://docs.aws.amazon.com/lex/latest/dg/API_PutBot.html#lex-PutBot-request-idleSessionTTLInSeconds) 필드를 설정함으로써 [PutBot](API_PutBot.md) 작업을 갖는 봇을 생성 또는 업데이트할 때에 제한 시간을 설정합니다.
# 의도 간 정보 공유
Amazon Lex는 의도 간 정보 공유를 지원합니다. 의도 간에 공유하려면 세션 속성을 사용하십시오.
예를 들어 `ShoeOrdering` 봇 사용자는 신발을 주문하는 것으로 시작합니다. 봇은 사용자와 대화하면서 신발 사이즈, 색상, 브랜드와 같은 슬롯 데이터를 수집합니다. 사용자가 주문을 하면 주문을 이행하는 Lambda 함수가 주문 번호가 포함된 `orderNumber` 세션 속성을 설정합니다. 사용자는 `GetOrderStatus` 의도를 사용하여 주문 상태를 확인합니다. 봇은 사용자에게 주문 번호 및 주문 날짜와 같은 슬롯 데이터를 요청할 수 있습니다. 봇이 필수 정보를 수집하면 주문 상태를 반환합니다.
같은 세션에서 사용자가 의도를 바꿀 수 있다고 생각되면 최신 주문 상태를 반환하도록 봇을 설계할 수 있습니다. 사용자에게 주문 정보를 다시 요청하는 대신 `orderNumber` 세션 속성을 사용하여 의도 간에 정보를 공유하고 `GetOrderStatus` 의도를 이행할 수 있습니다. 봇은 사용자가 마지막으로 주문한 상태를 반환하여 이 작업을 수행합니다.
의도 간의 정보 공유의 예제는 [여행 예약](ex-book-trip.md)을 참조하십시오.
# 복합 속성 설정
세션 및 요청 속성은 속성 및 값의 문자열 간 매핑입니다. 대부분의 경우 문자열 맵을 사용하여 클라이언트 애플리케이션과 봇 간에 속성 값을 전송할 수 있습니다. 하지만 문자열 맵으로 쉽게 변환할 수 없는 이진 데이터나 복잡한 구조를 전송해야 하는 경우도 있습니다. 예를 들어 다음 JSON 객체는 미국에서 인구가 가장 많은 세 도시의 배열을 나타냅니다.
```
{
"cities": [
{
"city": {
"name": "New York",
"state": "New York",
"pop": "8537673"
}
},
{
"city": {
"name": "Los Angeles",
"state": "California",
"pop": "3976322"
}
},
{
"city": {
"name": "Chicago",
"state": "Illinois",
"pop": "2704958"
}
}
]
}
```
이 데이터 배열은 문자열 대 문자열 맵으로 잘 변환되지 않습니다. 이 경우 객체를 간단한 문자열로 변환하여 [PostContent](API_runtime_PostContent.md) 및 [PostText](API_runtime_PostText.md) 연산과 함께 봇에 보낼 수 있습니다.
예를 들어 JavaScript를 사용하는 경우 객체를 JSON으로 변환하는 `JSON.stringify` 작업과 JSON 텍스트를 JavaScript 객체로 변환하는 `JSON.parse` 작업을 사용할 수 있습니다.
```
// To convert an object to a string.
var jsonString = JSON.stringify(object, null, 2);
// To convert a string to an object.
var obj = JSON.parse(JSON string);
```
`PostContent` 작업과 함께 세션 속성을 보내려면 다음 JavaScript 코드와 같이, 속성을 요청 헤더에 추가하기 전에 속성을 base64로 인코딩해야 합니다.
```
var encodedAttributes = new Buffer(attributeString).toString("base64");
```
먼저 데이터를 base64로 인코딩된 문자열로 변환한 다음 이 문자열을 세션 속성의 값으로 전송하여 `PostContent` 및 `PostText` 연산에 이진 데이터를 보낼 수 있습니다.
```
"sessionAttributes" : {
"binaryData": "base64 encoded data"
}
```
# 신뢰도 점수 사용
사용자가 말을 하면 Amazon Lex는 자연어 이해(NLU) 를 사용하여 사용자의 요청을 이해하고 적절한 의도를 제시합니다. 기본적으로 Amazon Lex는 봇이 정의한 가장 가능성이 높은 의도를 반환합니다.
경우에 따라 Amazon Lex에서 가장 가능성이 높은 의도를 파악하기 어려울 수 있습니다. 예를 들어, 사용자가 모호한 말을 하거나 비슷한 의도가 두 개 있을 수 있습니다. 적절한 의도를 판단하는 데 도움이 되도록 도메인 지식을 대체 의도 목록의 *신뢰도 점수*와 결합할 수 있습니다. 신뢰도 점수는 Amazon Lex가 제공하는 등급으로, 의도가 올바른 의도라고 확신하는 정도를 나타냅니다.
두 대체 의도 간의 차이를 확인하기 위해 두 대체 의도의 신뢰도 점수를 비교할 수 있습니다. 예를 들어 한 의도의 신뢰도 점수가 0.95이고 다른 의도의 신뢰도 점수가 0.65이면 첫 번째 의도가 올바른 것일 수 있습니다. 하지만 한 의도의 점수가 0.75점이고 다른 의도의 점수가 0.72인 경우 애플리케이션에서 도메인 지식을 사용하여 구별할 수 있는 모호함이 두 가지 의도 사이에 있습니다.
신뢰도 점수를 사용하여 의도의 표현 변경이 봇의 동작에 영향을 미치는지 확인하는 테스트 애플리케이션을 만들 수도 있습니다. 예를 들어 표현 세트를 사용하여 봇의 의도에 대한 신뢰도 점수를 얻은 다음 새 표현으로 의도를 업데이트할 수 있습니다. 그런 다음 신뢰도 점수를 확인하여 개선이 있었는지 확인할 수 있습니다.
Amazon Lex가 반환하는 신뢰도 점수는 비교 값입니다. 절대 점수로서 의존해서는 안됩니다. 점수는 Amazon Lex의 개선 사항에 따라 변경될 수 있습니다.
신뢰도 점수를 사용하면 Amazon Lex는 각 응답에서 가장 가능성이 높은 의도와 최대 4개의 대체 의도를 관련 점수와 함께 반환합니다. 모든 신뢰도 점수가 임계값 미만인 경우 Amazon Lex는 `AMAZON.FallbackIntent`, `AMAZON.KendraSearchIntent`, 또는 둘 다를 포함합니다(미리 구성한 경우). 기본 임계값을 사용하거나, 직접 자신의 임계값을 설정할 수도 있습니다.
다음 JSON 코드는 [PostText](API_runtime_PostText.md) 작업에 대한 응답의 `alternativeIntents` 필드를 보여줍니다.
```
"alternativeIntents": [
{
"intentName": "string",
"nluIntentConfidence": {
"score": number
},
"slots": {
"string" : "string"
}
}
],
```
봇을 생성 또는 업데이트할 때 임계값을 설정합니다. API 또는 Amazon Lex 콘솔을 사용할 수 있습니다. 아래 나열된 지역의 경우 정확성 향상 및 신뢰도 점수를 활성화하려면 옵트인해야 합니다. 콘솔의 **고급 옵션** 섹션에서 신뢰도 점수를 선택합니다. API를 사용하여 [PutBot](API_PutBot.md) 작업을 호출할 때 `enableModelImprovements` 파라미터를 설정하십시오.
+ 미국 동부(버지니아 북부)(us-east-1)
+ 미국 서부(오레곤)(us-west-2)
+ 아시아 태평양(시드니)(ap-southeast-2)
+ 유럽(아일랜드)(eu-west-1)
다른 모든 지역에서는 정확도 개선 및 신뢰도 점수 지원이 기본적으로 제공됩니다.
신뢰도 임계값을 변경하려면 콘솔에서 설정하거나 [PutBot](API_PutBot.md) 작업을 사용하여 신뢰도 임계값을 설정하십시오. 임계값은 1.00에서 0.00 사이의 숫자여야 합니다.
콘솔을 사용하려면 봇을 만들거나 업데이트할 때 신뢰 임계값을 설정하세요.
**봇 생성 시 신뢰 임계값 설정하기(콘솔)**
+ **봇 만들기**에서 **신뢰도 점수 임계값** 필드에 값을 입력합니다.
**신뢰도 임계값을 업데이트하려면(콘솔)**
1. 봇 목록에서 업데이트할 봇을 선택합니다.
1. **설정** 탭을 선택합니다.
1. 왼쪽 탐색 창에서 **일반**을 선택합니다.
1. **신뢰도 점수 임계값** 필드의 값을 업데이트하십시오.
**신뢰도 임계값을 설정 또는 업데이트하려면(SDK)**
+ [PutBot](API_PutBot.md) 작업 `nluIntentConfidenceThreshold` 파라미터를 설정합니다. 다음 JSON 코드는 설정 중인 파라미터를 보여줍니다.
```
"nluIntentConfidenceThreshold": 0.75,
```
## 세션 관리
Amazon Lex가 사용자와의 대화에서 사용하는 의도를 변경하려면 대화 상자 코드 후크 Lambda 함수의 응답을 사용하거나 사용자 지정 애플리케이션에서 세션 관리 API를 사용할 수 있습니다.
### Lambda 함수 사용
Lambda 함수를 사용하는 경우 Amazon Lex는 함수에 대한 입력이 포함된 JSON 구조를 사용하여 함수를 호출합니다. JSON 구조는 Amazon Lex가 사용자 표현에 대한 가장 가능성이 높은 의도로 식별한 의도가 포함된, `currentIntent`로 불리는 필드를 포함합니다. JSON 구조에는 사용자의 의도를 충족시킬 수 있는 최대 4개의 추가 의도를 포함하는 `alternativeIntents` 필드도 포함됩니다. 각 의도에는 Amazon Lex가 의도에 할당한 신뢰도 점수가 포함된, `nluIntentConfidenceScore`라고 불리는 필드가 포함되어 있습니다.
대체 의도를 사용하려면 Lambda 함수의 `ConfirmIntent` 또는 `ElicitSlot` 대화 작업에서 해당 의도를 지정합니다.
자세한 내용은 [Lambda 함수 사용](using-lambda.md)을 참조하세요.
### 세션 관리 API 사용
현재 의도와 다른 의도를 사용하려면 [PutSession](API_runtime_PutSession.md) 작업을 사용하세요. 예를 들어 Amazon Lex가 선택한 의도보다 첫 번째 대안이 더 낫다고 판단되면 `PutSession` 작업을 사용하여 의도를 변경하여 사용자가 상호 작용하는 다음 의도가 선택한 의도가 되도록 할 수 있습니다.
자세한 내용은 [Amazon Lex API로 세션 관리](how-session-api.md) 단원을 참조하십시오.
# 대화 로그
*대화 로그*를 활성화하여 봇 상호 작용을 저장합니다. 이러한 로그를 사용하여 봇의 성능을 검토하고 대화 관련 문제를 해결할 수 있습니다. [PostText](API_runtime_PostText.md) 작업에 대한 텍스트를 로그할 수 있습니다. [PostContent](API_runtime_PostContent.md) 작업에 대한 텍스트와 오디오를 모두 로그할 수 있습니다. 대화 로그를 활성화하면 사용자가 봇과 나누는 대화를 자세히 볼 수 있습니다.
예를 들어 봇이 있는 세션에는 세션 ID가 있습니다. 이 ID를 사용하여 사용자 표현 및 해당 봇 응답을 포함한 대화의 기록을 가져올 수 있습니다. 또한 표현에 대한 의도 이름 및 슬롯 값과 같은 메타 데이터를 얻을 수 있습니다.
**참고**
어린이 온라인 사생활 보호법(COPPA)이 적용되는 봇과의 대화 로그는 사용할 수 없습니다.
대화 로그는 별칭에 대해 구성됩니다. 각 별칭은 텍스트 및 오디오 로그에 대해 서로 다른 설정을 가질 수 있습니다. 각 별칭에 대해 텍스트 로그, 오디오 로그 또는 둘 다를 사용하도록 설정할 수 있습니다. 텍스트 로그는 텍스트 입력, 오디오 입력 기록 및 관련 메타 데이터를 CloudWatch Logs에 저장합니다. 오디오 로그는 오디오 입력을 Amazon S3에 저장합니다. AWS KMS 고객 관리형 CMKs.
로깅을 구성하려면 콘솔 또는 [PutBotAlias](API_PutBotAlias.md)작업을 사용합니다. 봇의 `$LATEST` 별칭이나 Amazon Lex 콘솔에서 사용할 수 있는 테스트 봇에 대한 대화를 기록할 수 없습니다. 별칭에 대한 대화 로그를 활성화하면 해당 별칭에 대한 [PostContent](API_runtime_PostContent.md) 또는 [PostText](API_runtime_PostText.md) 작업이 구성된 CloudWatch Logs 로그 그룹 또는 S3 버킷에 텍스트 또는 오디오 표현을 기록합니다.
**Topics**
+ [대화 로그에 대한 IAM 정책](conversation-logs-policies.md)
+ [대화 로그 구성](conversation-logs-configure.md)
+ [대화 로그 암호화](conversation-logs-encrypting.md)
+ [Amazon CloudWatch 로그에서 텍스트 로그 보기](conversation-logs-cw.md)
+ [Amazon S3에서 오디오 로그에 액세스](conversation-logs-s3.md)
+ [CloudWatch 지표를 통해 대화 로그 상태 모니터링](conversation-logs-monitoring.md)
# 대화 로그에 대한 IAM 정책
선택하는 로깅 유형에 따라, Amazon Lex는 Amazon CloudWatch Logs 및 S3(Amazon Simple Storage Service) 버킷을 사용해 로그를 보관할 권한이 필요합니다. Amazon Lex가 이러한 리소스에 액세스할 수 있도록 AWS Identity and Access Management 역할과 권한을 생성해야 합니다.
## 대화 로그에 대한 IAM 역할 및 정책 생성
대화 로그를 활성화하려면, CloudWatch Logs 및 Amazon S3 에 대한 쓰기 권한을 부여해야 합니다. S3 객체에 대해 객체 암호화를 활성화하는 경우 객체를 암호화하는 데 사용되는 AWS KMS 키에 액세스 권한을 부여해야 합니다.
IAM AWS Management Console, IAM API 또는를 사용하여 역할 및 정책을 AWS Command Line Interface 생성할 수 있습니다. 이 지침은 AWS CLI 를 사용하여 역할 및 정책을 생성합니다. 콘솔을 사용한 정책 생성에 대한 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [JSON 탭에 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)을 참조하세요.
**참고**
다음 코드는 Linux 및 MacOS 용으로 형식이 지정됩니다. Windows의 경우 Linux 줄 연속 문자(\$1)를 캐럿(^)으로 바꿉니다.
**대화 로그에 대한 IAM 역할 을 만들려면**
1. **LexConversationLogsAssumeRolePolicyDocument.json**이라는 현재 디렉터리에 문서를 만들고 다음 코드를 추가한 다음 저장합니다. 이 정책 문서는 Amazon Lex를 역할에 대한 신뢰할 수 있는 엔터티로써 추가합니다. 이를 통해 Lex는 대화 로그를 위해 구성된 리소스로 로그를 전달하기 위한 역할을 맡을 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lex.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 에서 다음 명령을 AWS CLI실행하여 대화 로그에 대한 IAM 역할을 생성합니다.
```
aws iam create-role \
--role-name role-name \
--assume-role-policy-document file://LexConversationLogsAssumeRolePolicyDocument.json
```
그런 다음 Amazon Lex가 CloudWatch Logs 에 쓸 수 있도록 하는 정책을 만들어 역할에 연결합니다.
**대화 텍스트를 CloudWatch Logs 에 로깅하기 위한 IAM 정책 을 만들려면**
1. **LexConversationLogsCloudWatchLogsPolicy.json**이라는 현재 디렉터리에 문서를 만들고 다음 IAM 정책 을 추가한 다음 저장합니다.
1. 에서 CloudWatch Logs 로그 그룹에 쓰기 권한을 부여하는 IAM 정책을 AWS CLI생성합니다.
```
aws iam create-policy \
--policy-name cloudwatch-policy-name \
--policy-document file://LexConversationLogsCloudWatchLogsPolicy.json
```
1. 대화 로그에 대해 생성한 IAM 역할 에 정책을 연결합니다.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/cloudwatch-policy-name \
--role-name role-name
```
S3 버킷에 오디오를 로깅하는 경우 Amazon Lex가 버킷에 쓸 수 있도록 허용하는 정책을 생성합니다.
**S3 버킷에 오디오를 로깅하기 위한 IAM 정책을 만들려면**
1. **LexConversationLogsS3Policy.json**이라는 현재 디렉터리에 문서를 만들고 다음의 정책을 추가한 후 저장합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
```
------
1. 에서 S3 버킷에 쓰기 권한을 부여하는 IAM 정책을 AWS CLI생성합니다.
```
aws iam create-policy \
--policy-name s3-policy-name \
--policy-document file://LexConversationLogsS3Policy.json
```
1. 대화 로그에 대해 생성한 역할에 정책을 연결합니다.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/s3-policy-name \
--role-name role-name
```
## IAM 역할 전달 권한 부여
콘솔 AWS Command Line Interface, 또는 AWS SDK를 사용하여 대화 로그에 사용할 IAM 역할을 지정하는 경우 대화 로그를 지정하는 사용자는 Amazon Lex에 역할을 전달할 권한이 있어야 합니다. 사용자가 역할을 Amazon Lex에 전달하도록 하려면 사용자, 역할 또는 그룹에 `PassRole` 권한을 부여해야 합니다.
다음 정책은 사용자, 역할 또는 그룹에게 부여할 권한을 정의합니다. `iam:AssociatedResourceArn` 및 `iam:PassedToService` 조건 키를 사용해 권한 범위를 제한할 수 있습니다. 자세한 내용은 사용 *AWS Identity and Access Management 설명서*의 [AWS 사용자에게 서비스에 역할을 전달할 수 있는 권한 부여 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) 및 [ IAM 및 AWS STS 조건 컨텍스트 키를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/role-name",
"Condition": {
"StringEquals": {
"iam:PassedToService": "lex.amazonaws.com"
},
"StringLike": {
"iam:AssociatedResourceARN": "arn:aws:lex:region:123456789012:bot:bot-name:bot-alias"
}
}
}
]
}
```
------
# 대화 로그 구성
콘솔 또는 `PutBotAlias` 작업의 `conversationLogs` 필드를 사용하여 대화 로그를 활성화 및 비활성화합니다. 오디오 로그, 텍스트 로그 또는 둘 다 설정하거나 해제할 수 있습니다. 새 봇 세션에서 로깅이 시작됩니다. 로그 설정에 대한 변경 사항은 활성 세션에 반영되지 않습니다.
텍스트 로그를 저장하려면 AWS 계정에 Amazon CloudWatch Logs 로그 그룹을 사용합니다. 유효한 로그 그룹 어느 것이든 사용할 수 있습니다. 로그 그룹은 Amazon Lex 봇과 동일한 리전에 있어야 합니다. CloudWatch Logs 로그 그룹 생성에 대한 자세한 내용을 알아보려면 *Amazon CloudWatch Logs 사용 설명서*의 [로그 그룹 및 로그 스트림 작업](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)을 참조하세요.
오디오 로그를 저장하려면 AWS 계정에 Amazon S3 버킷을 사용합니다. 유효한 S3 버킷 어느 것이든 사용할 수 있습니다. 버킷은 Amazon Lex 봇과 동일한 리전에 있어야 합니다. Amazon S3 버킷에 대한 자세한 내용은 *Amazon Simple Storage Service 시작 가이드*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)을 참조하세요.
Amazon Lex가 구성된 로그 그룹 또는 버킷에 쓸 수 있도록 하는 정책을 IAM 역할 에 제공해야 합니다. 자세한 내용은 [대화 로그에 대한 IAM 역할 및 정책 생성](conversation-logs-policies.md#conversation-logs-role-and-policy) 단원을 참조하십시오.
를 사용하여 서비스 연결 역할을 생성하는 경우 다음과 같이 `custom-suffix` 옵션을 사용하여 역할에 사용자 지정 접미사를 추가 AWS Command Line Interface해야 합니다.
```
aws iam create-service-linked-role \
--aws-service-name lex.amazon.aws.com \
--custom-suffix suffix
```
대화 로그를 활성화하는 데 사용하는 IAM 역할에 `iam:PassRole` 권한이 있어야 합니다. 다음 정책이 역할에 연결되어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/role"
}
]
}
```
------
## 대화 로그 활성화
**콘솔을 사용하여 로그를 활성화하려면**
1. [https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)에서 Amazon Lex 콘솔을 엽니다.
1. 목록에서 봇을 선택합니다.
1. **설정** 탭을 선택한 다음 왼쪽 메뉴에서 **대화 로그**를 선택합니다.
1. 별칭 목록에서 대화 로그를 구성할 별칭의 설정 아이콘을 선택합니다.
1. 텍스트, 오디오 또는 둘 다 기록할지 선택합니다.
1. 텍스트 로깅의 경우 Amazon CloudWatch Logs 로그 그룹 이름을 입력합니다.
1. 오디오 로깅의 경우 S3 버킷 정보를 입력합니다.
1. 선택 사항. 오디오 로그를 암호화하려면 암호화에 사용할 AWS KMS 키를 선택합니다.
1. 필요한 권한이 있는 IAM 역할을 선택합니다.
1. **저장**을 선택하여 대화 로깅을 시작합니다.
**API를 사용한 텍스트 로그를 활성화하려면**
1. `conversationLogs` 필드의 `logSettings` 멤버에 있는 항목으로 [PutBotAlias](API_PutBotAlias.md) 작업을 호출합니다.
+ `destination` 멤버를 `CLOUDWATCH_LOGS`로 설정
+ `logType` 멤버를 `TEXT`로 설정
+ `resourceArn` 멤버를 로그의 대상인 CloudWatch Logs 로그 그룹의 Amazon 리소스 이름(ARN)으로 설정
1. `conversationLogs` 필드의 `iamRoleArn` 멤버를 IAM 역할(특정한 리소스의 대화 로그를 활성화할 수 있는 필수 권한을 가진)의 Amazon 리소스 이름(ARN)으로 설정합니다.
**API를 사용하여 오디오 로그를 설정하려면**
1. `conversationLogs` 필드의 `logSettings` 멤버에 있는 항목으로 [PutBotAlias](API_PutBotAlias.md) 작업을 호출합니다.
+ `destination` 멤버를 `S3`로 설정
+ `logType` 멤버를 `AUDIO`로 설정
+ `resourceArn` 멤버를 오디오 로그가 저장된 Amazon S3 버킷의 ARN으로 설정
+ 선택 사항. 특정 AWS KMS 키로 오디오 로그를 암호화하려면 암호화에 사용되는 키의 ARN `kmsKeyArn` 멤버를 설정합니다.
1. `conversationLogs` 필드의 `iamRoleArn` 멤버를 IAM 역할(특정한 리소스의 대화 로그를 활성화할 수 있는 필수 권한을 가진)의 Amazon 리소스 이름(ARN)으로 설정합니다.
## 대화 로그 비활성화
**콘솔을 사용하여 로그를 해제하려면**
1. [https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)에서 Amazon Lex 콘솔을 엽니다.
1. 목록에서 봇을 선택합니다.
1. **설정** 탭을 선택한 다음 왼쪽 메뉴에서 **대화 로그**를 선택합니다.
1. 별칭 목록에서 대화 로그를 구성할 별칭의 설정 아이콘을 선택합니다.
1. 로깅을 해제하려면 텍스트, 오디오 또는 둘 다의 선택을 취소합니다.
1. 대화 로깅을 중지하려면 **저장**을 선택합니다.
**API를 사용하여 로그를 해제하려면**
+ `conversationLogs` 필드 없이 `PutBotAlias` 작업을 호출합니다.
**API를 사용하여 텍스트 로그를 해제하려면**
+
+ 오디오를 로깅하는 경우
+ `AUDIO`에 대한 `logSettings` 항목만 사용하여 [PutBotAlias](API_PutBotAlias.md) 작업을 호출합니다.
+ `PutBotAlias` 작업 호출에는 `TEXT`에 대한 `logSettings` 항목이 없어야 합니다.
+ 오디오를 로깅하지 않는 경우
+ `conversationLogs` 필드 없이 [PutBotAlias](API_PutBotAlias.md) 작업을 호출합니다.
**API를 사용하여 오디오 로그를 해제하려면**
+
+ 텍스트를 로깅하는 경우
+ `TEXT`에 대한 `logSettings`항목만 사용하여 [PutBotAlias](API_PutBotAlias.md) 작업을 호출합니다.
+ `PutBotAlias` 작업 호출에는 `AUDIO`에 대한 `logSettings` 항목이 없어야 합니다.
+ 텍스트를 로깅하지 않는 경우
+ `conversationLogs` 필드 없이 [PutBotAlias](API_PutBotAlias.md) 작업을 호출합니다.
# 대화 로그 암호화
암호화를 사용하여 대화 로그의 내용을 보호할 수 있습니다. 텍스트 및 오디오 로그의 경우 AWS KMS 고객 관리형 CMKs 사용하여 CloudWatch Logs 로그 그룹 및 S3 버킷의 데이터를 암호화할 수 있습니다.
**참고**
Amazon Lex는 대칭 CMK만 지원합니다. 비대칭 CMK를 사용하여 데이터를 암호화하지 마십시오.
Amazon Lex가 텍스트 로그에 사용하는 CloudWatch Logs 로그 그룹에서 AWS KMS 키를 사용하여 암호화를 활성화합니다. 로그 그룹의 AWS KMS 암호화를 활성화하기 위해 로그 설정에 AWS KMS 키를 제공할 수 없습니다. 자세한 내용은 *Amazon CloudWatch Logs 사용자 가이드*의 [Encrypt Log Data in CloudWatch Logs Using AWS KMS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)를 참조하세요.
오디오 로그의 경우 S3 버킷에서 기본 암호화를 사용하거나 AWS KMS 키를 지정하여 오디오 객체를 암호화합니다. S3 버킷이 기본 암호화를 사용하더라도 다른 AWS KMS 키를 지정하여 오디오 객체를 암호화할 수 있습니다. 자세한 내용은 *Amazon Simple Storage Service 개발자 가이드*의 [S3 버킷에 대한 Amazon S3 기본 암호화](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)를 참조하세요.
오디오 로그를 암호화하도록 선택한 경우 Amazon Lex에 AWS KMS 권한이 필요합니다. 대화 로그에 사용되는 IAM 역할에 추가 정책을 연결해야 합니다. S3 버킷에서 기본 암호화를 사용하는 경우 정책은 해당 버킷에 대해 구성된 AWS KMS 키에 대한 액세스 권한을 부여해야 합니다. 오디오 로그 설정에서 AWS KMS 키를 지정하는 경우에서 해당 키에 대한 액세스 권한을 부여해야 합니다.
대화 로그의 역할을 만들지 않은 경우 [대화 로그에 대한 IAM 정책](conversation-logs-policies.md) 섹션을 참조하십시오.
**오디오 로그 암호화에 AWS KMS 키를 사용하기 위한 IAM 정책을 생성하려면**
1. **LexConversationLogsKMSPolicy.json**이라는 현재 디렉터리에 문서를 만들고 다음의 정책을 추가한 후 저장합니다.
1. 에서 오디오 로그 암호화에 AWS KMS 키를 사용할 수 있는 권한을 부여하는 IAM 정책을 AWS CLI생성합니다.
```
aws iam create-policy \
--policy-name kms-policy-name \
--policy-document file://LexConversationLogsKMSPolicy.json
```
1. 대화 로그에 대해 생성한 역할에 정책을 연결합니다.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/kms-policy-name \
--role-name role-name
```
# Amazon CloudWatch 로그에서 텍스트 로그 보기
Amazon Lex는 Amazon CloudWatch Logs 의 사용자 대화에 대한 텍스트 로그를 저장합니다. 로그를 보려면 CloudWatch Logs 콘솔이나 API를 사용하십시오. 자세한 내용은 [필터 패턴을 사용한 로그 데이터 검색](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SearchDataFilterPattern.html) 및 *Amazon CloudWatch Logs 사용자 가이드*의 [CloudWatch Logs Insights 쿼리 구문](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)을 참조하세요.
**Amazon Lex 콘솔을 사용하여 로그를 보려면**
1. [https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)에서 Amazon Lex 콘솔을 엽니다.
1. 목록에서 봇을 선택합니다.
1. **설정** 탭을 선택한 다음 왼쪽 메뉴에서 **대화 로그**를 선택합니다.
1. **텍스트 로그** 아래의 링크를 선택하여 CloudWatch 콘솔에 있는 별칭에 대한 로그를 봅니다.
CloudWatch 콘솔이나 API를 사용하여 로그 항목을 볼 수도 있습니다. 로그 항목을 찾으려면 별칭에 대해 구성한 로그 그룹으로 이동합니다. Amazon Lex 콘솔 또는 [GetBotAlias](API_GetBotAlias.md) 작업을 사용하여 로그의 로그 스트림 접두사를 찾습니다.
사용자 표현에 대한 로그 항목은 여러 로그 스트림 에 있습니다. 대화의 표현에는 지정된 접두사가 있는 로그 스트림 중 하나의 항목이 있습니다. 로그 스트림 의 항목에는 다음 정보가 있습니다.
```
{
"messageVersion": "1.0",
"botName": "bot name",
"botAlias": "bot alias",
"botVersion": "bot version",
"inputTranscript": "text used to process the request",
"botResponse": "response from the bot",
"intent": "matched intent",
"nluIntentConfidence": "number",
"slots": {
"slot name": "slot value",
"slot name": null,
"slot name": "slot value"
...
},
"alternativeIntents": [
{
"name": "intent name",
"nluIntentConfidence": "number",
"slots": {
"slot name": slot value,
"slot name": null,
"slot name": slot value
...
}
},
{
"name": "intent name",
"nluIntentConfidence": number,
"slots": {}
}
],
"developerOverride": "true" | "false",
"missedUtterance": true | false,
"inputDialogMode": "Text" | "Speech",
"requestId": "request ID",
"s3PathForAudio": "S3 path to audio file",
"userId": "user ID",
"sessionId": "session ID",
"sentimentResponse": {
"sentimentScore": "{Positive: number, Negative: number, Neutral: number, Mixed: number}",
"sentimentLabel": "Positive" | "Negative" | "Neutral" | "Mixed"
},
"slotToElicit": "slot name",
"dialogState": "ElicitIntent" | "ConfirmIntent" | "ElicitSlot" | "Fulfilled" | "ReadyForFulfillment" | "Failed",
"responseCard": {
"genericAttachments": [
...
],
"contentType": "application/vnd.amazonaws.card.generic",
"version": 1
},
"locale": "locale",
"timestamp": "ISO 8601 UTC timestamp",
"kendraResponse": {
"totalNumberOfResults": number,
"resultItems": [
{
"id": "query ID",
"type": "DOCUMENT" | "QUESTION_ANSWER" | "ANSWER",
"additionalAttributes": [
{
...
}
],
"documentId": "document ID",
"documentTitle": {
"text": "title",
"highlights": null
},
"documentExcerpt": {
"text": "text",
"highlights": [
{
"beginOffset": number,
"endOffset": number,
"topAnswer": true | false
}
]
},
"documentURI": "URI",
"documentAttributes": []
}
],
"facetResults": [],
"sdkResponseMetadata": {
"requestId": "request ID"
},
"sdkHttpMetadata": {
"httpHeaders": {
"Content-Length": "number",
"Content-Type": "application/x-amz-json-1.1",
"Date": "date and time",
"x-amzn-RequestId": "request ID"
},
"httpStatusCode": 200
},
"queryId": "query ID"
},
"sessionAttributes": {
"attribute name": "attribute value"
...
},
"requestAttributes": {
"attribute name": "attribute value"
...
}
}
```
로그 항목의 내용은 거래 결과와 봇 및 요청 구성에 따라 다릅니다.
+ `intent`, `slots`, `slotToElicit` 필드는 `missedUtterance` 필드가 `true`인 경우 항목에 나타나지 않습니다.
+ 오디오 로그가 비활성화되어 있거나 `inputDialogMode` 필드가 `Text`인 경우 `s3PathForAudio` 필드가 나타나지 않습니다.
+ `responseCard` 필드는 봇에 대한 응답 카드를 지정한 경우에만 나타납니다.
+ `requestAttributes` 맵은 요청에 지정된 속성이 있는 경우에만 나타납니다.
+ 이 `kendraResponse`필드는 `AMAZON.KendraSearchIntent`가 Amazon Kendra 인덱스 검색을 요청할 때만 표시됩니다.
+ 봇의 Lambda 함수에 대체 의도가 지정된 경우 이 `developerOverride` 필드는 참입니다.
+ `sessionAttributes` 맵은 요청에 지정된 세션 속성이 있는 경우에만 나타납니다.
+ `sentimentResponse` 맵은 사용자가 봇을 구성해 감정 값을 반환할 경우에만 나타납니다.
**참고**
`messageVersion`에서 해당 내용을 변경하지 않아도 입력 형식을 변경할 수 있습니다. 새 필드가 있는 경우 코드에서 오류가 발생하면 안 됩니다.
Amazon Lex가 CloudWatch 로그에 쓸 수 있도록 설정된 역할과 정책이 있어야 합니다. 자세한 내용은 [대화 로그에 대한 IAM 정책](conversation-logs-policies.md)을 참조하세요.
# Amazon S3에서 오디오 로그에 액세스
Amazon Lex는 S3 버킷에 대화에 대한 오디오 로그를 보관합니다.
**콘솔을 사용하여 오디오 로그에 액세스하려면**
1. [https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)에서 Amazon Lex 콘솔을 엽니다.
1. 목록에서 봇을 선택합니다.
1. **설정** 탭을 선택한 다음 왼쪽 메뉴에서 **대화 로그**를 선택합니다.
1. **오디오 로그** 아래의 링크를 선택하여 Amazon S3 콘솔에 있는 별칭에 대한 로그에 액세스합니다.
Amazon S3 콘솔 또는 API를 사용하여 오디오 로그에 액세스할 수도 있습니다. Amazon Lex 콘솔 또는 `GetBotAlias` 작업 응답의 `resourcePrefix` 필드에서 오디오 파일의 S3 객체 키 접두사를 볼 수 있습니다.
# CloudWatch 지표를 통해 대화 로그 상태 모니터링
Amazon CloudWatch 를 사용하여 대화 로그의 전달 지표를 모니터링합니다. 로깅 문제가 발생할 경우 이를 인식할 수 있도록 지표에 경보를 설정할 수 있습니다.
Amazon Lex에서는 대화 로그에 대한 `AWS/Lex` 네임스페이스에 다음과 같은 4개의 지표를 제공합니다.
+ `ConversationLogsAudioDeliverySuccess`
+ `ConversationLogsAudioDeliveryFailure`
+ `ConversationLogsTextDeliverySuccess`
+ `ConversationLogsTextDeliveryFailure`
자세한 내용은 [대화 로그에 대한 CloudWatch 지표](monitoring-aws-lex-cloudwatch.md#cloudwatch-metrics-for-logging)을 참조하세요.
성공 지표는 Amazon Lex가 대상에 오디오 또는 텍스트 로그를 성공적으로 작성했음을 보여줍니다.
실패 지표는 Amazon Lex가 지정된 대상에 오디오 또는 텍스트 로그를 전달할 수 없음을 보여줍니다. 일반적으로 이는 구성 오류입니다. 실패 지표가 0보다 높으면 다음을 확인하세요.
+ Amazon Lex가 IAM 역할에 대한 신뢰할 수 있는 엔터티인지 확인합니다.
+ 텍스트 로깅의 경우 CloudWatch Logs 로그 그룹이 있는지 확인합니다. 오디오 로깅의 경우 S3 버킷이 있는지 확인합니다.
+ Amazon Lex가 CloudWatch 로그 그룹 또는 S3 버킷에 액세스하는 데 사용하는 IAM 역할에 로그 그룹 또는 버킷에 대한 쓰기 권한이 있는지 확인합니다.
+ S3 버킷이 Amazon Lex 봇과 동일한 리전에 존재하며, 사용자 계정에 속하는지 확인합니다.
+ S3 암호화에 AWS KMS 키를 사용하는 경우 Amazon Lex가 키를 사용하지 못하도록 하는 정책이 없는지 확인하고 제공한 IAM 역할에 필요한 AWS KMS 권한이 있는지 확인합니다. 자세한 내용은 [대화 로그에 대한 IAM 정책](conversation-logs-policies.md) 단원을 참조하십시오.
# Amazon Lex API로 세션 관리
사용자가 봇과 대화를 시작하면 Amazon Lex는 *세션*을 생성합니다. 애플리케이션과 Amazon Lex 간에 교환된 정보는 대화의 세션 상태를 구성합니다. 요청하면 지정한 봇 이름과 사용자 식별자 조합으로 세션이 식별됩니다. 사용자 식별자에 대한 자세한 내용은 [PostContent](API_runtime_PostContent.md) 또는 [PostText](API_runtime_PostText.md) 작업의 `userId` 필드를 참조하십시오.
세션 작업의 응답에는 사용자로 특정 세션을 식별하는 고유한 세션 식별자가 포함됩니다. 테스트 중에 또는 봇의 문제 해결을 위해 이 식별자를 사용할 수 있습니다.
애플리케이션과 봇 간에 전송된 세션 상태를 수정할 수 있습니다. 예를 들어 세션에 대한 사용자 정의 정보가 포함된 세션 속성을 생성 및 수정할 수 있으며, 다음 표현을 해석하도록 대화 컨텍스트를 설정하여 대화의 흐름을 변경할 수 있습니다.
세션 상태를 업데이트할 수 있는 방법에는 두 가지가 있습니다. 첫 번째 방법은 대화가 바뀔 때마다 호출되는 `PostContent` 또는 `PostText` 작업과 함께 Lambda 함수를 사용하는 것입니다. 자세한 내용은 [Lambda 함수 사용](using-lambda.md)을 참조하세요. 다른 방법은 애플리케이션에서 Amazon Lex 런타임 API를 사용하여 세션 상태를 변경하는 것입니다.
Amazon Lex 런타임 API는 봇과의 대화에 대한 세션 정보를 관리할 수 있도록 하는 작업을 제공합니다. 이 작업은 [PutSession](API_runtime_PutSession.md) 작업, [GetSession](API_runtime_GetSession.md) 작업, [DeleteSession](API_runtime_DeleteSession.md) 작업입니다. 이러한 작업을 사용하여 봇과의 사용자 세션 상태에 대한 정보를 얻고 상태를 세부적으로 제어할 수 있습니다.
현재 세션 상태를 확인하려는 경우 `GetSession` 작업을 사용합니다. 이 작업은 사용자와의 대화 상태, 설정된 모든 세션 속성, 사용자가 상호 작용한 마지막 세 의도에 대한 슬롯 값을 포함하여 현재 세션 상태를 반환합니다.
`PutSession` 작업을 사용하면 현재 세션 상태를 직접 조작할 수 있습니다. 봇이 다음으로 수행할 대화 작업의 유형을 설정할 수 있습니다. 이를 통해 봇과의 대화 흐름을 제어할 수 있습니다. Amazon Lex가 봇의 다음 작업을 결정하도록 하려면 대화 작업 `type` 필드를 `Delegate`로 설정합니다.
`PutSession` 작업을 사용하여 봇과의 새로운 세션을 만들고 봇이 시작해야 하는 의도를 설정할 수 있습니다. `PutSession` 작업을 사용하여 한 의도에서 다른 의도로 변경할 수도 있습니다. 세션을 만들거나 의도를 변경할 때 슬롯 값 및 세션 속성 등의 세션 상태를 설정할 수도 있습니다. 새 의도를 마치면 이전 의도를 다시 시작할 수 있습니다. `GetSession` 작업을 사용하여 Amazon Lex에서 이전 의도의 대화 상태를 가져오고 이 정보를 사용하여 의도의 대화 상태를 설정할 수 있습니다.
`PutSession` 작업의 응답에는 `PostContent` 작업과 동일한 정보가 포함되어 있습니다. `PostContent` 작업의 응답과 마찬가지로 이 정보를 사용하여 사용자에게 다음 정보를 입력하라는 메시지를 표시할 수 있습니다.
`DeleteSession` 작업을 사용하여 기존 세션을 제거하고 새 세션을 시작합니다. 예를 들어 봇을 테스트하려는 경우 `DeleteSession` 작업을 사용하여 봇에서 테스트 세션을 제거할 수 있습니다.
이 세션 작업은 이행 Lambda 함수와 함께 작동합니다. 예를 들어 Lambda 함수가 이행 상태로 `Failed`를 반환하는 경우, `PutSession` 작업을 사용하여 대화 작업 유형을 `close`로 설정하고 `fulfillmentState`를 `ReadyForFulfillment`로 설정하여 이행 단계를 재시도할 수 있습니다.
다음은 세션 작업으로 수행할 수 있는 작업입니다.
+ 봇이 사용자를 기다리지 않고 대화를 시작하도록 합니다.
+ 대화 중에 의도를 전환합니다.
+ 이전 의도로 돌아갑니다.
+ 상호 작용 중에 대화를 시작하거나 다시 시작합니다.
+ 슬롯 값의 유효성을 검사하고 봇이 유효하지 않은 값을 다시 묻도록 합니다.
이러한 각 내용은 아래에 자세히 설명되어 있습니다.
## 의도 전환
`PutSession` 작업을 사용하여 한 의도에서 다른 의도로 전환할 수 있습니다. 이 작업을 사용하여 이전 의도로 다시 전환할 수도 있습니다. `PutSession` 작업을 사용하여 새 의도의 슬롯 값 또는 세션 속성을 설정할 수 있습니다.
+ `PutSession` 작업을 직접적으로 호출합니다. 의도 이름을 새 의도의 이름으로 설정하고 대화 작업을 `Delegate`로 설정합니다. 새 의도에 필요한 슬롯 값 또는 세션 속성을 설정할 수도 있습니다.
+ Amazon Lex는 새 의도를 사용하여 사용자와의 대화를 시작합니다.
## 이전 의도 다시 시작
이전 의도를 다시 시작하려면 `GetSession` 작업을 사용하여 의도의 요약을 가져온 후, `PutSession` 작업을 사용하여 의도를 이전 대화 상태로 설정합니다.
+ `GetSession` 작업을 직접적으로 호출합니다. 작업의 응답에는 사용자가 상호 작용한 마지막 세 의도의 대화 상태에 대한 요약이 포함되어 있습니다.
+ 의도 요약의 정보를 사용하여 `PutSession` 작업을 호출합니다. 그러면 사용자가 대화의 같은 위치에 있는 이전 의도로 돌아갑니다.
경우에 따라 봇과 사용자의 대화를 다시 시작해야 할 수 있습니다. 예를 들어 고객 서비스 봇을 만들었다고 가정하겠습니다. 애플리케이션은 사용자가 고객 서비스 담당자와 대화해야 한다고 결정합니다. 사용자와 대화한 후 이 담당자는 수집한 정보와 함께 대화를 다시 봇에 전달할 수 있습니다.
세션을 다시 시작하려면 다음과 비슷한 단계를 사용합니다.
+ 애플리케이션은 사용자가 고객 서비스 담당자와 대화해야 한다고 결정합니다.
+ `GetSession` 작업을 사용하여 의도의 현재 대화 상태를 가져옵니다.
+ 고객 서비스 담당자는 사용자와 대화하고 문제를 해결합니다.
+ `PutSession` 작업을 사용하여 의도의 대화 상태를 설정합니다. 여기에는 슬롯 값 설정, 세션 속성 설정 또는 의도 변경이 포함될 수 있습니다.
+ 봇이 사용자와의 대화를 다시 시작합니다.
나중에 찾을 수 있도록 `PutSession` 작업 `checkpointLabel` 파라미터를 사용하여 의도에 레이블을 지정할 수 있습니다. 예를 들어, 고객에게 정보를 요청하는 봇은 고객이 정보를 수집하는 동안 `Waiting` 의도로 들어갈 수 있습니다. 이 봇은 현재 의도에 대한 체크포인트 레이블을 만든 다음 `Waiting` 의도를 시작합니다. 고객이 돌아오면 봇은 체크포인트 레이블을 사용하여 이전 의도를 찾아 다시 전환할 수 있습니다.
의도는 `GetSession` 작업에 의해 반환된 `recentIntentSummaryView` 구조에 있어야 합니다. `GetSession` 작업 요청에 체크포인트 레이블을 지정하는 경우 해당 체크포인트 레이블이 있는 의도를 최대 3개까지 반환합니다.
+ `GetSession` 작업을 사용하여 현재 세션 상태를 가져옵니다.
+ `PutSession` 작업을 사용하여 마지막 의도에 체크포인트 레이블을 추가합니다. 필요한 경우 이 `PutSession` 호출을 사용하여 다른 의도로 전환할 수 있습니다.
+ 레이블이 지정된 의도로 다시 전환해야 하는 경우 `GetSession` 작업을 호출하여 최근 의도 목록을 반환합니다. Amazon Lex에서 지정된 체크포인트 레이블이 있는 의도만 반환하도록 `checkpointLabelFilter` 파라미터를 사용할 수 있습니다.
## 새 세션 시작
봇이 사용자와 대화를 시작하도록 하려면 `PutSession` 작업을 사용하면 됩니다.
+ 슬롯이 없는 환영 의도와 사용자에게 의도를 명시하라는 결론 메시지를 만듭니다. 예를 들어 "무엇을 주문하시겠어요? '음료 주문' 또는 '피자 주문.'이라고 말할 수 있습니다.
+ `PutSession` 작업을 직접적으로 호출합니다. 의도 이름을 환영 의도의 이름으로 설정하고 대화 작업을 `Delegate`로 설정합니다.
+ Amazon Lex는 환영 의도의 프롬프트에 응답하여 사용자와의 대화를 시작합니다.
## 슬롯 값 유효성 검사
클라이언트 애플리케이션을 사용하여 봇에 대한 응답의 유효성을 검사할 수 있습니다. 응답이 유효하지 않은 경우 `PutSession` 작업을 사용하여 사용자로부터 새 응답을 얻을 수 있습니다. 예를 들어 꽃 주문 봇이 튤립, 장미, 백합만 팔 수 있다고 가정하겠습니다. 사용자가 카네이션을 주문하면 애플리케이션이 다음을 수행할 수 있습니다.
+ `PostText` 또는 `PostContent` 응답에서 반환된 슬롯 값을 검사합니다.
+ 슬롯 값이 유효하지 않으면 `PutSession` 작업을 직접적으로 호출합니다. 애플리케이션이 슬롯 값을 지우고, `slotToElicit` 필드를 설정하고, `dialogAction.type` 값을 `elicitSlot`으로 설정합니다. 선택적으로, Amazon Lex가 슬롯 값을 유도하기 위해 사용하는 메시지를 변경하려는 경우 `message` 및 `messageFormat` 필드를 설정할 수 있습니다.
# 봇 배포 옵션
현재 Amazon Lex 는 다음의 봇 배포 옵션을 제공합니다.
+ [AWS Mobile SDK](https://aws.amazon.com/mobile/sdk/) - AWS Mobile SDK 를 사용하여 Amazon Lex와 통신하는 모바일 애플리케이션을 구축할 수 있습니다.
+ Facebook Messenger – Facebook Messenger 페이지를 Amazon Lex 봇과 통합하여 Facebook에서 최종 사용자가 봇과 통신하도록 할 수 있습니다. 현재 구현에서 이 통합은 텍스트 입력 메시지만 지원합니다.
+ Slack – Slack 메시징 애플리케이션과 Amazon Lex 봇을 통합할 수 있습니다.
+ Twilio – Twilio의 SMS(Simple Messaging Service)와 Amazon Lex 봇을 통합할 수 있습니다.
예를 보려면 [Amazon Lex 봇 배포](examples.md)을 참조하세요.
# 기본 제공 의도 및 슬롯 유형
봇을 더 쉽게 생성할 수 있도록 Amazon Lex에서는 표준 기본 제공 의도 및 슬롯 유형을 사용할 수 있습니다.
**Topics**
+ [기본 제공 의도](howitworks-builtins-intents.md)
+ [기본 제공 슬롯 유형](howitworks-builtins-slots.md)
# 기본 제공 의도
일반적인 작업에 표준 기본 제공 의도 라이브러리를 사용할 수 있습니다. 기본 제공 의도에서 의도를 생성하려면, 콘솔에서 기본 제공 의도를 선택한 후 해당 기본 제공 의도에 새 이름을 지정합니다. 새 의도에는 샘플 표현 등 기본 의도의 구성이 포함되어 있습니다.
현재 구현에서는 다음 작업을 수행할 수 없습니다.
+ 기본 의도에서 샘플 표현 추가 또는 제거
+ 기본 제공 의도의 슬롯 구성
**봇에 기본 제공 의도를 추가하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. 기본 제공 의도를 추가할 봇을 선택합니다.
1. 탐색 창에서 **의도** 옆에 있는 더하기(\$1) 기호를 선택합니다.
1. **의도 추가**에서 **기존 의도 검색**을 선택합니다.
1. **검색 의도 상자**에 봇에 추가할 기본 제공 의도의 이름을 입력합니다.
1. **기본 제공 의도 복사**에서 의도 이름을 입력한 다음 **추가**를 선택합니다.
1. 봇에 필요한 대로 의도를 구성하세요.
**Topics**
+ [AMAZON.CancelIntent](built-in-intent-cancel.md)
+ [AMAZON.FallbackIntent](built-in-intent-fallback.md)
+ [AMAZON.HelpIntent](built-in-intent-help.md)
+ [AMAZON.KendraSearchIntent](built-in-intent-kendra-search.md)
+ [AMAZON.PauseIntent](built-in-intent-pause.md)
+ [AMAZON.RepeatIntent](built-in-intent-repeat.md)
+ [AMAZON.ResumeIntent](built-in-intent-resume.md)
+ [AMAZON.StartOverIntent](built-in-intent-start-over.md)
+ [AMAZON.StopIntent](built-in-intent-stop.md)
**참고**
영어(미국)(en-US) 로캘의 경우 Amazon Lex는 Alexa 표준 기본 제공 의도로부터 의도를 지원합니다. 기본 제공 의도 목록은 [Alexa Skills Kit](https://developer.amazon.com/docs/custom-skills/standard-built-in-intents.html)의 *표준 기본 제공 의도*를 참조하십시오.
Amazon Lex는 다음과 같은 의도는 지원하지 않습니다.
`AMAZON.YesIntent`
`AMAZON.NoIntent`
*Alexa Skills Kit*의 [기본 제공 의도 라이브러리](https://developer.amazon.com/docs/custom-skills/built-in-intent-library.html)에 있는 의도
# AMAZON.CancelIntent
사용자가 현재 상호 작용을 취소하기를 원한다는 것을 나타내는 단어와 문구에 응답합니다. 애플리케이션은 이 의도를 사용하여 사용자와의 상호작용을 종료하기 전에 슬롯 유형 값 및 기타 속성을 제거할 수 있습니다.
공통 표현:
+ 취소
+ 신경 쓰지 마
+ 잊어버려
# AMAZON.FallbackIntent
사용자의 의도 입력이 봇의 예상과 다를 경우 Amazon Lex가 *폴백 의도*를 호출하도록 구성할 수 있습니다. 예를 들어 사용자 입력 "캔디를 주문하고 싶어"가 봇의 `OrderFlowers` 의도와 맞지 않는 경우 Amazon Lex는 응답 처리를 위해 폴백 의도를 호출합니다.
기본 제공 `AMAZON.FallbackIntent` 의도 유형을 봇에 추가하여 폴백 의도를 추가할 수 있습니다. [PutBot](API_PutBot.md) 작업을 사용하거나 콘솔의 기본 제공 의도 목록에서 의도를 선택하여 의도를 지정할 수 있습니다.
폴백 의도 간접 호출은 두 단계로 진행됩니다. 첫 번째 단계에서 폴백 의도는 사용자의 입력을 기반으로 매칭됩니다. 폴백 의도가 일치할 경우 봇이 작동하는 방식은 프롬프트에 설정된 재시도 수에 따라 다릅니다. 예를 들어 의도를 판단하는 최대 시도 횟수가 2라면 봇은 폴백 의도를 호출하기 전에 봇의 확인 프롬프트를 두 번 반환합니다.
Amazon Lex가 폴백 의도와 일치하는 경우는 다음과 같습니다.
+ 의도에 대한 사용자 입력이 봇이 예상한 입력과 같지 않습니다.
+ 음성 입력에 노이즈가 있거나, 텍스트 입력이 단어로 인식되지 않습니다.
+ 사용자 입력이 모호하여 Amazon Lex에서 호출할 의도를 판단할 수 없습니다.
폴백 의도가 간접적으로 호출되는 시점은 다음과 같습니다.
+ 대화가 시작될 때 명확히 하기 위해 설정된 시도 횟수를 넘긴 후에도 봇이 사용자 입력을 의도로 인식하지 않는 경우
+ 설정된 시도 횟수를 넘긴 후에도 의도가 사용자 입력을 슬롯 값으로 인식하지 않는 경우
+ 설정된 시도 횟수를 넘긴 후에도 의도가 사용자 입력을 확인 프롬프트에 대한 응답으로 인식하지 않는 경우
폴백 의도에 사용할 수 있는 항목은 다음과 같습니다.
+ Lambda 함수 이행
+ 결론문
+ 후속 프롬프트
다음은 폴백 의도에 추가할 수 없습니다.
+ 표현
+ Slots
+ 초기화 및 검증 Lambda 함수
+ 확인 프롬프트
봇의 취소문과 폴백 의도를 모두 구성한 경우 Amazon Lex가 폴백 의도를 사용합니다. 봇에 취소문이 있어야 한다면 폴백 의도에 대한 이행 함수를 사용하여 취소문과 동일한 동작을 제공할 수 있습니다. 자세한 내용은 [PutBot](API_PutBot.md) 작업의 `abortStatement` 파라미터를 참조하십시오.
## 확인 프롬프트 사용
봇에 확인 프롬프트를 제공하면 사용자의 유효한 의도를 얻을 수 있도록 해당 프롬프트가 사용됩니다. 확인 프롬프트는 설정해 놓은 횟수를 반복합니다. 그 이후에 폴백 의도가 호출됩니다.
봇을 만들 때 확인 프롬프트를 설정하지 않았고, 사용자가 올바른 의도로 대화를 시작하지 않는다면 Amazon Lex는 폴백 의도를 즉시 호출합니다.
확인 프롬프트를 사용하지 않고 폴백 의도를 사용한다면 Amazon Lex는 다음 상황에서 폴백을 호출하지 않습니다.
+ 사용자가 후속 프롬프트에 응답하지만, 의도를 제공하지 않는 경우 예를 들어, "오늘 다른 것을 원하시나요?"라는 후속 프롬프트에 대한 응답에 대해, 사용자는 "네"라고 대답합니다. Amazon Lex에 사용자의 의도를 파악하기 위한 확인 프롬프트가 없기 때문에 400 잘못된 요청 예외가 반환됩니다.
+ AWS Lambda 함수를 사용할 때 `ElicitIntent` 대화 유형을 반환합니다. Amazon Lex에 사용자의 의도를 파악하기 위한 확인 프롬프트가 없기 때문에 400 잘못된 요청 예외가 반환됩니다.
+ `PutSession` 작업을 사용 중인 경우 `ElicitIntent` 대화 유형을 전송합니다. Amazon Lex에 사용자의 의도를 파악하기 위한 확인 프롬프트가 없기 때문에 400 잘못된 요청 예외가 반환됩니다.
## 폴백 의도에 Lambda 함수 사용
폴백 의도가 호출되면 응답은 [PutIntent](API_PutIntent.md) 작업에 대한 `fulfillmentActivity` 파라미터 설정에 따라 달라집니다. 봇은 다음 중 하나를 수행합니다.
+ 의도 정보를 클라이언트 애플리케이션에 반환합니다.
+ 이행 Lambda 함수를 호출합니다. 세션에 설정된 세션 변수로 함수를 직접적으로 호출합니다.
폴백 의도가 호출될 때 응답을 설정하는 작업에 대한 자세한 내용은 [PutIntent](API_PutIntent.md) 작업의 `fulfillmentActivity` 파라미터를 참조하십시오.
폴백 의도에서 이행 Lambda 함수를 사용하는 경우에는 이 함수로 다른 의도를 호출할 수 있습니다. 회신 번호를 수집하거나 고객 서비스 담당자와의 세션을 개설하는 사용자와 일종의 커뮤니케이션을 수행할 수도 있습니다.
이행 함수에서 다른 의도에 대해 수행할 수 있는 모든 작업을 폴백 의도 Lambda 함수에서 수행할 수 있습니다. 를 사용하여 이행 함수를 생성하는 방법에 대한 자세한 내용은 섹션을 AWS Lambda참조하세요[Lambda 함수 사용](using-lambda.md).
세션이 동일하면 폴백 의도는 여러 번 간접적으로 호출할 수 있습니다. 예를 들어 Lambda 함수가 `ElicitIntent` 대화 작업을 사용하여 사용자에게 다른 의도를 묻는 프롬프트를 표시한다고 해 보겠습니다. Amazon Lex가 설정된 시도 횟수 이후에 사용자의 의도를 추론할 수 없다면 폴백 의도를 다시 호출합니다. 또한 사용자가 구성된 시도 횟수 후 올바른 슬롯 값으로 응답하지 않을 때도 폴백 의도를 간접적으로 호출합니다.
세션 변수를 사용하여 폴백 의도를 호출하는 횟수를 추적하도록 Lambda 함수를 구성할 수 있습니다. Lambda 함수는 Lambda 함수에 설정한 임계값보다 더 많이 호출될 경우 다른 작업을 수행할 수 있습니다. 세션 변수에 대한 자세한 내용은 [Setting Session Attributes](context-mgmt-session-attribs.md) 단원을 참조하세요.
# AMAZON.HelpIntent
사용자가 봇과 상호작용하는 동안 도움이 필요함을 나타내는 단어나 문구에 응답합니다. 이 의도가 간접적으로 호출되면 Lambda 함수 또는 애플리케이션을 구성하여 봇 기능에 대한 정보를 제공하고, 도움이 필요한 영역에 대한 후속 질문을 하거나, 상담원에게 상호 작용을 넘겨줄 수 있습니다.
공통 표현:
+ 도움
+ 도와줘
+ 나 좀 도와줄래?
# AMAZON.KendraSearchIntent
Amazon Kendra로 인덱싱된 문서를 검색하려면 `AMAZON.KendraSearchIntent` 의도를 사용합니다. Amazon Lex가 사용자와의 대화에서 다음 작업을 결정할 수 없으면 검색 의도가 트리거됩니다.
`AMAZON.KendraSearchIntent`는 영어(미국)(en-US) 및 미국 동부(버지니아 북부), 미국 서부(오레곤) 및 유럽(아일랜드) 리전만 사용 가능합니다.
Amazon Kendra는 PDF 문서 또는 Microsoft Word 파일과 같은 자연어 문서를 인덱싱하는 기계 학습 기반 검색 서비스입니다. 인덱싱된 문서를 검색하고 질문에 대해 다음 유형의 응답을 반환할 수 있습니다.
+ 대답
+ 질문에 대한 답이 될 수 있는 FAQ 항목
+ 질문과 관련된 문서
`AMAZON.KendraSearchIntent` 사용 예는 [예제: Amazon Kendra 인덱스에 대한 FAQ 봇 생성](faq-bot-kendra-search.md) 섹션을 참조하십시오.
봇에 `AMAZON.KendraSearchIntent` 의도를 구성하면 Amazon Lex가 슬롯 또는 의도에 대한 사용자 표현을 파악할 수 없을 때마다 이 의도를 호출합니다. 예를 들어 봇이 "피자 토핑"이라는 슬롯 유형에 대한 응답을 유도할 때 사용자가 "피자가 뭐야?"라고 말할 경우 Amazon Lex는 이 질문을 처리하기 위해 `AMAZON.KendraSearchIntent`를 호출합니다. Amazon Kendra에서 응답이 없으면 봇에 구성된 대로 대화가 계속됩니다.
동일한 봇에서 `AMAZON.KendraSearchIntent`와 `AMAZON.FallbackIntent`가 모두 사용되는 경우 Amazon Lex는 이러한 의도를 다음과 같이 사용합니다.
1. Amazon Lex가 `AMAZON.KendraSearchIntent`을 호출합니다. 이 의도는 Amazon Kendra `Query` 작업을 호출합니다.
1. Amazon Kendra에서 응답을 반환하면 Amazon Lex가 사용자에게 결과를 표시합니다.
1. Amazon Kendra에서 응답이 없으면 Amazon Lex가 사용자에게 다시 메시지를 표시합니다. 다음 작업은 사용자의 응답에 따라 달라집니다.
+ 사용자의 응답에 슬롯 값을 채우거나 의도를 확인하는 것과 같이 Amazon Lex에서 인식하는 표현이 포함된 경우 봇에 구성된 대로 사용자와의 대화가 진행됩니다.
+ 사용자의 응답에 Amazon Lex에서 인식하는 표현이 포함되어 있지 않으면 Amazon Lex가 새로운 `Query` 작업을 호출합니다.
1. 구성된 재시도 횟수 이후에 응답이 없으면 Amazon Lex가 `AMAZON.FallbackIntent`를 호출하여 사용자와의 대화를 종료합니다.
`AMAZON.KendraSearchIntent`를 사용하여 Amazon Kendra에 요청을 하는 방법에는 다음 3가지가 있습니다.
+ 의도 검색이 대신 요청하도록 하세요. Amazon Lex는 사용자의 말을 검색 문자열로 사용하여 Amazon Kendra를 호출합니다. 의도를 생성할 때 Amazon Kendra에서 반환되는 응답 수를 제한하는 쿼리 필터 문자열을 정의할 수 있습니다. Amazon Lex는 쿼리 요청에서 필터를 사용합니다.
+ 대화 Lambda 함수를 사용하여 요청에 추가 쿼리 파라미터 추가하세요. `delegate` 대화 작업에 Amazon Kendra 쿼리 파라미터가 포함된 `kendraQueryFilterString` 필드를 추가합니다. Lambda 함수를 사용하여 요청에 쿼리 파라미터를 추가하면 해당 파라미터가 의도를 생성할 때 정의한 쿼리 필터보다 우선 적용됩니다.
+ 대화 Lambda 함수를 사용하여 새 쿼리 생성. Amazon Lex가 보내는 전체 Amazon Kendra 쿼리 요청을 생성할 수 있습니다. `delegate` 대화 작업의 `kendraQueryRequestPayload` 필드에 쿼리를 지정합니다. `kendraQueryRequestPayload` 필드가 `kendraQueryFilterString` 필드보다 우선 적용됩니다.
봇을 생성할 때 `queryFilterString` 파라미터를 지정하거나 대화 Lambda 함수에서 `delegate` 작업을 직접적으로 호출할 때 `kendraQueryFilterString` 필드를 지정하려면 Amazon Kendra 쿼리에 대한 속성 필터로 사용되는 문자열을 지정합니다. 문자열이 유효한 속성 필터가 아닌 경우 런타임에 `InvalidBotConfigException` 예외가 발생합니다. 속성 필터에 대한 자세한 내용은 *Amazon Kendra 개발자 안내서*의 [문서 속성을 사용하여 쿼리 필터링](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering)을 참조하십시오.
Amazon Lex가 Amazon Kendra에 보내는 쿼리를 제어하려면 대화 Lambda 함수의 `kendraQueryRequestPayload` 필드에 쿼리를 지정합니다. 쿼리가 유효하지 않으면 Amazon Lex에서 `InvalidLambdaResponseException` 예외를 반환합니다. 자세한 내용은 *Amazon Kendra 개발자 안내서*의 [쿼리 작업](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html)을 참조하세요.
`AMAZON.KendraSearchIntent` 사용 방법의 예는 [예제: Amazon Kendra 인덱스에 대한 FAQ 봇 생성](faq-bot-kendra-search.md) 단원을 참조하세요.
## Amazon Kendra 검색에 사용되는 IAM 정책
`AMAZON.KendraSearchIntent` 의도를 사용하려면 Amazon Lex가 Amazon Kendra `Query` 의도를 호출할 권한이 있는 런타임 역할을 수임할 수 있도록 하는 AWS Identity and Access Management (IAM) 정책을 제공하는 역할을 사용해야 합니다. 사용하는 IAM 설정은 Amazon Lex 콘솔을 `AMAZON.KendraSearchIntent` 사용하여를 생성하는지 아니면 AWS SDK 또는 AWS Command Line Interface ()를 사용하여 생성하는지에 따라 달라집니다AWS CLI. 콘솔을 사용하는 경우 Amazon Lex 서비스 연결 역할에 Amazon Kendra 호출 권한을 추가하거나, Amazon Kendra `Query` 작업 호출을 위한 전용 역할을 사용할 수 있습니다. AWS CLI 또는 SDK를 사용하여 의도를 생성할 때는 `Query` 작업을 직접적으로 호출하기 위한 역할을 사용해야 합니다.
### 권한 연결
Amazon Kendra 콘솔을 사용하여 `Query` 작업에 액세스할 수 있는 권한을 기본 Amazon Lex 서비스 연결 역할에 연결할 수 있습니다. 서비스 연결 역할에 권한을 연결하면 Amazon Kendra 인덱스에 연결하기 위한 전용 런타임 역할을 생성하고 관리할 필요가 없습니다.
Amazon Lex 콘솔에 액세스하는 데 사용하는 사용자, 역할 또는 그룹에는 역할 정책을 관리할 수 있는 권한이 있어야 합니다. 콘솔 액세스 역할에 다음 IAM 정책을 연결합니다. 이러한 권한을 부여하면 해당 역할이 기존 서비스 연결 역할 정책을 변경할 수 있는 권한을 갖게 됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:GetRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/lex.amazonaws.com/AWSServiceRoleForLexBots"
},
{
"Effect": "Allow",
"Action": "iam:ListRoles",
"Resource": "*"
}
]
}
```
------
### 역할 지정
콘솔, AWS CLI또는 API를 사용하여 Amazon Kendra `Query` 작업을 호출할 때 사용할 런타임 역할을 지정할 수 있습니다.
런타임 역할을 지정하는 데 사용하는 사용자, 역할 또는 그룹에는 `iam:PassRole` 권한이 있어야 합니다. 다음 정책은 권한을 정의합니다. `iam:AssociatedResourceArn` 및 `iam:PassedToService` 조건 컨텍스트 키를 사용해 권한 범위를 추가로 제한할 수 있습니다. 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [ IAM 및 AWS STS 조건 컨텍스트 키를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/role"
}
]
}
```
------
Amazon Lex가 Amazon Kendra를 호출하는 데 사용하는 런타임 역할에는 `kendra:Query` 권한이 있어야 합니다. Amazon Kendra `Query` 작업을 호출할 수 있는 권한을 위해 기존 IAM 역할을 사용하는 경우 역할에 다음 정책이 연결되어 있어야 합니다.
IAM 콘솔, IAM API 또는 AWS CLI 를 사용하여 정책을 생성하고 역할에 연결할 수 있습니다. 여기에 나온 지침에서는 AWS CLI를 사용하여 역할과 정책을 생성합니다.
**참고**
다음 코드는 Linux 및 MacOS 용으로 형식이 지정됩니다. Windows의 경우 Linux 줄 연속 문자(\$1)를 캐럿(^)으로 바꿉니다.
**역할에 쿼리 작업 권한을 추가하려면**
1. 현재 디렉터리에 **KendraQueryPolicy.json**이라는 문서를 만들고 다음 코드를 추가한 다음 저장합니다.
1. 에서 다음 명령을 AWS CLI실행하여 Amazon Kendra `Query` 작업을 실행하기 위한 IAM 정책을 생성합니다.
```
aws iam create-policy \
--policy-name query-policy-name \
--policy-document file://KendraQueryPolicy.json
```
1. `Query` 작업을 호출하는 데 사용하는 IAM 역할에 정책을 연결합니다.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/query-policy-name
--role-name role-name
```
Amazon Lex 서비스 연결 역할을 업데이트하거나 봇에 `AMAZON.KendraSearchIntent`를 만들 때 생성한 역할을 사용하도록 선택할 수 있습니다. 다음 절차에서는 사용할 IAM 역할 을 선택하는 방법을 보여 줍니다.
**AMAZON.KendraSearchItent에 대한 런타임 역할을 지정하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. `AMAZON.KendraSearchIntent`를 추가할 봇을 선택합니다.
1. **의도** 옆에 있는 더하기(\$1) 기호를 선택합니다.
1. **의도 추가**에서 **기존 의도 검색**을 선택합니다.
1. **검색 의도**에 **AMAZON.KendraSearchIntent**를 입력한 다음 **추가**를 선택합니다.
1. **기본 제공 의도 복사**에서 의도의 이름(예: **KendraSearchIntent**)을 입력한 다음 **추가**를 선택합니다.
1. **Amazon Kendra 쿼리** 섹션을 엽니다.
1. **IAM 역할**에서 다음 옵션 중 하나를 선택합니다.
+ 봇이 Amazon Kendra 인덱스를 쿼리할 수 있도록 Amazon Lex 서비스 연결 역할을 업데이트하려면 **Amazon Kendra 권한 추가**를 선택합니다.
+ Amazon Kendra `Query` 작업을 호출할 수 있는 권한이 있는 역할을 사용하려면 **기존 역할 사용**을 선택합니다.
## 요청 및 세션 속성을 필터로 사용
Amazon Kendra의 응답을 현재 대화와 관련된 항목으로 필터링하려면 봇을 생성할 때 `queryFilterString` 파라미터를 추가하여 세션 및 요청 속성을 필터로 사용합니다. 의도를 생성할 때 속성의 자리 표시자를 지정하면 Amazon Lex V2가 Amazon Kendra를 직접적으로 호출하기 전에 해당 값을 대체합니다. 요청 속성에 대한 자세한 내용은 [Setting Request Attributes](context-mgmt-request-attribs.md) 단원을 참조하세요. 세션 속성에 대한 자세한 내용은 [Setting Session Attributes](context-mgmt-session-attribs.md) 단원을 참조하세요.
다음은 Amazon Kendra라는 요청 속성을 사용하여 쿼리를 필터링하는 `queryFilterString` 파라미터의 예입니다.
```
"{"equalsTo": {"key": "City", "value": {"stringValue": "Seattle"}}}"
```
다음은 `"SourceURI"`이라는 세션 속성을 사용하여 Amazon Kendra 쿼리를 필터링하는 `queryFilterString` 파라미터의 예입니다.
```
"{"equalsTo": {"key": "SourceURI","value": {"stringValue": "[FileURL]"}}}"
```
다음은 `"DepartmentName"`이라는 요청 속성을 사용하여 Amazon Kendra 쿼리를 필터링하는 `queryFilterString` 파라미터의 예입니다.
```
"{"equalsTo": {"key": "Department","value": {"stringValue": "((DepartmentName))"}}}"
```
`AMAZON.KendraSearchInteng` 필터는 Amazon Kendra 검색 필터와 동일한 형식을 사용합니다. 자세한 내용은 *Amazon Kendra 개발자 안내서*의 [문서 속성을 사용하여 검색 결과 필터링](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering)을 참조하세요.
`AMAZON.KendraSearchIntent`과 함께 사용되는 쿼리 필터의 문자열은 각 필터의 첫 글자에 소문자를 사용해야 합니다. 예를 들어, 다음은 `AMAZON.KendraSearchIntent`에 대한 유효한 쿼리 필터입니다.
```
{
"andAllFilters": [
{
"equalsTo": {
"key": "City",
"value": {
"stringValue": "Seattle"
}
}
},
{
"equalsTo": {
"key": "State",
"value": {
"stringValue": "Washington"
}
}
}
]
}
```
## 검색 응답 사용
Amazon Kendra는 의도의 `conclusion` 문에서 검색에 대한 응답을 반환합니다. 이행 Lambda 함수가 결론 메시지를 생성하지 않는 한, 의도에 `conclusion` 문이 있어야 합니다.
Amazon Kendra에는 네 가지 유형의 응답이 있습니다.
+ `x-amz-lex:kendra-search-response-question_answer-question-` – 검색과 일치하는 FAQ 질문.
+ `x-amz-lex:kendra-search-response-question_answer-answer-` – 검색과 일치하는 FAQ 답변.
+ `x-amz-lex:kendra-search-response-document-` – 표현 텍스트와 관련된 인덱스에 있는 문서의 발췌문.
+ `x-amz-lex:kendra-search-response-document-link-` – 표현 텍스트와 관련된 인덱스에 있는 문서의 URL.
+ `x-amz-lex:kendra-search-response-answer-` – 질문에 대한 답이 되는 인덱스에 있는 문서의 발췌문.
응답은 `request` 속성에서 반환됩니다. 각 속성에 1부터 5까지 번호가 매겨진 최대 5개의 응답이 있을 수 있습니다. 서비스 이름 변경에 대한 자세한 내용을 알아보려면 *Amazon Kendra 개발자 가이드*의 [응답 유형](https://docs.aws.amazon.com/kendra/latest/dg/response-types.html)을 참조하세요.
`conclusion` 문에는 하나 이상의 메시지 그룹이 있어야 합니다. 각 메시지 그룹에는 하나 이상의 메시지가 포함됩니다. 각 메시지에는 Amazon Kendra의 응답에서 요청 속성으로 대체되는 하나 이상의 자리 표시자 변수가 포함될 수 있습니다. 메시지 그룹에는 해당 메시지의 모든 변수가 런타임 응답에서 요청 속성 값으로 대체되는 메시지가 하나 이상 있어야 합니다. 그렇지 않은 경우 자리 표시자 변수가 없는 메시지 하나가 그룹에 있어야 합니다. 요청 속성은 이중 괄호("((" "))")로 묶입니다. 다음 메시지 그룹 메시지는 Amazon Kendra의 모든 응답과 일치합니다.
+ "질문에 대한 FAQ를 찾았습니다: ((x-amz-lex:kendra-search-response-question\$1answer-question-1)), and the answer is ((x-amz-lex:kendra-search-response-question\$1answer-answer-1))"
+ "I found an excerpt from a helpful document: ((x-amz-lex:kendra-search-response-document-1))"
+ "질문에 대한 답변은 다음과 같습니다 ((x-amz-lex:kendra-search-response-answer-1))"
## Lambda 함수를 사용하여 요청 및 응답 관리
`AMAZON.KendraSearchIntent` 의도는 대화 코드 후크 및 이행 코드 후크를 사용하여 Amazon Kendra에 대한 요청과 응답을 관리할 수 있습니다. Amazon Kendra에 보내는 쿼리를 수정하려면 대화 코드 후크 Lambda 함수를 사용하고, 응답을 수정하려면 이행 코드 후크 Lambda 함수를 사용합니다.
### 대화 코드 후크를 사용하여 쿼리 생성
대화 코드 후크를 사용하여 Amazon Kendra에 보낼 쿼리를 생성할 수 있습니다. 대화 코드 후크 사용은 선택 사항입니다. 대화 코드 후크를 지정하지 않으면 Amazon Lex가 사용자 표현으로부터 쿼리를 구성하고 의도 구성 시 제공된(있는 경우) `queryFilterString`를 사용합니다.
Amazon Kendra에 대한 요청을 수정하기 위해 대화 코드 후크 응답에서 다음 두 필드를 사용할 수 있습니다.
+ `kendraQueryFilterString` – Amazon Kendra 요청에 대한 속성 필터를 지정하려면 이 문자열을 사용합니다. 인덱스에 정의된 인덱스 필드 중 하나를 사용하여 쿼리를 필터링할 수 있습니다. 필터 문자열의 구조는 *Amazon Kendra 개발자 안내서*의 [문서 속성을 사용하여 쿼리 필터링](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering)을 참조하세요. 지정된 필터 문자열이 유효하지 않으면 `InvalidLambdaResponseException` 예외가 발생합니다. `kendraQueryFilterString` 문자열은 해당 의도에 구성된 `queryFilterString`에 지정되어 있는 모든 쿼리 문자열을 재정의합니다.
+ `kendraQueryRequestPayload` – Amazon Kendra 쿼리를 지정하려면 이 문자열을 사용합니다. 쿼리에서 Amazon Kendra의 모든 기능을 사용할 수 있습니다. 유효한 쿼리를 지정하지 않으면 `InvalidLambdaResponseException` 예외가 발생합니다. 자세한 정보는 *Amazon Kendra 개발자 안내서*의 [쿼리](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html)를 참조하세요.
필터 또는 쿼리 문자열을 생성한 후 응답 `dialogAction` 필드를 `delegate`로 설정하여 Amazon Lex에 응답을 보냅니다. Amazon Lex는 Amazon Kendra 에 쿼리를 보낸 다음 이행 코드 후크에 쿼리 응답을 반환합니다.
### 응답에 이행 코드 후크 사용
Amazon Lex가 Amazon Kendra에 쿼리를 보내면 쿼리 응답이 `AMAZON.KendraSearchIntent` 이행 Lambda 함수로 반환됩니다. 코드 후크에 대한 입력 이벤트에는 Amazon Kendra의 전체 응답이 포함되어 있습니다. 쿼리 데이터는 Amazon Kendra `Query` 작업에서 반환된 것과 동일한 구조입니다. 자세한 정보는 *Amazon Kendra 개발자 안내서*의 [쿼리 응답 구문](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html#API_Query_ResponseSyntax)을 참조하세요.
이행 코드 후크는 선택 사항입니다. 이행 코드 후크가 존재하지 않거나 이행 코드 후크가 응답에 메시지를 반환하지 않는 경우 Amazon Lex는 응답에 `conclusion` 문을 사용합니다.
# 예제: Amazon Kendra 인덱스에 대한 FAQ 봇 생성
이 예제에서는 Amazon Kendra 인덱스를 사용하여 사용자의 질문에 대한 답변을 제공하는 Amazon Lex 봇을 생성합니다. FAQ 봇은 사용자와의 대화를 관리합니다. `AMAZON.KendraSearchIntent` 의도를 사용하여 인덱스에 쿼리하고 사용자에게 응답을 제공합니다. 봇을 생성하려면
1. 고객이 봇으로부터 답변을 얻기 위해 상호 작용할 봇을 생성합니다.
1. 사용자 지정 의도를 생성합니다. 봇에는 하나 이상의 표현과 함께 하나 이상의 의도가 필요합니다. 이 의도는 봇을 빌드하는 데 필요하지만 다른 방식으로는 사용되지 않습니다.
1. 봇에 `KendraSearchIntent` 의도를 추가하고 Amazon Kendra 인덱스와 함께 작동하도록 구성합니다.
1. Amazon Kendra 인덱스에 저장된 문서로 답변할 수 있는 질문을 하여 봇을 테스트합니다.
이 예제를 사용하기 전에 Amazon Kendra 인덱스를 생성해야 합니다. 자세한 내용은 *Amazon Kendra 개발자 안내서*의 [S3 버킷(콘솔)으로 시작하기](https://docs.aws.amazon.com/kendra/latest/dg/gs-console.html)를 참조하세요.
**FAQ 봇을 생성하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. 탐색 창에서 **봇**을 선택합니다.
1. **생성(Create)**을 선택합니다.
1. **사용자 지정 봇**을 선택합니다. 다음과 같이 봇을 구성합니다.
+ **봇 이름** – 봇에 용도를 나타내는 이름(예: **KendraTestBot**)을 지정합니다.
+ **음성 출력** – **없음**을 선택합니다.
+ **세션 제한 시간** – **5**를 입력합니다.
+ **감정 분석** – **아니요**를 선택합니다.
+ **COPPA** – **아니요**를 선택합니다.
+ **사용자 표현 저장** – **저장 안 함**을 선택합니다.
1. **생성(Create)**을 선택합니다.
봇을 성공적으로 빌드하려면 하나 이상의 샘플 표현을 사용하여 하나 이상의 의도를 생성해야 합니다. 이 의도는 Amazon Lex 봇을 빌드하는 데 필요하지만 FAQ 응답에는 사용되지 않습니다. 이 의도의 표현은 고객이 묻는 질문에 해당하지 않아야 합니다.
**필요한 의도를 생성하려면**
1. **봇 시작하기** 페이지에서 **의도 생성**을 선택합니다.
1. **의도 추가**에서 **의도 생성**을 선택합니다.
1. **의도 생성** 대화 상자에서 의도의 이름(예: **RequiredIntent**)을 지정합니다.
1. **샘플 표현**에 표현(예: **Required utterance**)를 입력합니다.
1. **의도 저장**을 선택합니다.
이제 Amazon Kendra 인덱스를 검색하기 위한 의도와 이를 통해 반환되어야 하는 응답 메시지를 생성합니다.
**AMAZON.KendraSearchIntent 및 응답 메시지를 생성하려면**
1. 탐색 창에서 **의도** 옆에 있는 더하기(\$1) 기호를 선택합니다.
1. **의도 추가**에서 **기존 의도 검색**을 선택합니다.
1. **의도 검색** 상자에 **AMAZON.KendraSearchIntent**를 입력한 다음 목록에서 이를 선택합니다.
1. **기본 제공 의도 복사**에서 의도 이름(예: **KendraSearchIntent**)을 입력한 다음 **추가**를 선택합니다.
1. 의도 편집기에서 **Amazon Kendra 쿼리**를 선택하여 쿼리 옵션을 엽니다.
1. **Amazon Kendra 인덱스** 메뉴에서 검색하려는 인덱스를 선택합니다.
1. **응답** 섹션에서 다음 3가지 메시지를 추가합니다.
```
I found a FAQ question for you: ((x-amz-lex:kendra-search-response-question_answer-question-1)) and the answer is ((x-amz-lex:kendra-search-response-question_answer-answer-1)).
I found an excerpt from a helpful document: ((x-amz-lex:kendra-search-response-document-1)).
I think the answer to your questions is ((x-amz-lex:kendra-search-response-answer-1)).
```
1. **의도 저장**을 선택한 다음 **빌드**를 선택하여 봇을 빌드합니다.
마지막으로 콘솔 테스트 창을 사용하여 봇의 응답을 테스트합니다. 질문이 인덱스가 지원하는 도메인에 있어야 합니다.
**FAQ 봇을 테스트하려면**
1. 콘솔 테스트 창에서 인덱스에 대한 질문을 입력합니다.
1. 테스트 창의 응답 섹션에서 답을 확인합니다.
1. 다른 질문에 대한 테스트 창을 재설정하려면 **채팅 기록 지우기**를 선택합니다.
# AMAZON.PauseIntent
사용자가 봇과의 상호 작용을 일시 중지하여 나중에 다시 돌아올 수 있도록 하는 단어 및 구문에 응답합니다. Lambda 함수 또는 애플리케이션이 의도 데이터를 세션 변수에 저장하거나, 현재 의도를 재개할 때 [GetSession](API_runtime_GetSession.md) 작업을 사용하여 의도 데이터를 검색해야 합니다.
공통 표현:
+ 일시 중지
+ 일시 중지
# AMAZON.RepeatIntent
사용자가 이전 메시지를 반복하게 할 수 있는 단어와 구문에 응답합니다. 애플리케이션은 Lambda 함수를 사용하여 이전 의도 정보를 세션 변수에 저장하거나 [GetSession](API_runtime_GetSession.md) 작업을 사용하여 이전 의도 정보를 가져와야 합니다.
공통 표현:
+ 반복
+ 다시 말해줘
+ 반복해줘
# AMAZON.ResumeIntent
사용자가 이전에 일시 중지된 의도를 재개할 수 있도록 단어와 구문에 응답합니다. Lambda 함수 또는 애플리케이션은 이전 의도를 재개하는 데 필요한 정보를 관리해야 합니다.
공통 표현:
+ 재개
+ 계속
+ 지속
# AMAZON.StartOverIntent
사용자가 현재 의도 처리를 중단하고 처음부터 다시 시작할 수 있도록 하는 단어와 구문에 응답합니다. Lambda 함수 또는 `PutSession` 작업을 사용하여 첫 번째 슬롯 값을 다시 이끌어낼 수 있습니다.
공통 표현:
+ 다시 시작
+ 재시작
+ 다시 시작해
# AMAZON.StopIntent
사용자가 현재 의도 처리를 중단하고 봇과의 상호작용을 종료하기를 원한다는 것을 나타내는 단어와 문구에 응답합니다. Lambda 함수 또는 애플리케이션은 기존 속성 및 슬롯 유형 값을 모두 지운 다음 상호 작용을 종료해야 합니다.
공통 표현:
+ 멈춰
+ 꺼
+ 조용히 해
# 기본 제공 슬롯 유형
Amazon Lex는 슬롯의 데이터를 인식하고 처리하는 방법을 정의하는 기본 제공 슬롯 유형을 지원합니다. 의도에 이러한 유형의 슬롯을 만들 수 있습니다. 따라서 날짜, 시간 및 위치와 같이 흔히 사용되는 슬롯 데이터의 열거 값을 만들 필요가 없습니다. 내장 슬롯 유형에는 버전이 없습니다.
| 슬롯 유형 | 간략한 설명 | 지원되는 로캘 |
| --- | --- | --- |
| [AMAZON.Airport](built-in-slot-airport.md) | 공항을 나타내는 단어를 인식합니다. | 모든 로캘 |
| [AMAZON.AlphaNumeric](built-in-slot-alphanumeric.md) | 문자와 숫자로 구성된 단어를 인식합니다. | 한국어(Ko-KR)를 제외한 모든 로캘 |
| [AMAZON.City](built-in-slot-city.md) | 공항을 나타내는 단어를 인식합니다. | 모든 로캘 |
| [AMAZON.Country](built-in-slot-country.md) | 공항을 나타내는 단어를 인식합니다. | 모든 로캘 |
| [AMAZON.DATE](built-in-slot-date.md) | 날짜를 나타내는 단어를 인식하여 표준 형식으로 변환합니다. | 모든 로캘 |
| [AMAZON.DURATION](built-in-slot-duration.md) | 지속 시간을 나타내는 단어를 인식하여 표준 형식으로 변환합니다. | 모든 로캘 |
| [AMAZON.EmailAddress](built-in-slot-email.md) | 이메일 주소를 나타내는 단어를 표준 이메일 주소로 변환합니다. | 모든 로캘 |
| [AMAZON.FirstName](built-in-slot-first-name.md) | 이름을 나타내는 단어를 인식합니다. | 모든 로캘 |
| [AMAZON.LastName](built-in-slot-last-name.md) | 성을 나타내는 단어를 인식합니다. | 모든 로캘 |
| [AMAZON.NUMBER](built-in-slot-number.md) | 숫자 단어를 인식하여 숫자로 변환합니다. | 모든 로캘 |
| [AMAZON.Percentage](built-in-slot-percent.md) | 백분율을 나타내는 단어를 숫자와 퍼센트 기호(%)로 변환합니다. | 모든 로캘 |
| [AMAZON.PhoneNumber](built-in-slot-phone.md) | 전화번호를 나타내는 단어를 숫자 문자열로 변환합니다. | 모든 로캘 |
| [AMAZON.SpeedUnit](built-in-slot-speed.md) | 속도 단위를 나타내는 단어를 표준 약어로 변환합니다. | 영어(미국)(en-US) |
| [AMAZON.State](built-in-slot-state.md) | 상태를 나타내는 단어를 인식합니다. | 모든 로캘 |
| [AMAZON.StreetName](built-in-slot-street-name.md) | 거리 이름을 나타내는 단어를 인식합니다. | 영어(미국)(en-US)을 제외한 모든 로캘 |
| [AMAZON.TIME](built-in-slot-time.md) | 시간을 나타내는 단어를 시간 형식으로 변환합니다. | 모든 로캘 |
| [AMAZON.WeightUnit](built-in-slot-weight.md) | 속도 단위를 나타내는 단어를 표준 약어로 변환합니다. | 영어(미국)(en-US) |
**참고**
영어(미국)(en-US) 로캘의 경우 Amazon Lex는 Alexa 스킬 키트의 슬롯 유형을 지원합니다. 사용 가능한 기본 제공 슬롯 유형의 목록은 Alexa Skills Kit 설명서의 [슬롯 유형 참조](https://developer.amazon.com/docs/custom-skills/slot-type-reference.html)를 참조하십시오.
Amazon Lex는 `AMAZON.LITERAL` 또는 `AMAZON.SearchQuery` 기본 제공 슬롯 유형을 지원하지 않습니다.
# AMAZON.Airport
공항 목록을 제공합니다. 그러한 예는 다음과 같습니다.
+ 존 F. 케네디 국제공항
+ 멜버른 공항
# AMAZON.AlphaNumeric
**APQ123**과 같은 문자와 숫자로 구성된 문자열을 인식합니다.
이 슬롯 유형은 한국어(Ko-KR)로캘에서 사용할 수 없습니다.
다음을 포함하는 문자열에 `AMAZON.AlphaNumeric` 슬롯 유형을 사용할 수 있습니다.
+ 알파벳 문자(예: **ABC**)
+ 숫자(예: **123**)
+ 영숫자 조합(예: **ABC123**)
`AMAZON.AlphaNumeric` 슬롯 유형에 정규식을 추가하여 슬롯에 입력된 값의 유효성을 검사할 수 있습니다. 예를 들어 정규식을 사용하여 다음 항목의 유효성을 검사할 수 있습니다.
+ 영국 또는 캐나다 우편 번호
+ 운전 면허증 번호
+ 차량 식별 번호
표준 정규 표현식을 사용합니다. Amazon Lex는 정규 표현식에서 다음 문자를 지원합니다.
+ A\$1Z, a\$1z
+ 0\$19
Amazon Lex는 정규식에서 유니코드 문자도 지원합니다. 형식은 `\uUnicode`입니다. 유니코드 문자를 나타내려면 4자리 숫자를 사용합니다. 예를 들어 `[\u0041-\u005A]`는 [A\$1Z]와 같습니다.
다음 정규식 연산자는 지원되지 않습니다.
+ 무한 반복자: 상한이 없는 \$1, \$1 또는 \$1x,\$1
+ 와일드 카드(.)
정규식의 최대 길이는 300자입니다. 정규식을 사용하는 AMAZON.AlphaNumeric 슬롯 유형에 저장되는 문자열의 최대 길이는 30자입니다.
다음은 정규식의 몇 가지 예입니다.
+ **APQ123** 또는 **APQ1** 같은 영숫자 문자열: `[A-Z]{3}[0-9]{1,3}` 또는 보다 제약된 `[A-DP-T]{3} [1-5]{1,3}`
+ **CP123456789US**같은 USPS(US Postal Service) 국제 우선 취급 우편 형식: `CP[0-9]{9}US`
+ **123456789** 같은 은행 송금 번호: `[0-9]{9}`
슬롯 유형에 정규식을 설정하려면 콘솔 또는 [PutSlotType](API_PutSlotType.md) 작업을 사용합니다. 슬롯 유형을 저장하면 정규식의 유효성이 검사됩니다. 정규식이 유효하지 않으면 Amazon Lex에서 오류 메시지가 반환됩니다.
슬롯 유형에 정규식을 사용하는 경우 Amazon Lex는 정규식과 대조하여 해당 유형의 슬롯에 대한 입력을 확인합니다. 입력이 정규식과 일치하면 해당 값이 슬롯에 허용되고, 입력이 정규식과 일치하지 않으면 Amazon Lex에서 다시 입력하라는 메시지가 표시됩니다.
# AMAZON.City
지역 및 세계 도시 목록을 제공합니다. 슬롯 유형은 도시 이름의 일반적인 변형을 인식합니다. Amazon Lex는 변형을 공식 명칭으로 변환하지 않습니다.
예시:
+ 뉴욕
+ 레이캬비크
+ 도쿄
+ 베르사유
# AMAZON.Country
전 세계 국가의 이름입니다. 예시:
+ 호주
+ 독일
+ 일본
+ 미국
+ 우루과이
# AMAZON.DATE
날짜를 나타내는 단어를 날짜 형식으로 변환합니다.
날짜는 의도에 ISO-8601 날짜 형식으로 제공됩니다. 의도가 슬롯에서 수신되는 날짜는 사용자가 말한 특정 문구에 따라 달라질 수 있습니다.
+ "오늘", "지금" 또는 "11월 25일"과 같이 특정 날짜에 매핑되는 표현은 전체 날짜로 변환됩니다: `2020-11-25`. 기본값은 *현재 날짜 또는 그 이후*의 날짜입니다.
+ "이번 주" 또는 "다음 주"와 같이 특정 주에 매핑되는 표현은 해당 주의 첫째 날의 날짜로 변환됩니다. ISO-8601 형식에서는 한 주가 월요일에 시작하여 일요일에 끝납니다. 예를 들어 오늘이 2020-11-25인 경우 "다음 주"는 `2020-11-30`로 변환됩니다.
+ "다음 달"과 같이 특정 날짜가 아닌 달에 매핑되는 표현은 해당 월의 마지막 날로 변환됩니다. 예를 들어 오늘이 2020-11-25인 경우 "다음 달"은 `2020-12-31`로 변환됩니다.
+ 연도에 매핑되지만 특정 월이나 요일은 아닌 표현(예: "다음 연도")는 다음 해의 마지막 날로 변환됩니다. 예를 들어 오늘이 2020-11-25인 경우 "다음 연도"는 `2021-12-31`로 변환됩니다.
# AMAZON.DURATION
지속 시간을 나타내는 단어를 지속 시간으로 변환합니다.
지속 시간은 [ISO-8601 지속 시간 형식](https://en.wikipedia.org/wiki/ISO_8601#Durations), `PnYnMnWnDTnHnMnS`를 기반으로 하는 형식으로 확인됩니다. `P`은 해당 사항이 기간이며, `n`가 숫자 값이고, `n` 뒤에 오는 대문자가 특정 날짜 또는 시간 요소임을 나타냅니다. 예를 들어, `P3D`은 3일을 의미합니다. `T`는 나머지 값이 날짜 요소가 아닌 시간 요소를 나타낸다는 것을 나타내는 데 사용됩니다.
예시:
+ "10분": `PT10M`
+ "다섯 시간": `PT5H`
+ "3일": `P3D`
+ "45초": `PT45S`
+ "8주": `P8W`
+ "7년": `P7Y`
+ "5시간 10분": `PT5H10M`
+ "2년 3시간 10분": `P2YT3H10M`
# AMAZON.EmailAddress
username@domain으로 제공된 이메일 주소를 나타내는 단어를 인식합니다. 주소에는 사용자 이름 부분에 밑줄(\$1), 하이픈(-), 마침표(.) 및 더하기 기호(\$1)와 같은 특수 문자를 포함할 수 있습니다.
# AMAZON.FirstName
일반적으로 사용되는 이름입니다. 이 슬롯 유형은 공식 이름과 비공식 닉네임을 모두 인식합니다. 의도에 전송된 이름은 사용자가 보낸 값입니다. Amazon Lex는 별명을 정식 이름으로 변환하지 않습니다.
비슷하지만 철자가 다른 이름의 경우 Amazon Lex는 의도에 단일 공통 양식을 전송합니다.
영어(미국)(en-US) 로캘에서는 AMAZON.US\$1First\$1Name이라는 슬롯 이름을 사용하십시오.
예시:
+ 에밀리
+ 존
+ 소피
# AMAZON.LastName
일반적으로 사용되는 성입니다. 철자가 다르지만 비슷하게 들리는 이름의 경우 Amazon Lex는 의도에 단일 공통 양식을 전송합니다.
영어(미국)(en-US) 로캘에서는 AMAZON.US\$1Last\$1Name이라는 슬롯 이름을 사용합니다.
예시:
+ 브로스키
+ 대셔
+ 에버스
+ 파레스
+ 웰트
# AMAZON.NUMBER
숫자를 표현하는 단어나 숫자를 십진수를 포함한 숫자로 변환합니다. 다음 표에는 `AMAZON.NUMBER` 슬롯 유형이 숫자 단어를 캡처하는 방식이 나와 있습니다.
| Input | 응답 |
| --- | --- |
| 백이십삽점사오 | 123.45 |
| 백이십삼점사오 | 123.45 |
| 영점사이 | 0.42 |
| 영점사이 | 0.42 |
| 232.998 | 232.998 |
| 50 | 50 |
# AMAZON.Percentage
백분율을 나타내는 단어와 기호를 숫자와 퍼센트 기호(%)로 변환합니다.
사용자가 퍼센트 기호 또는 "퍼센트"라는 단어 없이 숫자를 입력하면 슬롯 값은 숫자로 설정됩니다. 다음 표에는 `AMAZON.Percentage` 슬롯 유형이 백분율을 캡처하는 방식이 나와 있습니다.
| Input | 응답 |
| --- | --- |
| 50 퍼센트 | 50% |
| 0.4 퍼센트 | 0.4% |
| 23.5% | 23.5% |
| 이십오 퍼센트 | 25% |
# AMAZON.PhoneNumber
전화번호를 나타내는 숫자 또는 단어를 다음과 같이 구두점이 없는 문자열 형식으로 변환합니다.
| Type | 설명 | Input | 결과 |
| --- | --- | --- | --- |
| 앞에 더하기(\$1) 기호가 표시된 국제 전화번호 | 앞에 더하기 기호가 표시된 11자리 숫자 | \$161 7 4445 1061 \$11 (509) 555-1212 | `+61744431061` `+15095551212` |
| 앞에 더하기(\$1) 기호가 표시되지 않은 국제 전화번호 | 앞에 더하기 기호가 표시되지 않은 11자리 숫자 | 1 (509) 555-1212 61 7 4445 1061 | `15095551212` `61744451061` |
| 국내 전화번호 | 국가 번호가 표시되지 않은 10자리 숫자 | (03) 5115 4444 (509) 555-1212 | `0351154444` `5095551212` |
| 시내 전화번호 | 국가 번호 또는 지역 번호가 표시되지 않은 7자리 전화번호 | 555-1212 | 5551212 |
# AMAZON.SpeedUnit
속도 단위를 나타내는 단어를 해당 약어로 변환합니다. 예를 들어 "시간당 마일"은 `mph`로 변환됩니다.
이 슬롯 유형은 영어(미국)(en-US) 로캘에서만 사용할 수 있습니다.
다음 예제는 `AMAZON.SpeedUnit` 슬롯 유형이 속도 단위를 캡처하는 방식을 보여 줍니다.
| 속도 단위 | 약어 |
| --- | --- |
| 시간당 마일, mph, MPH, m/h | mph |
| 시간당 킬로미터, 시간당 km, kmph, KMPH, km/h | kmph |
| 초당 미터, mps, MPS, m/s | mps |
| 시간당 해리, knots, knot | knot |
# AMAZON.State
국가 내 지리적 및 정치적 지역의 이름.
예시:
+ 바이에른
+ 후쿠시마 현
+ 퍼시픽 노스웨스트
+ 퀸즐랜드
+ 웨일스
# AMAZON.StreetName
일반적인 도로명 주소 내의 거리 이름. 여기에는 집 번호가 아닌 도로명만 포함됩니다.
이 슬롯 유형은 영어(미국)(en-US) 로캘에서는 사용할 수 없습니다.
예시:
+ 캔버라 애비뉴
+ 프론트 스트리트
+ 마켓 로드
# AMAZON.TIME
시간을 나타내는 단어를 시간 값으로 변환합니다. 모호한 시기에 대한 해결책이 포함되어 있습니다. 사용자가 모호한 시간을 입력하면 Amazon Lex는 Lambda 이벤트의 `slotDetails` 속성을 사용하여 모호한 시간에 대한 확인을 Lambda 함수로 전달합니다. 예를 들어 봇이 사용자에게 배송 시간을 입력하라는 메시지를 표시하면 사용자는 "10시 정각"이라고 응답할 수 있습니다. 사용자가 응답한 시간은 모호합니다. 이 시간은 10 AM 또는 10 PM을 의미할 수 있습니다. 이 경우 `slots` 맵의 값은 `null`이고 `slotDetails` 엔터티에는 이 시간에 대해 가능한 두 가지 확인이 포함되어 있습니다. Amazon Lex는 다음 이벤트를 사용하여 Lambda 함수를 호출합니다.
```
"slots": {
"deliveryTime": null
},
"slotDetails": {
"deliveryTime": {
"resolutions": [
{
"value": "10:00"
},
{
"value": "22:00"
}
]
}
}
```
사용자가 모호한 시간으로 응답하면 Amazon Lex는 해당 시간을 Lambda 이벤트의 `slots` 속성의 Lambda 함수로 보내고 `slotDetails` 속성은 비어 있습니다. 예를 들어 사용자가 배송 시간을 묻는 메시지에 "10 PM"이라고 응답하면 Amazon Lex는 Lambda 함수에 다음과 같이 입력합니다.
```
"slots": {
"deliveryTime": "22:00"
}
```
Amazon Lex에서 Lambda 함수로 보낸 데이터에 대한 자세한 내용은 [입력 이벤트 형식](lambda-input-response-format.md#using-lambda-input-event-format) 섹션을 참조하십시오.
# AMAZON.WeightUnit
중량 단위를 나타내는 단어를 해당 약어로 변환합니다. 예를 들어 "킬로그램"은 `kg`로 변환됩니다.
이 슬롯 유형은 영어(미국)(en-US) 로캘에서만 사용할 수 있습니다.
다음 예제는 `AMAZON.WeightUnit` 슬롯 유형이 중량 단위를 캡처하는 방식을 보여 줍니다.
| 중량 단위 | 약어 |
| --- | --- |
| 킬로그램, 킬로, kgs, KGS | kg |
| 그램, gms, gm, GMS, g | g |
| 밀리그램, mg, mgs | mg |
| 파운드, lbs, LBS | lbs |
| 온스, oz, OZ | oz |
| 톤, ton, t | t |
| 킬로톤, kt | kt |
# 사용자 지정 슬롯 유형
각 의도에 대해 사용자의 요청을 이행하기 위해 의도에 필요한 정보를 나타내는 파라미터를 지정할 수 있습니다. 이러한 파라미터 또는 슬롯에는 일종의 유형이 있습니다. *슬롯 유형*은 Amazon Lex가 슬롯에 대한 값을 인식하기 위해 기계 학습 모델을 학습하는 데 사용하는 값 목록입니다. 예를 들어 "`Genres.`"라는 슬롯 유형을 정의할 수 있는데, 슬롯 유형의 각 값은 "코미디," "어드벤처," "다큐멘터리" 등의 장르 이름입니다. 슬롯 유형 값에 대한 동의어를 정의할 수 있습니다. 예를 들어 "코미디" 값에 대한 동의어로 "재밌는" 및 "유머러스한"를 정의할 수 있습니다.
슬롯 값에 대한 확인을 제한하도록 슬롯 유형을 구성할 수 있습니다. 슬롯 값은 열거로 사용되며 사용자가 입력한 값은 슬롯 값 또는 동의어 중 하나와 동일한 경우에만 슬롯 값으로 확인됩니다. 동의어는 해당 슬롯 값으로 확인됩니다. 예를 들어 사용자가 "재밌는"를 입력하면 슬롯 값 "코미디"로 확인됩니다.
또는 값을 확장하도록 슬롯 유형을 구성할 수 있습니다. 슬롯 값은 학습 데이터로 사용되며 사용자가 입력한 값이 슬롯 값 및 동의어와 유사한 경우 슬롯이 해당 값으로 확인됩니다. 이는 기본 설정 동작입니다.
Amazon Lex 는 슬롯에 가능한 확인 목록을 유지 관리합니다. 목록의 각 항목은 Amazon Lex 가 슬롯의 추가 가능함으로 인식한 *확인 값*을 제공합니다. 확인 값은 슬롯 값을 일치시키기 위한 최고의 방법입니다. 확인 목록에는 최대 다섯 개의 값이 포함됩니다.
사용자가 입력한 값이 동의어인 경우 확인 값 목록의 첫 번째 항목이 슬롯 유형 값입니다. 예를 들어 사용자가 "재밌는"를 입력한 경우 `slots` 필드에 "재밌는"이 포함되어 있고 `slotDetails` 필드의 첫 번째 항목은 "코미디"입니다. [PutSlotType](API_PutSlotType.md) 작업을 사용하여 슬롯 유형을 생성 또는 업데이트할 때 슬롯 값이 확인 목록의 첫 번째 값으로 채워지도록 `valueSelectionStrategy`를 구성할 수 있습니다.
Lambda 함수 를 사용하는 경우 이 함수의 입력 이벤트에는 `slotDetails`라는 확인 목록이 포함되어 있습니다. 다음 예제는 Lambda 함수에 대한 입력의 슬롯 및 슬롯 세부 정보 단원을 보여 줍니다.
```
"slots": {
"MovieGenre": "funny";
},
"slotDetails": {
"Movie": {
"resolutions": [
"value": "comedy"
]
}
}
```
각 슬롯 유형에 대해 값과 동의어는 최대 10,000개까지 정의할 수 있습니다. 각 봇은 슬롯 유형 값 및 동의어를 합해 최대 50,000개까지 포함할 수 있습니다. 예를 들면, 각각 5,000개 값과 5,000개 동의어를 가진 5개의 슬롯 유형을 가지거나 아니면 각각 2,500개 값과 2,500개 동의어를 가진 10개의 슬롯 유형을 가질 수 있습니다. 이 제한을 초과한 경우, [PutBot](API_PutBot.md) 작업을 호출할 때 `LimitExceededException`를 가져올 수 있습니다.
# 슬롯 난독화
Amazon Lex를 사용하면 슬롯의 내용이 표시되지 않도록 해당 내용을 난독화하거나 숨길 수 있습니다. 슬롯 값으로 캡처된 중요한 데이터를 보호하려면 슬롯 난독화를 활성화하여 대화 로그에서 해당 값을 마스킹할 수 있습니다.
슬롯 값을 난독화하도록 선택한 경우 Amazon Lex는 슬롯 값을 대화 로그의 슬롯 이름으로 바꿉니다. `full_name`이라는 슬롯의 경우 슬롯 값은 다음과 같이 난독화됩니다.
```
Before obfuscation:
My name is John Stiles
After obfuscation:
My name is {full_name}
```
표현에 괄호 문자(\$1\$1)가 있는 경우 Amazon Lex는 괄호 문자를 역슬래시 두 개(\$1\$1)로 이스케이프합니다. 예를 들어 텍스트 `{John Stiles}`는 다음과 같이 난독화됩니다.
```
Before obfuscation:
My name is {John Stiles}
After obfuscation:
My name is \\{{full_name}\\}
```
슬롯 값은 대화 로그에서 난독화됩니다. 슬롯 값은 `PostContent` 및 `PostText` 작업의 응답에서 계속 사용할 수 있으며, Lambda 함수의 유효성 검사 및 이행에 사용할 수 있습니다. 프롬프트 또는 응답에 슬롯 값을 사용하는 경우 이러한 슬롯 값은 대화 로그에서 난독화되지 않습니다.
대화의 첫 번째 차례에서 Amazon Lex가 표현의 슬롯 및 슬롯 값을 인식하면 슬롯 값을 난독화합니다. 슬롯 값이 인식되지 않으면 Amazon Lex는 표현을 난독화하지 않습니다.
두 번째 및 이후 차례에서 Amazon Lex는 유도할 슬롯과 슬롯 값을 난독화해야 하는지 여부를 알고 있습니다. Amazon Lex가 슬롯 값을 인식하면 값이 난독화됩니다. Amazon Lex가 값을 인식하지 못하면 전체 표현이 난독화됩니다. 누락된 표현의 슬롯 값은 난독화되지 않습니다.
또한 Amazon Lex는 요청 또는 세션 속성에 저장하는 슬롯 값을 난독화하지 않습니다. 속성으로 난독화해야 하는 슬롯 값을 저장하는 경우 값을 암호화하거나 난독화해야 합니다.
Amazon Lex는 오디오의 슬롯 값을 난독화하지 않습니다. 오디오 트랜스크립션의 슬롯 값을 난독화합니다.
봇의 모든 슬롯을 난독화할 필요는 없습니다. 콘솔을 사용하거나 Amazon Lex API를 사용하여 난독화할 슬롯을 선택할 수 있습니다. 콘솔의 슬롯에 대한 설정에서 **슬롯 난독화**를 선택합니다. API를 사용하는 경우 [PutIntent](API_PutIntent.md) 작업을 호출할 때 슬롯의 `obfuscationSetting` 필드를 `DEFAULT_OBFUSCATION`으로 설정합니다.
# 감정 분석
감정 분석을 사용하여 사용자 표현으로 표현된 감정을 결정할 수 있습니다. 감정 정보를 사용하여 대화 흐름을 관리하거나 직접 호출 후 분석을 수행할 수 있습니다. 예를 들어 사용자 감정이 부정적이면 대화를 인간 담당자에게 넘기는 흐름을 만들 수 있습니다.
Amazon Lex 는 Amazon Comprehend와 통합되어 사용자 감정을 감지합니다. Amazon Comprehend 의 응답은 텍스트의 전체 감정이 긍정, 중립, 부정 또는 혼합인지 여부를 나타냅니다. 응답에는 사용자 표현에 대한 가장 가능성이 높은 감정 및 각 감정 범주에 대한 점수가 포함됩니다. 점수는 감성이 올바르게 감지되었을 가능성을 나타냅니다.
콘솔을 사용하거나 Amazon Lex API를 사용하여 봇에 대한 감정 분석을 활성화합니다. Amazon Lex 콘솔에서 봇의 **설정** 탭을 선택한 다음 **감정 분석** 옵션을 **예**로 설정합니다. API를 사용하는 경우 `detectSentiment` 필드가 `true`로 설정된 [PutBot](API_PutBot.md) 작업을 호출합니다.
감정 분석이 활성화되면 [PostContent](API_runtime_PostContent.md) 및 [PostText](API_runtime_PostText.md) 작업의 응답은 다른 메타데이터와 함께 봇 응답에서 `sentimentResponse`라는 필드를 반환합니다. `sentimentResponse` 필드에는 감정 분석 결과를 포함하는 두 개의 필드인 `SentimentLabel` 및 `SentimentScore`가 있습니다. Lambda 함수 를 사용하는 경우 해당 `sentimentResponse` 필드는 함수로 전송된 이벤트 데이터에 포함됩니다.
다음은 `PostText` 또는 `PostContent`응답의 일부로 반환된 `sentimentResponse` 필드의 예입니다. `SentimentScore` 필드는 응답에 대한 점수를 포함하는 문자열입니다.
```
{
"SentimentScore":
"{
Mixed: 0.030585512690246105,
Positive: 0.94992071056365967,
Neutral: 0.0141543131828308,
Negative: 0.00893945890665054
}",
"SentimentLabel": "POSITIVE"
}
```
Amazon Lex 는 사용자를 대신해 Amazon Comprehend 를 호출하여 봇이 처리하는 모든 표현에서 감정을 결정합니다. 감정 분석을 활성화하면 Amazon Comprehend 에 대한 서비스 약관 및 계약에 동의하게 됩니다. Amazon Comprehend 요금에 대한 내용은 [Amazon Comprehend 요금](https://aws.amazon.com/comprehend/pricing/)을 참조하세요.
Amazon Comprehend 감정 분석의 작동 방식에 대한 자세한 내용은 *Amazon Comprehend 개발자 가이드*의 [감정 파악](https://docs.aws.amazon.com/comprehend/latest/dg/how-sentiment.html)을 참조하십시오.
# Amazon Lex 리소스 태그 지정
Amazon Lex 봇, 봇 별칭 및 봇 채널을 관리하는 데 도움이 되도록 각 리소스에 *태그*로 메타데이터를 할당할 수 있습니다. 태그는 AWS 리소스에 할당하는 레이블입니다. 각 태그는 키와 값으로 구성됩니다.
태그를 사용하면 용도, 소유자 또는 애플리케이션을 기준으로 하는 등 AWS 리소스를 다양한 방식으로 분류할 수 있습니다. 태그를 통해 다음 작업을 수행할 수 있습니다.
+ AWS 리소스를 식별하고 구성합니다. 많은 AWS 리소스가 태그 지정을 지원하므로 서로 다른 서비스의 리소스에 동일한 태그를 할당하여 리소스가 관련이 있음을 나타낼 수 있습니다. 예를 들어, 봇과 봇이 사용하는 Lambda 함수에 동일한 태그를 지정할 수 있습니다.
+ 비용을 할당합니다. AWS 결제 및 비용 관리 대시보드에서 태그를 활성화합니다.는 태그를 AWS 사용하여 비용을 분류하고 월별 비용 할당 보고서를 제공합니다. Amazon Lex의 경우 `$LATEST` 별칭을 제외하고 별칭과 관련된 태그를 사용하여 각 별칭에 대한 비용을 할당할 수 있습니다. `$LATEST` 별칭에 대한 비용을 할당하는 데는 Amazon Lex 봇과 관련된 태그를 사용합니다. 자세한 내용은 *AWS 결제 및 비용 관리 사용 설명서*의 [ 비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)을 참조하세요.
+ 리소스에 대한 액세스를 제어합니다. Amazon Lex에 태그를 사용하여 Amazon Lex 리소스에 대한 액세스를 제어하는 정책을 생성할 수 있습니다. 이러한 정책을 IAM 역할 또는 사용자에 연결하여 태그 기반 액세스 제어를 활성화할 수 있습니다. 자세한 내용은 [Amazon Lex의 ABAC](security_iam_service-with-iam.md#security_iam_service-with-iam-tags)을 참조하세요. 리소스의 태그를 기반으로 리소스에 대한 액세스를 제한하는 자격 증명 기반 정책의 예시는 [태그를 사용하여 리소스 액세스](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-tag)에서 확인할 수 있습니다.
AWS Management Console AWS Command Line Interface, 또는 Amazon Lex API를 사용하여 태그로 작업할 수 있습니다.
## 리소스에 태그 지정
Amazon Lex 콘솔을 사용하는 경우 리소스를 생성할 때 리소스에 태그를 지정하거나 나중에 태그를 추가할 수 있습니다. 이 콘솔을 사용하여 기존 태그를 업데이트하거나 제거할 수도 있습니다.
AWS CLI 또는 Amazon Lex API를 사용하는 경우 다음 작업을 사용하여 리소스에 대한 태그를 관리합니다.
+ [ListTagsForResource](API_ListTagsForResource.md) – 리소스와 연결된 태그를 봅니다.
+ [PutBot](API_PutBot.md) 및 [PutBotAlias](API_PutBotAlias.md) – 봇 또는 봇 별칭을 생성할 때 태그를 적용합니다.
+ [TagResource](API_TagResource.md) – 기존 리소스에서 태그를 추가 및 수정합니다.
+ [UntagResource](API_UntagResource.md) – 리소스에서 태그를 제거합니다.
Amazon Lex의 다음 리소스는 태깅을 지원합니다.
+ 봇 - 다음과 같은 Amazon 리소스 이름(ARN)을 사용합니다.
+ `arn:${partition}:lex:${region}:${account}:bot:${bot-name}`
+ 봇 별칭 - 다음과 같은 ARN을 사용합니다.
+ `arn:${partition}:lex:${region}:${account}:bot:${bot-name}:${bot-alias}`
+ 봇 채널 - 다음과 같은 ARN을 사용합니다.
+ `arn:${partition}:lex:${region}:${account}:bot-channel:${bot-name}:${bot-alias}:${channel-name}`
## 태그 제한
Amazon Lex 리소스의 태그에 다음과 같은 기본 제한이 적용됩니다.
+ 최대 태그 수 - 50
+ 최대 키 길이 - 128자
+ 최대 값 길이 - 256자
+ 키 및 값에 사용할 수 있는 문자 - a-z, A-Z, 0-9, 스페이스 및 \$1 . : / = \$1 - @ 문자
+ 키와 값은 대/소문자를 구분합니다.
+ 키 접두사로 `aws:`를 사용하지 마십시오. AWS 전용입니다.
# 리소스에 태그 지정(콘솔)
콘솔을 사용하여 봇, 봇 별칭 또는 봇 채널 리소스의 태그를 관리할 수 있습니다. 리소스를 생성할 때 태그를 추가하거나 기존 리소스에서 태그를 추가, 수정 또는 제거할 수 있습니다.
**봇을 생성할 때 태그를 추가하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. **생성**을 선택하여 새 봇을 생성합니다.
1. **봇 생성** 페이지 하단에서 **태그**를 선택합니다.
1. **태그 추가**를 선택하고 하나 이상의 태그를 봇에 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.
**봇 별칭을 생성할 때 태그를 추가하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. 봇 별칭을 추가할 봇을 선택합니다.
1. **설정**을 선택합니다.
1. 별칭 이름을 추가하고 봇 버전을 선택한 다음 **태그 추가**를 선택합니다.
1. **태그 추가**를 선택하고 하나 이상의 태그를 봇 별칭에 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.
**봇 채널을 생성할 때 태그를 추가하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. 봇 채널을 추가할 봇을 선택합니다.
1. **채널**을 선택한 다음 추가할 채널을 선택합니다.
1. 봇 채널에 대한 세부 정보를 추가한 다음 **태그**를 선택합니다.
1. **태그 추가**를 선택하고 하나 이상의 태그를 봇 채널에 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.
**봇을 가져올 때 태그를 추가하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. **작업**을 선택한 다음 **가져오기**를 선택합니다.
1. 봇을 가져올 zip 파일을 선택합니다.
1. **태그**를 선택한 다음 **태그 추가**를 선택하고 하나 이상의 태그를 봇에 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.
**기존 봇에 대한 태그를 추가, 제거 또는 수정하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. 왼쪽 메뉴에서 **봇**을 선택한 다음 수정할 봇을 선택합니다.
1. **설정**을 선택한 다음 왼쪽 메뉴에서 **일반**을 선택합니다.
1. **태그**를 선택한 다음 봇에 대한 태그를 추가, 수정 또는 제거합니다.
**봇 별칭에 대한 태그를 추가, 제거 또는 수정하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. 왼쪽 메뉴에서 **봇**을 선택한 다음 수정할 봇을 선택합니다.
1. **설정**을 선택한 다음 왼쪽 메뉴에서 **별칭**을 선택합니다.
1. 수정할 별칭에 대한 **태그 관리**를 선택한 다음 봇 별칭에 대한 태그를 추가, 수정 또는 제거합니다.
**기존 봇 채널에 대한 태그를 추가, 제거 또는 수정하려면**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) Amazon Lex 콘솔을 엽니다.
1. 왼쪽 메뉴에서 **봇**을 선택한 다음 수정할 봇을 선택합니다.
1. **채널**을 선택합니다.
1. **태그**를 선택한 다음 봇 채널에 대한 태그를 추가, 수정 또는 제거합니다.
# 리소스에 태그 지정(AWS CLI)
AWS CLI 를 사용하여 봇, 봇 별칭 또는 봇 채널 리소스의 태그를 관리할 수 있습니다. 봇 또는 봇 별칭을 생성할 때 태그를 추가하거나 봇, 봇 별칭 또는 봇 채널의 태그를 추가, 수정 또는 제거할 수 있습니다.
모든 예제는 Linux와 macOS용입니다. Windows에서 명령을 사용하려면 Linux 줄 연속 문자(\$1)를 캐럿(^)으로 바꿉니다.
**봇을 생성할 때 태그를 추가하려면**
+ 다음 단축 `put-bot` AWS CLI 명령은 봇을 생성할 때 태그를 추가하는 데 사용해야 하는 파라미터를 보여줍니다. 실제로 봇을 생성하려면 다른 파라미터를 사용해야 합니다. 자세한 내용은 [4단계: 시작하기(AWS CLI)](gs-cli.md) 단원을 참조하십시오.
```
aws lex-models put-bot \
--tags '[{"key": "key1", "value": "value1"}, \
{"key": "key2", "value": "value2"}]'
```
**봇 별칭을 생성할 때 태그를 추가하려면**
+ 다음 단축 `put-bot-alias` AWS CLI 명령은 봇 별칭을 생성할 때 태그를 추가하는 데 사용해야 하는 파라미터를 보여줍니다. 실제로 봇 별칭을 생성하려면 다른 파라미터를 사용해야 합니다. 자세한 내용은 [연습 5: 별칭 만들기(AWS CLI)](gs-cli-create-alias.md) 단원을 참조하십시오.
```
aws lex-models put-bot \
--tags '[{"key": "key1", "value": "value1"}, \
{"key": "key2", "value": "value2"}]"
```
**리소스의 태그를 나열하려면**
+ `list-tags-for-resource` AWS CLI 명령을 사용하여 봇, 봇 별칭, 봇 채널과 연결된 리소스를 표시합니다.
```
aws lex-models list-tags-for-resource \
--resource-arn bot, bot alias, or bot channel ARN
```
**리소스에서 태그를 추가하거나 수정하려면**
+ `tag-resource` AWS CLI 명령을 사용하여 봇, 봇 별칭 또는 봇 채널을 추가하거나 수정합니다.
```
aws lex-models tag-resource \
--resource-arn bot, bot alias, or bot channel ARN \
--tags '[{"key": "key1", "value": "value1"}, \
{"key": "key2", "value": "value2"}]'
```
**리소스에서 태그 제거**
+ `untag-resource` AWS CLI 명령을 사용하여 봇, 봇 별칭 또는 봇 채널에서 태그를 제거합니다.
```
aws lex-models untag-resource \
--resource-arn bot, bot alias, or bot channel ARN \
--tag-keys '["key1", "key2"]'
```