Dewu顧客サービスロボット多ラウンドSOPプロセスエンジン技術実習

1. ビジネスの背景

Dewu カスタマー サービス ロボットの自社開発の初期段階では、従来の 1 問 1 回答の FAQ ソリューションは比較的粗いものでした。相談ニーズに関しては、ユーザーを正確に問題解決に導くための差別化されたプロセスソリューションが存在せず、依然として多くのユーザーが問題解決のために手動のカスタマーサービスに依存しています。初期のマルチラウンド SOP エンジンは主にサードパーティのプラットフォームに依存していましたが、サードパーティの応答速度は比較的遅く、提供されるサービスはカスタマイズできず、プロセス構成の効率も比較的低かったです。ビジネスの急速な発展に伴い、複雑なシナリオを解決するロボットの能力を向上させ、手動の顧客サービスのコストを削減し、柔軟で視覚的なマルチラウンド SOP プロセス構成バックエンドを提供することが非常に必要です。 -ラウンドSOPプロセスエンジンの走行距離。

2. Duolun の紹介

ビジネス背景を理解した上で、顧客サービスの場面で Duolun についてあまり知らない人も多いと思いますが、ここでは実際のヒューマン マシンに基づいてロボットがどのように動作するかを紹介します。ダイアログ ユーザーの問題を複数回解決することに基づいています。

上記からもわかるように、ユーザー相談プロセスは質疑応答のプロセスに従って段階的に完了しており、この間、手動による顧客対応はありません。複数回の会話で、カスタマー サービス ボットがユーザーの問題を解決します。ここで疑問が生じるかもしれません。ロボットは何を尋ね、何を答えるべきかをどのようにして知るのでしょうか?実際には、これは意味認識でもアルゴリズム認識でもなく、複数ラウンドのプロセスを構成するための、構成背景に対応するビジュアル構成ページがあります。

3. 事前調査

要件を明確にした上で、ロボットの多段階SOPプロセスをどのような技術力で構築するのか、0から1で実装するのか、ベースで実装するのか。オープンソース フレームワークか? 直面する主な選択問題。もちろん0から1を実装するのがベストであり、多くの技術系学生にとって挑戦の機会でもありますが、当時の最大の課題はプロセス構築にCanvasキャンバスやグラフィック編集が含まれることでした。専門知識の背景がない場合、それは比較的難しいでしょう。それは比較的大規模であり、当時のビジネスの急速な発展と相まって、複数のラウンドの自己開発のカスタマイズ能力が緊急に必要でした。製品なので、それを実装するためにオープンソース フレームワークを選択しました。オープンソース フレームワークの調査では、以下のような多くのプロセス構成の実装にも言及しました。

• XX-Flowchart-Vue: フローチャートを実現できる vue ベースのフローチャート編集フレームワークただし、ビジネス シナリオのカスタム ノード スタイルには対応できません。
• vue-flowchart-editor: 複数のノード スタイルとシンプルなデータ構成機能を提供する vue ベースのフローチャート編集フレームワークです。カスタム ノードの場合は、次のような二次開発が必要です。ソース コード;
• アクティビティ: フロントエンド、バックエンド、およびデータ モデルを統合するプロセス エンジンの完全なセットである比較的完全なワークフロー ソリューション。使用する場合は、フロントエンドだけでなく、次のことを行う必要があります。ここでは二次開発が行われ、バックエンドも対応するサービスまたは二次設計と開発を展開する必要があります。コストは比較的高く、Activity で使用されるフロントエンド技術スタックは比較的古く、既存のシステムでは比較的古いものです。統合が難しいため、現在のビジネス シナリオには適していません。
• Flowable: ビジネス プロセス エンジン、主な開発言語は Java、使用する場合、バックエンドは完全なセットをデプロイする必要があります。プロセスエンジンサービス、フロントエンド側 主に修正連携、コストが比較的高く、現在のビジネスシナリオには不向き;
• X6: AntV のグラフ編集エンジンです。すぐに使える一連のインタラクティブなコンポーネントを提供し、使いやすいです。 ノードのカスタマイズ機能により、フローチャートやその他のグラフ アプリケーションを簡単に迅速に構築できます。

各フレームワークにはそれぞれ長所と短所があります。最終的に、二次開発用にグラフ編集エンジン antv-x6 を選択しました。主な理由は次のとおりです。オープンソース データ製品、コミュニティは比較的活発です。

はテクノロジー スタックとは無関係で、優れたスケーラビリティを備えています。
• はカスタム ノードをサポートし、高いカスタマイズ性を備えています。
• tools コンポーネントは比較的完成されており、すぐに使用できます
• 4. 技術アーキテクチャ

テクノロジの選択が明確になったら、次のステップは特定のテクノロジの実装です。マルチラウンド SOP プロセス エンジンは、フロントエンドの設計と実装を必要とするだけでなく、バックエンドの設計と実装なしでは実行できません。全体的なアーキテクチャ設計を次の図に示します。

##4.1 フロントエンド構成層

フロントエンド構成層には主に、マルチラウンド SOP ビジュアルプロセス構築、オンラインおよびオフライン管理、バージョン管理の 4 つの機能モジュールが含まれます。そしてインターフェース管理。

• SOP ビジュアル構築の複数ラウンド: 各ビジネス ノードのドラッグ アンド ドロップ操作とデータ構成を含み、さまざまなビジネス ノードの関連付けを通じて完全なプロセス構成を生成します。
• オンラインとオフライン管理: 良い製品を構築するため マルチラウンド SOP プロセスにはオンラインとオフラインの操作が必要です。オンラインのマルチラウンド プロセスで問題が発生した場合は、時間内にオフラインにする必要があります。
• バージョン管理: 構成された SOP プロセスが完了すると、マルチラウンド SOP プロセスはリリースされたばかりであり、プロセス ノードの応答スキルや機能は比較的基本的なものであり、オンライン ユーザーのプロセス データを通じてプロセス機能を継続的に改善する必要があります。各変更には、安定したオンラインを確保するためのアップグレード バージョンが必要です。継続的な最適化;
• インターフェイス管理: プロセスに関与する各ビジネス ノードは、異なるビジネス ドメインのサービスに依存します。たとえば、注文はトランザクション インターフェイスに依存する必要があります。物流はビジネスプロセス構成に関わるサプライチェーンインターフェースなどに依存する必要がある このような機能を実現するには、インターフェース構成を通じて実装する必要があります。

4.2 バックエンド サービス層

バックエンド サービス層の中核となるのはプロセス実行エンジン モジュールであり、実際のアプリケーション シナリオでは、最適なソリューションがマッチングされます。ユーザーが入力した質問に基づいてユーザーの問題を解決するプロセス。一致したプロセスを実行するプロセスでは、実行エンジンは最初にプロセスのコンテキストを作成します。ここで、コンテキスト情報は Redis キャッシュからロードされます。コンテキストに記録されたプロセスの実行ステータスに従って、次から決定されます。どのノードで実行を開始するか 実行後のコンテキストは情報の更新になります。プロセスの実行が終了すると、コンテキストは破棄されます。

4.3 アプリケーション層

アプリケーション層は主にマルチラウンド SOP プロセスの特定の使用シナリオであり、現在は Dewu 顧客サービス ロボットとエージェント支援 SOP の 2 つの使用シナリオが主に含まれています。

5. 技術的な課題

5.1 データ モデリング

データ モデリングを通じてノード間の関係の問題を解決します。

マルチラウンド SOP プロセスを視覚化するプロセスでは、キャンバス ノードの作成と接続が最も複雑です。一部のマルチラウンド シーンには 100 を超えるノードがあり、ノード間の関係は非常に重要です。キャンバスです。現在、ビジネス向けにカスタマイズされたノードには次の 4 種類があります:

##各ノードには独自のビジネス属性があります。ここでは、各ノードのビジネス属性と関連付け属性は、主にデータ モデリングの考え方を通じて抽象化されています。アイデアは次のとおりです。

#属性によって提供される元のデータ型は、カスタマイズされたビジネス データのニーズを十分に満たすことができます。 4 種類のビジネス ノードを分析した後、各ビジネス ノードは共通のデータ モデルを抽象化できます。その主なフィールドの意味は次のとおりです:

nodeName: ノードの名前

• nodeType: ノードのタイプ。スロット充填ノード、ジャンプ ノード、応答ノード、判定ノードの 4 つのノード タイプがあります。
• fromNodeId: ソース ノードの ID
• nextNodeId: ソース ノードの ID指しているノード
• fromEdgeIdList: ソースエッジ ID のリスト
• nextEdgeIdList: エッジ ID のリストを指している
• bizData: さまざまなビジネス ノードのビジネス属性情報
• ここでは ビジネス ノードとして bizData を使用します さまざまなビジネス ノードの属性データを格納するために使用される一般的なデータ モデル たとえば、スロット充填ノードにはスロットや異常などのビジネス属性があり、応答ノードには次のようなビジネス属性がありますcontentソートとコンテンツ。ビジネス ノードのデータ モデルを抽象化することにより、次の図に示すように、さまざまなノード間の関係を表現できます。
  • 判定ノードは、nextEdgeIdList 属性を通じてスロット充填ノードおよびジャンプ ノードに関連付けることができます;
  • 判定ノードは、fromNodeId 属性を通じて手動応答ノードに関連付けることができます;
  • 手動応答ノードに変換できますボトムアップ応答ノードは、nextNodeId を通じて関連付けられます;
  • ボトムアップ応答ノードは、fromEdgeIdList を通じて手動応答ノードに変換できます。

  さまざまなノードの関係がセマンティック属性を通じて表現された後、ノードとエッジの間の接続は、X6 が提供する addNode/addEdge メソッドに基づいて実現されるため、キャンバス内にノードがいくつあるかに関係なく、 、ノード間の接続は次のとおりです。関係は非常に明確です。

  5.2 RXJS

  RXJS イベント サブスクリプションと一方向データ フローを通じて、さまざまな機能モジュールのデータ フロー方向の問題を解決します。

  マルチラウンド SOP 視覚化バックエンドでは、ツールバー、キャンバスエリア、データ設定エリアの3つの異なる機能エリアがあり、各エリアの操作にはノードデータの変更が含まれます。明確なデータフローがないと、無秩序なデータ変更が発生し、潜在的なデータのリスクが発生します。保存時の混乱。ここでは、RXJS イベント サブスクリプションと一方向データ フローの設計パターンを採用しており、具体的な実装を次の図に示します。操作バーがイベントをトリガーします。たとえば、ノード操作を削除します。

  キャンバス領域で削除するノードを選択して、ノード データ削除イベントをトリガーします。

  データ フォーム構成領域ノードデータ削除イベントのデータを受信し、該当するノードデータを削除し、データメモリキャッシュに同期します;
  • 最終的にプロセスが送信されると、メモリ上のデータがサーバーデータベースに転送されます。
  • プロセス全体は、ノード データからフォーム データ、そしてキャッシュ データへと流れます。全体のフロー方向は一方向です。どのモジュールがトリガーされても、最終的なフロー方向はデータ メモリ キャッシュです。 。
  • データ フローに関しては、redux、vuex、dva など、現在多くのオープン ソース フレームワークが利用可能です。ここで RXJS が使用されるのはなぜですか?主な理由は、RXJS は比較的軽量であり、テクノロジー スタックとは何の関係もないため、その後のスケーラビリティが優れているためです。
  • 5.3 プロセス オーケストレーション

  プロセス オーケストレーション テクノロジを通じて、複雑なマルチラウンド プロセス構築の問題を解決します

  今年上半期の時点で、オンラインで 200 近くのプロセスが構築されています。やや複雑なマルチラウンドプロセス プロセスには 100 を超えるノードが含まれます 100 ノードを超える複雑なプロセスをノードごとに構成すると、構成効率が非常に低くなります。ここではプロセス オーケストレーション テクノロジが使用されます。

  プロセス オーケストレーションとは、視覚的なビジネス コンポーネントをドラッグ アンド ドロップすることでビジネス プロセスを配置し、プロセス エンジンがプロセスを実行することを指します。その標準化されたプロトコルは BPMN プロトコルであり、プロセス オーケストレーションにおけるさまざまなアイコンやコンポーネントの意味と使用仕様が含まれています。実際のアプリケーション シナリオでは、BPMN プロトコルを完全には使用しませんでしたが、BPMN プロトコルに従い、カスタマイズされたコンポーネントを作成しました。複雑なプロセスの場合は、さまざまなサブプロセスを通じてそれらを整理します。その考え方は次のとおりです:

  注文をキャンセルする複数ラウンドのプロセスの例を次に示します。

  

  上の図から明らかなように、複数ラウンドの注文キャンセル プロセスには 3 つのサブプロセスが含まれます。 ユーザー ID の決定サブプロセス、ユーザーアピールの決定サブプロセス、および注文のキャンセルサブプロセス。各サブプロセスは独立した完全なプロセスです。このように、3 つのサブプロセスを配置することで、注文キャンセルのための複雑な複数ラウンドのプロセスを構築できます。
  上記の 3 点は、自己研究の過程で直面する主な技術的課題ですが、実際には、数百のノードを数秒でレンダリングする方法や複雑な方法など、プロセスにはまだ多くの困難があります。ロジックの配置（コピー、カット）、複雑な判定ノードをワンクリックで展開・折りたたむ方法など、ここでは一つ一つ詳しく説明しません。

  6. ビジネス結果

  顧客サービス SOP プロセス エンジンの複数ラウンドの自己研究により、サードパーティ サービスが完全に置き換えられ、少なくとも数十万のアウトソーシング サービスが節約されるだけでなく、毎年コストがかかる一方、業績も向上し、高い成果を上げ、柔軟なカスタマイズを実現し、迅速な事業展開をサポートしています。発売以来、主に Dewu 顧客サービス ロボットとエージェント支援ロボットの 2 つのビジネス シナリオをカバーしてきましたが、そのうち Dewu ロボットには数百のマルチラウンド SOP プロセスがあり、エージェント支援ロボットには数十のマルチラウンド SOP プロセスがあります。顧客サービスの解決率が向上し、転送の人件費が削減されます。今年の 1 か月のデータを例に挙げると、オンライン化後、接客ロボットの解決率が大幅に向上し、SOP の解決率は FAQ の解決率と比較して 15% 以上増加しました。 FAQ受付件数の2倍となり、人件費を大幅に削減できます。

  7. まとめ

  接客ロボット多段SOPプロセスエンジンは、プロジェクト立ち上げからリリースまで約1ヶ月かかり、ゼロからのプロセスは投資家全員の共同作業の結果です。現在、マルチラウンドプロセスエンジンは、上記 2 つのシナリオに加えて、作業指示業務や品質検査業務での利用シーンも検討しており、現場向けに標準化されたサービスプロセスを提供するためのエージェント支援シナリオの充実も継続しています。顧客サービスと最前線の顧客サービスの向上 解決率。機能面では、引き続きプロセス エンジンの機能を向上させ、より多くのビジネス シナリオの使用をサポートし、業界のベンチマークとなるようプロセス エンジンの機能を継続的に向上させていきます。

以上がDewu顧客サービスロボット多ラウンドSOPプロセスエンジン技術実習の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。