KR101169113B1 - 기계 학습 - Google Patents

Abstract

자동 응답 시스템(예를 들어, 자동 음성 응답 시스템)은 자동 응답 능력을 개발 또는 향상시키기 위해 학습 전략을 이용할 수 있다. 학습 전략은 대화에서의 다른 당사자(예를 들어, 통화자)의 통신을 식별 및 분류하기 위해 대화에서의 한 당사자(예를 들어, 고객 서비스 에이전트)의 통신(예를 들어, 구두 표현, 텍스트 메시지, 기타 등등)을 사용하는 것을 포함한다. 분류된 통신으로부터 분류자가 작성될 수 있다. 분류자는 대화에서의 당사자(예를 들어, 에이전트)의 공통의 통신 패턴을 식별하기 위해 사용될 수 있다. 학습 전략은 또한 선택 기준에 기초하여 자동 응답 능력을 향상시키기 위해 통신을 학습 기회로서 선택하는 것을 포함할 수 있다(예를 들어, 선택 기준은 시스템이 신뢰성이 없거나 중요하지 않은 예로부터 학습하지 않도록 선택됨).

기계 학습, 자동 응답 시스템, 고객 지원 센터, 에이전트

Description

기계 학습{MACHINE LEARNING}

본 발명은 자동 응답 시스템에서의 기계 학습에 관한 것이다.

대화가 관리되는 한가지 응용은 고객 컨택 센터(customer contact center)에서이다. 고객 컨택 센터, 예를 들어 콜 센터는 새로운 경제에서의 기업의 가장 중요하고 동적인 영역 중 하나로서 등장하였다. 오늘날의 힘든 경제 환경에서, 가격 효율적으로 고객에게 서비스를 제공하고 고객을 유지하는 것은 전략적으로 중요하다. 만족한 고객을 유지하는 것이 새로운 고객을 유치하는 것보다 비용이 덜 든다는 것을 많은 회사들이 깨닫고 있다. 모든 고객 대화의 1/2 이상에 대한 기업 접점으로서, 고객 컨택 센터는 성공적인 사업 전략에 대한 초석이 되었다.

고객 컨택 센터의 중요성이 점점 높아지는 것은 최근의 현상이다. 역사적으로, 고객 서비스는 대부분의 조직에 의해 문제점과 비효율성으로 가득찬, 고비용이지만 필요한 사업 경영 비용으로서 간주되어 왔다. 많은 통화량은 통상적으로 미숙한 직원을 압도해버리며, 그 결과 고객들은 오래 기다려야 한다. 부적절한 정보 시스템은 대부분의 통화자에게 기본적인 정보를 여러번 반복하도록 요구한다. 이 때문에, 추정된 20%의 쇼핑객들은, 조직의 컨택 센터에 전화를 하게 하는 일에 부딪힐 때, 웹 사이트를 포기하고, 더 많은 사람들은 지연시키는 대기 행렬 또는 좌 절감을 느낄 정도의 메뉴 선택에 부딪힐 때 통화를 포기한다. 게다가, 고객 컨택 센터는 엄청난 운영 비용의 전형이며, 보통의 기업의 수익의 거의 10%를 소모한다. 노동력 비용이 이 지출을 좌우하며, 업계의 엄청나게 높은 이직율의 결과 새로운 에이전트의 끊임없는 신규 모집과 훈련이 있게 된다.

불행하게도, 사업에 있어서, 비용 효율적인 고객 서비스를 보장하는 목표는 더욱 어려워지고 있다. 인터넷은 조직과 그의 고객 간의 통신의 폭발을 주도하였다. 고객은 인터넷 경제에서 서비스에 더 높은 가치를 두고 있는데, 그 이유는 온라인으로 구입한 제품 및 서비스가 전통적인 판매 채널을 통해 구입한 것보다 더 많은 문의를 발생하기 때문이다. 고객 컨택 센터의 역할이 사업 파트너, 투자가 및 심지어 회사 직원 등의 새로운 대상자(audience)에 서비스하는 것을 포함하도록 확장되었다. 새로운 고도로 효과적인 광고 및 마케팅 전략은 고객들로 하여금 정보를 얻기 위해 이미 부담이 과중한 고객 컨택 센터와 대화하게 한다. 전화 통화에 부가하여, 이제는 고객 서비스 운영에 엄청난 부담을 주는 새로운 웹-기반 텍스트 채널(이메일, 웹-메일 및 채팅을 포함함)을 통해 문의가 행해진다.

우수한 고객 서비스의 중요성의 증가 및 이를 전달하는 데 대한 장애물의 조합이 고객 서비스 문제를 이루고 있다.

한 측면에서, 본 발명은 일련의 에이전트 분류자를 훈련시키기 위해 일련의 이미 기록된 에이전트-통화자 대화(예를 들어, 사람 에이전트-통화자 대화)에서 캡처된 에이전트 통신(예를 들어, 구두 표현, 텍스트 메시지, 기타 등등)을 사용하는 것을 특징으로 한다. 에이전트 분류자에 의해, 통화자 구두 표현이 찾아내어져 클러스터화될 수 있다. 클러스터화된 통화자 구두 표현은 일련의 통화자 클러스터를 훈련시키는 데 사용될 수 있다.

한 측면에서, 본 발명은 분류자(예를 들어, 에이전트 또는 통화자 분류자)를 사용하여 이전에 기록된 에이전트-통화자 대화에서의 통신을 분류하고 이 분류된 통신을 연관된 분류자에 대한 훈련 세트에 추가하며 그 분류자를 재구성함으로써 통화자 클러스터를 확대시키는 것을 특징으로 한다.

다른 측면에서, 본 발명은 에이전트 분류자를 사용하여 에이전트와 통화자 간의 일련의 이전에 기록된 대화에서의 통상적인 에이전트 요청 패턴을 식별하는 것을 특징으로 한다. 이 통상적인 에이전트 요청 패턴은 어떤 통화 유형(예를 들어, 동일한 초기 통화자 요청에 관련한 통화)과 연관될 수 있다. 이 에이전트 요청 패턴은, 예를 들어, 애플리케이션 개발자에 의해, 자동 응답 시스템의 대화 흐름을 설계하는 데 사용될 수 있다.

다른 측면에서, 본 발명은 동일한 정보를 요구하는 서로 다른 말로 표현된 에이전트 질문에 대한 통화자 응답의 분포를 사용하여 통화자로부터 원하는 응답을 생성할 가능성이 가장 많은 자동 응답 시스템의 질문 표현을 결정하는 것을 특징으로 한다.

다른 측면에서, 본 발명은 제1 당사자 유형의 구성원들(예를 들어, 사람 에이전트 또는 소프트웨어 에이전트)과 제2 당사자 유형의 구성원들(예를 들어, 사람 통화자) 간의 일련의 대화를 수신하는 단계를 포함하는 방법을 특징으로 하며, 여기서 각각의 대화는 제1 당사자 유형의 구성원의 통신, 및 제1 당사자 유형의 구성원의 통신(예를 들어, 요청에 대한 구두 응답)에 응답하는 제2 당사자 유형의 구성원의 통신(예를 들어, 구두 요청)을 포함한다. 이 방법은 또한 제1 당사자 유형의 구성원들의 통신을 제1 일련의 클러스터로 그룹화하는 단계, 및 이어서 제1 당사자유형의 구성원들의 통신의 그룹화에 기초하여 제2 당사자 유형의 구성원들의 응답 통신을 제2 일련의 클러스터로 그룹화하는 단계를 포함한다. 이 방법은 또한, 기계에 의해, 제2 일련의 클러스터 내의 하나 이상의 클러스터에 대한 일련의 제2 당사자 유형 분류자(예를 들어, 지원 벡터 기계 또는 결정 트리)를 발생하는 단계를 포함한다.

본 발명의 이 측면의 구현은 이하의 특징 중 하나 이상을 포함한다. 이 방법은 자동 음성 응답 시스템 또는 자동 텍스트 메시징 응답 시스템 등의 자동 응답 시스템에 대한 초기 애플리케이션을 개발하는 데 사용될 수 있다. 제1 당사자 유형의 구성원들의 통신은 컴퓨터를 사용하여 제1 일련의 클러스터로 그룹화될 수 있다. 예를 들어, 컴퓨터 프로세스는 먼저 통신들의 의미론적 특징을 결정하고 이어서 이 의미론적 특징에 기초하여 통신들을 클러스터로 그룹화할 수 있다.

제1 그룹의 구성원들의 통신들의 그룹은 그 구성원의 통신의 의미에 기초하여 그룹화될 수 있다. 환언하면, 어떤 그룹 내의 통신들 전부가 동일한 의미를 갖지만 서로 다른 표현을 가질 수 있도록 통신들이 그룹화될 수 있다. 제2 당사자 유형의 구성원들의 통신의 그룹은 제1 당사자 유형의 구성원들로부터의 정보의 요청에 대한 응답에 대응하는 그룹이다.

이 방법은 또한 제1 당사자 유형의 구성원들과 제2 당사자 유형의 구성원들 간의 제2 일련의 대화를 수신하는 단계, 제2 당사자 유형의 구성원들의 통신을 그룹화하기 위해 제2 당사자 유형 분류자를 적용하는 단계, 및, 기계에 의해, 클러스터 내에 그룹화된 통신들에 관한 데이터를 사용하여 제2 일련의 클러스터 내의 클러스터에 대한 제2 당사자 유형 분류자를 재생성하는 단계를 포함할 수 있다.

다른 측면에서, 본 발명은 응답 통신도 포함하는 대화의 일부인 개시 통신(예를 들어, 에이전트로부터의 정보 요청)을 분류하기 위해 일련의 분류자를 적용하는 것, 및 이 분류된 통신을 사용하여 통상적인 통신 패턴을 식별하는 것을 특징으로 한다.

본 발명의 구현은 이하의 특징 중 하나 이상을 포함할 수 있다. 이 방법은 또한 일련의 대화에서의 대화를 주제(예를 들어, 콜 센터에 전화를 한 통화자의 목적의 주제)별로 그룹화하는 단계 및 식별된 통상적인 통신 패턴을 그룹과 연관시키는 단계를 포함할 수 있다.

다른 측면에서, 본 발명은 제1 당사자 유형의 구성원들과 제2 당사자 유형의 구성 사이의 대화에서의 제1 당사자 유형의 구성원의 통신을 분류하기 위해 일련의 분류자(예를 들어, 지원 벡터 기계)를 적용하는 단계, 및 제1 당사자 유형의 구성원의 분류된 통신의 조합 또는 시퀀스에 기초하여 대화의 주제를 결정하는 단계를 포함한다.

본 발명의 구현은 이하의 특징 중 하나 이상을 포함한다. 이 방법은 또한 분류된 통신의 시퀀스를 알고 있는 주제를 갖는 대화와 연관된 분류된 통신의 시퀀스와 매칭시키는 단계를 포함할 수 있다.

다른 측면에서, 본 발명은 시스템의 성능을 개선하기 위해 통화자와 자동 응답 시스템(예를 들어, 자동 텍스트 메시징 응답 시스템 또는 자동 음성 응답 시스템) 간에 일어난 통신의 예들을 사용하는 것을 특징으로 한다.

다른 측면에서, 본 발명은 어떤 선택 기준에 기초하여 자동 응답 시스템에 대한 학습 기회를 위한 예제들을 선택하는 것을 특징으로 한다. 이 선택 기준은 시스템이 학습하는 바탕이 되는 예제들이 믿을만한 것이도록 하는 데 도움이 되도록 (예를 들어, 그래픽 사용자 인터페이스를 통해 사용자에 의해) 선정될 수 있다. 이 선택 기준은 또한 시스템이 시스템에 의미있는 개선을 가져다주는 예제들만을 선택하도록 선정될 수 있다. 시스템에 의미있는 개선을 가져다주지 않는 예제들을 버림으로써, 시스템은 자원(예를 들어, 개선을 구현하는 일을 맡은 프로세싱 자원 또는 학습 예제를 검토 또는 승인하는 일을 맡은 사람 관리 자원)에 대한 부담을 최소화하는 데 도움을 준다.

다른 측면에서, 본 발명은 대화(이들 대화 중 적어도 어떤 것은 고객 컨택 센터와 연관된 에이전트(예를 들어, 사람 에이전트 또는 소프트웨어 에이전트)와 사람 간의 일련의 통신(예를 들어, 구두 표현, 텍스트 메시지, 기타 등등)을 포함함)의 디지털 표현을 수신하는 단계 및 하나 이상의 선택 기준이 만족되는 경우 통신을 학습 기회로서 선택하는 단계를 포함하는 고객 컨택 센터와 연관된 자동 응답 시스템을 위한 학습 기회를 선택하는 방법을 특징으로 한다.

구현은 이하의 특징 중 하나 이상을 포함할 수 있다. 선택 기준은, 어떤 통신에 뒤이어서 사람과 에이전트 간의 통신 교환이 있어야 한다는 요건, 어떤 통신에 뒤이어서 사람과 에이전트 간의 다수의 성공적인 후속하는 통신 교환이 있어야 한다는 요건, 어떤 통신이 에이전트에 의해 제기된 만족도 질문에 사람이 긍정적으로 응답한 대화 내에 포함되어야 한다는 요건, 제1 대화에서의 어떤 통신이 다수의 다른 대화에서 일어나는 유사한 통신들에 의해 확인되어야 한다는 요건, 또는 어떤 통신이 이 통신을 사용하여 작성된 일련의 분류자로 하여금 이전의 일련의 분류자가 정확하게 분류했던 통신들을 잘못 분류하게 해서는 안된다는 요건을 포함할 수 있다.

어떤 구현에서, 사람과 에이전트 간의 통신은 사람 에이전트가 자동 응답 시스템에 의해 발생되는 제안된 응답의 순위 리스트로부터 사람의 통신에 대한 응답을 선택하는 지원 상호작용(assist interaction)을 포함할 수 있다. 이들 지원 상호작용을 위해, 선택 기준은 지원 상호작용에서의 선택된 응답이 문턱값보다 높은 순위로 되어 있어야 한다는 요건, 또는 지원 상호작용에서의 선택된 응답이 신뢰된 사람 에이전트로부터 선택되어야 한다는 요건을 포함할 수 있다.

선택된 통신은 선택된 통신을 사용하여 분류자를 재구성하는 것, 선택된 통신을 사용하여 자동 음성 인식 엔진에 대한 언어 모델을 생성하는 것, 또는 선택된 통신을 사용하여 유한 상태 네트워크를 수정하는 것에 의해 시스템 성능을 향상시키는 데 사용될 수 있다.

음성 응답 구현에서, 이 방법은 또한 학습 기회로서 선택된 구두 표현에 대해 오프라인 음성 인식 엔진에 의한 음성 인식을 수행하는 단계를 포함할 수 있다. 이 방법은 또한, 음성 인식을 수행하는 단계 이전에, 통신의 디지털 표현과 연관된 구두 표현의 의미의 신뢰 수준에 기초하여 선택된 구두 표현에 대한 음성 인식을 수행할지를 판정하는 단계를 포함할 수 있다.

다른 측면에서, 본 발명은 고객 컨택 센터와 연관된 하나 이상의 에이전트와 통화자 간에 있었던 통신의 디지털 표현을 수신하는 단계, 및 하나 이상의 선택 기준에 기초하여 녹음을 위해 대화의 디지털 표현에서 캡처된 구두 표현을 선택하는 단계를 포함하는, 고객 컨택 센터와 연관된 자동 음성 응답 시스템에 대한 학습 기회를 선택하는 방법을 특징으로 한다.

구현은 이하의 특징 중 하나 이상을 포함할 수 있다. 선택 기준은 자동 음성 응답 시스템에 의한 응답의 신뢰 수준이 어떤 범위의 값 내에 있어야 한다는 요건, 또는 대화 동안의 구두 표현에 대해 수행되는 음성 인식 프로세스의 신뢰 수준이 어떤 범위의 값 내에 있어야 한다는 요건을 포함할 수 있다. 이 방법은 또한 구두 표현에 대해 음성 인식을 수행하는 단계, 및 대화 동안의 구두 표현을 인식하기 위해 시스템에 의해 사용되는 음성 인식 프로세스에 의해 사용되는 단어들의 어휘에 구두 표현 내의 인식된 단어를 추가하는 단계를 포함할 수 있다.

다른 측면에서, 본 발명은 에이전트가 자동 응답 시스템에 의해 제안된 응답들 중에서 사람의 통신에 대한 응답을 선택하는 자동 응답 시스템에 연관된 사람 에이전트와 사람 간의 대화에 기초하여, 자동 응답 시스템을 훈련시키기 위한 예제로서 통신을 선택하는 단계를 포함하는 방법을 특징으로 한다. 본 발명의 구현은 이하의 특징 중 하나 이상을 포함할 수 있다. 통신의 선택은 에이전트에 의해 선택된 응답의 신뢰 수준에 또는 응답을 선택한 사람 에이전트의 신뢰 수준에 기초할 수 있다.

다른 측면에서, 본 발명은 자동 응답 시스템에 연락하는 사람 간의 통신을 식별하는 단계(그 결과, 응답이 사람 에이전트에 의해 처리됨), 및 시스템에 연락하는 사람으로부터의 유사한 장래의 통신에 응답하기 위해 자동 응답 시스템을 수정하는 단계를 포함하는 방법을 특징으로 한다.

한 특정의 구현에서, 자동 응답 시스템을 수정하는 단계는 시스템과 연관된 유한 상태 천이 네트워크를 수정하는 단계를 포함한다.

다른 측면에서, 본 발명은, 개념 인식 엔진에서의 분류자를 위한 일련의 훈련 예제에 통신을 추가하는 단계, 추가된 통신을 포함하는 일련의 훈련 예제를 사용하여 새로운 분류자를 생성하는 단계, 및 새로운 분류자에 대한 성능 요건에 기초하여 새로운 분류자를 무시하는 단계를 포함하는 자동 응답 시스템을 위한 학습 기회를 선택하는 방법을 특징으로 한다.

구현은 이하의 특징 중 하나 이상을 포함한다. 성능 요건은 새로운 분류자가 적어도 미리 정해진 수의 다른 예들을 정확하게 분류해야 한다는 요건, 또는 새로운 분류자가 상기 이전의 분류자의 한정적인 일련의 예들과 미리 정해진 양만큼 서로 다른 새로운 한정적인 일련의 예들을 가져야 한다는 요건일 수 있다.

다른 측면에서, 본 발명은 응답 통신의 적어도 하나의 클러스터(이 클러스터는 대화 내에서 응답 통신과 연관되어 있는 개시 통신의 하나 이상의 클러스터에 기초함)에 대한 일련의 분류자를 생성하는 것을 특징으로 한다.

구현은 이하의 특징 중 하나 이상을 포함할 수 있다. 개시 대화는 제1 당사자 유형의 구성원(예를 들어, 고객 서비스 센터에 있는 에이전트)으로부터 온 것일 수 있고, 응답 대화는 제2 당사자 유형의 구성원(예를 들어, 고객 서비스 센터에 연락하는 고객)으로부터 온 것일 수 있다. 이 방법은 또한 일련의 대화를 수신하는 단계를 포함할 수 있으며, 이 대화 중 적어도 일부는 개시 통신 및 연관된 응답 통신을 포함한다. 응답 통신의 클러스터는 개시 통신과 연관된 응답 통신을 포함할 수 있다.

다른 이점, 특징 및 구현은 이하의 설명 및 청구항으로부터 명백하게 될 것이다.

도 1은 상태 천이선도를 나타낸 도면.

도 1a는 상태 천이 그래프를 나타낸 도면.

도 2는 고객, 시스템 및 사람 에이전트 간의 상호 작용을 나타낸 도면.

도 3은 플로우차트를 나타낸 도면.

도 4는 소프트웨어 아키텍처 시스템의 개요를 나타낸 도면.

도 5는 도 4의 소프트웨어 아키텍처를 보다 상세히 나타낸 도면.

도 6은 작업 흐름 컴포넌트 시스템의 블록도.

도 7은 대화 채널 컴포넌트의 블록도.

도 8은 음성 인식기의 블록도.

도 9는 개념 인식 엔진의 블록도.

도 10은 마크업 언어 문서의 구성을 나타낸 도면.

도 11은 예시적인 그래프에 대한 상태 천이 그래프의 서브셋을 나타낸 도면.

도 12는 반복적 애플리케이션 개발 프로세스를 나타낸 도면.

도 13은 스크린샷을 나타낸 도면.

도 14는 다른 스크린샷을 나타낸 도면.

도 15는 초기 애플리케이션 개발 프로세스를 나타낸 도면.

도 16a 내지 도 16f는 초기 애플리케이션 개발 프로세스를 나타낸 도면.

도 17은 학습 서버의 블록도.

정보의 문자 그대로의 표현에 기초하기보다는 오히려 정보의 의미 또는 의미론적 문맥에 기초하여 정보와 지능적으로 상호작용하기 위해 미국 특허 제6,401,061호(여기에 인용함으로써 그 전체 내용이 본 명세서에 포함됨)에 기재된 기술 등의 개념 또는 의미에 기초한 자연어 처리 기술이 이용될 수 있다. 따라서, 예를 들어, 사용자가 문제를 제기하고 시스템이 응답을 제공하는 통신 등의, 통신을 관리하기 위한 시스템이 구축될 수 있다. 이러한 시스템은 아주 효과적이고, 사용하기 편리하며 결함-내성이 있는데, 왜냐하면 이 시스템이 문자 그대로의 표현에 상관없이 사용자 질의로부터 주요 개념을 자동적으로 추출하기 때문이다. 개념 인식 엔진(미국 특허 제6,401,061호에 기재되어 있는 종류의 것)은 음성 또는 텍스트-기반 통신 채널을 통한 대화에서 고객이 기반 시스템을 이용할 때 고객이 무엇을 요구하고 있는지에 기초하여 적절한 응답의 형성을 가능하게 해준다. 이 대화 는 고객과의 동기 통신(음성 또는 인스턴트 메시징을 사용하는 실시간 대화 또는 웹 페이지를 통한 다른 통신 등) 또는 비동기 통신(이메일 또는 음성 메일 메시지 등)일 수 있다. 비동기 통신 모드를 사용하는 대화에서, 응답은 고객의 문의에 대해 나중의 시간에 제공된다.

고객 컨택 센터의 경우, 런타임 이전에, 통신 관리 시스템은 고객과 고객 컨택스 센터의 사람 에이전트 사이의 로그된 실제 대화를 사용하여 지식 베이스를 생성한다. 시스템을 모든 가능한 고객 대화에 대해 프로그램하려고 시도하지 않고 이와 같이 로그된 대화를 사용하는 것은 셋업을 간단하고 신속하며 광범위한 시스템 관리자의 능력 내에 있도록 만들어준다.

계속하여 변하는 사업 환경에 신속하게 적응할 수 없는 전통적인 자체-서비스 시스템과는 달리, 본 명세서에 기술된 시스템은 전형적인 질문 및 대답 쌍을 신속하게 모델링할 수 있고 또 장래의 대화를 자동화할 수 있다.

시스템에 의해 처리되는 각각의 대화는 상태 및 다른 상태로의 천이의 순서 집합으로서 모델링되며, 여기서 각각의 상태로부터의 천이는 고객에 의한 질문 또는 진술 및 사람 에이전트에 의한 응답을 포함한다(또는 어떤 경우에, 사용자에게 다시 질문을 제기하는 것 등의 질문에 응답하여 취해지는 행동). 기록된 대화로부터 처리되고 있는 대화에 대한 기호로 나타낸 상태-천이 상태 시퀀스가 도 1에 나타내어져 있다. 어떤 구현에서, 고객에 의한 각각의 진술 또는 통신이나 사람 에이전트에 의한 응답에 대한 구분자는 어떤 기간의 침묵이나 구두 개입이다.

이들 진술 또는 응답 각각에 대한 텍스트는 대화, 예를 들어 텍스트 또는 음성 대화에서 어느 통신 매체가 사용되었든 그 매체로부터 추출된다. 예를 들어, 온라인 자동 음성 인식(ARS) 엔진이 구두 대화를 텍스트로 변환하는 데 사용될 수 있다. 그 다음에, 시스템은 고객의 질문 또는 진술이나 사람 에이전트의 응답으로부터 주요 개념을 추출한다. 이 추출은 개념 인식 엔진에서 사용하기 위한 지식 베이스로서 일련의 개념(의미론적 인자)으로 텍스트 요소(S-모프(S-Morph)) 및 그의 의미의 라이브러리를 생성함으로써 미국 특허 제6,401,061에 기술된 바와 같이 행해진다. 이 개념 인식 엔진은 고객 또는 에이전트로부터의 텍스트를 이들 S-모프로 파싱하고, 이어서 이들 S-모프와 매칭하는 개념이 수집된다. 통신(기술되고 있는 예에서, 질문 또는 응답)에 대한 이들 주요 개념은 비순서 집합(non-ordered set)으로서 저장될 수 있고, "개념 주머니(bag of concepts)"라고 할 수 있다. 구문 또는 근접성(nearness)을 반영하는 여러가지 구조로의 개념들의 상위 레벨 구성도 역시 가능하다. 일련의 로그된 대화(즉, 문답) 전체가 처리된 후에, 각각의 대화는 상태-천이 상태 시퀀스로서 표현된다. 이 시스템은, 초기 상태가 대화들 중 임의의 것으로 천이할 수 있도록, 대화 상태 천이 시퀀스 전부를 단일의 그래프로 누적한다. 이 취합된 천이 그래프는 이어서 중복 상태 및 천이를 대체시키는 그래프 이론 기술을 사용하여 압축된다. 이 시스템은, 천이를 그의 "개념"과 비교함으로써, 주어진 상태로부터의 어느 천이가 중복되는지를 재귀적으로 판정한다. 이어서, 동일한 상태로부터의 중복 천이의 후계자 상태는 후계자 상태로부터의 천이 전부를 갖는 하나의 상태로 병합된다. 중복 천이의 응답들 중 하나의 텍스트는 지식 베이스에 표준 응답으로서 보존되어 있다. 이 텍스트는 텍스트 형태로 대화 교환의 일부로서 다시 고객으로 전달되거나 음성으로 변환될 수 있다. 그 결과 얻어진 압축된 상태 천이 그래프는 시스템에 대한 지식 베이스를 형성한다. 압축된 상태 천이 그래프의 예가 도 1a에 도시되어 있다. 어떤 구현에서, 이 지식 베이스 내의 모든 정보는 잘 정의된 XML 문법을 사용하여 저장된다. 마크업 언어의 예로는 HTML(Hyper Text Markup Language), 및 VoiceXML(Voice Extensible Markup Language)이 있다. 이 경우에, 지식 베이스에 대한 정보를 저장하기 위해 CML(Conversation Markup Language, 대화 마크업 언어)가 사용된다.

지식 베이스가 형성되면, 시스템은, 예를 들어, 이 시스템이 고객 컨택 센터에서 통신을 관리하는 데 사용되는, 동작(런타임) 모드로 진행할 수 있다. 주어진 고객 컨택 센터에 대한 지식 베이스를 구축하는 데 사용된 로그들은, 어떤 구현에서, 그 동일한 고객 컨택 센터 또는 유사한 종류의 대화로 특징지워지는 고객 컨택 센터에서 일어나는 대화로부터 기록된다. 이 지식 베이스를 사용하여, 시스템은 고객 컨택 센터에 대한 상태 천이 그래프에 기초하여 런타임 대화의 현재 상태를 추적할 수 있다. 예를 들어, 고객이 고객 컨택 센터와 그의 첫번째 통신(텍스트로 변환됨)을 한 후에(예를 들어, 사용자는 임의의 자연어 구두 질의를 할 수 있음), 시스템은 텍스트로부터 개념을 추출하기 위해 개념 인식 엔진을 사용한다. 그 다음에, 시스템은 텍스트로부터의 개념을 컨택 센터의 상태 천이 그래프에서의 초기 상태로부터의 천이와 매칭시키려고 시도한다. 이 매칭은 현재 통신과 연관된 일련의 개념을 지식 베이스에 저장된 일련의 개념과 비교함으로써 행해진다. 2개의 일련의 개념들이 가까울수록, 매칭의 정확도에 더 많은 신뢰가 주어진다. 지식 베이 스에서의 최상의 매칭하는 천이가 어떤 문턱값을 넘는 신뢰도로 고객의 텍스트와 매칭하는 경우, 시스템은 정확한 천이를 식별한 것으로 가정하고, 지식 베이스에서 대응하는 응답을 찾으며, 그 대응하는 응답을 고객에게 전달한다. 시스템은 상태 천이 그래프에서 그 다음 상태로 진행하고, 고객의 다음 통신을 기다린다. 상태 및 천이의 시퀀스의 이러한 순회는 고객이 대화를 종료하거나 상태 천이 그래프가 종료 상태에 도달할 때까지 계속될 수 있다. 그렇지만, 개념 인식 엔진에 의해 수신된 텍스트에서의 에러 및 고객에 의한 비표준의(또는 예상치못한) 질문 또는 진술은 사람 에이전트의 간섭을 필요로 할 수 있다. 고객의 통신이 음성 형태인 경우, 음성에서 텍스트로의 변환이 이러한 에러를 가질 수 있다. 이러한 에러의 가능성으로 인해, 어떤 구현에서, 시스템은 고객에 대한 응답의 완전 자동화에 의존하지 않고 자동화가 성공하지 못할 때 사람 에이전트에 의한 수동 개입으로의 원활한 전환을 갖는다. 일반적으로, 이러한 유형의 점진적 자동화가 고객(1), 시스템(3) 및 사람 에이전트(5) 간의 대화를 나타낸 도 2에 암시되어 있다. (시스템의 다른 구현에서, 사용자에게 (시스템이 응답할 수 없음을 나타내는 것 이외에) 아무런 응답도 제공되지 않는 동안, 신뢰가 높은 경우에 자동 응답이 제공될 수 있다.)

어떤 예에서, 시스템은 전화를 통해 고객을 대화에 참여시키기 위해 음성 인식 기술을 사용한다. 음성 인식 기술은 고객의 음성을 텍스트로 변환하고, 이 텍스트는 개념 인식 엔진에의 입력으로 된다. 개념 인식 엔진과 음성 인식을 통합함으로써, 기반 시스템은 고객이 무엇을 의미하고 있는지를 개념적으로 이해함으로써 고객이 무엇을 말하는지를 인식한다. 이 조합은, 사용자를 다수의 채널에 걸쳐 직 관적이고 지능적이며 건설적인 대화에 참여시킴으로써, 고객 서비스 센터에서의 새로운 레벨의 자동화를 가능하게 해준다. 그리고, 그렇게 함으로써 조직이 모든 연락 채널에 걸쳐 상당한 분량의 일상적인 고객 트랜잭션을 덜 수 있게 되고, 상당한 비용을 절감할 수 있게 되며 또 서비스 레벨을 개선할 수 있게 된다.

다른 구현에서, 고객과의 이들 대화는, 예를 들어, VoiceXML 브라우저를 사용하여 오디오 인터페이스를 통해, HTML 브라우저를 사용하여 웹을 통해, IM 애플리케이션을 사용하여 인스턴트 메신저를 통해, 메일 애플리케이션을 사용하여 이메일을 통해, 또한 아직 사용되지 않는 채널을 통해 일어날 수 있다.

유의할 점은 이 시스템이 컨택 센터의 응답이 고객의 통신과 다른 모드의 통신을 사용할 수 있게 해준다는 것이다. 예를 들어, 고객은 음성을 사용하여 통신을 할 수 있고 컨택 센터는 텍스트로 응답을 할 수 있거나, 또는 고객은 텍스트를 사용하여 통신할 수 있고 컨택 센터는 컴퓨터 발생 음성으로 응답을 할 수 있다. 이것은 저장된 응답 텍스트를 직접 사용하는 것에 의해 또는 저장된 응답 텍스트를 컴퓨터 발생 음성으로 변환하는 것에 의해 달성된다.

어떤 구현에서, 시스템은 3가지 유형 또는 레벨의 대화 관리를 제공하며, 시스템은 주어진 대화 중에 이들 간에 전환할 수 있다.

1. 자동(Automated) - 시스템은 고객의 요청에 대한 적절한 응답을 생성할 수 있고 또 사람 에이전트와 완전히 독립적으로 트랜잭션을 자동화할 수 있다. 예를 들어, 고객 A는 새로운 제품에 관한 그의 보증에 관해 문의하기 위해 회사의 고객 컨택 센터에 전화를 한다. 고객 A는 자신을 소개하고, 샘플 문의를 포함하여, 자동 시스템이 어떻게 동작하는지에 대한 간략한 설명을 제공하는 자동 시스템에 의해 인사를 받는다. 이어서, 고객 A는 그 자신의 말로 그의 문의를 말하도록 재촉받는다. 고객 A는 대화 방식으로 그의 문의를 말한다. 자동 시스템은 고객에게 회사의 전반적인 보증 정책을 알려준다. 시스템은 고객 A에게 설명이 도움이 되었는지 또 임의의 부가적인 질문이 있는지를 물어본다. 그의 질문에 대답이 되었으면, 고객 A는 통화를 종료한다.

2. 혼합 에이전트 지원(Blended Agent Assist) - 이 모드에서, 시스템은 고객 문의 및 신뢰도/유사성("매칭 점수")별로 순위가 매겨진 다수의 제안된 응답을 사람 에이전트에게 제공함으로써 사람 에이전트를 필요로 한다. 사람 에이전트는 제안된 응답들 중 하나를 선택하고, 시스템이 통화를 완료할 수 있게 해준다. 사람 에이전트는 또한 시스템에 질문을 입력함으로써 대안의 응답을 위해 시스템 지식 베이스를 검색할 수 있다. 혼합 에이전트 지원 모드에서, 에이전트는 전화를 받거나 고객과 직접 대화하지 않는다. 혼합 모델은 에이전트가 시스템을 신속하게 정확한 해결로 안내할 수 있게 해줌으로써 에이전트 통화 시간을 감소시킬 것으로 예상된다. 이어서, 사람 에이전트는 새로운 트랜잭션으로 계속 이동할 수 있다. 예를 들어, 고객 B는 그가 서비스에 대한 지불을 하룻밤 넘길 수 있는 주소를 물어보기 위해 회사의 고객 서비스 조직에 전화를 건다. 고객 B는 자신을 소개하고 고객의 이름을 확인하는 자동 시스템으로 인사를 받는다. 고객의 이름을 확인한 후에, 고객 B는 자동 시스템이, 샘플 문의를 포함하여, 어떻게 동작하는지에 대한 간략한 설명을 제공받는다. 고객 B는 이어서 그 자신의 말로 그의 문의를 말하도록 요청받는다. 고객 B는 대화 방식으로 그의 문의를 말한다. 자동 시스템은 고객의 질문에 대한 대답을 찾는 동안에 고객에게 잠시 기다리라고 요구한다. 시스템은 그 다음 이용가능한 에이전트에게 전화를 한다. 고객이 기다리는 동안, 시스템은 이용가능한 사람 에이전트에게 연결되어 고객 B의 질문을 귀뜸해준다. 사람 에이전트는 고객의 질문에 대한 몇가지 제안된 응답을 갖는 스크린 팝을 수신한다. 사람 에이전트는 적절한 제안된 대답을 선택하고 "응답"을 쳐서, 시스템으로 하여금 그 대화를 완료할 수 있게 해준다. 시스템은 야간 주소를 제공함으로써 고객 B와의 대화를 재개한다. 시스템은 이 해답이 도움이 되었는지 및 임의의 부가적인 질문이 있는지를 고객 B에게 질문한다. 그의 질문에 대답이 되었으면, 고객 B는 사람 에이전트가 그 응답 중 임의의 것을 선택했는지 모르는 상태에서 통화를 종료한다.

3. 에이전트 지원 인수(Agent Assist Takeover) - 인수 모델에서, 시스템은 사람 에이전트로 확대하고, 사람 에이전트는 그 통화를 완전히 인수받아 통화자가 직접 대화에 참여하게 한다. 인수 모델은, 고객 서비스 에이전트에 대한 통화로부터 대화 정보를 사전 수집하고 그 에이전트가 통화 동안에 시스템의 지식 베이스에서 정보를 탐색함으로써, 에이전트 생산성을 향상시킬 것으로 예상되며, 이에 따라 통화에 소비해야 하는 시간을 감소시킬 수 있다. 예를 들어, 고객 C는 그의 계좌를 폐쇄하기 위해 회사의 고객 서비스 조직에 전화를 한다. 고객 C는 자신을 소개하고 고객의 이름을 확인하는 자동 시스템으로 인사를 받는다. 그의 이름을 확인한 후에, 고객 C는, 샘플 문의를 포함하여, 자동 시스템이 어떻게 동작하는지에 대 해 간략한 설명을 제공받는다. 고객 C는 이어서 그 자신의 말로 그의 문의를 말하도록 재촉받는다. 고객 C는 회사와의 그의 계좌를 폐쇄하고 싶다고 말한다. 자동 시스템은 고객의 계좌 번호를 확인하기 위해 고객에게 질문을 한다. 고객 C는 전화 키패드에서 그의 계좌 번호를 쳐넣는다. 시스템은 고객 C에게 그가 에이전트에게 이관되는 동안 기다려주도록 말한다. 시스템은 그 통화를 이 트랜잭션에 대한 적절한 에이전트 풀(agent pool)로 전달한다. 그 다음 이용가능한 에이전트는 고객 C의 질문의 기록을 수신하고 그의 계좌 정보를 갖는 스크린 팝을 수신한다. 이 에이전트는 고객 C가 언제 그의 계좌를 폐쇄하고자 하는지를 질문함으로써 통화를 인수받는다.

시스템은 시스템이 그 상황을 처리할 수 있는 능력에 기초하여 3가지 모드의 대화 관리 간에 전환한다. 예를 들어, 자동 대화 모드에서, 시스템이 충분한 확신으로 고객의 문의를 표준의 질문/응답 쌍과 매칭시킬 수 없는 경우, 시스템은 혼합 에이전트 지원 모드로 전환할 수 있다. 게다가, 혼합 에이전트 지원 모드에서, 고객의 문의가 주어질 때 사람 에이전트가 컴퓨터 발생된 응답 중 어느 것도 적절하지 않은 것으로 판정하는 경우, 시스템은 에이전트 지원 인수 대화 모드로 전환할 수 있으며, 사람 에이전트가 대화를 마무리한다. 본 발명의 양호한 실시예에서, 고객도 역시 대화의 모드를 전환할 수 있다. 예를 들어, 고객은 자동 대화 모드에서 빠져 나오게 전환하고자 할 수 있다. 다른 실시예에서, 시스템은, 사람 에이전트가 얼마나 바쁜지에 기초하여, 고객의 통신을 해석하는 데 있어서의 신뢰 문턱값을 조정할 수 있다. 이것은 분주한 사람 에이전트를 기다리지 않고 자동 응답을 시도하는 옵션을 고객에게 제공할 수 있다.

부가적인 대화 관리 모드는 사람 에이전트가 시스템의 통신 패턴에 충분한 경험을 가지고 있을 때 일어난다. 이 경우에, 고객의 통신이 낮은 신뢰 수준으로 천이와 매칭되면, 사람 에이전트는 고객의 질문을, 보다 성공적인 매칭을 가져올 수 있는 대체 텍스트로 재표현하기로 결정할 수 있다. 그러한 경우, 대화는 자동 모드에서 계속될 수 있다.

이들 3가지 대화 모드를 사용하여 시스템에 의해 관리되는 고객과 컨택 센터 간의 대화는 도 3에 나타낸 플로우차트에 의해 모델링된다. 이 흐름에서, 먼저 사용자는 질문 또는 진술을 컨택 센터로 전달함으로써 대화를 개시한다(단계 2). 그 다음에, 그 통신이 텍스트로 변환된다(단계 4). 식별된 천이는 시스템에 의한 차후의 응답에 관련 있는 가변 데이터를 포함할 수 있다. 이 가변 데이터는 고객의 이름 또는 식별 번호일 수 있으며 특정의 데이터 유형(문자열, 숫자, 날짜, 기타 등등)을 갖는다. (존재하는 경우) 가변 데이터는 고객의 통신의 텍스트로부터 추출된다(단계 6). 가변 데이터를 식별하는 데 특별한 규칙이 사용될 수 있다. 그 다음에, 개념 인식 엔진은 나머지 텍스트를 S-모프로 파싱하고 이들 S-모프에 매칭하는 "개념 주머니"를 수집한다(단계 8). 그 다음에, 시스템은 가장 높은 신뢰 수준을 갖는 고객의 통신으로부터의 추출된 개념에 매칭하는 개념을 갖는 현재 상태로부터의 천이를 식별한다(단계 10). 이 천이에서 데이터 변수가 예상되는 경우, 예상된 변수의 데이터 유형을 추출된 변수의 데이터 유형과 매칭시키는 것은 이 비교에 포함된다. 매칭의 신뢰도가 설정된 문턱값보다 높은 경우(단계 12), 시스템 은 고객이 식별된 천이에 있는 것으로 가정한다. 이 경우에, 시스템은 식별된 천이에 매칭하는 응답에 대한 데이터를 탐색해야만 할지도 모른다(단계 14). 예를 들어, 고객의 통신이 기업의 근무 시간에 관하여 묻는 질문인 경우, 시스템은 데이터베이스에서 근무 시간을 탐색할 수 있다. 그 다음에, 시스템은, 추가의 데이터가 응답의 일부분인 경우, 그 데이터와 함께 매칭하는 응답을 사용자에게로 전송한다(단계 16). 이 응답은 많은 형태의 통신 중 하나일 수 있다. 대화가 전화를 통화는 경우, 시스템의 응답은 컴퓨터-발생된 음성일 수 있다. 대화가 텍스트-기반인 경우, 응답은 텍스트일 수 있다. 질문이 음성이더라도 응답은 텍스트일 수 있으며, 그 역일 수도 있다. 시스템이 충분한 신뢰도를 갖는 천이를 식별하는 경우(단계 12), 컨택 센터에 있는 사람 에이전트는 지원하도록 재촉받는다. 사람 에이전트는 지금까지의 대화를 보여주는 그래픽 사용자 인터페이스를 본다(단계 18). 시스템은 또한 고객의 통신과 최상으로 잘 매칭하는 것을 갖는 천이로부터 최악으로 매칭하는 것까지의 순서로 되어 있는 현재 상태로부터의 예상된 천이의 리스트를 사람 에이전트에게 보여준다. 사람 에이전트는 예상된 천이 중 하나가 대화의 문맥에 적절한지를 판정한다(단계 20). 하나의 천이가 적절한 경우, 사람 에이전트는 시스템에게 그 천이를 알려주고, 시스템은 자동 모드에서 대화를 계속한다(단계 14). 그렇지 않고, 사람 에이전트가 대화의 문맥에 적절한 천이가 없는 것으로 판정하는 경우, 사람 에이전트는 대화의 종료 때가지 그 대화를 직접 인수한다(단계 28).

시스템은 동작(런타임) 모드에 있는 동안 그의 지식 베이스를 계속하여 확장 할 수 있다. 시스템이 에이전트 지원 인수 모드에 있을 때, 시스템은 사람 에이전트와 고객 간의 대화를 로그한다. 일정한 간격으로, 이들 대화는 지식 베이스의 초기 생성에서와 같이 처리되며, 새로운 상태 천이 시퀀스가 지식 베이스에 추가된다. 한가지 차이점은 에이전트 지원 인수 모드가 일반적으로 초기 상태 이후의 상태에서 시작한다는 것이다. 따라서, 새로운 상태 천이 시퀀스 중 하나는 일반적으로 비초기 상태로부터의 천이처럼 취합된 상태 천이 그래프에 추가된다. 새로운 상태 천이 시퀀스가 지식 베이스에서의 취합된 상태 천이 그래프에 추가될 때마다, 취합된 상태 천이 그래프가 전술한 바와 같이 압축된다.

시스템의 예시적인 구현이 도 4에 도시되어 있다. 대화 서버(30)는 시스템의 런타임 엔진이다. 대화 서버(30)는 J2EE(Java 2 Enterprise Edition) 애플리케이션 서버 상에 배치되어 있는 J2EE 애플리케이션이다. 이 애플리케이션은 개발되고 대화 스튜디오(32)를 사용하여 대화 서버로 배포된다. 도 4는 대화 서버(30)와 대화 스튜디오(32) 간의 관계를 나타낸 것이다.

이 시스템은 다중 채널 대화 애플리케이션이다. 대화 서버(30) 내에서, 일련의 자동 소프트웨어 에이전트가 시스템 애플리케이션을 실행한다. 다중 채널이란, 예를 들어, 소프트웨어 에이전트가 다수의 대화 채널, 즉 전화, 웹, 인스턴트 메시징, 및 이메일을 통해 통화자들과 대화할 수 있음을 의미한다. 대화적이란, 소프트웨어 에이전트가, 사람 에이전트가 통화자와 갖는 대화와 유사하게, 통화자와 쌍방향 대화를 갖는다는 것을 의미한다. 이 시스템은 반복적 애플리케이션 개발 및 실행 패러다임을 사용한다. 앞서 설명한 바와 같이, 시스템 애플리케이션을 지원하는 통화자 및 에이전트 대화는 컨택 센터 내의 사람 고객 지원 에이전트와 통화자 간의 실제 대화에 기초한다.

도 4는 또한 대화 서버와 시스템의 다른 구성요소 간의 관계를 나타내고 있다. 대화 서버(30)는 고객으로부터 보내오는 데이터를 받는 기업 정보 서버(34)와 상호작용하고, 고객 질문에 대한 응답을 위한 데이터를 제공한다. 에이전트 워크스테이션(36)은, 대화가 혼합 에이전트 지원 모드에 있을 때, 사람 에이전트로 하여금 시스템에 대한 천이를 선택할 수 있게 해주는 그래픽 사용자 인터페이스로 소프트웨어를 실행한다. 에이전트 전화(38)는, 대화가 에이전트 지원 인수 모드에 있을 때, 사람 에이전트가 고객과 실황 구두 대화에 들어갈 수 있게 해준다.

시스템은 또한, 시스템이 배치된 후에, 시스템이 통화로부터 학습하는 것을 돕는 프로세스를 구현하는 학습 서버(31)를 포함한다. 학습 서버(31)에 대해서는 도 17과 관련하여 이하에서 보다 상세히 기술한다.

대화 서버(30)의 내부 구조가 도 5에 도시되어 있다. 대화 서버(30)는 시스템 애플리케이션의 논리를 지원하는 4개의 계층으로 된 코어 세트를 갖는다. 이들 계층은 종래에 웹 애플리케이션 서버에서 발견되는 4개의 계층이다. 이들은 프리젠테이션(40), 작업 흐름(42), 비지니스(44) 및 통합(46)이다.

프리젠테이션 계층(40)은 최종 사용자에게 정보를 제공하는 일을 맡고 있다. JSP(Java Server Page) 등의 서블릿은 종래에 이 계층에서 사용되는 J2EE 기술이다. 프리젠테이션 계층은 2개의 서브시스템, 즉 대화 채널 서브시스템(interaction channel subsystem)(48) 및 에이전트 대화 서브시스템(agent interaction subsystem)(50)으로 이루어져 있다. 대화 채널 서브시스템(48)은 각각의 대화 채널, 즉 웹(52), VoiceXML(54), 인스턴스 메신저 채팅(56), 및 이메일(58)을 통해 대화 서버(30)의 고객과의 대화를 처리한다. 에이전트 대화 서브시스템은 대화 서버(30)의 컨택 센터 내의 사람 에이전트와의 대화를 처리한다.

작업 흐름 계층(42)은 동작들의 시퀀싱을 처리한다. 이들 동작은 비지니스 계층 내의 비지니스 객체에 대한 트랜잭션 및 최종 사용자와의 상호작용을 포함한다. 대화 서버(30)에서, 작업 흐름 계층(42)은 고객과 행해지는 대화를 이해하는 소프트웨어 에이전트(60)로 채워져 있다. 게다가, 이들 에이전트는 비지니스 계층(44) 내의 비지니스 객체와 상호작용한다. 소프트웨어 에이전트(60)는 대화 스튜디오(32)(애플리케이션 개발 시스템)에 의해 생성되는 마크업 언어의 인터프리터(interpreter)이다.

비지니스 계층(44)은 애플리케이션 영역에 대한 비지니스 객체를 보유하고 있다. EJB(Enterprise Java Bean)는 종래에 비지니스 계층에서 이용되는 기술이다. 대화 서버는 이 계층에 시스템-관련 기술을 도입하지 않는다. 오히려, 대화 서버는 J2EE 애플리케이션 서버 상에 배치된 다른 애플리케이션에 이용가능한 동일한 일련의 컴포넌트를 이용한다.

통합 계층(46)은 데이터베이스 및 외부 시스템에 대한 애플리케이션 서버의 인터페이스를 맡고 있다. J2EE 커넥터 및 웹 서비스는 이 계층에서 이용되는 종래의 기술이다. 비지니스 계층(44)과 같이, 대화 서버(30)는 시스템-관련 기술을 이 계층에 도입하지 않는다. 오히려, 대화 서버(30)는 종래의 J2EE 컴포넌트를 이용한다. 통상의 통합 계층의 가치는 외부 시스템들을 통합하는 어떤 작업도 J2EE 서버 상에 배치된 다른 애플리케이션에 이용가능하게 되어 있다는 것이다.

대화 서버(30)의 동작을 용이하게 해주는 일련의 서브시스템이 4개의 계층의 코어 세트를 둘러싸고 있다. 이들 서브시스템은 배치(deployment)(62), 로깅(logging)(64), 컨택 서버 인터페이스(66), 통계(68), 및 관리(70)이다.

배치 서브시스템은 시스템 애플리케이션의 반복적인 핫 배치(iterative, hot deployment)를 지원한다. 이것은 대화가 로그되고 대화 스튜디오(32)로 피드백되는 반복적인 애플리케이션 개발에 적합하며, 이 경우 컨택 센터 내의 직원은 시스템 애플리케이션이 이해하지 못한 구문으로 애플리케이션을 보강할 수 있다.

로깅 서브시스템(64)은 소프트웨어 에이전트(60)가 고객 및 고객 지원 에이전트와 하는 대화의 로그를 유지한다. 이 로그는 대화 스튜디오(32)에 의해 지원되는 반복적 애플리케이션 개발 프로세스에의 입력이다. 학습 서버(31)는 개념 인식 엔진(concept recognition engine, CRE)(74)에 대한 일련의 학습 기회를 발생하기 위해 이들 로그된 통화를 사용한다.

컨택 서버 인터페이스(CTI)(66)는 다수의 CTI 및 컨택 서버(72)에 통합된 인터페이스를 제공한다.

통계 서브시스템(68)은 사람 에이전트를 위해 통화-처리 통계를 유지한다. 이들 통계는 ACD 및/또는 컨택 서버(72)에 의해 제공되는 통계와 동등하다. 콜 센터 운영자들은 그 센터가 예상하고 있는 트래픽에 서비스를 제공하기에 충분한 작업 인원을 그 센터가 가지고 있도록 하기 위해 이들 통계를 사용할 수 있다.

관리 서브시스템(70)은 대화 서버(30)가 기업 내의 네트워크 관리 요원에 의해 관리될 수 있게 해준다. 이 서브시스템(70)은, 대화 서버(30)가 HP Open View 등의 네트워크 관리 시스템에 의해 관리될 수 있도록, SNMP 등의 표준 네트워크 관리 프로토콜을 지원한다.

도 6은 시스템의 작업 흐름 계층(40)의 컴포넌트를 나타낸 것이다. 소프트웨어 에이전트(60)는 작업 흐름 계층(40) 내의 주된 개체이다. 소프트웨어 에이전트(60)는 고객, 컨택 센터 내의 사람 에이전트, 및 백엔드 시스템(back-end system)과 대화하는 자동화된 개체이다. 이들 대화 전부는 대화 스튜디오(32)에 의해 개발되고 배치된 애플리케이션에 따라 행해진다. 작업 흐름 계층(40)에 대한 기능적 요건은 다음과 같다.

이용가능한 소프트웨어 에이전트를 할당 및 풀링하고 또한 그 에이전트가 대화 서버(30)에 배치된 애플리케이션들 중 임의의 것을 처리할 수 있게 해준다. 이 에이전트 풀링 기능(agent pooling capability)은 EJB의 인스턴스 풀링 기능(instance pooling capability)과 유사하다. 이는 또한 컨택 센터의 작업 인원 관리 모델 내에 적합하다.

대화 채널(interaction channel)은 소프트웨어 에이전트(60)를 할당하고 그 소프트웨어 에이전트(60)가 특정의 애플리케이션을 처리하도록 요청한다. 작업 흐름 계층(40)은 애플리케이션을 관리하는 애플리케이션 관리자와 상호작용한다. 애플리케이션 관리자는 (애플리케이션 개발자에 의해 지시된 대로) 이용할 애플리케이션의 버전을 선택한다.

소프트웨어 에이전트(60)는 요청하는 채널을 통해 대화가 허용되도록 보장하기 위해 라이센스 관리자로 검사를 한다. 허용되지 않는 경우, 소프트웨어 에이전트(60)는 적절한 응답을 반환한다.

소프트웨어 에이전트는 한번에 다수의 대화를 할 수 있다. 소프트웨어 에이전트는, 응답의 해결 동안에 사람 에이전트와 대화하면서, 적어도 하나의 고객과 대화를 할 수 있다. 이 기능은 에이전트가 한번에 다수의 채널을 통해 고객에게 말을 하게 하는 것으로 확장될 수 있다.

소프트웨어 에이전트(60)는 대화 스튜디오(32)에서 개발된 애플리케이션에 따라 대화를 한다.

소프트웨어 에이전트(60)는 고객의 입력이 수신된 상황에서 그 입력을 해석하기 위해 개념 인식 엔진(CRE)(74)을 호출하고 반환된 결과에 따라 행동한다.

각각의 소프트웨어 에이전트(60)는 그가 하고 있는 대화의 전사본(transcript)을 유지한다. 이 전사본은 궁극적으로 대화 로깅 서브시스템을 통해 로그된다. 이 전사본은 이하의 정보(모두가 적절히 타임 스탬프되어 있음)를 포함한다.

실행 중인 애플리케이션

이하의 것을 포함하는 고객과의 대화를 통한 경로

인식된 텍스트는 물론 구두 표현 둘다로서의 고객 입력

대화의 상태(문맥, 천이, 기타 등등)

의미 인식의 결과

의미 인식 결과에 기초하여 소프트웨어 에이전트가 취하는 조치

고객에게 전송되는 출력

소프트웨어 에이전트(60)가 취할 수 있는 조치 중 하나는 사람 에이전트의 지원을 요청하는 것이다. 이 결과 사람 에이전트와의 대화에 대한 서브 전사본(sub transcript)이 얻어진다. 이 전사본은 이하의 것을 포함한다.

통화의 시작에서의 에이전트 그룹에 대한 큐 통계

언제 전화를 걸었는지 또 받았는지

이하의 것을 포함하는 통화에 따른 에이전트의 행동의 서브-전사본

에이전트가 지원을 하는지 인수를 하는지

지원을 하는 데 에이전트가 취하는 조치, 예를 들어 소프트웨어 에이전트(60)에 의해 제시된 응답의 리스트 중에서 선택하는 것, 질의를 조정하여 지식 베이스를 검색하는 것, 맞춤 응답을 생성하는 것.

에이전트가 검토를 위해 특정의 응답에 표시를 하는지 및 에이전트가 응답에 표시하는 주석.

소프트웨어 에이전트(60)에 대한 에이전트의 지시

작업 흐름 계층(40)은 소프트웨어 에이전트(60)의 풀(들)에 대한 통계를 생성한다. 이들 통계는 통계 서브시스템(68)을 통해 발표된다.

작업 흐름 계층(40)을 통제하는 동작 파라미터(예를 들어, 최소 및 최대 에이전트/애플리케이션, 증대 증분)가 관리 서브시스템(70)을 통해 관리되는 구성 데이터베이스로부터 검색된다.

도 6은 작업 흐름 계층(40)을 구성하는 컴포넌트들, 즉 에이전트 관리자(76) 및 에이전트 인스턴스(agent instance)를 나타낸 것이다. 에이전트 관리자(76)는 에이전트 인스턴스의 풀링 및 특정의 애플리케이션에 대한 이들 인스턴스의 할당을 처리한다. 에이전트 관리자(76)는 대화 서버(32)를 구성하는 다른 관리자/서브시스템과 상호작용하는 일을 맡고 있다(에이전트 관리자(76)의 통계 서브시스템(68)과의 상호작용은 도시되어 있지 않음). 각각의 에이전트 인스턴스(60)는 로깅 관리자(78)와의 대화 전사본을 로그한다.

프리젠테이션 계층은 2개의 서브시스템, 즉 대화 채널(interaction channel)(48) 및 에이전트 대화 서브시스템(agent interaction subsystem)(50)으로 이루어져 있다.

대화 서버에 의해 지원되는 대화 모드, 즉 HTML(80), VoiceXML(82), 인스턴트 메신저(84), 및 이메일(86) 각각과 연관된 대화 채널이 있다. 대화 채널 서브시스템(48)은 코쿤 XSP(Cocoon XSP) 프로세싱 인프라 상에 구축된다. 대화 채널(48) 프로세싱은 도 7에 나타내어져 있다. 대화 채널에 대한 기능상 요건은 다음과 같다.

고객(최종 사용자)과의 각각의 대화를 위한 대화 세션을 개시, 유지 및 종료시킨다. 그 세션의 일부로서, 대화 채널은 고객과의 대화의 상태를 관리하는 에이전트 인스턴스를 보유한다.

들어오는 URL(Uniform Resource Locator)로부터 채널 유형 및 애플리케이션을 결정한다. URL은 http://호스트 주소//애플리케이션 이름.마임 타입?파라미터의 형태를 가질 수 있으며, 여기서 호스트 주소 = IP 주소 및 포트이고, 애플리케이션 이름 = 애플리케이션의 배치된 이름이며, MIME 타입 = 채널 유형(예를 들어, html, vxml, 기타 등등)을 나타내고, 파라미터 = 요청 파라미터이다.

HTML 및 VoiceXML 채널의 경우, 프로세싱을 위해 HTTP 요청을 에이전트에 전달한다. IM 및 이메일 채널의 경우, 등가의 요청 프로세싱 단계를 수행한다.

적절한 문서 정의 언어(HTML, VoiceXML, SIMPL, SMTP, 기타 등등)를 사용하여 채널-독립적인 응답을 채널-관련 응답으로 변환한다. 이 변환은 XSL 스타일-시트에 의해 좌우된다. 스타일-시트의 프로세싱 및 응답의 정의는 애플리케이션 정의의 일부이며, 각각의 요청 프로세싱 호출에 응답하여 에이전트에 의해 반환된다. 응답 및 XSL 스타일-시트의 정의는 이들 용도 경우에 속한다. 대화 채널이 이들 용도 경우에 특별히 배려를 하지는 않는다.

응답 문서 및 XSL 스타일-시트는 애플리케이션에 대해 채널 기반으로 정의된다. 응답 문서는 CML <출력> 태그의 내용은 물론 CML으로부터 발생된 다른 결과물(예를 들어, 문법 파일)을 요청한다.

"파일" 용도 경우에, 사용자는 애플리케이션 내에서 응답 문서를 정의한다. 응답 문서는 채널에서 정의된 XSL 스타일-시트를 사용하여 처리된다. 응답 문서는 응답 문서를 규율하는 DTD에 충실해야만 한다. 이 DTD는 다중-필드 폼(multi-field form)이 정의될 수 있게 해준다.

"열기" 용도 경우에, 사용자는 응답 문서는 물론, XSL 스타일 시트를 정의한다. 어느 문서에도 제한을 두지 않으며, 대화 서버(30)는 응답의 프로세싱과 관련하여 어떤 결과에도 책임을 지지 않는다.

이 변환은 채널 관련 문서 언어로의 변환 및 특정의 클라이언트에 대한 응답의 브랜딩(branding) 둘다를 처리한다.

VoiceXML 채널(54)의 경우, 대화 채널(82)은, 대화 로그에 포함시키고 및/또는 사람 에이전트에게 낮은 목소리로 전달하기 위해, 기록된 고객 요청을 로그하는 일 및 에이전트에 기록 장소를 알려주는 일을 맡고 있다.

앞서 언급한 바와 같이, 대화 채널 서브시스템(48)은 코쿤 기반구조를 사용하여 구현된다. 코쿤 기반구조는 웹 애플리케이션 서버 기반구조의 프리젠테이션 계층(40)에서 모델-뷰-컨트롤러 패러다임(model-view-controller paradigm)을 제공한다.

서블릿(90)(컨트롤러)는 HTTP 요청을 처리하고 그 요청을 처리하기 위해 에이전트 인스턴스(60)와 상호작용한다. 에이전트 인스턴스(60)는 응답 XSP 문서 및 문서의 출력에 적용할 XSL 스타일-시트를 반환한다.

XSP 문서(모델)는 컴파일되고 서블릿(92)으로서 실행된다. 문서는 그의 출력, 즉 XML 스트림을 생성하기 위해 에이전트 인스턴스에 파라미터를 요청한다. XSP 문서는 JSP 문서의 등가물이다. JSP 처리와 같이, XSP 문서가 마지막으로 컴파일된 이래로 XSP 문서가 변한 경우에만 XSP 컴파일이 행해진다.

XML 스트림은 XSL 스타일-시트(뷰)에 따라 대화 채널에 관련된 언어(예를 들 어, HTML, VXML)로 변환된다.

사람 에이전트 대화 서브시스템(AIS)은 컨택 센터 내의 사람 에이전트와의 대화를 설정하는 일 및 불확실한 응답을 해결하기 위해 소프트웨어 에이전트와 사람 에이전트 간의 협동을 관리하는 일을 맡고 있다. 이 서브시스템은 또한, 애플리케이션에서 애플리케이션의 전송이 요청될 때, 사용된다. 에이전트 대화 서브시스템은 컨택 서버와의 연결을 실행하기 위해 CTI 서버 인터페이스와 상호작용한다. CTI 서버 인터페이스는 또한, 에이전트 그룹에의 연결과 관련하여 그의 거동을 변경할 수 있는, 에이전트 대화 서브시스템에 큐 통계(queue statistics)를 제공한다.

에이전트 대화 서브시스템(agent interaction subsystem, AIS)은 이하의 동작을 행한다.

문제가 되는 응답을 해결하기 위해 컨택 센터 내의 사람 에이전트와의 대화를 개시, 유지 및 종료한다. 사람 에이전트는 이 특정의 응용에 대한 해결을 처리하기 위해 지정된 특정의 에이전트 그룹의 구성원이다.

에이전트와의 대화를 개시하는 것의 일부로서, AIS는 사람 에이전트의 데스크톱 애플리케이션이 응답의 해결에 협력할 수 있게 해주는 핸들을 에이전트 세션에 할당 및 전달한다.

AIS는 애플리케이션 프로그래밍 인터페이스(API)를 제공하며, 이 API를 통해 사람 에이전트의 데스크톱 애플리케이션은 이하의 것들, 즉 현재 해결해야 하는 고객 요청 및 제안된 응답, 해결 요청에 이르게 한 문턱값 설정 및 해결 요청이 너무 많은 양호한 응답으로 인한 것인지 너무 적은 양호한 응답으로 인한 것인지, 고객의 대화 채널 유형, 현재까지의 대화의 전사본, 이 고객 대화와 연관된 작업 흐름의 현재 상태, 예를 들어, 사람 에이전트가 이 대화에서 지원한 횟수, 고객이 소프트웨어 에이전트와 이야기한 시간, 고객이 대화와 관련하여 처해 있는 상태(상황), 대화의 상태 및 시간에 기초한 어떤 진행 척도, 및 현재 애플리케이션(및 네트워크) 속성을 검색할 수 있다.

AIS API는 또한 사람 에이전트가, 고객에게 반환할 응답을 선택하고, 요청을 수정하여 MRE 데이터베이스를 검색하며, 아마도 고객에게 반환할 응답을 선택하고, 소프트웨어 에이전트로부터 통화를 인수하며, 또한 대화 로그에서 검토하기 위해 요청/응답 대화에 표시하고 그 대화와 주석을 연관시킬 수 있게 해준다.

AIS API는 또한 사람 에이전트가 컨택 서버(72)에 로그인/로그아웃하고 또 컨택 센터 큐와 관련하여 그의 작업 상태를 관리할 수 있게 해주기 위해 JTAPI 인터페이스를 보여준다.

AIS API는 다수의 구현 기술로부터 액세스될 수 있게 해주는 언어-독립적인 포맷을 이용한다.

AIS는 VoiceXML 서버(54)로부터 컨택 서버로의 음성 통화의 라우팅 및 이들 음성 통화의 특정의 에이전트 세션과의 차후의 연관을 지원한다.

AIS는 애플리케이션 설계자가 사람 에이전트에 대한 애플리케이션 데이터의 프리젠테이션을 정의할 수 있게 해준다. 이 프리젠테이션은 대화 채널(82, 84, 86 또는 88)에서 이용된 동일한 XSL 프로세싱을 사용해야만 한다.

사람 에이전트 대화 서브시스템의 일부는 컨택 센터 에이전트가 해결 통화(resolution call)를 처리할 수 있게 해주는 에이전트 데스크톱 애플리케이션이다. 이 애플리케이션은 2가지 형태를 갖는다.

범용 사람 에이전트 데스크톱. 이 데스크톱은 비통합된 고객 관계 관리(CRM) 환경에서 동작하며, CTI 및 CS 서버에 연결된 에이전트의 데스크톱 상에서 별도의 프로세스로서 실행된다.

CRM 컴포넌트. 이 데스크톱은 CRM 패키지의 컨텍스트 내에서 실행되는 컴포넌트(ActiveX 컴포넌트 또는 애플릿)로서 패키지되어 있다.

음성 인식은 사람 음성 언어를 텍스트로 자동적으로 변환하는 기술이다. 음성 인식 시스템의 많은 예가 있다. 고객이 전화를 통해 대화하는 시스템의 구현에서, 음성 인식(온라인 ARS에 의해 수행됨)은 고객의 통신을 적절한 응답과 매칭시키는 데 있어서의 첫번째 단계이다. 일반적인 음성 인식은 의미있는 음소를 추출하기 위해 음성에 신호 처리 기술을 적용하는 것을 필요로 한다. 그 다음에, 이들 음소로부터 구성될 수 있는 단어를 사전으로부터 검색하기 위해 소프트웨어 검색 기술이 사용된다. 이 시스템의 음성 인식 부분은 통신의 있을법한 컨텍스트를 알고 있음으로써 이 검색을 안내한다. 시스템의 이 음성 인식 부분의 블록도가 도 8에 도시되어 있다. 전술한 바와 같이, 시스템은 고객과 컨택 콜 센터 간의 표준 대화의 상태 천이 그래프를 정의하는 마크업 언어(CML)로 이루어진 지식 베이스에 액세스한다. 소프트웨어 에이전트가 대화의 현재 상태를 추적하기 때문에, 이 에이전트는 이 상태로부터의 가능한 천이 모두를 탐색할 수 있다. 이들 천이 각각은 "개념 주머니" 또는 "S-모프 주머니"(104)를 갖는다. 이들 S-모프(104)는 매칭하는 텍스트(112)로 변환될 수 있다. 있을법한 천이 전부로부터의 매칭하는 텍스트의 취합은 사전에 있는 단어들 전부의 서브셋이다. 일반적으로, 그룹 전체보다는 그룹의 서브셋과 매칭하도록 검색하는 것이 보다 효율적이다. 따라서, 이 음성 인식기에 대한 검색 엔진(102)은 먼저 고객의 통신의 음소를 있을법한 천이 전부로부터의 텍스트(112)와 매칭시키려고 시도한다. 검색 엔진(102)은 이 텍스트와 매칭되지 않는 음소의 임의의 나머지 조합을 사전에서 검색한다.

이 시스템의 어떤 구현에서 사용되는 개념 인식 엔진(74)(도 5에 도시됨)은 텍스트 및 오디오 소스 둘다로부터의 사용자의 자연어 질문을 이해하는 안정된 언어 독립적인 방법을 제공하는 고도의 자연어 처리 기술이다. 이 기술은 정보의 문자 그대로의 표현에 기초하기 보다는 오히려 정보의 의미, 즉 의미론적 문맥에 기초하여 정보를 인덱싱하고 그와 상호작용한다. 개념 인식 엔진은 사람이 실제로 말하고 타이핑하는 방식을 이해하며, 그에 따라 원하는 정보에의 액세스를 용이하게 해주기 위해 시스템이 말씨 또는 언어에 관계없이 복잡한 대화에 사용자를 지능적으로 참여시킬 수 있게 해준다.

개념 인식 엔진은 구문의 형태소 레벨 분석에 기초하며, 그에 따라 개념 인식 엔진은 내포된 의미의 주요 성분에 대한 "이해"를 생성할 수 있게 된다. 이 기술은, 아주 정확하고 안정적인 것 이외에도, 계산적으로 효율적이며 종래의 자연어 기술보다 빠르고 언어 독립적이다.

자연어 처리를 적용하는 대부분의 다른 시스템은 사용자의 입력에 대한 같은 뜻의 구문을 찾기 위해 구문론적 분석을 사용한다. 이 분석은 먼저 아주 많은 언어 사전을 사용하여 구문에서의 모든 단어 또는 단어의 성분을 식별한다. 그 다음에, 시스템은 이들 요소를 엄밀 리스트(rigid list) 내의 특정의 엔트리(즉, 단어 또는 키워드 인덱스)에 매칭시키려고 한다. 그 결과, 이들 시스템은 문자열의 레벨에 기초한 매칭을 사용하고, 적어도 하나의 문자가 목표 인덱스 엔트리와 다른 경우, 매칭이 실패한다. 개념 엔진이 시스템의 어떤 구현에서 사용되는 경우, 매핑은 정해진 일련의 단어, 구문 또는 워드 요소에 기초하지 않고 정해진 일련의 개념에 기초한다.

의미론적 처리에 중점을 둔 결과, 개념 인식 프로세스는 본질적으로 안정되며, "노이즈많은" 입력 데이터에 대해서도 아주 잘 동작한다. 이것은 시스템이 음성 인식 소프트웨어를 사용하여 음성 단어를 인식할 수 있는 것에 유용하다. 시스템은 통상의 오탈자, 음성 인식 소프트웨어에 의해 발생되는 에러, 또는 문맥에 맞지 않는 단어에도 불구하고 실세계 대화 상호작용에서의 의미를 정확하게 인식하는 프로세스를 이용한다. 사용자는 단어들의 임의의 조합을 말할 수 있고, 시스템은 사용자의 의도를 이해하기에 충분히 융통성이 있다.

개념 인식 엔진은 의미론적 라벨을 생성하고 비교하는 알고리즘에 기초한다. 임의의 길이의 텍스트에 대한 의미론적 라벨은 그의 의미의 가장 중요한 성분을 포착하는 짧은 인코딩이다. 소스 데이터 스토어(들) 내의 항목들이 의미론적 태그가 붙어 있을 때, 이들은 이들을 자유-형식 음성 또는 텍스트 질의 또는 다른 입력 텍스트 소스에 (이들 입력 텍스트 소스에서 사용되는 실제 단어 및 구두점에 상관없 이) 선택적으로 매핑함으로써 검색될 수 있거나 또는 다른 방식으로 관리될 수 있다. 예를 들어, 시스템에 "맞지 않는 바지를 어떻게 반품할 수 있나요?"라고 질문하는 사용자는, 정확한 정보가 그 안의 어디에도 단어 "바지" 또는 "반품"을 포함하고 있지 않더라도, 조직의 반품 정책 데이터베이스로부터 관련 정보를 제공받게 된다. 동일한 정보를 찾는 다른 방식으로 표현된 사용자 질의는, 입력 문자열에서 사용된 실제 단어와 무관하게, 개념적으로 동일한 반품 정책에 매핑된다.

이 방법은 통계적 언어 모델 자동 음성 인식(statistical language model automatic speech recognition)(SLM ASR) 소프트웨어 및 유한-상태 문법(ASR)의 이점 간의 갭을 메운다. 이 기술은 자연어 처리 알고리즘인 개념 인식 엔진(CRE)이라고 한다.

개념 인식 엔진(CRE)은 텍스트 및 오디오 소스 둘다로부터의 사용자의 자연어 질문을 이해하는 안정되고 언어 독립적인 방법을 제공한다. 이 기술은 문자 그대로의 표현에 기초하기보다는 오히려 정보의 의미 또는 의미론적 문맥에 기초하여 정보를 인덱싱, 매핑하고 그와 상호작용하기 위한 고도의 자연어 처리 기술이다. 대부분의 다른 자연어 시도와는 달리, 이 기술은 텍스트의 완전한 "이해"를 생성하려는 시도에서 구문의 완전한 형식적 언어 분석에 의존하지 않는다. 그 대신에, 이 기술은 구문의 형태소 레벨 분석에 기초하며, 그에 의해 내포된 의미의 주요 성분의 "이해"를 생성할 수 있게 된다.

형태소는 의미 또는 의미론적 문맥(semantic context)을 포함하는 언어의 최소 단위로서 정의된다. 단어는 하나 또는 몇개의 형태소를 포함할 수 있으며, 이 들 각각은 하나의 또는 다수의 의미를 가질 수 있다. 이것의 비교적 간단한 예가 지구를 의미하는 형태소 geo 및 도해를 의미하는 graph로 이루어진 단어 geography를 사용하여 설명된다. 이들 2개의 서로 다른 형태소는, 결합될 때, 지구에 대한 학문을 의미하는 개념을 형성한다. 따라서, 보통의 통신에서 쉽게 이해되는 새로운 개념을 형성하기 위해 개개의 의미 단위가 결합될 수 있다.

이 기술은 의미론적 라벨을 생성 및 비교하는 알고리즘에 기초한다. 임의의 길이의 주어진 텍스트에 대한 의미론적 라벨은 그의 의미의 가장 중요한 성분을 포착하는 짧은 인코딩이다. "데이터베이스" 내의 항목들이 의미론적 태그가 붙여져 있을 때, 이들은 사용자-발생 자유-형식 텍스트 질의 또는 다른 유형의 입력 텍스트 문자열을 파싱함으로써 (입력 문자열에서 사용되는 실제 단어 및 구두점과 무관하게) 선택적으로 검색 또는 매핑될 수 있다.

CRE는, 그 결과 얻어지는 엔진 출력을 분석하고 또 이어서 비교될 수 있는 의미론적 라벨을 인덱싱된 회사 정보 데이터베이스에 할당함으로써, SLM ASR과 협력하여 문맥을 결정한다. 게다가, CRE는, 가장 통상적으로 잘못 인식되는 단어(작은 단어)를 무시하고 또 그의 분석에서 문맥상 보다 비중있는 단어(more context-heavy word)를 사용함으로써, 음성 인식 에러의 효과를 억제하는 데 도움이 된다. 따라서, CRE의 효과는, 통상적인 오탈자 또는 음성 인식 소프트웨어에 의해 발생되는 에러에도 불구하고, 실세계 대화 상호작용에서 의미를 정확하게 인식하는 자체 서비스 시스템을 가능하게 해준다. 보다 간단히 말하면, 이들 2가지 기술의 조합은 시스템으로 하여금 사람이 의도하는 바를 이해함으로써 사람이 말하는 것을 인 식할 수 있게 해준다.

설계 시에, CRE는 사용자에 의해 탐색되고 검색되는 데이터를 자동적으로 인덱싱한다. 대화 응용에서, 이 데이터는 콜 센터 에이전트와의 고객 대화의 전사된 기록이지만, 임의의 일련의 텍스트 정보(문서, 자주하는 질문(FAQ) 리스트, 데이터베이스 내의 자유-텍스트 정보, 채팅 쓰레드(chat thread), 이메일, 기타 등등)가 CRE를 사용하여 인덱싱될 수 있다. 인덱싱은 CRE가 데이터를 그의 개념적 유사성에 따라 그룹화 또는 "클러스터화"하는 프로세스이다. 종래의 알파벳순 인덱스와는 달리, CRE에 의해 생성된 클러스터는 개념 공간(concept space)이라고 하는 다차원 공간에 저장되는 특수한 개념적 참조이다. 이들은, 특수화되고 아주 큰 개념 데이터베이스를 수동으로 생성 및 유지할 필요없이, 임의의 개념에 대한 설명을 발생하기 위해 결합될 수 있는 일련의 기본 원자 개념(primary atomic concept)(이미의 기본 구성 단위)을 사용하여 '라벨링'된다. 개념 인덱싱이 단어 대신에 그의 의미에 기초하여 정보가 검색 또는 관리될 수 있게 해주기 때문에, 훨씬 더 효율적이고 내결함성이 있으며 지능적인 대화 관리 애플리케이션이 개발될 수 있다. 이 클러스터화 프로세스를 통해, CRE는 또한 클러스터들 간의 천이(즉, 통화 흐름)를 추출하고 나중에 자유-형식 고객 문의를 통화 로그에서 발견되는 에이전트 응답에 매핑하는 인덱스를 생성한다.

런 타임 시에, 어떤 예에서, CRE는 실시간으로 고객 문의에 대해 이 동일한 프로세스를 수행한다. CRE는 음성 인식 엔진으로부터 출력을 받아서 이를 형태학적 분석 기술을 사용하여 그의 연관된 형태소 세트로 분해한다. 시스템은, 철자 오기, 구두점 실수, 및 문맥을 벗어나거나 순서가 뒤바뀐 단어들을 비롯하여, 뒤죽박죽되어 있는 입력 데이터를 잘 처리하고, 입력 구문의 길이에는 어떤 사전 설정된 제한이 없다.

이어서, CRE는 형태소를 상기한 기본 원자 개념으로 변환하기 위해 개념 분석을 사용하고, 이 일련의 원자 개념들을 전체 입력에 대한 단일의 개념 코드로 조립하며, 그 코드를 인덱싱된 데이터 내의 그의 등가 코드로 매핑한다. 대화 애플리케이션에서, 이 프로세스는 기본적으로 시스템 응답, 기존의 대화형 음성 응답(interactive voice response, IVR) 메뉴 트리, 또는 고객 계좌 정보를 얻기 위해 트랜잭션 시스템에 질의하라는 지시일 수 있는 시스템 대화 상태(system dialog state)에의 사용자 입력에 '구두점을 찍는다'.

이 프로세스는 컨택 센터 자체 서비스 애플리케이션과 관련하여 아주 모호하고 대화식의 사용자 질의를 자동적으로 인식 및 "이해"하는 안정된 수단을 생성한다.

CRE와 SLM 음성 인식의 이 조합의 효과는 자동화를 통해 정보를 고객이 이용가능하도록 만들어줄 수 있는 능력을 향상시키는 것이다. 5가지 옵션 IVR 메뉴 또는 사전 정의된 음성 문법에 깔끔하게 맞지 않는 회사 정보가 대화식 인터페이스를 통해 이용가능하게 될 수 있다. 그 결과 발생하는 고객 입력이 그와 연관된 문맥을 가지기 때문에, 시스템이 복잡한 대화를 어떻게 지능적으로 처리하느냐에 대한 더 많은 옵션이 이용가능하게 된다.

단어 공간 대신에 의미론적 인자 공간(semantic model approach)에 벡터 모 델 방식을 적용하는 것은 이하의 이점을 제공한다.

1. 단어로부터 개념으로의 천이 자체가 보다 통계적인 것에서 보다 의미론적인 것으로 옮겨간다.

2. 종래의 벡터 모델은 종종 단어들 간의 임의의 구문적 또는 의미론적 관계를 무시하는 모델의 조합적 특성에 역점을 두는 "단어 주머니 모델(bag-of-words model)"이라고 한다. 이와 유사하게, 이 벡터 모델은 "개념 주머니 모델(bag-of-concepts model)"이라고 부를 수 있다. 종래의 벡터 모델에서, 우리가 관심있는 내부 파라미터(개념)와 통계적으로 연관된 어떤 외부 파라미터(단어)를 계산한다.

3. 기본적인 언어에서조차 의미론적 인자의 수가 단어의 수보다 훨씬 더 적은 한, 벡터 모델에서의 계산 강도가 상당히 더 낮다. 신뢰도 기반 매칭 순위를 형성하기 위해 다른 기계 학습 기술이 사용될 수 있다. 예를 들어, 지원 벡터 기계의 결정 트리 도입 또는 작성을 사용할 수 있다. 부스팅(boosting)을 사용하는 학습 기술들의 조합도 역시 가능하다.

이상에서, 모델 작업, 즉 입력 언어 텍스트 객체>의미론적 라벨>출력 언어 텍스트 객체의 2-단계 사이클 전체의 개별적인 부분에 대해 기술하였다. 이 사이클에서의 2개의 단계가 명확히 독립적이라는 것을 아는 것이 중요하다. 이들은 임의의 사람 언어와 연관되어 있지 않은 내부 "언어"인 의미론적 라벨을 통해서만 연결된다. 이 특징은 임의의 응용에서 입력측 및 출력측 둘다에서 언어를 변경하는 것이 가능하고 비교적 용이하도록 만들어준다.

첫번째 단계는 본질적으로 언어 종속적이다. 이는 다른 언어로의 전환이 주 어진 언어에서의 구문에 대한 의미론적 라벨의 자동 발생을 필요로 함을 의미한다. 이하에서는, 이 문제점을 해결하는 2가지 가능한 방법에 대해 기술한다. 두번째 단계는 의미론적 인덱스(semantic index)에 기초한다. 이 인덱스 자체는 객체의 언어에 신경쓰지 않고, 단지 그것을 가리킬 뿐이며, 포인터와 연관된 의미론적 라벨은 언어-독립적이다. 의미론적 인덱스에 언어-관련 정보가 없다.

제1 방법은 새로운 언어에 대한 새로운 S-모프 사전을 컴파일하는 것이다. 각각의 사람의 기록 언어에 대해, 일련의 S-모프가 컴파일될 수 있다. 이 컴파일 프로세스는 대규모의 텍스트 코퍼스로부터 또는 이 언어의 대형 사전으로부터의 어휘의 분석에 기초할 수 있다.

하나의 언어(영어)로 된 이러한 완전한 일련의 S-모프를 갖는 것이 다른 언어로 된 유사한 일련의 S-모프를 생성하는 데 유용하다. 시작점으로서, 제2 언어에서의 형태소 등가물을 찾으려고만 시도할 수 있다. 이것은 그렇지 않았으면 노동 집약적이었을 제2 언어에서의 코퍼스 분석의 노력을 감소시켜준다. 동일한 그룹의 언어에서 언어 간에 이동할 때 특히 그러한데, 그 이유는 이러한 언어가 다수의 어휘 "자료"를 공유하기 때문이다. 일련의 스페인어 S-모프는 영어 S-모프와 거의 동일한 크기이다. 스페인어 S-모프의 예로는 LENGU, FRAS, MULTI, ESPAN, SIGUI가 있다.

이것이 행해진 후에, S-모프 식별 알고리즘의 얼마간의 조정을 필요로 할 수 있다. 이 알고리즘에 관한 좋은 소식은 그의 작업의 대부분이 동일한 그룹의 언어들에 대해 통상적이라는 것이다. 알고리즘에 어떤 변경도 없이 영어에서 스페인어 로 전환할 때에도, 그 결과는 만족스러웠다. 인도-유럽 언어 대부분에 대해 거의 변경이 필요하지 않을 수 있다. 스페인어 실험은 시스템의 언어간 기능의 능력을 보여주었으며, 스페인어 형태소를 컴파일한 후에, 입력 언어로서의 스페인어는 영어에 대해 이미 개발된 모든 응용에 가능하게 되었다.

개념 인식 엔진에 필요한 정보를 저장하기 위해 언어 지식 베이스가 사용된다. 이 지식 베이스는 3가지 주요 성분, 즉 의미론적 인자 사전(semantic factor dictionary), S-모프 사전(S-Morph dictionary) 및 동의어 사전(synonym dictionary)을 갖는다. 의미론적 인자 사전 내의 각각의 엔트리는 이하의 것을 포함한다.

a) 의미론적 인자 이름,

b) 의미론적 인자 정의/설명,

c) 이 의미론적 인자를 사용하는 단어 개념 코드의 예.

S-모프 사전 내의 각각의 엔트리는 이하의 것을 포함한다.

a) S-모프 텍스트,

b) 별도의 부분(폴리세믹 형태소(polisemic morpheme)의 대안의 의미에 대한 의의소(sememe))을 갖는 의미론적 인자 개념 코드,

c) 다중인자 코드에서, 수정이 적용될 수 있는 헤드 인자(head factor)에 대한 라벨.

개념 인식 엔진의 기능 블록도가 도 9에 도시되어 있다. 이 도면의 블록들에 대해 다음과 같이 설명한다. S-모프 사전(122) 및 의미론적 인자 사전(124)은 일련의 개념 코드를 생성하기 위해 분석기(128)에서 사용된다.

그 다음에, 예제(142)에 기초하여 CML 파일이 생성된다. 이 결과, 씨소러스(thesaurus)에 기초하여 구동되는 데이터인 CML 파일이 얻어진다. 그 다음 단계는 CML 파일의 탐색 및 편집을 행하는 것이다. 이 탐색 및 편집은 이하의 단계들로 이루어져 있다.

a) 서로 다른 검색 기준으로 문자열 출현을 디스플레이하는 단계,

b) 새로운 대체 구문(paraphrase)을 추가하는 단계,

c) 새로운 질문-대답쌍을 추가하는 단계,

d) 하나의 대체 구문 또는 몇개의 대체 구문을 제거하는 단계,

e) (모든 대체 구문과 함께) 하나의 질문-대답쌍 또는 몇개의 쌍을 제거하는 단계,

f) (입력 및 출력 구문의 선택으로) 2개의 질문-대답쌍을 병합하는 단계,

g) 입력 및 출력 구문의 할당으로 하나의 쌍을 2개의 쌍으로 분할하는 단계,

h) 구문을 편집하는 단계(그룹 편집을 포함함).

그 다음에, CML 파일이 임의의 편집 시점에서 입력 정보로서 취해지고, 인덱스가 작성된다. 그 후에, 2개의 엔트리가 매칭되고, 지정된 CML/인덱스로 유사성 계산이 행해진다. 이것은, 2개의 구문에 대해, 2개의 개념 코드에 대해, 하나의 구문 및 하나의 개념 코드에 대해, 입력들 중 하나가 피드되는 입력으로부터 매번마다 들어오는 경우의 순환 모드(cyclic mode)에서 2개의 구문에 대해, 2개의 개념 코드에 대해, 또는 하나의 구문 및 하나의 개념 코드에 대해, 및 입력들 중 하나가 피드되는 입력으로부터 매번마다 들어오고 그 결과가 출력 파일에 저장되는 경우의 자동 매칭 및 유사성 계산에 대해, 행해진다. 그 다음에, 이름에 대한 의사인자(pseudofactor)를 생성하는 것, 단일-단어 및 다중-단어 개인 이름을 처리하는 것, 기업 및 제품에 대한 단일-단어 및 다중-단어 이름을 처리하는 것, 및 품사 태그를 발생하는 것에 의해 분석전 파싱(preanalysis parsing)이 행해진다.

이 시점에서, 애플리케이션 제어 및 테스팅이 수행된다. 이것은 이하의 단계들로 이루어져 있다.

a) 주기적으로 또한 자동적으로 입력 대화의 파일을 분석하는 단계(동일한 파일에 대한 이전의 처리와의 차이가 디스플레이되거나 출력 파일로 전송됨),

b) 유사성 문턱값의 제어,

c) 델타 간격(제1 및 제2 매칭 간의 유사성의 차이),

d) 반환된 매칭의 수의 제어.

대화 마크업 언어(CML) 주요 목표는 자동 또는 반자동 방식으로 고객과의 "대화"를 처리하기 위해 대화 서버에 대한 일련의 명령어를 지정하는 것이다. 자동화된 대화는 처음부터 끝까지 전적으로 대화 서버에 의해 처리되는 대화이다. 반자동화된 대화는 처음에는 대화 서버에 의해 처리되고, 그 다음에는 수집된 정보와 함께 사람 에이전트로 넘겨진다.

CML은 이하의 것들을 지정하는 마크업 언어이다.

대화 서버가 처리할 수 있는 대체 구문을 비롯한 고객 입력,

응답하기 위한 대화 서버 출력(예를 들어, TTS 및/또는 오디오 파일),

대화의 흐름. 이 흐름은 이하의 것들을 포함하는 일련의 상태 천이 네트워크를 사용하여 기술된다.

각각의 입력 및 출력이 발생할 수 있는 컨텍스트.

고객 입력 및 Java 객체로부터의 결과에 기초한, 다른 컨텍스트로의 천이.

백엔드 비지니스 계층 객체에 대한 호출.

인라인 애플리케이션 로직.

대화 서버와 사용자 간의 대화를 기술하기 위한 CML 언어에 부가하여, CMLApp 언어는 애플리케이션이 재사용가능한 컴포넌트로부터 작성될 수 있게 해준다.

어떤 예에서, CML은 이하의 것들을 포함하는 특정의 고객 지원 컨택 센터에서 일반적으로 발견되는 요청/응답 상호작용을 기술한다.

주식 시세, 펀드 안내서 요청, 기타 등등의 일반적인 정보 요청.

계좌 잔고, 거래 내역, 기타 등등 고객 관련 요청.

주식/펀드 거래, 기타 등등의 고객 개시 거래.

텔레마케팅 등의 센터-개시 상호작용.

CML은 대화 서버(CS)에 의해 해석되고 실행되도록 설계되어 있다. 앞서 설명한 바와 같이, CS는 CML 기반 애플리케이션을 해석하는 일련의 소프트웨어 에이전트를 갖는다. 이들 에이전트는 HTML, VoiceXML, SIMPL, SMTP 등의 채널 관련 문 서 언어와 CML의 채널 독립적인 표현 간에 또한 그 반대로 변환을 행하는 일련의 대화 채널과 직면하고 있다.

CML 문서(또는 애플리케이션이라고 하는 일련의 문서)는 소프트웨어 에이전트의 사용자와의 대화를 기술하는 대화 상태 천이 네트워크를 형성한다. 사용자는 항상 한번에 하나의 대화 상태 또는 컨텍스트에 있다. 일련의 천이는 대화가 새로운 컨텍스트로 이동하는 조건을 정의한다. 이들 조건은 사용자로부터의 새로운 요청, 대화 내에서의 특정의 상태, 또는 이 둘의 조합을 포함한다. 최종 컨텍스트에 도달될 때 실행이 종료된다.

소프트웨어 에이전트와 사용자 간의 대화인 상태 천이 네트워크를 정의하기 위해 4개의 요소, 즉 네트워크, 컨텍스트, 서브컨텍스트 및 천이가 사용된다.

네트워크는 소프트웨어 에이전트가 사용자와 하는 대화를 정의하는 컨텍스트(상태) 및 천이의 집합체이다. CML 문서마다 하나 이상의 네트워크가 있을 수 있으며, 각각의 네트워크는 그를 참조하는 데 사용되는 고유한 이름을 갖는다. 사용자와의 대화의 구문을 정의하는 것 이외에, 네트워크는 네트워크가 능동적으로 실행하고 있는 동안에 활성인 일련의 속성을 정의한다. 이들 속성은 사용자로의 출력에 제공되고 있는 데이터는 물론, 네트워크의 실행을 통제하는 데이터를 보유한다. 예를 들어, 천이의 사전-조건(pre-condition) 및 컨텍스트의 사후-조건(post-condition)이 속성의 관점에서 정의된다.

컨텍스트는 소프트웨어 에이전트와 사용자 간의 대화 내에서의 상태를 나타낸다. 각각의 컨텍스트는 애플리케이션을 다른 컨텍스트로 가게 하는(또는 동일한 컨텍스트로 루프백하는) 정의된 일련의 천이를 갖는다. 컨텍스트는 사용자의 요청이 예상되고 해석될 것인 상태를 나타낸다. 어떤 컨텍스트는 최종 컨텍스트로서 표시되어 있다. 최종 컨텍스트는 네트워크에 의해 표현된 대화의 종료를 나타낸다.

서브컨텍스트는 내포 네트워크(containing network)의 컨텍스트 내에서 다른 네트워크가 호출되는 특수 컨텍스트이다. 서브컨텍스트는 링크된 서브루틴 호출이며, 호출측 및 피호출측 네트워크의 속성의 바인딩(binding)이 있다. 서브컨텍스트는 모달(modal) 또는 비모달(non-modal)일 수 있다. 모달 서브컨텍스트에서, 그의 내포 네트워크(및 조상)의 천이는 비활성이다. 비모달 서브컨텍스트에서, 그의 내포 네트워크(및 조상)의 천이는 활성이다.

천이는 한 컨텍스트에서 다른 컨텍스트로의 변화를 정의한다. 그의 사전 조건이 만족되는 경우 및/또는 사용자 요청이 그 천이와 연관된 구두 표현의 클러스터와 매칭하는 경우 천이가 행해진다. 천이가 사전 조건을 정의하지 않는 경우, 사용자 요청과 천이의 구두 표현 간의 매칭만이 천이를 트리거해야 한다. 천이가 구두 표현의 클러스터를 정의하지 않는 경우, 천이는 그의 사전 조건이 참일 때마다 트리거된다. 사전 조건도 구두 표현의 클러스터도 정의되지 않은 경우, 천이는 자동적으로 트리거된다. 천이의 트리거링의 결과 천이 스크립의 실행 및 천이에 의해 가리켜진 컨텍스트로의 천이가 있게 된다.

어떤 예에서, CML 애플리케이션은 단일의 CMLApp 문서, 단일의 CML 문서, 및 클러스터 문서를 필요로 한다. 다중-문서 애플리케이션은 단일의 CMLApp 문서, 단 일의 클러스터 문서, 및 다수의 CML 문서를 필요로 한다. 도 10은 CMLApp 문서(150), CML 문서(154), 클러스터 문서(152), 출력 문서(156), 참조된 데이터 파일(158), 및 비지니스 객체(160)의 관계를 나타낸 것이다.

부록 1은 "abc12app.ucmla"라는 이름의 CMLApp 문서, "abc12clusters.ucmlc"라는 이름의 CML 클러스터 문서, 및 "abc12ucml.ucml"이라는 이름의 CML 문서서의 예의 텍스트를 나타낸 것이다. CMLApp 문서는 마크업 "clusterFile"을 사용하여 클러스터 파일을 지정하고, 마크업 "document"를 사용하여 CML 파일을 지정한다. CMLApp 문서는 또한 마크업 "channel type"을 사용하여 고객과의 통신의 채널을 지정한다. 이 경우에, 채널 유형은 "VXML"이다. 먼저, 클러스터 문서는 주어진 상태 또는 컨텍스트로부터의 주어진 천이에 대한 클러스터로 함께 그룹화되어 있는 고객으로부터의 기록된 통신 전부의 텍스트를 저장한다. 이 예시적인 클러스터 문서에서, 클러스터는 c1에서 c41의 이름을 가지고 있다. 클러스터와 연관된 데이터 변수는 마크업 "variable"를 사용하여 지정되고, "properName" 및 "digitString" 등의 유형을 갖는다. 이들 클러스터는 예시적인 CML 문서에서 참조된다. CML 문서는 상태 천이 그래프(또는 네트워크)를 정의한다. 예시적인 CML 문서는 일련의 상태(마크업 "context name"으로 표시됨) 및 천이(마크업 "transition name"으로 표시됨)를 정의한다. 예를 들어, CML 문서의 11 내지 16행은 다음과 같다.

"<context name="s0" final="false" toToAgent="false">.

<transitions>

<transition name="t0" to="sl">

<input cluster="c7"> yeah I'd like to check on the my

account balance please </input>

<output> do you have your account number sir </output>

</transition>

11-16 행은 상태(또는 컨텍스트) s0로의 천이 t0를 갖는 상태(또는 컨텍스트) s0가 있음을 규정한다. 천이 t0는 고객 통신 "yeah I'd like to check on the my account balance please" 및 컨택 센터 응답 "do you have your account number sir"이다. 도 11은 예시적인 CML 문서에 의해 정의되는 전체적인 상태 천이 그래프의 서브셋을 나타낸 것이다. 이 서브셋은 초기 상태로부터 s0(162)로, s1(164)로, s2(166)로, s3(168)로, s4(170)로, s5(172)로, s6(174)로, 그리고 마지막으로 s7(176)으로의 천이를 포함한다.

도 12를 참조하면, 자동 음성 응답 시스템에 대한 CML 애플리케이션의 개발을 위한 프로세스(180)는 2개의 주된 기계 학습 프로세스, 즉 초기 애플리케이션 개발 프로세스(182) 및 런타입 학습 프로세스(190)를 포함한다. 초기 애플리케이션 개발 프로세스(182)는 기록된 사람 에이전트-통화자 대화의 샘플을 사용하여 초기 CML 애플리케이션을 생성한다. 런타임 학습 프로세스(190)는 CML 애플리케이션을 계속하여 향상시키기 위해 기록된 시스템-통화자 대화의 샘플을 사용한다.

일련의 전사된 사람 에이전트-통화자 대화(181)는 초기 애플리케이션 개발 프로세서(182)에 입력된다. 전사된 에이전트-통화자 대화(181)는, 수동 전사 프로세스 또는 자동 전사 프로세스(예를 들어, 종래의 음성 인식 프로세스)를 사용하여 텍스트로 전사된, 사람 고객 지원 에이전트와 통화자 간의 기록된 대화이다. 사람 에이전트와 통화자가 전화로 통신하는 컨택 센터에서, 에이전트-통화자 대화의 샘플은 컨택 센터의 품질 보증 오디오 기록 설비로부터 획득될 수 있다. 한 구현에서, 샘플 사람 에이전트-통화자 전사본은, 초기 애플리케이션 개발 프로세스(182)에 공급될 때, IML(Import Markup Language) 파일의 형태로 되어 있다.

초기 애플리케이션 개발 프로세서(182)는 초기 CML 애플리케이션을 작성하기 위해 샘플 전사본을 사용한다. 초기 애플리케이션 개발 프로세스(그의 일례가 도 15 및 도 16에 보다 상세히 기술되어 있음)는 이하의 3가지 단계를 포함한다.

1. 분류자 작성(Build Classifier). 이 단계에서, 에이전트 구두 표현 및 통화자 구두 표현에 대한 일련의 분류자가 기록된 사람 에이전트-통화자 대화의 샘플을 사용하여 작성된다. 애플리케이션이 배치되고 온라인 상태로 되면, 이들 분류자는 통화자 구두 표현을 분류하는 데 사용된다. 통화자 구두 표현이 분류된 후에, 소프트웨어 에이전트는 유한 상태 네트워크를 사용하여 적절한 응답을 결정할 수 있다. 애플리케이션의 배치 이전에, 유한 상태 네트워크를 발생하기 위해 또한 정보에 대한 효과적인 에이전트 요청을 식별 및 개발하기 위해 2개의 분류자 세트가 사용될 수 있다.

2. 유한 상태 네트워크 발생. 이 단계에서, 대화는 서브 컨텍스트(subContext)를 사용하여 유한 상태 네트워크 또는 컨텍스트 없는 네트워크(context free network)로서 포착된다. CML 요소, 즉 컨텍스트(또는 상태)는 주된 상태 정의 구조(principal state definition construct)이다.

3. 코드 삽입 단계. 이 단계에서, 상태 네트워크는 대화와 연관된 자동화를 실시하기 위해 애플리케이션에 포함된다. 분류자가 작성되는 단계와 관련하여, 먼저 에이전트 구두 표현을 일련의 분류자로 클러스터하고 이어서 통화자 구두 표현을 찾아내어 분류하는 데 그 에이전트 분류자를 사용하는 것이, 특히 콜 센터에서, 유익할 수 있다.

콜 센터 애플리케이션에서, 통화자와 사람 에이전트 간의 대화는 일반적으로 에이전트에 의해 제어된다. 실제로, 에이전트는 종종 통화자와의 대화 동안에 표준화된 스크립트를 따르도록 지시받는다. 이들 스크립트는, 통화자 문의에 대한 대답이 신뢰성있고 효율적인 방식으로 제공되도록, 에이전트-통화자 대화를 감독하고 제약하기 위한 것이다. 사람 에이전트에 대한 통상의 규칙은 사람 에이전트가 대화 흐름의 제어를 결코 상실해서는 안된다는 것이다.

통화자 및 에이전트 구두 표현이, 예를 들어, TF-IDF(Term-Frequency-Inverse Document Frequency) 알고리즘을 사용하여, 구두 표현의 의미에 기초하여 클러스터화된 경우에, 에이전트 및 통화자 클러스터의 분포가 아주 다르게 보인다.

통화자 구두 표현 클러스터의 분포는 적은 아주 통상적인 응답 클러스터(예를 들어, 통화자가 번호를 말하거나 자신의 신원을 밝힌 구두 표현의 클러스터), 그에 뒤따르는 비교적 적은 수의 덜 통상적인 응답에 대한 급속한 클러스터 빈도수의 감소 및 아주 긴 테일의 싱글톤 클러스터(singleton cluster)를 갖는 경향이 있다. 싱글톤 클러스터는 일반적으로 총 통화자 구두 표현의 절반을 차지하며, 총 클러스터의 약 90-95%를 구성한다. 자동 음성 응답 시스템의 설계에 대한 가장 중 요한 유형의 통화자 구두 표현 중 하나를 나타내는, 정보에 대한 통화자의 초기 요청을 나타내는 구두 표현(예를 들어, "내 계좌 잔고가 얼마입니까?")은 일반적으로 전체 구두 표현 중 아주 작은 비율(통화 길이에 따라, 매 20-30개 구두 표현 중 약 1개)을 형성한다. 특정의 요청이 표현될 수 있는 많은 방식이 있기 때문에, 이들 초기 통화자 요청 구두 표현 유형은 보통 전체 분포에 걸쳐 배열되어 있으며, 많은 구두 표현이 그의 싱글톤 카테고리에 속한다.

에이전트 구두 표현 클러스터의 분포는, 에이전트 구두 표현의 스크립트된 특성으로 인해, 일반적으로 통화자 구두 표현 클러스터의 분포와 많이 다르다. 상세하게는, 에이전트 구두 표현 클러스터의 분포는 통화자에 대해 관찰된 분포보다 훨씬 더 균일하며, 가장 통상적인 구두 표현 클러스터에 대한 전체적인 빈도수가 더 낮고 클러스터 빈도수의 훨씬 더 점차적인 감소가 있다. 에이전트가 종종 통화자와의 통화에 관여하고 있기 때문에, 에이전트 구두 표현 클러스터의 분포는 또한 긴 테일의 싱글톤을 갖는다. 콜 센터 환경에서 에이전트와 통화자 클러스터의 분포 간의 다른 차이점은 높은 빈도수의 에이전트 클러스터가 정보 수집 질의(예를 들어, "당신의 사회 보장 번호가 무엇입니까?")(이는 자동 음성 응답 시스템의 설계에 대한 가장 중요한 구두 표현임)를 포함하는 경향이 있다는 것이다. 실제로, 클러스터의 가장 빈번한 20%를 분석함으로써 중요한 에이전트 거동(예를 들어, 정보에 대한 에이전트 요청)의 거의 전부를 특징지우는 것이 종종 가능하다.

도 15를 참조하면, 초기 애플리케이션 개발 프로세스(182)는 먼저 일련의 에이전트 분류자를 발생하고 이어서 이 일련의 에이전트 분류자를 사용하여 일련의 통화자 분류자를 식별 및 발생하는 에이전트-중심의 데이터 마이닝 기술을 사용한다.

초기 애플리케이션 프로세스(182)는 텍스트로 전사된 통계적으로 중요한 수의 사전 기록된 통화자-에이전트 대화(181)를 입력으로서 수신하고, 이어서 중요한 에이전트 클러스터(예를 들어, 에이전트가 통화자로부터 정보를 도출하는 구두 표현을 갖는 클러스터)가 식별된다. 이어서, 이들 중요한 에이전트 클러스터는 기계 학습 프로세스, 예를 들어, 지지 벡터 기계(Support Vector Machine, SVM)를 훈련시키기 위해 사용되고(즉, 그에 입력되고)(단계 304), 그로부터 일련의 에이전트 분류자가 생성된다.

에이전트 분류자가 생성되면, 이들 분류자는 전사된 대화 내에서 통화자 응답을 찾아내는 데 사용된다(단계 306). 이들 통화자 구두 표현은 이어서 일련의 통화자 클러스터로 클러스터화된다(단계 307). 이들 클러스터화된 통화자 구두 표현은 이어서 기계 학습 프로세스, 예를 들어 지지 벡터 기계를 훈련시키는 데 사용되고(즉, 그에 입력되고)(단계 308), 그로부터 일련의 통화자 분류자가 발생된다. 일련의 에이전트 및 통화자 분류자가 결정된 후에, 이들은 새로운 대화 전사본에서 에이전트 및 통화자 구두 표현을 분류하는 데 사용될 수 있다. 이어서, 중요한 에이전트 질의에 대한 적절한 통화자 응답이 이 새로운 전사본으로부터 추출되어 통화자 클러스터에 추가된다. 이어서, 이들 증강된 통화자 클러스터는 새로운 개선된 통화자 분류자를 작성하는 데 사용된다(단계 310).

일련의 전사된 대화가 주어지면(이 대화의 구두 표현은 일련의 에이전트 및 통화자 분류자를 사용하여 분류되어 있음), 규범적 에이전트 대화 패턴(canonical agent conversation pattern)이 식별될 수 있다(단계 312). 규범적 대화 패턴은 특정의 유형의 통화자 요청에 응답하여 에이전트에 의해 사용되는 정보 요청 및 대답의 통상적인 패턴이다. 예를 들어, 통화자가 에이전트에 연락하고 그의 계좌 잔고를 요청할 때, 에이전트들 간의 통상적인 응답 패턴은 질문 X(예를 들어, 이름이 무엇입니까?)를 묻고, 이어서 질문 Y(예를 들어, "사회 보장 번호가 무엇입니까?")가 오며, 이어서 질문 Z(예를 들어, "어머니의 결혼전 이름은 무엇입니까?")가 온다. 반면에, 통화자가 문헌을 요청하는 경우, 에이전트의 질문 X에 뒤따라서 질문 A(예를 들어, "우편 번호가 무엇입니까"") 및 질문 B(예를 들어, "주소가 몇번가입니까"")가 올 수 있다. 이들 규범적 대화 패턴은 애플리케이션에 대한 유한 상태 네트워크를 발생하는 데 사용될 수 있다(단계 314).

게다가, 전사된 대화에서의 분류된 에이전트 및 통화자 구두 표현의 쌍들은 정보에 대한 성공적인 에이전트 요청을 식별하는 데 사용될 수 있다(단계 316). 동일한 정보를 도출하기 위한 것인 서로 다르게 표현된 에이전트 질문에 대한 통화자 응답의 유형의 분포를 조사하면 정보를 요구하는 한 방식이 다른 방식들보다 효과적이라는 것을 알 수 있다. 예를 들어, "사회 보장 번호가 무엇입니까?"라고 표현된 제1 에이전트 요청은 통화자의 사회 보장 번호를 제공하지 않고 상당한 수의 "예"라는 통화자 응답을 가질 수 있다. 그렇지만, "사회 보장 번호가 무엇입니까?"라고 표현된 에이전트 요청을 분류하는 다른 에이전트 분류자는 질문에 대한 통화자 응답의 아주 높은 비율이 요청된 정보(즉, 통화자의 사회 보장 번호)를 제공하는 분포를 생성할 수 있다.

초기 애플리케이션 개발 프로세스의 한 예는 도 16a 내지 도 16e에 보다 상세히 도시되어 있다.

도 16a에 나타낸 바와 같이, 초기 애플리케이션 개발 소프트웨어 툴은 기록된 사람 에이전트-통화자 대화의 2개의 동일 크기의 랜덤하게 선택된 샘플(318), 훈련 세트 및 테스트 세트를 수집한다(단계 322). 이어서, 애플리케이션 개발자는 통화자의 초기 통화자 요청에 따라 각각의 샘플로부터의 통화를 일련의 버킷으로 분류한다(324a, 324b). 예를 들어, 통화자가 그의 계좌 잔고를 요청한 통화가 하나의 버킷에 위치될 수 있는 반면, 통화자가 주소의 변경을 요청한 통화는 별도의 버킷에 위치될 수 있다.

애플리케이션 개발자가 통화를 버킷으로 분류한 후에, 애플리케이션 개발자는 소프트웨어 툴을 사용하여 각각의 일련의 통화에 대해 초기 통화자 요청의 분포를 검사한다(단계 326). 통화의 훈련 세트 및 테스트 세트의 분포가 유사하지 않는 경우, 애플리케이션 개발자는 랜덤하게 선택된 통화의 더 큰 샘플을 획득하고(단계 330), 훈련 세트 및 테스트 세트가 유사한 통화-유형 분포를 나타낼 때까지 버킷팅 프로세스(bucketing process)를 반복한다.

훈련 세트 및 테스트 세트가 유사한 통화-유형 분포를 갖는 것으로 판정되면, 애플리케이션 개발자는 훈련 세트에서의 통화의 에이전트 구두 표현을 클러스터화하기 위해 소프트웨어 툴을 사용한다(단계 328). 에이전트 구두 표현을 클러스터화하기 위해, 소프트웨어 툴은 각각의 구두 표현에 대한 의미론적 특징의 리스 트를 결정하기 위해 개념 인식 엔진(앞서 보다 상세히 기술함)을 통해 구두 표현을 실행하고, 이어서 그의 의미론적 특징의 리스트에 기초하여 구두 표현을 클러스터화하기 위해 TF-IDF 알고리즘을 사용한다.

도 16b를 참조하면, 애플리케이션 개발자는 에이전트 클러스터를 검사하고, 임의의 중복하는 클러스터를 병합하며(단계 334), 분류에 사용하기 위해 어떤 수보다 많은 구두 표현(예를 들어, 4개보다 많은 구두 표현)을 갖는 에이전트 클러스터를 승인한다(단계 336). 애플리케이션 개발자는 일반적으로 모든 에이전트 클러스터를 분류하지 않는데, 그 이유는 발생 빈도가 낮은 클러스터가, 에이전트가 통화자로부터 중요한 정보를 도출한, 에이전트 구두 표현(예를 들어, "이름이 무엇입니까?")이 될 가능성이 없기 때문이다. 오히려, 낮은 빈도의 클러스터(예를 들어, 싱글톤 클러스터)는, 에이전트가 통화자를 대화에 참여시킨, 에이전트 구두 표현(예를 들어, 그곳 날씨는 오늘 어떻습니까?)을 포함할 가능성이 있다.

애플리케이션 개발자가 (예를 들어, 소프트웨어 툴의 그래픽 사용자 인터페이스를 사용하여) 클러스터를 승인한 후에, 애플리케이션 개발자는 승인된 클러스터에서의 구두 표현의 개념적 특징(즉, 훈련 데이터)에 기초하여 일련의 분류자를 생성하도록 소프트웨어 툴에 명령한다. 일련의 분류자는 기계 학습 프로세스(예를 들어, 결정 트리, 지원 벡터 기계)의 출력이다. 이 분류자는 각각의 새로운 구두 표현이 훈련 세트 중의 어느 클러스터와 가장 유사한지를 결정하는 데 사용된다. 양호한 구현에서, 소프트웨어 툴은 지원 벡터 기계(SVM) 기계 학습 프로세스를 사용하여 일련의 분류자를 작성한다. 이 프로세스는, 모든 다른 것과 비교되는 각각 의 클러스터에 대해 하나씩, 일련의 쌍별 구분자(pairwise discriminator)를 생성하며, 이는 이어서 새로운 구두 표현에 적용된다. 가장 많은 수의 비교에서 "이긴" 클러스터는 새로운 구두 표현이 귀속되어야만 하는 클러스터인 것으로 판정된다. 예를 들어, 분류자가 3개의 클러스터에 대한 SVM을 사용하여 작성되는 경우, 이 분류자는 클러스터 1을 클러스터 2에, 클러스터 1을 클러스터 3에, 또한 클러스터 2를 클러스터 3에 비교하기 위한 일련의 3개의 쌍별 구분자를 갖는다. 새로운 구두 표현이 분류자에 제공될 때, 3개의 비교 각각은 구두 표현의 의미론적 인자(대화 인식 엔진에 의해 결정됨)에 적용된다. 가장 많은 수의 비교를 "이긴" 클러스터가 어느 것이든 그 클러스터는 구두 표현이 귀속되어야만 하는 클러스터인 것으로 간주된다.

일련의 에이전트 클러스터가 작성되었으면, 분류자의 무결성을 검증하기 위해 통화의 훈련 세트가 분류자에 피드된다(단계 340). 분류자의 무결성은, 분류자가 훈련 세트의 에이전트 구두 표현를 귀속시킨 클러스터를, 에이전트 분류자의 발생 이전에 에이전트 구두 표현이 분류된 클러스터와 비교함으로써, 검사된다. 분류자가 훈련 세트를 분류하지 않아서 분류자가 어떤 검증 기준을 만족시키지 않게 되어 있는 경우(예를 들어, 분류자는 훈련 세트 내의 에이전트 구두 표현의 적어도 98%를 그의 적당한 클러스터로 분류해야만 함), 애플리케이션 개발자는 원래의 클러스터를 조정하고(단계 344) 에이전트 분류자(338)를 재작성한다.

분류자가 검증 기준을 만족시키는 경우, 통화의 테스트 세트 내의 에이전트 구두 표현은 분류자를 사용하여 주석 첨부된다(단계 346). 이것은 에이전트 구두 표현이 분류되었고 이 구두 표현이 가장 유사한 것으로 생각되는 클러스터를 식별해주는 태그가 각각의 에이전트 구두 표현과 연관되어 있음을 의미한다. 예를 들어, 에이전트 구두 표현 "사회 보장 번호가 무엇입니까?"는, 에이전트 구두 표현이 에이전트의 통화자 사회 보장 번호의 요청에 대응하는 클러스터에 분류되어 있음을 나타내는, 태그 "REQ_SSN"으로 주석 첨부될 수 있다.

테스트 세트 내의 에이전트 구두 표현에 주석 첨부를 한 후에, 애플리케이션 개발자는 주석을 검토하고 에이전트 구두 표현이 정확하게 분류되었는지 여부에 따라 주석 첨부된 테스트 세트에 점수를 매긴다(단계 348). 예를 들어, 에이전트 구두 표현 "사회 보장 번호가 무엇입니까?"가 "REQ_ADDRESS"로서 분류되는 경우, 애플리케이션 개발자는 이 분류를 잘못된 것으로 점수를 매긴다. 점수(예를 들어, 정확한 분류의 비율)가 타당한 것으로(단계 350) 애플리케이션 개발자가 만족하지 않는 경우, 애플리케이션 개발자는 원래의 클러스터를 조정하고(단계 344) 에이전트 분류자(338)를 재작성한다.

테스트 세트가 타당한 점수를 획득한 것으로 애플리케이션 개발자가 만족하는 경우, 현재의 에이전트 분류자는 "골드급(golden)" 에이전트 분류자로서 설정된다.

도 16c를 참조하면, 일련의 통화자 초기 요청 분류자를 개발하는 프로세스가 도시되어 있다. 통화자 초기 요청은 통화자가 전화를 한 1차적 이유(들)를 식별해주는 구두 표현(예를 들어, 통화자의 현재 계좌 잔고의 요청, 주소 변경의 요청, 기타 등등)을 말한다.

도 16c에 도시한 바와 같이, 통화의 훈련 세트의 에이전트 구두 표현은 소프트웨어 툴을 사용하여 "골드급" 에이전트 분류자로 주석 첨부된다(단계 354). 이어서, 소프트웨어 툴은 통화자의 초기 요청에 대한 에이전트의 요청에 대응하는 에이전트 분류자(예를 들어, "어떻게 도와드릴까요?"에 대응하는 분류자)에 대한 통화자 응답을 클러스터화한다(단계 356).

이어서, 클러스터화된 통화자 초기 요청은 (예를 들어, 지원 벡터 기계를 사용하여) 통화자의 초기 요청에 대한 일련의 분류자를 작성하는 데 사용된다(단계 358).

통화자의 초기 요청에 대응하는 통화자 구두 표현의 수가 적기 때문에(보통 통화당 단지 하나의 초기 요청), 애플리케이션 개발자는, 예를 들어, 통화의 텍스트를 판독하고 각각의 통화에 대한 초기 요청(들)을 클러스터에 위치함으로써, 통화자 요청 구두 표현을 수동으로 식별하도록 선택할 수 있다(단계 360).

초기의 일련의 통화자 초기 요청 분류자가 작성된 경우, 분류자를 통해 통화의 훈련 세트를 피드하고 분류자가 훈련 세트의 통화자 초기 요청 구두 표현을 귀속시킨 클러스터를, 통화자 초기 요청 분류자의 발생 이전에 통화자 초기 요청 구두 표현이 분류된 클러스터를 비교함으로써, 분류자가 검증된다(단계 362). 분류자가 훈련 세트를 분류하지 않아서 분류자가 어떤 검증 기준을 만족시키지 않는 경우(예를 들어, 분류자는 훈련 세트 내의 통화자 초기 요청 구두 표현의 적어도 95%를 그의 적당한 클러스터로 분류해야만 함), 애플리케이션 개발자는 원래의 클러스터를 조정하고(단계 366) 통화자 초기 요청 분류자를 재작성한다(단계 358).

검증 기준이 만족되는 경우, 통화의 테스트 세트는 통화자 초기 요청 분류자로 주석 첨부되고(단계 368) 이어서 애플리케이션 개발자에 의해 검토되고 점수가 매겨진다(단계 370). 초기 요청 분류자로 타당한 점수가 얻어지지 않는 경우, 애플리케이션 개발자는 클러스터를 조정하고 분류자를 재작성한다. (유의할 점은, 클러스터가 테스트 세트로부터 수집된 정보에 기초하여 조정되는 경우, 조정된 클러스터로부터 작성된 SVM의 평가는 새로운 일련의 테스트 데이터를 바탕으로 테스트되어야만 한다는 것이다.) 초기 요청 분류자로 타당한 점수가 얻어지는 경우, 통화자 초기 요청 분류자의 예비 세트(374)가 형성된다.

도 16d를 참조하면, 에이전트 정보 요청에 대한 일련의 비초기 통화자 응답을 작성하는 프로세스가 도시되어 있다. 도 16d에 도시된 프로세스는 도 16c에 도시된 프로세스와 유사하다. 도 16c에 도시된 프로세스와 같이, 도 16d에 도시된 프로세스는 통화자 구두 표현을 찾아내기 위해 "골드급" 에이전트 분류자를 사용한다. 그렇지만, 도 16d에 도시한 프로세스에서, 분류된 통화자 구두 표현은 비초기 요청 정보에 대한 에이전트의 요청에 대응하는 그 구두 표현(즉, 통화자가 통화자의 통화 목적을 위한 에이전트의 요청 이외의 에이전트의 정보 요청에 응답한 통화자 구두 표현)이다. 통화자의 이름, 주소, 사회 보장 번호, 및 생일에 대한 에이전트의 요청에 대한 통화자 응답은 비초기 요청 정보에 대한 에이전트의 요청에 대응하는 통화자 구두 표현이 예이다.

도 16d에 도시한 바와 같이, 통화의 훈련 세트의 에이전트 구두 표현은 소프트웨어 툴을 사용하여 "골드급" 에이전트 분류자로 주석 첨부된다(단계 376). 이 어서, 소프트웨어 툴은 통화자 응답을, 통화자의 초기 요청이 아닌 에이전트의 정보 요청에 대응하는 에이전트 분류자(예를 들어, "사회 보장 번호가 무엇입니까?"에 대응하는 분류자)로 클러스터화한다(단계 378).

에이전트의 비초기 정보 요청에 대한 클러스터화된 통화자 응답은 이어서 (예를 들어, 지원 벡터 기계를 사용하여) 통화자의 비초기 응답에 대한 일련의 분류자를 작성하는 데 사용된다(단계 380).

통화자 비초기 응답 분류자의 초기 세트가 작성되었으면, 분류자를 통해 통화의 훈련 세트를 피드하고 분류자가 훈련 세트의 통화자 비초기 응답 구두 표현을 귀속시킨 클러스터를 통화자 비초기 응답 구두 표현이 분류된 클러스터와 비교함으로써, 분류자가 검증된다(단계 384). 분류자가 훈련 세트를 분류하지 않아서 이들이 어떤 검증 기준을 만족시키지 않는 경우(예를 들어, 분류자는 훈련 세트 내의 통화자 구두 표현의 적어도 98%를 그의 적당한 클러스터로 분류해야만 함), 애플리케이션 개발자는 원래의 클러스터를 조정하고(단계 386) 통화자 비초기 응답 분류자를 재작성한다.

검증 기준이 만족되는 경우, 통화의 테스트 세트는 통화자 비초기 응답 분류자로 주석 첨부되고(단계 388), 이어서 애플리케이션 개발자에 의해 검토되고 점수가 매겨진다(단계 390). 비초기 응답 분류자로 타당한 점수가 얻어지지 않은 경우, 애플리케이션 개발자는 클러스터를 조정하고(단게 386), 분류자를 재작성한다. 비초기 응답 분류자로 타당한 점수가 얻어진 경우, 통화자 비초기 응답 분류자의 예비 세트(394)가 형성된다.

비초기 통화자 응답 분류자 및 초기 통화자 요청 분류자의 예비 세트는 예비 통화자 분류자의 결합 세트를 형성하기 위해 결합된다(단계 396).

도 16e를 참조하면, 예비 통화자 분류자를 보강하는 프로세스가 도시되어 있다. 이 프로세스에서, 분류자의 성능을 향상시키기 위해 전사된 사람 에이전트-통화자 통화의 훈련 및 테스트 세트의 다수(N개)의 랜덤 샘플이 사용된다.

랜덤 샘플(예를 들어, 100개의 랜덤하게 선택된 샘플)의 제1 훈련 세트는, 소프트웨어 툴을 사용하여, "골드급" 에이전트 분류자 및 예비 통화자 분류자로 주석 첨부된다(단계 400). 이어서, 소프트웨어 툴은 대응하는 분류자의 통화자 클러스터에 에이전트의 정보 요청(통화자의 통화 이유에 대한 요청 또는 다른 정보에 대한 에이전트의 요청)에 대응하는 통화자 구두 표현의 데이터(즉, 의미론적 특징)를 추가한다. 예를 들어, "예, 123-45-6789입니다"라는 통화자 구두 표현이 통화자의 사회 보장 번호에 대한 에이전트의 요청에 응답하여 제공되는 경우, 통화자 구두 표현의 의미론적 특징이 사회 보장 번호의 응답에 대응하는 통화자 클러스터에 추가된다.

샘플 세트 내의 통화자 구두 표현으로부터의 데이터 전부가 대응하는 클러스터에 추가되면, 통화자 분류자는, 예를 들어, 지원 벡터 기계를 사용하여 재작성된다(404).

이어서, 새로 작성된 분류자를 통해 통화의 훈련 세트를 피드하고 분류자가 훈련 세트의 통화자 구두 표현을 귀속시킨 클러스터를, 통화자 분류자의 발생 이전에 통화자 구두 표현이 분류된 클러스터와 비교함으로써, 재작성된 클러스터가 검 증된다(단계 408). 새로 작성된 분류자가 훈련 세트를 분류하지 않아 이들이 어떤 검증 기준을 만족시키지 않는 경우(예를 들어, 새로운 분류자는 이전의 분류자보다 더 높은 비율의 통화자 구두 표현을 정확하게 분류해야만 함), 애플리케이션 개발자는 클러스터를 조정하고(단계 410) 통화자 분류자를 재작성한다.

검증 기준이 만족되는 경우, 통화의 테스트 세트가 통화자 분류자로 재차 주석 첨부되고(410), 분류자를 개선시키기 위해 애플리케이션 개발자에 의해 검토되고 점수가 매겨진다(단계 412). (클러스터의 조정이 행해지지 않는데, 그 이유는 새로운 데이터가 분류자를 개선시킬 것으로 가정되어 있기 때문이다.) 에이전트 및 통화자 분류자의 최종 세트가 설정되는 지점인 점근선에 새로운 분류자의 점수가 접근할 때까지, 도 16e에 도시된 프로세스가 계속될 수 있다.

애플리케이션 개발자가 시스템에 대한 유한 상태 네트워크를 개발하는 데 사용할 수 있는 규범적 에이전트 대화 패턴을 식별하기 위해, 에이전트 및 통화자 분류자의 최종 세트가 사용될 수 있다. 예를 들어, 도 16f에 도시한 바와 같이, 일련의 랜덤하게 선택된 에이전트-통화자 샘플(420)은 최종적인 에이전트 및 통화자 분류자를 사용하여 분류자 태그로 주석 첨부된다(단계 422). 이어서, 통화는 통화 유형별로 특징지워진다(단계 424). 이 단계는 애플리케이션 개발자가 주석 첨부된 에이전트-통화자 샘플을 검토하는 것에 의해 수동으로 수행될 수 있거나 각각의 통화자의 초기 요청과 연관된 네트워크 경로(들)를 최적화하는 소프트웨어 프로세스에 의해 자동적으로 수행될 수 있다.

이어서, 소프트웨어 프로세스는, 각각의 통화 유형에 대한 에이전트 요청의 시퀀스를 비교함으로써, 각각의 통화 유형에 대한 통상적인 에이전트 요청 패턴을 식별할 수 있다(단계 426). 예를 들어, 하나의 통화 유형이 계좌 잔고의 요청인 경우, 소프트웨어 프로세스는, 하나 이상의 통상적인 요청 패턴(예를 들어, 다수의 에이전트가 요청 "A"를 했고, 이어서 요청 "B"를, 이어서 요청 "C"를 함)을 식별하기 위해, 계좌 잔고에 대한 요청에 응답하기 위해 각각의 에이전트 요청 시퀀스를 검사할 수 있다. 이어서, 소프트웨어 프로세스는 예비 유한 상태 네트워크를 자동적으로 발생하기 위해 식별된 공통적인 요청 패턴(예를 들어, 각각의 통화 유형에 대한 가장 통상적인 요청 패턴)을 사용한다(단계 428). 애플리케이션 개발자는, 예를 들어 시스템에 의해 이해되지 않은 응답에 대한 재프롬프트를 가능하게 해주기 위해, 또는 시스템이 정보를 탐색하는 동안 통화자에게 기다리도록 요구하기 위해 일반적으로 예비 유한 상태 네트워크에 노드를 추가한다.

예비 유한 상태 네트워크를 발생하기 위해 통상적인 에이전트 요청 패턴을 사용하는 것에 부가하여, 애플리케이션 개발자는 또한 통화 유형을 식별하기 위해 통상적인 에이전트 요청 패턴을 사용할 수 있다. 예를 들어, 다른 통화 유형에 대한 일련의 통상적인 에이전트 요청 패턴이 식별되면, 비분석된 일련의 통화자-에이전트 대화에서의 에이전트 요청 패턴을 식별하기 위해 에이전트 분류자가 그 비분석된 일련의 통화자-에이전트 대화에 적용된다. 비분석된 일련의 통화자-에이전트 대화에서의 에이전트 요청 패턴이 기지의 통화 유형에 대한 통상적인 요청 패턴 중 하나와 매칭하는 경우, 애플리케이션 개발자(또는 애플리케이션 개발자에 의해 사용되는 소프트웨어 툴)은 통화자-에이전트 대화가 통상적인 통화자-에이전트 요청 패턴에 대응하는 통화 유형인 것으로 가정할 수 있다. 통화자-에이전트 대화의 통화 유형은, 분류자의 임의의 특정의 순서와 무관하게, 대화에 존재하는 일련의 에이전트 분류자에 기초하여 판정될 수 있다. 다른 대안으로서, 통화 유형은 대화에 존재하는 에이전트 분류자의 시퀀스에 기초하여 판정될 수 있다.

전사된 대화에서의 분류된 에이전트 및 통화자 구두 표현의 쌍은 정보에 대한 성공적인 에이전트 요청를 식별하기 위해 사용될 수 있다. 동일한 정보를 도출하기 위한 것이었던(따라서, 동일한 클러스터에 있었던) 서로 다르게 표현된 에이전트 질문에 대한 통화자 응답의 분포는 정보를 요구하는 한가지 방법이 다른 방법들보다 더 효과적이라는 것을 보여줄 수 있다. 예를 들어, "사회 보장 번호를 물어봐도 될까요?"라고 표현된 제1 에이전트 요청은 통화자의 사회 보장 번호를 제공함이 없이 상당한 수의 "예"라는 통화자 응답을 가질 수 있다. 그렇지만, "사회 보장 번호가 무엇입니까?"라고 표현된 에이전트 요청을 분류하는 다른 에이전트 분류자는 질문에 대한 통화자 응답의 아주 높은 비율이 요청된 정보(즉, 통화자의 사회 보장 번호)를 제공한 분포를 생성할 수 있다. 어느 통화자 응답 유형이 응답적(responsive)이고 어느 것이 비응답적(non-responsive)인지를 식별함으로써, 연관된 통화자 구두 표현을 보고 그 에이전트 구두 표현의 용어가 통화자의 구두 표현의 응답성에 책임이 있는지 여부를 판정하는 것이 가능하다.

다시 도 12를 참조하면, (예를 들어, 도 16a 내지 도 16f에 도시된 초기 개발 프로세스를 사용하여) 초기 CML 애플리케이션 설명(184)이 개발되었으면, 이는 대화 서버(예를 들어, 도 5 내지 도 6에 도시된 대화 서버(30))에 배치된다(단계 186). 대화 서버는 양호하게는 CML 애플리케이션의 "핫 배치(hot-deployment)"를 지원하며, 이는 새로운 버전의 CML 애플리케이션 설명이 이미 대화 서버 상에서 실행 중에 있을 때 그 설명이 재배치될 수 있음을 의미한다. 핫-배치는 양호하게는 (i) 이미 활성인 애플리케이션 세션이 종료까지 실행될 수 있도록, (ii) 한 버전의 애플리케이션(예를 들어, 프롬프트 파일, 기타 등등)에 의해 이용되는 모든 자원이 더 이상 필요하지 않을 때가지 제거 또는 대체되지 않도록, (iii) 모든 새로운 애플리케이션 세션이 가장 새로운 버전의 애플리케이션을 사용하도록, 또한 (iv) 쓸모없는 버전의 애플리케이션 및 지원 자원 전부가, 활성 애플리케이션 세션에 의해 더 이상 필요하지 않을 때, 대화 서버로부터 제거되도록 보장한다.

CML 애플리케이션 설명이 대화 서버 상에 배치되고 통화를 처리하기 시작한 후에, 대화 서버는 시스템-통화자 대화 전부를 매체 저장소(187)에 기록하고 대화 로그(188)에 대화의 로그를 생성한다.

매체 저장소(187)는 시스템-통화자 대화로부터의 원시 데이터(예를 들어, 기록된 통화자-시스템 전화 대화의 오디오 파일, 통화자-시스템 인스턴트 메시징 대화의 텍스트 파일)를 포함한다. 오디오 기록 서브시스템(도시 생략)은 최초부터(시스템이 통화를 처리하기 시작할 때부터) 통화의 종료까지의 모든 고객 통화를 기록한다. 에이전트 인수 통화의 경우, 오디오 서브시스템은 에이전트/고객 대화를 그의 종료 때까지 계속하여 기록한다. 양호한 구현에서, 오디오 기록 서브시스템은 통화자가 대화에서 말한 모든 것을 하나의 오디오 파일에 기록하고 에이전트(들)(소프트웨어 및/또는 사람 에이전트)가 말한 모든 것을 별도의 파일에 기록한 다. 게다가, 오디오 기록 서브시스템은 양호하게는 기록된 대화에서 침묵을 제거한다.

대화 로그(188)는 로깅 서브시스템(64)(도 5에 도시됨)에 의해 발생된다. 로깅 서브시스템은 대화 서버에 의해 처리되는 모든 통화를 위한 세션 객체를 생성함으로써 대화 로그(64)를 발생한다. 이 세션 객체는 이하의 데이터를 포함한다.

실행 중인 애플리케이션(대화 서버 상에서 다수의 대화 애플리케이션이 사용되고 있을 수 있다)

대화가 시스템에 의해 어떻게 처리되었는지를 나타내는 라벨(예를 들어, 자동, 혼합 또는 에이전트 인수 대화)

채널 표시자(전화, 웹, 채팅/IM, 이메일)

오디오 저장소에 저장된 연관된 오디오 파일에의 링크

이하의 것들을 포함하는 전체 대화를 연대기 순서로 표현한 것

(i) 음성 엔진에 의해 인식된 고객 입력(인식된 입력)

(ii) 완전 자동 대화(즉, 소프트웨어 에이전트에 의해 완전히 처리된 대화)의 경우, 그 표현은 또한 이하의 것을 포함한다.

대화에 있어서의 각각의 질문에 대해 주어진 대답 및 그의 매칭 점수

(iii) 혼합 대화(즉, 사람 에이전트가 시스템에 의해 제공된 대답들의 리스트로부터 대답을 선택한 대화)의 경우, 그 표현은 또한 이하의 것을 포함한다.

상위 제안된 대답(들) 및 관련 매칭 점수

에이전트에 의해 선택된 대답 및 그의 매칭 점수, 그리고 제안된 대답들의 리스트 중에서의 순위

(iv) 인수 대화의 경우, 그 표현은 또한 이하의 것을 포함한다.

사람 에이전트와 고객 간의 오디오 대화

통화 시작 시간, 통화가 사람 에이전트로 확대된 시간(적용가능한 경우), 및 통화 완료 시간을 나타내는 타임스탬프.

에이전트와 통화자 간의 대화가 거쳐간 상태의 시퀀스 및 상태 천이를 야기한 사건, 예를 들어 사람 에이전트가 특정의 응답을 선택하는 것 또는 소프트웨어 에이전트가 응답을 선택하는 것.

통화를 지원한 또는 통화를 인수한 사람 에이전트의 신원(적용가능한 경우)

백엔드 시스템(예를 들어, 통화자 요청에 응답하는 정보를 포함하는 시스템)에 대한 모든 요청의 기록 및 그 요청의 결과. 예를 들어, 애플리케이션이 고객의 계좌 잔고를 검색할 필요가 있는 경우, 그것은 백엔드 시스템에 대한 호출을 필요로 한다.

매체 저장소(187) 및 대화 로그(188)가 CML 애플리케이션에 대한 조정을 용이하게 해주기 위해 런타임 학습 프로세스(190)에 이용가능하다.

런타임 학습 프로세스(190)는 CML 애플리케이션을 발전시켜 대화를 자동화할 수 있는 시스템의 능력을 향상시키는 데 시스템의 실행 이력(대응관계 로그(188) 및 매체 저장소(187)에 포착되어 있음)이 사용되는 적응적 학습 루프를 사용한다. 보다 구체적으로는, 런타임 학습 프로세스는 시스템에게 "좋은" 학습 기회인 것으로 판정되는 통화자-에이전트 대화의 이력으로부터 어떤 에이전트-통화자 대화를 선택한다. 선택된 에이전트-통화자 대화는 에이전트-통화자 대화 전체일 필요가 없고 에이전트-통화자 대화의 단지 일부분일 수 있다. 이하의 것은 시스템을 개선시키기 위해 런타임 학습 프로세스에 의해 선택될 수 있는 통화자-에이전트 대화의 예들이다.

1. 사람 에이전트가 시스템에 의해 발생된 통화자 구두 표현에 대한 응답의 순위 리스트로부터 응답을 선택한 대화에서, 통화자 구두 표현의 의미가 사람 에이전트에 이해 선택된 응답으로부터 시스템에 의해 구별될 수 있다. 따라서, 통화자 구두 표현이 시스템에 의해 사용되는 분류자를 개선시키기 위해 학습 기회로서 선택될 수 있다. 따라서, 통화자가 장래에 유사한 구두 표현을 하는 경우, 사람 에이전트로부터의 지원 없이 시스템이 응답할 수 있는 가능성이 더 많다. 또한, 온라인 ASR에 의해 사용되는 언어 모델을 개선시키기 위해 통화자 구두 표현의 인식된 음성(온라인 ASR, 오프라인 ASR에 의해 또는 수동 전사에 의해 인식될 수 있음)이 사용될 수 있다. 따라서, 통화자자가 장래의 유사한 음성을 사용하여 구두 표현을 하는 경우, 온라인 ASR이 그 음성을 정확하게 인식할 가능성이 더 많게 된다.

2. 시스템이 통화자 구두 표현에 대한 자동 응답을 제공한 대화에서, 자동 응답에 선행하는 통화자 구두 표현이 시스템의 거동을 강화하기 위해 시스템에 의해 학습 기회로서 선택될 수 있다. 이 경우에, 통화자 구두 표현의 인식된 음성(온라인 ASR, 오프라인 ASR에 의해 또는 수동 전사에 의해 인식될 수 있음)은 온라인 ASR에 의해 사용되는 언어 모델을 개선하기 위해 및/또는 통화자 구두 표현의 의미를 구별하는 데 사용되는 분류자를 개선하기 위해 사용될 수 있다.

3. 사람 에이전트가 대화를 인수한 대화에서, 사람 에이전트-통화자 대화는 학습 기회로서 선택될 수 있다. 이 경우에, 시스템 관리자는 시스템에 의해 예상되지 않았던(따라서 시스템의 유한 상태 네트워크의 일부가 아닌) 대화의 사람 에이전트-통화자 교환을 분석할 수 있다. 시스템 관리자는, 통화자가 장래에 콜 센터에 연락하는 경우, 시스템이 그 통화를 처리할 준비가 되어 있도록, 시스템의 유한 상태 네트워크에 노드를 추가하고 분류자를 작성하기 위해 사람 에이전트-통화자 교환을 사용할 수 있다. 예를 들어, 인쇄 오류에 의해 특정의 달에 고객에게 백지 청구서를 우편으로 보내게 된 경우, 시스템은 백지 청구서에 관한 다수의 통화자 문의를 받을 수 있다. 이것은 시스템에 의해 예상되지 않은 대화와 같다. 이들 문의 중 몇개를 수신한 후에, 시스템 관리자는, (예를 들어, 상기 도 5에 기술된 프로세스를 사용하여) 시스템이 장래에 유사한 통화를 처리할 수 있도록, 일련의 분류자를 작성하고 유한 상태 네트워크를 갱신할 수 있다.

런타임 학습 프로세스는 선택된 에이전트-통화자 대화를 대화 스튜디오(32)(도 4 및 도 5에 도시됨)에 피드하고, 그곳에서 이들은 분류자를 재작성하고 런타임 음성 인식에 사용되는 언어 모델을 개선시키며 및/또는 상태 천이 네트워크를 수정하는 데 사용된다.

한 구현에서, 런타임 학습 프로세스는 다음의 학습 기회에 대해 시스템-통화자 대화를 스캔한다.

1. 지원 - 소프트웨어 에이전트가 확신이 없을 때 사람 에이전트가 소프트웨어 에이전트에게 통화자 진술의 적절한 해석을 알려주는 대화에서, 통화자 진술의 에이전트 해석이 통화자 음성을 이해하기 위해 개념 인식 엔진에 의해 사용되는 분류자를 개선시키는 데 사용된다. 다른 구현은 온라인 ASR에 의해 사용되는 언어 모델을 개선시키기 위해 통화자 진술의 에이전트 해석을 사용한다.

2. 인수 - 사람 에이전트가 소프트웨어 에이전트로부터 대화를 인수한 대화에서, 사람 에이전트-통화자 교환은 새로운 대화를 식별하기 위해 시스템 관리자에 의해 분석된다. 새로운 대화가 식별되는 경우, 그 새로운 대화를 애플리케이션에 추가하기 위해 (예를 들어, 상기 도 15에 기술된 프로세스를 사용하여) 새로운 일련의 통화자 분류자 및 갱신된 유한 상태 네트워크가 개발될 수 있다.

3. 강화 - 소프트웨어 에이전트가 하나 이상의 통화자 구두 표현을 성공적으로 인식한 대화에서, 통화자 구두 표현(들)은 통화자 음성을 인식하기 위해 온라인 ASR에 의해 사용되는 언어 모델(음성 인식 엔진의 컴포넌트임)을 개선시키는 데 사용된다. 다른 구현은 통화자 음성의 의미를 이해하기 위해 개념 인식 엔진에 의해 사용되는 분류자를 개선시키기 위해 이들 대화를 사용한다.

런타임 학습 프로세스(190)가 학습 기회로서 에이전트-통화자 대화를 사용할 때, 학습 기회의 대화가 정확하지 않을 위험이 있다. "좋지 않은" 대화(예를 들어, 시스템이 통화자의 질문을 잘못 해석하여 틀린 응답을 제공한 대화)를 처리하 는 것은 시스템의 정확도 및 자동화 정도를 떨어뜨릴 위험을 제공한다. 따라서, 런타임 학습 프로세스는 양호하게는 학습해야 할 "좋은" 대화만을 선택하도록 보장하는 데 도움을 주는 하나 이상의 안전 장치를 포함한다.

양호한 실시예에서, 런타임 학습 프로세스는, 선택된 대화가 어떤 선택 기준을 만족시켜야만 하도록 하기 위해, 대화 스튜디오(32)(도 4 및 도 5에 도시함)에서 그래픽 사용자 인터페이스를 통해 시스템 관리자 또는 다른 사용자에 의해 구성가능하다. 한 구현에서, 시스템 관리자는 학습 기회를 선택하기 위한 이하의 선택 기준들 중에서 하나 이상을 선택할 수 있다.

1. n개(예를 들어, n = 2, 3, 4, 등등)의 후속하는 에이전트-통화자 대화가 성공적인 경우(예를 들어, 통화자 전화 끊기 또는 도움 요청 또는 사람 에이전트에게 말하기를 야기하지 않은 대화) 강화 학습 기회로서 에이전트-통화자 대화를 선택한다.

2. 통화자가 소프트웨어 에이전트 또는 사람 에이전트에 의해 제시된 만족도 질문(예를 들어, "그 대답이 질문에 도움이 되었습니까?", "받은 서비스에 만족하십니까?")에 대해 긍정적으로 응답한 경우에만 강화 및/또는 지원 학습 기회로서 에이전트-통화자 대화를 선택한다.

3. m개(예를 들어, m = 2, 3, 4, 등등)의 다른 예들에 의해 확인되는 에이전트-통화자 대화를 강화 및/또는 지원 학습 기회로서 선택한다. 이것은 시스템이 제한된 수의 예로부터 외삽하는 것을 방지해준다.

4. 에이전트 지원 대화가 어떤 수의 다른 에이전트에 의해 확인되는 경우 그 대화를 학습 기회로서 선택한다.

5. "신뢰된" 에이전트에 의해 지원이 수행되는 경우 에이전트 지원 대화를 선택한다. 신뢰된 에이전트는, 사람의 에이전트로서의 자격 기간 또는 에이전트에 귀속된 이전의 지원 학습 예에 대한 누적 점수 등의, 어떤 "신뢰" 척도에 따라 결정될 수 있다.

6. 에이전트 지원 대화가 시스템에 의해 제안된 상위 n개의 선택(예를 들어, n=1, 2, 3, 등등) 중에 있는 경우에만 그 대화를 학습 기회로서 선택한다.

7. 새로운 예를 클러스터에 추가하는 것이 미리 정해진 수의 이전의 예를 그 클러스터로부터 시프트시키는 경우 대화를 학습 기회로서 선택하는 것을 회피한다. 예를 들어, 기존의 클러스터가, 모두가 "계좌 잔고를 알고 싶습니다"를 의미하는, 100개의 예제 구두 표현을 포함하고 선택된 대화로부터의 새로운 통화자 구두 표현이 클러스터에 추가되며 새로운 일련의 분류자가 101개의 구두 표현(원래의 100개 + 새로운 1개)의 새로운 훈련 세트를 사용하여 재생성되는 것으로 가정한다. 101개 구두 표현은, 새로운 일련의 분류자가 이들을 어떻게 분류했는지를 알아보기 위해, 새로운 일련의 분류자에 적용될 수 있다. 이상적으로는 새로운 분류자는 이들 전부를 "계좌 잔고를 알고 싶습니다" 클러스터에 속하는 것으로 분류해야만 하는데, 왜냐하면 그것이 분류자가 어떻게 훈련되었는지이기 때문이다. 그렇지만, 어떤 수(예를 들어, 1, 2, 3, 등등)의 원래의 구두 표현이 지금 어떤 다른 클러스터에 속하는 것으로 잘못 분류되어 있는 것으로 발견된 경우 또는 지금 모호하게 분류되어 있는 경우, 이것은 새로운 학습된 구두 표현이 분류자의 정확도를 떨어뜨렸 으며 애당초 이 클러스터에 추가되지 않았어야 함을 나타내는 것이다. 이 선택 기준은, 미리 정해진 수의 이전 예가 제거되게 하는 새로운 예를 클러스터에 추가하기 위한 보다 강력한 증거를 필요로 하기 위해, 상기 선택 기준 3과 결합될 수 있다.

"좋지 않은" 예로부터의 학습으로 인한 시스템 열화 위험 이외에도, 프로세싱 및/또는 사람 관리 자원을 절약하기 위해 학습 기회를 제한하는 것도 유익할 수 있다. 예를 들어, 보통의 북미 콜 센터는 일년에 대략 300백만 통화를 처리하며, 통화당 10개의 통화자-에이전트 교환을 가정하면, 이것은 보통의 콜 센터가 하루에 120,000 잠재 학습 사건을 발생한다는 것을 의미한다. 많은 조직은 시스템이 어떤 책임자의 승인 없이 그의 거동을 변경하도록 허용하지 않는다(또는 법적으로 할 수 없다). 자동 시스템 진화가 요망되는 경우에도, 엄청난 분량의 예제는 궁극적으로 프로세싱 자원에 부담이 될 수 있다. 따라서, 런타임 학습 프로세스가 관련있거나 유용한 예제만이 사람 검토를 위해 처리 및/또는 제공되도록 보장하는 것이 유익할 수 있다. 양호한 실시예에서, 런타임 학습 프로세스는, 시스템 및/또는 사용자 과부하를 방지하는 데 도움을 주기 위해 선택된 대화가 하나 이상의 선택 기준을 만족시키게 하도록, 대화 스튜디오(32)(도 4 및 도 5에 도시됨)에서 그래픽 사용자 인터페이스를 통해 시스템 관리자 또는 다른 사용자에 의해 구성가능하다.

1. 그 자신의 이해의 바탕이 되는 대화가 일반적으로 그다지 유용하지 않기 때문에 적어도 n개(예를 들어, n=1, 2, 3, 등등)의 다른 대화를 만족시키지 않는 대화를 선택하지 않는다.

2. 이들이 분류하는 다른 대화의 수에 의해 대화에 순위를 매긴다. 이들 가장 생산적인 예제의 상위 n개(n = 1, 2, 3, 등등)만을 학습 기회로서 추가한다.

3. 적어도 어떤 문턱값에 의해 한정적 세트(definitive set)를 변경하지 않는 대화를 추가하지 않는다. 상기한 바와 같이, 분류자는 예제들의 훈련 세트로부터 생성된다. 훈련 세트 내의 어떤 예제는 중요하며, 어떤 것은 중요하지 않다. 즉, 중요하지 않은 예제를 제거하고 분류자를 재생성하고자 하는 경우, 이전과 동일한 분류자를 가져온다. 중요한 예제는 한정적 세트(SVM 분류자의 한정적 세트를 결정하는 데 사용되는 기지의 소프트웨어 프로세스)라고 한다. 이 선택 기준은, 대화가 학습 프로세스를 통해 분류자에 대한 훈련 세트에 추가되고 새로운 분류자가 새로운 훈련 세트를 사용하여 작성되지만 분류자의 한정적 세트가 어떤 문턱값에 의해 변하지 않는 경우(예를 들어, 그의 구성원 대부분이 이전과 같은 경우), 분류자가 부가적인 대화로부터 그다지 학습하지 않았으며 그것이 무시될 수 있음을 의미한다(이 경우에 원래의 분류자는 제 위치에 남아 있는다). 학습을 위한 유용한 대화는 한정적 세트에 눈에 띄는 영향을 주는 그 대화이다.

4. 클러스터 내의 예제들에 숫자 또는 나이-관련 문턱값을 위치함으로써 시스템이 보유하는 예제의 수 또는 다양성을 제한한다. 한가지 나이-관련 문턱값은 어떤 수의 다른 예제들을 분류하기 위해 예제가 사용된 마지막 시간이다. 이것은 사람-사람 데이터에 대해 훈련된 시스템이, 사람이 기계에 말할 때 채택할 수 있는, 다른 스타일을 학습하는 맨처음에 특히 중요하다.

상기 선택 기준이 임의의 형태의 시스템-통화자 통신(예를 들어, 음성, 인스 턴트 메시징, 기타 등등)에 적용되는 동안, 대화 매체가 음성 또는 수기 또는 온라인 ASR(또는 수기를 인식하는 경우 온라인 광학 문자 인식(OCR) 시스템)에서 상당한 인식 오류 가능성이 발생할 수 있는 임의의 다른 양식일 때 특수 문제가 발생한다.

어떤 경우, 대화 로그에 포착되는 통화자의 음성(또는 수기)의 인식은 유용한 예제로서 기능할 정도로 정확하지 않을 수 있다. 이것은 시스템이 통화자가 말하거나 쓴 것을 이해할 수 없을 때 사람 에이전트가 정확한 해석을 제공하는 지원 또는 인수 학습에서 특히 문제가 된다. 부정확하게 인식된 음성 또는 수기로부터의 학습은 시스템 성능을 떨어뜨릴 수 있거나 적어도 시스템 자원을 낭비할 수 있다. 런타임 학습 시스템은 양호하게는, 에이전트가 선택한 대답이 시스템에 의해 제공된 가설 중 상위 n개(예를 들어, n = 1, 2, 3,...)의 세트 중에 있도록 함으로써, 부정확하게 인식된 데이터로부터의 학습에 대해 보호한다. 시스템은 또한 (온라인 또는 오프라인 ASR에 의해 생성된) 인식된 데이터의 어떤 내부 신뢰 척도가 잘못 인식된 예제로부터의 학습을 회피하기 위해 문턱값을 초과하게 할 필요가 있을 수 있다.

대화 로그 내의 부정확하게 인식된 데이터의 위협은 상당한데, 왜냐하면 시스템이 동작 중일 때, 통화자가 응답을 얻기 위해 몇초 이상 기다리려고 하지 않는다는 점에서 시스템이 일반적으로 시간 제약에 직면하고 있기 때문이다. 이것은 온라인 ASR이 사용자 요청을 인식하고 분류하기 위해 사용할 수 있는 프로세싱의 양을 제한한다. 그렇지만, 런타임 학습 프로세스는 이러한 엄격한 시간 제약이 없 이 학습하기 위해 통화자 입력을 재인식할 수 있다. 이 오프라인 인식은 더 많은 자원을 사용하여 더 나은 결과를 달성하고 심지어 동일 및/또는 관련 사용자 입력에 대해 다중 패스를 행하기 위해 다른 알고리즘, 모델 또는 파라미터를 사용할 수 있다. 예를 들어, 각각의 회전을 재인식하기 위한 훈련으로서 통화자 대화 전체(전부 10 회전)가 사용될 수 있다. 런타임 학습 프로세스는 이 작업을 수행하기 위해 한산한 때에 초과 피크 주기 용량을 사용하도록 설계될 수 있다. 런타임 프로세스는 또한 통화자 입력을 재인식하기 위해 네트워크(예를 들어, 인터넷)를 통해 컴퓨팅 자원을 사용할 수 있다.

통화자 입력(예를 들어, 음성)을 인식하는 것은 계산 집중적인 프로세스이며, 그 자체로서, 런타임 학습 프로세스는 모든 사용자 구두 표현을 재인식하기 위한 프로세스에 이용가능한 프로세싱 자원을 가지지 않을 수 있다. 런타임 학습 프로세스가 프로세싱 자원을 제한할 수 있는 한가지 방식은, 상기한 선택 기준 개요 중 하나 이상을 사용하여, 학습 기회로서 선택된 그 시-통화자 대화만을 선택하는 것이다. 상기한 기술에 부가하여, 이 프로세스는 대화의 신뢰 수준을 필터로서 사용할 수 있다. 고신뢰 대화는 정확한 것으로 추정될 수 있으며, 저신뢰 대화는 믿지 못할 정도로 문제가 있는 것으로 추정될 수 있다(예를 들어, 너무 많은 외부 노이즈). 적절한 "높은" 및 "낮은" 문턱값은 예제를 훈련하는 것으로부터 시스템에 의해 계산될 수 있다.

게다가, 인식 기술은 종종 그 기술이 시스템의 어휘의 범위를 알고 있는 것으로 가정한다. 특정의 문제는 시스템의 기본적인 원시 유닛 인벤토리(inventory of primitive unit)를 언제 어떻게 확장하느냐이다. 오프라인 인식을 사용할 수 있는 런타임 학습 프로세스는 개념 인식 시스템의 어휘를 언제 확장하지를 결정하기 위해 다른 (보통 더 큰) 어휘를 사용할 수 있다. 더 큰 어휘가 더 나은 내부 및 외부 점수를 생성하는 경우, 런타임 학습 프로세스는 그 어휘가 개념 인식 엔진에 대한 "더 나은" 어휘인 것으로 가정할 수 있다. 런타임 학습 프로세스는 새로운 항목 및 조합을 포함하도록, 예를 들어, 뉴스 피드로부터 새로운 어휘를 동적으로 작성할 수 있다. 저레벨 신뢰 척도는 아마도 새로운 항목의 범위를 식별해줄 수 있다. 유사하게 그룹화된 새로운 항목들이 어떤 문턱값을 초과하는 경우, 사람은 새로운 항목을 식별하는 데 지원해주도록 요구받을 수 있다.

마지막으로, 많은 인식 시스템은 다른 작업 레벨에 대해 별도의 모델을 갖는다. 예를 들어, 음성 응답 시스템은 음성 레벨 단위(phonetic level unit)를 분류하기 위한 가우시안 음향 모델, 음성 시퀀스를 단어에 매핑하기 위한 사전, 단어 시퀀스를 평가하기 위한 통계적 언어 모델, 및 구두 표현 전체를 등가의 의미론적 그룹으로 분류하기 위한 SVM을 가질 수 있다. 런타임 학습 프로세스는 독립적으로 또는 여러가지 조합으로 결합하여 여러가지 레벨에서 모델들을 훈련시키기 위해 선택된 학습 예제를 사용할 수 있다.

도 17을 참조하면, 학습 서버(450)는 런타임 학습 프로세스를 구현한다. 이 특정의 구현에서, 학습 서버는 로그 스트리머(log streamer)(456), 학습 모듈(458), 학습 데이터베이스(460), 오디오 페처(audio fetcher)(462), 오프라인 자동 음성 인식 애플리케이션(464), 및 애플리케이션 스토어(application store)(466)를 포함한다.

동작을 설명하면, 시스템-통화자 대화의 로그는, 이 로그가 대화 서버에 의해 발생될 때, 대화 로그(452)로부터 로그 스트리머(456)로 푸시된다. 대화 서버(예를 들어, 도 4 및 도 5에 도시된 대화 서버(30)) 또는 다른 메카니즘(예를 들어, 다른 서버)은 로그를 로그 스트리머로 푸시하도록 구성될 수 있다.

로그 스트리머가 대화 로그를 수신할 때, 로그 스트리머는 분석을 위해 로그를 학습 모듈(458a, 458b) 중 하나로 라우팅한다. 이들 학습 모듈은 학습 서버에 학습 기능을 도입하는 모듈 방식이다. 예를 들어, 한 구현에서, 하나의 학습 모듈은 에이전트 지원으로부터의 학습 기회를 식별하는 것에 전용되어 있고, 제2 학습 모듈은 강화 학습 기회를 식별하는 것에 전용되어 있으며, 제3 학습 모듈은 인수 학습 기회를 식별하는 것에 전용되어 있다. 서버에 추가될 새로운 학습 기능이 있는 경우, 새로운 학습 모듈이 개발되고 학습 서버에 도입된다. 따라서, 예를 들어, 어휘 학습 모듈은, 시스템의 어휘를 확장하는 데 통화자 구두 표현에서 사용되는 단어를 검사하하기 위해, 학습 서버에 추가될 수 있다.

학습 모듈은 또한 대화 로그에 포착된 사건 및 오디오 파일을 학습 기회로서 선택하는 기능을 한다. 시스템 학습 모듈은, 시스템 관리자에 의해 지정된 선택 기준(상기함)에 따라, 대화 로그에 포착된 사건/오디오 파일을 선택한다. 어떤 수의 후속하는 시스템-통화자 대화가 성공적인 경우에 학습하기 위한 시스템-사용자 대화를 선택하는 것 등의 어떤 선택 기준은 후보 시스템-통화자 대화에 대응하는 대화 로그로부터 결정될 수 있다. 그렇지만, 다른 선택 기준은, 시스템-통화자 대 화가 선택되어야만 하는지를 결정하기 위해, 학습 모듈이 다수의 대화 로그를 검사할 것을 요구한다. 예를 들어, 에이전트-통화자 대화가 어떤 수의 다른 예제들에 의해 확인되지 않는 한 그 대화가 선택되어서는 안되는 것으로 선택 기준이 규정하고 있는 경우, 학습 모듈은 에이전트-통화자 대화에 대해 다중 패스를 행하게 된다. 제1 패스에서, 학습 모듈은 에이전트-통화자 대화를 가능한 학습 기회로서 식별하고 저장한다. 어떤 양의 후보 대화가 저장된 후에 또는 어떤 시간 후에, 학습 모듈은 궁극적으로 학습 기회로서 선정할 대화를 선택하기 위해 저장된 후보 대화를 분석한다.

학습 모듈이 시스템-통화자 대화를 학습 기회로서 선택할 때, 선택된 시스템-통화자 대화는 학습 데이터베이스(460)에 저장된다.

시스템-통화자 대화를 필터링하기 위한 선택 기준 이외에, 학습 모듈은 또한, 오프라인 ARS(464) 또는 수동 전사(468)에 대한 선택된 시스템-통화자 대화를 전송할지 여부를 결정하기 위해, 개념 인식 엔진에 의해 보고된 매칭 점수 레벨(대화 로그에 포함되어 있음)을 검사하도록 구성되어 있다. 매칭 점수의 문턱값 범위는 사용자(예를 들어, 시스템 관리자)에 의해 구성가능할 수 있거나 사전 프로그램되어 있을 수 있다. 매칭 점수에 대한 문턱값 범위는 양호하게는 아주 낮은 신뢰의 점수(구두 표현이 너무 문제가 많아 신뢰할 수 없음을 나타냄) 및 아주 높은 신뢰의 점수(원래의 인식이 정확함을 나타냄)를 배제시킨다. 전사가 오프라인 ASR(464)에 관한 것인 경우, 오프라인 ASR 프로세스(464)는, 특정의 인식 상태에 대해 사용되는 ASR 언어 모델을 검색하기 위해, 애플리케이션 스토어(466) 내의 애플리케이션 정의에 액세스한다(각각의 인식 상태는 별도의 언어 모델을 사용함). 학습 모듈은 모든 에이전트-인수 대화를 오프라인 ASR 또는 수동 전사로 라우팅하도록 구성되어 있는데, 그 이유는 개념 인식 엔진이 에이전트 인수 동안에 통화자 또는 에이전트 구두 표현을 인식하지 않기 때문이다. 어떤 구성에서, 학습 모듈은 통화자-사람 에이전트 대화의 고품질 전사를 획득하기 위해, 오프라인 ASR에 의한 자동화된 전사와는 달리, 수동 전사를 위한 에이전트 인수를 라우팅하도록 구성되어 있다.

마지막으로, 애플리케이션 개발자는, 고려할 준비가 되어 있는 학습 기회를 검색하기 위해, 대화 스튜디오(32) 상의 그래픽 사용자 인터페이스를 사용한다. 애플리케이션 개발자는 (예를 들어, 그래픽 사용자 인터페이스를 통해) 학습 기회를 선택적으로 승인하고, 승인된 학습 기회로 애플리케이션을 갱신한다. 애플리케이션이 갱신되면, 새 버전이 애플리케이션 스토어(466)에 위치되고 대화 서버에 배치된다.

지원 학습 기회는 적절한 개념 클러스터에 추가되는 새로운 통화자 구두 표현을 생성하며, 이는 이어서 개념 인식을 위해 사용되는 분류자를 재생성하는 데 사용된다. 갱신된 애플리케이션은 이어서, 그 다음에 이들이 통화자에 의해 말해질 때, 유사한 구두 표현을 적절히 분류할 수 있다. 강화 학습 기회는 온라인 ASR의 정확도를 향상시키기 위해 음성 인식을 위한 언어 모델에 추가되는 새로운 구두 표현을 생성한다. 인수 학습 기회는 새로운 주제 및 기존의 주제를 중심으로 한 새로운 대화를 처리하기 위해 유한 상태 네트워크를 확장한다.

도 13은 사람 에이전트가 작업 그룹에 로그하고 그의 작업 상태를 관리하며 전화를 받고 전화를 할 수 있게 해주는 범용 에이전트 데스크톱의 컴포넌트인 그래픽 사용자 인터페이스(208)를 나타낸 것이며, 이들 전부는 CTI 서버와의 대화를 통한다. 사용자 인터페이스(208)는 제어 패널이며, 이를 통해 에이전트는 데스크톱 애플리케이션을 비롯한 CTI 서버를 이용하는 애플리케이션을 기동시킨다.

인터페이스(208)는 Avaya IP 에이전트 데스크톱 상에 모델링된다. 데스크톱의 가장 통상적인 기능은 툴바를 통해 노출된다. 도 13에 도시된 툴바는, 전화(200)(선택된 통화에 대한 제어를 제공함), 다이얼(202)(전화를 거는 수단을 제공함), 에이전트(204)(ACD와 관련하여 에이전트의 작업 상태를 설정하는 수단을 제공함), 및 애플리케이션(206)(인터페이스(208)에 로드된 애플리케이션을 기동시키는 수단을 제공함)이다.

사람 에이전트의 로그인 시에, 데스크톱에 대한 구성은 서버로부터 로드된다. 이 구성의 일부는 데스크톱으로부터 기동될 수 있는 애플리케이션의 정의이다. 애플리케이션 구성은 애플리케이션을 구현하는 클래스 및 애플리케이션을 로드해오는 네트 장소(net location)를 포함한다. 게다가, 이 구성은 통화가 애플리케이션을 목표로 한 것임을 나타내는 애플리케이션 데이터를 포함한다.

도 14는 해결 애플리케이션(resolution application) 또는 그래픽 사용자 인터페이스(210)를 나타낸 것이다. 이 애플리케이션은, 통화가 해결 통화임을 나타내는 애플리케이션 데이터와 함께, 통화가 도착할 때마다 트리거된다. 애플리케이션 사용자 인터페이스는 3개의 주요 부분으로 나누어진다. 제공되는 정보는 다음 과 같다. 애플리케이션(212)(실행 중인 CML 애플리케이션), 컨텍스트(214)(애플리케이션 내에서의 현재 상태), 채널(216)(고객이 센터에 연락하는 채널), 문턱값(218)(컨텍스트에 대한 문턱값 설정), 상회/하회(220)(해결이 에이전트에 제공된 이유, 즉 문턱값을 넘는 대답이 너무 많거나 문턱값을 넘는 대답이 충분하지 않음), 지원(222)(이 세션에서 고객이 지원받은 횟수), 및 시간(224)(고객이 이 세션에 있은 시간).

문제 해결 패널(226) 내에서, 사람 에이전트는 고객의 질문에 대한 적절한 대답을 선택할 수 있다. 이 패널에서 에이전트가 수행할 수 있는 동작은, 지식 베이스 검색(228)(질의를 수정하고 대답을 얻기 위해 지식 베이스를 검색하는 것), 응답(230)(선택된 대답으로 고객에 응답하도록 소프트웨어 에이전트에 지시하는 것. 질의에 부합하는 대답(232)은 패널의 하단에 있는 테이블에 디스플레이된다. 각각의 대답(232)은 컨텍스트 신뢰 문턱값을 상회하는지 하회하는지, 그의 매칭 순위, 및 그의 질문의 요약을 나타낸다.), 인수(234)(소프트웨어 에이전트로부터 통화를 인수함), 귓속말(236)(고객 요청의 기록을 들음), 및 원래 질문 전송(Submit Original Question)(238)(지식 베이스에 대한 질의로서 고객의 원래의 질문을 전송함. 이것은 애플리케이션에 의해 수행되는 초기 동작이다.)

그래픽 사용자 인터페이스(210)는 또한 사람 에이전트가 "대체 질문"이라고 하는 박스에 고객의 통신에 대한 대체 텍스트를 입력할 수 있게 해준다. 컴퓨터 생성 응답의 신뢰 수준이 낮은 경우, 사람 에이전트는, 사람 에이전트가 시스템이 그것을 더 잘 매칭시킬 것임을 알도록, 고객의 통신을 바꿔 말하기로 결정할 수 있 다.

사용자 인터페이스의 하단에 2개의 컨트롤 세트, 즉 전사본 및 데이터가 있다. 전사본 버튼(240)은 소프트웨어 에이전트의 고객과의 대화를 채팅 스타일 전사본으로 보여주는 웹 페이지를 기동시킨다. 이 웹 페이지는 대화 채널에서 사용되는 동일한 코쿤 기반구조를 통해 대화의 소프트웨어 에이전트의 실행 전사본(running transcript)로부터 생성된다. 데이터 버튼(242)은 소프트웨어 에이전트에 의해 현재까지 수집된 애플리케이션 데이터를 보여주는 웹 페이지를 기동시킨다. 이 웹 페이지는, 대화 채널에서 사용되는 동일한 코쿤 기반구조를 통해, 소프트웨어 에이전트의 애플리케이션 및 네트워크 속성으로부터 생성된다. 대화 채널에서와 같이, 보다 일반적인 레벨에서의 정의보다 우선하는 보다 특정적인 레벨에서의 정의로 애플리케이션 레벨, 네트워크 레벨, 및/또는 컨텍스트 레벨에서 이 데이터의 프리젠테이션을 정의하는 것이 가능하다(예를 들어, 컨텍스트 레벨에서의 정의는 네트워크 또는 애플리케이션 레벨에서의 정의에 우선한다).

랩업 컨트롤(Wrap-Up Control)은 사람 에이전트가 대화 로그에 위치된 안내를 제공할 수 있게 해준다. 주석 첨부(Attach Note) 버튼(244)은 사람 에이전트가 대화 로그에서 이 대화에 주석을 첨부할 수 있게 해준다. 검토 표시(Mark for Review) 체크박스(246)는 이 대화가 대화 로그에서 검토를 위해 표시되어야만 함을 나타낸다. 완료(Done) 버튼(248)은 에이전트가 이 해결을 완료했음을 나타낸다. 시스템은 사전 예방적으로 품질 보증, 분쟁 해결, 및 시장 조사를 위해 아카이브된 음성 및 텍스트-기반 대화를 인덱싱, 분류 및 모니터링한다. 이 시스템이 완전히 자동화되어 있기 때문에, 이 시스템은 고객 통화 패턴에서의 편차를 알기 위해 사전 예방적으로 통화 아카이브를 모니터링하고 통상의 보고 메카니즘을 통해 관리자에게 경보를 할 수 있다.

예를 들어, 대화 마이닝의 카테고리에서, 시스템은 나중의 데이터 마이닝(예를 들어, 재무 서비스를 위한 품질 제어)을 위해 고객 오디오를 전사한다. 이것은 일괄 인식 프로세스로부터 전사된 대화를 가져오는 것, CRE가 로그를 클러스터화하기 위해 이용되는 것을 포함하며, 클러스터 내에서 특정의 주제(즉, 진급, 문제 영역, 기타 등등)를 검색하는 기능을 제공한다. 이 시스템은 또한 통화를 특정 주제별로 클러스터화할 수 있고(서브클러스터). 서브클러스터 내에서의 통화 패턴의 편차를 찾아내고 표시할 수 있으며, 또한 관리자가 편차가 발생하는 오디오 스트림 내의 특정 지점에 액세스할 수 있게 해줄 수 있다. 이 기능은 에이전트가 말하는 것에 대한 감사 추적(audit trail)을 제공한다. 예를 들어, 제품 반환에 대한 클러스터는 다른 에이전트가 고객에게 제품을 다른 장소로 반환하도록 지시하는 것을 나타낼 수 있다. 이것을 하기 위해, 클러스터는 다중-패스 ASR 이전에 로그와 연관된 데이터를 보유한다. 다른 예로서, 클러스터는, 어떤 에이전트가 지식 베이스 내의 기존의 대답을 고객 질문과 연관시키는(혼합 작업 흐름) 반면, 다른 에이전트는 전화를 받고(인수 작업 흐름) 그 자신의 응답을 제공한다는 것을 보여줄 수 있다.

컨택 센터 관리에 대한 어떤 응용을 비롯하여 본 발명의 어떤 구현이 기술되어 있지만, 광범위한 다른 구현이 이하의 청구항의 범위 내에 속한다.

<부록 1>

Claims (83)

1. 컴퓨터 프로세서에 의해 실행되는 방법으로서,

   제1 당사자 유형의 구성원과 제2 당사자 유형의 구성원 간의 대화의 집합을 수신하는 단계 - 상기 대화 각각은 상기 제1 당사자 유형의 구성원의 통신 및 상기 제1 당사자 유형의 구성원의 통신에 응답하는 상기 제2 당사자 유형의 구성원의 통신을 포함함 -;

   상기 제1 당사자 유형의 구성원들의 통신을 클러스터의 제1 집합으로 그룹화하는 단계;

   상기 제1 당사자 유형의 구성원들의 통신의 그룹화에 기초하여, 상기 제2 당사자 유형의 구성원들의 상기 응답 통신을 클러스터의 제2 집합으로 그룹화하는 단계; 및

   상기 클러스터의 제2 집합 내의 하나 이상의 클러스터에 대해 에이전트 유형의 분류자의 집합을 생성하는 단계

   를 포함하는 방법.
2. 제1항에 있어서, 상기 통신은 구두 표현(utterances)을 포함하는 방법.
3. 제1항에 있어서, 상기 통신은 텍스트 메시지를 포함하는 방법.
4. 제1항에 있어서, 상기 제1 당사자 유형의 구성원들의 통신은 콜 센터에서의 사람 고객 서비스 에이전트(human customer service agents)의 통신을 포함하는 방법.
5. 제1항에 있어서, 상기 제1 당사자 유형의 구성원들의 통신은 콜 센터에 연락하는 사람과 통신하도록 구성되어 있는 소프트웨어 에이전트의 통신을 포함하는 방법.
6. 제1항에 있어서, 상기 제2 당사자 유형의 구성원들의 통신은 콜 센터에 연락하는 사람의 통신을 포함하는 방법.
7. 제1항에 있어서, 상기 분류자는 지원 벡터 기계(support vector machines)를 포함하는 방법.
8. 제1항에 있어서, 상기 분류자는 의사결정 트리(decision tree)를 포함하는 방법.
9. 제1항에 있어서, 제1 당사자 유형의 구성원들의 통신은 클러스터의 제1 집합으로 그룹화되는 방법.
10. 제9항에 있어서, 제1 당사자 유형의 구성원들의 통신을 클러스터의 제1 집합으로 그룹화하는 단계는 상기 통신의 의미론적 특징을 결정하는 단계를 포함하는 방법.
11. 제1항에 있어서, 상기 제1 당사자 유형의 구성원들의 통신을 클러스터의 제1 집합으로 그룹화하는 단계는 상기 제1 당사자 유형의 구성원들의 통신의 의미(meaning)에 기초하는 방법.
12. 제1항에 있어서, 상기 컴퓨터 프로세서에 의해, 상기 클러스터의 제1 집합 내의 하나 이상의 클러스터에 대해 에이전트 유형의 분류자의 집합을 생성하는 단계를 더 포함하는 방법.
13. 제1항에 있어서,

    상기 제1 당사자 유형의 구성원들의 통신을 클러스터의 제1 집합으로 그룹화하는 단계는,

    상기 제1 당사자 유형의 구성원들로부터의 정보의 요청에 대응하는 통신을 클러스터의 제1 집합으로 그룹화하는 단계를 포함하는 방법.
14. 제13항에 있어서,

    상기 제1 당사자 유형의 구성원들의 통신의 그룹화에 기초하여 상기 제2 당사자 유형의 구성원들의 응답 통신을 클러스터의 제2 집합으로 그룹화하는 단계는,

    상기 제2 당사자 유형의 구성원들의 통신을 상기 제1 당사자 유형의 구성원들로부터의 정보의 요청에 대한 응답에 대응하는 그룹들로 그룹화하는 단계를 포함하는 방법.
15. 제13항에 있어서,

    상기 제1 당사자 유형의 구성원들의 통신의 그룹화에 기초하여 상기 제2 당사자 유형의 구성원들의 응답 통신을 클러스터의 제2 집합으로 그룹화하는 단계는,

    상기 제1 당사자 유형의 구성원의 통신을 상기 제1 당사자 유형의 클러스터로 분류하기 위해 상기 제1 에이전트 유형의 분류자들을 사용하는 단계; 및

    상기 분류된 제1 당사자 유형의 구성원의 통신에 후속하는 상기 제2 당사자 유형의 구성원의 통신을 상기 제1 당사자 유형의 클러스터와 관련이 있는 상기 제2 당사자 유형의 클러스터로 그룹화하는 단계를 포함하는 방법.
16. 제15항에 있어서,

    상기 제1 당사자 유형의 클러스터는 상기 제1 당사자 유형의 구성원에 의해 행해진 정보의 요청과 관련이 있고, 상기 제2 당사자 유형의 클러스터는 상기 제2 당사자 유형의 구성원에 의해 제공된 정보의 요청에 대한 응답과 관련이 있는 방법.
17. 제1항에 있어서,

    상기 컴퓨터 프로세서에 의해,

    상기 제1 당사자 유형의 구성원들과 상기 제2 당사자 유형의 구성원들 간의 대화의 제2 집합을 수신하는 단계 - 상기 대화 각각은 상기 제1 당사자 유형의 구성원의 통신 및 상기 제1 당사자 유형의 구성원의 통신에 응답하는 상기 제2 당사자 유형의 구성원의 통신을 포함함 -;

    상기 제2 당사자 유형의 구성원들의 통신을 그룹화하기 위해 분류자들을 적용하는 단계; 및

    기계에 의해, 상기 클러스터 내에 그룹화된 통신들에 관한 데이터를 사용하여 상기 클러스터의 제2 집합 내의 클러스터에 대한 에이전트 유형의 분류자들을 재생성하는 단계

    를 더 포함하는 방법.
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제
50. 삭제
51. 삭제
52. 삭제
53. 삭제
54. 삭제
55. 삭제
56. 삭제
57. 삭제
58. 삭제
59. 삭제
60. 삭제
61. 삭제
62. 삭제
63. 삭제
64. 삭제
65. 삭제
66. 삭제
67. 삭제
68. 삭제
69. 삭제
70. 삭제
71. 삭제
72. 삭제
73. 삭제
74. 삭제
75. 삭제
76. 삭제
77. 삭제
78. 삭제
79. 삭제
80. 삭제
81. 삭제
82. 삭제
83. 삭제

Images