Botpress vs 對話流 ES vs 對話流 CX 在 2022 年 [第一部分]

比較對話流和 Botpress 令人望而生畏，時間很傻。這兩個聊天機器人製作生態系統都有無數的功能和不同的做事方式，即使對於業內人士來說，面對面的比較也很棘手。如果你在下一個專案中在兩者之間做出決定，實際上只有一個真正的因素可以迫使你以一種或另一種方式，這取決於你的要求（Botpress 不是 SaaS，並且託管了 Dialogflow）。在大多數情況下，您會發現這兩個選項都是合法的，但您可能會找到偏好。

幫助您瞭解使用 Dialogflow 或 Botpress，我列出了要點並截取了屏幕截圖，以便您可以可視化實際差異。我專注於：平臺的一般易用性，入職和與新團隊成員合作，執行常見操作和大規模管理。

重要的是要注意，在某種程度上，當你選擇Dialogflow時，你真正在做的是投資谷歌。 Cloud 平臺，所以我將Dialogflow ES（基本要素）和CX（客戶體驗）組合在一起。另外，公平地說，我將與 Botpress 企業，以確保比較是針對付費解決方案的。

TLDR

對於一個純粹的FAQ風格的機器人，Dialogflow ES將完成這項工作！要完全控制您的功能和數據，您需要轉到 Botpress 企業和自託管。否則，對話流 CX 和 Botpress 可以很好地處理大多數項目，並且這三者都具有相似的語言理解能力。Dialogflow CX具有總體上更多的功能，並具有谷歌拋光，而 Botpress 更容易理解和工作。定價很難比較，因為對話流是按消息定價的（CX比ES貴得多），並且 Botpress的定價模式更加以服務為導向。

差異比較表

‍

完整比較

‍

添加按鈕和選項

按鈕、選擇和建議非常棒，因為它們允許使用者知道選項是什麼，並讓他們更容易選擇他們想要的東西。即使在電話呼叫中，選項也可以説明用戶瀏覽功能表。在其他不支援按鈕的基於文本的平臺上，速記可以更容易回答。

對話流ES

• 對話流ES上的預設回應類型不包含任何類似於按鈕的內容！

• 當你選擇支援類似按鈕的功能的平臺（如 Slack）時，可以看到它的內置回應類型。Slack 具有預設（無平台）選項所沒有的圖像、卡片和快速回復。

• 快速回復和卡片是在 Slack 中添加按鈕的簡單方法。

• 在聊天模擬器中，特定於平臺的預覽顯示兩者之間的差異。在對話流本身中使用它很方便。

• 您可以輕鬆新增連結或文字。快速回復的值等於文本。值用於自然語言理解意圖檢測。

• 有兩種處理回應的方法。第一種是使用類似於卡片/快速回復中使用的訓練短語創建意圖。對話流捕獲它並將用戶發送到回應。

• 第二種方法是使用履行，這是一種說事後執行的操作的奇特方式。具體來說，Fulfillment的webhooks只是意味著：用代碼處理回應。

• 不幸的是，您必須轉到其他頁面來處理所有履行。

1 的 8

此時，您必須使用谷歌 cloud 函數，或您自己的伺服器來處理自定義邏輯。有一個集成的代碼編輯器，但它非常有限。它會在緊要關頭完成一兩個操作，但你不想在這裡擁有你的整個代碼。

如果您計劃支援多個平臺（包括 Web），則必須為每種類型創建回應。好處是這不太可能破裂。另一方面，你會有更多的重複工作。特定於平台的預覽非常適合測試。很難從一個意圖到另一個意圖，看看點擊一個按鈕到底做了什麼。如果回應處理代碼，也很難看到正在發生的事情，即使只是為了大致瞭解正在發生的事情。

對話流 CX

對話流CX同時以相似和不同的方式處理按鈕。

• 在頁面中，您需要編輯發貨。將其視為此頁面中發生的操作（用戶在對話中的位置）。

• 用於添加對話框選項的功能表。文本很簡單，但沒有明確的按鈕選項。

• 如果要添加按鈕，則需要「自定義有效負載」選項。這不是很直觀。

• 例如，這就是您添加按鈕/晶元的方式。您將需要瀏覽文件。

• 如果按一下測試代理按鈕並嘗試一下，則會得到如下所示的內容。沒有按鈕，無法看到按鈕在不同平臺上的外觀。不是很有説明！

• 要測試您的流，請轉到管理，然後是集成，然後是Dialogflow Messenger的連接按鈕。

• 啟用，然後按下完成

• 按兩下微妙的「立即嘗試」按鈕，然後打開右下角的聊天氣泡並嘗試您的查詢。似乎如果您想更方便地試用它，則需要創建一個 html 檔並添加他們為您提供的代碼。

1 的 8

祝你好運，弄清楚這個！UI 不會使這一點變得明顯，搜索答案將生成基於代碼的解決方案和對話流ES的結果。豐富的回應很強大，但由於某種原因沒有得到適當的 GUI 處理。這是一個基於編碼的解決方案，您被迫在 gui 中處理。最後，在模擬器中對此進行測試不會向您顯示它在Dialogflow ES等不同平臺上的外觀，或者它在網上聊天中的外觀。

Botpress V12版本

• 從左側功能表手，拖放選擇圖示。

• 問題可以重複使用，因此有一個選擇器

• 選擇問題和答案。請注意禁用自由文本。當然，這僅適用於允許它的平臺。

• 創建或選擇問題/答案對後，您將看到。

• 高級部分允許您在用戶編寫不匹配的答案時給出提示的次數。

• 在流編輯器中，您可以輕鬆可視化和處理選擇的結果。失敗時是指用戶達到最大數量的錯誤回應。

• 如果您不想強迫使用者做出選擇，而只是給他們建議，請將最大重試次數設置為 0，然後在觸發“失敗時”的“User_failed_input”元素中檢測用戶輸入。

1 的 7

總體上做出所需的選擇很容易 Botpress 一旦你知道怎麼做，很容易可視化。提供建議不太直觀，感覺就像是對選擇技能功能的意外使用。如果您計劃支援多個平臺，按鈕是跨平台的事實可以節省您的時間。

比較

Botpress 在這裡有些不直觀，因為即使你想顯示建議，你也需要使用選擇技能。優點是驗證;您可以強制使用者回應其中一個選項。將建議功能與選擇技能分開可能有助於簡化此操作。對話流ES稍微容易一些。問題是沒有適用於所有支援平臺的按鈕功能。您需要開啟特定於平台的選項卡才能嘗試。這有點難找。Dialogflow CX是這裡的失敗者，沒有基於GUI的添加按鈕的方式。並非所有事情都比代碼更好，而且很難理解他們為什麼這樣做。而 Botpress 和對話流ES都可以更清楚地說明如何添加按鈕， Botpress 提供方便的跨平臺按鈕和驗證，而Dialogflow ES使提出建議變得更加容易。

按鈕按程可視化

Botpress 把蛋糕帶到這裡。因為它的單一適合解決方案可以輕鬆查看按鍵後會發生什麼。對話流的按鈕提供了方便的連結功能，但就對話流而言，這可能很難可視化。Dialogflow ES 沒有像 Dialogflow CX 或 Dialogflow CX 這樣的視覺流 Botpress，所以這也很難。

測試按鈕

Botpress 和對話流 ES 在模擬器中具有相反的策略。 Botpress 假設所有內容都相似，因此僅顯示一個常規視圖，而 Dialogflow 假定所有內容都不同，並分別顯示每個版本。出於某種原因，Dialogflow CX似乎已經走上了預設模擬器也不顯示您的路徑，而是向您顯示數據。無論是在為單個平臺還是多個平臺進行開發時，這都是非常不方便的。這是CX不僅僅是ES升級版本的一個例子。

自然語言理解能力

聊天機器人製造商解決方案通常擁有行業領先的NLU（自然語言理解），但這如何轉化為對話構建？如果您打算使用它，您應該詢問兩個關於 NLU 的問題。它是否支援 X 語言，它支援它的程度如何？

NLU 通常有兩件事可能會出錯。引擎在不應該檢測時檢測到某些內容（誤報），或者在應該檢測時不檢測到某些內容（漏報）。在實踐中，這兩個問題的解決方案是給機器學習引擎更多的例子和反例。當兩個引擎具有相似的基準測試時，不同之處在於您可能必須添加更多例句來涵蓋不太準確的引擎的邊緣情況，以使其同樣準確。甚至可能不是這種情況，具體取決於您要處理的主題。

Botpress 在本地使用時，開源提供的語言引擎比 Dialogflow 少（開箱即用 12 個）。如果你想使用一種不是12種語言之一的語言，你也可以為NLU使用FastText模型（Facebook開源，語言清單在這裡找到），如果你需要調整你的 語言模型，你可以這樣做。你也可以使用Dialogflow引擎作為NLU，如果你同意谷歌託管你的數據。這不是非此即彼。這兩個平臺都在改進這一點。因為 Botpress 可以使用 Dialogflow for NLU，公平的比較是可以 Botpress NLU做Dialogflow NLU做不到的事情。

流行語言的NLU在兩個平臺上可能具有類似的高品質，而不太流行的語言將更加麻煩。

話雖如此，如果您期望希伯來語或阿拉伯文支援，請注意，目前，Dialogflow ES 不支援這些語言。

識別句子元素

通常，自然語言理解分為兩個元件：意圖檢測和實體識別。您可以將意圖視為句子，將實體視為您希望理解的句子的一部分。日期、時間和位置是實體。

以這句話為例來說明：「找6月11日從東京到紐約的車票」。。意圖是購買機票，句子本身稱為話語。意向通常具有許多語句來饋送機器學習引擎。東京、紐約和 6 月 11 日都是實體。機票不是一個實體，因為這種句子結構不適用於機票以外的其他東西。但是，如果您有「購買東西」的意圖，則可以將其作為一個實體。由您決定要提取的內容！

對話流和 Botpress 具有或多或少相同類型的功能，具有用戶體驗更改和現成的選項。

對話流ES

若要在對話流 ES 中創建實體，可以先分配實體，也可以在編寫語句后添加實體。

• 若要從意向的話語創建實體，只需突出顯示所需的部分（在本例中為 #14147），就會出現一個彈出視窗。

• 有很多開箱即用的預設選項。

• 當您的搜索顯示為空時，創建新按鈕很方便。

• “允許自動擴展”允許用戶編寫“蘋果，梨，香蕉”之類的內容，NLU也可以匹配“柳丁”。

• 定義實體並在創建語句后，對話流將自動標記內容。在這種情況下，自動標記有點過於熱心，但刪除標籤比添加標籤更容易，所以一切都很好。

1 的 5

對話流 CX

• 有趣的是，Dialogflow CX在實體方面並不遵循Dialogflow ES。缺少新實體按鈕，因此您必須轉到其他地方才能添加它。

• 相反，您可以在意向頁面的底部看到它。“is清單”允許您輸入一系列值（蘋果，梨和香蕉），而“日誌中的編輯”是開發人員在其日誌中隱藏信用卡號等敏感資訊。

• 在對話流 CX 實體頁面中，您可以創建實體。這基本上與 Dialogflow ES 相同，但順序不同。主要的例外是高級中找到的「日誌中的編輯」選項。

• 這是Dialogflow CX獨有的功能。

1 的 4

模糊匹配和自動添加的實體會導致誤報問題。例如，如果要檢測蘋果、梨和甜瓜等圓形水果並選擇該選項，香蕉也會匹配，儘管它不是圓形的。實體排除可用於解釋這一點，儘管命名所有非圓形水果是不切實際的。您的里程會有所不同。

Botpress V12版本

• 在中創建實體 Botpress 很簡單，但不是即時完成的。

• 突出顯示某些內容不會像 Dialogflow ES 那樣為您提供創建新標記的選項。至少您可以按鍵盤上的數位（在本例中為 0），以便快速標記所有內容。

• 如果要標記某些內容，則需要先創建一個插槽。這與對話流不同。

1 的 3

比較

實體對每個人來說都是抽象的，沒有平臺像意圖一樣直觀地成為概念。使用者需要自己搜索，或在文檔/教程中發現它。這是一個經常需要開發人員的操作。這是因為許多自定義實體（如訂單號）都需要正則表達式。

Dialogflow 中的模糊匹配似乎功能稍微強大一些，因為它也模糊匹配重新排序的單詞，但除非語言允許對單詞重新排序，否則這似乎不是很有用。

對話流和 Botpress 是自動擴展。您可以提供同義詞清單，對話流仍然能夠理解。給定一個購物清單：蘋果，梨，香蕉，作為實體示例和句子「我想買芒果」， Botpress 不會正確檢測到它，而對話流可以。您可以通過添加更多異常來解決此問題，但這需要更多的工作。這也會產生一個新問題，因為您現在冒著過度檢測的風險。對話流 CX 中的異常欄位旨在處理此問題。總體而言，由於此可選，因此它的包含有利於對話流。

對於普通用戶來說，Dialogflow ES 因擁有最預設的選項、自動擴展和更方便的標記而勝出。

對話流CX，在實體的句子內清單中獲勝。您可以在 Botpress 但它要複雜得多。Dialogflow CX還以其從日誌中隱藏資訊的功能而獲勝，這可能很重要，也可能不重要，具體取決於您的用例，但這只是對Dialogflow ES的勝利，因為您可以完全控制 Botpress.

在對話流中，會自動標記實體，如果使用者想要區分，可以修改名稱。不知何故，這同時越來越不直觀，但對於剛開始的人來說，這少了一件需要擔心的事情。在 Botpress，則必須先創建實體，然後使用者才能在語句中標記它們。

部署生產就緒型 chatbots

你可以說 Botpress 必須自己託管，並且對話流已經為您託管，但這不會描繪正確的畫面。在實踐中， Botpress 企業提供託管服務，您可能需要使用 Dialogflow 進行一些部署。為什麼？因為雖然對話流可以完全從 cloud，當您想要添加自定義功能時，您必須在建議的Google上自行部署該功能 Cloud 或其他地方。

對話流ES

只要您不添加自定義功能（例如從遠端資料庫獲取訂單資訊），就不需要代碼部署，但仍有機器人版本部署要做（全部在 cloud).

• 準備好部署後，轉到設置，然後按兩下發布版本。

• 為其命名，例如初始版本或 v1.0。

• 您可以將環境稱為“生產”。這 Cloud 功能實現選項與Webhook相同，但與Google集成 Cloud.

• 在「集成」頁中，選擇所需的集成，然後選擇創建的環境。就是這樣！

1 的 4

要部署自定義代碼，您可以選擇其他平臺，但所有文檔都將指向使用 Google Cloud的無伺服器功能。您將使用此 API 來部署代碼。

實際上，如果您的機器人有點複雜，它將訪問 API，如果這樣做，您將需要自定義代碼。雖然這隻是完成的（使用一個命令上傳代碼），但如果您想在更改代碼之前進行任何類型的可用性測試，那麼您可能必須在 Dialogflow ES 中創建代理的副本進行測試。沒有簡單的方法可以解決這個問題。

對話流 CS

這與Dialogflow ES非常相似。

• 您需要先為環境創建一個版本。

• 創建版本後，Dialogflow CX的組織結構與Dialogflow ES幾乎相同。創建一個環境（在本例中為“生產”），然後導航到“集成”。

• 在“集成”頁中，可以再次選擇要部署的生產。與Dialogflow ES一樣，對於部署自定義代碼，您可以選擇另一個平臺，但所有文檔都將指向使用Google。 Cloud的無伺服器功能。

• 這就是您在對話流CX中連結到函數的方式。谷歌沒有捷徑 Cloud 函數類似於在對話流ES中，但您可以使用所有相同的功能。‍

Botpress V12版本

部署 Botpress 通常由使用者完成以維護數據擁有權，但是 Botpress 可以根據您的需求出租或説明出租。在撰寫本文時，沒有自助服務託管功能。自訂功能附加到 Botpress 實例，因此這在一定程度上降低了通過對話流進行部署的複雜性。對於可擴展的部署，您將需要精通託管軟體的軟體工程師，或者使用 Botpress 企業服務。

Botpress 企業版確實包含管道，可用於識別機器人並將其從草稿移動到生產環境，但這要求你已經託管了正在運行的生產就緒實例。

• Botpress 提供生產清單，使部署更容易。

• 由於函數存在於 Botpress，所有內容都可以一起測試，您可以將所有內容移至審核，然後進行生產。

要連接集成，您必須遵循文檔。大部分工作都是在配置檔中完成的，因此您需要開發人員來處理它，或者 Botpress 企業服務。

比較

如果您不需要任何自定義代碼，則很難擊敗對話流ES。它直觀且快速。如果您確實需要部署函數，則最終將獲得一個額外的步驟。Dialogflow CX 部署到生產環境稍微困難一些（一個額外的步驟，以及不太明顯的錯誤消息），並且與自定義代碼存在相同的問題。使用谷歌的好處 Cloud 平臺是您可能使用的 cloud 功能。雖然它們不是託管代碼的最便宜的方式，但它們是擁有高度可擴展功能的最簡單方法。

為 Dialogflow 部署函數的過程是創建一個新函數，託管它，獲取連結，在 Dialogflow webhook / 實現中更新它，測試新版本以確保它正常工作，如果是這樣，則部署新版本。第一次，它應該不會太痛苦，但如果你認為你會經常更新你的代碼以匹配你的對話邏輯，你就增加了一層額外的複雜性。在 Botpress，代碼和對話邏輯存在於同一個世界中，因此更新、測試和部署要容易得多。缺點是開發人員必須使用 Nodejs，所以如果他們不熟悉它，就會有一個學習曲線，這取決於他們以前使用的內容。這樣做的好處是，理論上文檔應該是最新的，因為只有一個庫。

如果沒有自定義代碼， Botpress 將是此類別中最糟糕的，因為您實際上必須託管一些東西，而不是不託管。而 Botpress 提供部署服務，因此從技術上講，您不必執行任何操作，它永遠不會像自助服務模型那樣方便。自定義代碼否定了這賦予對話流的優勢。

託管自己存在管理縮放的問題。當然，如果您的專案不能包含外部服務，那麼 Botpress 顯然是要走的路。 Botpress 確實有關於其開源版本的 部署的文檔 ，但它不是一個完整的自動擴展架構，就像您使用 Dialogflow 一樣。

這部分就是這樣。這是第2部分Botpress vs Dialogflow ES vs Dialogflow CX。