Problems with SKLearn Pipelines

[madarax64]

Hello,
I'm trying to implement black-box attacks against a classifier, which has the usual Sklearn interface i.e fit() and predict() methods. Therefore I made an SKLearn pipeline which converts my input (1D sequence) into a feature vector, then classifies the feature vector using a Logistic Regression classifier. I began with the example in this notebook but it didn't work. I eventually arrived at the BlackBoxClassifier, which allows me supply a simple prediction function. However, even after ensuring that the function produces the output in the specified format (i.e as 1-hot encoded prediction vectors stacked into a matrix) it still doesnt work. I get the following error:

<stack trace>
predictions[begin:end] = self.predict_fn(x_preprocessed[begin:end])
ValueError: setting an array element with a sequence.

I also tried wrapping the pipeline in an SklearnClassifier object as follows:
wrapper = SklearnClassifier(model = pipeline)
But attempting to generate the attack gives me a completely different error:
<stack trace>
self.theta = 0.01 / np.prod(self.estimator.input_shape)
TypeError: unsupported operand type(s) for /: 'float' and 'NoneType'
Could you please tell me how to resolve these issues?

Thanks!

[beat-buesser]

Hi @madarax64 The linked notebook did not work because there is no estimator yet that provides gradient calculations for pipelines. The BlackBoxClassifier is the best choice at the moment. What is the return value (shape, type, etc.) of your predict function?

[madarax64]

Hi @beat-buesser ,
No worries! Haha, I'm really hoping its not. I will definitely do these modifications as well. The attacks take up to 20 minutes (for a dataset of 105 samples), and so increasing these values will certainly make this time jump - I've seen it at a few hours (5-8) before (for larger values). Is that normal or am I doing something wrong? Regardless, I will run the experiments as described and report back probably in a few days when they're done.

So typically, I keep the batch size at the number of the samples (i.e 105 in the case of the dataset I mentioned above) - I thought this was somehow more specific to deep models and their batch sizes. What I can do is to also try different batch sizes as well as different max_eval and init_eval values and see how that varies. Does that work?

Thanks again for the help!

[beat-buesser]

Hi @madarax64 Yes, I would definitely test different values for batch_size because it affects how efficient your GPU/CPU is utilized. This implementation of HopSkipJump attacks one sample at a time, therefore the batch size is independent of the number of samples in x. Instead batch_size defines how many of the random samples defined by init_eval and max_eval are evaluated in parallel on your GPU/CPU for each sample.

[madarax64]

Hello Hello @beat-buesser ,
As discussed, I've been running the experiments for the past 3 weeks. Sadly, the results do not indicate any consistent effect for the batch size and other parameters. On the plus side, I also did a parallel set of experiments using the ZOO method and found that it works much more nicely for my purposes, so I will switch to that. Thank you for all the help with HopSkipJump so far. I really appreciate it.

When I first ran the ZOO attack it, it tells me that batch sizes greater than 1 are currently unsupported for feature vectors, so I leave the batch size at 1. Since nb_parallel is set to 128 by default, I leave that as is as well (I'm running on a Xeon workstation with 64 cores). Still, to attack just 20 samples, it takes about 2 hours. Each iteration takes roughly 253.90s (according to the tqdm estimate) on that dataset. I attacked a different dataset of 105 samples and it took above 7 hours. I wanted to ask if this is normal/expected and if there is some way to speed things up?
Thanks!

[beat-buesser]

Hi @madarax64 That's great and you have found interesting insights! You're right, ZOO supports mini-batches larger than 1 sample for data with more than 1 dimension. There is a check in line 120 for 1D feature vectors from tabular data that raises the exception you are observing:

adversarial-robustness-toolbox/art/attacks/evasion/zoo.py

Line 120 in 8608f9f

if len(classifier.input_shape) == 1:

I think there is no reason why larger batches with 1D features shouldn't be possible, it would probably just require removing the check and debugging the later lines of code that could fail if the features are 1D.

[beat-buesser]

How busy are your CPU/GPUs when running ZOO?