Dewu 고객 서비스 로봇 다단계 SOP 프로세스 엔진 기술 실습

1. 사업 배경

Dewu 고객 서비스 로봇의 자체 개발 초기에는 기존의 일문일답 FAQ 솔루션이 실제 비즈니스 시나리오에서 사용자를 만나기가 점점 어려워졌습니다. 표준화된 프로세스 솔루션은 사용자에게 문제 해결을 정확하게 안내하지만, 여전히 많은 사용자가 문제 해결을 위해 수동 고객 서비스에 의존하고 있습니다. 초기 다중 라운드 SOP 엔진은 주로 타사 플랫폼에 의존했습니다. 타사의 응답 속도는 상대적으로 느리고 제공되는 서비스는 사용자 정의할 수 없으며 프로세스 구성의 효율성이 상대적으로 낮았습니다. 비즈니스의 급속한 발전에 따라 복잡한 시나리오를 해결하는 로봇의 능력을 향상시키고 수동 고객 서비스 비용을 절감하며 유연한 시각적 다단계 SOP 프로세스 구성 백엔드를 제공하는 것이 매우 필요합니다. 이를 통해 자체 개발된 멀티가 시작되었습니다. - 마일리지의 라운드 SOP 프로세스 엔진.

2. 다중 바퀴 소개

사업 배경을 이해한 후에도 많은 사람들이 고객 서비스 시나리오에서 다중 바퀴에 대해 잘 알지 못할 수 있습니다. 여기서는 실제 인간-기계 대화를 결합하여 로봇이 사용자 문제를 해결하는 방법을 소개합니다. 다중 바퀴를 기반으로합니다.

위에서 볼 수 있듯이 사용자 상담 프로세스는 질의응답 프로세스에 따라 단계별로 완료됩니다. 이 기간 동안 고객 서비스는 수동으로 개입하지 않습니다. 로봇이 사용자의 문제를 해결했습니다. 그렇다면 여기에 질문이 있을 수 있습니다. 로봇은 무엇을 묻고 무엇에 대답해야 할지 어떻게 알 수 있습니까? 실제로 의미론적 인식도 ​​아니고 알고리즘 인식도 아닙니다. 구성 배경에는 여러 라운드의 프로세스를 구성하는 해당 시각적 구성 페이지가 있습니다.

3. 예비 연구

요구 사항을 명확히 한 후 로봇의 다단계 SOP 프로세스를 구축하려면 어떤 종류의 기술적 역량을 사용해야 합니까? 아니면 오픈 소스 프레임워크를 기반으로 구현할 것인지가 주요 선택이었습니다. 당시 직면한 문제. 물론 0부터 1까지 구현하는 것이 가장 좋고, 많은 기술학생들이 도전할 수 있는 기회이기도 합니다. 그러나 당시 직면한 가장 큰 문제는 프로세스 구축에 캔버스 캔버스와 그래픽 편집이 포함된다는 점이었습니다. 전문 지식이 없으면 비교적 어려울 것입니다. 상대적으로 규모가 크고 당시 사업의 급속한 발전과 함께 여러 차례의 자체 개발을 맞춤화할 수 있는 능력이 절실히 필요했습니다. 그래서 이를 구현하기 위해 오픈 소스 프레임워크를 선택했습니다. 오픈 소스 프레임워크를 조사하면서 우리는 다음과 같은 다양한 프로세스 구성의 구현을 참조했습니다.

• 비즈니스 시나리오의 사용자 정의 노드 스타일
• vue-flowchart-editor: 다음을 제공하는 vue 기반 흐름도 편집 프레임워크; 여러 노드 스타일 및 간단한 데이터 구성 기능. 사용자 정의 노드에는 소스 코드를 기반으로 한 보조 개발이 필요합니다.
• 액티비티: 프론트엔드, 백엔드 및 데이터 모델을 통합하는 완전한 프로세스 엔진입니다. , 프런트엔드에는 2차 개발이 필요할 뿐만 아니라 백엔드에도 해당 서비스를 배포하거나 재설계 및 개발하는 데 드는 비용이 상대적으로 높으며 Activity에서 사용하는 프런트엔드 기술 스택은 상대적으로 오래되고 어렵습니다. 기존 시스템에 통합하기 때문에 현재 비즈니스 시나리오에는 적합하지 않습니다.
• Flowable: 주요 개발 언어는 Java입니다. 이를 사용하는 경우 백엔드는 전체 프로세스 엔진 세트를 배포해야 합니다. 서비스는 주로 수정 작업에 협력하며 비용이 상대적으로 높기 때문에 현재 비즈니스 시나리오에는 적합하지 않습니다. ;
• X6: AntV에서 제공하는 일련의 그래프 편집 엔진입니다. Box 대화형 구성 요소와 사용하기 쉬운 노드 사용자 정의 기능을 통해 순서도와 같은 그래프 애플리케이션을 쉽고 빠르게 구축할 수 있습니다.

각 프레임워크에는 고유한 장점과 단점이 있습니다. 마지막으로 우리는 2차 개발을 위해 antv-x6 그래프 편집 엔진을 선택했습니다.

• Ant의 오픈 소스 데이터 제품은 비교적 활발한 커뮤니티를 가지고 있습니다. 기술을 따르십시오. 스택 독립적이며 확장성이 뛰어납니다.
• 도구 구성 요소는 비교적 완벽하며 즉시 사용할 수 있습니다.
• 기술 선택을 명확히 한 후, 다음 단계는 구체적인 기술 구현입니다. 다중 라운드 SOP 프로세스 엔진은 프런트 엔드의 설계 및 구현이 필요할 뿐만 아니라 백엔드의 설계 및 구현 없이는 할 수 없습니다. 전체 아키텍처 설계는 아래 그림에 나와 있습니다.

4.1 프런트 엔드 구성 레이어

프런트 엔드 구성 레이어에는 주로 멀티 라운드가 포함됩니다. SOP 시각적 프로세스 구성, 온라인 및 오프라인 관리, 버전 관리 및 인터페이스 관리의 네 가지 기능 모듈이 있습니다.

• 다중 SOP의 시각적 구성: 각 비즈니스 노드의 드래그 앤 드롭 작업 및 데이터 구성을 포함하고 다양한 비즈니스 노드의 연결을 통해 완전한 프로세스 구성 생성
• 온라인 및 오프라인 관리: 구축된 다중 라운드 SOP 프로세스는 온라인 및 오프라인 운영이 필요합니다. 온라인 멀티 라운드 프로세스에서 문제가 발생하면 시간에 맞춰 오프라인으로 전환해야 합니다.
• 버전 관리: 구성된 멀티 라운드 SOP 프로세스가 방금 출시되면 응답 기술이 필요합니다. 또는 프로세스 노드의 기능은 상대적으로 기본적이므로 온라인 사용자의 프로세스 데이터를 통해 프로세스 기능을 지속적으로 개선해야 합니다. 모든 변경에는 여러 단계의 SOP 프로세스를 지속적으로 최적화하는 동시에 안정적인 온라인 버전을 보장하기 위한 업그레이드 버전이 필요합니다.
인터페이스 관리: 프로세스 관련된 각 비즈니스 노드는 서로 다른 비즈니스 도메인의 서비스에 의존합니다. 예를 들어 주문은 거래 인터페이스에 의존해야 하고, 물류는 공급망 인터페이스에 의존해야 합니다. 이러한 기능은 비즈니스 프로세스 구성과 관련되며 다음을 수행해야 합니다. 인터페이스 구성을 통해 구현됩니다.

4.2 백엔드 서비스 계층

백엔드 서비스 계층의 핵심 부분은 프로세스 실행 엔진 모듈입니다. 실제 응용 시나리오에서는 사용자가 입력한 문제에 따라 가장 적합한 프로세스를 매칭하여 사용자의 문제를 해결합니다. 일치하는 프로세스를 실행하는 과정에서 실행 엔진은 먼저 프로세스의 컨텍스트를 생성합니다. 여기서 컨텍스트 정보는 Redis 캐시에서 로드되며 컨텍스트에 기록된 프로세스 실행 상태에 따라 결정됩니다. 실행을 시작할 노드. 실행 후 컨텍스트는 정보 업데이트입니다. 프로세스 실행이 끝나면 컨텍스트가 삭제됩니다.

4.3 애플리케이션 계층

애플리케이션 계층은 주로 다중 라운드 SOP 프로세스의 특정 사용 시나리오이며 현재는 주로 Dewu 고객 서비스 로봇과 에이전트 지원 SOP의 두 가지 사용 시나리오를 포함합니다.

5. 기술적 과제

5.1 데이터 모델링

데이터 모델링을 통해 노드 간 연관 문제를 해결합니다.

다회전 SOP 프로세스를 시각화하는 과정에서 캔버스 노드 생성 및 연결이 가장 복잡합니다. 일부 다중 라운드 장면에는 노드가 100개 이상 있으며 캔버스에서는 노드 간의 관계가 매우 중요합니다. 현재 비즈니스 맞춤형 노드는 다음과 같이 4가지 유형이 있습니다.

각 노드는 고유한 비즈니스 속성을 가지고 있으며, 여기서 각 노드의 비즈니스는 주로 다음과 같은 아이디어를 통해 결합됩니다. ​​데이터 모델링의 개념은 다음과 같습니다.

원본 속성 필드를 확장할 수 있으며 X6에서 제공하는 데이터 속성은 다음과 같습니다. 맞춤형 비즈니스 데이터. 네 가지 유형의 비즈니스 노드를 분석한 후 각 비즈니스 노드는 공통 데이터 모델을 추상화할 수 있습니다. 주요 필드의 의미는 다음과 같습니다.

nodeName: 노드의 이름
• nodeType: 노드의 유형입니다. 네 가지 노드 유형이 있습니다: 채우기 슬롯 노드, 점프 노드, 응답 노드 및 판단 노드
• fromNodeId: 소스 노드의 ID
• nextNodeId: 포인팅 노드의 ID
• fromEdgeIdList: 소스 에지 ID 목록
• nextEdgeIdList : 포인팅 엣지 ID 목록
• bizData: 비즈니스 노드의 다양한 비즈니스 속성 정보

여기서 bizData는 비즈니스 노드의 일반 데이터 모델로 사용되며, 예를 들어 슬롯과 같은 다양한 비즈니스 노드의 속성 데이터를 저장하는 데 사용됩니다. Filling 노드에는 Slot, Abnorma 등의 비즈니스 속성이 있고, Reply 노드에는 contentSort, Content 등의 비즈니스 속성이 있습니다. 비즈니스 노드의 데이터 모델을 추상화하면 아래 그림과 같이 서로 다른 노드 간의 관계를 표현할 수 있습니다.

• 판단 노드는 nextEdgeIdList 속성을 통해 슬롯 채우기 노드 및 점프 노드와 연결될 수 있습니다.
• 판단 노드는 fromNodeId 속성을 통해 수동 응답 노드와 연결될 수 있습니다. nextNodeId를 통한 백업 응답 노드
• 백업 응답 노드 fromEdgeIdList를 통해 수동 응답 노드에 연결할 수 있습니다.
• 다양한 노드 관계를 시맨틱 속성으로 표현한 후 X6에서 제공하는 addNode/addEdge 메소드를 기반으로 노드와 에지를 연결합니다. 이와 같이 캔버스에 노드가 몇 개 있더라도 노드 간의 관계는 유지됩니다. 매우 명확합니다.

5.2 RXJS

RXJS 이벤트 구독 및 단방향 데이터 흐름을 통해 다양한 기능 모듈의 데이터 흐름 방향 문제 해결

다중 SOP 시각화 구축 배경에는 툴바, 캔버스라는 세 가지 기능 영역이 있습니다. 영역 및 데이터 구성 영역 각 영역의 작동에는 노드 데이터 변경이 포함됩니다. 명확한 데이터 흐름이 없으면 데이터 변경이 혼란스럽고 저장 시 데이터 혼란이 발생할 수 있습니다. 여기서는 RXJS 이벤트 구독 및 단방향 데이터 흐름의 디자인 패턴을 채택합니다. 구체적인 구현은 아래 그림에 나와 있습니다.

작업 표시줄의 노드 작업은 노드 작업 삭제와 같은 이벤트를 트리거합니다.

• 캔버스 영역에서 필수 항목을 선택합니다. 삭제된 노드는 노드 데이터 삭제 이벤트를 트리거합니다.
• 데이터 양식 구성 영역은 노드 데이터 삭제 이벤트의 데이터를 수신하고 해당 노드 데이터를 삭제하고 데이터 메모리 캐시에 동기화합니다. ;
• 프로세스가 최종적으로 제출되면 메모리에 있는 데이터가 서버 데이터베이스로 전송됩니다.
• 전체 프로세스는 노드 데이터에서 데이터를 형성한 다음 데이터를 캐시하기 위해 흐릅니다. 전체 흐름 방향은 어떤 모듈이 트리거되더라도 최종 흐름 방향은 데이터 메모리 캐시입니다.

데이터 흐름의 경우 현재 redux, vuex, dva 등 다양한 오픈 소스 프레임워크를 사용할 수 있습니다. 여기서 RXJS를 사용하는 이유는 무엇인가요? 주로 RXJS는 상대적으로 가볍고 기술 스택과 관련이 없으므로 후속 확장성이 더 좋습니다.

5.3 프로세스 오케스트레이션

프로세스 오케스트레이션 기술을 통해 복잡한 다라운드 프로세스 구축 문제를 해결

상반기 기준 온라인 다라운드가 200개에 가깝고, 일부 복잡한 프로세스에는 100개 이상의 노드가 포함되어 있습니다. .100개가 넘는 노드의 복잡한 프로세스를 노드별로 구성하면 구성 효율성이 매우 낮습니다. 그러면 복잡한 프로세스를 어떻게 신속하게 구축할 수 있습니까? 여기에는 프로세스 오케스트레이션 기술이 사용됩니다.

프로세스 오케스트레이션은 시각적 비즈니스 구성 요소를 드래그 앤 드롭하여 비즈니스 프로세스를 정렬한 다음 프로세스 엔진이 프로세스를 실행하는 것을 의미합니다. 표준화된 프로토콜은 BPMN 프로토콜로, 프로세스 오케스트레이션에 있어서 다양한 아이콘과 구성 요소의 의미와 사용 사양을 담고 있습니다. 실제 애플리케이션 시나리오에서는 BPMN 프로토콜을 완전히 사용하지 않았지만 BPMN 프로토콜을 따르고 맞춤형 구성 요소를 만들었습니다. 복잡한 프로세스의 경우 다양한 하위 프로세스를 통해 정리합니다.

다음은 주문을 취소하는 다단계 프로세스의 예입니다.

위 그림에서 명확하게 볼 수 있습니다. 다단계 주문 취소 프로세스에는 사용자 신원을 결정하는 하위 프로세스, 사용자 요구를 결정하는 하위 프로세스, 주문 취소를 위한 하위 프로세스의 세 가지 하위 프로세스가 포함됩니다. 이러한 각 하위 프로세스는 독립적이고 완전한 프로세스입니다. 이러한 방식으로 세 가지 하위 프로세스의 배열을 통해 주문 취소를 위한 복잡한 다단계 프로세스를 구축할 수 있습니다.

위의 세 가지 사항은 자체 연구 과정에서 직면하게 되는 주요 기술적 과제입니다. 실제로 수백 개의 노드를 몇 초 안에 렌더링하는 방법, 복잡한 로직(복사, 자르기), 복잡한 판단 노드를 배치하는 방법, 복잡한 판단 노드를 한 번의 클릭으로 확장 및 축소하는 방법 등은 여기에서 하나씩 자세히 설명하지 않습니다.

6. 비즈니스 결과

다양한 SOP 프로세스 엔진에 대한 고객 서비스의 자체 연구는 매년 최소 수십만 달러의 아웃소싱 서비스 비용을 절감할 뿐만 아니라 좋은 결과를 얻습니다. 유연한 맞춤화로 비즈니스 개발을 신속하게 지원합니다. 출시 이후 Dewu 고객 서비스 로봇과 상담원 지원 로봇이라는 두 가지 비즈니스 시나리오를 주로 다루었습니다. 그 중 Dewu 로봇에는 수백 개의 다단계 SOP 프로세스가 있고 상담원 지원 로봇에는 수십 개의 다단계 SOP 프로세스가 있습니다. 고객 서비스 해결률이 향상되고 이전 인건비도 절감되었습니다. 온라인 접속 후, 올해 한 달의 데이터를 예로 들면, 고객 서비스 로봇의 해결률이 FAQ 해결률에 비해 15% 이상 향상되었습니다. FAQ접수번호의 2배로 인건비가 대폭 절약됩니다.

7. 요약

고객 서비스 로봇 멀티 라운드 SOP 프로세스 엔진은 프로젝트 수립부터 출시까지 약 한 달이 소요됩니다. 현재, 다중 라운드 프로세스 엔진은 위의 두 가지 시나리오를 제공하는 것 외에도 작업 주문 비즈니스 및 품질 검사 비즈니스에서 사용 시나리오를 탐색하고 있으며, 일선에 표준화된 서비스 프로세스를 제공하기 위해 상담사 지원 시나리오를 지속적으로 강화하고 있습니다. 고객 서비스 및 일선 고객 서비스 개선. 기능적인 측면에서 우리는 계속해서 프로세스 엔진의 기능을 개선하고, 더 많은 비즈니스 시나리오의 사용을 지원하며, 프로세스 엔진의 기능을 지속적으로 개선하여 업계의 벤치마크가 될 것입니다.

위 내용은 Dewu 고객 서비스 로봇 다단계 SOP 프로세스 엔진 기술 실습의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!