Compliancerisikoanalyse mithilfe von Azure Cognitive Search

In diesem Artikel finden Sie technische Richtlinien für die Implementierung einer Compliance-Risikoanalyselösung mithilfe von Azure Cognitive Search. Die Richtlinien basieren auf realen Projekterfahrungen. Wegen des großen Umfangs der Lösung und der Notwendigkeit, sie an Ihren spezifischen Anwendungsfall anzupassen, konzentriert sich der Artikel auf die wesentlichen und spezifischen Architektur- und Implementierungsaspekte. Sie verweist ggf. auf ausführliche Tutorials.

Apache®, Apache Lucene® und das Flammenlogo sind eingetragene Marken oder Marken der Apache Software Foundation in den USA und/oder anderen Ländern. Die Verwendung dieser Markierungen impliziert kein Endorsement durch die Apache Software Foundation.

Einführung

Jeden Tag führen Berater und Händler in Finanzinstituten Diskussionen, Analysen und Entscheidungen über Transaktionen in Millionenhöhe durch. Betrügerische Transaktionen, Kollusion, Insiderhandel und anderes Fehlverhalten von Mitarbeiter*innen stellen für diese Institutionen beträchtliche Risiken dar, sowohl in Bezug auf rechtliche Folgen als auch für das öffentliche Ansehen.

Die Aufgabe von Complianceteams ist es, diese Risiken zu verringern. Ein Teil ihrer Arbeit ist die Überwachung der Kommunikation über mehrere Kanäle, einschließlich Instant Messaging, E-Mails und geschäftlicher Telefonanrufe. Häufig werden die bei der Überwachung erhaltenen Daten anhand geschäftlicher Transaktionsdaten überprüft. Ziel ist es, Anzeichen von Complianceverstößen zu finden, die oft versteckt und subtil sind. Diese Aufgabe ist arbeitsintensiv, erfordert hohe Aufmerksamkeit und ist mit dem Durcharbeiten großer Datenmengen verbunden. Auch wenn automatisierte Systeme helfen können, kann das Volumen der übersehenen Risiken recht hoch sein, sodass die ursprüngliche Kommunikation überprüft werden muss.

Azure Cognitive Search kann dazu beitragen, die Risikobewertung zu automatisieren und ihre Qualität zu verbessern. Es verfügt über integrierte KI, erweiterbare KI und intelligente Suchfunktionen. Die in diesem Artikel vorgestellte Compliance-Risikoanalyselösung zeigt Ihnen, wie Sie Risiken wie Fehlverhalten von Finanzhändlern identifizieren und analysieren können, indem Sie Inhalte aus verschiedenen Kommunikationskanälen konsolidieren und analysieren. Zu den potenziellen Risiken, die in diesem unstrukturierten Inhalt identifiziert werden können, gehören Anzeichen der Marktmanipulation, Insiderhandel, Investmentfondsbetrug und andere.

Die Lösungsarchitektur nutzt Azure Cognitive Services und Azure Cognitive Search. Das Szenario zielt auf Kommunikationsrisiken im Finanzsektor ab, das Entwurfsmuster kann aber auch auf andere Branchen und Sektoren übertragen werden, z. B. Behörden und Gesundheitsversorgung. Organisationen können die Architektur anpassen, indem sie Risikobewertungsmodelle für ihre Geschäftsszenarien entwickeln und integrieren. Die Wolters Kluwer-Demo-App bietet beispielsweise Anwälten die Möglichkeit, in Akten und Schriftverkehr bezüglich Börsenaufsichtsbehörden schnell relevante Informationen zu finden. Sie identifiziert Risiken im Zusammenhang mit der Finanzierung, einschließlich Cybersicherheit und geistigen Eigentums.

Azure Cognitive Search verfügt über integrierte KI und benutzerdefinierte Skills, die die Geschäftsprozessleistung und die Produktivität von Complianceteams verbessern. Es ist besonders nützlich für die folgenden Situationen:

• Es besteht ein Bedarf, Erkenntnisse aus großen Mengen heterogener, unstrukturierter Dokumente zu gewinnen, z. B. Finanzberichte, Sprachtranskriptionen und E-Mails.
• Es sind keine vollständigen Risikomanagementverfahren für unstrukturierte Inhalte vorhanden.
• Vorhandene Ansätze sind zeit- und arbeitsintensiv und führen zu übermäßigen falschen Warnungen oder zu übersehenen tatsächlichen Risiken.
• Für eine umfassendere Risikoanalyse müssen verschiedene Kommunikationskanäle und Datenquellen integriert werden, einschließlich strukturierter Daten.
• Daten- und Domänenkenntnisse sind verfügbar, um Machine Learning-Modelle zu trainieren, die Risikosignale in unstrukturiertem Text identifizieren können. Alternativ können vorhandene Modelle integriert werden.
• Die Architektur muss zur Verbesserung der Lösung kontinuierlich unstrukturierte Daten erfassen und verarbeiten können, z. B. Unterhaltungen und Nachrichten.
• Bei der Complianceanalyse wird ein effizientes Tool für die Erkennung und detaillierte Analyse von Risiken benötigt. Das Tool muss ein Human-in-the-Loop-Tool sein, damit die Analyst*innen den Prozess steuern und mögliche falsche Vorhersagen kennzeichnen können, um die Modelle zu verbessern.

Azure Cognitive Search ist ein Cloudsuchdienst mit integrierten KI-Funktionen, die alle Arten von Informationen anreichern, um relevante Inhalte im großen Stil identifizieren und untersuchen zu können. Verwenden Sie kognitive Skills für visuelle und sprachliche Inhalte benutzerdefinierte Machine Learning-Modelle, um Erkenntnisse aus allen Arten von Inhalten zu gewinnen. Azure Cognitive Search bietet auch semantische Suchfunktionen, die erweiterte Techniken des maschinellen Lernens verwendet, um die Absicht der Benutzer*innen zu klassifizieren und die relevantesten Suchergebnisse kontextabhängig zu bewerten.

Das folgende Diagramm zeigt allgemein, wie Azure Cognitive Search funktioniert, von der Datenerfassung und Indizierung bis zum Bereitstellen von Ergebnissen für Benutzer*innen.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

In diesem Artikel finden Sie Details zu der Lösung für den Risikoanalyse-Anwendungsfall und andere Finanzdienstleistungsszenarien wie das zuvor erwähnte Wolters Kluwer-Beispiel. Er bietet Schritte zur technischen Umsetzung mit referenzierten Anleitungen und einer Referenzarchitektur. Er schließt bewährte Methoden aus organisatorischen und technischen Blickwinkeln ein. Das Entwurfsmuster geht davon aus, dass Sie eigene Daten einsetzen und eigene Risikoanalysemodelle entwickeln, die für Ihren Geschäftskontext und Ihre Anforderungen geeignet sind.

Lösungsübersicht

Das folgende Diagramm bietet eine allgemeine Ansicht der Risikoanalyselösung.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Um Kommunikation mit einem echten Risiko zu identifizieren, werden Inhalte aus heterogenen Kommunikationskanälen extrahiert und durch verschiedene Machine Learning-Modelle von Cognitive Services angereichert. Als Nächstes werden benutzerdefinierte domänenspezifische Modelle angewandt, um Anzeichen von Marktmanipulation und anderen Risiken zu identifizieren, die in Kommunikation und Interaktionen zwischen Personen auftreten. Sämtliche Daten werden in einer konsolidierten Azure Cognitive Search-Lösung aggregiert. Die Lösung besteht aus einer benutzerfreundlichen App mit Risikoidentifizierungs- und Analysefunktionen. Anwendungsdaten werden in einem Suchindex gespeichert und in einen Wissensspeicher übertragen, wenn Sie einen längerfristigen Speicher benötigen.

Die folgende Abbildung bietet eine konzeptionelle Übersicht über die Lösungsarchitektur:

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Obwohl jeder Kommunikationskanal, z. B. E-Mail, Chats und Telefonie, einzeln zum Erkennen potenzieller Risiken verwendet werden kann, werden bessere Erkenntnisse erzielt, indem Kanäle kombiniert und die Inhalte um zusätzliche Informationen wie Marktnachrichten ergänzt werden.

Die Risikoanalyselösung verwendet mehrere Schnittstellen zum Integrieren von Unternehmenskommunikationssystemen für die Datenerfassung:

• Blob Storage wird als allgemeine Quelle für Daten im Dokumentformat verwendet, z. B. E-Mail-Inhalte einschließlich Anlagen, Transkripts von Telefonanrufen oder Chats und Nachrichtendokumente.
• Office 365-Kommunikationsdienste wie Microsoft Exchange Online und Microsoft Teams können mithilfe von Microsoft Graph Data Connect für die Massenerfassung von E-Mails, Chats und anderen Inhalten integriert werden. Eine Azure Cognitive Search-Schnittstelle für SharePoint in Microsoft 365 ist ebenfalls verfügbar.
• Sprachkommunikation wie Telefonanrufe werden mithilfe des Spracherkennungsdiensts von Cognitive Services transkribiert. Die resultierenden Transkriptionen und Metadaten werden dann von Azure Cognitive Search über Blob Storage erfasst.

In diesen Beispielen kommen häufig verwendete Unternehmenskommunikationskanäle zum Einsatz. Es können jedoch auch zusätzliche Kanäle über ähnliche Erfassungsmuster integriert werden.

Nach der Konsolidierung werden die Rohdaten durch KI-Skills angereichert, um eine Struktur zu erkennen und textbasierte Inhalte aus zuvor nicht durchsuchbaren Inhaltstypen zu erstellen. Beispiel:

• Finanzberichte in PowerPoint-Dateien oder PDFs enthalten häufig eingebettete Bilder anstelle von maschinell lesbaren Text, um Änderungen zu verhindern. Zur Verarbeitung dieser Art von Inhalten werden alle Bilder durch optische Zeichenerkennung (OCR) mithilfe des kognitiven Skills „OCR“ analysiert.
• Inhalte in verschiedenen Sprachen werden mithilfe des kognitiven Skills „Textübersetzung“ in Englisch oder eine andere Sprache übersetzt.
• Wichtige Informationen wie Namen von Personen und Organisationen werden automatisch extrahiert und können mithilfe des kognitiven Skills „Entitätserkennung“ für leistungsstarke Suchabfragen verwendet werden. Eine Suche kann beispielsweise die gesamte Kommunikation zwischen James Doe und Mary Silva finden, die sich um ein bestimmtes Unternehmen während eines bestimmten Zeitraums dreht.
• Mit benutzerdefinierten Modelle können Nachweise eines Risikos in der Kommunikation identifiziert werden, z. B. Insiderhandel. Diese domänenspezifischen Modelle können auf Schlüsselwörtern, Äußerungen oder ganzen Absätzen basieren. Sie verwenden erweiterte Technologien für die linguistische Datenverarbeitung (Natural Language Processing, NLP). Benutzerdefinierte Modelle werden mithilfe von domänenspezifischen Daten für den vorliegenden Anwendungsfall trainiert.

Nach dem Anwenden der KI-Anreicherungen und benutzerdefinierten Skills von Azure Cognitive Search wird der Inhalt in einem Suchindex konsolidiert, der umfassende Such- und Knowledge Mining -Szenarien unterstützt. Complianceanalyst*innen und andere Benutzer*innen verwenden die Front-End-App, um potenzielle Risikokommunikation zu identifizieren und Drilldownsuchen für weitere Analysen durchzuführen. Die Risikomanagement ist ein dynamischer Prozess. Modelle werden ständig in der Produktion verbessert, und Modelle für neue Risikotypen werden hinzugefügt. Daher muss die Lösung modular sein. Neue Risikotypen werden auf der Benutzeroberfläche automatisch gekennzeichnet, wenn die Modelle erweitert werden.

Die Front-End-App verwendet intelligente und semantische Suchabfragen, um die Inhalte zu untersuchen. Die Inhalte können auch zur Compliancespeicherung oder zur Integration mit anderen Systemen in einen Wissensspeicher verschoben werden.

Die Bausteine der Lösung werden in den folgenden Abschnitten ausführlicher beschrieben.

Die Implementierung einer Risikoanalyselösung ist eine multidisziplinäre Übung, die die Mitarbeit wichtiger Beteiligter aus verschiedenen Domänen erfordert. Anhand unserer Erfahrungen empfehlen wir die folgenden Rollen, um eine erfolgreiche Entwicklung und Einführung der Lösung in die Organisation zu gewährleisten.

Datenerfassung

In diesem Abschnitt wird erläutert, wie Sie heterogene Inhalte in einer einzelnen Datenquelle konsolidieren und dann eine anfängliche Sammlung von Suchressourcen einrichten, die aus dieser Quelle abgeleitet werden.

Die Entwicklung und Implementierung einer Azure Cognitive Search-Lösung ist häufig ein inkrementeller Prozess. Datenquellen, Transformationen und Ergänzungen werden in nachfolgenden Iterationen über den Grundkonfigurationen hinzugefügt.

Der erste Schritt einer Azure Cognitive Search-Lösung besteht im Erstellen einer Dienstinstanz im Azure-Portal. Neben dem eigentlichen Suchdienst benötigen Sie mehrere Suchressourcen, einschließlich eines Suchindex, eines Indexers, einer Datenquelle und eines Skillsets. Sie können eine Grundkonfiguration mit geringem Aufwand erstellen, indem Sie den Assistenten zum Importieren von Daten von Azure Cognitive Search verwenden, der im Azure-Portal zu finden ist. Dieser Assistent, der hier dargestellt ist, führt Benutzer*innen durch die grundlegenden Schritte zum Erstellen und Laden eines einfachen Suchindex, der Daten aus einer externen Datenquelle verwendet.

Die Erstellung des Suchindex durch den Assistenten zum Importieren von Daten umfasst vier Schritte:

1. Verbindung mit Daten: Die Verbindung mit einem vorhandenen Blob Storage kann z. B. mühelos mit wenigen Klicks ausgeführt werden. Für die Authentifizierung wird eine Verbindungszeichenfolge verwendet. Zu anderen nativ unterstützten Datenquellen gehört eine Vielzahl von Azure-Diensten, z. B. Azure SQL-Datenbank, Azure Cosmos DB und Dienste wie SharePoint Online. In dieser Lösung wird Blob Storage verwendet, um die heterogenen Inhaltstypen zu konsolidieren.
2. Hinzufügen von kognitiven Skills: In diesem optionalen Schritt werden dem Indizierungsprozess integrierte KI-Skills hinzugefügt. Sie werden angewandt, um die aus der Datenquelle gelesenen Inhalte anzureichern. In diesem Schritt können beispielsweise die Namen und Standorte von Personen und Organisationen extrahiert werden.
3. Anpassung des Zielindex: In diesem Schritt konfigurieren die Entwickelnden die Feldentitäten für den Index. Ein Standardindex wird bereitgestellt, Felder können aber hinzugefügt, gelöscht oder umbenannt werden. Beispielfelder sind: Dokumenttitel, Beschreibung, URL, Autor, Standort, Unternehmen und Aktienticker sowie die Arten von Vorgängen, die für jedes dieser Felder möglich sind.
4. Erstellung des Indexers: Im letzten Schritt wird ein Indexer konfiguriert, die Komponente, die regelmäßig zum Aktualisieren des Inhalts des Suchindex ausgeführt wird. Ein wichtiger Parameter ist die Ausführungshäufigkeit des Indexers.

Nach dem Bestätigen der Konfigurationen werden eine Datenquelle, ein Skillset, ein Indexer und ein Index erstellt. Für jede dieser Komponenten wird eine JSON-Definition erstellt. Die JSON-Definitionen bieten erweiterte Anpassungen und können verwendet werden, um die Dienste programmgesteuert über eine REST-API zu erstellen. Der Vorteil besteht in der konsistenten und programmgesteuerten Erstellung von Ressourcen in allen nachfolgenden Entwicklungsiterationen. Aus diesem Grund verwenden wir JSON-Definitionen, um die Konfiguration aller Ressourcen zu veranschaulichen. Der Abschnitt Automatische Erstellung von Suchressourcen bietet ausführliche Erläuterungen zum programmgesteuerten Erstellen aller Ressourcen durch diese Definitionen.

In der Konfiguration wird Blob Storage als Standarddatenquelle ausgewählt. Obwohl Kommunikation aus mehreren Kanälen oder Quellen stammen kann, basiert ein generischer Ansatz für dieses Lösungsmuster auf sämtlicher Kommunikation in Blob Storage mit Text oder Bildern. Im folgenden Schritt wird die Konfiguration der JSON-Definition einer Datenquelle für Blob Storage näher untersucht.

In diesem Abschnitt wird auf einige Muster verwiesen, um zu veranschaulichen, wie Office 365 Kommunikation in Blob Storage erfasst wird und wie Audioanrufe mithilfe des Spracherkennungsdiensts transkribiert werden.

Blob Storage

Die folgende JSON-Definition zeigt die Struktur und die Informationen, die zum Konfigurieren von Blob Storage als Datenquelle für Azure Cognitive Search benötigt werden:

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

Die folgenden Felder sind erforderlich:

• Name: der Name, der der Datenquelle zugewiesen ist.
• Typ: definiert die Datenquelle als Blob Storage.
• Anmeldeinformationen: die Verbindungszeichenfolge für Blob Storage.
• Container: der Name des Containers, in dem die Blobs gespeichert sind. Es kann ein Verzeichnis im Container angegeben werden, sodass mehrere Datenquellen im selben Container erstellt werden können.

Standardmäßig unterstützt die Blob Storage-Datenquelle eine Vielzahl von Dokumentformaten. Beispielsweise werden Audiotranskriptionen häufig in JSON-Dateien gespeichert, E-Mails sind in der Regel MSG- oder EML-Dateien, Nachrichten oder zusätzliches Kommunikationsmaterial weisen die Formate PDF, Word (etwa DOC/DOCX/DOCM) oder PowerPoint (PPT/PPTX/PPTM) auf oder sind HTML-Webseiten.

Um mehrere Datenquellen für die Kommunikation im selben Blob Storage einzurichten, können Sie eine der folgenden Techniken verwenden:

• Geben Sie jeder Datenquelle einen eigenen Container.
• Verwenden Sie denselben Container für alle Datenquellen, weisen Sie jedoch jeder Datenquelle in diesem Container ein eigenes Verzeichnis zu.

Microsoft Graph Data Connect

Für Office 365-Kundschaft kann Microsoft Graph Data Connect verwendet werden, um ausgewählte Daten aus Microsoft Graph vor der Azure Cognitive Search-Lösung in Azure Storage zu extrahieren. Die in Microsoft Graph gespeicherten Daten umfassen Daten wie E-Mails, Besprechungen, Chats, SharePoint-Dokumente, Personen und Aufgaben.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Diagramm des Datenflows von Microsoft Graph. Der Prozess nutzt zum Extrahieren von Daten aus Microsoft Graph Azure Data Factory-Funktionen. Es gibt eine abgestufte Sicherheitssteuerung, einschließlich Einwilligung und eines Governancemodells. Die Data Factory-Pipeline ist mit den Datentypen konfiguriert, die extrahiert werden sollen, z. B. E-Mails und Teamchats, und einen Gültigkeitsbereich, etwa einer Gruppe von Benutzer*innen und einem Datumsbereich. Die Suche wird in einem definierten Zeitplan in konfigurierbaren Abständen ausgeführt und ist so konfiguriert, dass die extrahierten Daten in Azure Storage abgelegt werden. Von dort aus werden die Daten von einem Indexer in Azure Cognitive Search aufgenommen.

Spracherkennungs-Referenzarchitektur

Telefonunterhaltungen sind ein unabdingbares Arbeitstool bei jeder Finanzdienstleistungsorganisation. Sie können in eine Risikoanalyselösung einbezogen werden, wenn Zugriff auf die zugehörigen Audiodateien besteht. Dieser Abschnitt behandelt diese Situation.

Die Dokumententschlüsselung in Azure Cognitive Search umfasst eine Reihe von Verarbeitungsschritten, die vom Indexer ausgeführt werden, um Text und Bilder aus der Datenquelle zu extrahieren. Für Audiodateien wird eine Möglichkeit benötigt, Transkriptionen dieser Audiokommunikation zu extrahieren, damit sie für die textbasierte Verarbeitung verfügbar sind.

Das folgende Diagramm zeigt eine Pipeline zur Audioerfassung und Spracherkennung. Die Pipeline verarbeitet Batches von Audiodateien und speichert die Transkriptionsdateien in Blob Storage vor der Azure Cognitive Search-Lösung.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

In dieser Referenzarchitektur werden Audiodateien über eine Clientanwendung in Blob Storage hochgeladen. Während dieses Prozesses wird die Anwendung mit Microsoft Entra ID authentifiziert und die REST-API aufgerufen, um ein Token für Blob Storage abzurufen. Der sichere Zugriff auf die REST-API wird von Azure API Management bereitgestellt, und eine Azure Key Vault-Instanz bietet einen sicheren Speicher für die erforderlichen Geheimnisse zum Generieren der Token sowie für Kontoanmeldeinformationen.

Nachdem die Dateien hochgeladen wurden, wird ein Azure Event Grid-Trigger ausgegeben, um eine Azure-Funktion aufzurufen. Die Funktion verarbeitet dann die Audiodatei mithilfe der Cognitive Services-Spracherkennungs-API. Das transkribierte JSON-Dokument wird anschließend in einem separaten Blobcontainer gespeichert, der durch Azure Cognitive Search als Datenquelle erfasst werden kann.

Durchsuchen einer Projektmappe

Wie beschrieben, werden mehrere Datenquellen wie E-Mails, Transkriptionen und Nachrichten erstellt und dann in Blob Storage gespeichert. Jede Datenquelle wird dann auf eigene Weise transformiert und angereichert. Alle resultierenden Ausgaben werden demselben Index zugeordnet, sodass die Daten aus allen Arten von Quelldokumenten konsolidiert werden.

Das folgende Diagramm veranschaulicht diesen Ansatz. Für jede der verfügbaren Datenquellen ist ein benutzerdefinierter Indexer konfiguriert, und alle Ergebnisse werden in einen einzelnen Suchindex überführt.

In den folgenden Abschnitten werden die Indizierungs-Engines und die durchsuchbaren Indizes untersucht. Sie zeigen, wie Sie einen Indexer konfigurieren und JSON-Definitionen indizieren, um eine durchsuchbare Lösung zu implementieren.

Indexer

Ein Indexer koordiniert die Extraktion und Anreicherung von Dokumentinhalten. Eine Indexerdefinition enthält Details zu der Datenquelle, die erfasst werden soll, der Zuordnung der Felder sowie der Transformation und Anreicherung der Daten.

Da die Zuordnung, Transformation und Anreicherung nach Datentyp variiert, sollte ein Indexer für jede Datenquelle vorhanden sein. Beispielsweise kann das Indizieren von E-Mails OCR-Skills erfordern, um Bilder und Anlagen zu verarbeiten, für Transkriptionen sind hingegen nur sprachbasierte Skills erforderlich.

Dies sind die Schritte des Indizierungsprozesses:

• Dokumententschlüsselung: Azure Cognitive Search öffnet die Dokumente und extrahiert den relevanten Inhalt aus ihnen. Der extrahierte indizierbare Inhalt ist eine Funktion der Datenquellen und der Dateiformate. Für eine Datei wie eine PDF- oder Microsoft 365-Datei in Blob Storage öffnet der Indexer beispielsweise die Datei und extrahiert Text, Bilder und Metadaten.
• Feldzuordnung: Die Namen der Felder, die aus der Quelle extrahiert wurden, werden Zielfeldern in einem Suchindex zugeordnet.
• Skillsetausführung: Die integrierte oder benutzerdefinierte KI-Verarbeitung erfolgt in diesem Schritt, wie in einem späteren Abschnitt beschrieben wird.
• Ausgabefeldzuordnung: Die Namen von transformierten oder erweiterten Feldern werden den Zielfeldern in einem Index zugeordnet.

Der folgende Codeausschnitt zeigt ein Segment der JSON-Definition des E-Mail-Indexers. Diese Definition verwendet die in den Schritten beschriebenen Informationen und bietet detaillierte Anweisungen für die Indizierungs-Engine.

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

In diesem Beispiel wird der Indexer durch den eindeutigen Namen email-indexer identifiziert. Dieser Indexer bezieht sich auf eine Datenquelle namens email-ds, und die KI-Anreicherungen werden durch das Skillset email-skillset definiert. Die Ausgabe des Indizierungsprozesses wird im Index mit dem Namen combined-index gespeichert. Weitere Details umfassen einen auf tägliche Verarbeitung festgelegten Zeitplan, eine maximale Anzahl von 50 fehlerhaften Elementen und eine Konfiguration zum Generieren von normalisierten Bildern und zum Extrahieren von Inhalten und Metadaten.

Im Feldzuordnungsabschnitt wird das Feld metadata_storage_path mithilfe eines Base64-Codierers codiert und dient dann als eindeutiger Dokumentschlüssel. In der Ausgabe-Feldzuordnungskonfiguration (nur teilweise angezeigt) wird die Ausgabe des Anreicherungsprozesses dem Indexschema zugeordnet.

Wenn ein neuer Indexer für eine neue Datenquelle (z. B. Transkriptionen) erstellt wird, wird der Großteil der JSON-Definition entsprechend der Datenquelle und der Skillsetauswahl konfiguriert. Der Zielindex muss jedoch combined-index sein (sofern alle Feldzuordnungen kompatibel sind). Dies ist die Technik, durch die der Index Ergebnisse aus mehreren Datenquellen konsolidieren kann.

Indizes und andere Strukturen

Nach Abschluss des Indizierungsprozesses werden die extrahierten und erweiterten Dokumente in einem durchsuchbaren Index und optional in Wissensspeichern beibehalten.

• Durchsuchbarer Index: Ein durchsuchbarer Index entspricht der erforderlichen Ausgabe, die immer als Teil eines Indizierungsprozesses erstellt wird, und wird gelegentlich auch als Suchkatalog bezeichnet. Zum Erstellen eines Index ist eine Indexdefinition erforderlich. Sie enthält Konfigurationen (z. B. „Typ“, „durchsuchbar“, „filterbar“, „sortierbar“, „facettierbar“, „abrufbar“) für alle Felder. Diese Indexfeldnamen müssen auf die Zuordnungen für Indexerfeld und Ausgabefeld abgestimmt sein.

  Mehrere Indexer können demselben Index zugewiesen werden, sodass der Index Kommunikation aus verschiedenen Datasets wie E-Mails oder Transkriptionen konsolidiert. Ein Index kann dann mithilfe der Volltextsuche oder der semantischen Suche abgefragt werden.

  Ähnlich wie Indexer können Indizes mithilfe einer JSON-Indexdefinition konfiguriert werden. Der folgende Codeausschnitt entspricht einem Segment der JSON-Definition 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": []
    },
  

  In diesem Beispiel wird der Index durch den eindeutigen Namen combined-index identifiziert. Die Indexdefinition ist unabhängig von Indexern, Datenquellen und Skillsets. Die Felder definieren das Schema des Index, und zum Zeitpunkt der Konfiguration können Benutzer*innen den Namen und den Typ jedes Felds sowie eine Reihe von Eigenschaften konfigurieren, z. B. facettierbar, filterbar.

  In diesem Codeausschnitt sind zwei Felder enthalten. Metadata_storage_path ist eine abrufbare Zeichenfolge, die als Dokumentschlüssel verwendet wird. Das Feld Personen ist hingegen eine Sammlung von Zeichenfolgen, die facettierbar, filterbar, abrufbar und durchsuchbar sein kann, und die Volltextabfrage wird mithilfe einer standard.lucene-Analyse verarbeitet.

• Wissensspeicher: Ein Wissensspeicher kann eine optionale Ausgabe für unabhängige Analysen und nachgelagerte Verarbeitung in Nicht-Suchszenarien wie Knowledge Mining sein. Die Implementierung eines Wissensspeichers wird in einem Skillset definiert, in dem das angereicherte Dokument oder bestimmte Felder als Tabellen oder Dateien projiziert werden können.

  Die folgende Abbildung zeigt eine Implementierung eines Wissensspeichers:

  

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Mit einem Azure Cognitive Search-Wissensspeicher können Daten mithilfe der folgenden Optionen (als Projektionen bezeichnet) beibehalten werden:

• Dateiprojektionen ermöglichen die Extraktion von Inhalten (z. B. eingebettete Bilder) als Dateien. Ein Beispiel stellen Diagramme aus Finanzberichten dar, die in Bilddateiformaten exportiert werden.
• Tabellenprojektionen unterstützen tabellarische Berichtsstrukturen (z. B. für Analyseanwendungsfälle). Sie können zum Speichern aggregierter Informationen wie Risikoscores für jedes Dokument verwendet werden.
• Objektprojektionen extrahieren Inhalte als JSON-Objekte in Blob Storage. Sie können für die Risikoanalyselösung verwendet werden, wenn Daten aus Compliancegründen in unterschiedlicher Detailtiefe aufbewahrt werden müssen. Risikoscores können mithilfe dieses Ansatzes archiviert werden.

Da die Struktur der Suchdaten für Abfragen optimiert ist, liegt in der Regel keine Optimierung für andere Zwecke vor, z. B. Exportieren in einen Wissensspeicher. Sie können den Shaper-Skill verwenden, um die Daten entsprechend Ihren Aufbewahrungsanforderungen zu strukturieren, bevor Sie die Projektionen anwenden.

In einem Wissensspeicher werden die beibehaltenen Inhalte in Table oder Blob Storage in Azure Storage gespeichert.

Es gibt verschiedene Optionen für die Verwendung von Daten aus einem Wissensspeicher. Azure Machine Learning kann auf die Inhalte zugreifen, um Machine Learning-Modelle zu erstellen. Power BI kann die Daten analysieren und visuelle Elemente erstellen.

Finanzorganisationen verfügen über vorhandene Richtlinien und Systeme für langfristige Complianceaufbewahrung. Azure Storage ist daher möglicherweise nicht die ideale Ziellösung für diesen Anwendungsfall. Nachdem die Daten im Wissensspeicher gespeichert wurden, kann Data Factory sie in andere Systeme wie Datenbanken exportieren.

Abfrage-Engine

Nachdem ein Index erstellt wurde, können Sie ihn mit der Volltext- und semantischen Suche von Azure Cognitive Search abfragen.

• Die Volltextsuche basiert auf der Apache Lucene-Abfrage-Engine und akzeptiert in einem Suchparameter übergebene Begriffe und Ausdrücke in allen suchbaren Feldern des Index. Wenn übereinstimmende Begriffe gefunden werden, bewertet die Abfrage-Engine die Dokumente nach Relevanz und gibt die obersten Ergebnisse zurück. Die Dokumentbewertung kann über Bewertungsprofile angepasst werden, und Ergebnisse können mithilfe von indizierbaren Feldern sortiert werden.
• Die semantische Suche bietet eine Reihe leistungsstarker Features, die die Qualität der Suchergebnisse verbessern, indem semantische Relevanz und Sprachverständnis verwendet werden. Wenn die semantische Suche aktiviert ist, wird die Suchfunktion folgendermaßen erweitert:
  • Semantische Neubewertung verwendet Kontext oder semantische Bedeutung, um einen neuen Relevanzscore für vorhandene Ergebnisse zu berechnen.
  • Semantische Highlights extrahiert Sätze und Ausdrücke aus einem Dokument, die den Inhalt am besten zusammenfassen.

Der Abschnitt Benutzeroberfläche enthält ein Beispiel für die Leistungsfähigkeit der semantischen Suche. Die semantische Suche befindet sich derzeit in der Public Preview. Weitere Informationen zu ihren Funktionen finden Sie in der Dokumentation.

Automatische Erstellung von Suchressourcen

Die Entwicklung einer Suchlösung ist ein iterativer Vorgang. Nachdem Sie die Azure Cognitive Search-Infrastruktur und die anfängliche Version von Suchressourcen wie Datenquelle, Index, Indexer und Skillset bereitgestellt haben, verbessern Sie Ihre Lösung kontinuierlich, etwa durch Hinzufügen und Konfigurieren von KI-Skills.

Um Konsistenz und schnelle Iterationen sicherzustellen, wird empfohlen, die Erstellung der Azure Cognitive Search-Ressourcen zu automatisieren.

Für unsere Lösung verwenden wir die REST-API von Azure Cognitive Search, um zehn Ressourcen auf automatisierte Weise bereitzustellen, wie in dieser Abbildung gezeigt:

Da unsere Lösung unterschiedliche Verarbeitungs- und KI-Anreicherungen für E-Mails, Transkriptionen und Nachrichtendokumente erfordert, erstellen wir verschiedene Datenquellen, Indexer und Skillsets. Wir haben jedoch beschlossen, einen einzigen Index für alle Kanäle zu verwenden, um die Verwendung der Risikoanalyselösung zu vereinfachen.

Jedes der zehn Elemente weist eine zugeordnete JSON-Definitionsdatei auf, in der seine Konfiguration angegeben ist. Weitere Informationen zu den Einstellungen finden Sie in den Beispielcodefeldern in diesem Leitfaden.

Die JSON-Spezifikationen werden über API-Anforderungen des Skripts „build-search-config.py“ in der angezeigten Reihenfolge an Azure Cognitive Search gesendet. Im folgenden Beispiel wird veranschaulicht, wie Sie das E-Mail-Skillset erstellen, das in „email-skillset.json“ angegeben ist:

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 ist der Name der Azure Cognitive Search-Ressource.
• cog_search_admin_key ist der Administratorschlüssel. Die Verwendung eines Abfrageschlüssels ist für Verwaltungsvorgänge nicht ausreichend.

Nachdem alle Konfigurationsanforderungen ausgeführt wurden und der Index geladen wurde, wird mithilfe einer REST-Abfrage ermittelt, ob die Suchlösung ordnungsgemäß reagiert. Beachten Sie, dass es eine Zeitverzögerung gibt, bevor alle Ressourcen generiert wurden und die anfängliche Ausführung der Indexer abgeschlossen ist. Möglicherweise müssen Sie einige Minuten warten, bevor Sie zum ersten Mal eine Abfrage ausführen.

Informationen zur Verwendung der Azure Cognitive Search-REST-API zum programmgesteuerten Erstellen der Konfiguration für das Indizieren von Blob Storage-Inhalten finden Sie unter Tutorial: Verwenden von REST und KI zum Generieren von durchsuchbarem Inhalt über Azure-Blobs.

KI-Anreicherungen

In den vorherigen Abschnitten wurde die Grundlage der Risikoanalyselösung aufgebaut. Jetzt ist es an der Zeit, die Verarbeitung von Informationen aus unformatierten Inhalten in konkrete Geschäftserkenntnisse zu betrachten.

Um den Inhalt durchsuchbar zu machen, durchläuft der Kommunikationsinhalt eine Pipeline von KI-Anreicherungen, die integrierte Skills und benutzerdefinierte Modelle für die Risikoerkennung verwenden:

Zunächst wird die Verwendung von integrierten Skills basierend auf den für die Risikoanalyselösung verwendeten Beispielskills 1 bis 4 untersucht. Anschließend wird gezeigt, wie Sie einen benutzerdefinierten Skills zum Integrieren von Risikomodellen hinzufügen (Schritt 5). Schließlich wird das Überprüfen und Debuggen der Skillpipeline betrachtet.

Die folgenden Abschnitte bieten eine konzeptionelle Einführung. Eine praktische Erfahrung finden Sie im ausführlichen Leitfaden zu Microsoft Learn.

Integrierte Skills zur KI-Anreicherung

Die Pipeline von angewandten KI-Anreicherungen wird als Azure Cognitive Search-Skillset bezeichnet. Die folgenden integrierten Skills werden in der Risikoanalyselösung verwendet:

• Optische Zeichenerkennung: Finanzberichte können eine beträchtliche Menge von Inhalten aufweisen, die in Bilder eingebettet sind und nicht als Text vorliegen, um Änderungen an den Inhalten zu verhindern. Die folgende Präsentation zeigt ein Beispiel aus einem Microsoft-Quartalsbericht:

  

  Alle Folien des Decks enthalten ausschließlich Grafikinhalte. Um die Informationen nutzen zu können, wird der kognitive Skill „OCR“ für E-Mails (insbesondere relevant für Anlagen) und Marktnachrichtendokumente verwendet. Dadurch wird sichergestellt, dass Suchabfragen wie „Kapitalausgaben“ im vorherigen Beispiel den Text aus der Folie einschließen, obwohl der ursprüngliche Inhalt nicht maschinenlesbar ist. Die Suchrelevanz wird durch die semantische Suche weiter verbessert, wenn Benutzer*innen abweichende Begriffe für „Kapitalausgaben“ verwenden, die nicht im Text enthalten sind.

• Spracherkennung: In einer globalen Organisation ist die Unterstützung für maschinelle Übersetzung eine gängige Anforderung. Wenn etwa das Team von Complianceanalyst*innen es vorzieht, konsistent in englischer Sprache zu lesen und zu kommunizieren, muss die Lösung in der Lage sein, die Inhalte genau zu übersetzen. Mithilfe des kognitive Skills „Spracherkennung“ wird die Sprache des Originaldokuments identifiziert. Mithilfe diese Angabe wird ermittelt, ob eine Übersetzung in die gewünschte Zielsprache erforderlich ist, und sie wird auf der Benutzeroberfläche angezeigt, um den Benutzer*innen die Originalsprache anzugeben.

• Extrahieren von Personen und Organisationen: Der kognitive Skill „Entitätserkennung“ kann Personen, Standorte, Organisationen und andere Entitäten in unstrukturiertem Text identifizieren. Mithilfe dieser Informationen kann die Suche oder die Navigation über eine große Menge heterogener Inhalte verbessert werden, z. B. durch Filtern und Facettieren. Für die Risikoanalyselösung wurde die Extraktion von Personen (z. B. Händlernamen) und Organisationen (z. B. Firmennamen) ausgewählt.

  Das folgende Beispiel aus der JSON-Definition des Skillsets für E-Mails enthält Details zur ausgewählten Konfiguration:

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

  Zunächst wird die Extraktion von Personen und Organisationen aus dem Inhalt angegeben. Es sind weitere Kategorien vorhanden (z. B. Standorte), die bei Bedarf extrahiert werden können. Hier wurde jedoch absichtlich die Extraktion auf diese beiden Entitäten beschränkt, um zu vermeiden, dass Benutzer*innen am Anfang durch zu umfangreiche Informationen überwältigt werden.

  Da keine KI-Lösung eine Genauigkeit von 100 % bietet, besteht immer ein Risiko falsch positiver (z. B. Organisationsnamen, die eigentlich keine Organisationen darstellen) und falsch negativer Ergebnisse (z. B. übersehene Organisationen). Azure Cognitive Search bietet Steuerelemente zum Ausgleich des Signal-Rausch-Verhältnisses bei der Extraktion von Entitäten. In unserem Fall wird die minimale Genauigkeit für die Erkennung auf 0,85 festgelegt, um die Erkennungsrelevanz zu verbessern und das Rauschen zu verringern.

  Im nächsten Schritt werden die Eingaben und Ausgaben für das Skillset im angereicherten Dokuments angegeben. Der Eingabepfad verweist auf merged_content, also E-Mails und Anlagen. Die Anlagen enthalten Text, der mithilfe von OCR extrahiert wurde.

  Schließlich werden die Ausgabenamen Personen und Organisationen für die angegebenen Entitäten definiert. Später werden diese dem Suchindex als Teil der Indexerdefinition zugeordnet.

  Die Definitionen der anderen Skills folgen einem ähnlichen Muster, ergänzt durch skillspezifische Einstellungen.

• Übersetzung: Die eigentliche Übersetzung von Dokumenten, die Fremdsprachen enthalten, in englische Sprache wird im nächsten Schritt ausgeführt. Zur Konvertierung wird der kognitive Skill „Textübersetzung“ verwendet. Beachten Sie, dass Übersetzungsgebühren ausgewertet werden, wenn Text an die Textübersetzungs-API gesendet wird, auch wenn die Quell- und Zielsprache identisch sind. Um unter diesen Umständen Dienstgebühren zu vermeiden, werden zusätzliche bedingte kognitive Skills verwendet, um eine Übersetzung in solchen Fällen zu umgehen.

Benutzerdefinierte KI-Anreicherungen für die Risikoerkennung

Nachdem Sie nun die gewünschten integrierten Skills aus Azure Cognitive Search implementiert haben, wird betrachtet, wie Sie benutzerdefinierte Modelle für die Risikoanalyse hinzufügen.

Das Identifizieren beabsichtigten oder tatsächlichen Fehlverhaltens in Kommunikationsinhalten ist immer kontextabhängig und erfordert umfangreiche Domänenkenntnisse. Ein wesentliches Ziel der Risikoanalyselösung besteht darin, benutzerdefinierte Risikomodelle flexibel in die Anreicherungspipeline zu integrieren und anzuwenden, um echte Risiken für spezifische Geschäftsszenarien aufzudecken.

Je nach Anwendungsfall kann das folgende Unterhaltungsbeispiel auf ein potenziell beabsichtigtes Fehlverhalten hinweisen:

Die folgenden Optionen können unstrukturierte Kommunikationsinhalte analysieren, um Risiken zu identifizieren:

• Schlüsselwortbasierter Ansatz: Diese Technik verwendet eine Liste relevanter Schlüsselwörter (z. B. offline, besondere Erkenntnisse), um potenzielle Risiken zu identifizieren. Dieser Ansatz ist einfach zu implementieren, kann aber zu übersehenen Risiken führen, wenn die Formulierungen im Inhalt nicht mit den Schlüsselwörtern übereinstimmen.
• Entitätserkennungsbasierte Ansätze: Ein Machine Learning-Modell wird auf kurze Äußerungen (z. B. Sätze) trainiert, um Risiken mithilfe eines Sprachmodells zu identifizieren. Durch Fachwissen wird ein Trainingssatz repräsentativer Beispiele mit der entsprechenden Risikoklassifizierung (z. B. Marktmanipulation, Insiderhandel) erstellt. Ein wichtiger Vorteil dieser Technik ist, dass Risiken wahrscheinlich identifiziert werden, wenn die Äußerungen eine ähnliche semantische Bedeutung haben, aber in den Formulierungen von den Beispielen im Trainingssatz abweichen. Für solche Zwecke kann der Azure Conversational Language Understanding-Dienst verwendet werden.
• Erweiterte NLP-basierte Ansätze: Die jüngsten Fortschritte in neuronalen Netzen ermöglichen es, längere Segmente von unstrukturiertem Text zu analysieren, einschließlich Klassifizierung und anderer NLP-Aufgaben. Dieser Ansatz kann Signale identifizieren, die subtiler sind und mehrere Sätze oder Absätze umfassen. Der Nachteil dieses Ansatzes besteht darin, dass im Vergleich zu anderen Techniken in der Regel wesentlich mehr Trainingsdaten erforderlich sind. Azure bietet mehrere Optionen zum Trainieren von NLP-Modellen, einschließlich benutzerdefinierter Textklassifizierung und automatisierten maschinellen Lernens.

Jedes Modell, das als REST-Webdienst bereitgestellt wird, kann als benutzerdefinierter Skill in die Azure Cognitive Search-Risikoanalyselösung integriert werden. In unserem Beispiel wird eine Reihe von Conversational Language Understanding-Modellen mit einer Azure-Funktion integriert, die eine Schnittstelle zwischen Azure Cognitive Search und den Modellen darstellt. Diese Technik wird im folgenden Diagramm veranschaulicht:

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

E-Mails und Transkriptionen werden nach der Verarbeitung der integrierten Skills auf Risiken überprüft. Der benutzerdefinierte Skill stellt den Dokumenttyp und dessen Inhalt für die Azure Functions-App zur Vorverarbeitung bereit. Die App basiert auf dem veröffentlichten Beispiel und führt die folgenden Aufgaben aus:

1. Festlegung der zu verwendenden Modelle: Organisationen verwenden möglicherweise spezielle Modelle, um verschiedene Arten von Risiken zu identifizieren (z. B. Marktmanipulation, Insiderhandel, Investmentfondsbetrug). Die Funktions-App aktiviert die verfügbaren Modelle abhängig von den konfigurierten Einstellungen.
2. Vorverarbeitung von Inhalten: Diese Aufgabe umfasst das Verwerfen von Anlageninhalten und das Teilen des Texts in Sätze entsprechend der Struktur der Daten, die zum Trainieren der Risikomodelle verwendet werden.
3. Senden des in Token zerlegten Inhalts an die konfigurierten Risikomodelle: Die Risikomodelle weisen den einzelnen Sätzen Risikoscores zu.
4. Aggregieren und Bewerten der Ergebnisse: Dies erfolgt vor der Rückgabe an das Skillset. Der Dokumentrisikoscore ist das höchste Risiko aller enthaltenen Sätze. Der identifizierte Satz mit dem höchsten Risiko wird auch für die Anzeige auf der Benutzeroberfläche zurückgegeben. Außerdem werden Dokumentrisiken anhand des Scores als niedriges, mittleres oder hohes Risiko klassifiziert.
5. Schreiben von Informationen in den Azure Cognitive Search-Index: Die Informationen werden auf der Benutzeroberfläche für Complianceanalyst*innen und im Wissensspeicher verwendet. Sie schließen alle Kommunikationsinhalte, die integrierten Anreicherungen und die Ergebnisse der benutzerdefinierten Risikomodelle ein.

Das folgende JSON-Beispiel veranschaulicht die Definition der Schnittstelle zwischen Azure Cognitive Search und der Funktions-App (die die Risikomodelle aufruft) als benutzerdefinierter Skill:

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

Der URI gibt die Webadresse der Funktions-App an, die die folgenden Eingaben von Azure Cognitive Search abruft:

• text enthält den Inhalt in englischer Sprache.
• doc_type wird verwendet, um zwischen Transkriptionen, E-Mails und Marktnachrichten zu unterscheiden – diese erfordern unterschiedliche Vorverarbeitungsschritte.

Nachdem die Funktions-App die Risikoscores aus dem Conversational Language Understanding-Feature von Azure Cognitive Service für Language erhalten hat, gibt sie die konsolidierten Ergebnisse an Azure Cognitive Search zurück.

Finanzdienstleistungsorganisationen benötigen einen modularen Ansatz für die flexible Kombination vorhandener und neuer Risikomodelle. Daher wird keine Hartcodierung bestimmter Modelle durchgeführt. Stattdessen ist risk_models ein komplexer Datentyp, der Details für jeden Risikotyp zurückgibt (z. B. Insiderhandel), einschließlich des Risikoscores und des identifizierten Satzes mit dem höchsten Risikoscore. Compliance und Rückverfolgbarkeit sind wichtige Aspekte für Finanzdienstleistungsorganisationen. Risikomodelle werden jedoch ständig verbessert (z. B. durch Nutzung neuer Trainingsdaten), sodass sich die Vorhersagen für ein Dokument im Lauf der Zeit ändern können. Um die Rückverfolgbarkeit zu gewährleisten, wird mit jeder Vorhersage auch die genaue Version des Risikomodells zurückgegeben.

Die Architektur kann wiederverwendet werden, um erweiterte NLP-Modelle zu integrieren (z. B. zum Ermöglichen der Identifizierung subtilerer Risikosignale, die mehrere Äußerungen umfassen können). Die wichtigste Anpassung besteht darin, den Vorverarbeitungsschritt in der Funktions-App mit der Vorverarbeitung für das Training des NLP-Modells abzugleichen.

Debuggen von KI-Anreicherungspipelines

Das Verständnis von Informationsflows und KI-Anreicherungen kann für große Skillsets schwierig sein. Azure Cognitive Search bietet hilfreiche Funktionen zum Debuggen und Visualisieren der Anreicherungspipeline, einschließlich der Eingaben und Ausgaben der Skills.

Das Flussdiagramm wurde der Registerkarte Debugsitzungen der Azure Cognitive Search-Ressource im Azure-Portal entnommen. Er fasst den Anreicherungsflow zusammen, da der Inhalt nach und nach durch die integrierten Skills und die benutzerdefinierten Risikomodelle in einem Skillset verarbeitet wird.

Der Verarbeitungsflow im Skilldiagramm wird von Azure Cognitive Search basierend auf den Eingabe- und Ausgabekonfigurationen der Skills automatisch generiert. Das Diagramm zeigt auch den Grad der Parallelität bei der Verarbeitung.

Ein bedingter Skill wird verwendet, um den Dokumenttyp (E-Mail, Transkription oder Nachrichten) zu identifizieren, da diese in späteren Schritten unterschiedlich verarbeitet werden. Bedingte Skills werden verwendet, um Übersetzungsgebühren für Fälle zu vermeiden, in denen die Ausgangs- und die Zielsprache identisch sind.

Zu den integrierten Skills gehören OCR, Spracherkennung, Entitätserkennung, Übersetzung und Textzusammenführung, mit der ein eingebettetes Bild durch eingebettete OCR-Ausgabe im ursprünglichen Dokument ersetzt wird.

Der letzte Skill in der Pipeline ist die Integration der Conversational Language Understanding-Risikomodelle über die Funktions-App.

Schließlich werden die ursprünglichen und angereicherten Felder indiziert und dem Azure Cognitive Search-Index zugeordnet.

Der folgende Auszug aus einer Suchantwort zeigt ein Beispiel für die Erkenntnisse, die mithilfe von angereicherten Inhalten und semantischer Suche erlangt werden können. Der Suchbegriff lautet „how were capex“ (für „Wie entwickelten sich Kapitalausgaben während des Berichtszeitraums?“).

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

Benutzeroberfläche

Nach dem Implementieren eine Suchlösung können Sie den Index direkt über das Azure-Portal abfragen. Diese Option ist zwar gut für das Lernen, Experimentieren und Debuggen geeignet, bietet aber keine gute Endbenutzererfahrung.

Eine angepasste Benutzeroberfläche, die auf das Benutzererlebnis ausgelegt ist, kann den wahren Wert der Suchlösung sinnvoll zeigen und es Organisationen ermöglichen, Risikokommunikation in verschiedenen Kanälen und Quellen zu identifizieren und zu überprüfen.

Der Solution Accelerator für Knowledge Mining bietet eine Azure Cognitive Search-Benutzeroberflächenvorlage in Form einer .NET Core MVC-Web-App, die verwendet werden kann, um schnell einen Prototypen für die Abfrage und Anzeige der Suchergebnisse zu erstellen.

In wenigen Schritten kann die Benutzeroberfläche der Vorlage so konfiguriert werden, dass sie den Suchindex verbindet und abfragt und eine einfache Webseite erzeugt, auf der die Ergebnisse durchsucht und visualisiert werden können. Diese Vorlage kann weiter angepasst werden, um den Abruf und die Analyse der Risikokommunikation zu verbessern.

Der folgende Screenshot zeigt eine Beispielbenutzeroberfläche für das Risikoszenario, erstellt durch Anpassen der Azure Cognitive Search-Benutzeroberflächenvorlage. Diese Benutzeroberfläche zeigt eine Möglichkeit zum Anzeigen der Suchlösung, indem sie eine intuitive Ansicht der kanalübergreifenden Kommunikation und der Risikoinformationen bereitstellt.

Die Startseite bietet Interaktion mit der Suchlösung. Sie ermöglicht Benutzer*innen, Ergebnisse zu durchsuchen, zu optimieren, zu visualisieren und zu erkunden:

1. Die anfänglichen Ergebnisse werden aus einem Suchindex abgerufen und in tabellarischer Form angezeigt. Sie bieten somit einen einfachen Zugriff auf die Kommunikation und vereinfachen einen Vergleich der Ergebnisse.
   1. Wichtige Kommunikationsdetails sind für Benutzer*innen verfügbar, und Dokumente aus mehreren Kanälen (E-Mails, Transkriptionen, Nachrichten) werden in einer einzigen Ansicht konsolidiert.
   2. Scores aus den benutzerdefinierten Risikomodellen werden für die Kommunikation angezeigt, wobei höhere Risiken hervorgehoben werden können.
   3. In einer konsolidierten Risikoklassifizierung werden die Scores aus den benutzerdefinierten Risikomodellen aggregiert, sodass Ergebnisse basierend auf dem durchschnittlichen Risikoniveau sortiert werden können.
2. Ein Schwellenwert-Schieberegler bietet die Möglichkeit, die Risikoschwellenwerte zu ändern. Benutzerdefinierte Risikoscores, die den Schwellenwert überschreiten, werden hervorgehoben.
3. Eine Datumsbereichsauswahl bietet die Möglichkeit, den Zeitraum der Analyse zu erweitern oder nach historischen Ergebnissen zu suchen.
4. Die Suchergebnisse können mithilfe einer Reihe von Filtern eingeschränkt werden, z. B. nach Sprache oder Dokumenttyp. Diese Optionen werden als Funktion der im Index konfigurierten facettierbaren Felder dynamisch auf der Benutzeroberfläche generiert.
5. Eine Suchleiste bietet die Möglichkeit, den Index nach bestimmten Begriffen oder Ausdrücken zu durchsuchen.
6. Die semantische Suche ist verfügbar. Benutzer*innen können zwischen Standard- und Semantiksuche wechseln.
7. Neue Kommunikation kann direkt über die Benutzeroberfläche hochgeladen und indiziert werden. Für jedes Dokument wird außerdem eine Detailseite bereitgestellt:

Die Detailseite bietet Zugriff auf den Inhalt der Kommunikation und auf Anreicherungen und Metadaten:

8. Die bei der Dokumententschlüsselung extrahierten Inhalte werden angezeigt. Einige Dateien wie PDFs können direkt auf der Detailseite angezeigt werden.
9. Die Ergebnisse der benutzerdefinierten Risikomodelle werden zusammengefasst.
10. Die wichtigsten im Dokument erwähnten Personen und Organisationen werden auf dieser Seite angezeigt.
11. Weitere Metadaten, die während der Indizierung erfasst wurden, können hinzugefügt und in zusätzlichen Registerkarten der Detailseite angezeigt werden.

Wenn nicht englische Inhalte erfasst werden, können Benutzer*innen diese in der ursprünglichen Sprache oder in Englisch überprüfen. Auf der Registerkarte Transkript der Detailseite werden der ursprüngliche Inhalt und der übersetzte Inhalt nebeneinander angezeigt. Dies zeigt, dass beim Indizierungsvorgang beide Sprachen beibehalten werden, sodass beide auf der Benutzeroberfläche genutzt werden können.

Schließlich können Benutzer*innen semantische Suchvorgänge ausführen. Im nächsten Beispiel wird das wichtigste Ergebnis gezeigt, in dem der Ausdruck „how were capex“ (für „Wie entwickelten sich Kapitalausgaben während des Berichtszeitraums?“) mithilfe der semantischen Suche durchsucht wurde.

Eine entsprechende Suche im Volltextmodus führt zur Suche nach einer exakten Übereinstimmung für „capex“, die im Dokument nicht vorkommt. Durch die semantische Funktion kann die Abfrage-Engine jedoch erkennen, dass „capex“ sich auf „capital expenditures“, also „Kapitalausgaben“ bezieht, sodass diese Kommunikation als die relevanteste identifiziert wird. Darüber hinaus generiert die semantische Suche semantische Highlights (12), in denen das Dokument mit den relevantesten Sätzen zusammengefasst wird.

Empfehlungen

In diesem Abschnitt werden bewährte organisatorische und technische Methoden für die Entwicklung Ihrer Compliance-Risikoanalyselösung zusammengefasst.

Einbeziehen von erforderlichen Beteiligten: Die Implementierung einer Risikoanalyselösung ist eine multidisziplinäre Übung, die wichtige Beteiligte aus verschiedenen Domänen einbezieht. Gehen Sie davon aus, dass die zuvor eingeführten projektbezogenen und andere Rollen von der Lösung betroffen sind.

Sicherstellen einer angemessenen Einführung und eines Change Management: Die Automatisierung von Risikoanalysemethoden verursacht wahrscheinlich erhebliche Änderungen an der Arbeitsweise der Mitarbeiter*innen. Obwohl die Lösung einen Mehrwert mit sich bringt, können Änderungen an jedem Workflow eine Herausforderung darstellen und dadurch zu langen Einführungszeiträumen und eventuell zu Widerstand führen. Als bewährte Methode wird empfohlen, betroffene Mitarbeiter*innen frühzeitig einzubeziehen. Ziehen Sie das Prosci ADKAR-Einführungsmodell in Betracht, das auf fünf wichtigen Schritten einer Technologieeinführungsjourney beruht: Bewusstsein (Awareness), Wunsch (Desire), Wissen (Knowledge), Fähigkeit (Ability), Verstärkung (Reinforcement).

Verwendung mehrerer Kanäle zum Aufdecken von Risiken: Jeder Kommunikationskanal (z. B. E-Mail, Chats, Telefonie) kann einzeln untersucht werden, um potenzielle Risiken zu erkennen. Bessere Erkenntnisse werden jedoch durch die Kombination heterogener Kanäle formaler (z. B. E-Mail) und weniger formaler Kommunikation (z. B. Chats) erzielt. Darüber hinaus kann durch die Integration ergänzender Informationen (z. B. Marktnachrichten, Unternehmensberichte, SEC-Anmeldungen) zusätzlicher Kontext für die Complianceanalyse bereitgestellt werden (z. B. Informationen zu einer bestimmten Initiative eines Unternehmens).

Einfacher Anfang und Iteration: Azure Cognitive Search bietet umfassende integrierte KI-Anreicherungen basierend auf verschiedenen Cognitive Services. Es kann verlockend sein, sofort viele dieser Funktionen hinzuzufügen. Die Anzahl der Entitäten oder Schlüsselausdrücke, die extrahiert werden können, kann jedoch bei mangelnder Kontrolle die Endbenutzer*innen überwältigen. Der Beginn mit einer reduzierten Gruppe von Skills oder Entitäten kann sowohl Benutzer*innen als auch Entwickler*innen helfen, zu verstehen, welche den größten Nutzen bringen.

Verantwortungsvolle Innovation: Die Entwicklung von KI-Lösungen erfordert eine hohe Verantwortung von allen Beteiligten. Microsoft nimmt den verantwortungsvollen Einsatz von künstlicher Intelligenz sehr ernst und hat ein Framework von Kerndesignprinzipien entwickelt:

• Fairness
• Zuverlässigkeit und Sicherheit
• Datenschutz und -sicherheit
• Inklusion
• Transparenz und Verantwortlichkeit

Die Auswertung der Kommunikation der Mitarbeiter*innen erfordert besondere Aufmerksamkeit und bringt ethische Bedenken mit sich. In einigen Ländern/Regionen unterliegt die automatisierte Überwachung von Mitarbeiter*innen strengen gesetzlichen Beschränkungen. Machen Sie aus allen diesen Gründen verantwortungsbewusste Innovation zu einem Stützpfeiler Ihres Projektplans. Microsoft bietet für diesen Zweck verschiedene Frameworks und Tools an. Weitere Informationen finden Sie am Ende dieses Abschnitts im Feld Tipp.

Automatisieren Ihrer Entwicklungsiterationen: Der Datenimport-Assistent erleichtert den Einstieg, aber für komplexere Lösungen und produktive Anwendungsfälle wird empfohlen, Ressourcen wie Datenquellen, Indexer, Indizes und Skillsets als Code zu erstellen. Automatisierung beschleunigt die Entwicklungszyklen deutlich und gewährleistet eine konsistente Bereitstellung in der Produktion. Die Ressourcen werden im JSON-Format angegeben. Sie können JSON-Definitionen aus dem Portal kopieren, nach Bedarf ändern und dann im Anforderungstext von Aufrufen an die Azure Cognitive Search-REST-APIs angeben.

Auswählen des passenden NLP-Ansatzes für die Risikoanalyse: Möglichkeiten zum Identifizieren von Risiken in unstrukturiertem Text reichen von der grundlegenden Schlüsselwortsuche und Entitätsextraktion bis hin zu leistungsstarken modernen NLP-Architekturen. Die beste Auswahl hängt von der Menge und Qualität der vorhandenen Trainingsdaten für den jeweiligen Anwendungsfall ab. Wenn begrenzte Trainingsdaten vorhanden sind, können Sie ein auf Äußerungen basierendes Modell mithilfe des Conversational Language Understanding-Features von Azure Cognitive Service für Language trainieren. Vorhandene Unterhaltungen können überprüft werden, um Sätze zu identifizieren und zu bezeichnen, die auf relevante Risikotypen hinweisen. Manchmal sind weniger als Hundert Stichproben ausreichend, um ein Modell mit guten Ergebnissen zu trainieren.

In Fällen, in denen die Risikoanzeichen subtiler sind und sich über mehrere Sätze erstrecken, ist das Training eines hochmodernen NLP-Modells wahrscheinlich die bessere Wahl. Dieser Ansatz erfordert jedoch in der Regel deutlich mehr Trainingsdaten. Es empfiehlt sich, wenn möglich reale Daten zu verwenden, wenn sich die Lösung in der Produktion befindet. Dadurch können Anpassungen für potenzielle Fehleinschätzungen vorgenommen und das Modell kontinuierlich neu trainiert werden, um seine Leistung nach und nach zu verbessern.

Anpassen der Benutzeroberfläche an Ihre spezifischen Anforderungen: Eine funktionsstarke Benutzeroberfläche kann den gesamtem Wert von Azure Cognitive Search und den KI-Anreicherungen zur Verfügung stellen. Die Azure KI Search Benutzeroberflächen-Vorlage bietet zwar eine einfache und schnelle Möglichkeit zum Implementieren einer anfänglichen Webanwendung, sie muss jedoch wahrscheinlich angepasst werden, um zusätzliche Features zu integrieren. Sie muss außerdem die verarbeiteten Kommunikationsarten, die verwendeten Arten von KI-Anreicherungen und eventuelle weitere Geschäftsanforderungen berücksichtigen. Kontinuierliche Zusammenarbeit und wiederholte Durchläufe mit Front-End-Entwickler*innen, Geschäftsbeteiligten und Endbenutzer*innen helfen dabei, den Wert der Lösung zu verbessern, indem die Suche und die Überprüfung relevanter Kommunikation für Benutzer*innen optimiert werden.

Optimieren der Kosten für Übersetzungsdienste: Standardmäßig durchlaufen alle Dokumente die KI-Anreicherungspipeline. Das bedeutet, dass englischsprachige Dokumente auch dann an den Übersetzungsdienst übergeben werden, wenn eigentlich keine Übersetzung erforderlich ist. Da der Inhalt von der Übersetzungs-API verarbeitet wird, fallen jedoch dennoch Gebühren an. In unserer Lösung wird die Spracherkennung in Verbindung mit bedingten Skills verwendet, um Übersetzungen in diesen Fällen zu vermeiden. Wenn die erkannte Sprache des ursprünglichen Dokuments nicht Englisch ist, wird der Inhalt in ein bestimmtes Feld für nicht englische Inhalte kopiert und dann an den Übersetzungsdienst übergeben. Ist das Dokument in englischer Sprache gehalten, bleibt dieses Feld leer, und es werden keine Übersetzungsgebühren generiert. Schließlich werden alle Inhalte (ursprünglich englisch oder übersetzt) in einem gemeinsamen Feld für die weitere Verarbeitung zusammengeführt. Sie können auch die Zwischenspeicherung aktivieren, um vorhandene Anreicherungen wiederzuverwenden.

Sicherstellen der Verfügbarkeit und Skalierbarkeit Ihrer Produktionsumgebung: Nachdem Sie vom Proof of Concept in die Produktionsplanung wechseln, müssen Sie Verfügbarkeit und Skalierbarkeit berücksichtigen, um die Zuverlässigkeit und Leistung Ihrer Suchlösung sicherzustellen. Instanzen des Suchdiensts werden als Replikate bezeichnet und zum Lastenausgleich bei Abfragevorgängen verwendet. Fügen Sie Replikate für Hochverfügbarkeit und erhöhte Abfrageleistung hinzu. Verwenden Sie Partitionen, um die Skalierbarkeit Ihrer Lösung zu verwalten. Partitionen stellen physischen Speicher dar und weisen bestimmte Merkmale für Größe und E/A auf. Weitere Hinweise zum Verwalten von der Kapazität und anderer Dienstverwaltungsaspekte finden Sie in der Dokumentation.

Zusammenfassung

In diesem Leitfaden finden Sie umfassende Anleitungen zum Einrichten einer Lösung, die mithilfe von KI nach Anzeichen von Betrug sucht. Das Konzept lässt sich auch auf andere regulierte Branchen wie Gesundheitsversorgung oder Behörden übertragen.

Sie können die Architektur erweitern, sodass andere Datenquellen und KI-Funktionen wie die folgenden enthalten sind:

• Erfassen strukturierter Daten, z. B. Marktdaten (etwa Aktienkurse) und Transaktionsinformationen.
• Anfügen von speziellen Klassifizierungsmodellen zum Extrahieren von Inhalten aus papierbasierten Quellen durch Verwenden von Funktionen wie der Azure-Formularerkennung und der Azure-Lese-API.
• Erfassen von Informationen aus sozialen Netzwerken mithilfe von Azure Language Studio-Funktionen zum Kategorisieren und Filtern relevanter Themen oder der Azure-Standpunktanalyse zum Erfassen von Meinungstrends.
• Zusammenführen und Konsolidieren von Informationen aus Microsoft 365 mithilfe von Microsoft Graph, z. B. zwischenmenschliche Interaktionen, Unternehmen, mit denen Personen arbeiten, oder Informationen, auf die sie zugreifen. Wenn Sie diese Daten in Azure Storage speichern, können Sie sie einfach durchsuchen.

Die der Lösung zugrunde liegende Technologie, Azure Cognitive Search, ist die beste Wahl, da sie Knowledge Mining, Katalogsuche und Suche in der App unterstützt. Das Bereitstellen von mehreren Datenquellen und das Herstellen einer Verbindung mit diesen sowie das Bereitstellen integrierter und erweiterbarer KI für die Inhaltsverarbeitung sind einfache Vorgänge. Es stehen Funktionen wie die semantische Suche zur Verfügung, die durch Deep Learning unterstützt werden und Absichten der Benutzer*innen ableiten sowie die relevantesten Ergebnisse anzeigen und bewerten können.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Andreas Kopp | Senior Cloud Solution Architect
• João Pedro Martins | Senior Cloud Solution Architect Manager
• Carlos Alexandre Santos | Senior Cloud Solution Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Schnellstart: Erstellen eines Index für Azure Cognitive Search im Azure-Portal

Zugehörige Ressourcen

• Knowledge Mining für Kundensupport und Feedbackanalyse
• Technologie zur Verarbeitung von natürlicher Sprache
• Umfangreiche Verarbeitung von benutzerdefinierten natürlichen Sprachen
• Knowledge Mining für die Inhaltsrecherche