Why causing your model to fail is the most effective thing you possibly can do

When developing a recent model or algorithm, it’s tempting to check it over and once more with similar examples that each one work perfectly. While this may occasionally be fun, it doesn’t really enable you in understanding and improving your model. You learn from errors, so cause your model to fail!

Imagine your data science teammate involves you and tells you in regards to the recent model they simply trained. It’s so awesome, it might classify all types of baby animal images. In fact, your teammate will start showing you the way well it really works by letting the model classify a bunch of images all appropriately. At this moment the most effective thing to ask your teammate for is the next:

Show me some cases where it fails

At first, this might sound counterintuitive. In fact, it’s fun to see the model work and also you don’t wish to demotivate your teammate by causing the model to fail, but what gives you more insight into how the model behaves: Seeing the model work or seeing it fail?

If it classified N images of super cute kittens appropriately, it’s going to, most probably, also classify the N+1th image appropriately, if it looks similar to the others. Are you surprised? No. Did you learn anything in regards to the model’s behavior? No.

Nonetheless, in the event you find those images that cause the model to fail, you may eventually get an idea of the photographs the model still has problems with. That’s value rather a lot! Now you possibly can start to know the model and improve it much more.

The theoretical background on the seek for failures has a protracted tradition. For lots of of years, very smart people were considering and debating in regards to the query of how we will derive common rules from observations. The sun has risen within the morning today, and so did it yesterday and the day before. Does that mean that it’s going to rise again tomorrow? Well, not necessarily. One other example: I went to the park and all swans I saw there have been white, so I’d formulate my hypothesis

All swans are white.

As a great scientist, I’ll prove my hypothesis, after all, so I’m going to the subsequent park and take a look at the swans. They’re white too. So, is my hypothesis proven? No, because if I desired to prove it, I’d have to envision all swans. Well, I don’t have time for that, so what should I do? After having seen N white swans, taking a look at the N+1th white swan will give me no additional information. I should slightly:

Try to search out one black swan.

Why is that? Wouldn’t that falsify my hypothesis? Yes, that is strictly what it will do. And that’s what I should aim at.

Formally speaking, if I take a look at N white swans and derive that each one swans are white, I do a logical induction. The logical induction, nevertheless, has one drawback: It’s incorrect.

The above statement is an induction and we could read it as

My hypothesis H implies an commentary B, and I observed this commentary B. That suggests, that my hypothesis H is true.

The statement, in total, is incorrect though. In our example, the statement can be:

My hypothesis ‘all swans are white’ (H) implies, that the subsequent swan I observe is white (B). The subsequent swan I observe is white indeed (B). That suggests, that my hypothesis is true.

Again, that just isn’t true. While the commentary of a white swan is consistent with the hypothesis, it doesn’t imply its truth. It’s just not speaking against the hypothesis. When you usually are not convinced, take the next example:

My hypothesis ‘all swans are painted white by a secret organization of the US government’ implies, that the subsequent swan I observe is white (B). The subsequent swan I observe is white indeed (B). That suggests, that my hypothesis is true.

Simply not true.

Nonetheless, there remains to be hope. While the above statement was incorrect, the next is true:

We will read it as

My hypothesis H implies an commentary B, and I observed not B. This suggests that my hypothesis H just isn’t true.

or phrase your example as

My hypothesis ‘all swans are white’ (H) implies, that the subsequent swan I observe is white (B). The subsequent swan I observe just isn’t white (¬ B). That signifies that my hypothesis just isn’t true (¬ H).

That could be a true statement (and for the formal logic nerds amongst you, it is known as a modus tollens). If I find one example that speaks against the hypothesis, the hypothesis is proven to be incorrect, and that indeed is a recent piece of knowledge I didn’t have before.

All together which means, that hypotheses can never be proven or verified. They will just be falsified. However, if a hypothesis survives a lot of my attempts to falsify it, that speaks in favor of the hypothesis.

So, how is all that related to your teammate’s model? You don’t wish to prove or falsify a plain hypothesis here, however the foremost idea was, that the gain of knowledge comes from the cases that go incorrect. Simply speaking, cases where the model works, don’t inform you anything you didn’t know already. To know the model’s behavior, take a look at those cases where the model fails. For instance:

An entity recognizer that recognizes names can detect the names ‘Alice’ and ‘Paula’.

• Can it also detect ‘Kathrin’? Yes. Did you learn anything from that? No.
• Can it also detect ‘Linh’? No. → Possibly it has problems with Asian names.

A picture classifier can detect the situation where landscape images have been taken. It appropriately detects that the photos out of your last vacation were taken at a beach in Indonesia.

• Can it also detect the situation of the images you took the yr before in India? Yes. Did you learn anything from that? No.
• Does it also work for the images your granddad took on his first trip to Italy within the 50s? No. → Possibly the information misses old black-and-white photographs.

A cool recent robot hand is so flexible and may be controlled in a lot detail, that it might play a C-major scale on a piano.

• Can it also play an F-major scale? Yes. Did you learn anything from that? No.
• Can it also play a Mozart sonata? No. → Possibly its flexibility remains to be limited and a Mozart sonata is just too difficult for it.

All those examples show the way you gain knowledge from the cases that fail, not from people who work. In the identical way, you possibly can learn more about your teammate’s model that classifies cute animals:

• Can it also classify rare animals like baby octopuses or tree kangaroos?
• Does it also work with different image backgrounds?
• Can it classify baby fish, which look exactly like their parents, just smaller?
• What happens, if there are multiple different animals in a single picture?

Those are only a couple of examples that may enable you understand the model’s behavior. When breaking the model, be creative!

I just showed you why breaking your model is more helpful than seeing it work. The cases where it fails are those that carry useful information, similar to attempting to falsify a hypothesis is the important thing to strengthening it. Now it’s time to place formal logic into motion! Next time your teammate involves you to point out you their recent model, take a moment to understand it and have a good time the cases where it really works fantastic. But after that, start to interrupt it and find the sting cases. Those are those that may enable you improve the model much more. Hunt for the black swans!