4

웹 세미나에서는 여러 대화 작업 영역을 사용하여 프로젝트의 여러 주제를 처리하는 방법에 대해 언급했습니다 (예 : 기능적 대화와 오프 토픽). 이 디자인을 어떻게 구현해야합니까?여러 작업 영역으로 왓슨 대화를 구현하는 방법

두 개의 작업 영역이있는 경우 하나는 기능 - 주제이고 다른 하나는 주제가 아님을 알 수 있습니다. 요청을 처리 할 작업 영역을 결정하는 방법과 논리를 결정하는 방법은 무엇입니까?

그리고이 결정 논리는 서버 백엔드 또는 작업 공간 논리에 구현되어야합니까?

감사합니다.

답변

0

분류하려는 항목으로 첫 번째 의도 세트를 만듭니다. 이러한 의도 중 하나는 "Offtopic"이어야하며 주제를 벗어난 모든 질문을 포함해야합니다.

두 번째 작업 영역은 오프 주제이지만 관련 항목으로 나뉩니다.

전화를 걸어 Offtopic을 얻은 다음 두 번째 작업 영역을 호출하십시오. 그것은 오프 토픽의 본질을 되돌려 주어야 당신이 그것에 대한 조치를 취할 수 있습니다.

주제 항목에 간섭하지 않도록 기본 의도 집합을 테스트/조정해야합니다. 예를 들어 대화가 스포츠 용품 판매와 관련이 있다면 스포츠 관련 주제를 포착하는 것이 더 힘들 수 있습니다.

신뢰도를 고려해야 할 수도 있습니다.

0

나에게 제안 된 또 다른 접근 방식은 현재 마스터 라우팅 작업 영역과 가능하면 여러 응용 프로그램 작업 영역을 갖는 것입니다. 첫 번째 인스턴스에서 사용자의 입력은 어떤 응용 프로그램 작업 공간으로 경로를 정하는 높은 수준의 의도를 가진 마스터로 이동합니다. 응용 프로그램 작업 영역에는보다 세부적인 내용의 의도가 있습니다.

그러면 모든 후속 입력을 선택된 앱 작업 ​​영역과 마스터 라우터에 동시에 보냅니다. 이전에 설명 된 순차 접근 방식에 비해이 점의 잠재적 이점은 마스터 작업 영역이 주제를 벗어나 낮은 신뢰로 항복하지 않아도 제어 할 수 있다는 점입니다. 즉 오프 토픽을 중앙 집중화 할 수있을뿐 아니라 초기 라우팅과 동일한 마스터를 사용하여 다른 작업 공간으로 동적 라우팅을 할 수 있습니다.

I는 함께 (마스터가 마스터 작업 전송 얻고 중 작업 전류로 표시되는 편성 층이

{ 
    currentWs: xxxx, 
    contexts: { 
     ws_idn: {}, // basically an array of conversation contexts, 
     ....  // keyed on workspace_id's 
    } 
} 

입력과 같은 상황의 배열로 세션을 관리함으로써이를 수행 한 해당 작업 영역에 대한 관련 컨텍스트 개체로). 어느 컨텍스트에서도 컨텍스트를 잃지 않고 여러 chat봇 애플리케이션간에 이음새없이 전환 할 수 있습니다.