The main problem that people have with this, is basically there is no way to verify that the design matches the actual implementation. At least there is no way you or I could do it. After the Snowden Revelations, trusting becomes difficult. That is why basically everyone who uses this instruction, mixes it with other data to make sure that even if this generator really was backdoored, the damage is limited
One problem with that approach is that depending on how little you trust the general area around RDRAND, it doesn't work.
Now, before I continue, I should mention that Intel explained that in their design the back-end of RDRAND is completely separate from other (micro)architectural state (like registers). [However, this restriction does not help if you were to assume that e.g. RDRAND microcode is evil].
Theorem of poisonous entropy: Given an attacker able to observe the state of your CSPRNG, they can embed information in the CSPRNG output with negligible computational cost iff they are able to supply entropy.
Therefore, if you don't trust RDRAND to not spy on you, but still use it as an entropy source, you cannot build a secure CSRPNG.
If you distrust Intel to even separate the CSPRNG from architectural registers, you should probably assume that they've compromised even pure-software CSPRNGs running on their chips as well.
A good pseudorandom generator will pass any such test with flying colours, in fact it's a basic requirement. Bu that is no guarantee that, given a certain length of output, an external attacker couldn't sync up and predict all future outputs.
And I don't believe there is a general way to distinguish such a device from an actual random source without looking inside. For example, they could use AES256 output in counter mode on a low entopy chip ID + high entropy backdoor key. Trivial to bruteforce given a few words of output, but you would essentially need to break AES to detect it.
"The moving average is the most common filter in DSP, mainly because it is the easiest digital
filter to understand and use. In spite of its simplicity, the moving average filter is optimal for
a common task: reducing random noise while retaining a sharp step response. This makes it the
premier filter for time domain encoded signals. However, the moving average is the worst filter
for frequency domain encoded signals, with little ability to separate one band of frequencies from
another."
It definitely depends on your domain, but moving average/median can be extremely effective. (Or terrible, if mis-applied).