Recently, I saw a post by Rajiv Shah, Chicago-based data-scientist, regarding an article published in Nature last year called Deep learning of aftershock patterns following large earthquakes, written by scientists at Harvard in collaboration with Google. Below is the article:

Stand Up for Best Practices: Misuse of Deep Learning in Nature’s Earthquake Aftershock Paper

The Dangers of Machine Learning Hype

Practitioners of AI, machine learning, predictive modeling, and data science have grown enormously over the last few years. What was once a niche field defined by its blend of knowledge is becoming a rapidly growing profession. As the excitement around AI continues to grow, the new wave of ML augmentation, automation, and GUI tools will lead to even more growth in the number of people trying to build predictive models.

But here’s the rub: While it becomes easier to use the tools of predictive modeling, predictive modeling knowledge is not yet a widespread commodity. Errors can be counterintuitive and subtle, and they can easily lead you to the wrong conclusions if you’re not careful.

I’m a data scientist who works with dozens of expert data science teams for a living. In my day job, I see these teams striving to build high-quality models. The best teams work together to review their models to detect problems. There are many hard-to-detect-ways that lead to problematic models (say, by allowing target leakage into their training data).

Identifying issues is not fun. This requires admitting that exciting results are “too good to be true” or that their methods were not the right approach. In other words, it’s less about the sexy data science hype that gets headlines and more about a rigorous scientific discipline.

Bad Methods Create Bad Results

Almost a year ago, I read an article in Nature that claimed unprecedented accuracy in predicting earthquake aftershocks by using deep learning. Reading the article, my internal radar became deeply suspicious of their results. Their methods simply didn’t carry many of the hallmarks of careful predicting modeling.

I started to dig deeper. In the meantime, this article blew up and became widely recognized! It was even included in the release notes for Tensorflow as an example of what deep learning could do. However, in my digging, I found major flaws in the paper. Namely, data leakage which leads to unrealistic accuracy scores and a lack of attention to model selection (you don’t build a 6 layer neural network when a simpler model provides the same level of accuracy).

To my earlier point: these are subtle, but incredibly basic predictive modeling errors that can invalidate the entire results of an experiment. Data scientists are trained to recognize and avoid these issues in their work. I assumed that this was simply overlooked by the author, so I contacted her and let her know so that she could improve her analysis. Although we had previously communicated, she did not respond to my email over concerns with the paper.

Falling On Deaf Ears

So, what was I to do? My coworkers told me to just tweet it and let it go, but I wanted to stand up for good modeling practices. I thought reason and best practices would prevail, so I started a 6-month process of writing up my results and shared them with Nature. Upon sharing my results, I received a note from Nature in January 2019 that despite serious concerns about data leakage and model selection that invalidate their experiment, they saw no need to correct the errors, because “Devries et al. are concerned primarily with using machine learning as [a] tool to extract insight into the natural world, and not with details of the algorithm design.” The authors provided a much harsher response.

You can read the entire exchange on my github.

It’s not enough to say that I was disappointed. This was a major paper (it’s Nature!) that bought into AI hype and published a paper despite it using flawed methods.

Then, just this week, I ran across articles by Arnaud Mignan and Marco Broccardo on shortcomings that they found in the aftershocks article. Here are two more data scientists with expertise in earthquake analysis who also noticed flaws in the paper. I also have placed my analysis and reproducible code on github.

Standing Up For Predictive Modeling Methods

I want to make it clear: my goal is not to villainize the authors of the aftershocks paper. I don’t believe that they were malicious, and I think that they would argue their goal was to just show how machine learning could be applied to aftershocks. Devries is an accomplished earthquake scientist who wanted to use the latest methods for her field of study and found exciting results from it.

But here’s the problem: their insights and results were based on fundamentally flawed methods. It’s not enough to say, “This isn’t a machine learning paper, it’s an earthquake paper.” If you use predictive modeling, then the quality of your results are determined by the quality of your modeling. Your work becomes data science work, and you are on the hook for your scientific rigor.

There is a huge appetite for papers that use the latest technologies and approaches. It becomes very difficult to push back on these papers.

But if we allow papers or projects with fundamental issues to advance, it hurts all of us. It undermines the field of predictive modeling.

Please push back on bad data science. Report bad findings to papers. And if they don’t take action, go to twitter, post about it, share your results and make noise. This type of collective action worked to raise awareness of p-values and combat the epidemic of p-hacking. We need good machine learning practices if we want our field to continue to grow and maintain credibility.

Link to Rajiv’s Article

Original Nature Publication (note: paywalled)

GitHub repo contains an attempt to reproduce Nature’s paper

Confrontational correspondence with authors

Here’s what my data look like:

• There is a collection of a few thousand objects
• Each object is sampled on a grid, with multiple properties observed per point
• There are two types of objects

And the goal is to identify which of the two types of objects we have given the grid of samples.

So this looks like a straightforward CNN project. I’m not an expert, but I have experience fitting those on RGB images using TF/keras and doing some model tuning and validation. Should be easy, right?

The problem is that these grids are all irregular. I know how to fit CNNs when I have a collection of rectangular images all of the same size (if they’re different dimensions, then it’s straightforward to resize/interpolate/resample them). But how do you handle grids taken from what I can best describe as “blobs”? To make things even harder, the sampling instrument occasionally malfunctioned, so I have occasional NAs for the measurements. As far as my domain knowledge goes, the shape of the grid or the frequency of the instrument failing to make a valid measurement shouldn’t depend on the classification (or vice versa).

My thinking is perhaps there’s a way to reshape everything into rectangles of the same size, but I can’t think of how. Or is there another totally different type of model that would work best for these data?

Is knowing the parameters that control overfitting critical when trying to understand or use machine learning models?

​

If yes, what are some quick ways to find out the parameters that control overfitting without diving in deep?

I’m a Software Engineer specializing in Data Infrastructure/Engineering and DevOps.

I’ve been speaking with a few colleagues who work with ML and have expressed their frustration with the lack of a consistent “developer flow” for ML projects, so I wanted to ask this community, what does YOUR ideal developer flow look like?

I apologize in advance for my lack of knowledge on this subject, and if I’ve used any of the terms incorrectly. I’m very new and just trying to learn more about the underlying infrastructure.

​

Here’s what we sketched out to be a reasonable developer flow:

Assumptions:

1. Data is already available, all connections are correctly configured. You can explore it using notebooks or a sql tool like apache superset.
2. You have access to an ETL tool (eg: apache airflow) where you’ve built dags to aggregate data and preprocess source data to be in the input format for your ML model.
3. You have access to development machines (“devboxes”) which are configured exactly like production machines where the task/job will run – except that devboxes can only read production data but NOT write production data (can still write to dev/staging databases). These are your test environment.

Workflow:

1. You start a (hosted) notebook (Jupyter or Zeppelin) which has access to the data. You also have access to the pre-processed datasets mentioned in Assumptions[2] and you build out your models (I don’t really know what happens here – i’m sorry)
2. You can also write python/scala code instead of using the notebook and test it by running it on the devbox.
3. You’ve built and (minimally tested) your model and want to train, deploy and productionize it. What happens after this?

Could someone help me understand what happens after this step?

I’m guessing you’ll need to train the model, can that be done in the notebook or the python file which you can run on your devbox. Training the model in the notebook seems untrackable, so you’ll probably want to train it in python/scala code which will be checked into github.

You’ll probably need to re-train it periodically so the python/scala function can be deployed in an Airflow DAG which trains it daily/weekly.

What would be the common processes of deploying it after this step?

​

For example, for regular software projects it would be:

Code -> Test Locally -> Push to github (not merged yet) -> CI/CD builds the new code and pushes to staging -> test staging -> everything looks good/no regression in other services -> push to production by merging PR

​

For Data Engineering projects, the workflow is all over the place but my ideal workflow is:

Code (create a new DAG/update queries) -> Test on devbox with sample data (local testing is not possible with large datasets) -> Push to github (not merged yet) -> CI/CD builds the new code/DAG -> new DAG runs in staging with staging data, generates staging tables to test -> everything looks good/data quality checks pass -> push to production by merging PR -> production jobs pick up the new queries/DAGs.

​

DISCLAIMER: I know very little about this space, I’m happy to read any documentation you provide on this.

Thank you in advance!

Hi guys! I’ve started a project using Facebook’s Mask R-CNN. The goal is to have it recognize certain small objects from large (HD+) images.

I’m a bit worried how long it will take to train with original image size. Does it make much difference if I crop the objects out of the image and train them separately? It still should be able to work with large images though.

I am using pre-trained COCO weights and the tool I use for labeling is VGG Image Annotator. Thanks in advance!

A Google whistleblower explained that much of the demonetization/censorship action occurring on YouTube is done through Google’s speech-to-text. If so, it seems that altering a video’s audio to become an adversarial example, prior to it being uploaded, could serve to slow what’s happening.

​

Is it possible to reliably generate adversarial examples for an ai which you do not have direct access to (Google’s Cloud Speech-To-Text is behind a pay wall)? I’ve heard Lex Fridman mention that adversarial examples are often effective against multiple networks, even when their structures differ.

“We are pleased to announce that Geoffrey Hinton and Yann LeCun will deliver the Turing Lecture at FCRC. Hinton’s talk, entitled, “The Deep Learning Revolution” and LeCun’s talk, entitled, “The Deep Learning Revolution: The Sequel,” will be presented June 23rd from 5:15-6:30pm in Symphony Hall.”

​

https://www.youtube.com/watch?v=VsnQf7exv5I

I’d like to spread the word about r/compmathneuro‘s first Journal Club, which will take place on June 27 at 9:30 (UTC+1).

​

User u/Stereoisomer will present the paper “Towards the neural population doctrine” authored by Shreya Saxena and John P. Cunningham (available through this link). The presentation will be shared through either PowerPoint or KeyNote online, while users are encouraged to join us for a live voice discussion on discord. Those not able to participate in voice chat are encouraged to join us through the discord channel #paper-sharing. Following the presentation, we’ll host a short Q&A.

​

The journal club should last about an hour in total and will be moderated by mod u/mkeee2015. If you’re interested, please join our discord server through this invite.

​

Please note that this is the first time we attempt to organize a Journal Club, and should thus be regarded as experimental.

​

We hope to see you there!

Keypoint detection has successfully been modelled with CNNs that outputs a heatmap tensor of size H x W x K, where K is the number of instance keypoints you want to detect and H and W the output size of the heatmaps. If you want precise detections H and W should ideally be the same size as the input image.

​

I want to detect K>=300 using an input image of size 512 x 512. Due to obvious memory limitations I can’t use the above naive approach that upscales to the original input size.

​

Is anyone aware of some research that addresses this specific issue?