DE112022000915T5

DE112022000915T5 - Erstellen eines statistischen modells und auswerten der modellleistung

Info

Publication number: DE112022000915T5
Application number: DE112022000915.2T
Authority: DE
Inventors: William Francis Bradley; Katherine Esther Dalis
Original assignee: Cambridge Mobile Telematics Inc
Current assignee: Cambridge Mobile Telematics Inc
Priority date: 2021-01-29
Filing date: 2022-01-28
Publication date: 2023-11-16
Also published as: US20220245492A1; WO2022165152A1

Abstract

Ein Verfahren zum Erstellen und Auswerten eines statistischen Modells umfasst ein Empfangen, durch ein Datenverarbeitungssystem, von Telematikdaten und Versicherungsanspruchsdaten für eine Population von Fahrern. Ein Trainingsdatensatz wird auf der Grundlage der Telematikdaten generiert, der Werte für eine aus den Telematikdaten abgeleitete Proxy-Variable, und Werte für ein oder mehrere aus den Telematikdaten abgeleitete Merkmale umfasst. Ein Testdatensatz wird auf der Grundlage der Telematikdaten und der Anspruchsdaten generiert, der Werte für eine aus den Anspruchsdaten abgeleitete Proxy-Variable und Werte für ein oder mehrere aus den Telematikdaten abgeleitete Merkmale umfasst. Ein statistisches Modell wird unter Verwendung des Trainingsdatensatzes generiert, wobei das statistische Modell dazu ausgelegt ist, Werte der Proxy-Variable aus Werten des einen oder der mehreren Merkmale vorherzusagen. Das statistische Modell wird unter Verwendung des Testdatensatzes validiert.

Description

TECHNISCHES GEBIET
Diese Offenbarung betrifft im Allgemeinen Techniken zum Erstellen und Auswerten statistischer Modelle.
HINTERGRUND
Ein statistisches Modell ist ein mathematisches Modell, das eine Reihe von Annahmen hinsichtlich der Generierung beobachteter Daten verkörpert. Durch diese Annahmen kann ein statistisches Modell verwendet werden, um die Wahrscheinlichkeit eines konkreten Ergebnisses für eine gegebene Beobachtung (oder einen Satz von Beobachtungen) vorherzusagen. Aufgrund ihrer Vorhersagekraft finden statistische Modelle eine Vielfalt von Anwendungen in der Datenanalyse. Zum Beispiel werden in der Kraftfahrzeugversicherungsbranche statistische Modelle verwendet, um das von einem Fahrer ausgehende Risiko vorherzusagen, um den Preis für eine Kraftfahrzeugversicherungspolice für einen Fahrer zu bestimmen.
KURZDARSTELLUNG
In einem ersten Aspekt umfasst im Allgemeinen ein Verfahren: Empfangen, durch mindestens einen Prozessor, von Telematikdaten und Versicherungsanspruchsdaten für eine Population von Fahrern; Generieren, durch den mindestens einen Prozessor, eines Trainingsdatensatzes auf der Grundlage der Telematikdaten, wobei der Trainingsdatensatz umfasst: Werte für eine aus den Telematikdaten abgeleitete Proxy-Variable und Werte für ein oder mehrere aus den Telematikdaten abgeleitete Merkmale zum Vorhersagen der Proxy-Variable; Generieren, durch den mindestens einen Prozessor, eines Testdatensatzes auf der Grundlage der Telematikdaten und der Anspruchsdaten, wobei der Testdatensatz umfasst: Werte für eine aus den Anspruchsdaten abgeleitete Zielvariable, und Werte für das eine oder die mehreren aus den Telematikdaten abgeleiteten Merkmale; Generieren, durch den mindestens einen Prozessor, eines statistischen Modells unter Verwendung des Trainingsdatensatzes, wobei das statistische Modell derart ausgelegt ist, dass es Werte der Proxy-Variable aus Werten des einen oder der mehreren Merkmale vorhersagt; und Validieren, durch den mindestens einen Prozessor, des statistischen Modells unter Verwendung des Testdatensatzes.
In einem zweiten Aspekt, der mit dem ersten Aspekt kombiniert werden kann, umfasst im Allgemeinen das Validieren des statistischen Modells unter Verwendung des Testdatensatzes: Anwenden der Werte für das eine oder die mehreren Merkmale, die im Testdatensatz aufgenommen sind, auf das statistische Modell, um Werte für die Proxy-Variable für jeden Fahrer in der Population von Fahrern zu bestimmen; Bestimmen einer Verteilung der Werte für die Proxy-Variable für jeden Fahrer in der Population von Fahrern; und Abbilden der Werte für die Zielvariable im zweiten Datensatz auf die Verteilung.
In einem dritten Aspekt, der mit dem ersten oder dem zweiten Aspekt kombiniert werden kann, umfasst im Allgemeinen das Validieren des statistischen Modells unter Verwendung des Testdatensatzes: Generieren eines Lift-Diagramms, Berechnen einer Lift-Statistik, oder Berechnen einer Fläche unter einer ROC-Kurve (Receiver-Operator-Characteristic-Kurve, Operationscharakteristik eines Beobachters).
In einem vierten Aspekt, der mit einem von dem ersten bis dritten Aspekt kombiniert werden kann, umfassen im Allgemeinen die Werte für die Zielvariable, die im Testdatensatz aufgenommen sind, eine Anzahl von Versicherungsansprüchen für einen konkreten Expositionszeitraum oder Kosten von Versicherungsansprüchen für einen konkreten Expositionszeitraum.
In einem fünften Aspekt, der mit einem von dem ersten bis vierten Aspekt kombiniert werden kann, wird im Allgemeinen das Verfahren in einer ersten Recheninstanz ausgeführt, wobei das Verfahren ferner, in einer zweiten Recheninstanz, umfasst: Resampling des Trainingsdatensatzes mit Ersetzung, um einen resampelten Trainingsdatensatz zu erzeugen, wobei der resampelte Trainingsdatensatz Werte für die Proxy-Variable und Werte für das eine oder die mehreren Merkmale umfasst; Resampling des Testdatensatzes mit Ersetzung, um einen resampelten Testdatensatz zu erzeugen, wobei der resampelte Testdatensatz Werte für die Zielvariable und Werte für das eine oder die mehreren Merkmale umfasst; Generieren eines zweiten statistischen Modells unter Verwendung des resampelten Trainingsdatensatzes; und Auswerten des zweiten statistischen Modells unter Verwendung des resampelten Testdatensatzes, umfassend: Vergleichen einer Ausgabe des zweiten statistischen Modells mit einer Ausgabe des ersten statistischen Modells; und Bestimmen eines Konfidenzintervalls für die Ausgabe des ersten statistischen Modells zumindest teilweise auf der Grundlage des Vergleichs.
In einem sechsten Aspekt, der mit einem von dem ersten bis fünften Aspekt kombiniert werden kann, wird im Allgemeinen mindestens ein Abschnitt der Telematikdaten durch eine Telematikvorrichtung oder eine mobile Vorrichtung, die in einem Fahrzeug eines Fahrers in der Population von Fahrern angeordnet ist, erfasst.
In einem siebten Aspekt umfasst im Allgemeinen ein Verfahren: Empfangen, durch mindestens einen Prozessor, von Telematikdaten und Versicherungsanspruchsdaten für eine Population von Fahrern; Ableiten, durch den mindestens einen Prozessor, eines oder mehrerer Merkmale aus den Telematikdaten; Identifizieren, durch den mindestens einen Prozessor, einer Proxy-Variable aus dem einen oder den mehreren Merkmalen, wobei die Werte der Proxy-Variable einen Aufschluss über ein Fahrrisiko geben; Generieren, durch den mindestens einen Prozessor, eines Trainingsdatensatzes mit Spalten, die das eine oder die mehreren Merkmale und die Proxy-Variable repräsentieren, und Zeilen, die Werte für das eine oder die mehreren Merkmale und die Proxy-Variable für jeden Fahrer in der Population von Fahrern repräsentieren; Durchführen, durch den mindestens einen Prozessor, einer Regressionsanalyse auf dem Trainingsdatensatz, um ein statistisches Modell zu erzeugen, das das eine oder die mehreren Merkmale mit der Proxy-Variable in Beziehung setzt; und Auswerten, durch den mindestens einen Prozessor, des statistischen Modells durch Folgendes: Bestimmen, auf der Grundlage des Modells, einer Verteilung eines Fahrrisikos für die Population von Fahrern, und Abbilden der Anspruchsdaten auf die Verteilung, um ein relatives Risiko jedes Fahrers in der Population von Fahrern zu bestimmen.
In einem achten Aspekt umfasst im Allgemeinen ein Verfahren: Zugreifen, von einem Datendepot, auf Telematikdaten mit einer Mehrzahl von Feldern, wobei jedes Feld einen oder mehrere Werte umfasst, die ein ein Fahrzeug betreffendes Ereignis repräsentieren; Parsen, durch ein Datenverarbeitungssystem, von Feldern in den Telematikdaten, um ein oder mehrere spezifizierte Felder und einen oder mehrere entsprechende Werte zu identifizieren; Generieren eines Datensatzes mit Eingabewerten und Ausgabewerten, wobei die Eingabewerte Werte aus spezifizierten Feldern in den Telematikdaten sind, wobei die Ausgabewerte andere Werte aus anderen Feldern in den Telematikdaten sind, wobei die Ausgabewerte einen Proxy für eine Versicherungsanspruchseinreichung repräsentieren; Trainieren eines Modells, um ein Auftreten einer Einreichung eines Versicherungsanspruchs vorherzusagen, indem eine oder mehrere Regressionen an den Eingabe- und Ausgabewerten im Datensatz durchgeführt werden; Zugreifen, von einem Datendepot, auf Anspruchsdaten, die Versicherungsanspruchseinreichungen repräsentieren; Validieren des Modells durch Vergleichen der Anspruchsdaten mit einer Ausgabe des Modells, wobei bestimmt wird, dass das Modell validiert ist, wenn ein Fehler zwischen den Anspruchsdaten und der Ausgabe einen Schwellenwert erfüllt.
In einem neunten Aspekt umfasst im Allgemeinen ein Verfahren: Empfangen, durch mindestens einen Prozessor, eines oder mehrerer Parameter für ein Rechenexperiment, wobei der eine oder die mehreren Parameter ein oder mehrere Merkmale und einen oder mehrere Datensätze zum Generieren eines statistischen Modells umfassen; Generieren, durch den mindestens einen Prozessor, eines oder mehrerer Teilexperimente auf der Grundlage des Rechenexperiments, wobei jedes Teilexperiment eine Angabe eines konkreten Satzes des einen oder der mehreren Parameter umfasst, die im Teilexperiment anzuwenden sind; Generieren, durch den mindestens einen Prozessor, einer Warteschlange mit jedem des einen oder der mehreren Teilexperimente; Generieren, durch den mindestens einen Prozessor, einer oder mehrerer Recheninstanzen, die zum Folgenden ausgelegt sind: Empfangen eines Teilexperiments aus der Warteschlange; Generieren eines Trainingsdatensatzes und eines Testdatensatzes durch Resampling des einen oder der mehreren Datensätze mit Ersetzung; Generieren des statistischen Modells mit dem Trainingsdatensatz; Validieren des statistischen Modells mit dem Testdatensatz; Speichern einer oder mehrerer Ausgaben der Validierung in einem Speichersystem; Aggregieren der einen oder der mehreren im Speichersystem gespeicherten Ausgaben der Validierung, um eine aggregierte Ausgabe für das Rechenexperiment zu erzeugen; und Verarbeiten der aggregierten Ausgabe, um eine oder mehrere Leistungsmetriken für das statistische Modell zu generieren.
In einem zehnten Aspekt, der mit dem neunten Aspekt kombiniert werden kann, umfassen im Allgemeinen der eine oder die mehreren Parameter eine Spezifikation von Merkmalen aus dem einen oder den mehreren Merkmalen, die zur Vorhersage verwendet werden, eine Spezifikation einer Zielvariable aus dem einen oder den mehreren Merkmalen, eine Spezifikation einer Proxy-Variable aus dem einen oder den mehreren Merkmalen, oder einen Typ von Modell zum Generieren des statistischen Modells.
In einem elften Aspekt, der mit dem neunten oder dem zehnten Aspekt kombiniert werden kann, umfasst im Allgemeinen jede Instanz mehrere Verarbeitungspipelines, und jede Instanz empfängt ein Teilexperiment für jede verfügbare Pipeline der mehreren Verarbeitungspipelines.
In einem zwölften Aspekt, der mit einem von dem neunten bis elften Aspekt kombiniert werden kann, ist im Allgemeinen jede der einen oder der mehreren Recheninstanzen zum Folgenden ausgelegt: Bestimmen, ob verbleibende Teilexperimente in der Warteschlange vorhanden sind; und Beenden als Antwort auf eine Bestimmung, dass keine verbleibenden Teilexperimente in der Warteschlange vorhanden sind.
In einem dreizehnten Aspekt, der mit einem von dem neunten bis zwölften Aspekt kombiniert werden kann, umfasst im Allgemeinen das Verfahren ein Verarbeiten der aggregierten Ausgabe, um ein Konfidenzintervall für mindestens eine der einen oder der mehreren Leistungsmetriken zu generieren.
In einem vierzehnten Aspekt umfasst im Allgemeinen ein Verfahren: Empfangen, durch mindestens einen Prozessor, einer Spezifikation einer Risikofunktion; Empfangen, durch den mindestens einen Prozessor, einer Anfrage zum Auswerten der Risikofunktion, wobei die Anfrage eine Angabe eines konkreten Satzes von Daten, für den die Risikofunktion auszuwerten ist, und eine Angabe einer oder mehrerer Leistungsmetriken, die durch die Auswertung zu generieren sind, umfasst; Aufteilen, durch den mindestens einen Prozessor, des konkreten Satzes von Daten in einen oder mehrere Datenabschnitte; Instanziieren, durch den mindestens einen Prozessor, einer oder mehrerer Recheninstanzen, die zum Folgenden ausgelegt sind: Empfangen der Risikofunktion und eines des einen oder der mehreren Datenabschnitte; Verarbeiten der Risikofunktion mit dem Datenabschnitt, um einen oder mehrere Risikopunkte zu erzeugen; und Speichern des einen oder der mehreren Risikopunkte in einem Speichersystem; Aggregieren, durch den mindestens einen Prozessor, des einen oder der mehreren Risikopunkte, die im Speichersystem gespeichert sind, um eine aggregierte Ausgabe zu erzeugen; und Verarbeiten, durch den mindestens einen Prozessor, der aggregierten Ausgabe, um die eine oder die mehreren Leistungsmetriken für die Risikofunktion zu bestimmen.
In einem fünfzehnten Aspekt, der mit dem vierzehnten Aspekt kombiniert werden kann, umfasst im Allgemeinen die Spezifikation der Risikofunktion eine Angabe eines oder mehrerer Parameter für die Risikofunktion.
In einem sechzehnten Aspekt, der mit dem vierzehnten oder fünfzehnten Aspekt kombiniert werden kann, sind im Allgemeinen die eine oder die mehreren Recheninstanzen dazu ausgelegt, jeden des einen oder der mehreren Parameter zu iterieren, um einen oder mehrere Risikopunkte für jede Iteration des einen oder der mehreren Parameter zu erzeugen.
In einem siebzehnten Aspekt, der mit einem von dem vierzehnten bis sechzehnten Aspekt kombiniert werden kann, sind im Allgemeinen die eine oder die mehreren Recheninstanzen dazu ausgelegt, einen Gradienten jedes des einen oder der mehreren Parameter in Bezug auf die Risikofunktion zu berechnen.
In einem achtzehnten Aspekt, der mit einem von dem vierzehnten bis siebzehnten Aspekt kombiniert werden kann, ist im Allgemeinen jede der einen oder der mehreren Recheninstanzen zum Folgenden ausgelegt: Bestimmen, ob verbleibende Datenabschnitte vorhanden sind; und Beenden als Antwort auf eine Bestimmung, dass keine verbleibenden Datenabschnitte vorhanden sind.
In einem neunzehnten Aspekt umfasst im Allgemeinen ein Verfahren: Empfangen, durch mindestens einen Prozessor, einer Spezifikation einer oder mehrerer Transformationen, die einen Satz von Eingabedateien in einen Satz von Ausgabedateien transformieren; Generieren, durch den mindestens einen Prozessor, eines gerichteten Graphen, der Beziehungen zwischen dem Satz von Eingabedateien und dem Satz von Ausgabedateien beschreibt, auf der Grundlage der einen oder der mehreren Transformationen; Sortieren, durch den mindestens einen Prozessor, des gerichteten Graphen, um eine Reihenfolge zu bestimmen, in der die Transformationen angewendet werden; Berechnen, durch den mindestens einen Prozessor, eines kryptografischen Hashes für jede Eingabedatei im Satz von Eingabedateien; für jede der einen oder der mehreren Transformationen: Bestimmen einer Eingabe der Transformation auf der Grundlage der Reihenfolge; Berechnen eines Hashes der Transformation und der Eingabe in die Transformation; Vergleichen des Hashes der Transformation und der Eingabe in die Transformation mit einem Hash einer anschließenden Transformation, der in einem Speichersystem gespeichert ist; Speichern des Hashes der Transformation und der Eingabe in die Transformation in einem Speichersystem, wenn der Hash der Transformation und der Eingabe in die Transformation mit dem Hash der anschließenden Transformation übereinstimmt; und Anwenden der Transformation auf die Eingabe und Berechnen eines Hashes der Ausgabe und Speichern des Hashes der Eingabe in die Transformation, der Transformation, und der Ausgabe in einem Speichersystem, wenn der Hash der Transformation und der Eingabe in die Transformation mit dem Hash der anschließenden Transformation übereinstimmt; und Berechnen, durch das mindestens eine Datenverarbeitungssystem, eines endgültigen Hashes aller im Speichersystem gespeicherten Hashes.
In einem zwanzigsten Aspekt, der mit dem neunzehnten Aspekt kombiniert werden kann, ist im Allgemeinen ein gerichteter Graph ein gerichteter azyklischer Graph.
In einem einundzwanzigsten Aspekt, der mit dem neunzehnten oder dem zwanzigsten Aspekt kombiniert werden kann, ist im Allgemeinen die Reihenfolge eine topologische Reihenfolge, die mit Beziehungen zwischen dem Satz von Eingabedateien und dem Satz von Ausgabedateien konsistent ist.
Im zweiundzwanzigsten Aspekt, der mit einem von dem neunzehnten bis einundzwanzigsten Aspekt kombiniert werden kann, umfasst im Allgemeinen das Verfahren: Verfolgen, durch den mindestens einen Prozessor, einer Kette von Hashes; und Generieren, durch den mindestens einen Prozessor, einer Aufzeichnung mit der Änderung von Hashes.
In einem dreiundzwanzigsten Aspekt, der mit dem neunzehnten bis zweiundzwanzigsten Aspekt kombiniert werden kann, umfasst im Allgemeinen das Verfahren ein Speichern der Aufzeichnung in Metadaten für jede Ausgabedatei im Satz von Ausgabedateien.
In einem vierundzwanzigsten Aspekt umfasst im Allgemeinen ein System einen oder mehrere Prozessoren, die dazu ausgelegt sind, Operationen gemäß dem Verfahren nach einem von dem ersten bis dreiundzwanzigsten Aspekt durchzuführen.
In einem fünfundzwanzigsten Aspekt umfasst im Allgemeinen ein nichttransitorisches computerlesbares Medium Anweisungen, die bei einer Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren dazu veranlassen, Operationen nach einem von dem ersten bis dreiundzwanzigsten Aspekt durchzuführen.
Die Einzelheiten einer oder mehrerer Implementierungen werden in den begleitenden Zeichnungen und der nachstehenden Beschreibung dargelegt. Die hier beschriebenen Techniken können unter anderem durch ein oder mehrere Systeme, eine oder mehrere Vorrichtungen, ein oder mehrere Verfahren, oder ein oder mehrere nicht-transitorische computerlesbare Medien implementiert werden. Andere Merkmale und Vorteile werden aus der Beschreibung und den Zeichnungen sowie aus den Ansprüchen offensichtlich sein.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 zeigt ein Beispielsystem zum Erstellen und Auswerten eines statistischen Modells.
2A zeigt eine Beispielbenutzeroberfläche mit einem Verlustkosten-Lift-Diagramm.
2B zeigt eine Beispielbenutzeroberfläche mit einer ROC-Kurve (receiver operating characteristic, Operationscharakteristik eines Beobachters).
3 zeigt ein Beispiel für ein normalisiertes Lift-Stabilitäts-Diagramm.
4 zeigt einen Beispielprozess zum Generieren von Konfidenzintervallen.
5 und 6 zeigen Beispielprozesse zum Merkmallernen.
7 zeigt einen Beispielprozess zum Generieren einer reproduzierbaren Datenpipeline.
8 zeigt ein Beispiel für einen gerichteten azyklischen Graphen (DAG).
9 zeigt einen Beispielprozess zum Erstellen und Auswerten eines statistischen Modells.
10 zeigt ein Beispiel für ein Computersystem.

Gleiche Bezugszeichen in den verschiedenen Zeichnungen zeigen gleiche Elemente an.
AUSFÜHRLICHE BESCHREIBUNG
Um ein Risiko angemessen zuzuordnen, erstellen Analysten in der Kraftfahrzeugversicherungsbranche statistische Modelle, um ein Fahrrisiko auf der Grundlage beobachteter Merkmale jedes Fahrers vorherzusagen. Um ein solches Modell zu erstellen, teilt der Analyst zunächst einen Satz beobachteter Merkmale und entsprechender Anspruchsdaten (die ein Fahrrisiko repräsentieren) für eine Population von Fahrern in zwei disjunkte Abschnitte auf: einen Trainingsdatensatz und einen Testdatensatz (oder einen zurückgehaltenen Datensatz). Ein Modell, wie z. B. ein Regressionsmodell, wird an die Trainingsdaten angepasst, und der Testdatensatz wird zum Auswerten der Leistung des Modells verwendet. Wenn die Leistung des Modells validiert wird, kann eine erwartete Anspruchsrate (oder Anspruchskosten) für einen beliebigen gegebenen Fahrer vorhergesagt werden.
Jedoch können Anspruchsdaten knapp sein und möglicherweise sind nicht genügend Anspruchsdaten verfügbar, um das statistische Modell wirksam zu trainieren oder zu validieren. Außerdem sind Anspruchsdaten in manchen Fällen möglicherweise nicht die beste Zielvariable zum Trainieren des statistischen Modells, weswegen der Verbrauch eines Abschnitts der Anspruchsdaten für Trainingszwecke eine ineffiziente Ressourcennutzung darstellt. Selbst wenn genügend Anspruchsdaten verfügbar sind, ist ein Erstellen und Auswerten eines statistischen Modells zeit- und ressourcenintensiv, weswegen es für einen Analysten schwierig wird, die Leistung neuer Modelle und Merkmale sinnvoll zu untersuchen.
Die hier beschriebenen Techniken verbessern die Erstellung und Auswertung statistischer Modelle, wie z. B. Modelle zum Vorhersagen eines Fahrrisikos. In einigen Beispielen wird eine interaktive Benutzeroberfläche bereitgestellt, die es einem Benutzer (z. B. einem Analysten) ermöglicht, verschiedene Parameter zum Aufbauen eines Modells zu spezifizieren, wie z. B. unter anderem Merkmale, die zur Vorhersage verwendet werden, und die Zielvariable, die zum Trainieren und/oder Testen verwendet wird. Wenn der Benutzer nicht sicher ist, welche Merkmale für ein konkretes Modell auszuwählen sind (oder einfach neue Merkmale untersuchen möchte), können Merkmal-Lernprozesse eingesetzt werden, die große Mengen an Low-Level-Daten verbrauchen, um in kurzer Zeit neue Merkmale zu entwickeln. Um das Problem des Kompromisses zwischen der Größe des Trainings- und des Testdatensatzes zu vermeiden, ermöglichen außerdem die hier beschriebenen Techniken es einem Benutzer, über Proxy-Variablen zu modellieren.
Unter Verwendung der durch den Benutzer spezifizierten Informationen wird ein Modell schnell und effizient generiert und validiert, und Leistungsmetriken werden dem Benutzer präsentiert. In einigen Beispielen werden hochparallele Bootstrapping-Techniken verwendet, um schnell Konfidenzintervalle für Modellausgaben zu generieren, um statistisch aussagekräftige Vergleiche zwischen Modellen zu ermöglichen. Zusätzliche hier beschriebene Techniken unterstützen auch die Aufzeichnungsaufbewahrung und Einhaltung von Vorschriften durch ein vollautomatisiertes System, das Modelldatenpipelines in einem reproduzierbaren Format bewahrt.
1 zeigt ein Beispielsystem 100 zum Erstellen und Auswerten eines statistischen Modells. Zum Beispiel kann das System 100 derart ausgelegt sein, dass es ein statistisches Modell zum Vorhersagen eines Fahrrisikos anhand eines Satzes beobachteter Merkmale für einen Fahrer erstellt und auswertet. In diesem Kontext repräsentiert ein Risiko die erwartete Anzahl von Ansprüchen durch einen Fahrer während eines konkreten Expositionszeitraums (z. B. ein Häufigkeitsmodell), oder die erwarteten Kosten von Ansprüchen durch den Fahrer während eines konkreten Expositionszeitraums (z. B. ein Verlustkostenmodell). Um ein Verständnis zu erleichtern, verwendet die nachstehende Diskussion das Beispiel eines statistischen Modells, das zum Vorhersagen eines Risikos von Kraftfahrzeugversicherungsansprüchen ausgelegt ist. Jedoch sind die hier beschrieben Techniken nicht auf solche Modelle beschränkt und können in einigen Implementierungen verwendet werden, um andere Modelle zu erstellen und auszuwerten.
Wie in 1 dargestellt, umfasst das System 100 einen Modellgenerator 102, ein Speichersystem 104, und eine Client-Vorrichtung 106. Das Speichersystem 104 umfasst ein oder mehrere computerlesbare Speichermedien, die dazu ausgelegt sind, Daten zum Erstellen und Auswerten eines statistischen Modells, wie z. B., neben anderen Informationen, Versicherungsanspruchsdaten und beobachteten Merkmalsdaten, zu empfangen und zu speichern. In diesem Beispiel beziehen sich Versicherungsanspruchsdaten auf Informationen über das Bestehen, die Kosten oder andere Aspekte von Versicherungsansprüchen. Versicherungsanspruchsdaten können außerdem Informationen hinsichtlich einer Exposition eines Fahrers umfassen (z. B. Informationen über die Zeitspanne (oder Distanz), für die der Fahrer versichert ist oder für die die beobachteten Merkmalsdaten gesammelt werden). In einigen Beispielen empfängt das Speichersystem 104 die Anspruchsdaten von einer Versicherungsgesellschaft 108 (z. B. über ein oder mehrere drahtgebundene oder drahtlose Netzwerke).
Beobachtete Merkmalsdaten beziehen sich auf Informationen über einen versicherten Fahrer (z. B. Alter, Geschlecht, Kreditwürdigkeit, Postleitzahl usw.) oder über das Fahrzeug des versicherten Fahrers (z. B. Marke, Modell, Jahr, Wert usw.). In einigen Beispielen umfassen die beobachteten Merkmalsdaten Telematikdaten, die während einer oder mehrerer Fahrten (z. B. einer Fahrtinstanz zwischen einem Startort und einem Endort) eines Fahrzeugs 110 eines versicherten Fahrers erfasst wurden. Zum Beispiel kann das Fahrzeug 110 einen oder mehrere Sensoren (z. B. Beschleunigungsmesser, Gyroskope, globale Navigationssatellitensysteme (GNSS), Bildsensoren, Audiosensoren usw.) umfassen, die dazu ausgelegt sind, Telematikdaten zur Übertragung an das Speichersystem 104 zu sammeln. In einigen Beispielen sind die Sensoren in einer Telematikvorrichtung aufgenommen, die im Fahrzeug montiert oder ins Fahrzeug mitgenommen wird. Eine solche Telematikvorrichtung kann eine Telematikvorrichtung eines Originalgeräteherstellers (OEM) sein, die während der Herstellung des Fahrzeugs 110 montiert wird, eine Telematikvorrichtung, die zum Beispiel mit einem On-Board-Diagnoseanschluss (OBD-Anschluss) des Fahrzeugs 110 verbunden ist, oder eine mobile Vorrichtung, wie z. B. ein Smartphone, ein Tablet oder eine tragbare Vorrichtung, die in das Fahrzeug 110 mitgenommen wird. In einigen Beispielen ist die Telematikvorrichtung eine Tag-Vorrichtung, die im Fahrzeug 110 angeordnet oder befestigt wird (jedoch nicht elektrisch mit ihm verbunden ist), wie z. B. eine Tag-Vorrichtung der Art, die in der US-Patentanmeldung Nr. 14/529,812 mit dem Titel „System and Method of Obtaining Vehicle Telematics data“ beschrieben ist, deren gesamte Inhalte hier durch Rückbezug aufgenommen sind. Die Telematikdaten können weiter, möglicherweise in Verbindung mit zusätzlichen Daten, verarbeitet werden, um weitere Merkmale bereitzustellen. Ein Beispiel findet sich in der US-Patentanmeldung Nr. 13/832,456 mit dem Titel „Inference of vehicular trajectory characteristics with personal mobile devices“, deren gesamte Inhalte hier durch Rückbezug aufgenommen sind. In einigen Beispielen sind die Anspruchsdaten und die Daten beobachteter Merkmale miteinander, zum Beispiel über eine eindeutige Kennung für den Versicherten verknüpft.
In Betrieb empfängt der Modellgenerator 102 vom Speichersystem 104 einige oder alle der Anspruchsdaten und Daten beobachteter Merkmale. In einigen Beispielen ist der Modellgenerator 102 durch ein Computersystem, wie z. B. das unter Bezugnahme auf 10 beschriebene Computersystem 1000, umgesetzt. Der Modellgenerator 102 verwendet dann einen oder mehrere Prozessoren, um die empfangenen Daten zu verarbeiten, um ein statistisches Modell zu erstellen und auszuwerten. Zunächst wählt bei 112 der Modellgenerator 102 Parameter zum Erstellen und Auswerten des Modells. In einigen Beispielen umfasst die Parameterauswahl 112 unter anderem eine Auswahl und Erweiterung der für eine Vorhersage verwendeten Merkmale, des für eine Validierung verwendeten Zielmerkmals, der zum Trainieren und/oder Testen verwendeten Zielvariable (die gemäß den hier beschriebenen Proxy-Zieltechniken unterschiedlich sein kann), des zum Trainieren und/oder Testen verwendeten Datentyps, oder des Typs des anzupassenden Modells (z. B. Poisson, Tweedie, negatives Binomial usw.) oder Kombinationen davon. Eine solche Auswahl kann automatisch durch den Modellgenerator 102 auf der Grundlage bekannter oder beobachteter Regeln oder Einschränkungen, oder durch einen Benutzer der Client-Vorrichtung 106, oder durch den Benutzer in Verbindung mit dem Modellgenerator 102 getroffen werden. Zum Beispiel kann der Modellgenerator 102 ausgelegt sein, um die Client-Vorrichtung 106 dazu zu veranlassen, eine grafische Benutzeroberfläche (GUI) anzuzeigen, die es dem Benutzer der Client-Vorrichtung 106 ermöglicht, einige oder alle der Parameter für die Modellerstellung und - auswertung anzuzeigen und auszuwählen. In einigen Beispielen ist die Client-Vorrichtung 106 ein Computersystem (z. B. ein Computer, ein Laptop, ein Smartphone, ein Tablet usw.), wie z. B. das unter Bezugnahme auf 10 beschriebene Computersystem 1000, das durch einen Benutzer (z. B. einen Analysten) bedient wird. In einigen Beispielen umfasst die Parameterauswahl 112 eine Merkmalauswahl und/oder eine Merkmalextraktion, wie unten im Teilabschnitt „Merkmalslemen in großem Maßstab“ beschrieben.
Nachdem Parameter und andere Merkmale des statistischen Modells ausgewählt wurden, fährt der Modellgenerator 102 mit einem Erstellen 114 des Modells fort. Im Allgemeinen umfasst die Modellerstellung 114 ein Anpassen des ausgewählten Modelltyps an den Trainingsdatensatz (indem z. B. optimale Parameter für das Modell gefunden werden, die das Modell am besten an den Trainingsdatensatz anpassen). In einigen Beispielen umfasst der Trainingsdatensatz einen Abschnitt der Daten beobachteter Merkmale und der entsprechenden Anspruchsdaten, die für das Training aufgeteilt wurden. In anderen Beispielen umfasst der Trainingsdatensatz einen Abschnitt der Daten beobachteter Merkmale und eine von den Anspruchsdaten separate Proxy-Zielvariable, wie nachstehend im Teilabschnitt „Modellieren über Proxy-Variablen“ beschrieben.
Nachdem das Modell an den Trainingsdatensatz angepasst wurde, wird das Modell auf dem Testdatensatz ausgewertet 116. Im Allgemeinen umfasst die Modellauswertung 116 ein Validieren, ob die Vorhersageleistung des Modells auf dem Trainingsdatensatz auf den neuen Testdatensatz übertragbar ist (z. B. durch Generieren von Leistungsmetriken für das Modell, wie auf den Testdatensatz angewendet, Vergleichen des Vorhersagefehlers des Modells für jeden Datensatz usw.). In einigen Beispielen umfasst der Testdatensatz den Abschnitt der beobachteten Merkmalsdaten und der entsprechenden Anspruchsdaten, der beim Training des Modells zurückgehalten wurde. In anderen Beispielen, wie z. B. wenn eine Proxy-Zielvariable zum Trainieren des Modells verwendet wird, umfasst der Testdatensatz alle Anspruchsdaten und die zugehörigen Daten beobachteter Merkmale.
Das endgültige Vorhersagemodell kann entweder durch direktes Verwenden des Modells oder durch indirektes Verwenden des Modells zum Ableiten eines Risikos aus dem Testdatensatz erstellt werden. Wenn zum Beispiel das Modell eine Risikoschätzung erzeugt, kann es zum direkten Vorhersagen des von einem Fahrer ausgehenden Risikos verwendet werden. Ein direktes Verwenden des Modells kann angebracht sein, wenn der Trainingsdatensatz groß ist. Wenn jedoch die Größe des Trainingsdatensatzes klein ist, können dann Schätzungen überangepasst werden, was zu einer mangelhaften Modellleistung führt. Insbesondere kann das Modell Zuschläge und Abschläge übertreiben. Dagegen kann das Modell indirekt verwendet werden, um eine Reihenfolge von Fahrern vom sichersten zum riskantesten bereitzustellen, die dann mit dem relativen Risiko aus den zurückgehaltenen Testdaten in Beziehung gesetzt werden kann. Statistisch gesehen kann diese Operation derart betrachtet werden, dass eine Vorwärts- und eine Rückwärts-Wahrscheinlichkeitstransformation verwendet wird, um den Bereich der Vorhersagen auf die Verteilung der zurückgehaltenen Daten abzubilden. In der Praxis läuft dies darauf hinaus, ein Lift-Diagramm zu erstellen, das das Modell für Quantile verwendet, aber die Häufigkeitszahlen oder Verlustkosten aus den Testdaten zum Schätzen des relativen Risikos verwendet. Die Y-Achse jedes Punktes auf der Lift-Kurve entspricht dem Abschlag oder Zuschlag, der diesem Teil der Population angeboten wird.
In einigen Beispielen umfasst die Modellauswertung 116 ein Bestimmen verschiedener Leistungsmetriken für das Modell, wie z. B. unter anderem des Lifts, der Fläche unter der Kurve (AUC). In einigen Beispielen werden für diese Statistiken Konfidenzintervalle bereitgestellt. Angenommen, dass zum Beispiel ein Risikomodell für einen Satz von Fahrern erzeugt wurde. Für jeden Fahrer erstellt das Modell eine Vorhersage für die erwartete Anzahl von Ansprüchen, die der Fahrer generieren wird, als eine Funktion eines Satzes beobachteter Merkmale über den Fahrer. Durch Analysieren jedes Fahrers der Reihe nach kann das Modell verwendet werden, um Vorhersagen für eine gesamte Population von Fahrern zu erzeugen. Als Nächstes werden die Fahrer in Quantilbereiche aufgeteilt (z. B. durch Sortieren der Fahrer nach zunehmender Risikowahrscheinlichkeit und anschließendes Aufteilen dieser geordneten Liste in gleich große Bereiche auf der Grundlage von Quantilen, mit optionaler Gewichtung, um unterschiedliche Expositionsniveaus bei Fahrern zu berücksichtigen). Die Anzahl von Ansprüchen für jeden Quantilbereich wird dann aggregiert. Aus diesen Informationen kann der Häufigkeits-Lift oder die Häufigkeits-Lift-Statistik als das Verhältnis zwischen der Anzahl von Ansprüchen, die dem risikoreichsten Quantilbereich entspricht, und der Anzahl von Ansprüchen im risikoännsten Quantilbereich bestimmt werden. Wenn die gesamten Anspruchskosten pro Quantil und nicht die Gesamtzahl von Ansprüchen aggregiert werden, kann der Verlustkosten-Lift analog bestimmt werden. In jedem Fall entspricht eine Statistik mit einem größeren Lift einem besser vorhersagenden Modell.
Eine weitere Leistungsmetrik, die für das Modell bestimmt werden kann, ist eine AUC, wobei die Kurve die ROC-Kurve (Receiver Operating Characteristic) ist. In einigen Beispielen werden Konfidenzintervalle für die Modellvorhersagen bestimmt, wie nachstehend im Teilabschnitt „Bootstrapping in großem Maßstab“ beschrieben.
In einigen Beispielen generiert der Modellgenerator 102 Leistungsergebnisse 118 für das Modell auf der Grundlage der Auswertung. Diese Leistungsergebnisse umfassen zum Beispiel einen für Menschen lesbaren Text und/oder für Menschen sichtbare Zahlen, die die Leistung des Modells beschreiben, wie z. B., neben anderen Informationen, Lift-Diagramme, Lift-Statistiken, ROC-Diagramme, AUC-Messungen und Konfidenzintervalle für Modellvorhersagen. In einigen Beispielen ist der Modellgenerator 102 dazu ausgelegt, die Leistungsergebnisse auf der Client-Vorrichtung 106 zur Analyse durch einen Benutzer bereitzustellen oder anderweitig anzuzeigen (z. B. indem die Client-Vorrichtung 106 dazu veranlasst wird, eine GUI mit den Leistungsergebnissen anzuzeigen). Zum Beispiel zeigt 2A eine Beispielbenutzeroberfläche 200 mit einem Verlustkosten-Lift-Diagramm 202, das auf der Client-Vorrichtung 106 angezeigt wird. In diesem Beispiel zeigt das Lift-Diagramm 202 den Lift relativer Verlustkosten für verschiedene Quantile von Fahrern, zusammen mit Konfidenzintervallen 204 für die vorhergesagten Werte und einem für Menschen lesbarem Text 206, der verschiedene Leistungsmetriken für das Modell beschreibt. 2B zeigt eine Beispielbenutzeroberfläche 210 mit einem ROC-Diagramm 212, das auf der Client-Vorrichtung 106 angezeigt werden kann. In diesem Beispiel umfasst das ROC-Diagramm 212 mehrere ROC-Kurven, die die Richtig-Positiv-Rate und die Falsch-Positiv-Rate für verschiedene Modelle beschreiben, sowie die AUC 214 für jedes Modell.
Durch die Leistungsergebnisse 118, die durch den Modellgenerator 102 bereitgestellt werden, kann ein Benutzer der Client-Vorrichtung 106 schnell und einfach die Leistung eines konkreten Modells auswerten und die relative Leistung des Modells mit anderen Modellen vergleichen. Wenn der Benutzer mit der Leistung des Modells zufrieden ist, kann der Benutzer den Modellgenerator 102 dazu veranlassen, das Modell und seine zugrunde liegende Datenpipeline zur Aufzeichnungsaufbewahrung zu speichern, wie nachstehend im Teilabschnitt „Reproduzierbare Datenpipelines“ beschrieben. Zu diesem Zeitpunkt kann der Benutzer das Modell zum Vorhersagen eines Fahrerrisikos auf der Grundlage neuer Beobachtungen verwenden. Das Modell kann außerdem aktualisiert (und die Modifikationen ausgewertet) werden, um neue Trainingsdaten (z. B. neue Beobachtungen für bestehende Merkmale) oder neue Testdaten (z. B. neue Anspruchsdaten) zu berücksichtigen, oder modifiziert werden, um zum Beispiel die für die Vorhersage verwendeten Merkmale hinzuzufügen, zu entfernen, oder auf eine andere Weise zu ändern.
Modellieren über Proxy-Variablen:
Beim Trainieren und Validieren eines statistischen Modells ist es wünschenswert, Trainings- und Testdatensätze zu verwenden, die möglichst groß sind, um die Leistung des Modells und die Zuverlässigkeit der Validierung zu maximieren. In vielen Fällen weisen jedoch die zum Trainieren und Validieren eines statistischen Modells verwendeten Daten eine feste Größe auf. Im Kontext einer Kraftfahrzeugversicherung sind zum Beispiel die Anspruchsdaten, die zum Trainieren und Validieren eines Risikomodells verwendet werden, durch die Anzahl verfügbarer Ansprüche beschränkt. Aufgrund der festen Größe dieser Daten besteht eine inhärente Spannung zwischen der Größe des Trainings- und des Testdatensatzes: Je größer der Trainingsdatensatz, desto kleiner der Testdatensatz (und umgekehrt).
Dieser Kompromiss besteht jedoch nur, wenn der Testdatensatz anhand derselben Zielvariable trainiert wird wie der Trainingsdatensatz. Der Begriff „Zielvariable“ (auch als endogene, Ergebnis-, Kriteriums- oder Regressand-Variable bezeichnet) bezieht sich auf die Variable, die das Modell vorherzusagen versucht, wie z. B. die Anzahl von Ansprüchen oder die Gesamtkosten von Ansprüchen bei der Vorhersage eines Fahrrisikos. Wenn eine unabhängige Proxy-Zielvariable (z. B. im gleichen Satz von Fahrern, oder vielleicht in einem anderen Satz von Fahrern) vorhanden ist, dann können alle der Proxy-Zieldaten zum Trainieren des Modells verwendet werden und alle der tatsächlichen Zieldaten (z. B. Anspruchsdaten) können zum Validieren des Modells verwendet werden. Der Begriff „Proxy-Zielvariable“ bezieht sich auf eine Variable, die die Zielvariable, die das Modell vorherzusagen versucht, repräsentiert oder mit ihr korreliert ist. Da der Testprozess unverändert bleibt, bleibt die Modellvalidierung statistisch gültig. Tatsächlich ist die Validierung oft genauer als eine Validierung ohne eine Proxy-Zielvariable, da alle tatsächlichen Zieldaten für die Validierung verwendet wurden.
Eine Proxy-Zielvariable scheint möglicherweise die „falsche Variable“ zum Trainieren eines statistischen Modells zu sein, um eine tatsächliche Zielvariable vorherzusagen. In einigen Beispielen kann sich eine Proxy-Zielvariable jedoch besser bewähren als die tatsächliche Zielvariable. Zum Beispiel wird die Aufgabe des Versuchs betrachtet, ein Gewicht einer Person anhand ihrer gemessenen Höhe vorherzusagen. Eine Sammlung von <Höhe, beobachtetes Gewicht>-Messungen wird bereitgestellt, um ein Modell zu erstellen, das das beobachtete Gewicht anhand der Höhe vorhersagt. Angenommen jedoch, dass das Gewicht der Person durch eine ungenaue Waage bestimmt wird, die eine verrauschte Messung erzeugt, anstatt das wahre Gewicht der Person zu melden. Die Höhe einer neuen Person wird bereitgestellt, und die Aufgabe besteht darin, das gemessene Gewicht der Person auf der ungenauen Waage vorherzusagen.
Wenn in einigen Beispielen eine Modellvalidierung nicht erforderlich ist, können alle <Größe, beobachtetes Gewicht>-Paare als ein Trainingsdatensatz verwendet werden, um ein Vorhersagemodell des beobachteten Gewichts zu erstellen (z. B. durch lineare Regression).
Angenommen, dass eine weitere Option für Testzwecke darin besteht, jede Person auf einer genaueren Waage zu messen (obwohl das Ziel weiterhin darin besteht, den Messwert auf der ungenauen Waage vorherzusagen). Wenn für alle Trainingsmessungen dieselbe Waage verwendet werden muss, ist es in manchen Fällen besser, die genauere Waage (z. B. das Proxy-Ziel) anstelle der ungenauen Waage (z. B. das tatsächliche Ziel) zu verwenden. Angenommen, dass das Modell zum Beispiel auf i = 1, ..., N = 10 Menschen mit Höhen H_i, die gleichmäßig zwischen [60, 72] Zoll verteilt sind, trainiert wird. Angenommen ferner, dass die wahren Gewichte W_i, und W_i = 2H_i sind. Gemessene Gewichte von der ungenauen Waage sind $B_{i} = W_{i} + n_{i}^{B},$

mit einem Rauschterm $n_{i}^{B} \sim N (0, S_{B}^{2}),$
und gemessene Gewichte von der genauen Waage sind $G_{i} = W_{i} + n_{i}^{G}$
mit einem Rauschterm $n_{i}^{G} \sim N (0, S_{G}^{2}),$
wobei 1 = S_G << S_B = 20 (und alle Rauschterme unabhängig sind). Wenn eine neue Höhe H_j gesampelt wird und der Fehler zwischen der Vorhersage und B_j, dann ist eine lineare Regression, die auf G_i trainiert wird, ungefähr 10 % genauer (in Standardabweichung) als eine, die auf B_i trainiert wird, obwohl auf der „falschen“ Waage (z. B. dem Proxy-Ziel) trainiert wurde.
Dementsprechend ist in einigen Beispielen der Modellgenerator 102 dazu ausgelegt, eine Proxy-Zielvariable zu verwenden, um ein statistisches Modell zu erstellen. Zum Beispiel ist im Automobilkontext der Modellgenerator 102 derart ausgelegt, dass er Telematikdaten empfängt und ein Modell trainiert, um ein Fahrrisiko unter Verwendung eines oder mehrerer Proxy-Ziele aus den Telematikdaten vorherzusagen. Diese Proxy-Ziele umfassen neben anderen telematikbasierten oder nicht telematikbasierten Proxy-Zielen Telematikkollisionen (z. B. Kollisionen, die aus der Bewegung des Fahrzeugs detektiert werden, und nicht Kollisionen, die als das Ergebnis einer Anspruchseinreichung detektiert werden), starkes Bremsen (z. B. Bremsen, das stärker ist als ein bestimmtes Ausmaß), starke Beschleunigung (z. B. Beschleunigung, die größer ist als ein bestimmtes Ausmaß), Telefonnutzung während der Fahrt (z. B. eine gleichzeitige Bewegung des Fahrzeugs und des Telefons des Fahrers) oder Kombinationen davon, sind aber nicht darauf beschränkt. Zusätzliche Einzelheiten bezüglich einer Detektion von Telematikkollisionen sind in der US-Patentanmeldung Nr. 16/035,861 mit dem Titel „Vehicle Telematics of Vehicle Crashes“ beschrieben, deren gesamte Inhalte hier durch Rückbezug in ihrer Gänze aufgenommen sind.
Der Modellgenerator 102 kann ein Proxy-Ziel unter Verwendung ähnlicher Techniken validieren wie jene, die hier zur Validierung eines tatsächlichen Ziels (unter anderem z. B. durch Analyse eines Lift-Diagramms oder Berechnung der AUC) beschrieben sind. Da eine Validierung des Proxy-Ziels eine relative Reihenfolge des vorhergesagten Ergebnisses (z. B. eine relative Reihenfolge des Fahrrisikos) anstelle des tatsächlich vorhergesagten Werts erzeugt, gilt die Validierung auch dann, wenn das Modell ein anderes Ziel vorhersagt. Der relative Charakter der Modellvorhersagen bedeutet auch, dass der absolute Maßstab der Modellvorhersagen irrelevant ist. Um die Verteilung des Proxy-Ziels in die Verteilung des tatsächlichen Ziels zu transformieren, kann der Modellgenerator 102 das indirekte Verfahren zum Erstellen des endgültigen Vorhersagemodells verwenden, wie vorstehend beschrieben.
Durch Verwenden einer Proxy-Zielvariable kann der Modellgenerator 102 ein Modell mit verbesserter Leistung im Vergleich mit einem Modell erstellen, das unter Verwendung einer tatsächlichen Zielvariable erstellt wurde, wie im vorstehenden Beispiel dargelegt. Außerdem kann eine Proxy-Zielvariable (z. B. starkes Bremsen) gewählt werden, die deutlich häufiger vorkommt als die eigentliche Zielvariable (z. B. Versicherungsansprüche, die relativ selten sind). Dies verbessert nicht nur die Modellleistung (z. B. durch Bereitstellen von mehr Trainingsdaten, durch Bereitstellen von Trainingsdaten, die ein latentes Risiko besser modellieren können als das tatsächliche Ziel usw.), sondern die Verwendung des Proxy-Ziels zum Trainieren ermöglicht auch, dass alle verfügbaren Daten für das tatsächliche Ziel (z. B. Anspruchsdaten) zum Testen und Validieren verwendet werden. Durch Maximieren der Größe des Testdatensatzes kann die Leistung des Modells genauer und zuverlässiger ausgewertet werden. Zum Beispiel ist ein versicherungsstatistischer Standard vorhanden, der 1082 Ansprüche zum Validieren eines Häufigkeitsmodells erfordert (siehe z. B. Longley-Cook, Laurence H.: „An introduction to credibility theory“, Casualty Actuarial Society, 1962). Wenn einem Versicherungsstatistiker 1082 Ansprüche für eine konkrete Art von Versicherungsanspruch vorliegen, ermöglicht dann ein Verwenden eines Proxy-Ziels es, ein glaubwürdiges Modell zu erstellen, das mit dem herkömmlichen Ansatz der Aufteilung der Daten in einen Test- und Trainingssatz nicht validiert werden könnte.
Ein Verwenden einer Proxy-Zielvariable kann außerdem die Zeit bis zur Markteinführung eines Modells reduzieren. Angenommen, dass eine Versicherungsgesellschaft zum Beispiel daran interessiert ist, ein neues Modell zum Vorhersagen eines Fahrrisikos auf der Grundlage von starkem Bremsen zu entwickeln. Um dieses Modell zu validieren, muss die Versicherungsgesellschaft genügend Daten über die eigene Population von Fahrern sammeln. Angenommen, dass die Gesellschaft zum Beispiel C Ansprüche sammeln muss, um die Validität zu begründen. Wenn die Gesellschaft eine standardmäßige 70%/30%-Training/Test-Aufteilung verwendet (z. B. 70 % von Anspruchsdaten werden zum Trainieren verwendet, und die verbleibenden 30 % werden zum Testen verwendet), dann muss die Gesellschaft 3,3C Ansprüche sammeln, um genügend Daten zum Erstellen eines Modells und dessen Validieren bereitzustellen. Wenn die Gesellschaft hingegen eine Proxy-Zielvariable verwendet, dann muss sie lediglich C Ansprüche zum Validieren sammeln. Da sich die Ansprüche im Laufe der Zeit aggregieren, beschleunigt der Proxy-Ziel-Ansatz den Trainings- und Validierungsprozess um einen Faktor 3,3 und reduziert auf diese Weise die Zeit bis zur Markteinführung des neuen Modells.
In einigen Beispielen erhöht ein Verwenden einer Proxy-Zielvariable die Modelleinheitlichkeit zwischen Gerichtssystemen. Beispielsweise unterliegen Kraftfahrzeugversicherungsansprüche verschiedenen gerichtsspezifischen Vorschriften, so dass ein Ereignis, das in einem Rechtssystem zu einem Anspruch führt, in einem anderen Rechtssystem möglicherweise zu keinem Anspruch führt. Von daher kann es schwierig sein, Anspruchsdaten aus verschiedenen Rechtssystemen auf kohärente Weise zu kombinieren. Es kann jedoch eine Proxy-Zielvariable (z. B. starkes Bremsen) definiert und einheitlich in allen Rechtssystemen gemessen werden. So kann die effektive Größe eines einheitlichen Trainingssatzes beim Verwenden einer Proxy-Zielvariable wesentlich größer sein als beim Verwenden einer tatsächlichen Zielvariable.
Eine Proxy-Zielvariable kann außerdem ein Sampling mit impliziter Wichtigkeit ermöglichen. Angenommen, dass die gewählte Proxy-Zielvariable zum Beispiel teureren Ansprüchen entspricht. Wenn ein Modell, das zum Vorhersagen der Proxy-Variable erstellt wurde, prädiktiv ist, würde sich eine Lift-Statistik großer Häufigkeit ergeben. Da dieses Beispiel jedoch die teuren Ansprüche effektiv übersampelt, wäre die Verlustkosten-Lift-Statistik sogar noch größer als die Häufigkeits-Lift-Statistik. Dieser Vorteil kann als eine Art von Sampling mit impliziter Wichtigkeit angesehen werden, bei dem das Sampling der Anspruchsanzahl in Richtung von Ansprüchen, die für die Prämienpreisgestaltung von größerem Interesse sind, voreingenommen ist.
Bootstrapping in großem Maßstab:
Angenommen, dass die Leistung eines Modells anhand eines Testdatensatzes ausgewertet wird, indem ein Lift-Diagramm und eine entsprechende Lift-Statistik erstellt werden. Sowohl das Lift-Diagramm als auch die Lift-Statistik sind als Punktschätzungen gegeben. Jedoch wäre es wünschenswert, ein Konfidenzintervall für die Schätzungen zu erzeugen. Wenn ein Modell einen höheren Lift aufweist als ein anderes, kann dann auf diese Weise bestimmt werden, ob der Leistungsunterschied statistisch signifikant ist.
Wenn mehr Daten auf einem Gebiet verfügbar werden, werden außerdem Modelle typischerweise zunehmend prädiktiver und der Lift nimmt zu. Da zum Beispiel Smartphones zum Sammeln umfangreicher Fahrdaten verfügbar geworden sind, sollte sich die Genauigkeit von Kraftfahrzeugrisikomodellen verbessern. Mit verbessertem Lift wird die Notwendigkeit für Konfidenzintervalle größer. Betrachtet wird der Einsatz eines generativen Modells mit bekanntem Lift und ein Sampling vieler Datensätze, wobei der versicherungsstatistisch vorgeschlagene Schwellenwert von 1082 Ansprüchen beibehalten wird. Für jeden durch das Modell gesampelten Datensatz wird ein gewisser Lift beobachtet, der größer oder kleiner als der wahre Lift sein kann. Durch Resampling des Modells kann für jeden wahren Lift eine kumulative Verteilungsfunktion (CDF) für das Verhältnis des beobachteten Lifts zum wahren Lift erlangt werden. Wie durch das Diagramm 300 zur normalisierten Lift-Stabilität in 3 dargestellt, ist die Verteilung des beobachteten Lifts umso breiter und ein Konfidenzintervall wird dementsprechend umso wichtiger, je höher der Lift ist. Es ist zu beachten, dass 3 den relativen Sampling-Fehler zeigt; wenn der absolute Fehler beim Lift berücksichtigt wird, ist die Verteilung des beobachteten Lifts sogar breiter.
In einigen Beispielen, wie z. B. in einfachen Wahrscheinlichkeitsmodellen, ist es möglich, ein analytisches Konfidenzintervall in geschlossener Form zu erzeugen. Allerdings machen die komplexen Schritte beim Erstellen eines versicherungsstatistischen Modells (z. B. eines verallgemeinerten linearen Modells (GLM)) diesen Ansatz unpraktisch.
Dementsprechend ist in einigen Beispielen der Modellgenerator 102 dazu ausgelegt, Bootstrapping zu verwenden, um Konfidenzintervalle auch bei extrem komplizierten Modellen zu schätzen. Im Allgemeinen umfasst ein Bootstrapping ein zufälliges Sampling von Daten mit Ersetzung und ein Wiederholen der Analyseschritte (z. B. Anpassen eines neuen Modells, z. B. eines GLM, jedes Mal, wenn die Daten resampelt werden). Nachdem ein Schwellenwert von Samples generiert wurde, kann ein Konfidenzintervall für praktisch jede Statistik von Interesse extrahiert werden, einschließlich der Werte eines Lift-Diagramms (z. B. für den beobachteten Lift für jeden Quantilbereich) und der Lift-Statistik selbst.
Bedauerlicherweise ist Bootstrapping sehr rechenintensiv. Das Laden von Daten, ein Resampling von diesen, und Anpassen eines einzelnen Modells an die Daten kann in einem realen System 30 Sekunden dauern. Um ein Konfidenzintervall mit einem hohen Maß an Genauigkeit zu erhalten, kann es erforderlich sein, diesen Prozess 10.000 Mal zu wiederholen (um z. B. 10.000 Bootstrap-Samples zu erzeugen), was zu einer Berechnungszeit von 3,5 Tagen führt, um ein einzelnes Konfidenzintervall zu erzeugen. Eine solche Verzögerung würde den Prozess in den meisten Situationen unpraktisch machen.
Von daher kann ein Prozess 400 verwendet werden, um Konfidenzintervalle schnell zu erzeugen, wie in 4 dargestellt. In einigen Beispielen kann der Prozess 400 durch den Modellgenerator 102 und eine Rechenumgebung 450 (neben anderen Komponenten des Systems 100, wie z. B. dem Speichersystem 104 und/oder der Client-Vorrichtung 106) ausgeführt werden. Obwohl als separate Komponenten dargestellt, sind in einigen Beispielen der Modellgenerator 102 und die Rechenumgebung 450 ein einzelnes Datenverarbeitungssystem (oder ein verteiltes Datenverarbeitungssystem).
Operationen des Prozesses 400 umfassen ein Empfangen 402 von Parametereinstellungen für ein Rechenexperiment. Zum Beispiel können die Parametereinstellungen von einem Benutzer, der die Client-Vorrichtung 106 (z. B. über eine Eingabe oder Auswahl der Parametereinstellungen in einer auf der Client-Vorrichtung angezeigten GUI) bedient, empfangen werden, durch den Modellgenerator 102 (z. B. auf der Grundlage bekannter oder beobachteter Regeln oder Einschränkungen) automatisch gewählt werden, oder eine Kombination davon. In diesem Kontext bezieht sich ein Rechenexperiment auf eine Sammlung von Teilexperimenten, die jeweils einem Bootstrap-Resampling von Daten für einen konkreten Satz von Parametereinstellungen, einem Anpassen eines Modells an die Daten, einem Validieren der Modellleistung auf einem separaten Satz von Daten, einem Sammeln der Ergebnisse, und einem Erzeugen von einem für Menschen lesbaren Text, für Menschen sichtbaren Zahlen und maschinenlesbaren Daten auf eine automatisierte Weise entsprechen. In einigen Beispielen sind die bei 402 empfangenen Parametereinstellungen den bei 112 gewählten Parametern ähnlich oder gleich, und umfassen, unter anderem, zum Beispiel für die Vorhersage verwendete Merkmale, das für die Validierung verwendete Zielmerkmal, die zum Trainieren und/oder Testen verwendete Zielvariable (die gemäß den hier beschriebenen Proxy-Zieltechniken unterschiedlich sein kann), die zum Trainieren und/oder Testen verwendeten Datentypen, den Typ des anzupassenden Modells (z. B. Poisson, Tweedie, negatives Binomial usw.), Merkmalauswahleinstellungen, oder Merkmalextraktionseinstellungen, oder Kombinationen davon.
Bei 404 empfängt der Modellgenerator 102 eine Beschreibung jedes Teilexperiments im Rechenexperiment. Die Beschreibung eines Teilexperiments kann zum Beispiel eine Beschreibung eines konkreten Satzes von Parametereinstellungen umfassen, die im Teilexperiment anzuwenden sind. In einigen Beispielen verwendet ein Benutzer der Client-Vorrichtung 106 eine Software-Bibliothek, um zum Beispiel JSON-Beschreibungen (JavaScript Object Notation) der Teilexperimente zu kodieren. In einigen Beispielen umfasst jedes Teilexperiment eine Auswertung von 10 Bootstrap-Resamples der gleichen Parametereinstellungen, obwohl eine andere Anzahl von Resamples durch den Benutzer spezifiziert werden kann.
Sobald die Beschreibungen der Teilexperimente empfangen wurden, werden die Teilexperimente in eine Arbeitswarteschlange 452 einer Rechenumgebung 450, wie z. B. einer Cloud-Rechenumgebung, eingefügt 406. Dies veranlasst die Instanziierung 408 einer oder mehrerer Recheninstanzen 454a, .., 454N (z. B. virtuelle Maschinen) innerhalb der Rechenumgebung 450. Jede Instanz ruft 410 dann ein Teilexperiment-Experiment für jede verfügbare Pipeline ab. In einigen Beispielen führt eine Instanz so viele Pipelines aus, wie durch die zugrunde liegenden Rechenressourcen, wie z. B. die Kernanzahl und den verfügbaren Speicher, unterstützt werden können. Nachdem ein Teilexperiment abgerufen wurde, verarbeitet 412 jede Instanz das Teilexperiment. Ein Verarbeiten eines Teilexperiments umfasst ein Extrahieren und Modifizieren von Merkmalen aus gefilterten Trainingsdaten durch ein probabilistisches Modell, und anschließendes Validieren anhand von Testdaten. In einigen Beispielen lässt sich jede Operation (z. B. Merkmalextraktion, Merkmalmodifikation, Datensatzauswahl, Datenfilterung, Auswahl des probabilistischen Modells, (Proxy-)Zielvariablen zum Testen und Trainieren usw.) durch das Teilexperiment konfigurieren.
Wenn die Teilexperimente verarbeitet werden, werden Ergebnisse für jede Bootstrap-Resample in einem Speichersystem, wie z. B. dem Speichersystem 104 oder einem anderen Speichersystem (z. B. einer Cloud-Datenbank, einem Cloud-Speicher, einem über ein Netzwerk angeschlossenen Speicher usw.) gespeichert 414. Beim Beenden eines Teilexperiments bestimmt 416 die Instanz, ob in der Warteschlange Teilexperimente verbleiben. Wenn verbleibende Teilexperimente vorhanden sind, ruft die Instanz das nächste verfügbare Teilexperiment in der Warteschlange ab und wiederholt Operationen 412 bis 416. Wenn andererseits keine verbleibenden Teilexperimente vorhanden sind, beendet sich 418 die Instanz selbst. Durch Instanziieren von Recheninstanzen nur bei Bedarf und Beenden der Instanzen, wenn die Arbeit abgeschlossen ist, erhöht der Prozess 400 die Recheneffizienz und minimiert die Gesamtkosten für die Durchführung von Experimenten (insbesondere, wenn der Prozess 400 in einer kommerziellen Cloud-Rechenumgebung ausgeführt wird).
Nach Abschluss des Rechenexperiments und seiner Teilexperimente werden die Ergebnisse in einer einzigen Datei kombiniert (z. B. durch die letzte verbleibende Instanz oder einen separaten Prozessor in der Rechenumgebung 450) und in einem Speichersystem gespeichert. Die Ergebnisdatei kann dann verarbeitet werden, um eine oder mehrere Ausgaben zu erzeugen, wie z. B. Lift-Diagramme mit Lift-Statistiken und Konfidenzintervallen. Auf diese Weise erhält ein Benutzer schnell Konfidenzintervalle für ein statistisches Modell (neben anderen Leistungsdaten), was seine Fähigkeit verbessert, das Modell zu analysieren und es mit anderen Modellen zu vergleichen.
Die hier beschriebenen Bootstrapping-Techniken erleichtern außerdem eine Suche nach Hyperparametern. Ein Benutzer (z. B. ein Analyst) befindet sich häufig in der Situation, in der er versucht, mehrere Parameter gleichzeitig für seine Merkmale anzupassen. Zum Beispiel will der Benutzer möglicherweise gleichzeitig den besten Teilsatz von Merkmalen wählen, die zum Erzeugen des Modells verwendet werden, den Modelltyp wählen, ob ein Merkmal direkt oder sein Logarithmus verwendet werden soll, ob Extremwerte eines Merkmals abgeschnitten werden sollen, um Ausreißer zu entfernen, und wenn ja, den Schwellenwert für die Abrundung wählen.
Eine Lösung für Hyperparameter-Suchprobleme dieser Art kann langsam oder unmöglich sein, da die Dimensionalität des Suchraums exponentiell mit der Anzahl der anzupassenden Parameter wächst. Anstatt jedoch eine einzelne, hochgenaue Konfidenzintervallberechnung (oder eine andere Berechnung) durchzuführen, können die hier beschriebenen Techniken verwendet werden, um Tausende von Experimenten mit geringerer Genauigkeit durchzuführen. Der beste Satz von Parametern kann dann schnell gefunden werden.
Wenn Tausende von Hypothesen ausgewertet werden, wird es außerdem zunehmend wahrscheinlicher, dass einige nicht-kausale Hypothesen gut abschneiden. Dieses Problem kann bis zu einem gewissen Grad durch eine bescheidene Menge von Bootstrap-Resampling angegangen werden. Zum Beispiel kann das System 250 Teilexperimente durchführen, jedes Teilexperiment 40 Mal erneut resampeln, und den Medianwert ermitteln, was so schnell wie ein einzelner 10.000-Bootstrap-Durchlauf ist und praktisch ist.
Merkmalslemen in großem Maßstab:
Bei der klassischen versicherungsstatistischen Risikomodellierung für Kraftfahrzeugversicherungen würde ein Fahrer durch eine Handvoll Variablen, wie z. B. Alter, Geschlecht, Postleitzahl und Kreditwürdigkeit, beschrieben. Dem Versicherungsstatistiker bleibt dann die Aufgabe, diese Variablen zu nutzen und sie zu regressieren, um die Anspruchszahl oder Anspruchskosten zu schätzen. Selbst bei Millionen von Fahrerpolicen war dieser Prozess aus rechnerischer Sicht vergleichsweise einfach.
In einem modernen Telematiksystem ist es jedoch vertretbar, pro jede Fahrsekunde 1000 Fahrvariablen zu sammeln. Über einen Bewertungszeitraum von mehreren Monaten bis zu einem Jahr kann ein typischer Fahrer problemlos eine Milliarde Variablen generieren. Die traditionellen Methoden der Merkmalentwicklung sind nicht mehr anwendbar.
Ein Ansatz besteht darin, Intuition zu verwenden, um ein einfaches Merkmal aus den Daten zu extrahieren (z. B. „Vielleicht ist starkes Bremsen gefährlich?“), es zur Liste der anderen Variablen hinzuzufügen und zu prüfen, ob sich die Vorhersageleistung verbessert. Dieser Ansatz wird durch die rechnerische und statistische Komplexität des Umgangs mit den Daten in vollem Umfang bedingt.
5 zeigt einen Prozess 500 zum Merkmallernen gemäß einem Aspekt der Offenbarung. Der Prozess 500 ist darauf ausgelegt, große Mengen an Low-Level-Daten zu verbrauchen, um in kurzer Zeit eine standardisierte Ausgabe zu erzeugen, wodurch Benutzer bei der Entwicklung neuer Merkmale zur Verbesserung einer Modellleistung unterstützt werden. In einigen Beispielen wird der Prozess 500 durch den Modellgenerator 102 (neben anderen Komponenten des Systems 100, wie z. B. dem Speichersystem 104 und/oder der Client-Vorrichtung 106) ausgeführt. In einigen Beispielen wird der Prozess 500 durch eine Rechenumgebung (wie z. B. die Rechenumgebung 450) allein oder in Kombination mit dem Modellgenerator 102 ausgeführt.
Operationen des Prozesses 500 umfassen ein Empfangen 502 einer Spezifikation einer Risikofunktion. In einigen Beispielen handelt es sich bei der Risikofunktion um ein Stück Software, die durch einen Benutzer (z. B. einen Benutzer der Client-Vorrichtung 106) definiert wird und die Telematikdaten einer Fahrt als eine Eingabe verwendet und Risikopunkte ausgibt. Die Risikofunktion kann zum Beispiel ein Stück Software sein, die die Gesamtzahl von Sekunden zählt, in denen die Geschwindigkeit des Fahrzeugs 50 Meilen pro Stunde überschreitet, oder die die Anzahl von Linksabbiege-Manövern während einer Fahrt zählt, wobei ein Linksabbiege-Manöver auf eine genaue Art und Weise definiert ist. Bei 504 wird eine Anfrage zum Auswerten der Risikofunktion für ein spezifiziertes Korpus von Telematikdaten empfangen, um einen aufgezählten Satz von Leistungsmetriken zu erzeugen. In einigen Beispielen umfassen die Leistungsmetriken unter anderem einen Lift, eine AUC oder einen Gini-Index (z. B. ein Maß für die statistische Streuung) oder Kombinationen davon.
Das Telematikdatenkorpus wird in einen oder mehrere Teile aufgeteilt 506. Eine oder mehrere Recheninstanzen 550a, ..., 550N (z. B. virtuelle Maschinen) werden instanziiert 508, und jeder Instanz werden die Risikofunktion, Leistungsmetriken und ihr Teil des Korpus übergeben. Bei 510 wertet jede Recheninstanz die Risikofunktion für alle Telematikdaten in ihrem Teil des Korpus (oder alle Fahrten in ihrem Teil des Korpus) aus. Wenn die Auswertung der Risikofunktion abgeschlossen ist, speichert 512 die Instanz die Ergebnisse der Auswertung (z. B. die Risikopunkte) in einem Speichersystem, wie z. B. dem Speichersystem 104 oder einem anderen Speichersystem (z. B. einer Cloud-Datenbank, einem Cloud-Speicher, einem über ein Netzwerk angeschlossenen Speicher usw.).
Bei 514 bestimmt die Instanz, ob verbleibende Instanzen vorhanden sind, die die Risikofunktion weiterhin auswerten. Wenn mindestens eine Instanz verbleibt, beendet 516 sich die Instanz selbst, um den Verbrauch von Rechenressourcen zu reduzieren und die Kosten zu minimieren. Wenn keine verbleibenden Instanzen vorhanden sind (z. B. ist die Instanz die letzte Instanz), aggregiert 518 dann die Instanz die im Speichersystem für jede Instanz gespeicherten Risikopunkte und wertet 520 die Leistung der Risikofunktion aus, indem die spezifizierten Leistungsmetriken aus den aggregierten Ergebnissen abgeleitet werden. In einigen Beispielen werden die Risikopunkte aggregiert und die Leistung der Funktion wird durch einen anderen Prozessor, der von den Instanzen separat ist, ausgewertet. Bei 522 werden die Leistungsmetriken an den Benutzer (z. B. über eine auf der Client-Vorrichtung 106 angezeigte GUI) geliefert.
Der Prozess 500 ist zum Auswerten einer einzelnen Risikofunktion geeignet. Um die Parameter für eine Risikofunktion zu optimieren, kann ein in 6 dargestellter Prozess 600 verwendet werden. In einigen Beispielen wird der Prozess 600 durch den Modellgenerator 102 (neben anderen Komponenten des Systems 100, wie z. B. dem Speichersystem 104 und/oder der Client-Vorrichtung 106) ausgeführt. In einigen Beispielen wird der Prozess 600 durch eine Rechenumgebung (wie z. B. die Rechenumgebung 450) allein oder in Kombination mit dem Modellgenerator 102 ausgeführt.
Operationen des Prozesses 600 umfassen ein Empfangen 602 einer Spezifikation einer Risikofunktion und eines Satzes von Parametern zur Optimierung. Zum Beispiel kann die Risikofunktion ein Stück Software sein, die die Gesamtzahl von Sekunden zählt, in denen die Geschwindigkeit des Fahrzeugs X Meilen pro Stunde überschreitet, wobei X ein Parameter ist. In einigen Beispielen kann der für die Risikofunktion spezifizierte Satz von Parametern Anfangswerte aufweisen. Bei 604 wird eine Anfrage zum Auswerten der Risikofunktion für ein spezifiziertes Korpus von Telematikdaten empfangen, um einen aufgezählten Satz von Leistungsmetriken zu erzeugen. In einigen Beispielen umfassen die Leistungsmetriken unter anderem einen Lift, eine AUC oder einen Gini-Index (z. B. ein Maß für die statistische Streuung) oder Kombinationen davon.
Das Telematikdatenkorpus wird in einen oder mehrere Teile aufgeteilt 606. Eine oder mehrere Recheninstanzen 650a, ..., 650N (z. B. virtuelle Maschinen) werden instanziiert 608, und jeder Instanz werden die Risikofunktion und ihre Parameter, Leistungsmetriken und ihr Teil des Korpus übergeben. Bei 610 wertet jede Recheninstanz die Risikofunktion unter Verwendung der Anfangsparameterwerte für alle Telematikdaten in ihrem Teil des Korpus (oder alle Fahrten in ihrem Teil des Korpus) aus. Jede Instanz berechnet 612 außerdem einen Gradienten der Parameter in Bezug auf eine Zielmetrik zum Beispiel unter Verwendung einer automatischen Differenzierung. In diesem Kontext ist die Zielmetrik eine Funktion der Risikopunkte und des Anspruchsstatus des Teils von Telematikdaten oder der Fahrt (z. B. hat der Fahrer einen Anspruch verursacht?). In einigen Beispielen können die Parameter aktualisiert werden, bevor alle Gradienten berechnet wurden. Bei 614 speichert die Instanz die Ergebnisse der Auswertung (z. B. die Risikopunkte) in einem Speichersystem, wie z. B. dem Speichersystem 104 oder einem anderen Speichersystem (z. B. einer Cloud-Datenbank, einem Cloud-Speicher, einem über ein Netzwerk angeschlossenen Speicher usw.). In einigen Beispielen speichert die Instanz außerdem den bei 612 berechneten Gradienten der Parameter.
Bei 616 summiert die Instanz die Gradienten und aktualisiert die Parameter. Als nächstes bestimmt 618 die Instanz, ob ein Zeit-, Schritt- und/oder Qualitätsschwellenwert überschritten wurde. Falls nein, kehrt die Instanz zu 610 zurück und wiederholt 610 bis 618 mit den aktualisierten Parametern. Wenn hingegen einer oder mehrere der Schwellenwerte überschritten wurden (z. B. weil die Instanz das schrittweise Durchlaufen der Parameter abgeschlossen hat, ihre zugewiesene Verarbeitungszeit überschritten hat, oder einen Qualitätsschwellenwert nicht mehr erfüllt), fährt die Instanz mit 620 fort, wo bestimmt wird, ob noch verbleibende Instanzen vorhanden sind, die die Risikofunktion weiterhin auswerten. Wenn mindestens eine Instanz verbleibt, beendet 622 sich die Instanz selbst, um den Verbrauch von Rechenressourcen zu reduzieren und die Kosten zu minimieren. Wenn keine verbleibenden Instanzen vorhanden sind (z. B. ist die Instanz die letzte Instanz), aggregiert 624 dann die Instanz die im Speichersystem für jede Instanz gespeicherten Risikopunkte und wertet 626 die Leistung der Risikofunktion aus, indem die spezifizierten Leistungsmetriken aus den aggregierten Ergebnissen abgeleitet werden. In einigen Beispielen werden die Risikopunkte aggregiert und die Leistung der Funktion wird durch einen anderen Prozessor, der von den Instanzen separat ist, ausgewertet. Bei 628 werden die Leistungsmetriken an den Benutzer (z. B. über eine auf der Client-Vorrichtung 106 angezeigte GUI) geliefert.
In einigen Beispielen können die für das Merkmallernen sowie die Modellerstellung und -auswertung verwendeten Korpora verbessert werden, um die Leistung und Effizienz der hier beschriebenen Techniken zu steigern. Das klassische Datenkorpus umfasst alle Fahrten, die durch eine Population von Fahrern unternommen wurden, zusammen mit deren zukünftigem Anspruchsverlauf. Das Datenkorpus kann zum Beispiel alle Fahrten umfassen, die die Population von Fahrern während eines Zeitraums von sechs Monaten unternommen hat, und die Anzahl oder Kosten von Ansprüchen, die sie in den folgenden sechs Monaten verursacht haben, können vorhergesagt werden. In den in 5 und 6 dargestellten Prozessen 500 und 600 wird ein Risiko für jede Fahrt erzeugt, und diese einzelnen Risikopunkte werden aggregiert (z. B. durch Summieren), um eine aggregierte Risikopunktzahl für jeden Fahrer zu erzeugen.
Jedoch bestehen einige alternative Verfahren zum Erstellen von Korpora. Erstens sind Versicherungsansprüche selten, so dass unverhältnismäßig viel Zeit für die Analyse „sicherer“ Fahrer (z. B. Fahrer ohne Ansprüche) aufgewendet wird. Stattdessen kann der Satz von Fahrern resampelt werden, so dass diejenigen mit und ohne Ansprüche nahezu oder genau gleich sind. Dadurch kann in einigen realen Datensätzen die Größe des Datenkorpus um ungefähr das 100-fache reduziert werden, was die Zeit und die Rechenressourcen reduziert, die für die Durchführung von Datenoperationen erforderlich sind. In einigen Beispielen kann auch ein Erstellen eines Modells auf der Grundlage ausgewogener Daten die Modellleistung verbessern.
Alternativ können Telematikkollisionen und Ansprüche kombiniert werden, um die genaue Fahrt zu bestimmen, die einen Anspruch generiert hat. Beim Bewerten von Umweltfaktoren, die ein Risiko direkt hervorrufen (z. B. unsicheres Wetter), können die Daten ein Modell erzeugen, das wesentlich prädiktiver ist. Außerdem kann die Datengröße im Vergleich mit dem ursprünglichen Datenkorpus um das 10.000-fache reduziert werden. Es ist zu beachten, dass ein Merkmal unter Verwendung eines Proxy-Ziels entwickelt und dann unter Verwendung von Ansprüchen validiert werden kann, wenn das System zweimal verwendet wird.
Wie vorstehend besprochen, können die Daten-Samples zwischen Fahrern mit und ohne Ansprüche ausgeglichen werden, um die Größe des Datenkorpus und die Zeit, die für die Analyse „sicherer“ Fahrer aufgewendet wird, zu reduzieren. Dieses Resampling führt jedoch zu einer Verzerrung der Leistungsmetriken. Um unvoreingenommene Ergebnisse zu erzeugen, die für das ursprüngliche Problem geeignet sind, sollten die Leistungsmetriken unverstellt bleiben. Wenn zum Beispiel ein Bruchteil A sicherer Fahrer und ein Bruchteil B riskanter Fahrer gesampelt werden (mit einer typischen Verteilung von A«B), kann dann jedem sicheren Fahrer bei der Durchführung von Leistungsmessungen (z. B. durch Erstellen eines Lift-Diagramms) ein Gewicht von 1/A zugewiesen werden und jedem riskanten Fahrer kann ein Gewicht von 1/B zugewiesen werden. Gleichermaßen kann auch eine Gewichtung angewendet werden, um die Exposition in Situationen zu normalisieren, in denen Fahrer unterschiedliche Expositionen aufweisen.
Reproduzierbare Datenpipelines:
Eine Datenpipeline zum Erstellen eines Vorhersagemodells umfasst ein Sammeln verschiedener Datentypen aus verschiedenen Quellen. Die Eingabe in eine solche Pipeline kann zum Beispiel neben anderen Daten Dateien mit Anspruchsdaten (z. B. Anspruchsanzahl oder Anspruchskosten) zusammen mit Expositionszeiträumen für Versicherungspolicen; Telematikdaten für Fahrten der Fahrer in diesen Zeiträumen, wie z. B. Risikopunkte, Kilometerstand, und Fahrtdatum; Daten, die Fahrer-IDs mit entsprechenden Versicherungspolicen verknüpfen, umfassen. Alle dieser Daten können in mehreren Formen auftreten. Zum Beispiel können Ansprüche von mehreren verschiedenen Versicherungsanbietern, mit jeweils einem separaten Dateiformat und Datenschema, kombiniert werden.
Diese Dateien müssen bereinigt, in ein gemeinsames Schema konvertiert, zusammengeführt und das fahrtübergreifende Risiko muss in ein Risiko pro Fahrer und Bewertungszeitraum aggregiert werden. Ein Risiko kann auch auf andere Weise aggregiert werden, z. B. nach Fahrzeug und Bewertungszeitraum oder Versicherungspolice und Bewertungszeitraum. Die Ausgabe der Datenpipeline ist eine Designmatrix. Die Zeilen entsprechen Fahrerperioden (z. B. ein einzelner Fahrer für eine festgelegte Zeitspanne), und die Spalten entsprechen beobachteten Merkmalen (z. B. Zeitdauer von Geschwindigkeitsüberschreitungen oder Anzahl von Ereignissen starken Bremsens), Zielvariablen (z. B. Anspruchsanzahl, Anspruchskosten oder ein Proxy-Ziel), Exposition (z. B. Anzahl von Versicherungstagen oder Anzahl von Tagen der Datenerfassung). Es können mehrere Designmatrizen erzeugt werden, die Test- versus Trainingsdaten oder unterschiedlichen Populationen von Fahrern entsprechen.
Beim Entwickeln eines Risikomodells treten neue Datenquellen auf, die in die Datenpipeline integriert werden müssen. Des Weiteren werden in der Regel Missgeschicke bei der anfänglichen Datenverarbeitung aufgedeckt, was die Hinzufügung zusätzlicher Filter- und Datenbereinigungsschritte während des gesamten Prozesses erfordert.
Wenn das Risikomodell entwickelt wird, ändern sich in der Regel die Zwischendaten und die endgültige Designmatrix. Wenn ein versicherungsstatistisches Team die Entwicklung des Risikomodells abgeschlossen hat, erstellt es ein Modell unter Verwendung der aktuell besten Designmatrix. In den Vereinigten Staaten wird ein Dokument, das dieses Modell beschreibt, beim Department of Insurance (DOI) in jedem Staat, in dem ein Versicherer das Modell verwenden möchte, eingereicht.
Um Fragen von DOIs zu beantworten und um jegliche potenziellen rechtlichen Anfragen zu beantworten, ist es unbedingt erforderlich, dass die beim Erstellen des Modells verwendeten Daten verfügbar bleiben. Es ist nicht ausgeschlossen, dass DOI ein Jahr oder länger nach der Einreichung eine Frage stellt, die eine Analyse der zugrunde liegenden Daten erfordert.
Aufgrund des komplexen und dynamischen Charakters der Datenpipeline und weil die weitere Entwicklung typischerweise nach der Modelleinreichung fortgesetzt wird (z. B. zur Unterstützung einer zukünftigen Generation von Risikomodellen), ist es möglich, dass Versicherungsstatistiker den Überblick über die konkrete Version der Daten verlieren, die sie für eine konkrete Einreichung verwendeten. Wenn ein Modell auf einer konkreten Designmatrix trainiert wird, aber viele Designmatrizen erzeugt werden, gibt es außerdem möglicherweise keine natürliche Möglichkeit, eine konkrete Designmatrix mit den Daten zu verknüpfen, die sie generiert haben. Da die Dateien sehr groß sind und die Verarbeitungszeit viele Stunden in Anspruch nehmen kann, werden schließlich Analysten davon abgehalten, saubere, gekennzeichnete Kopien ihrer Daten zu archivieren.
In solchen Situationen kann es unmöglich werden, die genauen Daten zu finden oder zu reproduzieren, die zum Erstellen eines konkreten Modells verwendet wurden. Im schlimmsten Fall kann ein Modell für regulatorische Zwecke unbrauchbar werden, da die verwendeten spezifischen Daten nicht wiederhergestellt werden können, was einen jahrelangen versicherungsstatistischen Aufwand zunichtemachen kann.
7 zeigt einen Beispielprozess 700 zum Generieren einer reproduzierbaren Datenpipeline. In einigen Beispielen wird der Prozess 700 durch den Modellgenerator 102 (neben anderen Komponenten des Systems 100, wie z. B. dem Speichersystem 104 und/oder der Client-Vorrichtung 106) ausgeführt.
Operationen des Prozesses 700 umfassen ein Definieren 702 eines Satzes von Transformationen in einer Software, die einen Satz von Eingabedateien in einen Satz von Ausgabedateien transformieren. Auf der Grundlage des Satzes von Transformationen wird ein gerichteter Graph generiert 704, der die Beziehungen zwischen allen Eingabe-, Zwischen- und Ausgabedateien beschreibt. In einigen Beispielen wird der gerichtete Graph automatisch analysiert, um sicherzustellen, dass er einen gerichteten azyklischen Graphen (DAG) bildet (z. B. einen gerichteten Graphen ohne Zyklen). Ein Beispiel-DAG 800 ist in 8 dargestellt. Bei 706 wird eine topologische Sortierung des DAG durchgeführt, um eine konsistente Reihenfolge, in der die Transformationen anzuwenden sind, zu erzeugen, die ihre Eingabe-zu-Ausgabe-Beziehungen berücksichtigt.
Für alle Eingabedateien werden kryptografische Hashes berechnet 708. Zum Beispiel wird ein Satz von Eingabedateien, die in einer Cloud-Speicherumgebung gespeichert sind, identifiziert und an einen bestimmten Ort kopiert, und kryptografische Hashes werden für diese Dateien berechnet. Die kryptografischen Hashes unterscheiden verschiedene Dateien mit einer sehr hohen Wahrscheinlichkeit. Zum Beispiel kann ein SHA-256-Hash verwendet werden, wobei in diesem Fall die Wahrscheinlichkeit, zwei verschiedene Zufallsdateien nicht zu unterscheiden, geringer ist als 10^-77. Bei 710 wird jede Transformation in der durch die topologische Sortierung spezifizierten Reihenfolge angewendet, wobei ein Hash der Eingabefunktionen und ein Hash des Codes, der die Transformation spezifiziert, für jede Transformation berechnet werden. Diese Transformationen werden kanonisch sortiert und erneut gehasht, um einen Hash für den „Elternteil“ jeder Ausgabedatei zu erzeugen 712. Die Ausgabedateien selbst können zu Eingaben für nachgelagerte Transformationen werden, und die Hash-Kette wird verfolgt 714. Bei 716 wird bestimmt, ob weitere Transformationen angewendet werden sollen. Wenn weitere Transformationen vorhanden sind, wiederholt der Prozess 700 Operationen 710 bis 716, bis alle Transformationen in der richtigen Reihenfolge angewendet wurden. Nachdem alle Transformationen angewendet wurden, werden der vollständige Satz von Ausgaben und die Aufzeichnung der kryptografischen Hashes jeder Datei in einem Speichersystem (z. B. dem Speichersystem 104 oder einem anderen Speichersystem, wie z. B. einem Cloud-Speichersystem) gespeichert 718. In einigen Beispielen wird die Aufzeichnung sowohl in einer Log-Datei als auch in Metadaten selbst, die mit jeder Datei assoziiert sind, gespeichert. Bei 720 wird ein endgültiger kryptografischer Hash aller Dateien und Transformationen berechnet, um eine einzige Signatur der gesamten Datenpipeline bereitzustellen.
Bei nachfolgenden Durchläufen kann der Modellgenerator 102 versuchen, die Änderungen an der Datenpipeline zu analysieren, um die Anzahl von kryptografischen Hashes zu reduzieren, die neu berechnet werden müssen. Bevor eine Transformation angewendet wird, werden zum Beispiel die Hashes der Eingabedateien und der Transformation neu berechnet. Der „Eltemteil“-Hash jeder Ausgabedatei wird untersucht, und wenn jener Hash unverändert ist, dann kann die Transformation ohne eine Änderung der Ausgabe übersprungen werden.
In einigen Beispielen ist der Ausgabeort für die Ausgaben und die Aufzeichnung der kryptografischen Hashes konfigurierbar. Dadurch können mehrere unterschiedliche Datensätze und Datenpipelines nebeneinander existieren, ohne dass sie sich gegenseitig stören. In einigen Beispielen kann die Ausgabe des Prozesses 700 in den hier beschriebenen Bootstrap-Prozess eingespeist werden. Durch Verfolgen des Ausgabeorts und des endgültigen kryptografischen Hashes wird automatisch ein Prüfpfad generiert, der beschreibt, welche Daten verwendet wurden. Wenn ein Risikomodell zur Einreichung bereit ist, kann das Ausgabeverzeichnis eingefroren werden (z. B. dürfen die Daten nicht mehr geändert oder ergänzt werden).
Da die Eingabedateien in das Ausgabeverzeichnis kopiert werden, ist es möglich, die gesamte Datenpipeline zu reproduzieren. Des Weiteren ist es durch den automatisierten Vergleich von Hashes möglich, das Ausgabeverzeichnis automatisch zu untersuchen und (mit extrem hoher Wahrscheinlichkeit, z. B. abgesehen von kryptografischen Hash-Kollisionen) zu garantieren, dass sich nichts geändert hat.
Der Prozess 700 beschreibt eine topologische Sortierung zum Anwenden der Transformationen (z. B. wird die Reihenfolge der Transformationen in einer Weise serialisiert, die den DAG respektiert). Es ist jedoch möglich, den DAG automatisch zu untersuchen und Transformationen abzuleiten, die sicher parallel durchgeführt werden können. Das einfachste Verfahren wäre, alle Transformationen in jeder Schicht des DAG gleichzeitig durchzuführen, aber weitere Optimierungen sind möglich. Diese Parallelisierung führt eine logisch und funktional äquivalente Operation zur seriellen Version durch, kann jedoch die Verarbeitungszeit reduzieren. Des Weiteren kann es für einen Versicherungsstatistiker schwierig sein, einen effizienten parallelisierten Zeitplan für das Anwenden von Transformationen zu bestimmen, wobei dieses System diesbezüglich sogar eine optimale, von Menschen verwaltete Datenpipeline übertreffen würde.
9 zeigt ein Ablaufdiagramm eines Beispielprozesses 900 zum Erstellen und Auswerten eines statistischen Modells. In einigen Beispielen sind die elektronische(n) Vorrichtung(en), das (die) System(e), oder die Komponente(n) oder Abschnitte oder Implementierungen davon, von 1 bis 8, derart ausgelegt, dass sie den Prozess 900 durchführen, wie z. B. der Modellgenerator 102.
Operationen des Prozesses 900 umfassen ein Empfangen 902 von Telematikdaten und Versicherungsanspruchsdaten für eine Population von Fahrern. In einigen Beispielen wird mindestens ein Abschnitt der Telematikdaten durch eine Telematikvorrichtung oder eine mobile Vorrichtung, die in einem Fahrzeug eines Fahrers in der Population von Fahrern angeordnet ist, erfasst. In einigen Beispielen werden andere Daten, wie z. B. demografische Informationen über einen Fahrer oder Versicherungsnehmer empfangen.
Ein Trainingsdatensatz zum Trainieren eines statistischen Modells wird auf der Grundlage der Telematikdaten generiert 904. Der Trainingsdatensatz kann Werte für eine aus den Telematikdaten abgeleitete Proxy-Variable und Werte für ein oder mehrere aus den Telematikdaten abgeleitete Merkmale zum Vorhersagen der Proxy-Variablen umfassen. In einigen Beispielen umfasst die Proxy-Variable unter anderem Telematikkollisionen, starkes Bremsen, starke Beschleunigung, Telefonablenkung, Geschwindigkeitsüberschreitung oder Kombinationen davon.
Ein Testdatensatz zum Validieren des statistischen Modells wird auf der Grundlage der Telematikdaten und der Anspruchsdaten generiert 906. Der Testdatensatz kann Werte für eine aus den Anspruchsdaten abgeleitete Proxy-Variable und Werte für das eine oder die mehreren aus den Telematikdaten abgeleiteten Merkmale umfassen. In einigen Beispielen umfassen Werte für die Zielvariable, die im Testdatensatz aufgenommen sind, eine Anzahl von Versicherungsansprüchen für einen konkreten Expositionszeitraum oder Kosten von Versicherungsansprüchen für einen konkreten Expositionszeitraum, oder beides.
Das statistische Modell wird unter Verwendung des Trainingsdatensatzes generiert 908. Zum Beispiel kann eine Regressionsanalyse auf den Trainingsdatensatz angewendet werden, um das statistische Modell an den Trainingsdatensatz anzupassen. Auf diese Weise wird das statistische Modell dazu ausgelegt, Werte der Proxy-Variable aus Werten des einen oder der mehreren Merkmale vorherzusagen.
Nach dem Generieren des statistischen Modells, wird das Modell unter Verwendung des Testdatensatzes validiert 910. In einigen Beispielen umfasst das Validieren des statistischen Modells unter Verwendung des Testdatensatzes: Anwenden der Werte des einen oder der mehreren Merkmale, die im Testdatensatz aufgenommen sind, auf das statistische Modell, um Werte für die Proxy-Variable für jeden Fahrer in der Population von Fahrern zu bestimmen; Bestimmen einer Verteilung der Werte für die Proxy-Variable für jeden Fahrer in der Population von Fahrern; und Abbilden der Werte für die Zielvariable im zweiten Datensatz auf die Verteilung. In einigen Beispielen umfasst das Validieren des statistischen Modells unter Verwendung des Testdatensatzes ein Generieren, neben anderen Leistungsmetriken, eines Lift-Diagramms, Berechnen einer Lift-Statistik, oder Berechnen einer Flächen-ROC-Kurve (z. B. AUC), oder Kombinationen von diesen. Jede dieser Statistiken kann einem Benutzer (z. B. einem Analysten) zum Beispiel in einer grafischen Benutzeroberfläche angezeigt werden.
10 ist ein Blockdiagramm eines Beispielcomputersystems 1000. Zum Beispiel könnte unter Bezugnahme auf 1 der Modellgenerator 102 ein Beispiel des hier beschriebenen Systems 1000 sein, ebenso wie ein Computersystem, das von einem der Benutzer verwendet wird, die auf Ressourcen dieser Komponenten zugreifen (z. B. die Client-Vorrichtung 106). Das System 1000 umfasst einen Prozessor 1010, einen Speicher 1020, eine Speichervorrichtung 1030 und eine oder mehrere Eingabe-/Ausgabeschnittstellenvorrichtungen 1040. Jede der Komponenten 1010, 1020, 1030 und 1040 kann zum Beispiel unter Verwendung eines Systembusses 1050 miteinander verbunden werden.
Der Prozessor 1010 ist in der Lage, Anweisungen zum Ausführen innerhalb des Systems 1000 zu verarbeiten. Der Begriff „Ausführung“ bezieht sich, wie hier verwendet, auf eine Technik, in der ein Programmcode einen Prozessor dazu veranlasst, eine oder mehrere Prozessoranweisungen auszuführen. In einigen Implementierungen ist der Prozessor 1010 ein Single-Thread-Prozessor. In einigen Implementierungen ist der Prozessor 1010 ein Multi-Thread-Prozessor. Der Prozessor 1010 ist in der Lage, im Speicher 1020 oder in der Speichervorrichtung 1030 gespeicherten Anweisungen zu verarbeiten. Der Prozessor 1010 kann Operationen ausführen, wie z. B. jene, die unter Bezugnahme auf 4 bis 7 und 9 und beschrieben wurden.
Der Speicher 1020 speichert Informationen innerhalb des Systems 1000. In einigen Implementierungen ist der Speicher 1020 ein computerlesbares Medium. In einigen Implementierungen ist der Speicher 1020 eine flüchtige Speichereinheit. In einigen Implementierungen ist der Speicher 1020 eine nichtflüchtige Speichereinheit.
Die Speichervorrichtung 1030 ist in der Lage, einen Massenspeicher für das System 1000 bereitzustellen. In einigen Implementierungen ist die Speichervorrichtung 1030 ein nichttransitorisches computerlesbares Medium. In verschiedenen unterschiedlichen Implementierungen kann die Speichervorrichtung 1030 zum Beispiel eine Festplattenvorrichtung, eine optische Plattenvorrichtung, ein Solid-State-Laufwerk, ein Flash-Laufwerk, ein Magnetband oder eine andere Speichervorrichtung mit großer Kapazität umfassen. In einigen Implementierungen kann die Speichervorrichtung 1030 eine Cloud-Speichervorrichtung sein, z. B. eine logische Speichervorrichtung, die eine oder mehrere physische Speichervorrichtungen umfasst, die in einem Netzwerk verteilt sind und auf die über ein Netzwerk zugegriffen wird. In einigen Beispielen kann die Speichervorrichtung Langzeitdaten speichern. Die Eingabe-/Ausgabeschnittstellenvorrichtungen 1040 stellen Eingabe-/Ausgabeoperationen für das System 1000 bereit. In einigen Implementierungen können die Eingabe-/Ausgabeschnittstellenvorrichtungen 1040 eines oder mehrere von einer Netzwerkschnittstellenvorrichtung, z. B. eine Ethernet-Schnittstelle, einer seriellen Kommunikationsvorrichtung, z. B. eine RS-232-Schnittstelle, und/oder einer drahtlosen Schnittstellenvorrichtung, z. B. eine 802.11-Schnittstelle, ein 3G-Funkmodem, ein 4G-Funkmodem, ein 5G-Funkmodem usw., umfassen. Eine Netzwerkschnittstellenvorrichtung ermöglicht es dem System 1000, zu kommunizieren, zum Beispiel Daten zu senden und zu empfangen. In einigen Implementierungen kann die Eingabe-/Ausgabevorrichtung Treibervorrichtungen umfassen, die dazu ausgelegt sind, Eingabedaten zu empfangen und Ausgabedaten an andere Eingabe-/Ausgabevorrichtungen, z. B. Tastatur, Drucker und Anzeigevorrichtungen 1060, zu senden. In einigen Implementierungen können mobile Rechenvorrichtungen, mobile Kommunikationsvorrichtungen und andere Vorrichtungen verwendet werden.
Ein Server, wie z. B. die in 1 dargestellten Server, kann auf verteilte Weise über ein Netzwerk implementiert werden, wie z. B. eine Serverfarm, oder eine Reihe weit verteilter Server, oder kann in einer einzelnen virtuellen Vorrichtung implementiert werden, die mehrere verteilte Vorrichtungen umfasst, die auf koordinierte Weise miteinander arbeiten. Zum Beispiel kann eine der Vorrichtungen die anderen Vorrichtungen steuern, oder die Vorrichtungen können nach einer Reihe koordinierter Regeln oder Protokolle arbeiten, oder die Vorrichtungen können auf andere Weise koordiniert werden. Der koordinierte Betrieb der mehreren verteilten Vorrichtungen erweckt den Anschein eines Betriebs als eine einzelne Vorrichtung.
In einigen Beispielen ist das System 1000 innerhalb eines einzelnen integrierten Schaltungsgehäuses aufgenommen. Ein System 1000 dieser Art, in dem sowohl ein Prozessor 1010 als auch eine oder mehrere andere Komponenten innerhalb eines einzelnen integrierten Schaltungsgehäuses aufgenommen sind und/oder als eine einzelne integrierte Schaltung hergestellt werden, wird zuweilen als ein Mikrocontroller bezeichnet. In einigen Implementierungen umfasst das integrierte Schaltungsgehäuse Anschlussstifte, die Eingabe-/Ausgabeanschlüssen entsprechen, die z. B. verwendet werden können, um Signale an eine oder mehrere der Eingabe-/Ausgabeschnittstellenvorrichtungen 1040 und von ihnen zu kommunizieren.
Obwohl ein Beispielverarbeitungssystem in 10 beschrieben wurde, können Implementierungen des Gegenstands und der funktionalen Operationen, die in dieser Beschreibungen beschrieben sind, in digitalen elektronischen Schaltungen, in greifbar verkörperter Computersoftware oder -firmware, in einer Computerhardware, einschließlich der in dieser Beschreibung offenbarten Strukturen und ihrer strukturellen Äquivalente, oder in Kombinationen von einem oder mehreren davon implementiert werden. Softwareimplementierungen des beschriebenen Gegenstands können als ein oder mehrere Computerprogramme implementiert werden. Jedes Computerprogramm kann ein oder mehrere Module von Computerprogrammanweisungen umfassen, die auf einem materiellen, nichttransitorischen, computerlesbaren Computerspeichermedium zur Ausführung durch Datenverarbeitungsvorrichtungen oder zur Steuerung des Betriebs von diesen codiert sind. Alternativ oder zusätzlich können die Programmanweisungen in/auf einem künstlich generierten Ausbreitungssignal kodiert sein. In einem Beispiel kann das Signal ein maschinengeneriertes elektrisches, optisches oder elektromagnetisches Signal sein, das generiert wird, um Informationen zur Übertragung an geeignete Empfängervorrichtungen zur Ausführung durch eine Datenverarbeitungsvorrichtung zu kodieren. Das Computerspeichermedium kann eine maschinenlesbare Speichervorrichtung, ein maschinenlesbares Speichersubstrat, eine Speichervorrichtung mit wahlfreiem oder seriellem Zugriff, oder eine Kombination aus Computerspeichermedien sein.
Die Begriffe „Datenverarbeitungsvorrichtung“, „Computer“, und „Rechenvorrichtung“ (oder Äquivalente, wie durch einen Durchschnittsfachmann verstanden) beziehen sich auf eine Datenverarbeitungshardware. Zum Beispiel kann eine Datenverarbeitungsvorrichtung alle Arten von Vorrichtungen, Geräten und Maschinen zum Verarbeiten von Daten umfassen, einschließlich von zum Beispiel einem programmierbaren Prozessor, einem Computer, oder mehreren Prozessoren oder Computern. Die Vorrichtung kann außerdem spezielle Logikschaltungen umfassen, einschließlich zum Beispiel einer zentralen Verarbeitungseinheit (CPU), eines Field Programmable Gate Arrays (FPGA) oder einer anwendungsspezifischen integrierten Schaltung (ASIC). In einigen Implementierungen können die Datenverarbeitungsvorrichtungen oder die speziellen Logikschaltungen (oder eine Kombination der Datenverarbeitungsvorrichtungen oder der speziellen Logikschaltungen) hardware- oder softwarebasiert (oder eine Kombination aus sowohl hardware- als auch softwarebasiert) sein. Die Vorrichtung kann optional einen Code umfassen, der eine Ausführungsumgebung für Computerprogramme erzeugt, zum Beispiel einen Code, der Prozessor-Firmware, einen Protokollstapel, ein Datenbankverwaltungssystem, ein Betriebssystem, oder eine Kombination von Ausführungsumgebungen bildet. Die vorliegende Offenbarung zieht die Verwendung von Datenverarbeitungsvorrichtungen mit oder ohne herkömmliche Betriebssysteme in Betracht, zum Beispiel LINUX, UNIX, WINDOWS, MAC OS, ANDROID oder IOS.
Ein Computerprogramm, das auch als ein Programm, eine Software, eine Softwareanwendung, ein Modul, ein Softwaremodul, ein Skript oder ein Code bezeichnet oder beschrieben werden kann, kann in jeder Form von Programmiersprache geschrieben sein. Programmiersprachen können zum Beispiel kompilierte Sprachen, interpretierte Sprachen, deklarative Sprachen oder prozedurale Sprachen umfassen. Programme können in jeder Form bereitgestellt werden, einschließlich als eigenständige Programme, Module, Komponenten, Unterprogramme oder Einheiten zum Verwenden in einer Computerumgebung. Ein Computerprogramm kann, muss aber nicht, einer Datei in einem Dateisystem entsprechen. Ein Programm kann in einem Abschnitt einer Datei gespeichert werden, die andere Programme oder Daten aufweist, zum Beispiel ein oder mehrere Skripte, die in einem Markup-Language-Dokument gespeichert sind, in einer einzelnen Datei, die dem betreffenden Programm gewidmet ist, oder in mehreren koordinierten Dateien, die ein oder mehrere Module, Unterprogramme oder Codeabschnitte speichern. Ein Computerprogramm kann zur Ausführung auf einem Computer oder auf mehreren Computern bereitgestellt werden, die sich zum Beispiel an einem Standort befinden oder über mehrere Standorte verteilt sind, die über ein Kommunikationsnetzwerk miteinander verbunden sind. Obwohl Abschnitte der in den verschiedenen Figuren dargestellten Programme als einzelne Module dargestellt sein können, die die verschiedenen Merkmale und Funktionen durch verschiedene Objekte, Methoden oder Prozesse implementieren, können die Programme stattdessen eine Reihe von Untermodulen, Diensten Dritter, Komponenten und Bibliotheken umfassen. Umgekehrt können die Merkmale und Funktionalität verschiedener Komponenten, soweit angemessen, zu einzelnen Komponenten zusammengefasst werden. Schwellenwerte, die für rechnerische Bestimmungen verwendet werden, können statisch, dynamisch oder sowohl statisch als auch dynamisch bestimmt werden.
Die in dieser Beschreibung beschriebenen Verfahren, Prozesse oder Logikabläufe können durch einen oder mehrere programmierbare Computer ausgeführt werden, die ein oder mehrere Computerprogramme ausführen, um Funktionen auszuführen, indem sie mit Eingabedaten arbeiten und Ausgaben generieren. Die Verfahren, Prozesse oder Logikabläufe können außerdem durch spezielle Logikschaltungen, zum Beispiel eine CPU, ein FPGA oder eine ASIC, ausgeführt werden und die Vorrichtung kann auch als diese implementiert werden.
Für die Ausführung eines Computerprogramms geeignete Computer können auf einem oder mehreren allgemeinen und speziellen Mikroprozessoren und anderen Arten von CPUs basieren. Die Elemente eines Computers sind eine CPU zum Durchführen oder Ausführen von Anweisungen und eine oder mehrere Speichervorrichtungen zum Speichern von Anweisungen und Daten. Im Allgemeinen kann eine CPU Anweisungen und Daten von einem Speicher empfangen (und Daten in diesen schreiben). Ein Computer kann außerdem eine oder mehrere Massenspeichervorrichtungen zum Speichern von Daten umfassen oder operativ mit diesen gekoppelt sein. In einigen Implementierungen kann ein Computer Daten von den Massenspeichervorrichtungen, die zum Beispiel magnetische, magnetooptische Platten oder optische Platten umfassen, empfangen und Daten an sie übertragen. Des Weiteren kann ein Computer in eine andere Vorrichtung eingebettet sein, zum Beispiel in ein Mobiltelefon, einen persönlichen digitalen Assistenten (PDA), einen mobilen Audio- oder Videoplayer, eine Spielekonsole, einen GPS-Empfänger (GPS: Global Positioning System), oder eine tragbare Speichervorrichtung, wie z. B. ein USB-Flash-Laufwerk (USB: Universal Serial Bus).
Computerlesbare Medien (wenn zutreffend transitorisch oder nicht-transitorisch), die zum Speichern von Computerprogrammanweisungen und -daten geeignet sind, können alle Formen von permanenten/nicht-permanenten und flüchtigen/nicht-flüchtigen Speichern, Medien und Speichervorrichtungen umfassen. Computerlesbare Medien können zum Beispiel umfassen: Halbleiterspeichervorrichtungen, wie z. B. einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen Phasenwechselspeicher (PRAM), einen statischen Direktzugriffsspeicher (SRAM), einen dynamischen Direktzugriffsspeicher (DRAM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), und Flash-Speichervorrichtungen. Computerlesbare Medien können zum Beispiel auch magnetische Vorrichtungen, wie z. B. Bänder, Einsätze, Kassetten und interne/wechselbare Platten umfassen. Computerlesbare Medien können außerdem magnetooptische Platten und optische Speichervorrichtungen und - technologien umfassen, darunter zum Beispiel DVD (Digital Video Disc), CD-ROM, DVD+/- R, DVD-RAM, DVD-ROM, HD-DVD und BLURAY. Der Speicher kann verschiedene Objekte oder Daten speichern, einschließlich von Caches, Klassen, Frameworks, Anwendungen, Modulen, Sicherungsdaten, Jobs, Webseiten, Webseitenvorlagen, Datenstrukturen, Datenbanktabellen, Datendepots und dynamischen Informationen. Im Speicher gespeicherte Objekt- und Datentypen können Parameter, Variablen, Algorithmen, Anweisungen, Regeln, Einschränkungen und Referenzen umfassen. Außerdem kann der Speicher Protokolle, Richtlinien, Sicherheits- oder Zugriffsdaten und Berichtsdateien umfassen. Der Prozessor und der Speicher können durch spezielle Logikschaltungen ergänzt oder in diese integriert sein.
Obwohl diese Beschreibung viele spezifische Implementierungseinzelheiten umfasst, sollten diese nicht als Einschränkungen des Umfangs dessen, was beansprucht werden kann, ausgelegt werden, sondern vielmehr als Beschreibungen von Merkmalen, die für konkrete Implementierungen spezifisch sein können. Bestimmte Merkmale, die in dieser Beschreibung im Kontext separater Implementierungen beschrieben werden, können auch, in Kombination, in einer einzelnen Implementierung implementiert werden. Umgekehrt können verschiedene Merkmale, die im Kontext einer einzelnen Implementierung beschrieben werden, auch in mehreren Implementierungen, einzeln oder in jeder geeigneten Teilkombination implementiert werden. Des Weiteren können, obwohl zuvor beschriebene Merkmale als in bestimmten Kombinationen wirkend beschrieben und sogar ursprünglich als solche beansprucht werden, ein oder mehrere Merkmale aus einer beanspruchten Kombination, in manchen Fällen, aus der Kombination entfernt werden, und die beanspruchte Kombination kann auf eine Teilkombination oder eine Abwandlung einer Teilkombination ausgerichtet sein.
Konkrete Implementierungen des Gegenstands wurden beschrieben. Andere Implementierungen, Änderungen und Permutationen der beschriebenen Implementierungen liegen innerhalb des Umfangs der nachstehenden Ansprüche und sind für einen Fachmann offensichtlich. Obwohl Operationen in den Zeichnungen oder Ansprüchen in einer konkreten Reihenfolge dargestellt sind, sollte dies nicht derart verstanden werden, dass es erforderlich ist, dass solche Operationen in der konkreten gezeigten Reihenfolge oder in einer sequenziellen Reihenfolge durchgeführt werden müssen, oder dass alle dargestellten Operationen durchgeführt müssen (manche Operationen können als optional betrachtet werden), um gewünschte Ergebnisse zu erzielen. Unter bestimmen Umständen kann ein Multitasking oder eine parallele Verarbeitung (oder eine Kombination aus Multitasking und Parallelverarbeitung) vorteilhaft sein und, wie es angemessen erscheint, durchgeführt werden.
Des Weiteren sollte die Trennung oder Integration verschiedener Systemmodule und -komponenten in den zuvor beschriebenen Implementierungen nicht derart verstanden werden, dass eine solche Trennung oder Integration in allen Implementierungen erforderlich ist, und es versteht sich, dass die beschriebenen Programmkomponenten und -systeme im Allgemeinen in ein einzelnes Softwareprodukt miteinander integriert oder in mehreren Softwareprodukten gehäust werden können.
Dementsprechend definieren oder beschränken die zuvor beschriebenen Beispielimplementierungen die vorliegende Offenbarung nicht. Andere Änderungen, Ersetzungen und Abwandlungen sind ebenfalls möglich, ohne vom Erfindungsgedanken und Umfang der vorliegenden Offenbarung abzuweichen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 14529812 [0036]
US 13832456 [0036]
US 16035861 [0050]

Claims

Computerimplementiertes Verfahren, umfassend: Empfangen, durch mindestens einen Prozessor, von Telematikdaten und Versicherungsanspruchsdaten für eine Population von Fahrern, Generieren, durch den mindestens einen Prozessor, eines Trainingsdatensatzes auf der Grundlage der Telematikdaten, wobei der Trainingsdatensatz umfasst: Werte für eine aus den Telematikdaten abgeleitete Proxy-Variable, und Werte für ein oder mehrere aus den Telematikdaten abgeleitete Merkmale zum Vorhersagen der Proxy-Variable, Generieren, durch den mindestens einen Prozessor, eines Testdatensatzes auf der Grundlage der Telematikdaten und der Anspruchsdaten, wobei der Testdatensatz umfasst: Werte für eine aus den Anspruchsdaten abgeleitete Zielvariable, und Werte für das eine oder die mehreren aus den Telematikdaten abgeleiteten Merkmale, Generieren, durch den mindestens einen Prozessor, eines statistischen Modells unter Verwendung des Trainingsdatensatzes, wobei das statistische Modell dazu ausgelegt ist, Werte der Proxy-Variable aus Werten des einen oder der mehreren Merkmale vorherzusagen, und Validieren, durch den mindestens einen Prozessor, des statistischen Modells unter Verwendung des Testdatensatzes.
Verfahren nach Anspruch 1, wobei das Validieren des statistischen Modells unter Verwendung des Testdatensatzes umfasst: Anwenden der Werte für das eine oder die mehreren Merkmale, die im Testdatensatz aufgenommen sind, auf das statistische Modell, um Werte für die Proxy-Variable für jeden Fahrer in der Population von Fahrern zu bestimmen, Bestimmen einer Verteilung der Werte für die Proxy-Variable für jeden Fahrer in der Population von Fahrern, und Abbilden der Werte für die Zielvariable im zweiten Datensatz auf die Verteilung.
Verfahren nach Anspruch 1, wobei das Validieren des statistischen Modells unter Verwendung des Testdatensatzes ein Generieren eines Lift-Diagramms, ein Berechnen einer Lift-Statistik, oder ein Berechnen einer Fläche unter einer ROC-Kurve (Receiver-Operator-Characteristic-Kurve, ROC: Operationscharakteristik eines Beobachters) umfasst.
Verfahren nach Anspruch 1, wobei die Werte für die Zielvariable, die im Testdatensatz aufgenommen sind, eine Anzahl von Versicherungsansprüchen für einen konkreten Expositionszeitraum oder Kosten von Versicherungsansprüchen für einen konkreten Expositionszeitraum umfassen.
Verfahren nach Anspruch 1, wobei das Verfahren in einer ersten Recheninstanz ausgeführt wird, wobei das Verfahren ferner, in einer zweiten Recheninstanz, umfasst: Resampling des Trainingsdatensatzes mit Ersetzung, um einen resampelten Trainingsdatensatz zu erzeugen, wobei der resampelte Trainingsdatensatz Werte für die Proxy-Variable und Werte für das eine oder die mehreren Merkmale umfasst, Resampling des Testdatensatzes mit Ersetzung, um einen resampelten Testdatensatz zu erzeugen, wobei der resampelte Testdatensatz Werte für die Zielvariable und Werte für das eine oder die mehreren Merkmale umfasst, Generieren eines zweiten statistischen Modells unter Verwendung des resampelten Trainingsdatensatzes, und Auswerten des zweiten statistischen Modells unter Verwendung des resampelten Testdatensatzes, umfassend: Vergleichen einer Ausgabe des zweiten statistischen Modells mit einer Ausgabe des ersten statistischen Modells, und Bestimmen eines Konfidenzintervalls für die Ausgabe des ersten statistischen Modells zumindest teilweise auf der Grundlage des Vergleichs.
Computerimplementiertes Verfahren, umfassend: Empfangen, durch mindestens einen Prozessor, eines oder mehrerer Parameter für ein Rechenexperiment, wobei der eine oder die mehreren Parameter ein oder mehrere Merkmale und ein oder mehrere Datensätze zum Generieren eines statistischen Modells umfassen, Generieren, durch den mindestens einen Prozessor, eines oder mehrerer Teilexperimente auf der Grundlage des Rechenexperiments, wobei jedes Teilexperiment eine Angabe eines konkreten Satzes des einen oder der mehreren Parameter umfasst, die im Teilexperiment anzuwenden sind, Generieren, durch den mindestens einen Prozessor, einer Warteschlange mit jedem des einen oder der mehreren Teilexperimente, Generieren, durch den mindestens einen Prozessor, einer oder mehrerer Recheninstanzen, die zum Folgenden ausgelegt sind: Empfangen eines Teilexperiments aus der Warteschlange, Generieren eines Trainingsdatensatzes und eines Testdatensatzes durch Resampling des einen oder der mehreren Datensätze mit Ersetzung, Generieren des statistischen Modells mit dem Trainingsdatensatz, Validieren des statistischen Modells mit dem Testdatensatz, Speichern einer oder mehrerer Ausgaben der Validierung in einem Speichersystem, Aggregieren der einen oder der mehreren Ausgaben der Validierung, die im Speichersystem gespeichert sind, um eine aggregierte Ausgabe für das Rechenexperiment zu erzeugen, und Verarbeiten der aggregierten Ausgabe, um eine oder mehrere Leistungsmetriken für das statistische Modell zu generieren.
Verfahren nach Anspruch 6, wobei der eine oder die mehreren Parameter eine Spezifikation von Merkmalen aus dem einen oder den mehreren Merkmalen, die zur Vorhersage verwendet werden, eine Spezifikation einer Zielvariable aus dem einen oder den mehreren Merkmalen, eine Spezifikation einer Proxy-Variable aus dem einen oder den mehreren Merkmalen, oder einen Typ von Modell zum Generieren des statistischen Modells umfassen.
Verfahren nach Anspruch 6, wobei jede Instanz mehrere Verarbeitungspipelines umfasst, und wobei jede Instanz ein Teilexperiment für jede verfügbare Pipeline der mehreren Verarbeitungspipelines empfängt.
Verfahren nach Anspruch 6, wobei jede der einen oder der mehreren Recheninstanzen zum Folgenden ausgelegt ist: Bestimmen, ob verbleibende Teilexperimente in der Warteschlange vorhanden sind, und Beenden als Antwort auf eine Bestimmung, dass keine verbleibenden Teilexperimente in der Warteschlange vorhanden sind.
Verfahren nach Anspruch 6, das ferner ein Verarbeiten der aggregierten Ausgabe umfasst, um ein Konfidenzintervall für mindestens eine der einen oder der mehreren Leistungsmetriken zu generieren.
Computerimplementiertes Verfahren, umfassend: Empfangen, durch mindestens einen Prozessor, einer Spezifikation einer Risikofunktion, Empfangen, durch den mindestens einen Prozessor, einer Anfrage zum Auswerten der Risikofunktion, wobei die Anfrage eine Angabe eines konkreten Satzes von Daten, mit dem die Risikofunktion auszuwerten ist, und eine Angabe einer oder mehrerer Leistungsmetriken, die durch die Auswertung zu generieren sind, umfasst, Aufteilen, durch den mindestens einen Prozessor, des konkreten Satzes von Daten in einen oder mehreren Datenabschnitte, Instanziieren, durch den mindestens einen Prozessor, einer oder mehrerer Recheninstanzen, die zum Folgenden ausgelegt sind: Empfangen der Risikofunktion und eines von dem einen oder den mehreren Datenabschnitten, Verarbeiten der Risikofunktion mit dem Datenabschnitt, um einen oder mehrere Risikopunkte zu erzeugen, und Speichern des einen oder der mehreren Risikopunkte in einem Speichersystem, Aggregieren, durch den mindestens einen Prozessor, des einen oder der mehreren Risikopunkte, die im Speichersystem gespeichert sind, um eine aggregierte Ausgabe zu erzeugen, und Verarbeiten, durch den mindestens einen Prozessor, der aggregierten Ausgabe, um die eine oder die mehreren Leistungsmetriken für die Risikofunktion zu bestimmen.
Verfahren nach Anspruch 11, wobei die Spezifikation der Risikofunktion eine Angabe eines oder mehrerer Parameter für die Risikofunktion umfasst.
Verfahren nach Anspruch 12, wobei die eine oder die mehreren Recheninstanzen dazu ausgelegt sind, jeden des einen oder der mehreren Parameter zu iterieren, um einen oder mehrere Risikopunkte für jede Iteration des einen oder der mehreren Parameter zu erzeugen.
Verfahren nach Anspruch 12, wobei die eine oder die mehreren Recheninstanzen dazu ausgelegt sind, einen Gradienten jedes des einen oder der mehreren Parameter in Bezug auf die Risikofunktion zu berechnen.
Verfahren nach Anspruch 11, wobei jede der einen oder der mehreren Recheninstanzen zum Folgenden ausgelegt ist: Bestimmen, ob verbleibende Datenabschnitte vorhanden sind, und Beenden als Antwort auf eine Bestimmung, dass keine verbleibenden Datenabschnitte vorhanden sind.
Computerimplementiertes Verfahren, umfassend: Empfangen, durch mindestens einen Prozessor, einer Spezifikation einer oder mehrerer Transformationen, die einen Satz von Eingabedateien in einen Satz von Ausgabedateien transformieren, Generieren, durch den mindestens einen Prozessor, eines gerichteten Graphen, der Beziehungen zwischen dem Satz von Eingabedateien und dem Satz von Ausgabedateien beschreibt, auf der Grundlage der einen oder der mehreren Transformationen, Sortieren, durch den mindestens einen Prozessor, des gerichteten Graphen, um eine Reihenfolge zu bestimmen, in der die Transformationen angewendet werden, Berechnen, durch den mindestens einen Prozessor, eines kryptografischen Hashes für jede Eingabedatei im Satz von Eingabedateien, für jede der einen oder der mehreren Transformationen: Bestimmen einer Eingabe der Transformation auf der Grundlage der Reihenfolge, Berechnen eines Hashes der Transformation und der Eingabe in die Transformation, Vergleichen des Hashes der Transformation und der Eingabe in die Transformation mit einem Hash einer anschließenden Transformation, der in einem Speichersystem gespeichert ist, Speichern des Hashes der Transformation und der Eingabe in die Transformation in einem Speichersystem, wenn der Hash der Transformation und der Eingabe in die Transformation mit dem Hash der anschließenden Transformation übereinstimmt, und Anwenden der Transformation auf die Eingabe und Berechnen eines Hashes der Ausgabe und Speichern des Hashes der Eingabe in die Transformation, der Transformation, und der Ausgabe in einem Speichersystem, wenn der Hash der Transformation und der Eingabe in die Transformation mit dem Hash der anschließenden Transformation übereinstimmt, und Berechnen, durch das mindestens eine Datenverarbeitungssystem, eines endgültigen Hashes aller im Speichersystem gespeicherten Hashes.
Verfahren nach Anspruch 16, wobei der gerichtete Graph ein gerichteter azyklischer Graph ist.
Verfahren nach Anspruch 16, wobei die Reihenfolge eine topologische Reihenfolge ist, die mit Beziehungen zwischen dem Satz von Eingabedateien und dem Satz von Ausgabedateien konsistent ist.
Verfahren nach Anspruch 16, ferner umfassend: Verfolgen, durch den mindestens einen Prozessor, einer Kette von Hashes, und Generieren, durch den mindestens einen Prozessor, einer Aufzeichnung mit der Änderung von Hashes.
Verfahren nach Anspruch 19, das ferner ein Speichern der Aufzeichnung in Metadaten für jede Ausgabedatei im Satz von Ausgabedateien umfasst.