Open problems

We will present six open problems at the workshop during a panel discussion at 4:30PM UTC, 17/07/2020.

If you are intending to attend the event, please take some time to read the problems below in advance in order to get the most out of the discussion:

Deploy machine learning models serverlessly at scale

Yuzhui Liu (Bloomberg), Dan Sun (Bloomberg), Clive Cox (Seldon)

With machine learning approaches becoming more widely adopted in organizations, there is a trend to deploy a large number of models. For example, a news classification service may train a custom model based on a news category. Another important reason why organizations desire to train a lot of models is to protect data privacy. It is safer to isolate each user’s data and train models separately. While you get the benefit of better inference accuracy and data privacy by building models for each use case, it is more challenging to deploy thousands to hundreds of thousands of models. Furthermore, there are an increasing number of use cases which serve neural network-based models. Those models are better served on GPUs to achieve reasonable latency. However, since GPUs are expensive resources, it is very costly to serve a lot of GPU-based models.This problem can be partially addressed using two different approaches. On the one hand, TFX serving (https://www.tensorflow.org/tfx/guide/serving), AWS multi-model-server (https://github.com/awslabs/multi-model-server) and Triton Inference Server (https://github.com/NVIDIA/triton-inference-server) support loading multiple models into a model server. However, they lack serverless features, such as autoscaling. On the other hand, KFServing (https://github.com/kubeflow/kfserving) is a popular model serving solution on Kubernetes. It provides a serverless deployment experience and scales server instances automatically. But, its 'one model, one server' paradigm presents challenges for a Kubernetes cluster when dealing with a large number of models. To scale the number of models, we have to scale the number of servers, something that can quickly run into the cluster's limits.A system that can load multiple models into a server and provide serverless features out of the box is an unsolved problem.

Model Selection for Production Systems

Zhenwen Dai (Spotify)

Evaluating the effect of individual changes to machine learning (ML) systems such as choice of algorithms, features, etc., is the key to growth in many internet services and industrial applications. Practitioners are always faced with the decision of choosing one from several candidate models to be deployed in production. This can be viewed as a model selection problem, however, classical model selection paradigms such as cross-validation consider ML models in insolation and focus on selecting the model with the best predictive power on unseen data. This assumption does not apply to modern industrial ML systems, as such a system usually consists of lots of individual components and a ML model is only one of them. The metric of interest often depends on uncontrollable factors like users' responses. Only optimizing the predictive power of the ML model would not lead to a better metric of the overall system. Instead, randomized experiments (also known as "A/B tests") are considered as the gold-standard of evaluating the system changes as they provide a more direct measure of the metric. However, only a few variants of the ML models can be tested using randomized experiments as they are time-consuming to conduct and have resource constraints (such as the number of active users, etc.), further deploying bad systems can lead to catastrophic consequences. Currently, the lack of safe and efficient ways to evaluate and analyze models before online deployment is a common bottleneck for ML development iterations in industry.

Machine learning severely lacks the formal processes and industry standards of other engineering disciplines

Alexander Lavin (Augustus Intelligence), Gregory Renard (Augustus Intelligence)

In recent years we have seen several investigations into the differences between traditional SWE and ML (e.g. Amershi et al. '19, Lavin & Renard '20, Breck et al. '16). Some have observed that the processes and nomenclature can be quite different in the development and deployment cycles; for example, the notions of "proof of concept" and "release version" have new meanings and requirements when ML is involved. Industrial AI teams define processes for ML systems development, but nonetheless struggle to communicate ML development with other teams, let alone non-technical stakeholders such as executives and clients. The industry could greatly benefit from ML systems engineering best-practices, along with a common nomenclature of tech maturity throughout the ML project lifecycle. Lavin & Renard '20 suggest such a framework, which the AI community should embrace and collectively improve to define an ML systems engineering standard for us all.

Green Lighting ML: Confidentiality, Integrity, and Availability of Machine Learning Systems in Deployment

Erick Galinkin (Montreal AI Ethics Institute and Rapid7) and Abhishek Gupta (Montreal AI Ethics Institute and Microsoft)

Security and ethics are both core to ensuring that a machine learning system can be trusted. In production machine learning, there is generally a hand-off from those who build a model to those who deploy a model. In this hand-off, the engineers responsible for model deployment are often not privy to the details of the model and thus, the potential vulnerabilities associated with its usage, exposure, or compromise. Techniques such as model theft, model inversion, or model misuse may not be considered in model deployment, and so it is incumbent upon data scientists and machine learning engineers to understand these potential risks so they can communicate them to the engineers deploying and hosting their models. This is an open problem in the machine learning community and in order to help alleviate this issue, automated systems for validating privacy and security of models need to be developed, which will help to lower the burden of implementing these hand-offs and increasing the ubiquity of their adoption.

Approaches to AI ethics must consider second-order effects and downstream uses, but how?

Alexander Lavin (Augustus Intelligence)

Problem: In the past several years we’ve seen AI ethics become a priority for industry and academia; simple slogans like “do no evil” have evolved into legitimate policies and ethics review boards. Many institutions define a process by which they screen projects to align with company ideals and values. Yet even after carefully selecting clients, there remains the risk of unintended uses and downstream effects of deployed ML systems. For example, a facial recognition product for a supermarket who then uses the results to send targeted ads that may be gender/race insensitive. Or consider a pricing algorithm developed for real estate brokers that may end up imposing racially segregated neighborhood borders, leading to effects such as discriminatory school districts. How can we ensure deployed AI models and algorithms are used as initially intended, months or years down the road? Even when the products are used as intended, how can AI companies keep an eye on second-order effects (in an unobtrusive way)?

SECure: A Social and Environmental Certificate for AI Systems

Camylle Lanteigne (Montreal AI Ethics Institute and McGill University), Abhishek Gupta (Montreal AI Ethics Institute and Microsoft), Sara Kingsley (Carnegie Mellon University)

An ESG style framework combining socio-technical measures to build eco-socially responsible AI systems is lacking, but is required to ensure consumers of AI systems can make choices aligned with their values. One possible framework would have four pillars: compute-efficient machine learning, federated learning, data sovereignty, and a LEEDesque certificate. Compute-efficient machine learning is the use of compressed network architectures that show marginal decreases in accuracy. Federated learning augments the first pillar’s impact through the use of techniques that distribute computational loads across idle capacity on devices. This is paired with the third pillar of data sovereignty to ensure the privacy of user data via techniques like use-based privacy and differential privacy. The final pillar ties all these factors together and certifies products and services in a standardized manner on their environmental and social impacts, allowing consumers to align their purchase with their values.

Google Sites

Report abuse