Azure Cognitive Search를 사용하여 규정 준수 위험 분석

Azure AI Search
Azure AI 서비스
Microsoft Graph

이 문서에서는 Azure Cognitive Search를 사용하여 규정 준수 위험 분석 솔루션을 구현하기 위한 기술 지침을 제공합니다. 이 지침은 실제 프로젝트 환경을 기반으로 합니다. 솔루션의 포괄적인 범위와 특정 사용 사례에 맞게 조정해야 할 필요성을 고려하여 이 문서에서는 필수적이고 구체적인 아키텍처 및 구현 측면에 중점을 둡니다. 단계별 자습서를 적절하게 참조합니다.

Apache®, Apache Lucene® 및 불꽃 로고는 미국이나 기타 국가에서 Apache Software Foundation의 등록 상표 또는 상표입니다. 이러한 표시의 사용은 Apache Software Foundation에 의한 보증을 암시하지 않습니다.

소개

금융 기관의 컨설턴트와 거래자는 매일 수백만 달러에 달하는 트랜잭션에 대해 논의하고, 분석하고, 결정합니다. 직원의 사기성 트랜잭션, 공모, 내부 거래 및 기타 위법 행위는 법적 결과와 대중적 이미지 측면에서 모두 이러한 기관에 대한 중대한 위험입니다.

규정 준수 팀은 이 위험을 완화하기 위해 노력합니다. 업무의 일부로 인스턴트 메시징, 메일 및 회사 전화 통화를 포함하여 여러 채널에서 통신을 모니터링하고 있습니다. 종종 모니터링이 비즈니스 트랜잭션 데이터에 대해 교차 검사됩니다. 목표는 종종 숨겨지고 미묘한 비준수의 징후를 찾는 것입니다. 이 작업은 노동 집약적이고 주의를 많이 기울여야 하며 대량의 데이터를 선별하는 작업을 포함합니다. 자동화된 시스템이 도움이 될 수 있지만 간과된 위험의 양이 매우 많을 수 있어서 원래 통신을 검토해야 합니다.

Azure Cognitive Search는 위험 평가의 품질을 자동화하고 개선하는 데 도움이 될 수 있습니다. 기본 제공 AI, 확장 가능한 AI 및 지능형 검색 기능을 제공합니다. 이 문서에 제시된 규정 준수 위험 분석 솔루션은 다양한 통신 채널의 콘텐츠를 통합하고 분석하여 금융 거래자의 위법 행위 같은 위험을 식별하는 방법을 보여 줍니다. 이 비구조적 콘텐츠에서 식별할 수 있는 잠재적 위험에는 시장 조작, 내부 거래, 뮤추얼 펀드 사기 등의 신호가 포함됩니다.

솔루션 아키텍처는 Azure Cognitive Services 및 Azure Cognitive Search를 사용합니다. 이 시나리오는 금융 부문의 통신 위험을 대상으로 하지만 디자인 패턴은 정부, 의료 등의 다른 산업 및 부문으로 이전됩니다. 조직은 비즈니스 시나리오에 적용되는 위험 평가 모델을 개발하고 통합하여 아키텍처를 조정할 수 있습니다. 예를 들어 Wolters Kluwer 데모 앱은 변호사에게 SEC(증권거래위원회) 서류 및 서신에서 관련 정보를 신속하게 찾을 수 있는 기능을 제공합니다. 사이버 보안 및 지적 재산권 위험을 포함하여 자금 조달에 관련된 위험을 식별합니다.

Azure Cognitive Search에는 비즈니스 프로세스 성능과 규정 준수 팀의 생산성을 개선하는 기본 제공 AI 및 사용자 지정 기술이 있습니다. 이 기능은 다음과 같은 경우에 특히 유용합니다.

  • 재무 보고서, 음성 대화 내용 기록, 메일 등 많은 서로 다른 비구조적 문서에서 인사이트를 추출해야 합니다.
  • 비구조적 콘텐츠에 대한 위험 관리 절차는 완전히 적용되지 않았습니다.
  • 기존 접근 방식은 시간 및 노동이 많이 필요하므로 너무 많은 거짓 경보 또는 간과되는 실제 위험이 발생합니다.
  • 보다 포괄적인 위험 분석을 위해 구조적 데이터를 비롯한 다양한 통신 채널과 데이터 원본을 통합해야 합니다.
  • 데이터 및 도메인 지식은 기계 학습 모델을 학습시켜서 비구조적 텍스트에서 위험 신호를 식별하는 데 사용할 수 있습니다. 또는 기존 모델을 통합할 수 있습니다.
  • 아키텍처는 솔루션을 개선하기 위해 대화, 뉴스 등의 새로 사용 가능한 비정형 데이터를 지속적으로 수집하고 처리할 수 있습니다.
  • 규정 준수 분석가는 위험 식별 및 자세한 분석을 위한 효율적인 도구가 필요합니다. 분석가가 프로세스를 제어하고 모델을 개선하기 위해 가능한 잘못된 예측에 플래그를 지정할 수 있도록 도구는 휴먼 인더 루프 도구여야 합니다.

Azure Cognitive Search는 모든 유형의 정보를 보강하는 AI 기능이 기본 제공되는 클라우드 검색 서비스로, 관련 콘텐츠를 대규모로 식별하고 탐색하는 데 도움이 됩니다. 시각 및 언어 인식 기술을 사용하거나 사용자 지정 기계 학습 모델을 사용하여 모든 유형의 콘텐츠에서 인사이트를 발굴합니다. 또한 Azure Cognitive Search는 고급 기계 학습 기술을 사용하여 사용자 의도를 분류하고 상황에 따라 가장 관련성이 높은 검색 결과의 순위를 지정하는 의미 체계 검색 기능을 제공합니다.

다음 다이어그램에서는 데이터 수집 및 인덱싱부터 사용자가 사용할 수 있는 결과를 만드는 것까지 Azure Cognitive Search의 작동 방식을 간략하게 보여 줍니다.

Diagram of high-level view of how Azure Cognitive Search works.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

이 문서에서는 앞에서 언급한 Wolters Kluwer 예제와 같은 위험 분석 사용 사례 및 기타 금융 서비스 시나리오에 대한 솔루션에 관해 자세히 설명합니다. 참조된 방법 설명서 및 참조 아키텍처가 포함된 기술 실행 단계를 제공합니다. 여기에는 조직 및 기술 관점의 모범 사례가 포함됩니다. 디자인 패턴은 고유한 데이터를 가져오고 비즈니스 컨텍스트 및 요구 사항에 적합한 고유한 위험 분석 모델을 개발한다고 가정합니다.

다음 리소스에서 Azure Cognitive Search의 소개를 확인하고 사용해 봅니다.

솔루션 개요

다음 다이어그램에서는 위험 분석 솔루션을 간략하게 보여 줍니다.

Diagram of a high-level view of the risk analysis solution.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

실제 위험 통신을 식별하기 위해 서로 다른 통신 채널의 콘텐츠는 Cognitive Services의 다양한 기계 학습 모델에 의해 추출되고 보강됩니다. 다음으로, 사용자 지정 도메인별 모델을 적용하여 사용자 간 통신 및 상호 작용에서 나타나는 시장 조작 및 기타 위험의 징후를 식별합니다. 모든 데이터는 통합된 Azure Cognitive Search 솔루션으로 집계됩니다. 솔루션은 위험 식별 및 분석 기능이 있는 사용자에게 친숙한 앱으로 구성됩니다. 애플리케이션 데이터는 검색 인덱스 및 지식 저장소에 저장됩니다(장기 스토리지가 필요한 경우).

다음 그림은 솔루션 아키텍처의 개념적 개요를 제공합니다.

Diagram of the conceptual overview of the solution architecture.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

메일, 채팅 및 전화 통신과 같은 각 통신 채널을 격리 상태로 사용하여 잠재적 위험을 탐지할 수 있지만 채널을 결합하고 시장 뉴스와 같은 보완적인 정보로 콘텐츠를 보강하여 더 나은 인사이트를 얻을 수 있습니다.

위험 분석 솔루션은 여러 인터페이스를 사용하여 데이터 수집을 위해 엔터프라이즈 통신 시스템을 통합합니다.

  • Blob Storage는 첨부 파일, 전화 통화 또는 채팅 기록, 뉴스 문서가 포함된 메일 콘텐츠 등 문서 형식의 데이터에 대한 일반 원본으로 사용됩니다.
  • Microsoft Exchange Online 및 Microsoft Teams와 같은 Office 365 통신 서비스는 메일, 채팅 및 기타 콘텐츠를 대량 수집하기 위해 Microsoft Graph 데이터 연결을 사용하여 통합할 수 있습니다. Microsoft 365의 SharePoint에 대한 Azure Cognitive Search 인터페이스도 사용할 수 있습니다.
  • 전화 통화와 같은 음성 통신은 Cognitive Services의 음성 텍스트 변환 서비스를 사용하여 기록됩니다. 그런 다음, 결과 대화 내용 기록 및 메타데이터는 Blob Storage를 통해 Azure Cognitive Search에 의해 수집됩니다.

이 예제에서는 자주 사용되는 엔터프라이즈 통신 채널을 다룹니다. 그러나 추가 채널의 통합도 가능하며 유사한 수집 패턴을 사용할 수 있습니다.

통합 후에는 AI 기술을 통해 원시 데이터를 보강하여 구조를 검색하고 이전에 검색할 수 없었던 콘텐츠 형식에서 텍스트 기반 콘텐츠를 만듭니다. 예를 들면 다음과 같습니다.

  • PowerPoint 파일 또는 PDF의 재무 보고서에는 변경을 방지하기 위해 머신에서 읽을 수 있는 텍스트 대신 포함된 이미지가 들어 있는 경우가 많습니다. 이 종류의 콘텐츠를 처리하기 위해 모든 이미지는 OCR 인식 기술을 사용하여 OCR(광학 인식)을 통해 분석됩니다.
  • 텍스트 번역 인식 기술을 사용하여 다양한 언어의 콘텐츠를 영어 또는 다른 언어로 번역합니다.
  • 사용자 및 조직의 이름과 같은 중요한 정보는 자동으로 추출되며 엔터티 인식 기반 인식 기술을 사용하여 강력한 검색 쿼리에 사용될 수 있습니다. 예를 들어 검색은 지정된 기간 동안 특정 회사에 대해 논의하는 James Doe와 Mary Silva 간의 모든 통신을 찾을 수 있습니다.
  • 사용자 지정 모델은 통신에서 내부 거래 같은 위험 증거를 식별하는 데 사용됩니다. 이 도메인별 모델은 키워드, 발화 또는 전체 단락을 기반으로 할 수 있습니다. 이 모델은 고급 NLP(자연어 처리) 기술을 사용합니다. 사용자 지정 모델은 현재 사용 사례에 대한 도메인별 데이터를 사용하여 학습됩니다.

Azure Cognitive Search AI 보강 및 사용자 지정 기술을 적용한 후 콘텐츠는 검색 인덱스로 통합되어 풍부한 검색 및 지식 마이닝 시나리오를 지원합니다. 규정 준수 분석가 및 기타 사용자는 프런트 엔드 앱을 사용하여 잠재적인 위험 통신을 식별하고 추가 분석을 위해 드릴다운 검색을 수행합니다. 위험 관리는 동적 프로세스입니다. 모델은 프로덕션에서 지속적으로 개선되고 새로운 위험 유형에 대한 모델이 추가됩니다. 따라서 솔루션은 모듈식이어야 합니다. 모델 세트가 확장되면 UI에서 새 위험 유형에 자동으로 플래그가 지정됩니다.

프런트 엔드 앱은 지능형 및 의미 체계 검색 쿼리를 사용하여 콘텐츠를 검사합니다. 규정 준수 보존 또는 다른 시스템과의 통합을 위해 콘텐츠를 지식 저장소로 이동할 수도 있습니다.

솔루션의 구성 요소는 다음 섹션에서 더 자세히 설명합니다.

위험 분석 솔루션 구현은 다양한 도메인의 주요 관련자가 참여해야 하는 종합적인 연습입니다. 환경에 따라 솔루션의 성공적인 개발 및 조직 채택을 보장하려면 다음 역할을 포함하는 것이 좋습니다.

Diagram that shows the roles needed for a successful deployment of the solution.

데이터 수집

이 섹션에서는 서로 다른 콘텐츠를 단일 데이터 원본으로 통합한 다음, 해당 원본에서 파생된 검색 자산의 초기 컬렉션을 설정하는 방법을 설명합니다.

Azure Cognitive Search 솔루션의 개발 및 구현은 일반적으로 증분 프로세스입니다. 데이터 원본, 변환 및 확대는 기준 구성을 기반으로 연속해서 반복적으로 추가됩니다.

Azure Cognitive Search 솔루션의 첫 번째 단계는 Azure Portal에서 서비스 인스턴스를 만드는 것입니다. 검색 서비스 자체 외에도 검색 인덱스, 인덱서, 데이터 원본 및 기술 세트를 비롯한 여러 검색 자산이 필요합니다. Azure Portal에 있는 Azure Cognitive Search의 데이터 가져오기 마법사를 사용하여 쉽게 기준 구성을 만들 수 있습니다. 여기에 설명된 이 마법사는 외부 데이터 원본의 데이터를 사용하는 간단한 검색 인덱스를 만들고 로드하는 기본 단계를 사용자에게 안내합니다.

Screenshot of the import data wizard.

데이터 가져오기 마법사의 검색 인덱스 만들기에는 다음 네 단계가 있습니다.

  1. 데이터에 연결: 예를 들어 몇 번 클릭으로 쉽게 기존 Blob Storage에 연결할 수 있습니다. 연결 문자열은 인증에 사용됩니다. 기본적으로 지원되는 다른 데이터 원본에는 Azure SQL Database, Azure Cosmos DB 등의 다양한 Azure 서비스와 SharePoint Online 등의 서비스가 포함됩니다. 이 솔루션에서 Blob Storage는 서로 다른 콘텐츠 형식을 통합하는 데 사용됩니다.
  2. 인식 기술 추가: 이 선택적 단계에서는 기본 제공 AI 기술이 인덱싱 프로세스에 추가됩니다. 이 기술은 데이터 원본에서 읽은 콘텐츠를 보강하기 위해 적용됩니다. 예를 들어 이 단계에서는 사용자 및 조직의 이름과 위치를 추출할 수 있습니다.
  3. 대상 인덱스 사용자 지정: 이 단계에서 개발자는 인덱스에 대한 필드 엔터티를 구성합니다. 기본 인덱스가 제공되지만 필드를 추가, 삭제하거나 이름을 바꿀 수 있습니다. 예제 필드는 문서 제목, 설명, URL, 작성자, 위치, 회사 및 주식 시세 및 각 필드에서 가능한 작업 유형입니다.
  4. 인덱서 만들기: 마지막 단계에서는 검색 인덱스의 콘텐츠를 업데이트하기 위해 정기적으로 실행되는 구성 요소인 인덱서를 구성합니다. 키 매개 변수는 인덱서를 실행해야 하는 빈도입니다.

구성이 확인되면 데이터 원본, 기술 세트, 인덱서 및 인덱스가 만들어집니다. 이러한 각 구성 요소에 대해 JSON 정의가 만들어집니다. JSON 정의는 향상된 사용자 지정을 제공하며 REST API를 통해 프로그래밍 방식으로 서비스를 만드는 데 사용할 수 있습니다. 이점은 모든 후속 개발 반복 시에 일관된 프로그래밍 방식으로 자산을 만드는 것입니다. 이 이유로 JSON 정의를 사용하여 모든 자산의 구성을 보여 줍니다. 검색 자산 자동 만들기 섹션에서는 이러한 정의를 사용하여 프로그래밍 방식으로 모든 자산을 만드는 방법에 대한 자세한 설명을 제공합니다.

구성에서 Blob Storage가 기본 데이터 원본으로 선택됩니다. 통신이 여러 채널 또는 원본에서 시작될 수 있더라도 이 솔루션 패턴에 대한 일반적인 접근 방식은 Blob Storage에 있고 텍스트 및/또는 이미지를 포함하는 모든 통신을 사용합니다. 다음 단계에서는 Blob Storage에 대한 데이터 원본 JSON 정의의 구성을 확장합니다.

이 섹션에서는 일부 패턴을 참조하여 Blob Storage에 Office 365 통신을 수집하는 방법과 음성 텍스트 변환 서비스를 사용하여 오디오 호출을 기록하는 방법을 예제로 보여 줍니다.

Blob Storage

다음 JSON 정의는 Blob Storage를 Azure Cognitive Search의 데이터 원본으로 구성하는 데 필요한 구조와 정보를 보여 줍니다.

{
  "name": "email-ds",
  "description": "Datasource for emails.",
  "type": "azureblob",
  "subtype": null,
  "credentials": {
    "connectionString": "DefaultEndpointsProtocol=https;AccountName=..."
  },
  "container": {
    "name": "communications",
    "query": "written_comms/emails"
  }
}

다음 필드는 필수입니다.

  • 이름: 데이터 원본에 할당된 이름입니다.
  • 형식: 데이터 원본을 Blob Storage로 정의합니다.
  • 자격 증명: Blob Storage에 대한 연결 문자열입니다.
  • 컨테이너: Blob이 저장되는 컨테이너의 이름입니다. 동일한 컨테이너 내에서 여러 데이터 원본을 만들 수 있도록 컨테이너 내의 디렉터리를 지정할 수 있습니다.

기본적으로 Blob Storage 데이터 원본은 다양한 문서 형식을 지원합니다. 예를 들어 일반적으로 오디오 대화 내용 기록은 JSON 파일에 저장되고, 메일은 MSG 또는 EML 파일이며, 뉴스 또는 추가 통신 자료는 PDF, DOC/DOCX/DOCM과 같은 PDF, Word 형식, PPT/PPTX/PPTM과 같은 PowerPoint 형식 또는 HTML 웹 페이지입니다.

동일한 Blob Storage에서 통신을 위해 여러 데이터 원본을 설정하는 데는 다음 기술 중 하나를 사용할 수 있습니다.

  • 각 데이터 원본에 고유한 컨테이너를 제공합니다.
  • 모든 데이터 원본에 대해 동일한 컨테이너를 사용하지만 각 데이터 원본에 해당 컨테이너의 고유한 디렉터리를 제공합니다.

Microsoft Graph 데이터 연결

Office 365 고객의 경우 Microsoft Graph 데이터 연결을 사용하여 선택된 데이터를 Microsoft Graph에서 Azure Storage에 Azure Cognitive Search 솔루션의 업스트림으로 추출할 수 있습니다. Microsoft Graph에 저장된 데이터에는 메일, 모임, 채팅, SharePoint 문서, 사람, 작업 등의 데이터가 포함됩니다.

참고

이 메커니즘의 사용에는 데이터 동의 프로세스가 적용됩니다.

Diagram of Microsoft Graph Data Connect.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

이 다이어그램은 Microsoft Graph의 데이터 흐름을 보여 줍니다. 이 프로세스는 Azure Data Factory 기능을 사용하여 Microsoft Graph에서 데이터를 추출합니다. 동의 및 거버넌스 모델을 포함한 세분화된 보안 제어가 있습니다. Data Factory 파이프라인은 메일 메시지, 팀 채팅 등의 추출할 데이터 형식과 사용자 그룹, 날짜 범위 등의 범위로 구성됩니다. 검색은 정의된 일정에 따라 구성 가능한 간격으로 실행되며 추출된 데이터를 Azure Storage에 넣도록 구성됩니다. 그런 다음, 인덱서가 데이터를 Azure Cognitive Search로 수집합니다.

다음 문서에는 나중에 Azure Cognitive Search로 수집하기 위해 Data Factory를 통해 Microsoft Graph 데이터 연결에서 Azure Storage로 데이터 추출을 설정하는 방법에 대한 단계별 지침이 포함되어 있습니다.

음성 텍스트 변환 참조 아키텍처

전화 대화는 모든 금융 서비스 조직의 필수 작업 도구입니다. 이 도구는 해당 오디오 파일에 대한 액세스 권한이 있는 경우 위험 분석 솔루션에 포함될 수 있습니다. 이 섹션에서는 해당 상황을 다룹니다.

Azure Cognitive Search의 문서 크래킹은 인덱서가 데이터 원본에서 텍스트와 이미지를 추출하기 위해 실행하는 일련의 처리 단계입니다. 오디오 파일의 경우 텍스트 기반 처리에 사용할 수 있도록 이 오디오 통신의 대화 내용 기록을 추출하는 방법이 필요합니다.

다음 다이어그램은 오디오 수집 및 음성 텍스트 변환 파이프라인을 보여 줍니다. 파이프라인은 오디오 파일을 일괄 처리하고 대화 내용 기록 파일을 Blob Storage에 Azure Cognitive Search 솔루션의 업스트림으로 저장합니다.

Diagram of a speech-to-text pipeline.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

이 참조 아키텍처에서 오디오 파일은 클라이언트 애플리케이션을 통해 Blob Storage에 업로드됩니다. 이 프로세스 중에 애플리케이션은 Microsoft Entra ID를 사용하여 인증하고 REST API를 호출하여 Blob Storage에 대한 토큰을 가져옵니다. REST API에 대한 보안 액세스는 Azure API Management에서 제공하며, Azure Key Vault는 토큰을 생성하는 데 필요한 비밀과 계정 자격 증명을 안전하게 저장합니다.

파일이 업로드된 후 Azure 함수를 호출하기 위해 Azure Event Grid 트리거를 내보냅니다. 그런 다음, 함수는 Cognitive Services 음성 텍스트 변환 API를 사용하여 오디오 파일을 처리합니다. 기록된 JSON 문서는 별도의 Blob 컨테이너에 저장되며 Azure Cognitive Search에서 데이터 원본으로 수집할 수 있습니다.

음성 대화 내용 기록에 대한 자세한 내용은 다음 문서를 참조하세요.

솔루션 검색

설명된 대로 메일, 대화 내용 기록, 뉴스 등의 여러 데이터 원본이 만들어진 후 Blob Storage에 저장됩니다. 그런 다음, 각 데이터 원본은 고유한 방식으로 변환되고 보강됩니다. 결과 출력은 모두 동일한 인덱스에 매핑되어 모든 유형 원본 문서의 데이터를 통합합니다.

다음 다이어그램에서는 이 접근 방식을 보여 줍니다. 사용자 지정 인덱서는 사용 가능한 각 데이터 원본에 대해 구성되며 모든 결과는 하나의 검색 인덱스를 공급합니다.

Diagram that shows how indexers transform data for consolidating.

다음 섹션에서는 인덱싱 엔진 및 검색 가능한 인덱스를 살펴봅니다. 인덱서 구성 방법과 JSON 정의를 인덱싱하여 검색 가능한 솔루션을 구현하는 방법을 보여 줍니다.

인덱서

인덱서는 문서 콘텐츠의 추출 및 보강을 오케스트레이션합니다. 인덱서 정의에는 수집할 데이터 원본에 대한 세부 정보, 필드를 매핑하는 방법 및 데이터를 변환하고 보강하는 방법이 포함됩니다.

매핑, 변환 및 보강은 데이터 형식에 따라 달라지기 때문에 각 데이터 원본에 대한 인덱서가 있어야 합니다. 예를 들어 메일을 인덱싱하려면 이미지와 첨부 파일을 처리하는 OCR 기술이 필요할 수 있지만 대화 내용 기록에는 언어 기반 기술만 필요합니다.

인덱싱 프로세스의 단계는 다음과 같습니다.

  • 문서 크래킹: Azure Cognitive Search가 열리고 문서에서 관련 콘텐츠를 추출합니다. 추출된 인덱싱 가능한 콘텐츠는 데이터 원본 및 파일 형식의 기능입니다. 예를 들어 Blob Storage의 PDF 또는 Microsoft 365 파일 같은 파일의 경우 인덱서는 파일을 열고 텍스트, 이미지, 메타데이터를 추출합니다.
  • 필드 매핑: 원본에서 추출된 필드의 이름은 검색 인덱스의 대상 필드에 매핑됩니다.
  • 기술 세트 실행: 기본 제공 또는 사용자 지정 AI 처리는 이후 섹션의 설명대로 이 단계에서 수행됩니다.
  • 출력 필드 매핑: 변환되거나 보강된 필드의 이름은 인덱스의 대상 필드에 매핑됩니다.

다음 코드 조각은 메일 인덱서 JSON 정의의 세그먼트를 보여 줍니다. 이 정의는 단계에 자세히 설명된 정보를 사용하고 인덱싱 엔진에 대한 자세한 지침 세트를 제공합니다.

{
  "name": "email-indexer",
  "description": "",
  "dataSourceName": "email-ds",
  "skillsetName": "email-skillset",
  "targetIndexName": "combined-index",
  "disabled": null,
  "schedule": {
    "interval": "P1D",
    "startTime": "2021-10-17T22:00:00Z"
  },
  "parameters": {
    "batchSize": null,
    "mixabilities": 50,
    "maxFailedItemsPerBatch": 0,
    "base64EncodeKeys": null,
    "configuration": {
      "imageAction": "generateNormalizedImages",
      "dataToExtract": "contentAndMetadata",
      "parsingMode": "default"
    }
  },
  "fieldMappings": [
    {
      "sourceFieldName": "metadata_storage_path",
      "targetFieldName": "metadata_storage_path",
      "mappingFunction": {
        "name": "base64Encode",
        "parameters": null
      }
    }
  ],
  "outputFieldMappings": [
    {
      "sourceFieldName": "/document/merged_content/people",
      "targetFieldName": "people"
    },
    {
      "sourceFieldName": "/document/merged_content/organizations",
      "targetFieldName": "organizations"
    },

이 예제에서 인덱서는 고유한 이름 email-indexer로 식별됩니다. 이 인덱서는 email-ds라는 데이터 원본을 참조하고 AI 보강은 email-skillset라는 기술 세트를 통해 정의됩니다. 인덱싱 프로세스의 출력은 combined-index라는 인덱스에 저장됩니다. 추가 세부 정보에는 매일로 설정된 일정, 최대 50개 실패한 항목 수, 정규화된 이미지를 생성하고 콘텐츠와 메타데이터를 추출하는 구성이 포함됩니다.

필드 매핑 섹션에서 metadata_storage_path 필드base64encoder를 사용하여 인코딩되어 고유한 문서 키 역할을 합니다. 출력 필드 매핑 구성(부분적으로만 표시됨)에서 보강 프로세스의 출력은 인덱스 스키마에 매핑됩니다.

새 데이터 원본(예: 대화 내용 기록)에 대한 새 인덱서가 만들어지면 대부분의 JSON 정의는 데이터 원본 및 기술 세트 선택에 맞게 구성됩니다. 그러나 대상 인덱스는 결합된 인덱스여야 합니다(모든 필드 매핑이 호환되는 경우). 이는 인덱스가 여러 데이터 원본의 결과를 통합할 수 있도록 하는 기술입니다.

인덱스 및 기타 구조

인덱싱 프로세스가 완료된 후 추출되고 확대된 문서는 검색 가능한 인덱스 및 필요에 따라 지식 저장소에 유지됩니다.

  • 검색 가능한 인덱스: 검색 가능한 인덱스는 항상 인덱싱 프로세스의 일부로 만들어지는 필요한 출력에 해당하며 검색 카탈로그라고도 합니다. 인덱스를 만들려면 인덱스 정의가 필요합니다. 여기에는 모든 필드에 대한 구성(예: 형식, 검색 가능(searchable), 필터링 가능, 정렬 가능, 패싯 가능 및 검색 가능(retrievable))이 포함됩니다. 이러한 인덱스 필드 이름은 인덱서 필드 및 출력 필드 매핑에 맞게 조정되어야 합니다.

    여러 인덱서를 동일한 인덱스에 할당할 수 있으므로 인덱스는 메일 또는 대화 내용 기록과 같은 다양한 데이터 세트의 통신을 통합합니다. 그런 다음, 전체 텍스트 검색 또는 의미 체계 검색을 사용하여 인덱스 쿼리를 수행할 수 있습니다.

    인덱서와 비슷하게 인덱스 JSON 정의를 사용하여 인덱스를 구성할 수 있습니다. 다음 코드 조각은 결합된 인덱스 JSON 정의의 세그먼트에 해당합니다.

    {
    "name": "combined-index",
    "fields": [
      {
        "name": "metadata_storage_path",
        "type": "Edm.String",
        "facetable": false,
        "filterable": false,
        "key": true,
        "retrievable": true,
        "searchable": false,
        "sortable": false,
        "analyzer": null,
        "indexAnalyzer": null,
        "searchAnalyzer": null,
        "synonymMaps": [],
        "fields": []
      },
      {
        "name": "people",
        "type": "Collection(Edm.String)",
        "facetable": true,
        "filterable": true,
        "retrievable": true,
        "searchable": true,
        "analyzer": "standard.lucene",
        "indexAnalyzer": null,
        "searchAnalyzer": null,
        "synonymMaps": [],
        "fields": []
      },
    

    이 예제에서 인덱스는 고유한 이름 combined-index로 식별됩니다. 인덱스 정의는 인덱서, 데이터 원본 또는 기술 세트와 독립적입니다. 필드는 인덱스의 스키마를 정의하며 구성 시 사용자는 각 필드의 이름과 형식뿐만 아니라 패싯 가능, 필터링 가능 등의 속성 세트를 구성할 수 있습니다.

    이 코드 조각에는 두 개의 필드가 포함됩니다. Metadata_storage_path는 문서 키로 사용되는 검색 가능 문자열입니다. 반면에 people 필드는 패싯 가능, 필터링 가능, 검색 가능(retrievable) 및 검색 가능(searchable)할 수 있는 문자열의 컬렉션이며 전체 텍스트 쿼리는 standard.lucene 분석기를 사용하여 처리됩니다.

  • 지식 저장소: 지식 저장소는 지식 마이닝 같은 검색 이외 시나리오에서 독립적인 분석 및 다운스트림 처리에 사용되는 선택적 출력일 수 있습니다. 지식 저장소 구현은 보강된 문서 또는 특정 필드를 테이블 또는 파일로 프로젝션하도록 구성할 수 있는 기술 세트 내에 정의됩니다.

    다음 그림에서는 지식 저장소의 구현을 보여 줍니다.

    Diagram that illustrates how to implement a knowledge store.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

Azure Cognitive Search 지식 저장소를 사용하면 다음 옵션(프로젝션이라고 함)을 사용하여 데이터를 유지할 수 있습니다.

  • 파일 프로젝션을 사용하면 콘텐츠(예: 포함된 이미지)를 파일로 추출할 수 있습니다. 예를 들면 이미지 파일 형식으로 내보낸 재무 보고서의 다이어그램 또는 차트가 있습니다.
  • 테이블 프로젝션은 테이블 형식 보고 구조(예: 분석 사용 사례)를 지원합니다. 각 문서의 위험 점수와 같은 집계된 정보를 저장하는 데 사용할 수 있습니다.
  • 개체 프로젝션은 콘텐츠를 JSON 개체로 Blob Storage에 추출합니다. 규정 준수를 위해 데이터를 세부 정보로 보존해야 하는 경우 위험 분석 솔루션에 사용할 수 있습니다. 위험 점수는 이 접근 방식을 사용하여 보관할 수 있습니다.

검색 데이터의 구조는 쿼리에 최적화되어 있으므로 일반적으로 지식 저장소로 내보내는 것과 같은 다른 용도에 최적화되지 않습니다. 쉐이퍼 기술을 사용하여 프로젝션을 적용하기 전에 보존 요구 사항에 맞게 데이터를 다시 구성할 수 있습니다.

지식 저장소에서 지속형 콘텐츠는 테이블 또는 Blob Storage의 Azure Storage에 저장됩니다.

지식 저장소의 데이터를 사용하기 위한 여러 옵션이 있습니다. Azure Machine Learning은 기계 학습 모델을 빌드하기 위해 콘텐츠에 액세스할 수 있습니다. Power BI는 데이터를 분석하고 시각적 개체를 만들 수 있습니다.

금융 조직에는 장기 규정 준수 보존을 위한 기존 정책과 시스템이 있습니다. 따라서 Azure Storage는 이 사용 사례에 이상적인 대상 솔루션이 아닐 수 있습니다. 데이터가 지식 저장소에 저장된 후 Data Factory는 데이터를 데이터베이스와 같은 다른 시스템으로 내보낼 수 있습니다.

쿼리 엔진

인덱스가 만들어지면 Azure Cognitive Search를 통해 전체 텍스트 및 의미 체계 검색을 사용하여 쿼리할 수 있습니다.

  • 전체 텍스트 검색은 Apache Lucene 쿼리 엔진을 기반으로 빌드되며 인덱스의 모든 검색 가능한 필드에서 검색 매개 변수에 전달되는 용어 또는 구를 허용합니다. 일치하는 용어가 발견되면 쿼리 엔진은 관련성 순서로 문서의 순위를 지정하고 상위 결과를 반환합니다. 점수 매기기 프로필을 통해 문서 순위를 사용자 지정할 수 있으며 인덱스 정렬 가능 필드를 사용하여 결과를 정렬할 수 있습니다.
  • 의미 체계 검색은 의미 체계 관련성 및 언어 이해를 사용하여 검색 결과의 품질을 개선하는 강력한 기능 세트를 제공합니다. 사용하도록 설정하면 의미 체계 검색은 다음과 같은 방법으로 검색 기능을 확장합니다.
    • 의미 체계 순위 재지정은 쿼리의 컨텍스트 또는 의미 체계 의미를 사용하여 기존 결과에 대한 새 관련성 점수를 계산합니다.
    • 의미 체계 강조 표시는 콘텐츠를 가장 잘 요약하는 문장과 구를 문서에서 추출합니다.

사용자 인터페이스 섹션에는 의미 체계 검색의 기능 예제가 포함되어 있습니다. 의미 체계 검색은 퍼블릭 미리 보기로 제공됩니다. 해당 기능에 대한 자세한 내용은 설명서에서 확인할 수 있습니다.

검색 자산 자동 만들기

검색 솔루션 개발은 반복 프로세스입니다. Azure Cognitive Search 인프라 및 데이터 원본, 인덱스, 인덱서, 기술 세트 등 검색 자산의 초기 버전을 배포한 후 솔루션을 지속적으로 개선합니다(예: AI 기술 추가 및 구성을 통해).

일관성과 빠른 반복을 보장하려면 Azure Cognitive Search 자산을 만드는 프로세스를 자동화하는 것이 좋습니다.

솔루션의 경우 다음 그림과 같이 Azure Cognitive Search의 REST API를 사용하여 자동화된 방식으로 10개 자산을 배포합니다.

Diagram that shows the use of the REST API to automate the deployment of assets.

솔루션에는 메일, 대화 내용 기록, 뉴스 문서에 대한 다양한 처리 및 AI 보강이 필요하므로 고유한 데이터 원본, 인덱서, 기술 세트를 만듭니다. 그러나 모든 채널에 단일 인덱스를 사용하여 위험 분석 솔루션 사용을 간소화하기로 결정했습니다.

10개 항목 각각에는 해당 구성을 지정하는 연결된 JSON 정의 파일이 있습니다. 설정에 대한 설명은 이 가이드의 예제 코드 상자를 참조하세요.

JSON 사양은 표시된 순서대로 build-search-config.py 스크립트에서 수행한 API 요청을 통해 Azure Cognitive Search에 전송됩니다. 다음 예제에서는 email-skillset.json에 지정된 메일 기술 세트를 만드는 방법을 보여 줍니다.

url = f"https://{search_service}.search.windows.net/skillsets?api-version=2020-06-30-Preview"
headers = {'Content-type': 'application/json', 'api-key': cog_search_admin_key}

r = requests.post(url, data=open('email-skillset.json', 'rb'), headers=headers)

print(r)
  • search_service는 Azure Cognitive Search 리소스의 이름입니다.
  • cog_search_admin_key는 관리자 키입니다. 관리 작업에는 쿼리 키를 사용하는 것으로 충분하지 않습니다.

모든 구성 요청이 수행되고 인덱스가 로드된 후 REST 쿼리는 검색 솔루션이 제대로 응답하는지 여부를 확인합니다. 모든 자산이 생성되고 인덱서가 초기 실행을 완료하기 전에 시간 지연이 있습니다. 처음 쿼리하기 전에 몇 분 정도 기다려야 할 수 있습니다.

Azure Cognitive Search REST API를 사용하여 Blob Storage 콘텐츠를 인덱싱하기 위한 구성을 프로그래밍 방식으로 만드는 방법에 대한 내용은 자습서: REST 및 AI를 사용하여 Azure Blob에서 검색 가능한 콘텐츠 생성을 참조하세요.

AI 보강

이전 섹션에서는 위험 분석 솔루션의 기반을 빌드했습니다. 이제 원시 콘텐츠에서 실질적인 비즈니스 인사이트로 정보를 처리하는 데 집중해야 합니다.

콘텐츠를 검색 가능하도록 설정하기 위해 통신 콘텐츠는 기본 제공 기술과 사용자 지정 모델을 위험 탐지에 사용하는 AI 보강 파이프라인을 통해 전달됩니다.

Diagram that shows an AI enrichment pipeline.

먼저 위험 분석 솔루션에 사용한 예제 기술 1~4를 기반으로 기본 제공 기술을 사용하는 방법을 살펴봅니다. 그런 다음, 위험 모델을 통합하기 위한 사용자 지정 기술을 추가하는 방법을 알아봅니다(5단계). 마지막으로, 기술 파이프라인을 검토하고 디버그하는 방법을 알아봅니다.

다음 섹션에서는 개념적 소개를 제공합니다. 실습 환경은 Microsoft Learn 단계별 가이드를 참조하세요.

기본 제공 AI 보강 기술

적용된 AI 보강의 파이프라인을 Azure Cognitive Search 기술 세트라고 합니다. 다음 기본 제공 기술은 위험 분석 솔루션에 사용됩니다.

  • 광학 인식: 재무 보고서는 콘텐츠 변경을 방지하기 위해 텍스트가 아닌 이미지에 포함된 상당한 양의 콘텐츠를 포함할 수 있습니다. 다음 프레젠테이션에서는 Microsoft 분기별 보고서의 예제를 보여 줍니다.

    Screenshot of an example of content embedded in an image.

    데크의 모든 슬라이드에는 그래픽 콘텐츠만 포함됩니다. 정보를 활용하기 위해 OCR 인식 기술은 메일(특히 첨부 파일과 관련이 있음) 및 시장 뉴스 문서에 사용됩니다. 이 기술을 사용하면 머신이 원래 콘텐츠를 읽을 수 없는 경우에도 이전 예제의 “자본 지출”과 같은 검색 쿼리는 슬라이드에서 텍스트를 찾을 수 있습니다. 사용자가 텍스트에 포함되지 않은 “자본 지출”에 대한 대체 용어를 이용하는 경우 의미 체계 검색을 통해 검색 관련성이 더욱 향상됩니다.

  • 언어 감지: 글로벌 조직에서 기계 번역 지원은 일반적인 요구 사항입니다. 예를 들어 규정 준수 분석가 팀이 영어로 일관되게 읽고 통신하는 것을 선호한다고 가정하면 솔루션은 콘텐츠를 정확하게 번역할 수 있어야 합니다. 언어 감지 인식 기술은 원본 문서의 언어를 식별하는 데 사용됩니다. 이 정보는 원하는 대상 언어로 번역이 필요한지 여부를 식별하는 데 사용되며 사용자에게 원래 언어를 나타내기 위해 사용자 인터페이스에도 표시됩니다.

  • 사용자 및 조직 추출:엔터티 인식 기반 인식 기술은 비구조적 텍스트에서 사람, 위치, 조직 및 기타 엔터티를 식별할 수 있습니다. 이 정보는 서로 다른 콘텐츠의 큰 본문에서 검색 또는 탐색(예: 필터링 및 패싯)을 개선하는 데 사용할 수 있습니다. 위험 분석 솔루션의 경우 사용자(예: 거래자 이름) 및 조직(예: 회사 이름)의 추출이 선택되었습니다.

    메일용 기술 세트에 대한 JSON 정의의 다음 예제에서는 선택한 구성에 대한 세부 정보를 제공합니다.

    "skills": [
      {
        "@odata.type": "#Microsoft.Skills.Text.V3.EntityRecognitionSkill",
        "name": "Detect Entities",
        "description": "Detect people and organizations in emails",
        "context": "/document/merged_content",
        "categories": [
          "Person",
          "Organization"
        ],
        "defaultLanguageCode": "en",
        "minimumPrecision": 0.85,
        "modelVersion": null,
        "inputs": [
          {
            "name": "text",
            "source": "/document/merged_content"
          },
          {
            "name": "languageCode",
            "source": "/document/original_language"
          }
        ],
        "outputs": [
          {
            "name": "persons",
            "targetName": "people"
          },
          {
            "name": "organizations",
            "targetName": "organizations"
          }
        ]
      },
    

    먼저 콘텐츠에서 사용자 및 조직의 추출을 지정합니다. 다른 범주가 있으며(예: 위치) 필요한 경우 추출될 수 있습니다. 그러나 처음에 너무 많은 정보가 사용자를 혼란스럽게 만들지 않도록 이러한 두 엔터티에 대한 추출을 의도적으로 제한했습니다.

    AI 솔루션이 100% 정확도를 제공하지 않으므로 항상 가양성(예: 실제로 조직이 아닌 조직 이름)과 가음성(예: 실제 조직이 간과됨)의 위험이 있습니다. Azure Cognitive Search는 엔터티 추출 시 신호 대 노이즈 비율의 균형을 맞추는 컨트롤을 제공합니다. 이 경우 검색의 최소 정밀도를 0.85로 설정하여 인식 관련성을 높이고 노이즈를 줄입니다.

    다음 단계에서는 보강된 문서 내의 기술 세트에 대한 입력과 출력을 지정합니다. 입력 경로는 메일 및 첨부 파일을 포함하는 merged_content를 가리킵니다. 첨부 파일 콘텐츠에는 OCR을 사용하여 추출된 텍스트가 포함됩니다.

    마지막으로, 지정된 엔터티에 대한 출력 이름 사용자조직을 정의합니다. 나중에 이 이름은 인덱서 정의의 일부로 검색 인덱스에 매핑됩니다.

    기타 기술 정의는 유사한 패턴을 따르고 기술별 설정으로 보완됩니다.

  • 번역: 다음 단계에서 외국어를 포함하는 문서를 실제로 영어로 번역합니다. 텍스트 번역 인식 기술은 변환에 사용됩니다. 원본 및 대상 언어가 동일한 경우에도 번역 요금은 텍스트가 Translator Text API로 전송될 때마다 측정됩니다. 이런 상황의 서비스 요금을 방지하기 위해 추가 조건부 인식 기술을 사용하여 이 경우에 번역을 무시합니다.

Azure Cognitive Search의 데이터 가져오기 도우미를 사용하여 콘텐츠 수집 및 보강을 빠르게 시작할 수 있습니다. 앞으로는 자동화된 방식으로 기술 세트 및 기타 Azure Cognitive Search 자산을 만들 수 있습니다. 다음 문서에서는 자세한 정보를 제공합니다.

위험 탐지를 위한 사용자 지정 AI 보강

이제 Azure Cognitive Search에서 원하는 기본 제공 기술을 구현했으므로 위험 분석을 위해 사용자 지정 모델을 추가하는 방법을 살펴보겠습니다.

통신 콘텐츠에서 의도적 또는 실제 부정 행위를 식별하는 것은 항상 컨텍스트에 따라 달라지며 광범위한 도메인 지식이 필요합니다. 위험 분석 솔루션의 주요 목표는 특정 비즈니스 시나리오에 대한 진정한 위험을 파악하기 위해 사용자 지정 위험 모델을 보강 파이프라인에 유연하게 통합하고 적용하는 방법을 제공하는 것입니다.

사용 사례에 따라 다음 대화 예제는 잠재적인 의도적 위법 행위를 나타낼 수 있습니다.

Illustration that shows a conversation that suggests intended misconduct.

다음 옵션은 비구조적 통신 콘텐츠를 구문 분석하여 위험을 식별할 수 있습니다.

  • 키워드 기반 접근 방식: 이 기술은 관련 키워드 목록(예: 오프라인, 특수 인사이트)을 사용하여 잠재적 위험을 식별합니다. 이 접근 방식은 구현하기 쉽지만 콘텐츠의 공식이 키워드와 일치하지 않는 경우 위험을 간과할 수 있습니다.
  • 엔터티 인식 기반 접근 방식: 기계 학습 모델은 언어 모델을 사용하여 위험을 식별하기 위해 짧은 발화(예: 문장)를 학습합니다. 전문가 지식은 해당 위험 분류(예: 시장 조작, 내부 거래)를 사용하여 대표적인 예제의 학습 집합을 만드는 데 사용됩니다. 이 기술의 주요 이점은 발화에서 의미 체계 의미가 비슷하지만 학습 집합의 예제와는 공식이 다른 경우 위험을 식별할 가능성이 있다는 것입니다. Azure 대화 언어 이해 서비스는 이 용도로 사용할 수 있습니다.
  • 고급 NLP 기반 접근 방식: 신경망의 최근 발전 덕분에 분류 및 기타 NLP 작업을 포함하여 비구조적 텍스트의 더 긴 세그먼트를 분석할 수 있습니다. 이 접근 방식은 더 검색하기 힘들고 여러 문장이나 단락에 걸쳐 있는 신호를 식별할 수 있습니다. 이 접근 방식의 단점은 일반적으로 다른 기술에 비해 훨씬 더 많은 학습 데이터가 필요하다는 것입니다. Azure는 사용자 지정 텍스트 분류자동화된 Machine Learning을 포함하여 NLP 모델을 학습시키기 위한 여러 옵션을 제공합니다.

REST 웹 서비스로 제공되는 모든 모델을 사용자 지정 기술로 Azure Cognitive Search 위험 분석 솔루션에 통합할 수 있습니다. 이 예제에서는 Azure Cognitive Search와 모델 간의 인터페이스 역할을 하는 Azure 함수와 대화 언어 이해 모델 세트를 통합합니다. 다음 다이어그램에서는 이 기술을 보여 줍니다.

Diagram that shows how to integrate a custom skill.

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

기본 제공 기술을 처리한 후 메일 및 대화 내용 기록에서 위험을 검사합니다. 사용자 지정 기술은 전처리를 위해 문서 형식과 해당 콘텐츠를 Azure Functions 앱에 제공합니다. 앱은 게시된 예제를 기반으로 하며 다음 작업을 수행합니다.

  1. 사용할 모델 결정: 조직은 고유한 모델을 사용하여 여러 유형의 위험(예: 시장 조작, 내부 거래, 뮤추얼 펀드 사기)을 식별할 수 있습니다. Functions 앱은 구성된 기본 설정에 따라 사용 가능한 모델을 활성화합니다.
  2. 콘텐츠 전처리: 이 작업에는 위험 모델을 학습시키는 데 사용되는 데이터 구조와 일치하도록 첨부 파일 콘텐츠를 삭제하고 텍스트를 문장으로 분할하는 작업이 포함됩니다.
  3. 구성된 위험 모델에 토큰화된 콘텐츠 보내기: 위험 모델은 각 문장에 위험 점수를 할당합니다.
  4. 결과 집계 및 채점: 이 작업은 결과를 기술 세트로 반환하기 전에 수행됩니다. 문서 위험 점수는 모든 문장의 가장 높은 위험입니다. 식별된 최상위 위험 문장도 UI에 표시하기 위해 반환됩니다. 또한 문서 위험은 점수에 따라 낮음, 중간 또는 높음 위험으로 분류됩니다.
  5. Azure Cognitive Search 인덱스에 정보 기록: 정보는 규정 준수 분석가 UI 및 지식 저장소에서 사용됩니다. 여기에는 모든 통신 콘텐츠, 기본 제공 보강 및 사용자 지정 위험 모델의 결과가 포함됩니다.

다음 JSON 예제에서는 Azure Cognitive Search와 Functions 앱(위험 모델을 호출) 간 인터페이스 정의를 사용자 지정 기술로 보여 줍니다.

   {
      "@odata.type": "#Microsoft.Skills.Custom.WebApiSkill",
      "name": "apply-risk-models",
      "description": "Obtain risk model results",
      "context": "/document/content",
      "uri": "https://risk-models.azurewebsites.net/api/luis-risks?...",
      "httpMethod": "POST",
      "timeout": "PT3M",
      "batchSize": 100,
      "degreeOfParallelism": null,
      "inputs": [
        {
          "name": "text",
          "source": "/document/mergedenglishtext"
        },
        {
          "name": "doc_type",
          "source": "/document/type"
        }
      ],
      "outputs": [
        {
          "name": "risk_average",
          "targetName": "risk_average"
        },
        {
          "name": "risk_models",
          "targetName": "risk_models"
        }
      ],
    },

URI는 Azure Cognitive Search에서 다음 입력을 가져오는 Functions 앱의 웹 주소를 지정합니다.

  • text에는 영어 콘텐츠가 포함되어 있습니다.
  • doc_type은 대화 내용 기록, 메일 및 시장 뉴스를 구분하는 데 사용되며 여러 전처리 단계가 필요합니다.

Functions 앱은 언어용 Azure Cognitive Service의 대화 언어 이해 기능에서 위험 점수를 받은 후 통합 결과를 Azure Cognitive Search에 반환합니다.

금융 서비스 조직에서는 기존 및 신규 위험 모델을 유연하게 결합하기 위한 모듈식 접근 방식이 필요합니다. 따라서 특정 모델의 하드 코딩은 수행되지 않습니다. 대신 risk_models는 위험 점수 및 위험 점수가 가장 높은 식별된 문장을 포함하여 각 위험 유형(예: 내부 거래)에 대한 세부 정보를 반환하는 복잡한 데이터 형식입니다. 규정 준수 및 추적 가능성은 금융 서비스 조직의 주요 관심사입니다. 그러나 위험 모델은 지속적으로 개선되므로(예: 새 학습 데이터 활용) 문서에 대한 예측은 시간이 지남에 따라 변경될 수 있습니다. 추적 가능성을 보장하기 위해 위험 모델의 특정 버전도 각 예측과 함께 반환됩니다.

아키텍처를 다시 사용하여 더 많은 고급 NLP 모델을 통합할 수 있습니다(예: 여러 발화에 걸쳐 있을 수 있는 더 미묘한 위험 신호를 식별할 수 있도록 함). 기본 조정은 Functions 앱의 전처리 단계를 NLP 모델 학습을 위해 수행된 전처리와 일치시키는 것입니다.

구현 방법:

AI 보강 파이프라인 디버그

대규모 기술 세트의 경우 정보 흐름과 AI 보강을 이해하는 것이 어려울 수 있습니다. Azure Cognitive Search는 기술의 입력 및 출력을 포함하여 보강 파이프라인을 디버그하고 시각화하는 데 유용한 기능을 제공합니다.

Illustration of capabilities for debugging an enrichment pipeline.

순서도는 Azure Portal에서 Azure Cognitive Search 리소스의 디버그 세션 탭에서 추출되었습니다. 순서도에서는 콘텐츠가 기술 세트의 기본 제공 기술 및 사용자 지정 위험 모델을 통해 연속적으로 처리됨에 따라 보강 흐름을 요약합니다.

기술 그래프의 처리 흐름은 기술의 입력 및 출력 구성에 따라 Azure Cognitive Search에서 자동으로 생성됩니다. 또한 그래프는 처리 중인 병렬 처리 수준을 보여 줍니다.

문서 형식(메일, 대화 내용 기록 또는 뉴스)은 이후 단계에서 서로 다르게 처리되므로 조건부 기술을 사용하여 문서 형식을 식별합니다. 원래 언어와 대상 언어가 동일한 경우 조건부 기술을 사용하여 번역 요금을 방지합니다.

기본 제공 기술에는 OCR, 언어 감지, 엔터티 검색, 번역 및 텍스트 병합이 포함되며, 이 기술은 포함된 이미지를 원본 문서의 포함된 OCR 출력으로 바꾸는 데 사용됩니다.

파이프라인의 마지막 기술은 Functions 앱을 통해 대화 언어 이해 위험 모델을 통합하는 것입니다.

마지막으로, 원래 필드와 보강된 필드는 인덱싱되고 Azure Cognitive Search 인덱스에 매핑됩니다.

검색 응답에서 발췌한 다음 예제는 보강된 콘텐츠 및 의미 체계 검색을 사용하여 얻을 수 있는 인사이트를 보여 줍니다. 쿼리 용어는 “capex가 어떻게 되었나요”(“보고 기간에 자본 지출이 어떻게 개발되었나요?”의 약어)입니다.

{
 "@search.captions" : [
  {
   "highlights" : "Cash flow from operations was $22.7 billion, up 2296 year-over-year,   driven by strong cloud billings and collections Free cash flow of $16.3 billion, up 1796 year-over-year, reflecting higher<em> capital expenditures</em> to support our cloud business 6 includes non-GAAP constant currency CCC\") growth and cash flow."
  }],
 "sender_or_caller" : "Jim Smith",
 "recipient" : "Mary Turner",
 "metadata_storage_name" : "Reevaluate MSFT.msg",
 "people" : ["Jim Smith", "Mary Turner", "Bill Ford", … ],
 "organizations" : ["Microsoft", "Yahoo Finance", "Federal Reserve", … ],
 "original_language" : "nl",
 "translated_text" : "Here is the latest update about …",
 "risk_average" : "high",
 "risk_models" : [
  {
   "risk" : "Insider Trade",
   "risk_score" : 0.7187,
   "risk_sentence" : "Happy to provide some special insights to you. Let’s take this conversation offline.",
   "risk_model_version" : "Inside Trade v1.3"
  },
 ]
}

사용자 인터페이스

검색 솔루션이 구현된 후 Azure Portal을 사용하여 인덱스를 직접 쿼리할 수 있습니다. 이 옵션은 학습, 실험 및 디버깅에 적합하지만 좋은 최종 사용자 환경이 아닙니다.

사용자 환경에 초점을 맞춘 사용자 지정 사용자 인터페이스는 검색 솔루션의 진정한 가치를 보여 주고 조직이 광범위한 채널과 원본에서 위험 통신을 식별하고 검토할 수 있도록 하는 데 유용합니다.

지식 마이닝 솔루션 가속기는 검색 결과를 쿼리하고 보기 위해 프로토타입을 빠르게 빌드하는 데 사용할 수 있는 .NET Core MVC 웹앱인 Azure Cognitive Search UI 템플릿을 제공합니다.

몇 단계에 걸쳐 검색 인덱스를 연결 및 쿼리하도록 템플릿 UI를 구성하여 결과를 검색하고 시각화하는 간단한 웹 페이지를 렌더링할 수 있습니다. 이 템플릿은 위험 통신을 검색하고 분석하는 환경을 개선하기 위해 추가로 사용자 지정할 수 있습니다.

다음 스크린샷은 Azure Cognitive Search UI 템플릿을 사용자 지정하여 만들어진 위험 시나리오에 대한 샘플 사용자 인터페이스를 보여 줍니다. 이 UI는 채널 간 통신 및 위험 정보에 대한 직관적인 보기를 제공하여 검색 솔루션을 표시하는 방법을 보여 줍니다.

Screenshot of a custom user interface created from the Azure Cognitive Search UI template.

시작 페이지에서는 검색 솔루션에 대한 상호 작용을 제공합니다. 사용자가 결과를 검색, 구체화, 시각화 및 탐색할 수 있습니다.

  1. 초기 결과는 검색 인덱스에서 검색되고 표 형식으로 표시되므로 통신에 쉽게 액세스할 수 있고 결과 비교가 간소화됩니다.
    1. 사용자가 주요 통신 세부 정보를 사용할 수 있으며 여러 채널(메일, 대화 내용 기록, 뉴스)의 문서가 단일 보기로 통합됩니다.
    2. 사용자 지정 위험 모델의 점수는 통신별로 표시되며 더 높은 위험을 강조 표시할 수 있습니다.
    3. 통합 위험 분류는 사용자 지정 위험 모델에서 점수를 집계하고 평균 위험 수준에 따라 결과를 정렬하는 데 사용됩니다.
  2. 임계값 슬라이더는 사용자가 위험 임계값을 변경하는 기능을 제공합니다. 임계값을 초과하는 사용자 지정 위험 점수가 강조 표시됩니다.
  3. 날짜 범위 선택기는 분석 기간을 넓히거나 기록 결과를 검색하는 기능을 제공합니다.
  4. 언어 또는 문서 형식과 같은 필터 세트를 사용하여 검색 결과를 구체화할 수 있습니다. 이 옵션은 인덱스에서 구성된 패싯 가능 필드의 기능으로 UI에서 동적으로 생성됩니다.
  5. 검색 창은 인덱스에서 특정 용어 또는 구를 검색하는 기능을 제공합니다.
  6. 의미 체계 검색을 사용할 수 있습니다. 사용자는 표준 검색과 의미 체계 검색 간에 전환할 수 있습니다.
  7. 사용자 인터페이스를 통해 직접 새 통신을 업로드하고 인덱싱할 수 있습니다. 각 문서에 대한 세부 정보 페이지도 제공됩니다.

Screenshot of an example details page.

세부 정보 페이지에서는 통신 콘텐츠뿐 아니라 보강 및 메타데이터에 액세스할 수 있습니다.

  1. 문서 크래킹 프로세스 중에 추출된 콘텐츠가 표시됩니다. PDF와 같은 일부 파일은 세부 정보 페이지에서 직접 볼 수 있습니다.
  2. 사용자 지정 위험 모델의 결과가 요약되어 있습니다.
  3. 문서에 언급된 상위 사용자 및 조직이 이 페이지에 표시됩니다.
  4. 인덱싱 프로세스 중에 캡처된 추가 메타데이터는 세부 정보 페이지의 추가 탭에서 추가하고 표시할 수 있습니다.

영어가 아닌 콘텐츠가 수집된 경우 사용자는 원래 언어 또는 영어로 콘텐츠를 검토할 수 있습니다. 세부 정보 페이지의 대본 탭에는 원본 콘텐츠와 번역된 콘텐츠가 나란히 표시됩니다. 이는 인덱싱 프로세스 중에 두 언어가 모두 유지되어 사용자 인터페이스에서 둘 다 사용할 수 있음을 보여 줍니다.

마지막으로, 사용자가 의미 체계 검색을 수행할 수 있습니다. 다음 예제에서는 의미 체계 검색을 사용하여 “capex가 어떻게 되었나요” 식(“보고 사분기에 자본 지출이 어떻게 개발되었나요?”의 약어)이 검색된 상위 결과를 보여 줍니다.

Screenshot of a sample UI for a user to enable semantic search.

전체 텍스트 모드에서 동등한 검색을 수행하면 검색 쿼리는 문서에 표시되지 않는 “capex”에 대한 정확한 일치 항목을 검색합니다. 그러나 의미 체계 기능을 사용하면 쿼리 엔진은 “capex”가 “자본 지출”과 관련이 있음을 식별할 수 있으므로 이 통신이 가장 관련성이 높은 것으로 식별됩니다. 또한 의미 체계 검색은 의미 체계 강조 표시(12)를 생성하여 가장 관련성이 높은 문장으로 문서를 요약합니다.

모범 사례

이 섹션에서는 규정 준수 위험 분석 솔루션을 개발하기 위한 조직 및 기술 모범 사례를 요약합니다.

필요한 관련자 참여: 위험 분석 솔루션 구현은 다양한 도메인의 주요 관련자가 참여하는 종합적인 연습입니다. 이전에 도입된 프로젝트 관련 역할과 솔루션의 영향을 받는 다른 역할이 포함되어야 합니다.

적절한 채택 및 변경 관리 보장: 위험 분석 사례를 자동화하면 직원의 업무 방식이 크게 변경될 수 있습니다. 솔루션이 가치를 더하지만 워크플로의 변경이 어려울 수 있으며, 이로 인해 채택 기간이 길어지고 저항이 발생할 수 있습니다. 모범 사례에서는 영향을 받는 직원을 일찍 참여시켜야 한다고 제안합니다. 기술 채택 경험의 5가지 주요 단계인 인식, 필요, 지식, 능력 및 강화에 중점을 둔 Prosci ADKAR 채택 모델을 사용하는 것이 좋습니다.

여러 채널을 사용하여 위험 파악: 각 통신 채널(예: 메일, 채팅, 전화 통신)은 잠재적 위험을 탐지하기 위해 격리 상태로 살펴볼 수 있습니다. 그러나 형식적인 통신(예: 메일)과 편안한 통신(예: 채팅)의 서로 다른 채널을 결합하여 더 나은 인사이트를 얻을 수 있습니다. 또한 보완 정보(예: 시장 뉴스, 회사 보고서, SEC 서류)를 통합하면 규정 준수 분석가를 위해 추가 컨텍스트(예: 회사의 특정 이니셔티브 정보)를 제공할 수 있습니다.

간단한 시작 및 반복: Azure Cognitive Search는 다양한 Cognitive Services를 기반으로 포괄적인 기본 제공 AI 보강 세트를 제공합니다. 이러한 많은 기능을 바로 추가하려고 할 수 있습니다. 그러나 제대로 제어되지 않으면 추출할 수 있는 엔터티 또는 핵심 구의 수가 최종 사용자를 혼란스럽게 만들 수 있습니다. 감소된 기술 세트 또는 엔터티부터 시작하여 사용자와 개발자가 가장 큰 가치를 더하는 항목을 이해하는 데 도움이 될 수 있습니다.

책임 있는 혁신: AI 솔루션 개발은 관련된 모두로부터 높은 수준의 책임을 요구합니다. Microsoft는 인공 지능의 책임 있는 사용을 매우 중요하게 생각하며 핵심 디자인 원칙의 프레임워크를 개발했습니다.

  • 공정성
  • 안정성 및 안전
  • 개인 정보 보호 및 보안
  • 포용성
  • 투명성 및 책임

직원 통신 평가는 특별한 주의가 요구되며 윤리적 문제를 제기합니다. 일부 국가/지역에서는 직원의 자동화된 모니터링에 엄격한 법적 제한이 적용됩니다. 이러한 모든 이유를 고려하여 책임 있는 혁신을 프로젝트 계획의 초석으로 만듭니다. Microsoft는 이 목적을 위해 여러 프레임워크와 도구를 제공합니다. 자세한 내용은 이 섹션의 끝에 있는 상자를 참조하세요.

개발 반복 자동화: 데이터 가져오기 마법사를 사용하면 쉽게 시작할 수 있지만, 더 복잡한 솔루션과 생산성 높은 사용 사례의 경우 코드에서 데이터 원본, 인덱서, 인덱스, 기술 세트 등의 자산을 만드는 것이 좋습니다. 자동화는 개발 주기의 속도를 크게 높이고 프로덕션에 대한 일관된 배포를 보장합니다. 자산은 JSON 형식으로 지정됩니다. 포털에서 JSON 정의를 복사하고, 필요에 따라 수정한 다음, Azure Cognitive Search REST API에 대한 호출의 요청 본문에 제공할 수 있습니다.

위험 분석에 적합한 NLP 접근 방식 선택: 비구조적 텍스트의 위험을 식별하는 방법은 기본 키워드 검색 및 엔터티 추출에서 강력한 최신 NLP 아키텍처에 이르기까지 다양합니다. 가장 좋은 선택은 특정 사용 사례에 대한 기존 학습 데이터의 양과 품질에 따라 달라집니다. 학습 데이터가 제한된 경우 언어용 Azure Cognitive Service의 대화 언어 이해 기능을 사용하여 발화 기반 모델을 학습시킬 수 있습니다. 기존 대화를 검토하여 관련 위험 유형을 나타내는 문장을 식별하고 레이블을 지정할 수 있습니다. 경우에 따라 좋은 결과로 모델을 학습시키는 데는 수십 개의 샘플로 충분합니다.

위험 징후가 더 미묘하고 여러 문장에 걸쳐 있는 경우 최첨단 NLP 모델을 학습시키는 것이 더 나은 선택일 수 있습니다. 그러나 이 접근 방식에는 일반적으로 훨씬 더 많은 학습 데이터가 필요합니다. 솔루션이 프로덕션에 있는 경우 가능할 때마다 실제 데이터를 사용하여 잠재적인 잘못된 예측에 맞게 조정하고 시간이 지남에 따라 성능을 개선하기 위해 모델을 지속적으로 다시 학습시키는 것이 좋습니다.

특정 요구 사항에 따라 UI 조정: 풍부한 사용자 인터페이스를 사용하면 Azure Cognitive Search 및 AI 보강의 모든 부가 가치를 사용할 수 있습니다. Azure AI Search UI 템플릿은 초기 웹 애플리케이션을 구현하는 쉽고 빠른 방법을 제공하지만 추가 기능을 통합하도록 조정해야 할 수 있습니다. 또한 처리되는 통신 유형, 사용되는 AI 보강 유형 및 추가 비즈니스 요구 사항을 수용해야 합니다. 프런트 엔드 개발자, 비즈니스 관련자 및 최종 사용자 간의 지속적인 협업과 반복은 관련 통신을 찾고 검토하는 사용자 환경을 최적화하여 솔루션의 가치를 개선하는 데 도움이 됩니다.

번역 서비스에 대한 비용 최적화: 기본적으로 모든 문서는 AI 보강 파이프라인을 통해 흐릅니다. 즉, 실제 번역이 필요하지 않더라도 영어 문서가 번역 서비스에 전달됩니다. 그러나 콘텐츠는 Translation API에서 처리되므로 요금이 적용됩니다. 이 솔루션에서는 조건부 기술과 함께 언어 감지를 사용하여 이러한 경우의 번역을 방지합니다. 원본 문서의 검색된 언어가 영어가 아닌 경우 콘텐츠는 영어가 아닌 콘텐츠의 특정 필드에 복사된 다음, 번역 서비스에 전달됩니다. 영어 문서인 경우 이 필드는 비어 있으며 번역 요금이 발생하지 않습니다. 마지막으로, 모든 콘텐츠(원래 영어 또는 번역됨)가 추가 처리를 위해 공통 필드로 병합됩니다. 캐싱을 사용하도록 설정하여 기존 보강을 다시 사용할 수도 있습니다.

프로덕션 환경의 가용성 및 스케일링 성능 보장: 개념 증명에서 프로덕션 계획으로 이동한 후 검색 솔루션의 안정성과 성능을 보장하려면 가용성과 스케일링 성능을 고려해야 합니다. 검색 서비스의 인스턴스를 복제본이라고 하며 쿼리 작업의 부하를 분산하는 데 사용됩니다. 고가용성 및 쿼리 성능 향상을 위해 복제본을 추가합니다. 파티션을 사용하여 솔루션의 스케일링 성능을 관리합니다. 파티션은 물리적 스토리지를 나타내며 특정 크기 및 I/O 특성을 포함합니다. 용량 및 기타 서비스 관리 고려 사항을 관리하는 방법에 대한 자세한 참고 자료는 설명서를 참조하세요.

이 섹션에서 설명하는 모범 사례에 대한 자세한 내용은 다음 리소스를 참조하세요.

결론

이 가이드에서는 AI를 사용하여 사기 징후를 찾는 솔루션을 설정하기 위한 포괄적인 참고 자료를 제공합니다. 이 접근 방식은 의료 또는 정부와 같은 다른 규제 산업에 적용할 수 있습니다.

다음과 같은 다른 데이터 원본 및 AI 기능을 포함하도록 아키텍처를 확장할 수 있습니다.

  • 시장 데이터(예: 주식 시세) 및 트랜잭션 정보와 같은 구조적 데이터 수집.
  • Azure Form Recognizer, Azure Read API 등의 기능을 사용하여 종이 기반 원본에서 콘텐츠를 추출하도록 디자인된 분류 모델 연결.
  • Azure Language Studio 기능을 통해 관련 토픽을 분류 및 필터링하거나 Azure 감정 분석을 통해 의견 추세를 캡처하여 소셜 네트워킹 정보 수집.
  • Microsoft Graph를 사용하여 대인관계 상호 작용, 사용자가 일하는 회사 또는 사용자가 액세스하는 정보와 같은 Microsoft 365의 정보 조합 및 통합. 이 데이터를 Azure Storage에 저장하면 쉽게 검색할 수 있습니다.

솔루션의 기반이 되는 기술인 Azure Cognitive Search는 지식 마이닝, 카탈로그 검색 및 앱 내 검색을 지원하기 때문에 가장 좋은 선택입니다. 여러 데이터 원본을 배포 및 연결하고 콘텐츠 처리를 위한 기본 제공 및 확장 가능한 AI를 제공하는 것은 간단합니다. 여기에는 딥 러닝이 지원되는 의미 체계 검색과 같은 기능, 사용자 의도를 유추하고 가장 관련성이 높은 결과를 표시하고 순위를 지정할 수 있는 기능이 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계