Ion_Stoica_Ben_Lorica_600x448.jpg

Waar u op moet letten in een modelserver om op machine learning gebaseerde services te bouwen

by with No Comment & EducationAIArticlesartificial intelligenceBI / Data Science BlogsBI / Data Science NewsBusiness intelligenceData Blogs | Information From Enterprise LeadersData Educationdata scientistGPUJuliaJupyter NotebookMachine LearningMLOpsPythonPython ecosystemRRay ServeSmart Data BlogsSmart Data News

Klik voor meer informatie over co-auteur Ion Stoica.

Klik voor meer informatie over co-auteur Ben Lorica.

Machine learning wordt ingebed in applicaties waarin veel gegevenstypen en gegevensbronnen zijn betrokken. Dit betekent dat softwareontwikkelaars met verschillende achtergronden moeten werken aan projecten waarbij ML betrokken is. In onze vorige posthebben we de belangrijkste functies opgesomd die machine learning-platforms nodig hebben om aan de huidige en toekomstige workloads te voldoen. We hebben ook MLOps beschreven, een reeks praktijken gericht op het produceren van de levenscyclus van machine learning.

Afbeeldingsbron: Anyscale

In dit bericht richten we ons op modelservers, software die de kern vormt van machine learning diensten die in realtime of offline werken. Er zijn twee veelgebruikte benaderingen voor het presenteren van machine learning-modellen. De eerste benadering integreert modelevaluatie in een webserver (bijvoorbeeld Flask) als een API-service-eindpunt dat is toegewijd aan een voorspellingsservice.

De tweede benadering verplaatst modelevaluatie naar een aparte dienst. Dit is een actief gebied voor startups en er zijn steeds meer opties die in deze categorie vallen. Het aanbod omvat services van cloudproviders (SageMaker, Azuur, Google Cloud), open source-projecten voor het bedienen van modellen (Ray Serve, Seldon, TorchServe, TensorFlow Serving, etc.), eigen software (SAS, Datatron, ModelOps, etc.), en op maat gemaakte oplossingen die meestal in een generiek raamwerk zijn geschreven.

Hoewel machine learning kan worden gebruikt voor eenmalige projecten, proberen de meeste ontwikkelaars machine learning te integreren in hun producten en services. Modelservers zijn belangrijke componenten van de software-infrastructuur voor het produceren van machine learning, en daarom moeten bedrijven hun opties zorgvuldig evalueren. Dit bericht richt zich op de belangrijkste functies waar bedrijven naar moeten zoeken in een modelserver.

Ondersteuning voor populaire toolkits

Uw modelserver staat waarschijnlijk los van uw modeltrainingssysteem. Kies een modelserver die een getraind modelartefact kan gebruiken dat is geproduceerd met behulp van een aantal populaire tools. Ontwikkelaars en machine learning-ingenieurs bouwen modellen met behulp van veel verschillende bibliotheken, waaronder die voor deep learning (PyTorch, TensorFlow), machine learning en statistieken (scikit-learn, XGBoost, SAS, statsmodels). Modelbouwers blijven ook verschillende programmeertalen gebruiken. Hoewel Python naar voren is gekomen als de dominante taal voor machine learning, hebben andere talen zoals R, Java, Scala, Julia en SAS nog steeds veel gebruikers. Meer recentelijk hebben veel bedrijven Data Science-werkbanken geïmplementeerd, zoals Databricks, Cloudera, Dataiku, Domino Data Lab en anderen.

Een GUI voor modelimplementatie en meer

Ontwikkelaars gebruiken misschien een opdrachtregelinterface, maar zakelijke gebruikers willen een grafische gebruikersinterface die hen door het proces van het implementeren van modellen leidt en de verschillende fasen van de levenscyclus van machine learning belicht. Naarmate de implementatieprocessen volwassen worden, kunnen ze meer migreren naar scripting en automatisering. Model servers met gebruikersinterfaces omvatten Seldon implementeren, SAS Model Manager, Datatron, en anderen die zich richten op zakelijke gebruikers.

Eenvoudig te bedienen en te implementeren, maar met hoge prestaties en schaalbaarheid

Nu machine learning wordt ingebed in kritieke applicaties, hebben bedrijven modelservers met lage latentie nodig die grootschalige voorspellingsservices kunnen aandrijven. Bedrijven zoals Facebook en Google hebben machine learning-services die realtime reacties bieden miljarden keren elke dag. Hoewel dit extreme gevallen kunnen zijn, implementeren veel bedrijven ook applicaties zoals aanbeveling en personalisatiesystemen die dagelijks met veel gebruikers communiceren. Met de beschikbaarheid van open source-software hebben bedrijven nu toegang tot modelservers met lage latentie die naar veel machines kunnen worden geschaald.

De meeste modelservers gebruiken een microservice-architectuur en zijn toegankelijk via een REST- of gRPC-API. Dit maakt het gemakkelijker om machine learning (“aanbevolen”) te integreren met andere services (“winkelwagentje”). Afhankelijk van uw configuratie wilt u misschien een modelserver waarmee u modellen kunt implementeren in de cloud, op locatie of beide. Uw modelserver moet deelnemen aan infrastructuurfuncties zoals automatisch schalen, resourcebeheer en hardware-inrichting.

Sommige modelservers hebben recente innovaties toegevoegd die de complexiteit verminderen, de prestaties verbeteren en flexibele opties bieden voor integratie met andere services. Met de introductie van een nieuw Tensor-gegevenstype ondersteunt RedisAI data lokaliteit – een functie waarmee gebruikers Tensors van hun favoriete client kunnen krijgen en instellen en ‘hun AI-model kunnen uitvoeren waar hun gegevens leven’. Ray Serve brengt modelevaluatielogica dichter bij bedrijfslogica door ontwikkelaars end-to-end controle te geven van API-eindpunt tot modelevaluatie en terug naar het API-eindpunt. Bovendien is het eenvoudig te bedienen en net zo eenvoudig in te zetten als een eenvoudige webserver.

Bevat tools voor testen, implementatie en uitrol

Zodra een model is getraind, moet het worden beoordeeld en getest voordat het wordt geïmplementeerd. Seldon Deploy, Datatron en andere modelservers hebben een aantal interessante mogelijkheden waarmee u modellen kunt testen met een enkele voorspelling of met een belastingtest. Om foutidentificatie en testen te vergemakkelijken, kunt u met deze modelservers ook testgegevens uploaden en testvoorspellingen visualiseren.

Nadat uw model is beoordeeld en getest, zou uw modelserver u de mogelijkheid moeten bieden om modellen veilig te promoten en te degraderen. Andere populaire uitrolpatronen zijn onder meer:

  • Kanarie: Een klein deel van de verzoeken wordt naar het nieuwe model gestuurd, terwijl het grootste deel van de verzoeken naar een bestaand model wordt gerouteerd.
  • Schaduwen: Productieverkeer wordt gekopieerd naar een niet-productieservice om het model te testen voordat het in productie wordt genomen.

Idealiter zijn uitroltools volledig automatiseerbaar, zodat uw implementatietools kunnen worden aangesloten op uw CI / CD- of MLOps-proces.

Ondersteuning voor complexe implementatiepatronen

Naarmate u meer gebruikmaakt van machine learning, moet uw modelserver in staat zijn om veel modellen in productie te ondersteunen. Uw modelserver moet ook complexe implementatiepatronen ondersteunen waarbij meer dan één model tegelijk moet worden geïmplementeerd. Het moet een verscheidenheid aan patronen ondersteunen, waaronder:

  • A / B-tests: Een fractie van de voorspellingen gebruikt één model en de rest gaat naar een ander model.
  • Ensembles: Meerdere modellen worden gecombineerd om een ​​krachtiger voorspellend model te vormen.
  • Cascade: Als een basismodel een voorspelling met weinig zekerheid oplevert, wordt het verkeer naar een alternatief model geleid. Een andere use case is verfijning: detecteer of er een auto op de foto staat en, als die er is, stuur de foto naar een model dat de kentekenplaat van de auto leest.
  • Multi-Arm Bandit: Een vorm van bekrachtigingsleren, bandieten verdelen verkeer over verschillende concurrerende modellen.

Out of the Box Metrics en Monitoring

Machine learning-modellen kunnen in de loop van de tijd achteruitgaan en het is belangrijk om systemen te hebben die aangeven wanneer modellen minder nauwkeurig worden of vooringenomenheid en ander onverwacht gedrag gaan vertonen. Uw modelserver moet prestaties, gebruik en andere aangepaste metrische gegevens uitzenden die kunnen worden gebruikt door visualisatie en realtime monitoringtools. Sommige modelservers beginnen geavanceerde mogelijkheden te bieden, waaronder anomaliedetectie en waarschuwingen. Er zijn zelfs startups (Superwijs, Arize) die zich richten op het gebruik van ‘machine learning om machine learning te monitoren’. Hoewel dit momenteel gespecialiseerde tools zijn die losstaan ​​van en moeten worden geïntegreerd met modelservers, is het vrij waarschijnlijk dat sommige modelservers geavanceerde monitoring- en observatiemogelijkheden in hun aanbod zullen inbouwen.

Integreert met Model Management Tools

Naarmate u meer modellen implementeert voor productie, moet uw modelserver worden geïntegreerd met uw modelbeheertools. Deze tools vallen onder vele labels – toegangscontrole, modelcatalogus, modelregistratie, dashboard voor modelbeheer – maar in wezen bieden ze u een 360-gradenoverzicht van eerdere en huidige modellen.

Omdat modellen periodiek moeten worden geïnspecteerd, moet uw modelserver worden gekoppeld aan services voor het controleren en reproduceren van modellen. Modelversiebeheer is nu standaard en wordt geleverd met de meeste modelservers die we hebben onderzocht. Datatron heeft een dashboard voor modelbeheer dat tools biedt voor het controleren van slecht presterende modellen. Veel modelservers hebben data lineage services die registreren wanneer verzoeken zijn verzonden en wat de invoer en uitvoer van het model waren. Debugging- en controlemodellen vereisen ook een verfijnd begrip van hun belangrijkste drijfveren. Seldon Deploy kan worden geïntegreerd met een open source tool voor modelinspectie en uitlegbaarheid.

Verenigt batch- en online scoren

Stel dat u uw model heeft bijgewerkt of dat u een groot aantal nieuwe records heeft ontvangen. In beide voorbeelden moet u uw model wellicht toepassen op een grote gegevensset. U hebt een modelserver nodig die grote datasets efficiënt kan scoren in mini-batches, en die ook een lage latentie biedt, online scoren (Ray Serve ondersteunt bijvoorbeeld batch- en online scoring).

Samenvatting

Nu machine learning in meer softwaretoepassingen wordt ingebed, moeten bedrijven hun modelservers zorgvuldig selecteren. Hoewel Ray Serve een relatief nieuwe open source modelserver is, heeft deze al veel van de functies die we in dit bericht hebben genoemd. Het is een schaalbare, eenvoudige en flexibele tool voor het implementeren, bedienen en bewaken van machine learning-modellen. Zoals we in ons vorige bericht hebben opgemerkt, geloven we dat Ray en Ray Serve in de toekomst de basis zullen zijn van veel ML-platforms.

Maarit_Widmann_Alfredo_Roccato_600x448.jpg

From Modeling to Scoring: Correcting Predicted Class Probabilities in Imbalanced Datasets

by with No Comment & EducationArticlesBI / Data Science BlogsBI / Data Science NewsBusiness intelligenceclass statisticsData Blogs | Information From Enterprise LeadersData Educationdata sciencedata scientistmatrix statisticsmodel evaluationmodelingnumeric predictionoversamplingscoringSmart Data BlogsSmart Data NewsSMOTEunbalanced datasetsundersampling

Click to learn more about co-author Maarit Widmann.

Click to learn more about co-author Alfredo Roccato.

This is the second part of a the From Modeling to Scoring Series, see Part One here.

Wheeling like a
hamster in the Data Science cycle? Don’t know when to stop training your model?

Model evaluation is an important part of a Data Science project, and it’s exactly this part that quantifies how good your model is, how much it has improved from the previous version, how much better it is than your colleague’s model, and how much room for improvement there still is.

In this series of blog posts, we review different scoring metrics: for classification, numeric prediction, unbalanced datasets, and other similar, more or less challenging model evaluation problems.

Today: Classification on Imbalanced Datasets

It is not unusual in machine learning applications to deal with imbalanced datasets such as fraud detection, computer network intrusion, medical diagnostics, and many more.

Data imbalance refers to unequal distribution of classes
within a dataset, namely that there are far fewer events in one class in
comparison to the others. If, for example, we have a credit card fraud
detection dataset, most of the transactions are not fraudulent, and very few
can be classed as fraud detections. This underrepresented class is called the
minority class, and by convention, the positive class.

It is recognized that classifiers work well when each class
is fairly represented in the training data.

Therefore, if the data is imbalanced, the performance of
most standard learning algorithms will be compromised because their purpose is
to maximize the overall accuracy. For a dataset with 99 percent negative events
and 1 percent positive events, a model could be 99 percent accurate, predicting
all instances as negative, though, being useless. Put in terms of our credit
card fraud detection dataset, this would mean that the model would tend to
classify fraudulent transactions as legitimate transactions. Not good!

As a result, overall accuracy is not enough to assess the performance of models trained on imbalanced data. Other statistics, such as Cohen’s kappa and F-measure, should be considered. F-measure captures both the precision and recall, while Cohen’s kappa takes into account the a priori distribution of the target classes.

The ideal classifier should provide high accuracy over the
minority class, without compromising on the accuracy for the majority class.

Resampling to Balance Datasets

To work around the problem of class imbalance, the rows in
the training data are resampled. The basic concept here is to alter the
proportions of the classes (a priori distribution) of the training data in
order to obtain a classifier that can effectively predict the minority class
(the actual fraudulent transactions).

Resampling Techniques

  • Undersampling: A random sample of events from the majority class is drawn and removed from the training data. A drawback of this technique is that it loses information and potentially discards useful and important data for the learning process.
  • Oversampling: Exact copies of events representing the minority class are replicated in the training dataset. However, multiple instances of certain rows can make the classifier too specific, causing overfitting issues.
  • SMOTE (Synthetic Minority Oversampling Technique): “Synthetic” rows are generated and added to the minority class. The artificial records are generated based on the similarity of the minority class events in the feature space.

Correcting Predicted Class Probabilities

Let’s assume that we train a model on a resampled dataset.
The resampling has changed the class distribution of the data from imbalanced
to balanced. Now, if we apply the model to the test data and obtain predicted
class probabilities, they won’t reflect those of the original data. This is
because the model is trained on training data that is not representative of the
original data, and thus the results do not generalize into the original or any
unseen data. This means that we can use the model for prediction, but the class
probabilities are not realistic: We can say whether a transaction is more
probably fraudulent or legitimate, but we cannot say how probably it belongs to
one of these classes. Sometimes we want to change the classification threshold because
we want to take more/fewer risks, and then the model with the corrected class
probabilities that haven’t been corrected wouldn’t work anymore. 

After resampling, we have now trained a model on balanced
data, i.e., data that contains an equal number of fraudulent and legitimate transactions,
which is luckily not a realistic scenario for any credit card provider and,
therefore — without correcting the predicted class probabilities — would not be
informative about the risk of the transactions in the next weeks and months.

If the final goal of the analysis is not only to classify
based on the highest predicted class probability but also to get the correct
class probabilities for each event, we need to apply a transformation to the
obtained results. If we don’t apply the transformation to our model, grocery
shopping with a credit card in a supermarket might raise too much
interest! 

The following formula shows how to correct the predicted class probabilities for a binary classifier [1]:

For example, if the proportion of the positive class in the original dataset is 1 percent and, after resampling, it is 50 percent, and the predicted positive class probability is 0.95, applying the correction it gives:

Example: Fraud Detection

When we apply a classification model to detect fraudulent
transactions, the model has to work reliably on imbalanced data. Although few
in number, fraudulent transactions can have remarkable consequences. Therefore,
it’s worth checking how much we can improve the performance of the model and
its usability in practice by resampling the data and correcting the predicted
class probabilities. 

Evaluating the Cost of a Classification Model

In the real world, the performance of a classifier is
usually assessed in terms of cost-benefit analysis: Correct class predictions
bring profit, whereas incorrect class predictions bring cost. In this case,
fraudulent transactions predicted as legitimate cost the amount of fraud, and
transactions predicted as fraudulent — correctly or incorrectly — bring
administrative costs. 

Administrative costs (Adm) are the expected costs of
contacting the cardholder and replacing the card if the transaction was
correctly predicted as fraudulent or reactivating it if the transaction was
legitimate. Here we assume, for simplicity, that the administrative costs for
both cases are identical.

The cost matrix below summarizes the costs assigned to the different classification results. The minority class, “fraudulent,” is defined as the positive class, and “legitimate” is defined as the negative class.

Table 1: The cost matrix that shows the costs assigned to different classification results as obtained by a model for fraud detection. Correctly classified legitimate transactions bring no cost. Fraudulent transactions predicted as legitimate cost the amount of fraud. Transactions predicted as fraudulent bring administrative costs.

Based on this cost matrix, the total cost of the model is:

Finally, the cost of the model will be compared to the amount of fraud. Cost reduction tells how much cost the classification model brings compared to the situation where we don’t use any model:

The Workflow

In this example, we use the “Credit Card Fraud Detection” dataset provided by Worldline and the Machine Learning Group of ULB (Université Libre de Bruxelles) on big data mining and fraud detection. The dataset contains 284,807 transactions made by European credit card holders during two days in September 2013. The dataset is highly imbalanced: 0.172 percent (492 transactions) were fraudulent, and the rest were normal. Other information on the transactions has been transformed into principal components.

The workflow in Figure 1 shows the overall process of
reading the data, partitioning the data into a training and test set,
resampling the data, training a classification model, predicting and correcting
the class probabilities, and evaluating the cost reduction. We selected SMOTE
as the resampling technique and logistic regression as the classification
model. Here we estimate administrative costs to be 5 euros.

The workflow provides three different scenarios for the same
data: 

1. Training and applying the model
using imbalanced data

2. Training the model on balanced data
and applying the model to imbalanced data without correcting the predicted
class probabilities

3. Training the model on balanced data and applying the model to imbalanced data where the predicted class probabilities have been corrected

Figure 1: Workflow that compares three ways of training and applying a classification model using imbalanced data. Firstly, the model training is done on imbalanced data. Secondly, the training set is resampled using SMOTE to make it balanced. Thirdly, the training set is resampled using SMOTE, and predicted class probabilities are corrected based on the a priori class distribution of the data. The workflow is available for download on the Hub.

Estimating the Cost for Scenario 1 Without Resampling

A logistic regression model provides these results:

Table 2: The confusion matrix, class statistics, and estimated cost reduction obtained by a fraud detection model that was trained on imbalanced data. The cost reduction is evaluated using the formula in the “Evaluating the cost of a classification model” section.

The setup in this scenario provides good values for
F-measure and Cohen’s kappa statistics, but a relatively high False Negative
Rate (40.82 percent). This means that more than 40 percent of the fraudulent
transactions were not detected by the model — increasing the amount of fraud
and, therefore, the cost of the model. The cost reduction of the model compared
to not using any model is 42 percent.

Estimating the Cost for Scenario 2 with Resampling

A logistic regression model trained on a balanced training set (oversampled using SMOTE) yields these results:

Table 3: The confusion matrix, class statistics, and estimated cost obtained by a fraud detection model that was trained on oversampled, balanced data. The cost is evaluated using the formula in the “Evaluating the cost of a classification model” section.

The False Negative Rate is very low (12.24 percent), which
means that almost 90 percent of the fraudulent transactions were detected by
the model. However, there are a lot of “false alarms” (391 legitimate
transactions predicted as fraud) that increase administrative costs. However,
the cost reduction achieved by training the model on a balanced dataset is 64
percent — higher than what we could reach without resampling the training data.
The same test set was used for both scenarios.

Estimating the Cost for Scenario 3 with Resampling and Correcting
the Predicted Class Probabilities

A logistic regression model trained on a balanced training set (oversampled using SMOTE) yields these results when the predicted probabilities have been corrected according to the a priori class distribution of the data:

Table 4: The confusion matrix, class statistics, and estimated cost as obtained by a fraud detection model that was trained on oversampled, balanced data and where the predicted class probabilities were corrected according to the a priori class distribution. The cost is evaluated using the formula in the “Evaluating the cost of a classification model” section.

As the results for this scenario in Table 4 show, correcting
the predicted class probabilities leads to the best model of these three
scenarios in terms of the greatest cost reduction. 

In this scenario, where we train a classification model on oversampled
data and correct the predicted class probabilities according to the a priori
class distribution in the data, we reach a cost reduction of 75 percent
compared to not using any model. 

Of course, the cost reduction depends on the value of the
administrative costs. Indeed, we tried this by changing the estimated
administrative costs and found out that this last scenario can attain cost
reduction as long as the administrative costs are 0.80 euros or more.

Summary

Often, when we train and apply a classification model, the
interesting events in the data belong to the minority class and are therefore
more difficult to find: fraudulent transactions among the masses of
transactions, disease carriers among the healthy people, and so on.

From the point of view of the performance of a
classification algorithm, it’s recommended to make the training data balanced.
We can do this by resampling the training data. Now, the training of the model
works better, but how about applying it to new data, which we suppose to be
imbalanced? This setup leads to biased values for the predicted class
probabilities because the training set does not represent the test set or any
new, unseen data. 

Therefore, to obtain optimal performance of a classification
model together with reliable classification results, correcting the predicted
class probabilities by the information on the a priori class distribution is
recommended. As the use case in this blog post shows, this correction leads to
better model performance and concrete profit.

References

1.Marco Saerens, Patrice Latinne, and Christine
Decaestecker. Adjusting the outputs of a classifier to new a priori
probabilities: a simple procedure. Neural computation 14(1):21–41,
2002.

mk_data-discovery.png

Wat is gegevensdetectie? – DATAVERSITEIT

by with No Comment & EducationanalyticsArticlesAugmented analyticsBI / Data Science NewsBusiness intelligencecitizen data scientistdata discoveryData EducationData Governance & Data Quality | News & Articlesdata lineagedata preparationdata qualitydata scientistDatabase NewsMachine LearningmetadataWhat is...?

Gegevensdetectie

Data discovery beschrijft processen voor het begrijpen van datasets die voorhanden zijn voor data-integratie en / of data-analyse. Deze stap vindt plaats in het ontwerp en zou moeten combineer technische zoek van tools met vakkennis, van mensen. Tijdens het ontdekken van gegevens wordt bij de beoordeling een weergave op hoog niveau genomen data voorbereiding, of datakwaliteitsbehoeften. Gegevensdetectie kan worden onderverdeeld in twee concepten:

  • Handmatige gegevensopsporing: In de afgelopen 20 jaar, voordat machine learning vorderde, dataspecialisten in kaart gebrachte gegevens door de enige hersenkracht van mensen. Simpel gezegd, mensen kritisch nagedacht over welke gegevens beschikbaar zijn, waar deze worden opgeslagen en waarom en wat er aan de eindklant moet worden verstrekt. Bedrijven bewaakten metadata en data lineage discovery om meer te weten te komen over gegevenscategorisatie en -stroom. Datastewards, meestal mensen met geavanceerde technische kennis, die zorgen voor gegevensactiva, documentregels en -standaarden die het gegevensontdekkingsproces begeleiden. Bij deze benaderingen conceptualiseren en / of tekenen mensen een kaart om alle gegevens in een organisatie te begrijpen.
  • Slimme gegevensopsporing: Met de technologische vooruitgang in de afgelopen twee jaar omvatte de definitie van gegevensdetectie geautomatiseerde manieren om gegevens te presenteren, om diepere zakelijke inzichten te onthullen. Slimme gegevensdetectie vertegenwoordigt een sprong voorwaarts met verbeterde analyses en machine learning. Kunstmatige intelligentie bereidt, conceptualiseert, integreert, en presenteert, meestal door middel van visuals, verborgen patronen en inzichten. Bedenk dat het algemene begrip en de analyse van de beschikbare datasets zich bevindt in de machines waarop computers vragen ontvangen, wat bewerkingen uitvoeren in een zwarte doos en met hun beredeneerde antwoorden komen.

Sommigen op het gebied van Data Science kunnen gegevensdetectie dubbelzinnig maken met geautomatiseerde slimme tools voor gegevensdetectie. Zowel handmatige als geautomatiseerde tools werken echter het beste onder de definitie van gegevensdetectie, aangezien beide in artikelen kunnen worden besproken en geïmpliceerd. Zoals AnalyticsWeek stelt: “Machine leren is de tussenpersoon die het gegevensontdekkingsproces verbetert om het geschikt te maken voor de prominente zorgen over gegevensbeheer en naleving van regelgeving waarmee hedendaagse ondernemingen worden geconfronteerd. “

Andere definities van Data Discovery zijn onder meer:

  • “Een resultaat waarmee zakelijke gebruikers gebruik kunnen maken van Advanced Analytics en burgerdatawetenschappers kunnen creëren.” (Kartik Patel)
  • “Tools die gegevens opschonen en voorbereiden, verborgen patronen en correlaties vinden en inzichten bieden zonder tussenkomst van de gebruiker.” (Paramita (Guha) Ghosh)
  • “Praktijken, architectonische technieken en tools voor het bereiken van een consistente toegang tot en levering van gegevens over…. de onderneming om te voldoen aan de vereisten voor gegevensverbruik van alle applicaties en bedrijfsprocessen. ” (Gartner)
  • “In kaart brengen van informatierelaties die worden ondersteund door machine learning.” (Forbes)
  • Het zoeken naar waar gevoelige gegevens zich bevinden, zodat deze adequaat kunnen worden beschermd of veilig kunnen worden verwijderd. (MIT IST)

Gegevens Ontdekking Gebruiksvoorbeelden zijn:

Bedrijven gebruiken gegevensdetectie om:

  • Identificeer subtiele patronen
  • Leef wetten na, zoals de Algemene data Beschermingsverordening (AVG)
  • Geef niet-technische mensen of datawetenschappers van burgers toegang tot data-analyse
  • Om de volledigheid van gegevens te testen en ervoor te zorgen
  • Verlaag de kosten tot wel 80 procent

Afbeelding gebruikt onder licentie van Shutterstock.com

Ion_Stoica_600x448.jpg

Vijf belangrijke functies voor een machine learning-platform

by with No Comment & EducationAIArticlesartificial intelligenceBI / Data Science BlogsBI / Data Science NewsBusiness intelligenceData Blogs | Information From Enterprise LeadersData Educationdata scientistGPUJuliaJupyter NotebookMachine Learningmachine learning platformMLOpsPythonPython ecosystemRRay ServeSmart Data BlogsSmart Data News

Klik voor meer informatie over auteur Ion Stoica.

Ontwerpers van machine learning-platforms moeten de huidige uitdagingen het hoofd bieden en plannen maken voor toekomstige workloads.

Zoals machine learning voet aan de grond krijgt in steeds meer bedrijven, worstelen teams met de fijne kneepjes van het managen van de levenscyclus van machine learning.

Het typische startpunt is om elke datawetenschapper een Jupyter-notebook te geven die wordt ondersteund door een GPU-instantie in de cloud en om een ​​apart team de implementatie en bediening te laten beheren, maar deze aanpak valt uiteen naarmate de complexiteit van de applicaties en het aantal implementaties toeneemt.

Als gevolg hiervan zijn meer teams op zoek naar platforms voor machine learning. Verschillende startups en cloudproviders beginnen end-to-end platforms voor machine learning aan te bieden, waaronder AWS (SageMaker), Azure (Machine Learning Studio), Databricks (MLflow), Google (Cloud AI Platform) en andere. Veel andere bedrijven kiezen ervoor om hun eigen bedrijf te bouwen, waaronder Uber (Michelangelo), Airbnb (BigHead), Facebook (FBLearner), Netflix en Apple (Overton).

Afbeeldingsbron: Anyscale
Figuur 1: Open Source Ray kan worden gebruikt om inplugbare componenten voor platforms voor machine learning te bouwen. De blauwe vakken zijn componenten waarvoor er enkele bibliotheken bovenop zijn gebouwd.

Veel gebruikers bouwen ML-tools en -platforms. Dit is een actieve ruimte: verschillende startups en cloudplatforms beginnen end-to-end machine learning-platforms aan te bieden, waaronder Amazon, Databricks, Google en Microsoft. Maar gesprekken met mensen in de gemeenschap blijven gebruikers terugdrijven naar deze tool om veel onopgeloste uitdagingen op te lossen.

De verzameling bibliotheken van Ray kan naast andere ML-platformcomponenten worden gebruikt. En in tegenstelling tot monolithische platforms, hebben gebruikers de flexibiliteit om een ​​of meer van de bestaande bibliotheken te gebruiken of om hun eigen bibliotheken te bouwen. Een gedeeltelijke lijst van machine learning-platforms die dergelijke functies al bevatten, omvat:

In dit bericht zullen we inzichten delen die zijn afgeleid van gesprekken met veel ML-platformbouwers. We zullen functies vermelden die van cruciaal belang zijn om ervoor te zorgen dat uw ML-platform goed gepositioneerd is voor moderne AI-toepassingen. We zullen er ook voor zorgen dat ontwikkelaars die ML-platforms en ML-componenten bouwen, een dergelijk platform zouden moeten overwegen, omdat het een ecosysteem van zelfstandige bibliotheken heeft die kunnen worden gebruikt om enkele van de onderstaande items aan te pakken.

Ecosysteemintegratie

Ontwikkelaars en ingenieurs voor machine learning gebruiken verschillende tools en programmeertalen (R, Python, Julia, SAS, etc.). Maar met de opkomst van diep leren, Python is de dominante programmeertaal voor machine learning geworden. Dus als er iets is, moet een ML-platform Python en het Python-ecosysteem ondersteunen.

In de praktijk vertrouwen ontwikkelaars en machine learning-ingenieurs op veel verschillende Python-bibliotheken en tools. De meest gebruikte bibliotheken zijn onder meer deep learning-tools (TensorFlow, PyTorch), machine learning en bibliotheken voor statistische modellering (scikit-learn, statsmodels), NLP-tools (spaCy, Knuffelend gezicht, AllenNLP) en het afstemmen van modellen (Hyperopt, Afstemmen).

Omdat het naadloos integreert in het Python-ecosysteem, gebruiken veel ontwikkelaars Ray voor het bouwen van machine learning-tools. Het is een gedistribueerd computerplatform voor algemene doeleinden dat kan worden gebruikt om eenvoudig bestaande Python-bibliotheken en -toepassingen te schalen. Het heeft ook een groeiende verzameling zelfstandige bibliotheken die beschikbaar zijn voor Python-ontwikkelaars.

Eenvoudig schalen

Zoals wij dat is genoteerd in De toekomst van computers wordt gedistribueerd, nemen de “eisen van machine learning-applicaties razendsnel toe”. De opkomst van deep learning en nieuwe workloads betekent dat gedistribueerd computergebruik gebruikelijk zal zijn voor machine learning. Helaas hebben veel ontwikkelaars relatief weinig ervaring met gedistribueerd computergebruik.

Schalen en gedistribueerde berekeningen zijn gebieden waarop Ray veel gebruikers heeft geholpen met wie we hebben gesproken. Het stelt ontwikkelaars in staat zich te concentreren op hun applicaties in plaats van op de fijne kneepjes van gedistribueerd computergebruik. Het gebruik ervan biedt verschillende voordelen voor ontwikkelaars die machine learning-applicaties moeten schalen:

  • Het is een platform waarmee u uw bestaande applicaties eenvoudig naar een cluster kunt schalen. Dit kan zo simpel zijn als het schalen van uw favoriete bibliotheek naar een rekencluster (zie dit recente post over het gebruik ervan om scikit-learn te schalen). Of het zou kunnen gaan om het gebruik van de API om een ​​bestaand programma naar een cluster te schalen. Het laatste scenario is er een die we hebben zien gebeuren voor toepassingen in NLP, online leren, fraudedetectie, financiële tijdreeksen, OCR, en vele andere use-cases.
  • RaySGD vereenvoudigt gedistribueerde training voor PyTorch en TensorFlow. Dit is goed nieuws voor de vele bedrijven en ontwikkelaars die worstelen met het trainen of afstemmen van grote neurale netwerken.
  • In plaats van tijd te besteden aan DevOps, maakt een ingebouwde clusterstarter het eenvoudig om een ​​cluster op te zetten.

Uitbreidbaarheid voor nieuwe workloads

Moderne AI-platforms hebben notoir honger naar rekenkracht. In De toekomst van computers wordt gedistribueerd post waarnaar hierboven wordt verwezen, hebben we dat opgemerkt model afstemmen is een belangrijk onderdeel van het ontwikkelingsproces van machine learning:

“Je traint een model niet één keer. Doorgaans hangt de kwaliteit van een model af van verschillende hyperparameters, zoals het aantal lagen, het aantal verborgen eenheden en de batchgrootte. Om het beste model te vinden, moet u vaak tussen verschillende hyperparameterinstellingen zoeken. Dit proces wordt hyperparameter-afstemming genoemd en kan erg duur zijn. ” Ion Stoica

Ontwikkelaars kunnen kiezen uit verschillende bibliotheken om modellen af ​​te stemmen. Een van de meer populaire tools is Afstemmen, een schaalbare bibliotheek voor het afstemmen van hyperparameters die bovenop Ray is gebouwd. Tune draait op een enkel knooppunt of op een cluster en is snel een van de meer populaire bibliotheken in dit ecosysteem geworden.

Reinforcement learning (RL) is een ander gebied dat het vermelden waard is. Veel van de recente artikelen over RL hebben betrekking op gameplay (Atari, Go, videogames voor meerdere spelers) of op toepassingen in industriële omgevingen (bijv. Efficiëntie van datacenters). Maar zoals we hebben eerder opgemerktzijn er opkomende toepassingen in aanbevelingen en personalisatie, simulatie en optimalisatie, financiële tijdreeksen en publiek beleid.

RL is rekenintensief, complex om te implementeren en op te schalen, en als zodanig zullen veel ontwikkelaars gewoon bibliotheken willen gebruiken. Ray biedt een eenvoudige, zeer schaalbare bibliotheek (RLlib) die ontwikkelaars en machine learning-ingenieurs in verschillende organisaties al in de productie gebruiken.

Tools ontworpen voor teams

Nu bedrijven meer modellen voor machine learning gaan gebruiken en implementeren, zullen teams van ontwikkelaars met elkaar moeten kunnen samenwerken. Ze hebben toegang nodig tot platforms die zowel delen als ontdekken mogelijk maken. Houd bij het overwegen van een ML-platform rekening met de belangrijkste fasen van modelontwikkeling en -operaties, en ga ervan uit dat teams van mensen met verschillende achtergronden tijdens elk van die fasen zullen samenwerken.

Bijvoorbeeld, feature winkels (eerste geïntroduceerd door Uber in 2017) zijn handig omdat ze ontwikkelaars in staat stellen te delen en te ontdekken Kenmerken waar ze anders misschien niet aan hadden gedacht. Teams moeten ook kunnen samenwerken tijdens de levenscyclus van modelontwikkeling. Dit omvat het beheren, volgen en reproduceren van experimenten. Het toonaangevende open source-project op dit gebied is MLflow, maar we zijn gebruikers tegengekomen van andere tools zoals Gewichten en afwijkingen en Komeet, evenals gebruikers die hun eigen tools hebben gebouwd om ML-experimenten te beheren.

Ondernemingen hebben aanvullende functies nodig, waaronder beveiliging en toegangscontrole. Modelbeheer en modelcatalogi (analogen van vergelijkbare systemen voor het beheren van gegevens) zullen ook nodig zijn naarmate teams van ontwikkelaars meer modellen bouwen en implementeren.

Eerste klas MLOps

MLOps is een reeks praktijken gericht op het produceren van de levenscyclus van machine learning. Het is een relatief nieuwe term die ideeën put uit continue integratie (CI) en continue implementatie (CD), twee veelgebruikte methoden voor softwareontwikkeling. Een recent Thoughtworks-bericht somde enkele belangrijke overwegingen op voor het opzetten van CD voor machine learning (CD4ML). Enkele belangrijke items voor CI / CD voor machine learning zijn reproduceerbaarheid, experimentbeheer en -tracking, modelbewaking en observatie, en meer. Er zijn een paar startups en open source-projecten die MLOps-oplossingen bieden, waaronder Datatron, Verta, TFX, en MLflow.

Ray heeft componenten die nuttig zouden zijn voor bedrijven die overstappen op CI / CD of die CI / CD-tools bouwen voor machine learning. Het heeft al bibliotheken voor de belangrijkste fasen van de ML-levenscyclus: opleiding (RaySGD), afstemmen (Tune), en inzet (Dienen). Door toegang te hebben tot bibliotheken die naadloos samenwerken, kunnen gebruikers CI / CD-methoden gemakkelijker in hun MLOps-praktijk integreren.

Samenvatting

We hebben de belangrijkste elementen opgesomd waarover machine learning-platforms zouden moeten beschikken. Onze uitgangspunten zijn dat Python de voorkeurstaal zal blijven voor ML, gedistribueerde computing zal steeds meer nodig zijn, nieuwe workloads zoals afstemming van hyperparameters en RL moeten worden ondersteund, en tools om samenwerking en MLOps mogelijk te maken, moeten beschikbaar zijn.

Met deze aannames in gedachten, geloven we dat Ray de basis zal zijn van toekomstige ML-platforms. Veel ontwikkelaars en ingenieurs gebruiken het al voor hun machine learning-toepassingen, waaronder training, optimalisatie en service. Het pakt niet alleen de huidige uitdagingen aan, zoals schaal en prestaties, maar is ook goed gepositioneerd om toekomstige workloads en gegevenstypen te ondersteunen. Ray, en het groeiende aantal bibliotheken dat erop wordt gebouwd, zal de komende jaren helpen bij het opschalen van ML-platforms. We kijken ernaar uit om te zien wat je bouwt.

Scott_Fincher_Paolo_Tamagnini_Maarit_Widmann_600x448.jpg

Guided Visualization and Guided Exploration

by with No Comment & EducationanalyticsArticlesautomated data scienceBI / Data Science BlogsBI / Data Science Newsbusiness analystBusiness intelligenceData Blogs | Information From Enterprise LeadersData Educationdata qualitydata sciencedata scientistdata visualizationguided analyticsguided explorationguided visualizationSmart Data BlogsSmart Data News

Click to learn more about co-author Scott Fincher.

Click to learn more about co-author Paolo Tamagnini.

Click to learn more about co-author Maarit Widmann.

No matter if we are experienced data
scientists or business analysts, one of our daily routines is the easy and
smooth extraction of the relevant information from our data regardless of the
kind of analysis we are facing.

A good practice for this is to use data visualizations: charts and graphs to visually summarize the complexity in the data. The required expertise for data visualization can be divided in two main areas:

  • The ability to correctly prepare
    and select a subset of the dataset columns and visualize them in the right
    chart
  • The ability to interpret the
    visual results and take the right business decisions based on what is
    displayed

In this post we will see how visual interfaces for business intelligence, i.e. guided analytics, can help you in creating visualizations on the fly and also identify complex patterns via those visualizations.

Guided visualization is about guiding
the business analyst from raw data to a customized graph. The
business analyst is led through the process and prompted to select the columns
to be visualized, while everything else is automated. In contrast, guided exploration navigates
the data scientist from large masses of data to an
automatically computed set of visualizations showing statistically interesting
patterns. 

In the final section of this article,
we summarize the common practices and strategies used to build those guided analytics
applications, such as re-using functionalities by sharing components.

Guiding a Business Analyst from Data Selection to the Right Graphs

The challenges of data visualization are many. Often our data at hand contain values in data types that are not suitable for our analysis. For example, how do we calculate the number of days between two events, if the date values are reported as String? The numbers “6” and “7” make more sense as String, if they indicate Friday and Saturday, don’t they? These kinds of Data Quality issues affect not only how successful we are in further analyzing the data, but they also affect our choice of graphs for reporting. For example, if we want to plot values by time, or assign a color to a day of the week, these columns have to have the appropriate data types. 

However, even with perfect data, we
don’t always end up with an optimal visualization that shows how the data have
developed or highlights relationships in the data. The right graph depends on
our purpose: Do we want to visualize one or more features? Are the features
categorical or numeric? Here it comes down to our expertise as a business
analyst to select the graph that best communicates our message.

The task of selecting the best graph has not necessarily become easier with the increasing number of graphs and visualization tools available. Additionally, the easier we make it for ourselves to build a graph (visualization), the more difficult it becomes to intervene in the process (guided). Ideally, we would like to combine our business expertise – allowing the business analyst to intervene and add their knowledge – with the automated Data Science tasks – i.e automatically creating the visualization based on the expertise supplied. 

Guided Visualization: Automating When Possible and Interacting When Needed

The cost of many all-in-one
visualization solutions is that they don’t consider the whole process of data
visualization from accessing the raw data to downloading a customized graph.
Using these types of tools we would get a graph despite having provided unclean
data. And if we wanted to visualize only a subset of the data, we would
probably have to filter the input data first. Without filtering the input data
first, a graph showing sales developments for the last year could be our only
choice, given that the data consists of sales for the whole year: not that
useful if we’re only interested in developments in the last quarter. 

Guided visualization provides a more comprehensive view of the process of building graphs as shown in Figure 1.

Figure 1: The process of data visualization from accessing raw data to downloading and deploying a customized graph. The Guided Visualization application considers the whole process and allows user interaction in the middle of it.

In the data cleaning phase, even
advanced business analysts can easily overlook columns that contain only
constant values or numeric columns with few distinct values. Date&Time
values are easier to spot, but we need to make sure that we don’t lose or
change any information when we convert their data type. Given these challenges,
we want to automate as many of these tasks as possible, yet not trust the
results blindly. In the process of Guided Visualization, the business analyst
can check the results after each process step and, if needed, apply further
changes. 

After the data preparation and column
selection step, we are ready to move on to building the first version of the
graph. If we were asked whether we preferred a line plot, a bar chart, etc.,
few of us could build these options in their minds and make the decision. In
the guided visualization process, selecting the relevant graph is made easier
by way of a dashboard, which shows a collection of potential and relevant
graphs. At this point, the expertise of a business analyst is brought back into
the process: Which graph serves my purpose best? Are the title and labels
informative? Is the range of the graph appropriate? These changes can be
applied via the interactive dashboard. Once ready, the final step is to
download the graph as an image file.

Guided Visualization Workflow

The guided visualization process as
described above requires a logic that automates the process steps from data
cleaning to selecting the columns to be visualized, accessing a set of relevant
graphs, selecting and customizing the graphs, through to downloading the final
graphs as image files. The process is partly affected by the business analyst’s
decisions at the interaction points. 

So let’s have a look at the guided visualization workflow itself and the steps that are involved. Figure 2 shows these steps. Each component enables user interaction during the process, whereas the calculations between the components take place fully automatically in the background. You can download the workflow from the Hub. 

Figure 2: A workflow for Guided Visualization that asks for interaction in the process steps for reading the data, selecting the columns to visualize, customizing the graphs, and downloading the final images. All other process steps, such as converting the domains of the columns and removing columns with only constant values, happen automatically in the background.

Components enable interaction: Upload -> Select
Columns -> Select
Domains -> Customize -> Download

  • The first interaction point is
    enabled by the “Upload” component where the business analyst selects a
    data file
  • The second interaction point is
    enabled by the “Select Columns” component. It produces an interactive
    dashboard, which the business analyst can use to select which column(s) to
    visualize
  • The third interaction point, the
    “Select Domains” component, is optional. At this point, the business
    analyst can manually change the data types of the selected columns
  • The fourth interaction point is
    the “Customize” component. It shows a collection of relevant graphs based
    on the number of columns and their data types. Here the business analyst
    can select one or more graphs, change their labels, zoom them, and apply
    other visual changes
  • The fifth and final interaction point
    is the “Download” component that enables downloading the selected and
    customized graphs as images.

Of course not all of the specific requests of the business analyst will match the steps of guided visualization we’ve described above. However, the same logic remains useful in extended and modified versions of the same process. For example, it’s easy to insert more interaction points as components into our workflow (in Figure 2). We could also provide more graphs than are provided by the process so far (Figure 3). We would do this by adding new nodes inside the nested components shown in Figure 4.

Figure 3: Some of the possible graphs generated by the guided visualization process when the business analyst has selected two columns.
Figure 4: A workflow showing one process step (the “Customize” component in the workflow available on the Hub) in the guided visualization process. Here a selection of graphs is generated based on the number and type of the selected columns. Each selection of graphs can be enhanced with other nodes for visualization into the corresponding component.

Guiding a Data Scientist from Unexplored Data to Interesting Data

More experienced users, like for example data scientists, might also find the process of visualizing data challenging, especially if the data come from an unexplored and complex dataset. By complex we mean hundreds of columns with cryptical names for example. This problem is common in the earliest stage of the analytics process where the expert needs to understand the data before making any assumptions. Data visualization is a powerful tool for data exploration, however, if we have hundreds of unknown columns what needs to be visualized first?

Automatically Visualizing Interesting Patterns Between Columns

One approach to quickly find the
interesting columns to visualize is by using statistical tests. Here, we take a
good sample of our really large dataset and we start computing a number of
statistics for single columns, pairs of columns, and even groups of columns.
This is usually computationally expensive so we should make sure that the
sample we take isn’t too big.

Using this approach we find interesting patterns – for example the most correlated pair of columns (Figure 6), a column with a skewed distribution, or one with a profusion of outliers. The statistical tests naturally take the domain of the data into account. For example, if we want to find an interesting relationship between a categorical and a numeric column, we wouldn’t use correlation measures but the ANOVA test (Figure 7) instead.

Ultimately, we will find a long list of
patterns and relationships to be visualized. What then? Well based on what we
want to visualize, we can find the best visualization for each interesting
pattern. How do we visualize the most correlated columns? We can use a scatter
plot. How can we show outliers in a column? We could use a box plot. Finding
the best visualization for each interesting pattern is a crucial step and might
need some visualization background. But what if we had a tool able to
automatically first find those patterns and then also visualize them in the
most suitable chart? All we then have to do is to provide the data and the tool
gives us visualizations in return.

Guided Exploration Workflow

This is what the workflow for guided exploration does. You can see it in Figure 5: it reads the data, computes the statistics, and creates a dashboard (Figure 6), which visualizes them. Nice right?

Figure 5: A workflow for guided exploration that asks for raw data, calculates statistics on the data and automatically visualizes the found patterns and relationships in a dashboard. This can help data scientists in quickly exploring and understanding complex data.
Figure 6: Parts of the dashboard generated by the Guided Exploration workflow. The graphs show highly correlated and inverse correlated columns in scatter plots for the numeric columns and in a sunburst chart for the categorical columns. The automatically generated dashboard can help data scientists to understand and explore a complex data.

The Human in the Loop

In raw data, the most intense patterns
are actually the result of columns of a bad quality: two columns that are
practically identical would subsequently give high correlation; or columns with
too many constant or missing values, and so on. Furthermore, we might have
columns with obvious relationships because they, for example, measure the same
thing but with different units. Examples of these patterns are shown in Figures
6 and 7.

Whatever the cause, it is likely that the first time we visualize statistics calculated on raw data our results will be disappointingly boring. That is why the dashboard is in a recursive loop, as shown in the workflow in Figure 5.

The way this works is that we can iteratively remove the columns that are not interesting for some reason. We become the Human-in-the-Loop and iteratively choose which data columns should be kept and which should not, based on what the dashboard shows us. After a few iterations we will see a good number of interesting charts. All we need to do now is sit back, relax, let the workflow take us through a univariate and multivariate analysis, and extract the important information.

Figure 7: These two visualizations, a stacked histogram and a conditional box plot, show both the relationship between the distribution of a numeric column (DepTime) and a categorical column (delay_class). We can see how the two subsets of data assume a different distribution. If we partitioned the data using the two categorical values “delay” and “no delay”, we could confirm this using an ANOVA test.

Executing the Model

You can download the workflow from the Hub, deploy it to your Server and execute it from the WebPortal, and – iteration after iteration – discard columns from any web browser. At the end of the loop it is up to you what you want to do with the few relevant columns that are left. You could simply output the results, or add more nodes to the workflow and immediately extend your analysis with other techniques. You might for example train a simple regression model given the lucky correlation with your target that you’ve just found – thanks to this process.

Customizable and Reusable Process Steps

If you look closely at the two
workflows presented above you’ll notice that there are quite a few similarities
between them. Things like the layout, internal documentation, overall style,
and functionality are consistent across these workflows. This is by design, and
you can incorporate this consistency in workflows too.

Layouting and Page Design

By using the newly updated layout panel in WebPortal preparation, you have the ability to make consistently formatted pages, complete with padding, titles, headers, footers, sidebars – everything needed to make a professional looking combined view.

When combined with an initial CSS Editor node, you can define presentation elements like font selection, size, and placement in a single component and then pass those downstream to all subsequent nodes for a consistent display. The above are all elements of layout and page design that were used in the guided visualization and guided exploration workflows: Arranging the components’ views that correspond to web pages, enhancing the display and consistency with CSS styling and customizing the appearance of the WebPortal with dynamic headers and sidebars.

Component Re-use and Sharing

Beyond just similarity in look-and-feel
between workflows, we also re-used functionality between workflows where it
made sense to do so. After all, why create workflow functionality from scratch
if it has already been implemented and tested in an existing workflow? There’s
no need to re-invent the wheel, right?

For common tasks that we needed to
implement in these workflows – things like uploading files, selecting columns,
saving images, and so forth – there is a component.

Now, with the new Hub, you also have
the ability to import components and nodes directly into our own workflows!

Components vs. Metanodes

Another area of consistency in these workflows was the way we used components, as opposed to metanodes. We made a conscious decision early on to make use of components whenever we knew a user interaction point in the webportal would be required. So whenever the user is asked, for example, to choose columns for a model, or perhaps select a particular graph for visualizing data, this option was always included in component form.

Figure 9: Examples of shared components that encapsulate often repeated tasks in the guided visualization and guided exploration workflows, and enable user interaction in the view that they produce.

We used metanodes regularly too, but
for different reasons. Where logical operations, automated functions, or just
simple organization and cleanup were needed, this is where metanodes were
brought in. When needed, we would nest metanodes within each other – sometimes
multiple times. This process is all about making sure the workflow has a clean
look, and is easy to understand.

Workflow Design Considerations

When you’re designing your own workflows, you might even want to think about this method for using components and metanodes from the very beginning. Before dragging and dropping individual nodes into a workflow, start first with empty components and metanodes that represent the overall functionality. It might look something like this:

Figure 10: The process steps in the workflow for guided visualization. Each component inside the upper box corresponds to an interaction point, and each metanode inside the lower box corresponds to an automated process step.

Summary

The processes of guided visualization
and exploration require a number of decisions: What are the most important
columns for my purpose? How do I visualize them? Are all columns necessary to
keep in the data? Do they have the appropriate data types?

A business analyst might easily explain
the development shown by a graph, but comparing different ways of visualizing
the development might be outside of his/her interest or expertise. On the other
hand, someone who’s an expert in building fancy graphs doesn’t necessarily have
the best understanding for interpreting them. That’s why an application that automates
the steps that require out-of-domain expertise can be practical in completing
day-to-day tasks. 

Here we have shown how a business
analyst can start with raw data and generate relevant and useful
visualizations. On top of that, we’ve presented a workflow that can help a data
scientist gain better understanding of complex data.

1600247230_Eva_Murray_600x448.jpg

Wat zijn GPU’s en waarom houden datawetenschappers van ze?

by with No Comment & EducationanalyticsArticlesBI / Data Science BlogsBI / Data Science NewsBusiness intelligenceCPUData Architecture BlogsData Architecture NewsData Blogs | Information From Enterprise LeadersData Educationdata sciencedata scientistdatabasedeep learningGPUgraphics processing unitpython libraryTensorFlow

Klik voor meer informatie over auteur Eva Murray.

Beweeg over, CPU’s. De GPU’s zijn aangekomen in moderne ondernemingen en datawetenschappers willen ze graag gebruiken voor hun modellering en deep learning-toepassingen.

Waarom gebeurt dit en wat zijn de voordelen van GPU’s voor Data Science-toepassingen? Lees verder en kom erachter.

Wat zijn GPU’s?

GPU’s, of grafische verwerkingseenheden, worden al decennia lang in de game-industrie gebruikt en werden populairder toen Sony de term voor het eerst gebruikte met betrekking tot zijn PlayStation-console. Ze zijn essentieel geweest voor de snelle weergave en verwerking van computerspellen en hebben de ervaring voor gamers radicaal veranderd naarmate de graphics steeds gedetailleerder, genuanceerder en realistischer werden.

Hoewel GPU’s zijn ontworpen om afbeeldingen weer te geven door middel van snelle wiskundige berekeningen, is het deze krachtige verwerking die ze aantrekkelijk maakt voor Data Science. Het stelt AI in staat om te leren van beelden en geluiden, door enorme hoeveelheden beeld- en geluidsingangen te gebruiken voor deze diepe leerprocessen.

Om dit te realiseren, voeden GPU’s neurale netwerken die op schaal worden getraind, zodat eindgebruikers kunnen genieten van beeld-, video- en spraakgebaseerde applicaties, evenals de aanbevelingsengines die zo velen van ons gebruiken, of het nu gaat om het vinden van een goed restaurant of onze nieuwe favoriete sneakers.

Hoe hebben GPU’s invloed op de datawetenschap?

We zijn allemaal bekend met de noodzaak van een goede verwerkingskracht om ons werk gedaan te krijgen. Dat geldt zowel voor onze laptops en desktopcomputers als voor grotere infrastructuur zoals servers, switches en natuurlijk het netwerk waarop we allemaal vertrouwen.

De term CPU, centrale verwerkingseenheid, is gemeengoed en beschrijft de hoofdprocessor in een computer, het “brein” van de machine die instructies en programma’s uitvoert.

In Data Science, Python-bibliotheken zijn steeds efficiënter geworden in het gebruik van de bestaande beschikbare CPU-kracht. Als u echter met honderden miljoenen of zelfs miljarden records wilt werken en diepgaande leerapplicaties wilt uitvoeren, zijn CPU’s niet voldoende.

Enter: GPU’s met hun krachtige parallelle verwerkingsarchitectuur, waarmee organisaties bijvoorbeeld prognosemodellen kunnen uitvoeren voor miljoenen mogelijke productcombinaties voor hun winkels om hun magazijnactiviteiten te informeren, plannen en optimaliseren.

GPU’s en de kracht die ze naar Data Science brengen, openen nieuwe kansen voor datawetenschappers, analyse-afdelingen, en de organisatie als geheel.

CPU’s verwerken sequentieel, terwijl GPU’s parallel worden verwerkt. Dus zelfs een groot cluster van CPU’s kan niet dezelfde prestaties behalen als de juiste architectuur van GPU’s voor het trainen van deep learning-algoritmen.

GPU’s

Stel je nu deze geoptimaliseerde parallelle architectuur van GPU’s voor, gecombineerd met de massaal parallelle verwerking die in je database is ingebouwd. Uw databasesoftware en -hardware zijn nu perfect afgestemd op de AI-taken die u wilt uitvoeren, waarbij beide van elkaar profiteren en elkaar optimaal benutten.

Om de prestaties van onze database die op GPU’s draait te testen, hebben we een model getraind in TensorFlow, met behulp van een dataset van fine food-recensies van Amazon. De dataset bevat meer dan 500.000 beoordelingen van meer dan 10 jaar. Ons model is ontworpen om de score voor elk product te voorspellen op basis van de tekst van de recensie, waar we het sentiment willen analyseren. We kunnen dan de voorspelde score vergelijken met de werkelijke score die beschikbaar is in de gegevens maar niet wordt gebruikt in de training.

De dataset bevat categorische, numerieke en tekstdata, wat het een mooie uitdaging maakt voor ons model, dat gebaseerd is op een voorgetraind model in TensorFlow, genaamd Universal Sentence Encoder. De complexiteit van de dataset zorgt voor een interessante use case voor GPU’s, omdat niet alleen de verschillende datatypes specifieke coderingsstrategieën vereisen, maar de grote hoeveelheid tekst vereist ook een groot model, wat een goede test zal zijn voor onze GPU’s.

Als je wilt leren hoe je een TensorFlow-model traint in UDF’s op GPU’s, ga dan naar deze gids op GitHub.

De resultaten

Voor onze tests hebben we de volgende instellingen gebruikt op Google Cloud Platform (regio: Iowa):

  • 1x NVIDIA Tesla K80
  • 1x NVIDIA Tesla V100
  • 1x CPU met 8 kernen
  • 1x CPU met 32 ​​kernen

Bij het vergelijken van de prestaties van GPU’s en CPU’s voor het trainen van ons model, voltooide de K80 elk tijdperk 9,9 keer sneller (72 sec versus 710 sec) dan de CPU met 8 cores en 2,9 keer sneller (72 sec versus 210 sec) dan de CPU met 32 ​​cores.

De V100, de meest geavanceerde GPU die momenteel beschikbaar is in de cloud, voltooide elk tijdperk 28,4 keer sneller (25 sec versus 710 sec) dan de 8-core CPU en 8,4 keer sneller (25 sec versus 210 sec) dan de 32-core CPU.

Deze resultaten spreken voor zich en bieden onze klanten en gebruikers echte kansen om hun Data Science-applicaties rechtstreeks naar de database te verplaatsen.

Wat zijn de kansen voor GPU’s in Data Science en Analytics?

GPU’s zijn essentieel voor datawetenschappers die met grote datavolumes werken aan het ontwikkelen, trainen en verfijnen van hun modellen. Ze bieden een meer kosteneffectieve optie voor het laden en manipuleren van gegevens op deze schaal dan CPU’s en behalen daarom het dubbele voordeel van lagere infrastructuurkosten in combinatie met verbeterde prestaties.

Gezien de vraag naar datawetenschappers in de markt en de waarde die organisaties zouden moeten hechten aan hun vaardigheden, bieden GPU’s geweldige kansen om datawetenschappers in staat te stellen meer tijd te besteden aan taken met toegevoegde waarde en ervaar minder frustraties als gevolg van traag presterende systemen en tools.

GPU’s bieden deze voordelen overal waar een organisatie gegevens heeft: in de cloud, op locatie of in een hybride model.

Maarit_Widmann_Alfredo_Roccato_600x448.jpg

Van modelleren tot scoren: een optimale classificatiedrempel vinden op basis van kosten en winst

by with No Comment & EducationArticlesBI / Data Science BlogsBI / Data Science NewsBusiness intelligenceclass statisticsData Blogs | Information From Enterprise LeadersData Educationdata sciencedata scientistmatrix statisticsmodel evaluationmodelingnumeric predictionoptimal classificationscoringSmart Data BlogsSmart Data Newsunbalanced datasets

Klik voor meer informatie over co-auteur Maarit Widmann.

Klik voor meer informatie over co-auteur Alfredo Roccato.

Rijden als een hamster in de Data Science-cyclus? Weet u niet wanneer u moet stoppen met het trainen van uw model?

Modelevaluatie is een belangrijk onderdeel van een Data Science project en het is precies dit deel dat kwantificeert hoe goed uw model is, hoeveel het is verbeterd ten opzichte van de vorige versie, hoeveel beter het is dan het model van uw collega, en hoeveel ruimte voor verbetering er nog is.

In deze reeks berichten bekijken we verschillende scorestatistieken: voor classificatie, numerieke voorspelling, ongebalanceerde datasets en andere vergelijkbare, meer of minder uitdagende, modelevaluatieproblemen.

Vandaag: classificatieresultaten bestraffen en belonen met een winstmatrix

Verwarmeringsmatrix en klassenstatistieken vat de prestaties van een classificatiemodel samen: de werkelijke en voorspelde verdeling van de doelklassen, de nauwkeurigheid van de toewijzing in de positieve klasse en het vermogen om de positieve klasse-gebeurtenissen te detecteren. Deze statistieken houden echter geen rekening met de kosten van een fout, dat wil zeggen een voorspelling in de verkeerde doelgroep.

Als de verdeling van de doelklassen onevenwichtig is, vereist het correct voorspellen van gebeurtenissen in de minderheidsklasse hoge modelprestaties, terwijl het voorspellen van gebeurtenissen in de meerderheidsklasse gemakkelijk toevallig kan gebeuren. Zou het niet zinvol zijn om hier rekening mee te houden en de resultaten anders te wegen bij het evalueren van de modelprestaties?

Uiteindelijk bepaalt het uiteindelijke doel van de classificatie of het zinvol is om kosten in te voeren voor bepaalde typen classificatieresultaten. Kosten zijn handig wanneer onjuiste voorspellingen in de ene doelklasse ernstiger gevolgen hebben dan onjuiste voorspellingen in de andere klasse (n). Of, anders gezegd, correcte voorspellingen in de ene klasse hebben gunstiger gevolgen dan correcte voorspellingen in de andere klasse (n). Het niet detecteren van een criminele passagier op de veiligheidscontrole van de luchthaven heeft bijvoorbeeld ernstiger gevolgen dan het per ongeluk classificeren van een niet-bedreigende passagier als gevaarlijk. Daarom moeten deze twee soorten onjuiste voorspellingen verschillend worden gewogen. Er zijn geen kosten nodig als alle doelklassen even interessant of belangrijk zijn, en de gevolgen van een verkeerde voorspelling in de ene doelklasse net zo slecht zijn als voor de andere klassen. Dit is het geval wanneer we bijvoorbeeld de kleur van een wijn of het geslacht van een klant voorspellen.

Van modelnauwkeurigheid tot verwachte winst

Naast nauwkeurigheidsstatistieken kunnen de prestaties van een classificatiemodel worden gemeten aan de hand van verwachte winst. De winst wordt gemeten in een concrete eenheid die wordt bepaald door het uiteindelijke doel van de classificatie.

Wanneer we in de praktijk classificatieresultaten gebruiken, kennen we elke voorspelde klasse een andere behandeling toe: criminele passagiers worden aangehouden, niet-bedreigende passagiers worden doorgelaten. Risicovolle klanten krijgen geen kredietverstrekking, kredietwaardige klanten wel! Enzovoort. De meest wenselijke classificatieresultaten leveren winst op, zoals de beveiliging van een luchthaven of het geld dat een kredietinstelling verdient. Deze winst meten we in een vooraf gedefinieerde eenheid zoals het aantal dagen zonder terreuralarm, of euro’s. De meest ongewenste resultaten brengen kosten met zich mee – een terreuralarm op de luchthaven of geld verloren door een bank – en we meten de kosten in dezelfde eenheid als de winst.

Hier beoordelen we de nauwkeurigheid en verwachte winst van een classificatiemodel dat de kredietwaardigheid van kredietaanvragers voorspelt. In een credit scoring-applicatie heeft het voorspellen van individueel klantgedrag een consequentie in termen van winst (of verlies). Het weigeren van goede kredieten kan leiden tot verlies van winstmarges (commercieel risico). Het goedkeuren van krediet voor aanvragers met een hoog risico kan leiden tot slechte schulden (kredietrisico).

Classificatiedrempel optimaliseren

Een classificatiemodel voorspelt een positieve klassenscore voor elke gebeurtenis in de gegevens. Standaard worden de gebeurtenissen toegewezen aan de positieve klasse als hun score hoger is dan 0,5, en anders aan de negatieve klasse. Als we de classificatiedrempel wijzigen, veranderen we de toewijzing in de positieve en negatieve klasse. Bijgevolg veranderen ook de waarden van nauwkeurigheid en verwachte winst.

De data

In dit voorbeeld gebruiken we de bekende Duitse kredietgegevensset, zoals overgenomen uit de Archief van de Universiteit van Californië voor machinaal leren en intelligente systemen.

De dataset is samengesteld uit 1000 klanten. De inputvariabelen zijn de individuele kenmerken van de onderwerpen, zoals sociaal-demografische, financiële en persoonlijke, maar ook die met betrekking tot de lening, zoals het geleende bedrag, het doel van de inschrijving en vermogensindicatoren. Het doel is de beoordeling van de kredietwaardigheid van de kredietaanvrager door de bank (2 = risicovol en 1 = kredietwaardig).

In deze dataset worden 700 aanvragers (70%) geclassificeerd als kredietwaardig en 300 (30%) als risicovol.

We noemen de risicovolle klanten de positieve klasse en de kredietwaardige klanten de negatieve klasse.

Workflow om verwachte winst te produceren voor verschillende classificatiedrempels

De workflow die in Figuur 1 wordt getoond, begint met gegevenstoegang en voorverwerking. Om de voorspellende mogelijkheden van het model te beoordelen, wordt de initiële dataset verdeeld in twee even grote tabellen, respectievelijk de trainingsset en de validatieset genoemd. Vervolgens wordt op de trainingsset een logistisch regressiemodel getraind om de kredietwaardigheid van de sollicitanten te voorspellen.

Binnen de metanode “Winst per drempel” worden aanvragers in de validatieset toegewezen aan de twee kredietwaardigheidsklassen “risicovol” en “kredietwaardig” op basis van de positieve klassenscores die worden voorspeld door het logistieke regressiemodel, en een classificatiedrempel. De classificatie wordt meerdere keren herhaald, te beginnen met een lage waarde van de drempelwaarde en deze voor elke iteratie te verhogen. De uitvoertabel van de metanode bevat de nauwkeurigheidsstatistieken en verwachte winst zoals verkregen met de verschillende drempelwaarden en een vooraf gedefinieerde winstmatrix.

Ten slotte worden de prestatiestatistieken van het model voor verschillende drempelwaarden getoond in een interactieve samengestelde weergave zoals geproduceerd door de component “Winstweergaven”.

U kunt deze workflow downloaden van:

  • Hub
  • EXAMPLES Server (EXAMPLES / 04_Analytics / 10_Scoring / 02_Optimizing_Classification_Threshold_Based_on_Profit)
Figuur 1: Workflow om een ​​classificatiemodel te trainen en om nauwkeurigheidsstatistieken en verwachte winst te produceren op basis van de voorspelde positieve klassenscores, vooraf gedefinieerde winstmatrix en variërende waarden van de classificatiedrempel. Een optimale drempelwaarde kan empirisch worden gedefinieerd uit de interactieve samengestelde weergave en tabeluitvoer die de nauwkeurigheid en verwachte winst door verschillende drempelwaarden laten zien. De workflow kan worden gedownload vanaf de EXAMPLES Server en op de Hub

Winstmatrix

Om misclassificatie te beoordelen in termen van verwachte winst, wordt een winstmatrix gevraagd om kosten toe te wijzen aan ongewenste uitkomsten.

We introduceren negatieve kosten (-1) voor de valse negatieven – risicovolle aanvragers die een krediet krijgen – en een positieve winst (0,35) voor de echte negatieven – kredietwaardige aanvragers die een krediet krijgen. De winstmatrix in Tabel 1 toont de kosten- en winstwaarden voor deze classificatieresultaten.

Tabel 1: Winstmatrix die winst toevoegt aan de classificatieresultaten: kosten voor goedgekeurde slechte kredieten en winst voor goedgekeurde goede kredieten.

De waarden van kosten en winst geïntroduceerd in tabel 1 zijn gebaseerd op de volgende hypothese [1]: Laten we aannemen dat een juiste beslissing van de bank zou resulteren in 35% winst aan het einde van een bepaalde periode, zeg 3-5 jaar. Als het tegendeel waar zou zijn, dat wil zeggen dat de bank voorspelt dat de aanvrager kredietwaardig is, maar het blijkt een slechte kredietwaardigheid te zijn, dan is het verlies 100%.

Verwachte winst berekenen

De volgende formules worden gebruikt om de modelprestaties te rapporteren in termen van verwachte winst:

Waar p is het aandeel van de positieve (risicovolle) klassegebeurtenissen van alle gegevens.

Waar n is het aantal kredietaanvragers. Meer in het algemeen, aangenomen dat de klasse met een negatief risicopotentieel wordt gedefinieerd als de positieve klasse, kan een gemiddelde winst voor een classificatiemodel met een winstmatrix worden berekend met behulp van de volgende formule:

Waar n is het aantal gebeurtenissen in de gegevens. In dit voorbeeld hebben we 500 kredietaanvragers in de validatieset met een gemiddelde lening van € 10.000. 70% van de aanvragers is kredietwaardig en 30% is risicovol. Laten we eerst een basislijn voor de winststatistieken berekenen zonder een classificatiemodel te gebruiken:

Als we een krediet goedkeuren voor alle aanvragers, bedraagt ​​het verwachte verlies 225.000 €.

Laten we vervolgens uitrekenen wat de verwachte winst is als we de kredietwaardigheid evalueren met behulp van een classificatiemodel en we wegen de uitkomsten af ​​met de winstmatrix.

De minimumdrempel voor de positieve klasse om niet-nulwinst te behalen [2] kan uit de kostenmatrix worden berekend als:

Deze waarde kan empirisch worden aangepast zoals hieronder beschreven.

De workflow die in Figuur 2 wordt getoond, herhaalt verschillende drempels naar de positieve klassenscores die zijn voorspeld door een classificatiemodel, hier een logistisch regressiemodel. De drempelwaarden variëren van 0 tot 1 met een stapgrootte van 0,01. De workflow produceert de algehele nauwkeurigheid voor elke waarde van de drempel door de werkelijke (ongewijzigd in elke iteratie) en voorspelde (gewijzigd in elke iteratie) doelklassewaarden te vergelijken. Om de verwachte winst te berekenen, worden de classificatieresultaten van elke iteratie gewogen met de waarden in de winstmatrix. In de uitvoertabel van deze workflow komt elke rij overeen met een waarde van de classificatiedrempel, bovendien worden voor elke classificatiedrempel de modelnauwkeurigheidsstatistieken, de gemiddelde winst per aanvrager, het gemiddelde bedrag per aanvrager en het totale gemiddelde bedrag weergegeven.

Figuur 2: Produceren van de nauwkeurigheid en verwachte winst voor verschillende classificatiedrempelwaarden van 0 tot 1 met een stapgrootte van 0,01. Invoergegevens bevatten de werkelijke waarden van de doelklasse, positieve klassenscores voorspeld door een classificatiemodel en winstmatrixwaarden.

De resultaten

De interactieve samengestelde weergave in figuur 3 laat zien hoe de waarden van vier verschillende prestatie-indicatoren van het model zich ontwikkelen als de waarde van de classificatiedrempel stijgt van 0 naar 1. De prestatie-indicatoren zijn: 1. Algehele nauwkeurigheid (lijndiagram in de linkerbovenhoek) 2 Totaal gemiddeld bedrag (lijndiagram in de rechterbovenhoek), 3. Gemiddelde winst per aanvrager (lijndiagram in de linker benedenhoek), en 4. Gemiddeld bedrag per aanvrager (lijndiagram in de rechter benedenhoek).

Figuur 3: Een interactieve samengestelde weergave om de ontwikkeling te tonen van 1. Algemene nauwkeurigheid, 2. Totaal gemiddeld bedrag, 3. Gemiddelde winst per aanvrager, en 4. Gemiddeld bedrag per aanvrager wanneer de classificatiedrempel stijgt van 0 naar 1.

Gebaseerd op een empirische evaluatie, de optimale drempel is 0,51 in termen van algehele nauwkeurigheid en 0,27 in termen van verwachte winst. Tabel 2 geeft de prestaties weer van het logistische regressiemodel met behulp van de standaard en geoptimaliseerde drempelwaarden in termen van algehele nauwkeurigheid en gemiddelde winst per aanvrager:

Tabel 2: Verwachte winst en algehele nauwkeurigheid wanneer kredietwaardigheid helemaal niet wordt voorspeld, en wanneer deze wordt voorspeld met behulp van de standaard en geoptimaliseerde classificatiedrempels 0,113 winst per aanvrager geeft een gemiddeld bedrag van 1.130 € en, op basis van 500 aanvragers, het totale gemiddelde bedrag is 565.000 €.

Referenties

[1] Wang, C., & Zhuravlev, M. Een analyse van winst en klanttevredenheid in consumentenfinanciering. Case Studies in het bedrijfsleven, de industrie en overheidsstatistieken, 2(2), pagina’s 147-156, 2014.

[2]

C. Elkan. De basis van kostenbewust leren. In Proceedings of the Seventeenth International Joint Conference on Artificial Intelligence, pagina’s 973-978, 2001.