챗봇을 통해 처리하려는 조직의 사용 사례를 식별했다고 가정해 보겠습니다. 당신은 익숙해졌습니다 아마존 렉스, 프로토타입을 만들고 봇과 몇 가지 시험적인 상호 작용을 했습니다. 전반적인 경험이 마음에 들었고 이제 프로덕션 환경에 봇을 배포하고 싶지만 Amazon Lex의 모범 사례가 확실하지 않습니다. 이 게시물에서는 Amazon Lex 봇을 개발 및 배포하기 위한 모범 사례를 검토하여 종단 간 봇 수명 주기를 간소화하고 운영을 최적화할 수 있도록 합니다.
우리는 이전의 계획, 설계 및 구성 단계를 다뤘습니다. 블로그 게시물. 계속하기 전에 봇과 매력적인 대화를 구축하는 데 도움이 되도록 이러한 게시물을 검토하는 것이 좋습니다. 봇을 처음 구성한 후에는 내부적으로 테스트하고 봇 정의를 반복해야 합니다. 이제 봇이 실시간 대화를 처리하는 프로덕션 환경(예: 콜 센터)에 배포할 준비가 되었습니다. 프로덕션 단계에서는 원하는 비즈니스 목표를 충족하는지 지속적으로 모니터링해야 합니다. 이 주기는 새로운 사용 사례 및 개선 사항을 추가할 때 반복됩니다.
봇 개발, 테스트, 배포 및 모니터링에 대한 모범 사례를 검토해 보겠습니다.
개발
봇을 개발할 때 다음 모범 사례를 고려하십시오.
- 코드를 통한 봇 스키마 관리 – Amazon Lex 콘솔은 봇을 설계 및 구성할 때 사용하기 쉬운 인터페이스를 제공하지만 설정을 복제하기 위해 수동 작업에 의존합니다. 이 단계를 단순화하기 위해 설계를 마친 후 봇 스키마를 코드로 변환하는 것이 좋습니다. 당신이 사용할 수있는 API or AWS 클라우드 포메이션 (참조 AWS CloudFormation으로 Amazon Lex V2 리소스 생성) 프로그래밍 방식으로 봇을 관리합니다.
- 봇 버전 관리가 포함된 체크포인트 봇 스키마 – 체크포인트는 애플리케이션을 마지막으로 알려진 안정 상태로 되돌리기 위해 자주 사용되는 일반적인 접근 방식입니다. Amazon Lex는 다음을 통해 이 기능을 제공합니다. 봇 버전 관리. 개발 프로세스의 각 마일스톤에서 새 버전을 사용하는 것이 좋습니다. 이를 통해 봇 정의를 점진적으로 변경할 수 있으며 예상대로 작동하지 않을 경우 되돌릴 수 있는 쉬운 방법을 제공합니다.
- 데이터 처리 요구 사항 식별 및 적절한 제어 구성 – Amazon Lex는 AWS를 따릅니다. 책임 분담 모델, 업계 규정 및 회사의 자체 데이터 개인 정보 보호 표준을 준수하기 위한 데이터 보호 지침이 포함되어 있습니다. 또한 Amazon Lex는 다음을 준수합니다. 규정 준수 프로그램 SOC, PCI 및 FedRAMP와 같은 Amazon Lex는 민감한 것으로 간주되는 슬롯을 난독화하는 기능을 제공합니다. 데이터 개인 정보 보호 요구 사항을 식별하고 봇에서 적절한 제어를 구성해야 합니다.
지원
봇을 정의한 후에는 봇을 테스트하여 의도한 대로 작동하고 올바르게 구성되었는지 확인해야 합니다. 예를 들어 다음과 같은 다른 서비스를 트리거할 수 있는 권한이 있어야 합니다. AWS 람다 기능. 또한 봇을 테스트하여 다양한 유형의 사용자 요청을 해석할 수 있는지 확인해야 합니다. 테스트를 위해 다음 모범 사례를 고려하십시오.
- 테스트 데이터 식별 – 봇 성능을 테스트하려면 관련 테스트 데이터를 수집해야 합니다. 테스트 데이터에는 특히 봇이 음성 입력을 이해해야 하는 IVR 사용 사례의 경우 봇과의 예상 사용자 대화에 대한 포괄적인 표현이 포함되어야 합니다. 테스트 데이터는 다양한 말하기 스타일과 억양을 다루어야 합니다. 이러한 테스트 데이터는 대상 고객 기반에 대한 경험 검증을 제공할 수 있습니다.
- 사용자 경험 측정항목 식별 – 대화 경험을 정의하는 것은 어려울 수 있습니다. 사용자가 봇과 상호작용할 수 있는 모든 다양한 방법을 예상하고 계획해야 합니다. 너무 규범적으로 들리지 않고 어떻게 발신자를 안내합니까? 발신자가 정확하지 않거나 불완전한 정보를 제공하는 경우 어떻게 복구합니까? 다양한 시나리오를 통해 대화를 관리하려면 다양한 말하기 스타일, 음향 조건 및 양식을 다루는 명확한 목표를 설정하고 추적할 수 있는 객관적인 지표를 식별해야 합니다. 예를 들어 객관적인 지표는 "대화의 90%는 사용자에게 두 번 미만의 재프롬프트를 재생해야 함"이고 주관적인 지표는 "대부분의 대화는 사용자에게 입력을 반복하도록 요청해서는 안 됩니다."입니다.
- 그 과정에서 사용자 경험 평가 – 경우에 따라 겉보기에 작은 변경이 사용자 경험에 큰 영향을 미칠 수 있습니다. 예를 들어, 계정 ID 슬롯 유형에 사용되는 정규식에 실수로 오타를 도입하여 봇이 사용자에게 다시 입력을 제공하라는 메시지를 다시 표시하는 상황을 생각해 보십시오. 사용자 경험을 평가하고 자동화된 테스트에 투자하여 주요 지표를 생성해야 합니다. 당신은 참조 할 수 있습니다 자동 음성 인식 서비스 평가 과 Amazon Connect 및 Amazon Lex로 정확도 및 회귀 테스트 주요 메트릭을 테스트하고 생성하는 방법에 대한 예.
전개
봇의 성능에 만족하면 봇을 배포하여 프로덕션 트래픽을 제공할 수 있습니다. 수명 주기 동안 봇을 반복하면서 배포를 반복하여 연속 프로세스가 되도록 하므로 오류 가능성을 줄이기 위해 간소화되고 자동화된 배포가 중요합니다. 배포에 대해 다음 모범 사례를 고려하십시오.
- 다중 계정 환경 사용 – AWS 권장 사항을 따라야 합니다. 다중 계정 환경 설정 조직에서 개발 단계와 프로덕션 단계에 대해 별도의 AWS 계정을 사용합니다. 다중 리전이 있는 경우 프로덕션을 위해 리전별로 별도의 AWS 계정도 사용해야 합니다. 단계마다 별도의 AWS 계정을 사용하면 AWS 리소스에 대한 보안, 액세스 및 청구 경계가 제공됩니다.
- 개발에서 생산까지 봇 홍보 자동화 – 개발 단계의 봇 설정을 프로덕션 단계로 복제할 때 자동화된 솔루션을 사용하고 수동 터치 포인트를 최소화해야 합니다. 봇을 생성하려면 CloudFormation 템플릿을 사용해야 합니다. 또는 다음을 사용할 수 있습니다. Amazon Lex 내보내기 및 가져오기 API 계정 간에 봇 스키마를 복사하는 자동화된 수단을 제공합니다.
- 단계적으로 변경 사항 롤아웃 – 변경 사항을 프로덕션 환경에 단계적으로 배포하여 모든 사용자에게 릴리스되기 전에 프로덕션 트래픽의 하위 집합에 변경 사항이 릴리스되도록 해야 합니다. 이러한 접근 방식은 변경에 문제가 있는 경우 폭발 반경을 제한할 수 있는 기회를 제공합니다. 이를 달성할 수 있는 한 가지 방법은 05단계 배포 접근 방식을 사용하는 것입니다. 봇에 대해 두 개의 별칭(예: prod-95 및 prod-05)을 만듭니다. 먼저 새 봇 버전을 하나의 별칭(이 예에서는 prod-95)과 연결합니다. 주요 지표가 성공 기준을 충족하는지 확인한 후 두 번째 별칭(prod-XNUMX)을 새 봇 버전과 연결합니다.
Amazon Lex 봇과 통합하는 데 사용되는 클라이언트 애플리케이션의 트래픽 분산을 제어해야 합니다. 예를 들어 아마존 연결 봇과 통합하기 위해 다음을 사용할 수 있습니다. 백분율로 배포 두 개 이상과 함께 접점 블록 고객 의견 얻기 블록.
Amazon Lex는 기본적으로 테스트 별칭을 제공합니다. 테스트 별칭은 Amazon Lex 콘솔을 통한 임시 수동 테스트에만 사용되며 프로덕션 규모의 로드를 처리하기 위한 것이 아닙니다. 프로덕션 트래픽에 전용 별칭을 사용하는 것이 좋습니다.
모니터링
모니터링은 안정성, 가용성 및 효과적인 최종 사용자 경험을 유지하는 데 중요합니다. 봇의 메트릭을 분석하고 학습을 피드백 메커니즘으로 사용하여 봇 스키마와 개발, 테스트 및 배포 방식을 개선해야 합니다. Amazon Lex는 다음과 같은 여러 메커니즘을 지원합니다. 모니터 봇. Lex 봇을 모니터링하기 위해 다음 모범 사례를 고려하십시오.
- 지속적으로 모니터링하고 반복 – Amazon Lex는 다음과 통합됩니다. 아마존 클라우드 워치 봇과 사용자의 상호 작용에 대한 주요 통찰력을 제공할 수 있는 거의 실시간 메트릭을 제공합니다. 이러한 통찰력은 최종 사용자 경험에 대한 관점을 얻는 데 도움이 될 수 있습니다. Amazon Lex가 내보내는 다양한 유형의 지표에 대해 자세히 알아보려면 다음을 참조하십시오. Amazon CloudWatch로 Amazon Lex V2 모니터링. 경보를 트리거하도록 임계값을 설정하는 것이 좋습니다. 마찬가지로 Amazon Lex는 봇과 사용자의 상호 작용에서 원시 입력 발언에 대한 가시성을 제공합니다. 당신은 사용해야합니다 발화 통계 or 대화 로그 커뮤니케이션 패턴을 식별하고 필요에 따라 봇을 적절하게 변경하기 위한 통찰력을 얻습니다. 봇에 대한 개인화된 분석 대시보드를 만드는 방법을 알아보려면 다음을 참조하십시오. Amazon Lex 챗봇에 대한 운영 지표 모니터링.
이 게시물에서 논의된 모범 사례는 주로 Amazon Lex 관련 사용 사례에 중점을 둡니다. 이 외에도 AWS에서 클라우드 인프라를 관리할 때 모범 사례를 검토하고 준수해야 합니다. 클라우드 인프라가 안전하고 승인된 사용자만 액세스할 수 있는지 확인하십시오. 또한 적절한 검토 및 채택 AWS 보안 모범 사례 조직 내에서. 마지막으로 적극적으로 검토해야 합니다. AWS 할당량 개별 AWS 서비스에 대해(Amazon Lex 할당량 포함) 필요한 경우 적절한 변경을 요청합니다.
결론
Amazon Lex를 사용하여 정교한 자연어 대화를 지원하고 고객 서비스 효율성을 높일 수 있습니다. 이 게시물에서는 봇 수명 주기의 개발, 테스트, 배포 및 모니터링 단계에 대한 모범 사례를 검토했습니다. 이러한 지침을 통해 최종 사용자 경험을 개선하고 더 나은 고객 참여를 달성할 수 있습니다. 지금 바로 Amazon Lex 대화 환경 구축을 시작하십시오!
저자에 관하여
스와 판딥 싱 Amazon Lex 팀의 엔지니어입니다. 그는 봇과의 상호 작용을 보다 부드럽고 인간처럼 만들기 위해 노력하고 있습니다. 그는 일 외에 여행을 하고 다른 문화에 대해 배우는 것을 좋아합니다.
