다음을 통해 공유


지능형 애플리케이션 워크로드를 위한 의도 인식 및 엔터티 추출 옵션

의도 인식 및 엔터티 추출은 자연어 이해의 핵심 구성 요소입니다.

의도 인식에는 입력 뒤에 있는 사용자의 목표 또는 목적을 식별하는 작업이 포함됩니다. 예를 들어 사용자가 "항공편을 예약하고 싶습니다"라고 말하면 항공편을 예약하려는 의도입니다. 의도 인식은 에이전트가 사용자의 요청에 따라 취해야 할 조치를 이해하는 데 도움이 됩니다.

엔터티 추출에는 사용자의 입력에서 특정 정보를 식별하고 추출하는 작업이 포함됩니다. 엔터티는 날짜, 이름, 위치 또는 기타 관련 데이터와 같은 항목일 수 있습니다. 예를 들어 "9월 15일에 뉴욕행 항공편 예약"이라는 문장에서 "뉴욕"과 "9월 15일"은 엔터티입니다.

에이전트는 사용자의 목표를 이해하기 위한 의도와 작업을 완료하는 데 필요한 특정 세부 정보를 식별하기 위한 엔터티를 사용합니다. 따라서 의도 인식 및 엔터티 추출을 통해 에이전트는 사용자 쿼리에 정확하고 효율적인 응답을 제공할 수 있습니다.

지능형 애플리케이션 워크로드를 설계할 때 지능형 애플리케이션 워크로드가 긍정적인 사용자 경험을 제공할 수 있도록 의도 인식 및 엔터티 추출에 가장 적합한 옵션을 선택해야 합니다.

정의

용어 정의
NLU 자연어 이해는 기계 독해에 중점을 둔 AI 자연어 처리의 하위 집합입니다.
CLU 대화 언어 이해는 사용자 지정 NLU 모델을 만들 수 있는 Azure AI의 기능입니다.
LLM 거대 언어 모델은 인간의 언어를 이해하고 생성하도록 설계된 AI 모델의 한 유형입니다.
GPT 사전 훈련된 생성형 트랜스포머는 트랜스포머 아키텍처를 사용하여 인간과 유사한 텍스트를 이해하고 생성하는 거대 언어 모델 제품군을 말합니다.
동적 체인 동적 체인은 생성 작업에 대한 트리거를 자동화하는 방법입니다. 가능한 모든 주제 또는 트리거 문구를 수동으로 정의하는 대신 동적 체인을 사용하면 AI가 대화의 컨텍스트에 따라 호출해야 하는 주제 또는 플러그인 작업을 결정할 수 있습니다.

지능형 애플리케이션 워크로드에서 의도 인식 및 엔터티 추출에 적합한 옵션을 선택하려면 다음과 같은 몇 가지 주요 고려 사항이 필요합니다.

  • 미리 빌드된 엔터티와 사용자 지정 엔터티: Microsoft Copilot Studio에서 제공하는 미리 빌드된 엔터티가 요구 사항을 충족하는지 평가합니다. 사전 빌드된 엔터티는 날짜, 숫자 및 이름과 같은 일반적인 정보 유형을 다룹니다. 애플리케이션에 도메인별 지식이 필요한 경우 사용자 지정 엔터티를 만들어야 할 수 있습니다.

  • 사용자 입력의 복잡성: 사용자 입력의 복잡성과 가변성을 고려합니다. 간단한 시나리오의 경우 사전 빌드된 엔터티로 충분할 수 있습니다. 더 복잡한 상호 작용의 경우 사용자 지정 엔터티 및 정규식(regex)과 같은 고급 구성이 필요할 수 있습니다.

  • 슬롯 채우기: 애플리케이션에 에이전트가 사용자 입력에서 누락된 정보를 적극적으로 찾아 채우는 사전 예방적 슬롯 채우기가 필요한지 확인합니다. 슬롯 채우기는 후속 질문의 필요성을 줄여 사용자 경험을 향상시킬 수 있습니다.

  • 성능 및 확장성: 선택한 방법의 성능 및 확장성을 평가합니다. 사용자 지정 엔터티 및 복잡한 구성에는 더 많은 처리 능력이 필요한 경우가 많으며 응답 시간에 영향을 줄 수 있습니다.

  • 유지 관리 용이성: 엔터티를 유지 관리하고 업데이트하는 용이성을 고려합니다. 사전 빌드된 엔터티는 관리하기가 더 쉬운 반면, 사용자 지정 엔터티는 애플리케이션이 발전함에 따라 지속적인 조정이 필요합니다.

표준 NLU, Azure CLU 또는 동적 연결 중에서 선택

Copilot Studio에서 토픽 또는 작업 트리거는 표준 NLU 모델을 사용하거나 사용자 지정 Azure CLU 모델과 결합하거나 재정의하거나 NLU 모델을 GPT 대규모 언어 모델 기반 모델인 동적 체인으로 완전히 대체하여 구현할 수 있습니다.

표준 NLU 모델 사용자 지정 Azure CLU 모델 동적 체인
Pro 사전 정의된 많은 엔터티 형식과 함께 사전 학습된 상태로 제공되는 기본 제공 모델입니다.

구성은 트리거 문구와 사용자 지정 엔터티(값과 동의어가 있는 닫힌 목록 또는 정규식)를 추가하여 수행됩니다.
기본 모델로 더 많은 언어를 지원합니다.

더 나은 의도 인식을 위해 또는 특정 산업 요구 사항을 해결하기 위해 의도 트리거 모델의 사용자 지정을 지원합니다.

복잡한 엔터티 추출(예: 동일한 형식)을 허용합니다.

엔티티 추출에는 Copilot Studio 표준 NLU도 사용할 수 있습니다.
GPT 거대 언어 모델을 사용하며 더 넓은 스펙트럼의 데이터에 대해 사전 훈련된 상태로 제공됩니다.

여러 인텐트를 처리하고 토픽 및/또는 플러그 인을 연결할 수 있습니다.

누락된 입력에 대한 질문을 자동으로 생성하고 대화 컨텍스트에서 복잡한 엔터티 및 질문에 답변합니다.

구성은 토픽, 플러그 인 작업, 입력 및 출력을 설명하여 수행됩니다.
Con 쿼리당 단일 의도 인식.

연장할 수 없습니다. 모델의 동작 방식을 수정하거나 모델을 미세 조정할 수 없습니다. 있는 그대로 제공됩니다.

동일한 쿼리에서 동일한 유형의 여러 엔터티를 슬롯으로 채우려면 각각에 대한 명확성이 필요합니다(예: 출발지와 목적지 도시).
쿼리당 단일 의도 인식.

구성은 추가 비용으로 Azure에서 수행됩니다.

평가해야 하는 자체 서비스 제한이 있습니다.

Azure CLU 의도 및 Copilot Studio 토픽은 신중하게 동기화해야 합니다.
생성형 AI 기능이기 때문에 메시지의 라이선스 소진율은 일반 토픽 트리거보다 높습니다.

트리거 문구 및 슬롯 채우기

지능형 애플리케이션 워크로드를 개발할 때 기본 기능을 사용하여 의도 인식을 개선하고 대화를 간소화합니다. 기존 FAQ 데이터베이스 및 채팅 기록에서 토픽 트리거 문구를 식별하여 예상되는 문구가 관련성 있고 정확한지 확인하는 것부터 시작합니다. 엔터티를 사용하는 방법을 고려합니다. 예를 들어 정규식을 사용하여 주문 ID, 이메일에 사전 빌드된 엔터티 또는 동의어가 있는 작업 유형에 대한 닫힌 목록을 찾을지 여부입니다. 또한 샘플 문구를 사용하여 토픽 트리거를 테스트하여 의도 인식 및 엔터티 추출 프로세스의 정확성을 검증하고 구체화하는 방법을 계획합니다. 배포 및 테스트 고려 사항에서 자세히 알아보세요.

트리거 문구

트리거 문구는 에이전트의 NLU 모델을 학습시킵니다. 에이전트가 특정 토픽을 트리거하는 특정 문구를 정의하여 사용자 발화를 정확하게 인식하고 응답하는 데 도움이 됩니다. 이러한 트리거 문구를 적절하게 구성하면 에이전트가 사용자의 의도를 올바르게 식별하고 적절하게 응답할 수 있습니다. 에이전트에서 트리거할 토픽이 확실하지 않은 경우 최대 3개의 잠재적 토픽 후보(여러 토픽 일치 시스템 토픽)를 제안하거나 토픽이 식별되지 않은 경우 기본 응답으로 대체할 수 있습니다. 이 메커니즘은 대화의 흐름을 유지하는 데 도움이 되며 에이전트가 광범위한 사용자 입력을 효과적으로 처리할 수 있도록 합니다.

엔터티 추출 및 슬롯 채우기

엔터티 추출 및 슬롯 채우기는 효과적인 에이전트를 개발하는 데 중요한 구성 요소입니다. 이러한 프로세스를 통해 에이전트는 사용자 쿼리에서 관련 세부 정보를 식별하고 추출하여 정보를 효율적으로 획득하고 사용할 수 있습니다.

엔터티 추출에는 특정 정보를 식별하기 위해 사용자의 입력을 구문 분석하는 작업이 포함됩니다. 예를 들어 "라지 사이즈 파란색 티셔츠 3장을 주문하고 싶습니다"라는 쿼리에서 에이전트 NLU 모델은 다음 엔터티를 추출해야 합니다.

  • 수량: 3
  • 색상: 파란색
  • 사이즈: 라지
  • 품목 종류: 티셔츠

슬롯 채우기는 이러한 추출된 엔터티를 사용하여 주어진 작업에 필요한 정보를 완료하는 프로세스입니다. 이 예에서 에이전트는 토픽을 주문으로 인식하고 추출된 엔터티로 필요한 슬롯을 채웁니다. 에이전트는 더 많은 질문을 하지 않고도 사용자의 요청을 이해할 수 있어 상호 작용을 간소화할 수 있습니다.

엔터티 추출 및 슬롯 채우기를 통해 에이전트는 복잡한 쿼리를 보다 효과적으로 처리하여 정확하고 상황에 맞는 응답을 제공하고 사용자 경험을 향상시킬 수 있습니다.

자세히 보기:

Microsoft Copilot Studio와 Azure CLU 통합

CLU 모델을 Copilot Studio 에이전트와 통합하면 에이전트의 기능을 크게 향상시킬 수 있습니다. 이 통합에는 Azure CLU 의도를 Copilot Studio 토픽에 매핑하는 작업이 포함되므로 에이전트가 사용자 의도를 보다 정확하게 이해하고 응답할 수 있습니다. 또한 Copilot Studio 미리 빌드된 엔터티를 Azure CLU 엔터티와 함께 사용하여 엔터티 추출을 위한 강력한 프레임워크를 제공할 수 있습니다.

이 통합을 고려할 때 지능형 애플리케이션 워크로드에 Azure CLU가 필요한지 여부를 평가하는 것이 중요합니다. 예를 들어 Azure CLU는 애플리케이션에 필수적일 수 있는 더 많은 언어, 산업별 사전 및 복잡한 엔터티 추출을 지원합니다. Azure CLU를 사용한 사용자 지정 엔터티 추출은 자동 또는 "운이 좋은" 슬롯 채우기를 사용하도록 설정할 수도 있으며, 이를 통해 에이전트는 후속 질문을 묻지 않고 단일 구문으로 원본 및 대상 도시를 모두 식별하는 등의 시나리오를 처리할 수 있습니다.

또 다른 중요한 측면은 Azure CLU 서비스 할당량 및 제한이 에이전트의 사용량과 일치하는지 확인하는 것입니다. 예를 들어 분당 의도 인식이 필요한 호출이 1,000개 미만일 것으로 예상되는 경우 S 계층을 사용하여 Azure CLU를 설정할 수 있습니다. 이 구성을 사용하면 에이전트가 서비스 제한을 초과하거나 예기치 않은 비용을 발생시키지 않고 예상 워크로드를 처리할 수 있습니다.

자세히 보기:

토픽 구조에 대한 고려 사항

주제를 효과적으로 구조화하는 것은 자연스럽고 원활한 대화를 만드는 데 중요합니다. 토픽은 결합될 때 사용자가 에이전트와 원활하게 상호 작용할 수 있도록 하는 개별 대화 경로입니다. 토픽 구조를 디자인할 때 고려해야 할 몇 가지 주요 사항은 다음과 같습니다.

  • 트리거 기반 토픽: 이러한 토픽은 사용자 발화에 따라 활성화되며 진입점 역할을 합니다. 이러한 토픽에 대한 명확한 트리거 문구를 정의하십시오. 트리거 문구가 여러 토픽에서 겹치는 경우 명확한 질문을 한 후 적절한 토픽으로 리디렉션할 수 있는 포괄적 토픽을 구현하는 것이 좋습니다. 엔터티 추출 및 슬롯 채우기를 사용하면 필요한 정보가 이미 제공된 경우 이러한 명확한 질문을 건너뛸 수 있습니다.

  • 리디렉션 기반 토픽: 이러한 토픽은 리디렉션 작업, 활동 또는 이벤트에 의해 트리거되며 다른 여러 토픽에서 호출될 수 있습니다. 다양한 대화 경로에 원활하게 통합할 수 있도록 입력 및 출력 변수를 사용하여 재사용 가능하고 모듈식으로 설계되어야 합니다.

  • 이중 트리거 토픽: 일부 토픽은 의도 인식 또는 명시적 리디렉션을 통해 트리거될 수 있습니다. 이러한 유연성 덕분에 보다 역동적이고 반응이 빠른 대화가 가능합니다.

  • 대화 부스팅 및 대체: 사용자의 쿼리에 의해 일치하는 토픽이 트리거되지 않는 상황에 대한 대체 토픽을 만듭니다. 이러한 토픽은 일반적인 응답을 제공하거나 대화 흐름을 유지하기 위해 관련 토픽을 제안할 수 있습니다.

설계 방식:

  • 주요 시나리오에 대한 사용자 지정 토픽: 관련 트리거 문구 및 리디렉션을 사용하여 주요 시나리오에 대한 몇 가지 사용자 지정 토픽을 개발합니다. 상위-하위 토픽 구조를 사용하여 복잡한 상호 작용을 관리할 수 있습니다. 인식할 수 없는 의도의 경우 생성형 답변 및 대체 메커니즘을 구현합니다.

  • 명확성 항목: 명확한 질문이 필요한 작업에 명확성 항목을 사용하도록 계획합니다. 예를 들어 사용자 계정 작업에는 작업 유형(예: 만들기, 잠금 해제, 일시 중단) 및 관련 시스템(예: SAP, ServiceNow Microsoft)에 대한 설명이 필요할 수 있습니다.

  • 중복 방지: 콘텐츠가 중복되지 않도록 하려면 반복해야 하는 대화 상자 경로에 대해 재사용 가능한 항목을 만듭니다. 이러한 재사용 가능한 토픽은 상위 토픽에서 호출할 수 있으며, 완료되면 대화에서 상위 토픽의 논리를 다시 시작할 수 있습니다.

자세히 보기:

인식할 수 없는 의도 처리

인식할 수 없는 의도를 효과적으로 관리하면 원활한 사용자 경험이 보장됩니다. 인식할 수 없는 의도는 에이전트가 사용자 발화를 이해하지 못하고 기존 토픽을 트리거할 충분한 신뢰도가 부족할 때 발생합니다. 이러한 시나리오를 처리하기 위한 몇 가지 제안 사항은 다음과 같습니다.

  • 인식되지 않은 의도 관리: 처음에는 인식되지 않은 의도를 대화형 부스팅 시스템 주제로 직접 전달하여 SharePoint 사이트와 같은 공개 웹 사이트와 기업 리소스에서 답변을 검색합니다. 관련 정보를 찾을 수 없는 경우 시스템은 Azure OpenAI GPT-4 모델과 함께 사용자 지정 시스템 프롬프트를 사용하여 ChatGPT와 유사한 환경으로 대체할 수 있습니다. 이 방법을 사용하면 쿼리가 계획되지 않은 경우에도 사용자가 유용한 응답을 받을 수 있습니다.

  • 외부 시스템과의 통합: 대체 전략의 일환으로 외부 시스템과 통합하는 경우를 고려하세요. 예를 들어 HTTP 요청을 사용하여 Azure OpenAI GPT-4 모델과 통합하여 규정을 준수하는 ChatGPT와 같은 환경을 제공합니다.

  • 대체 사용량 모니터링: 대체에 해당하는 대화의 비율을 정기적으로 검토합니다. 이러한 인사이트를 사용하여 기존 토픽을 보강하거나 새 토픽을 만들어 에이전트가 이해 및 응답 기능을 지속적으로 개선하도록 합니다.

  • 대체 토픽 및 생성형 답변: 매칭 토픽이 식별되지 않으면 대체 시스템 토픽이 트리거됩니다. 생성형 답변이 활성화된 경우, 알 수 없는 의도 이벤트에서 대화형 부스팅 토픽이 먼저 트리거되고, 그 다음에 필요에 따라 대체 토픽이 트리거됩니다. 이 계층화된 접근 방식은 인식되지 않은 의도를 효과적으로 관리하는 데 도움이 됩니다.

  • 대화 부스팅 및 대체 사용: 생성형 답변을 사용하여 다양한 데이터 원본을 검색하거나 언어용 Azure Cognitive Service와 같은 다른 시스템과 통합하세요. 이 서비스는 대량의 질문 및 답변 쌍을 처리할 수 있으며 무작위 질문에 대한 채팅 모델을 포함합니다.

  • 핵심 시나리오 및 사용자 지정 항목: 핵심 시나리오 및 항목이 잘 정의되고 사용자 지정 항목을 통해 처리되는지 확인합니다. 구조화되고 효율적인 대화 흐름을 유지하기 위해 이러한 토픽의 결과를 명확하게 정의합니다.

지역화 및 언어

에이전트를 구축할 때 지능형 애플리케이션 워크로드가 지원해야 하는 언어와 시장을 고려합니다. 현지화 및 언어 지원은 지능형 애플리케이션 워크로드가 다양한 사용자 기반의 요구 사항을 충족하도록 하는 데 중요한 요소입니다. 다음은 몇 가지 제안된 접근 방식입니다.

  • 언어당 하나의 에이전트: 이 접근 방식에는 각 언어에 대해 별도의 에이전트 만드는 작업이 포함됩니다. 각 에이전트가 특정 언어에 완전히 최적화되도록 합니다. 그러나 여러 에이전트를 유지 관리하는 것은 리소스를 많이 사용할 수 있습니다.

  • 여러 언어에 대해 하나의 에이전트(구성된 번역): 이 접근 방식을 사용하면 단일 에이전트가 에이전트 구성의 일부로 제공되는 번역과 함께 여러 언어를 지원합니다. 이 방법을 사용하려면 에이전트가 업데이트되거나 새 콘텐츠가 추가될 때마다 번역을 업데이트해야 합니다. 리소스 효율성과 언어 지원 간의 균형을 제공하지만 번역 업데이트를 신중하게 관리해야 합니다.

  • 여러 언어에 대한 하나의 에이전트(실시간 번역): 이 방법은 릴레이 에이전트를 사용하여 런타임에 실시간 번역을 제공합니다. 이를 통해 더 많은 언어를 신속하게 배포할 수 있으며 빈번한 번역 업데이트의 필요성이 줄어듭니다. 그러나 릴레이 에이전트 및 실시간 번역 계층(예: Azure Service Copilot 및 Azure Cognitive Services Translator)에 대한 종속성을 도입합니다.

주요 고려 사항:

  • 언어 및 시장: 에이전트가 지원해야 하는 언어와 시장은 현지화 전략에 영향을 미칩니다.

  • 단일 언어와 다국어 에이전트: 여러 언어를 지원하는 단일 에이전트 개발할지 또는 각 언어에 대해 별도의 에이전트를 개발할지 결정합니다. 이 결정은 리소스 가용성, 유지 관리 기능 및 관련된 언어의 복잡성과 같은 요인에 따라 달라집니다.

  • 번역 타이밍: 구성 단계에서 번역을 설정해야 하는지 아니면 런타임에 실시간으로 제공해야 하는지 여부를 고려합니다. 구성된 번역은 안정성과 제어 기능을 제공하는 반면, 실시간 번역은 유연성과 신속한 배포를 제공합니다.

자세히 보기: