Did you know Neural is taking the stage this fall ? Together with an amazing line-up of experts, we will explore the future of AI during TNW Conference 2021. Secure your ticket now !

Machine learning is becoming an important tool in many industries and fields of science. But ML research and product development present several challenges that, if not addressed, can steer your project in the wrong direction.

In a paper recently published on the arXiv preprint server, Michael Lones, Associate Professor in the School of Mathematical and Computer Sciences, Heriot-Watt University, Edinburgh, provides a list of dos and don’ts for machine learning research.

The paper, which Lones describes as “lessons that were learnt whilst doing ML research in academia, and whilst supervising students doing ML research,” covers the challenges of different stages of the machine learning research lifecycle. Although aimed at academic researchers, the paper’s guidelines are also useful for developers who are creating machine learning models for real-world applications.

Here are my takeaways from the paper, though I recommend anyone involved in machine learning research and development to read it in full.

Pay extra attention to data

Machine learning models live and thrive on data. Accordingly, across the paper, Lones reiterates the importance of paying extra attention to data across all stages of the machine learning lifecycle. You must be careful of how you gather and prepare your data and how you use it to train and test your machine learning models.

No amount of computation power and advanced technology can help you if your data doesn’t come from a reliable source and hasn’t been gathered in a reliable manner. And you should also use your own due diligence to check the provenance and quality of your data. “Do not assume that, because a data set has been used by a number of papers, it is of good quality,” Lones writes.

Your dataset might have various problems that can lead to your model learning the wrong thing.

For example, if you’re working on a classification problem and your dataset contains too many examples of one class and too few of another, then the trained machine learning model might end up learning to predict every input as belonging to the stronger class. In this case, your dataset suffers from “class imbalance.”

While class imbalance can be spotted quickly with data exploration practices, finding other problems needs extra care and experience. For example, if all the pictures in your dataset were taken in daylight, then your machine learning model will perform poorly on dark photos. A more subtle example is the equipment used to capture the data. For instance, if you’ve taken all your training photos with the same camera, your model might end up learning to detect the unique visual footprint of your camera and will perform poorly on images taken with other equipment. Machine learning datasets can have all kinds of such biases.

The quantity of data is also an important issue. Make sure your data is available in enough abundance. “If the signal is strong, then you can get away with less data; if it’s weak, then you need more data,” Lones writes.

In some fields, the lack of data can be compensated for with techniques such as cross-validation and data augmentation. But in general, you should know that the more complex your machine learning model, the more training data you’ll need. For example, a few hundred training examples might be enough to train a simple regression model with a few parameters. But if you want to develop a deep neural network with millions of parameters, you’ll need much more training data.

Another important point Lones makes in the paper is the need to have a strong separation between training and test data. Machine learning engineers usually put aside part of their data to test the trained model. But sometimes, the test data leaks into the training process, which can lead to machine learning models that don’t generalize to data gathered from the real world.

“Don’t allow test data to leak into the training process,” he warns. “The best thing you can do to prevent these issues is to partition off a subset of your data right at the start of your project, and only use this independent test set once to measure the generality of a single model at the end of the project.”

In more complicated scenarios, you’ll need a “validation set,” a second test set that puts the machine learning model into a final evaluation process. For example, if you’re doing cross-validation or ensemble learning , the original test might not provide a precise evaluation of your models. In this case, a validation set can be useful.

“If you have enough data, it’s better to keep some aside and only use it once to provide an unbiased estimate of the final selected model instance,” Lones writes.

Know your models (as well as those of others)

Today, deep learning is all the rage. But not every problem needs deep learning. In fact, not every problem even needs machine learning. Sometimes, simple pattern-matching and rules will perform on par with the most complex machine learning models at a fraction of the data and computation costs.

But when it comes to problems that are specific to machine learning models, you should always have a roster of candidate algorithms to evaluate. “Generally speaking, there’s no such thing as a single best ML model,” Lones writes. “In fact, there’s a proof of this, in the form of the No Free Lunch theorem, which shows that no ML approach is any better than any other when considered over every possible problem.”

The first thing you should check is whether your model matches your problem type. For example, based on whether your intended output is categorical or continuous, you’ll need to choose the right machine learning algorithm along with the right structure. Data types (e.g., tabular data, images, unstructured text, etc.) can also be a defining factor in the class of model you use.

One important point Lones makes in his paper is the need to avoid excessive complexity. For example, if you’re problem can be solved with a simple decision tree or regression model, there’s no point in using deep learning.

Lones also warns against trying to reinvent the wheel. With machine learning being one of the hottest areas of research, there’s always a solid chance that someone else has solved a problem that is similar to yours. In such cases, the wise thing to do would be to examine their work. This can save you a lot of time because other researchers have already faced and solved challenges that you will likely meet down the road.

“To ignore previous studies is to potentially miss out on valuable information,” Lones writes.

Examining papers and work by other researchers might also provide you with machine learning models that you can use and repurpose for your own problem. In fact, machine learning researchers often use each other’s models to save time and computational resources and start with a baseline trusted by the ML community.

“It’s important to avoid ‘not invented here syndrome’, i only using models that have been invented at your own institution, since this may cause you to omit the best model for a particular problem,” Lones warns.

Know the final goal and its requirements

Having a solid idea of what your machine learning model will be used for can greatly impact its development. If you’re doing machine learning purely for academic purposes and to push the boundaries of science, then there might be no limits to the type of data or machine learning algorithms you can use. But not all academic work will remain confined in research labs.

“[For] many academic studies, the eventual goal is to produce an ML model that can be deployed in a real world situation. If this is the case, then it’s worth thinking early on about how it is going to be deployed,” Lones writes.

For example, if your model will be used in an application that runs on user devices and not on large server clusters, then you can’t use large neural networks that require large amounts of memory and storage space. You must design machine learning models that can work in resource-constrained environments .

Another problem you might face is the need for explainability . In some domains, such as finance and healthcare, application developers are legally required to provide explanations of algorithmic decisions in case a user demands it. In such cases, using a black-box model might be impossible. For example, even though a deep neural network might give you a performance advantage, its lack of interpretability might make it useless. Instead, a more transparent model such as a decision tree might be a better choice even if it results in a performance hit. Alternatively, if deep learning is an absolute requirement for your application, then you’ll need to investigate techniques that can provide reliable interpretations of activations in the neural network.

As a machine learning engineer, you might not have precise knowledge of the requirements of your model. Therefore, it is important to talk to domain experts because they can help to steer you in the right direction and determine whether you’re solving a relevant problem or not.

“Failing to consider the opinion of domain experts can lead to projects which don’t solve useful problems, or which solve useful problems in inappropriate ways,” Lones writes.

For example, if you create a neural network that flags fraudulent banking transactions with very high accuracy but provides no explanation of its decision, then financial institutions won’t be able to use it.

Know what to measure and report

There are various ways to measure the performance of machine learning models, but not all of them are relevant to the problem you’re solving.

For example, many ML engineers use the “accuracy test” to rate their models. The accuracy test measures the percent of correct predictions the model makes. This number can be misleading in some cases.

For example, consider a dataset of x-ray scans used to train a machine learning model for cancer detection. Your data is imbalanced, with 90 percent of the training examples flagged as benign and a very small number classified as malign. If your trained model scores 90 on the accuracy test, it might have just learned to label everything as benign. If used in a real-world application, this model can lead to missed cases with disastrous outcomes. In such a case, the ML team must use tests that are insensitive to class imbalance or use a confusion matrix to check other metrics. More recent techniques can provide a detailed measure of a model’s performance in various areas.

Based on the application, the ML developers might also want to measure several metrics. To return to the cancer detection example, in such a model, it might be important to reduce false negatives as much as possible even if it comes at the cost of lower accuracy or a slight increase in false positives. It is better to send a few people healthy people for diagnosis to the hospital than to miss critical cancer patients.

In his paper, Lones warns that when comparing several machine learning models for a problem, don’t assume that bigger numbers do not necessarily mean better models. For example, performance differences might be due to your model being trained and tested on different partitions of your dataset or on entirely different datasets.

“To really be sure of a fair comparison between two approaches, you should freshly implement all the models you’re comparing, optimise each one to the same degree, carry out multiple evaluations… and then use statistical tests… to determine whether the differences in performance are significant,” Lones writes.

Lones also warns not to overestimate the capabilities of your models in your reports. “A common mistake is to make general statements that are not supported by the data used to train and evaluate models,” he writes.

Therefore, any report of your model’s performance must also include the kind of data it was trained and tested on. Validating your model on multiple datasets can provide a more realistic picture of its capabilities, but you should still be wary of the kind of data errors we discussed earlier.

Transparency can also contribute greatly to other ML research. If you fully describe the architecture of your models as well as the training and validation process, other researchers that read your findings can use them in future work or even help point out potential flaws in your methodology.

Finally, aim for reproducibility. if you publish your source code and model implementations, you can provide the machine learning community with great tools in future work.

Applied machine learning

Interestingly, almost everything Lones wrote in his paper is also applicable to applied machine learning, the branch of ML that is concerned with integrating models into real products. However, I would like to add a few points that go beyond academic research and are important in real-world applications.

When it comes to data, machine learning engineers must consider an extra set of considerations before integrating them into products. Some include data privacy and security, user consent, and regulatory constraints. Many a company has fallen into trouble for mining user data without their consent.

Another important matter that ML engineers often forget in applied settings is model decay. Unlike academic research, machine learning models used in real-world applications must be retrained and updated regularly. As everyday data changes, machine learning models “decay” and their performance deteriorates. For example, as life habits changed in wake of the covid lockdown, ML systems that had been trained on old data started to fail and needed retraining. Likewise, language models need to be constantly updated as new trends appear and our speaking and writing habits change. These changes require the ML product team to devise a strategy for continued collection of fresh data and periodical retraining of their models.

Finally, integration challenges will be an important part of every applied machine learning project. How will your machine learning system interact with other applications currently running in your organization? Is your data infrastructure ready to be plugged into the machine learning pipeline? Does your cloud or server infrastructure support the deployment and scaling of your model? These kinds of questions can make or break the deployment of an ML product.

For example, recently, AI research lab OpenAIlaunched a test version of their Codex API model for public appraisal. But their launch failed because their servers couldn’t scale to the user demand.

Hopefully, this brief post will help you better assess your machine learning project and avoid mistakes. Read Lones’s full paper, titled, “How to avoid machine learning pitfalls: a guide for academic researchers,” for more details about common mistakes in the ML research and development process.

This article was originally published by Ben Dickson on TechTalks , a publication that examines trends in technology, how they affect the way we live and do business, and the problems they solve. But we also discuss the evil side of technology, the darker implications of new tech, and what we need to look out for. You can read the original article here .

Researchers SOMEHOW peered into a black-box AI made for identifying molecules on exoplanets

Do you know what the Earth’s atmosphere is made of? You’d probably remember it’s oxygen, and maybe nitrogen. And with a little help from Google you can easily reach a more precise answer: 78% nitrogen, 21% oxygen and 1% argon gas. However, when it comes to the composition of exo-atmospheres – the atmospheres of planets outside our solar system – the answer is not known. This is a shame, as atmospheres can indicate the nature of planets, and whether they can host life.

As exoplanets are so far away, it has proven extremely difficult to probe their atmospheres. Research suggests that artificial intelligence (AI) may be our best bet to explore them – but only if we can show that these algorithms think in reliable, scientific ways, rather than cheating the system. Now our new paper, published in the Astrophysical Journal , has provided reassuring insight into their mysterious logic.

Astronomers typically exploit the transit method to investigate exoplanets, which involves measuring dips in light from a star as a planet passes in front of it. If an atmosphere is present on the planet, it can absorb a very tiny bit of light, too. By observing this event at different wavelengths – colors of light – the fingerprints of molecules can be seen in the absorbed starlight, forming recognizable patterns in what we call a spectrum.

A typical signal produced by the atmosphere of a Jupiter-sized planet only reduces the stellar light by ~0.01% if the star is Sun-like. Earth-sized planets produce 10-100 times lower signals. It’s a bit like spotting the eye color of a cat from an aircraft.

In the future, the James Webb Space Telescope ( JWST ) and the Ariel Space Mission, both probes that will investigate exoplanets from their orbit in space, will help by providing high-quality spectra for thousands of exo-atmospheres. But while scientists are excited about this, the latest research suggests it may be tricky. Due to the complex nature of atmospheres, the analysis of a single transiting planet may take days or even weeks to complete.

Naturally, researchers have started to look for alternative tools. AI are renowned for their ability to assimilate and learn from a large amount of data and their superb performance on different tasks once trained. Scientists have therefore attempted to train AI to predict the abundance of various chemical species in atmospheres.

Current research has established that AIs are well-suited for this task . However, scientists are meticulous and sceptical, and to prove this is really the case, they want to understand how AIs think.

Peeking inside the black box

In science, a theory or a tool cannot be adopted if it is not understood. After all, you don’t want to go through the excitement of discovering life on an exoplanet, just to realize it is simply a “glitch” in the AI. The bad news is that AIs are terrible at explaining their own findings. Even AI experts have a hard time identifying what causes the network to provide a given explanation. This disadvantage has often prevented the adoption of AI techniques in astronomy and other scientific fields.

We developed a method that allows us a glimpse into the decision-making process of AI. The approach is quite intuitive. Suppose an AI has to confirm whether an image contains a cat. It would presumably do this by spotting certain characteristics, such as fur or face shape. To understand which characteristics it is referencing, and in what order, we could blur parts of the cat’s image and see if it still spots that it is a cat.

This is exactly what we did for an exoplanet-probing AI by “perturbing”, or changing, regions of the spectrum. By observing how the AI’s predictions on the abundances of exoplanet molecules changed (say water in the atmosphere) when each region was doctored, we started to build a “picture” of how the AI thought, such as which regions of the spectrum it used for deciding the level of water in the atmosphere.

Reassuringly for us astronomers, we found that a well-trained AI relies heavily on physical phenomena, such as unique spectroscopic fingerprints – just like an astronomer would. This may come as no surprise, after all, where else can the AI learn it from?

In fact, when it comes to learning, AI is not so different from a cheeky high-school student – it will try its best to avoid the hard way (such as understanding difficult mathematical concepts) and find any shortcuts (such as memorizing the mathematical formulae without understanding why) in order to get the correct answer.

If the AI made predictions based on memorizing every single spectrum it had come across, that would deeply undesirable. We want the AI to derive its answer from the data, and perform well on unknown data, not just the training data for which there is a correct answer.

This finding provided the first method to have a sneaky peek into so-called “AI black-boxes”, allowing us to evaluate what the AIs have learnt. With these tools, researchers now can not only use AIs to speed up their analysis of exo-atmospheres, but they can also verify that their AI uses well-understood laws of nature.

That said, it’s too early to claim that we fully understand AIs. The next step is to work out precisely how important each concept is, and how it gets processed into decisions.

The prospect is exciting for AI experts, but even more so for us scientists. AI’s incredible learning power originates from its ability to learn a “representation”, or pattern, from the data – a technique similar to how physicists have discovered laws of nature in order to better understand our world. Having access to the minds of AI may therefore grant us the opportunity to learn new, undiscovered laws of physics.

This article by Kai Hou (Gordon) Yip , Postdoctoral Research Fellow at ExoAI, UCL and Quentin Changeat , Postdoctoral Research Fellow in Astronomy, UCL , is republished from The Conversation under a Creative Commons license. Read the original article .

Microsoft’s creepy teenage chatbot Xiaoice is getting its own company

Microsoft is turning its Xiaoice chatbot into an independent company, the software giant announced today .

Xiaoice — pronounced “Shao-ice” and translated as “little Bing” — is rather creepily programmed to act like an 18-year-old girl. The chatbot was initially released in China, but is now also available in Indonesia and Japan. According to Microsoft , the service has attracted more than 660 million online users since its 2014 launch.

Xiaoice is designed to provide a more emotional experience than voice assistants such as Apple’s Siri and Microsoft‘s Cortana. While its rivals are programmed to perform specific tasks, Xiaoice is more of a digital companion. As Microsoft puts it :

This can create some pretty unnerving connections with its users. In 2015, Microsoft claimed that 25% of users — around 10 million people — have said “I love you” to the bot. More positively, a Chinese user recently said that Xiaoice had saved his life when he was contemplating suicide.

By spinning the chatbot off into a separate entity, Microsoft aims to  “accelerate the Xiaoice product line’s localized innovation, and to improve Xiaoice’s commercial ecosystem.”

Unfortunately, these developments could also deepen gender stereotypes. A study by UNESCO found that giving digital assistants female voices reinforces gender biases, and recommended that tech firms stopped making the systems female by default. Microsoft apparently hasn’t heeded the warning, but concerned consumers should give the bot a wide berth. As if the idea of a relationship with a virtual teenage girl wasn’t reason enough to avoid it.