대화 언어 이해나 오케스트레이션 워크플로 앱을 사용하는 시기
대규모 애플리케이션을 만들 때 단일 대화형 앱(플랫 아키텍처) 또는 오케스트레이션된 여러 앱에서 사용 사례를 가장 잘 제공하는지 여부를 고려해야 합니다.
오케스트레이션 개요
오케스트레이션 워크플로는 하나의 프로젝트에서 LUIS, 대화 언어 이해 및 사용자 지정 질문 답변의 다양한 프로젝트를 연결할 수 있는 기능입니다. 그런 다음 하나의 엔드포인트를 사용하여 예측을 위해 이 프로젝트를 사용할 수 있습니다. 오케스트레이션 프로젝트는 호출해야 하는 자식 프로젝트를 예측하고 자동으로 요청을 라우팅하며 응답과 함께 반환합니다.
오케스트레이션에는 두 단계가 포함됩니다.
- 호출할 자식 프로젝트 예측
- 발화를 대상 자식 앱으로 라우팅 및 자식 앱 응답 반환
오케스트레이션의 장점
명확한 분해 및 더 빠른 개발:
- 전체 스키마에 도메인이 상당한 수로 있는 경우 오케스트레이션 방식을 사용하면 애플리케이션을 여러 자식 앱(각각 특정 도메인 제공)으로 분해할 수 있습니다. 예를 들어, 자동차 대화형 앱에는 내비게이션 도메인이나 미디어 도메인이 있을 수 있습니다.
- 각 도메인 앱을 병렬로 개발하는 것이 더 쉽습니다. 특정 도메인 전문 지식을 갖춘 사용자와 팀은 개별 앱에서 협업하고 병렬로 작업할 수 있습니다.
- 각 도메인 앱이 더 작으므로 개발 주기가 더 빨라집니다. 규모가 작은 도메인 앱은 단일 대규모 앱보다 학습하는 데 훨씬 적은 시간이 소요됩니다.
보다 유연한 신뢰도 점수 임계값:
- 각 도메인에 별도의 자식 앱이 제공되므로 서로 다른 자식 앱에 대해 별도의 임계값을 쉽게 설정할 수 있습니다.
적절한 경우 AI 품질 향상:
일부 애플리케이션에서는 특정 엔터티에 대한 도메인 제한이 필요합니다. 오케스트레이션을 통해 이 작업을 쉽게 달성할 수 있습니다. 오케스트레이션 프로젝트에서 어떤 자식 앱을 호출해야 할지 예측한 후에는 다른 자식 앱이 호출되지 않습니다.
예를 들어 앱에 미리 빌드된 엔터티
Person.Name이 포함된 경우 차량 질문 컨텍스트에서 "잭을 어떻게 사용하나요?"발화를 고려합니다. 이 컨텍스트에서 잭은 자동차 도구이며 사람 이름으로 인식되어서는 안 됩니다. 오케스트레이션을 사용하면 이러한 질문에 답하기 위해 만들어진 자식 앱으로 해당 발화를 리디렉션할 수 있으며, 해당 자식 앱에는Person.Name엔터티가 없습니다.
오케스트레이션의 단점
자식 앱의 중복 엔터티:
- 도메인과 관계없이 모든 발화에서 미리 빌드된 특정 엔터티가 반환되어야 하는 경우(예:
Quantity.Number또는Geography.Location) 오케스트레이션 앱(의도 전용 모델)에 엔터티를 추가할 방법이 없습니다. 모든 개별 자식 앱에 추가해야 합니다.
- 도메인과 관계없이 모든 발화에서 미리 빌드된 특정 엔터티가 반환되어야 하는 경우(예:
Efficiency:
- 오케스트레이션 앱은 두 가지 모델 유추를 사용합니다. 하나는 호출할 자식 앱 예측용이며 다른 하나는 자식 앱 예측용입니다. 유추 시간은 일반적으로 플랫 아키텍처의 단일 앱보다 느립니다.
오케스트레이터에 대한 학습/테스트 분할:
- 오케스트레이션 앱을 학습해도 테스트와 학습 집합 간에 데이터를 세분화하여 분할할 수 없습니다. 예를 들어, 자식 앱 A에 대해 90-10 분할로 학습한 다음 자식 앱 B에 대해 80-20 분할로 학습할 수는 없습니다. 이러한 제한 사항은 사소할 수 있지만 기억해야 합니다.
플랫 아키텍처 개요
플랫 아키텍처는 대화형 앱을 개발하는 다른 방법입니다. 오케스트레이션 앱을 사용하여 여러 자식 앱 중 하나에 발화를 보내는 대신 발화를 처리하는 단일(또는 플랫) 앱을 개발합니다.
플랫 아키텍처의 장점
단순성:
- 소규모 앱이나 도메인의 경우 오케스트레이터 방식이 지나치게 복잡할 수 있습니다.
- 모든 의도와 엔터티는 동일한 앱 수준에 있으므로 모든 의도와 엔터티를 함께 변경하는 것이 더 쉬울 수 있습니다.
항상 반환되어야 하는 엔터티를 추가하는 것이 더 쉽습니다.
- 미리 빌드된 특정 엔터티나 목록 엔터티를 모든 발화에 반환하려면 단일 앱의 다른 엔터티와 함께 추가해야 합니다. 앞서 언급했듯이 오케스트레이션을 사용하는 경우 모든 자식 앱에 추가해야 합니다.
플랫 아키텍처의 단점
대규모 앱의 경우 다루기 어려울 수 있음:
- 대규모 앱(예: 50개가 넘는 의도나 엔터티)의 경우 변화하는 스키마와 데이터 세트를 추적하기가 어려울 수 있습니다. 이러한 어려움은 앱이 여러 도메인을 서비스해야 하는 경우에 두드러지게 나타납니다. 예를 들어, 자동차 대화형 앱에는 내비게이션 도메인이나 미디어 도메인이 있을 수 있습니다.
엔터티 일치 항목에 대한 제한된 제어:
- 플랫 아키텍처에서는 엔터티가 특정 경우에만 반환되도록 제한할 수 없습니다. 오케스트레이션을 사용하면 특정 엔터티를 특정 자식 앱에 할당할 수 있습니다.