Botpress 2022년 다이얼로그플로우 ES와 다이얼로그플로우 CX 비교 [1부]

다이얼로그플로우와 Botpress 를 비교하는 것은 어렵고 시간이 많이 걸립니다. 두 챗봇 제작 생태계 모두 수많은 기능과 다양한 작업 방식을 갖추고 있어 업계 종사자조차도 직접 비교하기가 까다롭습니다. 다음 프로젝트를 위해 두 가지 중 하나를 결정해야 하는 경우, 요구 사항에 따라 한 가지 방법 또는 다른 방법을 강요할 수 있는 실제 요소는 실제로 하나뿐입니다(Botpress 는 SaaS가 아니며 Dialogflow는 호스팅됩니다). 대부분의 경우 두 옵션 모두 합법적이라는 것을 알 수 있지만 선호하는 옵션을 찾을 수 있습니다.

Dialogflow 또는 Botpress 를 사용하여 봇을 구축하는 것이 어떤 것인지 이해하는 데 도움이 되도록 중요한 사항 목록을 작성하고 스크린샷을 찍어 실질적인 차이점을 시각화할 수 있도록 했습니다. 저는 플랫폼의 일반적인 편의성, 새로운 팀원 온보딩 및 작업, 일반적인 작업 수행 및 대규모 관리 등에 중점을 두었습니다.

어느 정도는 다이얼로그플로우를 선택하면 실제로는 구글 Cloud 플랫폼에 투자하는 것이므로 다이얼로그플로우 ES(필수 기능)와 CX(고객 경험)를 함께 그룹화했습니다. 또한 공정성을 기하기 위해 Botpress Enterprise와 비교하여 유료 솔루션에 대한 비교를 확실히 할 것입니다.

TLDR

순수한 FAQ 스타일 봇의 경우 Dialogflow ES로 충분합니다! 기능과 데이터를 완전히 제어하려면 Botpress 엔터프라이즈로 이동하여 자체 호스팅해야 합니다. 그렇지 않으면 Dialogflow CX 및 Botpress 대부분의 프로젝트를 잘 처리할 수 있으며 세 가지 모두 비슷한 언어 이해 기능을 갖추고 있습니다. Dialogflow CX는 전반적으로 약간 더 많은 기능을 가지고 있으며 Google의 세련미를 갖추고 있는 반면 Botpress 은 이해하고 작업하기가 더 쉽습니다. 가격은 다이얼로그플로우가 메시지당 가격이 책정되고(CX가 ES보다 훨씬 비쌉니다) Botpress의 가격 모델이 서비스 지향적이기 때문에 비교하기 어렵습니다.

차이점 비교표

‍

전체 비교

‍

버튼 및 선택 사항 추가하기

버튼, 선택 및 제안은 사용자가 어떤 옵션이 있는지 알 수 있고 원하는 것을 더 쉽게 선택할 수 있도록 해주기 때문에 훌륭합니다. 전화 통화에서도 옵션은 사용자가 메뉴를 탐색하는 데 도움이 될 수 있습니다. 버튼을 지원하지 않는 다른 텍스트 기반 플랫폼에서는 단축키를 사용하면 응답하기가 더 쉬워질 수 있습니다.

다이얼로그플로우 ES

• Dialogflow ES의 기본 응답 유형에는 버튼과 유사한 것이 포함되어 있지 않습니다!

• Slack과 같이 버튼과 같은 기능을 지원하는 플랫폼을 선택하면 해당 플랫폼에 기본으로 제공되는 응답 유형을 볼 수 있습니다. Slack에는 기본(플랫폼 없음) 옵션에는 없는 이미지, 카드 및 빠른 답장이 있습니다.

• 빠른 답장과 카드는 Slack에서 버튼을 쉽게 추가할 수 있는 방법입니다.

• 채팅 에뮬레이터에서 플랫폼별 미리 보기는 두 플랫폼의 차이점을 보여줍니다. 다이얼로그플로우 자체에서 이 기능을 사용하면 편리합니다.

• 링크나 텍스트를 쉽게 추가할 수 있습니다. 빠른 답장의 값은 텍스트와 동일합니다. 값은 자연어 이해 의도 감지에 사용됩니다.

• 응답을 처리하는 방법에는 두 가지가 있습니다. 첫 번째는 카드/빠른 답장에 사용된 것과 유사한 훈련 문구를 사용하여 인텐트를 만드는 것입니다. 다이얼로그플로우가 이를 포착하여 사용자를 응답으로 보냅니다.

• 두 번째 방법은 이후 수행되는 작업을 멋지게 표현하는 주문 처리를 사용하는 것입니다. 구체적으로, 주문 처리의 웹후크는 코드로 응답을 처리한다는 의미입니다.

• 안타깝게도 모든 주문 처리를 처리하려면 다른 페이지로 이동해야 합니다.

8 중 1

이 시점에서 사용자 정의 로직을 처리하려면 Google cloud 함수 또는 자체 서버를 사용해야 합니다. 통합 코드 편집기가 있지만 상당히 제한적입니다. 한두 가지 작업에는 유용하지만 전체 코드를 여기에 넣고 싶지는 않을 것입니다.

웹을 포함한 여러 플랫폼을 지원할 계획이라면 각 유형에 대한 응답을 만들어야 합니다. 장점은 깨질 가능성이 적다는 것입니다. 반면에 더 많은 반복 작업을 해야 한다는 단점이 있습니다. 플랫폼별 미리보기는 테스트에 유용합니다. 인텐트에서 인텐트로 이동하여 버튼을 클릭하면 실제로 어떤 일이 발생하는지 확인하기가 어렵습니다. 응답이 코드를 처리하는 경우, 무슨 일이 일어나고 있는지 일반적인 관점만 파악하는 것조차 어렵습니다.

다이얼로그플로우 CX

다이얼로그플로우 CX는 버튼을 유사하게 처리하는 동시에 다르게 처리합니다.

• 페이지에서 주문 처리를 편집해야 합니다. 이 페이지 내에서 발생하는 작업(대화에서 사용자의 위치)으로 생각하면 됩니다.

• 대화 상자 옵션을 추가하기 위한 메뉴입니다. 텍스트는 간단하지만 버튼에 대한 명확한 옵션이 없습니다.

• '사용자 정의 페이로드' 옵션은 버튼을 추가하려는 경우 필요한 옵션입니다. 직관적이지 않습니다.

• 예를 들어 버튼/칩을 추가하는 방법입니다. 문서를 탐색해야 합니다.

• 테스트 에이전트 버튼을 클릭하고 사용해 보면 다음과 같은 화면이 표시됩니다. 버튼도 없고, 다른 플랫폼에서 버튼이 어떻게 보이는지 확인할 방법도 없습니다. 별로 도움이 되지 않네요!

• 플로우를 테스트하려면 관리, 연동 서비스, 다이얼로그플로우 메신저의 연결 버튼으로 이동합니다.

• 활성화한 다음 완료를 클릭합니다.

• 미묘한 "지금 사용해보기" 버튼을 클릭한 다음 오른쪽 하단의 말풍선을 열고 쿼리를 시도해 보세요. 더 편리하게 사용해보고 싶다면 HTML 파일을 생성하고 제공된 코드를 추가해야 할 것 같습니다.

8 중 1

행운을 빕니다! UI는 이를 명확하게 보여주지 않으며, 답을 검색하면 코드 기반 솔루션과 Dialogflow ES에 대한 결과를 얻을 수 있습니다. 리치 응답은 강력하지만 어떤 이유에서인지 적절한 GUI 처리를 받지 못했습니다. 이것은 코딩 기반 솔루션으로 GUI에서 처리해야 합니다. 마지막으로, 에뮬레이터에서 테스트하는 것만으로는 Dialogflow ES와 같은 다른 플랫폼에서 어떻게 보이는지 또는 웹챗에서 어떻게 보이는지 알 수 없습니다.

Botpress v12

• 왼쪽 메뉴 손에서 선택 아이콘을 끌어다 놓습니다.

• 질문은 재사용할 수 있으므로 선택기가 있습니다.

• 질문과 답변 선택하기. 자유 텍스트 비활성화를 확인합니다. 물론 이 기능은 이를 허용하는 플랫폼에서만 작동합니다.

• 질문/답변 쌍을 만들거나 선택하면 다음과 같은 화면이 표시됩니다.

• 고급 섹션에서는 사용자가 일치하지 않는 답변을 작성하는 경우 정해진 횟수만큼 메시지를 표시할 수 있습니다.

• 플로우 편집기에서 선택의 결과를 쉽게 시각화하고 처리할 수 있습니다. 실패는 사용자가 최대 오답 수에 도달한 경우입니다.

• 사용자에게 선택을 강요하지 않고 단순히 제안만 하고 싶다면 최대 재시도 횟수를 0으로 설정한 다음 '실패 시'를 트리거하는 'User_failed_input' 요소에서 사용자 입력을 감지하세요.

7 중 1

Botpress 에서 필요한 선택을 하는 방법과 시각화하기 쉬운 방법을 알면 전반적으로 선택이 쉬워집니다. 제안을 제공하는 것은 직관적이지 않고 선택 스킬 기능을 계획에 없이 사용하는 것처럼 느껴집니다. 여러 플랫폼을 지원하려는 경우 버튼이 크로스 플랫폼이라는 사실은 시간을 절약할 수 있습니다.

비교

Botpress 는 제안을 표시하고 싶어도 선택 스킬을 사용해야 한다는 점에서 다소 직관적이지 않습니다. 사용자가 선택 사항 중 하나에 응답하도록 강제할 수 있는 유효성 검사가 장점입니다. 선택 스킬에서 제안 기능을 분리하면 이 작업을 더 쉽게 수행할 수 있습니다. Dialogflow ES는 다소 쉽습니다. 문제는 지원되는 모든 플랫폼에 대한 버튼 기능이 없다는 것입니다. 플랫폼별 탭을 열어서 시도해야 합니다. 찾기가 다소 어렵습니다. 다이얼로그플로우 CX는 버튼을 추가할 수 있는 GUI 기반 방법이 없는 것이 단점입니다. 모든 것이 코드로 더 나은 것은 아니며, 왜 이런 방식으로 진행했는지 이해하기 어렵습니다. Botpress 및 Dialogflow ES 모두 버튼을 추가하는 방법을 더 명확하게 만들 수 있지만 Botpress 편리한 크로스 플랫폼 버튼 및 유효성 검사를 제공하는 반면 Dialogflow ES는 제안을 훨씬 쉽게 할 수 있습니다.

버튼 누름 흐름 시각화

Botpress 이 가장 큰 장점입니다. 단일 맞춤 솔루션으로 버튼을 클릭한 후 어떤 일이 일어나는지 쉽게 확인할 수 있기 때문입니다. Dialogflow의 버튼은 편리한 링크 기능을 제공하지만 대화 흐름 측면에서 보면 시각화하기가 까다로울 수 있습니다. Dialogflow ES에는 Dialogflow CX나 Botpress 와 같은 시각적 흐름이 없기 때문에 이 또한 어렵습니다.

버튼 테스트

Botpress Botpress 는 모든 것이 비슷할 것으로 가정하여 하나의 일반 보기만 표시하고, Dialogflow는 모든 것이 다르다고 가정하여 각 버전을 개별적으로 표시합니다. 어떤 이유에서인지 Dialogflow CX는 기본 에뮬레이터도 표시하지 않고 대신 데이터를 표시하는 경로를 택한 것 같습니다. 이는 단일 플랫폼 용으로 개발할 때나 여러 플랫폼 용으로 개발할 때 모두 매우 불편합니다. CX가 단순히 ES의 업그레이드 버전이 아니라는 것을 보여주는 예입니다.

자연어 이해 기능

챗봇 제작사 솔루션은 종종 업계 최고 수준의 자연어 이해(NLU)를 자랑하지만, 이것이 대화 구축에 어떻게 적용될 수 있을까요? NLU를 사용할 계획이라면 두 가지 질문을 해야 합니다. X 언어를 지원하는가, 그리고 얼마나 잘 지원하는가?

NLU에는 일반적으로 두 가지 문제가 발생할 수 있습니다. 엔진이 감지하지 말아야 할 것을 감지하거나(오탐), 감지해야 할 것을 감지하지 못하는 경우(오탐). 실제로 이 두 가지 문제에 대한 해결책은 머신러닝 엔진에 더 많은 예제와 반대 예제를 제공하는 것입니다. 두 엔진의 벤치마크가 비슷할 경우, 정확도가 낮은 엔진의 정확도를 높이려면 에지 케이스를 커버할 수 있는 예문을 조금 더 추가해야 한다는 차이점이 있을 수 있습니다. 크런치하려는 주제에 따라 그렇지 않을 수도 있습니다.

Botpress 오픈 소스는 로컬에서 사용할 때 Dialogflow보다 적은 수의 언어 엔진을 제공합니다(기본 제공 12개). 12개 언어 중 하나가 아닌 다른 언어를 사용하려는 경우 NLU용 FastText 모델(언어 목록은 여기에서 확인할 수 있는 Facebook 오픈 소스)을 사용할 수도 있으며, 언어 모델을 조정해야 하는 경우 그렇게 할 수 있습니다. Google에서 데이터를 호스팅하는 것이 괜찮다면 NLU에 Dialogflow 엔진을 사용할 수도 있습니다. 둘 중 하나도 아닙니다. 두 플랫폼 모두 항상 이 부분을 개선하고 있습니다. Botpress 에서 NLU에 Dialogflow를 사용할 수 있으므로, 공정한 비교는 Botpress NLU가 할 수 있는 것과 Dialogflow NLU가 할 수 없는 것을 비교하는 것입니다.

인기 있는 언어로 된 NLU는 두 플랫폼에서 비슷하게 좋은 품질을 제공할 가능성이 높으며, 덜 인기 있는 언어는 더 문제가 될 수 있습니다.

즉, 히브리어 또는 아랍어 지원을 기대하는 경우 현재 Dialogflow ES는 해당 언어를 지원하지 않는다는 점에 유의하시기 바랍니다.

문장 요소 인식하기

일반적으로 자연어 이해는 의도 감지와 엔티티 인식이라는 두 가지 구성 요소로 나뉩니다. 의도는 문장으로, 엔티티는 이해하고자 하는 문장의 일부로 생각할 수 있습니다. 날짜, 시간, 위치는 엔티티입니다.

"6월 11일에 도쿄에서 뉴욕으로 가는 티켓 찾기"라는 문장을 예로 들어 설명해 보겠습니다. 인텐트는 항공권 구매이며, 문장 자체를 발화라고 합니다. 인텐트에는 일반적으로 머신 러닝 엔진에 공급할 많은 발화가 포함됩니다. 도쿄, 뉴욕, 6월 11일은 모두 엔티티입니다. 티켓은 엔티티가 아닌데, 이 문장 구조는 비행기 티켓이 아닌 다른 것에는 적용되지 않기 때문입니다. 하지만 "무언가를 구매하라"는 의도가 있다면 엔티티로 사용할 수 있습니다. 무엇을 추출할지는 사용자가 결정할 수 있습니다!

다이얼로그플로우와 Botpress 는 사용자 경험 변경 사항과 미리 준비된 옵션 등 거의 동일한 종류의 기능을 제공합니다.

다이얼로그플로우 ES

Dialogflow ES에서 엔티티를 만들려면 먼저 엔티티를 할당하거나 발화를 작성한 후에 엔티티를 추가할 수 있습니다.

• 인텐트의 발화에서 엔티티를 만들려면 원하는 부분(이 경우 #14147)을 강조 표시하기만 하면 팝업이 나타납니다.

• 기본으로 제공되는 기본 옵션이 많이 있습니다.

• 검색 결과가 비어 있는 경우 새로 만들기 버튼을 사용하면 편리합니다.

• "자동 확장 허용"을 사용하면 사용자가 "사과, 배, 바나나"와 같은 내용을 입력하면 NLU가 "오렌지"와도 일치시킬 수 있습니다.

• 엔티티를 정의한 후 발화를 만들면 Dialogflow가 자동으로 콘텐츠에 태그를 지정합니다. 이 경우 자동 태그 지정이 다소 과하게 이루어졌지만 태그를 추가하는 것보다 제거하는 것이 더 쉽기 때문에 문제가 없습니다.

5 중 1

다이얼로그플로우 CX

• 흥미롭게도 Dialogflow CX는 엔티티와 관련하여 Dialogflow ES를 따르지 않습니다. 새 엔티티 버튼이 없으므로 추가하려면 다른 곳으로 이동해야 합니다.

• 대신 인텐트 페이지 하단에 표시됩니다. '목록'을 사용하면 일련의 값(사과, 배, 바나나)을 입력할 수 있으며, '로그에서 삭제'는 개발자가 신용카드 번호와 같은 민감한 정보를 로그에서 숨길 수 있습니다.

• Dialogflow CX 엔티티 페이지에서 엔티티를 만들 수 있습니다. 이것은 기본적으로 Dialogflow ES와 동일하지만 순서가 다릅니다. 주요 예외는 고급에 있는 "로그에서 편집" 옵션입니다.

• 이는 다이얼로그플로우 CX만의 고유한 기능입니다.

4 중 1

퍼지 매칭과 자동으로 추가된 엔티티는 오탐지 문제를 일으킵니다. 예를 들어 사과, 배, 멜론과 같은 둥근 과일을 감지하고 해당 옵션을 선택하면 바나나도 둥글지 않음에도 불구하고 일치합니다. 엔티티 제외를 사용하여 이를 설명할 수 있지만, 둥글지 않은 모든 과일의 이름을 지정하는 것은 비현실적입니다. 마일리지는 달라집니다.

Botpress v12

• Botpress 에서 엔티티를 만드는 것은 매우 간단하지만 즉석에서 만들어지는 것은 아닙니다.

• 무언가를 강조 표시해도 Dialogflow ES처럼 새 태그를 만들 수 있는 옵션이 제공되지 않습니다. 적어도 키보드의 숫자(이 경우 0)를 눌러 모든 항목에 빠르게 태그를 지정할 수 있습니다.

• 무언가에 태그를 지정하려면 먼저 슬롯을 만들어야 합니다. 이것은 대화 흐름과는 다릅니다.

3 중 1

비교

엔티티는 누구에게나 추상적인 개념이며, 인텐트만큼 직관적인 개념을 제공하는 플랫폼은 없습니다. 사용자가 직접 검색하거나 문서/자습서에서 찾아야 합니다. 이는 개발자에게 매우 자주 요구되는 작업입니다. 주문 번호와 같은 많은 사용자 지정 엔티티에는 정규 표현식이 필요하기 때문입니다.

대화 흐름의 퍼지 매칭은 순서가 바뀐 단어도 퍼지 매칭하기 때문에 약간 더 강력해 보이지만, 언어에서 단어 순서가 바뀌는 것을 허용하지 않는 한 이 기능은 그다지 유용하지 않은 것 같습니다.

Dialogflow와 Botpress 의 실제 차이점은 자동 확장입니다. 동의어 목록을 제공해도 Dialogflow는 여전히 이해할 수 있습니다. 사과, 배, 바나나를 실체 예로 들어 "망고를 사고 싶어요"라는 문장과 쇼핑 목록이 주어졌을 때 Botpress 은 이를 올바르게 감지하지 못하지만 Dialogflow는 감지합니다. 예외를 더 추가하여 이 문제를 해결할 수 있지만 이는 더 많은 작업이 필요합니다. 또한 이제 과잉 감지의 위험이 있으므로 새로운 문제가 발생합니다. Dialogflow CX의 예외 필드는 이 문제를 처리하도록 설계되었습니다. 전반적으로 이 예외 필드는 선택 사항이므로 대화 흐름에 포함되는 것이 유리합니다.

일반 사용자에게는 기본 옵션이 가장 많고, 자동 확장 기능이 있으며, 태그 지정이 더 편리하다는 점에서 Dialogflow ES가 우위에 있습니다.

문장 내 엔티티 목록에서 승리하는 다이얼로그플로우 CX. Botpress 에서 이 작업을 수행할 수 있지만 훨씬 더 복잡합니다. 사용 사례에 따라 중요할 수도 있고 그렇지 않을 수도 있는 로그에서 정보를 숨기는 기능도 Dialogflow CX가 우위에 있지만, 이는 Botpress 을 완전히 제어할 수 있기 때문에 Dialogflow ES보다 우위에 있을 뿐입니다.

대화 흐름에서는 엔티티에 자동으로 태그가 지정되며, 사용자가 구분을 원할 경우 이름을 수정할 수 있습니다. 어떻게 보면 직관적이지 않을 수도 있지만, 처음 시작하는 사람에게는 걱정할 일이 하나 줄어듭니다. Botpress 에서는 사용자가 발화에 태그를 지정하기 전에 엔티티를 먼저 만들어야 합니다.

프로덕션 지원 배포 chatbots

Botpress 을 직접 호스팅해야 하고 Dialogflow가 이미 호스팅되어 있다고 말할 수도 있지만, 이는 올바른 그림이 아닙니다. 실제로 Botpress Enterprise는 호스팅 서비스를 제공하며, Dialogflow를 사용하여 배포해야 할 가능성이 높습니다. 왜 그럴까요? 왜냐하면 Dialogflow는 cloud 에서 완전히 실행할 수 있지만 사용자 지정 기능을 추가하려는 순간 해당 기능을 추천된 Google Cloud 또는 다른 곳에 직접 배포해야 하기 때문입니다.

다이얼로그플로우 ES

원격 데이터베이스에서 주문 정보를 가져오는 것과 같은 사용자 지정 기능을 추가하지 않는 한 코드 배포는 필요하지 않지만 봇 버전 배포는 여전히 수행해야 합니다(모두 cloud)에서 수행해야 합니다.

• 배포할 준비가 되면 설정으로 이동한 다음 '버전 게시'를 클릭합니다.

• 초기 릴리스 또는 v1.0과 같은 이름을 지정합니다.

• 환경을 "프로덕션"이라고 부를 수 있습니다. Cloud 기능 이행 옵션은 웹훅과 동일하지만 Google Cloud 과 통합되어 있습니다.

• 연동 페이지에서 원하는 연동 서비스를 선택한 다음 생성한 환경을 선택할 수 있습니다. 그게 다입니다!

4 중 1

사용자 정의 코드를 배포할 때 다른 플랫폼을 선택할 수 있지만 모든 문서에서는 Google Cloud의 서버리스 기능을 사용하도록 안내합니다. 이 API를 사용하여 코드를 배포하게 됩니다.

실제로 봇이 조금이라도 복잡하다면 API에 액세스하게 될 것이고, 그렇게 되면 사용자 지정 코드가 필요할 것입니다. 명령 하나로 코드를 업로드하는 간단한 작업이지만, 코드를 변경하기 전에 어떤 종류의 사용성 테스트를 수행하려면 Dialogflow ES에서 에이전트의 복사본을 만들어 테스트해야 할 가능성이 높습니다. 이 문제를 쉽게 해결할 수 있는 방법은 없습니다.

다이얼로그플로우 CS

이것은 Dialogflow ES와 매우 유사합니다.

• 먼저 환경용 버전을 만들어야 합니다.

• Dialogflow CX는 버전을 만든 후 Dialogflow ES와 거의 동일한 조직을 갖습니다. 환경(이 경우 프로덕션)을 만든 다음 통합으로 이동합니다.

• 통합 페이지에서 다시 한 번 프로덕션을 선택하여 배포할 수 있습니다. 사용자 지정 코드를 배포할 때 Dialogflow ES와 마찬가지로 다른 플랫폼을 선택할 수 있지만 모든 문서에서는 Google Cloud의 서버리스 기능을 사용하도록 안내합니다.

• 이것이 Dialogflow CX에서 함수에 연결하는 방법입니다. 다이얼로그플로우 ES에서와 같이 Google Cloud 함수에 대한 바로 가기는 없지만, 모두 동일하게 사용할 수 있습니다.↪CF_200D↩

Botpress v12

Botpress 배포는 일반적으로 사용자가 데이터 소유권을 유지하기 위해 수행하지만, 필요에 따라 Botpress 에서 호스팅을 호스팅하거나 호스팅을 지원할 수 있습니다. 이 글을 쓰는 시점에는 셀프 서비스 호스팅 기능이 없습니다. 사용자 지정 기능은 Botpress 인스턴스에 첨부되어 있으므로 Dialogflow를 통한 배포의 복잡성을 다소 줄여줍니다. 확장 가능한 배포를 위해서는 소프트웨어 호스팅에 정통한 소프트웨어 엔지니어가 필요하거나 Botpress 엔터프라이즈 서비스를 사용해야 합니다.

Botpress Enterprise에는 봇을 식별하여 초안에서 프로덕션으로 이동할 수 있는 파이프라인이 포함되어 있지만, 이를 위해서는 이미 프로덕션 준비 인스턴스가 실행 중이어야 합니다.

• Botpress 는 프로덕션 체크리스트를 제공하여 배포가 더 쉬워집니다.

• 함수는 Botpress 에 있으므로 모든 것을 함께 테스트할 수 있으며, 모든 것을 검토한 다음 프로덕션으로 이동할 수 있습니다.

연동 서비스에 연결하려면 설명서를 따라야 합니다. 대부분의 작업은 구성 파일에서 이루어지므로 개발자가 처리하거나 Botpress 엔터프라이즈 서비스에서 처리하는 것이 좋습니다.

비교

사용자 지정 코드가 필요하지 않다면 Dialogflow ES를 이길 수 없습니다. 직관적이고 빠르죠. 기능을 배포해야 하는 경우 추가 단계가 필요합니다. Dialogflow CX는 프로덕션 환경에 배포하기가 약간 더 어렵고(추가 단계가 하나 더 있고 오류 메시지가 덜 명확함), 사용자 지정 코드와 관련된 동일한 문제가 있습니다. Google Cloud 플랫폼 사용의 장점은 cloud 함수를 사용할 가능성이 높다는 것입니다. 가장 저렴한 코드 호스팅 방법은 아니지만 확장성이 뛰어난 함수를 가장 쉽게 만들 수 있는 방법입니다.

다이얼로그플로우에 함수를 배포하는 프로세스는 새 함수를 만들고, 호스팅하고, 링크를 가져와 다이얼로그플로우 웹훅/이행에서 업데이트하고, 새 버전을 테스트하여 작동하는지 확인하고, 작동한다면 새 버전을 배포하는 순서로 진행됩니다. 처음에는 너무 힘들지 않겠지만 대화 로직에 맞게 코드를 자주 업데이트해야 한다고 생각한다면 복잡성이 한 층 더 추가되는 것입니다. Botpress 에서는 코드와 대화 로직이 동일한 세계에 존재하므로 업데이트, 테스트 및 배포가 훨씬 쉽습니다. 단점은 개발자가 Nodejs를 사용해야 하므로 익숙하지 않은 경우 이전에 사용했던 것에 따라 학습 곡선이 있다는 것입니다. 장점은 라이브러리가 하나뿐이기 때문에 이론적으로는 문서가 더 최신 상태여야 한다는 것입니다.

사용자 정의 코드가 아니었다면 Botpress 이 카테고리에서 최악일 것입니다. 실제로 호스팅을 해야 하기 때문입니다. Botpress 은 배포 서비스를 제공하므로 기술적으로는 아무것도 할 필요가 없지만 셀프 서비스 모델만큼 편리하지는 않습니다. 사용자 지정 코드는 Dialogflow가 제공하는 이점을 무효화합니다.

직접 호스팅하면 확장 관리 문제가 있습니다. 물론 프로젝트에 외부 서비스를 포함할 수 없다면 Botpress 을 사용하는 것이 좋습니다. Botpress 에는 오픈 소스 버전의 배포에 대한 문서가 있지만 Dialogflow를 사용할 때와 같이 완전한 자동 확장 아키텍처는 아닙니다.

여기까지입니다. 다음은 Botpress 대 Dialogflow ES 대 Dialogflow CX의 2부입니다.