There&#x27;s actually a case in the early history of perceptrons that brings up this exact issue:<p>&quot;There is a humorous story from the early days of machine learning about a network that was supposed to be trained to recognize tanks hidden in forest regions. The network was trained on a large set of photographs – some with tanks and some without tanks. After learning was complete the system appeared to work well when “shown” additional photographs from the original set. As a final test, a new group of photos were taken to see if the network could recognize tanks in a slightly different setting. The results were extremely disappointing. No one was sure why the network failed on this new group of photos. Eventually, someone noticed that in the original set of photos the network had been trained on, all of the photos with tanks had been taken on a cloudy day, while all of the photos without tanks were taken on a sunny day. The network had not learned to detect the difference between scenes with tanks and without tanks, it had instead learned to distinguish photos taken on cloudy days from photos taken on sunny days!&quot;[0]<p>The pragmatic answer is that this is why you have two hold-out sets: cross validation&#x2F;dev set and the test set. Typically you keep 70% of the data for training, 15% of the data for CV and 15% for Test. Ideally you should shuffle the data enough that there isn&#x27;t any bias in the natural order of the data.<p>You train the model on the train data, and estimate how well the model actually performs on the CV set which the model did not see in training. You continue to use the CV set while you tweak parameters, try out new models etc. At this point you may have &quot;cheated&quot; a bit because you only kept things that worked well on your CV data. Finally when you say &quot;this is done!&quot; you try out your model on the Test data set.<p>Of course it&#x27;s still possible that you would have the even&#x2F;odd issue, and the answer to this whole set of issues is &quot;healthy skepticism&quot;, and checking for these types of errors.<p>Take for example this Sentence Completion Challenge from Microsoft Research [1]<p>They claim some astounding results on correctly predicting GRE type questions using a very simple model (LSA for those who care). These results seemed impossible! But it turns out they cheated by training the model <i>only</i> on possible answers (which is akin to studying for the actually GRE by only review the possible answers that will be on the exam).<p>We tend to obsess over p-values and test validation scores as a substitute for reasoning. But all research papers should be read as an argument a friend is making to you, &quot;I&#x27;ve done this incredible thing... &quot;, and no single number should replace reasoned inquisition into possible errors.<p>[0] <a href="http:&#x2F;&#x2F;watson.latech.edu&#x2F;WatsonRebootTest&#x2F;ch14s2p4.html" rel="nofollow">http:&#x2F;&#x2F;watson.latech.edu&#x2F;WatsonRebootTest&#x2F;ch14s2p4.html</a><p>[1] <a href="http:&#x2F;&#x2F;research.microsoft.com&#x2F;apps&#x2F;pubs&#x2F;?id=157031" rel="nofollow">http:&#x2F;&#x2F;research.microsoft.com&#x2F;apps&#x2F;pubs&#x2F;?id=157031</a>