Analyse des risques de conformité à l’aide de Recherche cognitive Azure

Cet article fournit des instructions techniques pour l’implémentation d’une solution d’analyse des risques de conformité à l’aide de Recherche cognitive Azure. Les lignes directrices sont basées sur des expériences de projet réelles. Étant donné l’étendue complète de la solution et la nécessité de l’adapter à votre cas d’usage spécifique, l’article se concentre sur les aspects essentiels et spécifiques de l’architecture et de l’implémentation. Il fait référence à des tutoriels pas à pas en fonction des besoins.

Apache®, Apache Lucene® et le logo représentant une flamme sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.

Introduction

Chaque jour, les consultants et les traders des institutions financières discutent, analysent et prennent des décisions impliquant des transactions de plusieurs millions de dollars. Les transactions frauduleuses, la falsification, le trading d’initiés et d’autres inconduites par les employés sont des risques importants pour ces institutions, tant en termes de conséquences juridiques que d’image publique.

Les équipes de conformité ont pour mission d’atténuer ces risques. Une partie de leur travail consiste à surveiller les communications entre plusieurs canaux, notamment la messagerie instantanée, les e-mails et les appels téléphoniques professionnels. Souvent, la surveillance fait l’objet d’une double vérification avec les transaction métier. L’objectif est de trouver des signes de non-conformité, souvent cachés et subtils. Cette tâche est gourmande en main-d’œuvre et en attention et implique l’analyse de volumes élevés de données. Bien que les systèmes automatisés puissent aider, le volume de risques négligés peut être assez élevé, ce qui entraîne la nécessité d’examiner les communications d’origine.

Le service Recherche cognitive Azure peut vous aider à automatiser et à améliorer la qualité de l’évaluation des risques. Il dispose de fonctionnalités intégrées d’IA, d’IA extensible et de recherche intelligente. La solution d’analyse des risques de conformité présentée dans cet article vous montre comment identifier les risques, comme l’inconduite des traders, en regroupant et en analysant le contenu de différents canaux de communication. Les risques potentiels qui peuvent être identifiés dans ce contenu non structuré incluent des signaux de manipulation du marché, de délai d’initié, de fraude de fonds communs de placement et d’autres.

L’architecture de la solution utilise Azure Cognitive Services et Recherche cognitive Azure. Le scénario cible les risques de communication dans le secteur financier, mais le modèle de conception convient à d’autres secteurs, tels que le secteur public et le secteur de la santé. Les organisations peuvent adapter l’architecture en développant et en intégrant des modèles d’évaluation des risques qui s’appliquent à leurs scénarios métier. Par exemple, l’application de démonstration Wolters Kluwer fournit aux avocats la possibilité de trouver rapidement des informations pertinentes dans les documents et correspondances de la SEC (Securities and Exchange Commission). Elle identifie les risques liés au financement, y compris les risques de cybersécurité et de propriété intellectuelle.

Le service Recherche cognitive Azure dispose d’une IA intégrée et de compétences personnalisées qui améliorent les performances des processus métier et la productivité des équipes de conformité. Il est particulièrement utile pour les situations suivantes :

• Il est nécessaire d’extraire des insights d’un grand nombre de documents non structurés hétérogènes, tels que des rapports financiers, des transcriptions vocales et des e-mails.
• Les procédures de gestion des risques pour le contenu non structuré ne sont pas entièrement en place.
• Les approches existantes sont fastidieuses et gourmandes en main-d’œuvre et entraînent trop de fausses alarmes ou des risques réels qui sont négligés.
• Il est nécessaire d’intégrer divers canaux de communication et sources de données, y compris des données structurées, pour une analyse des risques plus complète.
• Les données et les connaissances relatives au domaine sont disponibles pour entraîner des modèles Machine Learning afin d’identifier les signaux de risque dans du texte non structuré. Vous pouvez également intégrer des modèles existants.
• Il est nécessaire que l’architecture puisse continuellement ingérer et traiter les données non structurées nouvellement disponibles, telles que les conversations et les actualités, pour améliorer la solution.
• Les analystes de conformité ont besoin d’un outil efficace pour l’identification et l’analyse détaillée des risques. L’outil doit intégrer des opérateurs humains afin que les analystes contrôlent le processus et puissent détecter de possibles prédictions incorrectes afin d’améliorer les modèles.

Recherche cognitive Azure est un service de recherche cloud qui dispose de fonctionnalités IA intégrées qui enrichissent tous les types d’informations pour vous aider à identifier et à explorer le contenu pertinent à l’échelle. Vous pouvez utiliser des compétences cognitives pour la vision et la langue, ou utiliser des modèles Machine Learning personnalisés pour découvrir des informations à partir de tous types de contenu. Recherche cognitive Azure offre également une fonctionnalité de recherche sémantique, qui utilise des techniques de Machine Learning avancées pour classifier l’intention de l’utilisateur et classer en contexte les résultats de recherche les plus pertinents.

Le diagramme suivant montre une vue générale du fonctionnement du service Recherche cognitive Azure, de l’ingestion et de l’indexation des données à la mise à disposition des résultats pour l’utilisateur.

Téléchargez un fichier PowerPoint de cette architecture.

Cet article fournit des détails sur la solution pour le cas d’usage d’analyse des risques et d’autres scénarios de services financiers comme l’exemple Wolters Kluwer mentionné précédemment. Il fournit des étapes d’exécution techniques avec une documentation référencée et une architecture de référence. Il inclut les meilleures pratiques des points de vue organisationnel et technique. Le modèle de conception part du principe que vous apportez vos propres données et développez vos propres modèles d’analyse des risques, adaptés à votre contexte métier et à vos besoins.

Vue d’ensemble de la solution

Le diagramme suivant donne une vue d’ensemble de la solution d’analyse des risques.

Téléchargez un fichier PowerPoint de cette architecture.

Pour identifier les communications courant un réel risque, le contenu des canaux de communication hétérogènes est extrait et enrichi par différents modèles Machine Learning de Cognitive Services. Ensuite, des modèles personnalisés propres à un domaine sont appliqués pour identifier les signes de manipulation du marché et d’autres risques qui apparaissent dans les communications et les interactions entre les personnes. Toutes les données sont agrégées dans une solution Recherche cognitive Azure consolidée. La solution se compose d’une application conviviale avec des fonctionnalités d’identification et d’analyse des risques. Les données d’application sont stockées dans un index de recherche et dans une base de connaissances si vous avez besoin d’un stockage à long terme.

L’illustration suivante fournit une vue d’ensemble conceptuelle de l’architecture de la solution :

Téléchargez un fichier PowerPoint de cette architecture.

Bien que chaque canal de communication (par exemple, e-mail, conversations et téléphone) puisse être utilisé de manière isolée pour détecter les risques potentiels, de meilleures informations sont obtenues en combinant les canaux et en enrichissant le contenu avec des informations complémentaires telles que les actualités du marché.

La solution d’analyse des risques utilise plusieurs interfaces afin d’intégrer des systèmes de communication d’entreprise pour l’ingestion des données :

• Le Stockage Blob est utilisé comme source générale pour les données au format document, telles que le contenu des e-mails, y compris les pièces jointes, les transcriptions des appels téléphoniques ou des conversations et des documents d’actualités.
• Les services de communication Office 365 tels que Microsoft Exchange Online et Microsoft Teams peuvent être intégrés à l’aide de Connexion aux données Microsoft Graph pour l’ingestion en bloc de d’e-mails, de conversations et d’autres contenus. Une interface Recherche cognitive Azure pour SharePoint dans Microsoft 365 est également disponible.
• Les communications vocales telles que les appels téléphoniques sont transcrites à l’aide du service Reconnaissance vocale de Cognitive Services. Les transcriptions et métadonnées résultantes sont ensuite ingérées par Recherche cognitive Azure via le Stockage Blob.

Ces exemples couvrent les canaux de communication d’entreprise fréquemment utilisés. Toutefois, l’intégration de canaux supplémentaires est également possible et peut utiliser des modèles d’ingestion similaires.

Après la consolidation, les données brutes sont enrichies par les compétences d’IA pour détecter la structure et créer du contenu textuel à partir de types de contenu qui ne pouvaient précédemment pas faire l’objet de recherches. Par exemple :

• Les rapports financiers dans des fichiers PowerPoint ou PDF contiennent souvent des images incorporées plutôt que du texte lisible par un ordinateur, afin d’empêcher les modifications. Pour traiter ce type de contenu, toutes les images sont analysées par la reconnaissance optique de caractères (OCR) à l’aide de la compétence cognitive OCR.
• Le contenu de différentes langues est traduit en anglais ou une autre langue à l’aide de la compétence cognitive Traduction de texte.
• Des informations importantes telles que les noms des personnes et des organisations sont automatiquement extraites et peuvent être utilisées pour des requêtes de recherche puissantes à l’aide de la compétence cognitive Reconnaissance d’entité. Par exemple, une recherche peut trouver toutes les communications entre James Doe et Mary Silva qui discutent d’une société particulière pendant une période donnée.
• Les modèles personnalisés sont utilisés pour identifier les preuves de risque, telles que le délit d’initié, dans les communications. Ces modèles propres au domaine peuvent être basés sur des mots clés, des énoncés ou des paragraphes entiers. Ils utilisent des technologies avancées de traitement du langage naturel (NLP). Les modèles personnalisés sont entraînés à l’aide de données propres au domaine pour le cas d’usage actuel.

Après avoir appliqué les enrichissements par IA et les compétences personnalisées de Recherche cognitive Azure, le contenu est consolidé dans un index de recherche pour prendre en charge des scénarios enrichis d’exploration de connaissances et de recherche. Les analystes de conformité et d’autres utilisateurs utilisent l’application front-end pour identifier les communications à risque potentielles et effectuer des recherches approfondies pour une analyse plus poussée. La gestion des risques est un processus dynamique. Les modèles sont constamment améliorés en production et les modèles en lien avec de nouveaux types de risques sont ajoutés. Par conséquent, la solution doit être modulaire. Les nouveaux types de risques sont automatiquement signalés dans l’interface utilisateur à mesure que l’ensemble de modèles est étendu.

L’application front-end utilise des requêtes de recherche intelligente et sémantique pour examiner le contenu. Le contenu peut également être déplacé dans une base de connaissances pour la rétention de conformité ou l’intégration à d’autres systèmes.

Les composants de la solution sont décrits plus en détail dans les sections suivantes.

L’implémentation d’une solution d’analyse des risques est un exercice multidisciplinaire qui nécessite l’implication des principales parties prenantes issues de divers domaines. Sur la base de nos expériences, nous vous recommandons d’inclure les rôles suivants pour garantir un développement réussi et une adoption organisationnelle de la solution.

Ingestion de données

Cette section explique comment consolider le contenu hétérogène dans une seule source de données, puis configurer une collection initiale de ressources de recherche dérivées de cette source.

Le développement et l’implémentation d’une solution Recherche cognitive Azure sont souvent un processus incrémentiel. L’ajout de sources de données, de transformations et d’augmentations est effectué dans des itérations successives, en plus des configurations de base.

La première étape d’une solution Recherche cognitive Azure consiste à créer une instance de service dans le Portail Azure. Outre le service de recherche lui-même, vous avez besoin de plusieurs ressources de recherche, notamment un index de recherche, un indexeur, une source de données et un ensemble de compétences. Vous pouvez créer une configuration de référence avec peu d’efforts à l’aide de l’Assistant Importation de données de Recherche cognitive Azure, qui se trouve dans le Portail Azure. Cet Assistant, illustré ici, guide l’utilisateur à travers les étapes de base de la création et du chargement d’un index de recherche simple qui utilise des données à partir d’une source de données externe.

La création de l’index de recherche par l’Assistant Importation de données comporte quatre étapes :

1. Connexion aux données : la connexion au Stockage Blob existant, par exemple, peut être effectuée sans effort en quelques clics. Une chaîne de connexion est utilisée pour l’authentification. D’autres sources de données prises en charge en mode natif incluent divers services Azure tels que Azure SQL Database, Azure Cosmos DB et des services tels que SharePoint Online. Dans cette solution, le Stockage Blob est utilisé pour consolider les types de contenu hétérogènes.
2. Ajout de compétences cognitives : dans cette étape facultative, les compétences d’IA intégrées sont ajoutées au processus d’indexation. Elles sont appliquées pour enrichir le contenu lu à partir de la source de données. Par exemple, cette étape peut extraire les noms et les localisations des personnes et des organisations.
3. Personnalisation de l’index cible : dans cette étape, le développeur configure les entités de champ pour l’index. Un index par défaut est fourni, mais les champs peuvent être ajoutés, supprimés ou renommés. Voici des exemples de champs : titre du document, description, URL, auteur, emplacement, société et code mnémonique, ainsi que les types d’opérations possibles sur chacun d’eux.
4. Création de l’indexeur : la dernière étape configure un indexeur, le composant qui s’exécute régulièrement pour mettre à jour le contenu de l’index de recherche. Un paramètre clé est la fréquence à laquelle l’indexeur doit s’exécuter.

Lorsque les configurations sont confirmées, une source de données, un ensemble de compétences, un indexeur et un index sont créés. Pour chacun de ces composants, une définition JSON est créée. Les définitions JSON fournissent une personnalisation améliorée et peuvent être utilisées pour créer les services par programmation via une API REST. L’avantage est la création cohérente et programmatique de ressources dans toutes les itérations de développement suivantes. Pour cette raison, nous utilisons des définitions JSON pour illustrer la configuration de toutes les ressources. La section Création automatique des ressources de recherche fournit des explications détaillées sur l’utilisation de ces définitions pour créer par programme toutes les ressources.

Dans la configuration, le Stockage Blob est sélectionné comme source de données par défaut. Même si les communications peuvent provenir de plusieurs canaux ou sources, une approche générique pour ce modèle de solution s’appuie sur toutes les communications existantes dans le Stockage Blob et contenant du texte et/ou des images. L’étape suivante développe la configuration d’une définition JSON de source de données pour le Stockage Blob.

Certains modèles sont référencés dans cette section pour illustrer comment ingérer des communications Office 365 dans le Stockage Blob et comment transcrire des appels audio à l’aide du service Reconnaissance vocale.

Stockage Blob

La définition JSON suivante montre la structure et les informations nécessaires pour configurer le Stockage Blob comme source de données pour Recherche cognitive Azure :

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

Les deux champs suivants sont obligatoires :

• Nom : nom affecté à la source de données.
• Type : définit la source de données sur le Stockage Blob.
• Informations d’identification : chaîne de connexion pour le Stockage Blob.
• Conteneur : nom du conteneur dans lequel les objets blob sont stockés. Un répertoire dans le conteneur peut être spécifié afin que plusieurs sources de données puissent être créées dans le même conteneur.

Par défaut, la source de données Stockage Blob prend en charge un large éventail de formats de document. Par exemple, les transcriptions audio sont souvent stockées dans des fichiers JSON, les e-mails sont généralement des fichiers MSG ou EML, des actualités ou des documents de communication supplémentaires sont souvent au format PDF, aux formats Word tels que DOC/DOCX/DOCM ou aux formats PowerPoint tels que PPTX/PPTX/PPTM ou les pages web HTML.

Pour configurer plusieurs sources de données pour les communications dans le même Stockage Blob, vous pouvez utiliser l’une des techniques suivantes :

• Donnez à chaque source de données son propre conteneur.
• Utilisez le même conteneur pour toutes les sources de données, mais donnez à chaque source de données son propre répertoire dans ce conteneur.

Connexion aux données Microsoft Graph

Pour les clients Office 365, Connexion aux données Microsoft Graph peut être utilisé pour extraire les données sélectionnées à partir de Microsoft Graph dans Stockage Azure, en amont de la solution Recherche cognitive Azure. Les données stockées dans Microsoft Graph incluent des données telles que des e-mails, des réunions, des conversations, des documents SharePoint, des personnes et des tâches.

Téléchargez un fichier PowerPoint de cette architecture.

Le diagramme montre le flux de données de Microsoft Graph. Le processus s’appuie sur des fonctionnalités Azure Data Factory pour extraire des données de Microsoft Graph. Il existe un contrôle de sécurité granulaire, incluant le consentement et un modèle de gouvernance. Le pipeline Data Factory est configuré avec les types de données à extraire, tels que les e-mails et les conversations d’équipe, ainsi qu’une étendue telle qu’un groupe d’utilisateurs et une plage de dates. La recherche est exécutée selon une planification définie à intervalles configurables et configurée pour supprimer les données extraites dans Stockage Azure. À partir de là, les données sont ingérées dans Recherche cognitive Azure par un indexeur.

Architecture de référence Reconnaissance vocale

Les conversations téléphoniques sont un outil de travail essentiel de toute organisation proposant des services financiers. Elles peuvent être incluses dans une solution d’analyse des risques s’il existe un accès aux fichiers audio respectifs. Cette section traite de cette situation.

Le craquage de document dans Recherche cognitive Azure est un ensemble d’étapes de traitement exécutées par l’indexeur pour extraire du texte et des images de la source de données. Pour les fichiers audio, nous avons besoin d’un moyen d’extraire des transcriptions de ces communications audio afin qu’elles soient disponibles pour le traitement textuel.

Le diagramme suivant montre un pipeline d’ingestion audio et de reconnaissance vocale. Le pipeline traite les lots de fichiers audio et stocke les fichiers de transcription dans le Stockage Blob, en amont de la solution Recherche cognitive Azure.

Téléchargez un fichier PowerPoint de cette architecture.

Dans cette architecture de référence, les fichiers audio sont chargés dans le Stockage Blob via une application cliente. Pendant ce processus, l’application s’authentifie à l’aide de Microsoft Entra ID et appelle l’API REST pour obtenir un jeton pour le stockage Blob. L’accès sécurisé à l’API REST est fourni par Gestion des API Azure, et un coffre Azure Key Vault fournit un stockage sécurisé des secrets nécessaires pour générer les jetons, ainsi que les informations d’identification du compte.

Une fois les fichiers chargés, un déclencheur Azure Event Grid est émis pour appeler une fonction Azure. La fonction traite ensuite le fichier audio à l’aide de l’API Reconnaissance vocale Cognitive Services. Le document JSON transcrit est ensuite stocké dans un conteneur d’objets blob distinct, qui peut être ingéré en tant que source de données par Recherche cognitive Azure.

Solution de recherche

Comme décrit, plusieurs sources de données telles que les e-mails, les transcriptions et les actualités sont créées, puis stockées dans le Stockage Blob. Chaque source de données est ensuite transformée et enrichie de sa propre manière. Toutes les sorties obtenues sont mappées au même index, en regroupant les données de tous les types de documents sources.

Le diagramme suivant illustre cette approche. Un indexeur personnalisé est configuré pour chacune des sources de données disponibles, et tous les résultats alimentent un index de recherche unique.

Les sections suivantes explorent les moteurs d’indexation et les index pouvant faire l’objet d’une recherche. Elles montrent comment configurer un indexeur et comment indexer des définitions JSON pour implémenter une solution pouvant faire l’objet d’une recherche.

Indexeurs

Un indexeur orchestre l’extraction et l’enrichissement du contenu du document. Une définition d’indexeur inclut des détails sur la source de données qui doit être ingérée, comment mapper les champs et comment transformer et enrichir les données.

Étant donné que le mappage, la transformation et l’enrichissement varient selon le type de données, il doit y avoir un indexeur pour chaque source de données. Par exemple, l’indexation des e-mails peut nécessiter des compétences de reconnaissance optique de caractères (OCR) pour traiter des images et des pièces jointes, mais les transcriptions n’ont besoin que de compétences linguistiques.

Voici les étapes du processus d’indexation :

• Craquage de document : Recherche cognitive Azure ouvre et extrait le contenu pertinent des documents. Le contenu indexable extrait est une fonction des formats de source de données et de fichier. Par exemple, pour un fichier tel qu’un fichier PDF ou Microsoft 365 dans le Stockage Blob, l’indexeur ouvre le fichier et extrait du texte, des images et des métadonnées.
• Mappage de champs : les noms des champs extraits de la source sont mappés dans des champs de destination dans un index de recherche.
• Exécution de l’ensemble de compétences : le traitement IA intégré ou personnalisé est effectué dans cette étape, comme décrit dans une section ultérieure.
• Mappage de champs de sortie : les noms des champs transformés ou enrichis sont mappés aux champs de destination dans un index.

L’extrait de code suivant montre un segment de la définition JSON de l’indexeur d’e-mails. Cette définition utilise les informations détaillées dans les étapes et fournit un ensemble détaillé d’instructions au moteur d’indexation.

{
  "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"
    },

Dans cet exemple, l’indexeur est identifié par le nom unique email-indexer. Cet indexeur fait référence à une source de données nommée email-ds, et les enrichissements par IA sont définis par l’ensemble de compétences nommé email-skillset. Les sorties du processus d’indexation sont stockées dans l’index nommé combined-index. Des détails supplémentaires incluent une planification définie sur tous les jours, un nombre maximal de 50 éléments ayant échoué et une configuration permettant de générer des images normalisées et d’extraire du contenu et des métadonnées.

Dans la section Mappage de champs, le champ metadata_storage_path est encodé à l’aide d’un codeur base64encoder, pour servir de clé de document unique. Dans la configuration du mappage de champs de sortie (uniquement partiellement affichée), les sorties du processus d’enrichissement sont mappées au schéma d’index.

Si un nouvel indexeur est créé pour une nouvelle source de données (par exemple, des transcriptions), la majeure partie de la définition JSON est configurée pour s’aligner avec la sélection de la source de données et de l’ensemble de compétences. Toutefois, l’index cible doit être combined-index (à condition que tous les mappages de champs soient compatibles). Il s’agit de la technique qui permet à l’index de consolider les résultats de plusieurs sources de données.

Index et autres structures

Une fois le processus d’indexation terminé, les documents extraits et augmentés sont conservés dans un index pouvant faire l’objet d’une recherche et, éventuellement, dans les bases de connaissances.

• Index pouvant faire l’objet d’une recherche : un index pouvant faire l’objet d’une recherche correspond à la sortie requise qui est toujours créée dans le cadre d’un processus d’indexation et qui est parfois également appelée catalogue de recherche. Pour créer un index, une définition d’index est requise. Elle contient des configurations (par exemple, type, possibilité d’effectuer une recherche, filtrable, triable, à choix multiples et récupérable) pour tous les champs. Ces noms de champs d’index doivent être alignés avec les mappages de champs d’indexeur et de sortie.

  Plusieurs indexeurs peuvent être affectés au même index, afin que l’index consolide les communications à partir de différents jeux de données, tels que les e-mails ou les transcriptions. Un index peut ensuite être interrogé à l’aide de la recherche en texte intégral ou de la recherche sémantique.

  Comme pour les indexeurs, les index peuvent être configurés à l’aide d’une définition JSON d’index. L’extrait de code suivant correspond à un segment de la définition JSON combined-index :

  {
  "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": []
    },
  

  Dans cet exemple, l’index est identifié par le nom unique combined-index. La définition d’index est indépendante des indexeurs, sources de données ou ensembles de compétences. Les champs définissent le schéma de l’index et, au moment de la configuration, un utilisateur peut configurer le nom et le type de chaque champ, ainsi qu’un ensemble de propriétés, telles que à choix multiples, filtrable.

  Dans cet extrait de code, deux champs sont inclus. Metadata_storage_path est une chaîne récupérable utilisée comme clé de document. En revanche, le champ people est une collection de chaînes pouvant être accessibles, filtrables, récupérables et pouvant faire l’objet d’une recherche, et l’interrogation de texte intégral est traitée à l’aide d’un analyseur standard.lucene.

• Base de connaissances : une base de connaissances peut être une sortie facultative, à utiliser pour l’analyse indépendante et le traitement en aval dans des scénarios de non-recherche comme l’exploration de connaissances. L’implémentation d’une base de connaissances est définie dans un ensemble de compétences, où le document enrichi ou les champs spécifiques peuvent être configurés de façon à être projetés sous forme de tables ou de fichiers.

  L’illustration suivante montre une implémentation d’une base de connaissances :

  

Téléchargez un fichier PowerPoint de cette architecture.

Avec une base de connaissances Recherche cognitive Azure, les données peuvent être conservées à l’aide des options suivantes (appelées projections) :

• Les projections de fichiers permettent l’extraction de contenu (par exemple, des images incorporées) en tant que fichiers. Voici un exemple de diagrammes ou de graphiques provenant de rapports financiers exportés dans des formats de fichiers image.
• Les projections de table prennent en charge les structures de création de rapports tabulaires (par exemple, pour les cas d’usage à visée analytique). Elles peuvent être utilisés pour stocker des informations agrégées telles que des scores de risque pour chaque document.
• Les projections d’objets extraient du contenu en tant qu’objets JSON dans le Stockage Blob. Elles peuvent être utilisés pour la solution d’analyse des risques si les données doivent être conservées de manière précise pour des raisons de conformité. Les scores de risque peuvent être archivés à l’aide de cette approche.

Étant donné que la structure des données de recherche est optimisée pour les requêtes, elle n’est généralement pas optimisée à d’autres fins, comme l’exportation vers une base de connaissances. Vous pouvez utiliser la compétence Modélisateur pour restructurer les données en fonction de vos besoins de rétention avant d’appliquer les projections.

Dans une base de connaissances, le contenu persistant est stocké dans Stockage Azure, dans le stockage table ou dans le stockage blob.

Il existe plusieurs options d’utilisation des données d’une base de connaissances. Azure Machine Learning peut accéder au contenu permettant de créer des modèles Machine Learning. Power BI peut analyser les données et créer des visuels.

Les organisations financières disposent de stratégies et de systèmes existants pour la rétention de conformité à long terme. Par conséquent, Stockage Azure peut ne pas être la solution cible idéale pour ce cas d’usage. Une fois les données enregistrées dans la base de connaissances, Data Factory peut les exporter vers d’autres systèmes tels que des bases de données.

Moteur de requête

Une fois qu’un index est créé, vous pouvez utiliser Recherche cognitive Azure pour l’interroger à l’aide de la recherche en texte intégral et de la recherche sémantique.

• La recherche en texte intégral repose sur le moteur de requête Apache Lucene et accepte les termes ou expressions passés dans un paramètre de recherche dans tous les champs pouvant faire l’objet d’une recherche de l’index. Lorsque des termes correspondants sont trouvés, le moteur de requête classe les documents dans l’ordre de pertinence et retourne les meilleurs résultats. Le classement des documents peut être personnalisé via des profils de scoring, et les résultats peuvent être triés à l’aide de champs triables d’index.
• La recherche sémantique fournit un ensemble de fonctionnalités puissantes qui améliorent la qualité des résultats de la recherche à l’aide de la pertinence sémantique et de la compréhension du langage. Lorsqu’elle est activée, la recherche sémantique étend la fonctionnalité de recherche de la manière suivante :
  • Le reclassement sémantique utilise le contexte ou la signification sémantique d’une requête pour calculer un nouveau score de pertinence par rapport aux résultats existants.
  • Les mises en surbrillance sémantiques mettent en surbrillance les phrases et les expressions d’un document qui résume le mieux le contenu.

La section Interface utilisateur inclut un exemple de la puissance de la recherche sémantique. La recherche sémantique est disponible en préversion publique. Vous trouverez plus d’informations sur ses fonctionnalités dans la documentation.

Création automatique de ressources de recherche

Le développement d’une solution de recherche est un processus itératif. Une fois que vous avez déployé l’infrastructure Recherche cognitive Azure et la version initiale des ressources de recherche telles que la source de données, l’index, l’indexeur et l’ensemble de compétences, vous améliorez en permanence votre solution (par exemple, en ajoutant et en configurant des compétences IA).

Pour garantir la cohérence et les itérations rapides, nous vous recommandons d’automatiser le processus de création des ressources Recherche cognitive Azure.

Pour notre solution, nous utilisons l’API REST de Recherche cognitive Azure pour déployer dix ressources de manière automatisée, comme affiché dans cette illustration :

Étant donné que notre solution nécessite différents enrichissements de traitement et par IA pour les e-mails, les transcriptions et les documents d’actualités, nous créons des sources de données, des indexeurs et des ensembles de compétences distincts. Toutefois, nous avons décidé d’utiliser un index unique pour tous les canaux afin de simplifier l’utilisation de la solution d’analyse des risques.

Chacun des dix éléments a un fichier de définition JSON associé pour spécifier sa configuration. Consultez les exemples de zones de code de ce guide pour obtenir des explications sur les paramètres.

Les spécifications JSON sont envoyées à Recherche cognitive Azure via les demandes d’API effectuées par le script build-search-config.py dans l’ordre indiqué. L’exemple suivant montre comment créer l’ensemble de compétences de messagerie spécifié dans 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 est le nom de la ressource Recherche cognitive Azure.
• cog_search_admin_key est la clé d’administration. L’utilisation d’une clé de requête n’est pas suffisante pour les opérations de gestion.

Une fois que toutes les demandes de configuration ont été effectuées et que l’index est chargé, une requête REST détermine si la solution de recherche répond correctement. Notez qu’il existe un délai avant que toutes les ressources soient générées et que les indexeurs aient terminé leurs exécutions initiales. Vous devrez peut-être attendre quelques minutes avant d’effectuer une première interrogation.

Pour plus d’informations sur l’utilisation de l’API REST Recherche cognitive Azure pour créer par programme la configuration de l’indexation du contenu du Stockage Blob, consultez : Tutoriel : Utiliser REST et l’IA pour générer du contenu pouvant faire l’objet d’une recherche à partir d’objets blob Azure.

enrichissement de l’IA

Dans les sections précédentes, nous avons établi les bases de la solution d’analyse des risques. Il est maintenant temps de se concentrer sur le traitement des informations du contenu brut en insights métier tangibles.

Pour que le contenu puisse faire l’objet d’une recherche, le contenu de communication est transmis via un pipeline d’enrichissements par IA qui utilisent des compétences intégrées et des modèles personnalisés pour la détection des risques :

Tout d’abord, nous examinons comment utiliser des compétences intégrées en fonction des exemples de compétences 1 à 4 que nous avons utilisés pour la solution d’analyse des risques. Ensuite, nous voyons comment ajouter une compétence personnalisée pour intégrer des modèles de risque (étape 5). Enfin, nous voyons comment passer en revue et déboguer le pipeline des compétences.

Les sections suivantes fournissent une introduction conceptuelle. Pour une expérience pratique, consultez le guide pas à pas sur Microsoft Learn.

Compétences d’enrichissement par IA intégrées

Le pipeline d’enrichissements par IA appliqués est appelé ensemble de compétences Recherche cognitive Azure. Les compétences intégrées suivantes sont utilisées dans la solution d’analyse des risques :

• Reconnaissance optique des caractères : les rapports financiers peuvent inclure une quantité importante de contenu incorporé dans des images plutôt que du texte afin d’empêcher la modification du contenu. La présentation suivante montre un exemple issu d’un rapport trimestriel Microsoft :

  

  Toutes les diapositives du diaporama contiennent uniquement du contenu graphique. Pour utiliser les informations, la compétence cognitive Reconnaissance optique de caractères (OCR) est utilisée pour les e-mails (ceci est particulièrement pertinent pour les pièces jointes) et les documents d’actualités sur le marché. Cela garantit que les requêtes de recherche telles que « dépenses en capital » dans l’exemple précédent recherchent le texte dans la diapositive, même si le contenu d’origine n’est pas lisible par ordinateur. La pertinence de la recherche est améliorée en effectuant une recherche sémantique dans les cas où les utilisateurs utilisent des termes différents pour « dépenses en capital » qui ne sont pas contenus dans le texte.

• Détection de langue : dans une organisation mondiale, la prise en charge de la traduction automatique est une exigence courante. En supposant que l’équipe d’analystes de conformité préfère lire et communiquer de manière cohérente en anglais, par exemple, la solution doit être en mesure de traduire le contenu avec précision. La compétence cognitive de détection de langue est utilisée pour identifier la langue du document d’origine. Ces informations sont utilisées pour identifier si une traduction vers la langue cible souhaitée est requise et s’affichent également dans l’interface utilisateur pour indiquer la langue d’origine à l’utilisateur.

• Extraire des personnes et des organisations : la compétence cognitive Reconnaissance d’entité peut identifier des personnes, des emplacements, des organisations et d’autres entités dans du texte non structuré. Ces informations peuvent être utilisées pour améliorer la recherche ou la navigation (par exemple, le filtrage et facettage) sur un grand corps de contenu hétérogène. Pour la solution d’analyse des risques, l’extraction de personnes (par exemple, les noms commerciaux) et d’organisations (par exemple, les noms de société) a été choisie.

  L’exemple suivant de la définition JSON de l’ensemble de compétences pour les e-mails fournit des détails sur la configuration sélectionnée :

  "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"
        }
      ]
    },
  

  Tout d’abord, nous spécifions l’extraction de personnes et d’organisations à partir du contenu. D’autres catégories existent (par exemple, emplacements) et peuvent être extraites si nécessaire. Toutefois, nous avons intentionnellement limité l’extraction à ces deux entités pour éviter de proposer trop d’informations aux utilisateurs au début.

  Étant donné qu’aucune solution IA ne fournit une précision de 100 %, il existe toujours un risque de faux positifs (par exemple, des noms d’organisation qui ne sont pas vraiment des organisations) et les faux négatifs (par exemple, les organisations réelles sont ignorées). Recherche cognitive Azure fournit des contrôles pour équilibrer le rapport signal-bruit dans l’extraction d’entités. Dans notre cas, nous définissons la précision minimale pour la détection sur 0,85 afin d’améliorer la pertinence de la reconnaissance et de réduire le bruit.

  À l’étape suivante, nous spécifions les entrées et sorties de l’ensemble de compétences dans le document enrichi. Notre chemin d’accès d’entrée pointe vers merged_content, qui inclut les e-mails et les pièces jointes. Le contenu des pièces jointes inclut du texte extrait à l’aide de la reconnaissance optique de caractères.

  Enfin, nous définissons les noms de sortie personnes et organisations pour les entités spécifiées. Plus tard, ceux-ci seront mappés à l’index de recherche dans le cadre de la définition de l’indexeur.

  Les définitions des autres compétences suivent un modèle similaire, complété par des paramètres spécifiques aux compétences.

• Traduction : la traduction en anglais de documents contenant des langues étrangères est effectuée à l’étape suivante. La compétence cognitive de traduction de texte est utilisée pour la conversion. Notez que les frais de traduction sont évalués chaque fois que le texte est envoyé à l’API Traduction de texte Translator Text, même si les langues source et cible sont identiques. Pour éviter les frais de service dans ces circonstances, des compétences cognitives conditionnelles supplémentaires sont utilisées pour contourner la traduction dans ces cas de figure.

Enrichissements par IA personnalisés pour la détection des risques

Maintenant que vous avez implémenté les compétences intégrées souhaitées à partir de Recherche cognitive Azure, examinons comment ajouter des modèles personnalisés pour l’analyse des risques.

L’identification de l’inconduite prévue ou réelle dans le contenu de communication dépend toujours du contexte et nécessite une connaissance approfondie du domaine. Un objectif clé de la solution d’analyse des risques consiste à fournir un moyen d’intégration flexible et à appliquer des modèles de risque personnalisés dans le pipeline d’enrichissement pour découvrir de véritables risques pour des scénarios métier spécifiques.

Selon le cas d’usage, l’exemple de conversation suivant peut indiquer une inconduite potentielle :

Les options suivantes peuvent analyser le contenu de communication non structuré pour identifier les risques :

• Approche basée sur les mots clés : cette technique utilise une liste de mots clés pertinents (par exemple, hors connexion, insights spéciaux) pour identifier les risques potentiels. Cette approche est facile à implémenter, mais peut négliger des risques si les formulations du contenu ne correspondent pas aux mots clés.
• Approches basées sur la reconnaissance d’entités : un modèle Machine Learning est formé sur des énoncés courts (par exemple, des phrases) pour identifier les risques à l’aide d’un modèle de langage. Les connaissances de l’expert sont utilisées pour créer un jeu d’apprentissage d’exemples représentatifs avec la classification des risques correspondante (par exemple, manipulation du marché, délit d’initié). Un avantage clé de cette technique est que les risques ont une bonne probabilité d’être identifiés si les énoncés ont une signification sémantique similaire mais différentes formulations des exemples dans le jeu d’apprentissage. Le service Azure Conversational Language Understanding peut être utilisé à ces fins.
• Approches avancées basées sur le traitement du langage naturel (NLP) : les récentes avancées en matière de réseaux neuronaux permettent d’analyser des segments plus longs de texte non structuré, notamment la classification et d’autres tâches NLP. Cette approche peut identifier les signaux plus subtils et qui couvrent plusieurs phrases ou paragraphes. L’inconvénient de cette approche est que beaucoup plus de données d’entraînement sont généralement nécessaires par rapport à d’autres techniques. Azure fournit plusieurs options pour l’apprentissage des modèles de traitement du langage naturel, notamment la classification de texte personnalisée et le Machine Learning automatisé.

Tout modèle fourni en tant que service web REST peut être intégré en tant que compétence personnalisée dans la solution d’analyse des risques Recherche cognitive Azure. Dans notre exemple, nous intégrons un ensemble de modèles conversationnels Language Understanding avec une fonction Azure qui agit comme interface entre Recherche cognitive Azure et les modèles. Le diagramme suivant illustre cette technique :

Téléchargez un fichier PowerPoint de cette architecture.

Les e-mails et les transcriptions sont analysés pour y repérer les risques après le traitement des compétences intégrées. La compétence personnalisée fournit le type de document et son contenu à l’application Azure Functions à des fins de prétraitement. L’application est basée sur l’exemple publié et effectue les tâches suivantes :

1. Détermine les modèles à utiliser : les organisations peuvent utiliser des modèles distincts pour identifier plusieurs types de risques (par exemple, manipulation du marché, délit d’initié, fraude de fonds mutuels). L’application Functions active les modèles disponibles en fonction des préférences configurées.
2. Prétraitement du contenu : cette tâche inclut la suppression du contenu de pièce jointe et le fractionnement du texte en phrases pour correspondre à la structure des données utilisées pour entraîner les modèles de risque.
3. Envoie le contenu tokenisé aux modèles de risque configurés : les modèles de risque attribuent des scores de risque à chaque phrase.
4. Agrège et note les résultats : cette opération est effectuée avant de les retourner à l’ensemble de compétences. Le score de risque du document correspond au risque le plus élevé de toutes ses phrases. La phrase identifiant un risque principal est également retournée pour affichage dans l’interface utilisateur. En outre, les risques de document sont classés selon le score (faible, moyen ou élevé).
5. Écrit des informations dans l’index Recherche cognitive Azure : les informations sont utilisées dans l’interface utilisateur de l’analyste de conformité et dans la base de connaissances. elles incluent tout le contenu des communications, les enrichissements intégrés et les résultats des modèles de risque personnalisés.

L’exemple JSON suivant illustre la définition d’interface entre Recherche cognitive Azure et l’application Functions (qui appelle les modèles de risque) comme compétence personnalisée :

   {
      "@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"
        }
      ],
    },

L’URI spécifie l’adresse web de l’application Functions qui obtient les entrées suivantes de Recherche cognitive Azure :

• text contient le contenu en langue anglaise.
• =doc_type est utilisé pour faire la distinction entre les transcriptions, les e-mails et les actualités du marché qui nécessitent différentes étapes de prétraitement.

Une fois que l’application Functions reçoit les scores de risque de la fonctionnalité de compréhension du langage courant d’Azure Cognitive Service for Language, elle retourne les résultats consolidés à Recherche cognitive Azure.

Les organisations de services financiers ont besoin d’une approche modulaire pour combiner de manière flexible les modèles de risque existants et nouveaux. Par conséquent, aucun codage irréversible de modèles spécifiques n’est effectué. Au lieu de cela, risk_models est un type de données complexe qui retourne des détails pour chaque type de risque (par exemple, délai d’initié) y compris le score de risque et la phrase identifiée avec le score de risque le plus élevé. La conformité et la traçabilité sont des préoccupations clés pour les organisations de services financiers. Toutefois, les modèles de risque sont constamment améliorés (par exemple, en utilisant de nouvelles données d’apprentissage), de sorte que les prédictions d’un document peuvent changer au fil du temps. Pour garantir la traçabilité, la version spécifique du modèle de risque est également retournée avec chaque prédiction.

L’architecture peut être réutilisée pour intégrer des modèles de traitement du langage naturel plus avancés (par exemple, pour permettre l’identification des signaux de risque plus subtils qui peuvent s’étendre sur plusieurs énoncés). L’ajustement principal consiste à faire correspondre l’étape de prétraitement dans l’application Functions au prétraitement qui a été effectué pour l’apprentissage du modèle de traitement du langage naturel.

Débogage des pipelines d’enrichissement par IA

La compréhension du flux d’informations et des enrichissements par IA peut être difficile pour les ensembles de compétences volumineux. Recherche cognitive Azure fournit des fonctionnalités utiles pour le débogage et la visualisation du pipeline d’enrichissement, notamment les entrées et les sorties des compétences.

L’organigramme a été extrait de l’onglet Sessions de débogage de la ressource Recherche cognitive Azure dans le Portail Azure. Il résume le flux d’enrichissements, car le contenu est traité successivement par les compétences intégrées et les modèles de risque personnalisés dans un ensemble de compétences.

Le flux de traitement dans le graphique de compétences est généré automatiquement par Recherche cognitive Azure en fonction des configurations d’entrée et de sortie des compétences. Le graphique montre également le degré de parallélisme dans le traitement.

Une compétence conditionnelle est utilisée pour identifier le type de document (e-mail, transcription ou actualités), car différents types sont traités différemment dans les étapes ultérieures. Les compétences conditionnelles sont utilisées pour éviter les frais de traduction dans les cas où les langues d’origine et cible sont identiques.

Les compétences intégrées incluent la reconnaissance optique de caractères (OCR), la détection de langue, la détection d’entité, la traduction et la fusion de texte, qui est utilisée pour remplacer une image incorporée par une sortie OCR incorporée dans le document d’origine.

La dernière compétence dans le pipeline est l’intégration des modèles de risque de compréhension du langage courant via l’application Functions.

Enfin, les champs d’origine et enrichis sont indexés et mappés à l’index Recherche cognitive Azure.

L’extrait suivant d’une réponse de recherche montre un exemple d’insights qui peuvent être obtenus à l’aide du contenu enrichi et de la recherche sémantique. Le terme de requête est « how were capex » (c-à-d « comment les dépenses d’investissement ont-elles évolué au cours de la période de reporting ? »).

{
 "@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"
  },
 ]
}

Interface utilisateur

Une fois qu’une solution de recherche est implémentée, vous pouvez interroger l’index directement à l’aide du Portail Azure. Bien que cette option soit adaptée pour l’apprentissage, l’expérimentation et le débogage, ce n’est pas une expérience appropriée pour l’utilisateur final.

Une interface utilisateur personnalisée, axée sur l’expérience utilisateur, est utile pour montrer la valeur réelle de la solution de recherche et permettre aux organisations d’identifier et d’examiner les communications à risque sur un large éventail de canaux et de sources.

L’accélérateur de solution Exploration de connaissances fournit un modèle d’interface utilisateur Recherche cognitive Azure (une application web .NET Core MVC) qui peut être utilisé pour créer rapidement un prototype afin d’interroger et d’afficher les résultats de la recherche.

En quelques étapes, l’interface utilisateur du modèle peut être configurée pour se connecter et interroger l’index de recherche, en affichant une page web simple pour rechercher et visualiser les résultats. Ce modèle peut être personnalisé pour améliorer l’expérience de récupération et d’analyse des communications à risque.

La capture d’écran suivante montre un exemple d’interface utilisateur pour notre scénario de risque, créé en personnalisant le modèle d’interface utilisateur Recherche cognitive Azure. Cette interface utilisateur montre un moyen d’afficher la solution de recherche en fournissant une vue intuitive des communications entre différents canaux et des informations sur les risques.

La page de démarrage fournit une interaction avec la solution de recherche. Elle permet à l’utilisateur de rechercher, d’affiner, de visualiser et d’explorer les résultats :

1. Les résultats initiaux sont récupérés à partir d’un index de recherche et affichés sous forme tabulaire, ce qui facilite l’accès aux communications et simplifie la comparaison des résultats.
   1. Les principaux détails de communication sont disponibles pour l’utilisateur et les documents provenant de plusieurs canaux (e-mails, transcriptions, actualités) sont regroupés en une seule vue.
   2. Les scores des modèles de risque personnalisés sont affichés pour chaque communication, où des risques plus élevés peuvent être mis en surbrillance.
   3. Une classification des risques consolidée agrège les scores des modèles de risque personnalisés et est utilisée pour trier les résultats en fonction du niveau moyen de risque.
2. Un curseur de seuil permet à l’utilisateur de modifier les seuils de risque. Les scores de risque personnalisés qui dépassent le seuil sont mis en surbrillance.
3. Un sélecteur de plage de dates permet d’élargir la période d’analyse ou de rechercher des résultats passés.
4. Les résultats de la recherche peuvent être affinés à l’aide d’un ensemble de filtres, tels que la langue ou le type de document. Ces options sont générées dynamiquement dans l’interface utilisateur, en fonction des champs pouvant être exposés configurés dans l’index.
5. Une barre de recherche permet de rechercher des termes ou expressions spécifiques dans l’index.
6. La recherche sémantique est disponible. L’utilisateur peut basculer entre la recherche standard et la recherche sémantique.
7. Les nouvelles communications peuvent être chargées et indexées directement via l’interface utilisateur. Une page de détails est également fournie pour chaque document :

La page de détails fournit l’accès au contenu de la communication et aux enrichissements et métadonnées :

8. Le contenu extrait pendant le processus de craquage de document s’affiche. Certains fichiers tels que les fichiers PDF peuvent être consultés directement dans la page de détails.
9. Les résultats des modèles de risque personnalisés sont synthétisés.
10. Les principales personnes et organisations mentionnées dans le document sont affichées dans cette page.
11. Des métadonnées supplémentaires capturées pendant le processus d’indexation peuvent être ajoutées et affichées dans des onglets supplémentaires de la page de détails.

Si le contenu non anglais est ingéré, l’utilisateur peut passer en revue le contenu dans la langue d’origine ou en anglais. L’onglet Transcription de la page de détails affiche le contenu d’origine et le contenu traduit côte à côte. Cela montre que, pendant le processus d’indexation, les deux langues sont conservées et peuvent ainsi être toutes les deux consommées par l’interface utilisateur.

Enfin, l’utilisateur peut effectuer des recherches sémantiques. L’exemple suivant montre le principal résultat où l’expression « how were capex » (c-à-d « comment les dépenses d’investissement ont-elles évolué au cours du trimestre de reporting ? ») a fait l’objet d’une recherche à l’aide de la recherche sémantique.

Dans une recherche équivalente en mode texte intégral, la requête de recherche recherche une correspondance exacte pour « capex », qui n’apparaît pas dans le document. Toutefois, la fonctionnalité sémantique permet au moteur de requête d’identifier que « capex » est lié aux « dépenses en capital », afin que cette communication soit identifiée comme la plus pertinente. En outre, la recherche sémantique génère des surbrillances sémantiques (12), résumant le document avec les phrases les plus pertinentes.

Bonnes pratiques

Cette section récapitule les meilleures pratiques organisationnelles et techniques pour développer votre solution d’analyse des risques de conformité.

Impliquer les parties prenantes requises : l’implémentation d’une solution d’analyse des risques est un exercice multidisciplinaire impliquant les principales parties prenantes issues de divers domaines. Prévoyez d’inclure les rôles liés au projet qui ont été introduits précédemment et d’autres rôles affectés par la solution.

Garantir l’adoption et la gestion adéquates des changements : l’automatisation des pratiques d’analyse des risques entraînera probablement des changements importants dans la façon de travailler des collaborateurs. Bien que la solution ajoute de la valeur, les modifications apportées à un flux de travail peuvent représenter un défi, ce qui entraîne de longues périodes d’adoption et, éventuellement, une résistance. Il est recommandé d’impliquer les collaborateurs concernés le plus tôt possible. Référez-vous au modèle d’adoption de Prosci ADKAR, qui se concentre sur cinq étapes clés d’un parcours d’adoption de la technologie : Prise de conscience, Désir, Connaissances, Capacité et Renforcement.

Utiliser plusieurs canaux pour découvrir les risques : chaque canal de communication (par exemple, e-mail, conversations, téléphone) peut être étudié de manière isolée pour détecter les risques potentiels. Toutefois, de meilleurs insights sont obtenus en combinant des canaux hétérogènes de communications formelles (par exemple, e-mail) et moins formelles (par exemple, conversations). En outre, l’intégration d’informations complémentaires (par exemple, les nouvelles du marché, les rapports d’entreprise, les dossiers SEC) peut fournir un contexte supplémentaire pour l’analyste de conformité (par exemple, à propos d’une initiative spécifique d’une entreprise).

Démarrer de façon simple et itérer : Recherche cognitive Azure fournit un ensemble complet d’enrichissements par IA intégrés, basés sur différents services Cognitive Services. Il peut être tentant d’ajouter immédiatement un grand nombre de ces fonctionnalités. Toutefois, si le nombre d’entités ou d’expressions clés qui peuvent être extraites n’est pas contrôlé correctement, cela peut submerger l’utilisateur final. En commençant par un ensemble réduit de compétences ou d’entités, vous pouvez aider les utilisateurs et les développeurs à comprendre ceux qui ajoutent le plus de valeur.

Innovation responsable : le développement de solutions IA exige un haut niveau de responsabilité de tous ceux qui sont impliqués. Microsoft prend très au sérieux l’utilisation responsable de l’intelligence artificielle et a développé un cadre de principes de conception fondamentaux :

• Équité
• Fiabilité et sécurité
• Confidentialité et sécurité
• Inclusivité
• Transparence et responsabilité

L’évaluation des communications des employés nécessite une attention particulière et soulève des préoccupations éthiques. Dans certains pays/certaines régions, la surveillance automatisée des employés est soumise à des restrictions légales strictes. Pour toutes ces raisons, faites de l’innovation responsable une pierre angulaire de votre plan de projet. Microsoft propose plusieurs frameworks et outils à cet effet. Pour plus d’informations, reportez-vous à la zone Conseil à la fin de cette section.

Automatiser vos itérations de développement : l’Assistant Importation de données facilite la prise en main, mais pour des solutions plus complexes et des cas d’usage productifs, nous vous recommandons de créer des ressources telles que des sources de données, des indexeurs, des index et des ensembles de compétences dans le code. L’automatisation accélère considérablement les cycles de développement et garantit un déploiement cohérent en production. Les ressources sont spécifiées au format JSON. Vous pouvez copier des définitions JSON à partir du portail, les modifier en fonction des besoins, puis les fournir dans le corps de la demande des appels aux API REST Recherche cognitive Azure.

Sélectionner l’approche de traitement du langage naturel appropriée pour l’analyse des risques : méthodes permettant d’identifier les risques dans une plage de textes non structurés, allant de la recherche de mots clés de base et de l’extraction d’entités à des architectures NLP modernes et puissantes. Le meilleur choix dépend de la quantité et de la qualité des données d’apprentissage existantes pour le cas d’usage spécifique. Si les données d’apprentissage sont limitées, vous pouvez entraîner un modèle basé sur des énoncés à l’aide de la fonctionnalité de compréhension du langage courant d’Azure Cognitive Service for Language. Les conversations existantes peuvent être examinées pour identifier et étiqueter les phrases qui indiquent des types de risques pertinents. Parfois, des dizaines d’échantillons suffisent pour entraîner un modèle avec de bons résultats.

Dans les cas où les signes de risque sont plus subtils et s’étendent sur plusieurs phrases, l’entraînement d’un modèle de traitement du langage naturel de pointe est probablement le meilleur choix. Toutefois, cette approche nécessite généralement des données d’apprentissage beaucoup plus importantes. Nous vous recommandons d’utiliser, dans la mesure du possible, les données réelles lorsque la solution est en production, afin d’ajuster les erreurs potentielles et de réentraîner continuellement le modèle afin d’améliorer ses performances au fil du temps.

Adapter l’interface utilisateur en fonction de vos besoins spécifiques : une interface utilisateur riche peut rendre disponible toute la valeur ajoutée de Recherche cognitive Azure et des enrichissements par IA. Bien que le modèle d’interface utilisateur Recherche Azure AI offre un moyen simple et rapide d’implémenter une application web initiale, il doit probablement être adapté pour intégrer des fonctionnalités supplémentaires. Il doit également prendre en charge les types de communications traitées, les types d’enrichissements par IA utilisés et toutes exigences métier supplémentaires. La collaboration et l’itération continues entre les développeurs front-end, les parties prenantes de l’entreprise et les utilisateurs finaux permettront d’améliorer la valeur de la solution en optimisant l’expérience utilisateur lors de la recherche et de l’examen des communications pertinentes.

Optimiser les coûts des services de traduction : par défaut, tous les documents transitent par le pipeline d’enrichissement par IA. Cela signifie que les documents en langue anglaise sont transmis au service de traduction même si aucune traduction réelle n’est nécessaire. Toutefois, étant donné que le contenu est traité par l’API Traduction, des frais s’appliquent néanmoins. Dans notre solution, nous utilisons la détection de langue conjointement avec des compétences conditionnelles pour éviter la traduction dans ces cas de figure. Si la langue détectée du document d’origine n’est pas l’anglais, le contenu est copié dans un champ spécifique pour le contenu non anglais, puis transmis au service de traduction. Si le document est en anglais, ce champ est vide et aucun frais de traduction n’est généré. Enfin, tout le contenu (à l’origine en anglais ou traduit) est fusionné dans un champ commun pour faire l’objet d’un traitement supplémentaire. Vous pouvez également activer la mise en cache pour réutiliser les enrichissements existants.

Garantir la disponibilité et la scalabilité de votre environnement de production : une fois que vous êtes passé de la preuve de concept à la planification de la production, vous devez tenir compte de la disponibilité et de la scalabilité pour garantir la fiabilité et les performances de votre solution de recherche. Les instances du service de recherche sont appelées réplicas et sont utilisées pour équilibrer la charge des opérations de requête. Ajoutez des réplicas pour la haute disponibilité et augmentez les performances des requêtes. Utilisez des partitions pour gérer la scalabilité de votre solution. Les partitions représentent le stockage physique et ont une taille et des caractéristiques d’E/S spécifiques. Reportez-vous à la documentation pour obtenir des conseils supplémentaires sur la gestion de la capacité et d’autres considérations relatives à la gestion des services.

Conclusion

Ce guide fournit des conseils complets pour configurer une solution qui utilise l’IA afin de rechercher des signes de fraude. L’approche s’applique à d’autres secteurs réglementés tels que la santé ou le secteur public.

Vous pouvez étendre l’architecture de façon à inclure d’autres sources de données et fonctionnalités d’IA, telles que :

• Ingérer des données structurées, telles que des données de marché (par exemple, le cours boursier) et des informations sur les transactions.
• Attacher des modèles de classification conçus pour extraire du contenu à partir de sources papier, à l’aide de fonctionnalités telles que Azure Form Recognizer et l’API Read d’Azure.
• Ingérer des informations sur les réseaux sociaux à l’aide des fonctionnalités d’Azure Language Studio pour catégoriser et filtrer les sujets pertinents, ou l’analyse des sentiments Azure pour capturer les tendances d’opinion.
• Utiliser Microsoft Graph pour assembler et consolider des informations à partir de Microsoft 365, telles que des interactions interpersonnelles, les entreprises avec lesquelles les personnes travaillent ou des informations auxquelles elles accèdent. Lorsque vous enregistrez ces données dans Stockage Azure, vous pouvez facilement les rechercher.

La technologie qui sous-tend la solution, Recherche cognitive Azure, constitue le meilleur choix, car elle prend en charge l’exploration de connaissances, la recherche de catalogue et la recherche dans l’application. Il est simple de déployer et de se connecter à plusieurs sources de données et de fournir une IA intégrée et extensible pour le traitement du contenu. Elle dispose de fonctionnalités telles que la recherche sémantique qui sont optimisées par le Deep Learning, des fonctionnalités qui peuvent déduire l’intention de l’utilisateur et afficher et classer les résultats les plus pertinents.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Andreas Kopp | Architecte de solutions cloud senior
• João Pedro Martins | Responsable senior Architecte de solution cloud
• Carlos Alexandre Santos | Architecte de solution cloud senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Démarrage rapide : Créer un index Recherche cognitive Azure dans le portail Azure

Ressources associées

• Exploration des connaissances pour le support client et l’analyse des commentaires
• Technologie de traitement du langage naturel
• Traitement du langage naturel personnalisé à grande échelle
• Exploration des connaissances pour la recherche de contenu