Updates from FFL on new papers, articles, and exciting developments
View this email in browser

Hello! In this month’s newsletter, we take a look at causality in machine learning, and machine learning in the browser.

Causality in machine learning

by Seth

Judea Pearl, the inventor of Bayesian networks, recently published a book called The Book of Why: The New Science of Cause and Effect. The book covers a great many things, including a detailed history of how the fields of causality and statistics have long been at odds, Pearl’s own do-calculus framework for teasing causal inferences from observational data, and why (in Pearl’s view) the future of AI depends on causality.

One of the key points in Pearl’s book is that observational data - data collected from real world systems - on its own, can only possibly convey associations between variables. To glean which variables in the data act as causes, and which are effects of those causes, we need something more. The implications are profound. A pharmaceutical company cannot ever tell if a particular drug is an effective treatment for a disease simply by observing the outcomes of patients who have taken that drug. It is impossible for scientists to prove that smoking causes lung cancer from observing outcomes of smokers and non-smokers. And yet, these are both things that we as a society have the capability to do today.

The traditional method for proving cause and effect is called a randomized controlled trial. In a randomized controlled trial, you randomly assign some test subjects to a treatment group and some to a control group. In the case of proving the effectiveness of a drug, patients are randomly assigned to receive the drug or not. By doing this, you can guarantee that the two groups are the same in every possible way, except for the treatment. If you then observe that the outcomes of one group are better than another, you can conclude that the treatment causes the improved outcome.

But randomized controlled trials are expensive, slow, and oftentimes impossible. You cannot ethically force a group of patients to smoke for a lifetime simply for the sake of proving that smoking causes cancer. And indeed, this is precisely the dilemma that made it extremely difficult to prove that smoking causes cancer, a topic Pearl covers in exquisite detail in his book. On top of that, observational data is cheap and plentiful. Is there truly no way to tease causality from observational data?

In a recent panel on causality from the Machine Learning Summer School in South Africa, Columbia University professor David Blei explained that this conundrum is precisely what has motivated him to pursue causality in his research.

“When you sit down and read all the books about causal inference and all the papers about it, it’s very theoretical but there’s one message that you get, from the historical perspective anyway, which is that causal inference from observational data is impossible . . . To me that seemed silly, that with, say you’re a hospital and you have 250 million electronic health records of what medicines people received and what happened to those people. It seemed silly to say that it is impossible to learn, say that Advil helps headaches.”

There are many ways in which causal understanding could improve the fields of machine learning and AI, and the ability to reliably infer causation from observational data is a hot topic. Judea Pearl’s do-calculus is primarily a framework for doing just that. Under the right conditions and with some assumptions, causality can be inferred from purely observational data.

A machine learning model that captures causal relationships of data is one way to ensure that the model will generalize to new settings, one of the most difficult aspects of machine learning. A model that associates the rising of the sun with the crow of a rooster may be able to adequately predict when the sun will rise. If the rooster has just crowed, the sun will rise shortly thereafter. This model will not, however, generalize to situations where there is no rooster. It would never predict that the sun will rise because it has never observed such a data point. However, if the model captured the causal relationships between the two, that the sun being about to rise causes the rooster’s crow, it would be obvious that the sun will rise even without the rooster.

Causality is also tightly related to fairness in machine learning, a topic we care deeply about. In The Book of Why, Pearl discusses the “Berkeley admissions paradox,” the story of one statistician’s attempt in the 1970s to detect potential discrimination against admitting women at UC Berkeley. Pearl discusses how traditional statistics combined only with observational data can lead to competing conclusions. It is possible to conclude that the university discriminated against women or that they discriminated in favor of women, depending on how you slice the data. Only using the language of causality can we draw correct conclusions.

The role of causality in AI and machine learning is a controversial topic, and Pearl has no problems stoking that controversy in his book. Regardless, The Book of Why has helped revive the topic of causality in the ML and AI communities. In the recent machine learning summer school in South Africa, there were multiple sessions on causality. At the recent Fairness, Accountability, and Trust conference there were multiple discussions devoted to causality. Textbooks on causality are being published and multiple jobs asking for causal inference are popping up. Though the immediate future of causality in machine learning is likely (still) limited to randomized controlled trials like A/B testing, the potential to draw causal conclusions from near-unlimited quantities of observational data is too great to ignore. Finally, Pearl argues that cause and effect are the key mechanisms through which humans process the complex world around them, and that we can never reach true artificial general intelligence without equipping machines with notions of cause and effect.

Machine Learning in the Browser

by Victor

The promise of Machine Learning (ML) on edge devices holds potential to enable new capabilities while reaping the benefits associated with on-device computation. As an environment that is frequently the source of data (user interactions, sensors such as cameras, acelerometers, etc.), the browser within PCs, mobile and IoT devices represents an important edge “platform.” Deploying models in such environments can improve latency for interactive applications, reduce model distribution costs, and enable privacy as data is no longer sent to remote servers for analysis.

In recent times, advances in graphic acceleration in the browser (WebGL), increasing compute capabilities on edge devices, and the advent of JavaScript-based ML frameworks make ML in the browser particularly exciting.

Why Machine Learning in the Browser?


By bringing computation directly to the user, there is opportunity to improve application latency. This is especially true for tasks that may or may not be computationally intensive but have been traditionally performed on remote servers. For example, recommendation tasks such as predicting a user’s next action (that previously involved roundtrip calls to a remote server (upload user data, process, download result)) can be performed in the browser with faster response times.


Perhaps, one of the most compelling strategies for building user trust in a product is to offer objective notions of privacy. In many cases, systems designed to be provably private (“we do not store your data”) can be more convincing than systems which offer privacy assurances (“we store your data, but only use it for specific known purposes”). With ML in the browser, it is possible to perform analysis on a client’s data on their device via the browser and provide value to them without transmitting their data to any servers for processing. An example is the ability to offer language translation or image captioning or document classification services for sensitive content in the browser. Within the same framework, models can be trained on a user’s local data and used to provide improved, personalized services.


Setting up a traditional environment for running ML models can be tedious and challenging to deploy. While these issues can now be addressed with the use of docker containers as well as dependency management packages, it is still challenging to package and distribute applications with ML models on end user devices. The process of bundling a client application that first installs frameworks such as Tensorflow or Pytorch, simply for the purpose of enabling ML capabilities, can be error prone, and varies with the distribution platform.

On the other hand, browser based deployments can leverage the standardized web environment with zero installation costs for the user and distribution costs for the developer. Costs associated with building for multiple platforms (e.g., CPU architectures, Operating Systems) are also avoided as mature web standards allow web applications to remain stable across these environments.

Libraries for Machine Learning in the Browser: Tensorflow.js

There are several open source libraries which provide a simple JavaScript API that allows users to build and train machine learning models in the browser. These include projects such as Tensorflow.js, ConvnetJS, Brain.js, Synaptic, Neataptic, WebDNN and Mind.

As of right now, Tensorflow.js appears to be the most mature API in terms of maintenance, integration with the broader ML ecosystem, and community adoption. TensorFlow.js consists of two sets of APIs: the Ops API which provides lower-level linear algebra operations (e.g., matrix multiplication, tensor addition, etc.), and the Layers API, which provides higher-level model building blocks and best practices with emphasis on neural networks. The Layers API is modeled after the tf.keras namespace in TensorFlow Python, which is based on the widely adopted Keras API and supports rapid prototyping of complex ML models.

Figure shows the architecture of the Tensorflow.js library. source

TensorFlow.js is designed to run in-browser and server-side, as shown in the figure above. When running inside the browser, it utilizes the GPU of the device via WebGL to enable fast parallelized floating point computation. In Node.js, TensorFlow.js binds to the TensorFlow C library, enabling full access to TensorFlow. TensorFlow.js also provides a slower CPU implementation as a fallback (omitted in the figure for simplicity), implemented in plain JS. This fallback can run in any execution environment and is automatically used when the environment has no access to WebGL or the TensorFlow binary. (See the Tensorflow.js paper here.)

Tensorflow.js integrates well with the broader Tensorflow ecosystem by providing a converter which also allows users to convert, load, and run existing Tensorflow models. Developers can build, train, optimize and test their models in Tensorflow (Python) and then export the resulting model for use in the browser.

Current Applications and Outlook

With Tensorflow.js, users can prototype and run models of varying complexity from simple linear/polynomial regression to complex neural networks for image recognition, object detection, pose detection, and Natural Language Processing.

There have also been interesting applications ranging from prototyping handsfree interactions for increased accessiblity, hand gesture interaction and numerous examples for teaching ML concepts. Furthermore, and as we mention in an earlier report, Tensorflow.js can enable Federated Learning where locally trained models (not data) from participating devices are shared with a central server. The server combines these into an updated federated model which is then shared with each device.

While these usecases are still emergent, one important limitation for ML in the browser is related to the single-threaded nature of JavaScript applications in the browser. Browsers typically have a “main thread” where JavaScript code, event processing, and other instructions are run. It does not support a multi-threaded paradigm (though research in this area is active) and can be less performant than other programming environments. If designed incorrectly, a compute intensive ML operation can “block” the main thread, which can hamper the overall interaction experience for users.

As edge devices become more compute capable, it is likely that more processing, including model training and inference tasks, will be shifted to the browser. It is also likely that more third party libraries and design patterns will begin to integrate the use of ML models in the browser.

Upcoming Events

If you’re attending any of these conferences, please let us know and stop by to say hello!

All the best,

The Cloudera Fast Forward Labs Team