Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix model query count when no candidate result scores are improvements over current result score #350

Merged
merged 3 commits into from
Nov 22, 2020

Conversation

a1noack
Copy link
Contributor

@a1noack a1noack commented Nov 19, 2020

It seems that when none of the items in results have a higher score than the cur_result.score, the num_queries attribute of cur_result exits the while loop in the _perform_search method with an incorrect value of model queries. I think this fixes the problem.

@a1noack
Copy link
Contributor Author

a1noack commented Nov 19, 2020

Actually, I think this is still partially incorrect.

@a1noack a1noack marked this pull request as draft November 20, 2020 00:19
@jinyongyoo
Copy link
Collaborator

@a1noack I don't think that should matter, since we actually keep track of the number of queries in GoalFunction class.

@a1noack
Copy link
Contributor Author

a1noack commented Nov 20, 2020

@jinyongyoo But I think cur_result and each element in results are GoalFunctionResult objects, and each of these has its own query count.

@a1noack
Copy link
Contributor Author

a1noack commented Nov 20, 2020

Okay, after a bit more testing, I'm thinking that I was right the first time. I think the commit I made actually is correct.

@a1noack a1noack marked this pull request as ready for review November 20, 2020 06:19
Copy link
Collaborator

@uvafan uvafan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is correct; good find.

I think it should only matter in cases where the attack ends with an index that it doesn't swap out which is probably relatively rare except maybe with maximizing goal functions.

I think it would be nice to add a comment with a short explanation of why this is necessary; I also think there might be similar issues in most/all of the other SearchMethods when the search ends by failing to find any replacements.

@jinyongyoo
Copy link
Collaborator

@a1noack I also can see why this might be an issue. This isn't an issue for keeping track of the queries we used so far, but it still is an issue for the number queries we report for each goal function result at the end. Thanks for catching it.

I think all search methods have this issue and I think there's an easier way to fix this.
@uvafan Can we just set num_queries of goal function result returned by perform_search to be equal to num_queries of GoalFunction?

@uvafan
Copy link
Collaborator

uvafan commented Nov 20, 2020

@a1noack I also can see why this might be an issue. This isn't an issue for keeping track of the queries we used so far, but it still is an issue for the number queries we report for each goal function result at the end. Thanks for catching it.

I think all search methods have this issue and I think there's an easier way to fix this.
@uvafan Can we just set num_queries of goal function result returned by perform_search to be equal to num_queries of GoalFunction?

Yeah I think this is a better solution. Good idea

@qiyanjun
Copy link
Member

@jinyongyoo ready to merge?

@jinyongyoo
Copy link
Collaborator

jinyongyoo commented Nov 21, 2020

@qiyanjun We can merge it, but it'll just fix one search method. What I proposed fixes it for every search method.

@a1noack Hey Adam, do you think it's possible for you to fix it this way?

@a1noack I also can see why this might be an issue. This isn't an issue for keeping track of the queries we used so far, but it still is an issue for the number queries we report for each goal function result at the end. Thanks for catching it.

I think all search methods have this issue and I think there's an easier way to fix this.
@uvafan Can we just set num_queries of goal function result returned by perform_search to be equal to num_queries of GoalFunction?

@a1noack
Copy link
Contributor Author

a1noack commented Nov 21, 2020

Here's a more general fix. It's not beautiful, but I think it should be fine as long as we continue to treat SearchMethod's _perform_search function as private and it is only called through the __call__ method.

@a1noack
Copy link
Contributor Author

a1noack commented Nov 21, 2020

Okay, so the run_attack_faster_alzantot_recipe-textattack attack --model lstm-mr --recipe faster-alzantot --num-examples 3 --num-examples-offset 32 --shuffle=False test is failing because the expected query count does not equal the actual number of queries.

Part of the expected output for this test is:

+-------------------------------+--------+
| Attack Results                |        |
+-------------------------------+--------+
| Number of successful attacks: | 2      |
| Number of failed attacks:     | 1      |
| Number of skipped attacks:    | 0      |
| Original accuracy:            | 100.0% |
| Accuracy under attack:        | 33.33% |
| Attack success rate:          | 66.67% |
| Average perturbed word %:     | 17.34% |
| Average num. words per input: | 15.0   |
| Avg num queries:              | 551.67 |
+-------------------------------+--------+

But that part in the new output when I run this test is:

+-------------------------------+---------+
| Attack Results                |         |
+-------------------------------+---------+
| Number of successful attacks: | 2       |
| Number of failed attacks:     | 1       |
| Number of skipped attacks:    | 0       |
| Original accuracy:            | 100.0%  |
| Accuracy under attack:        | 33.33%  |
| Attack success rate:          | 66.67%  |
| Average perturbed word %:     | 17.34%  |
| Average num. words per input: | 15.0    |
| Avg num queries:              | 1132.67 |
+-------------------------------+---------+

So the new query count is much higher. Which makes sense given the changes I made.

Not sure what you want to do about this. A bunch of the tests might be wrong.

@jinyongyoo
Copy link
Collaborator

jinyongyoo commented Nov 22, 2020

@a1noack Looks good to me! Thank you for catching this mistake and fixing it. I checked out what was happening with the genetic algorithm, and it turns out whenever we perturb a population member/text, we call get_goal_results on that one text at a time. Therefore, the num_queries stored in goal function result of each population member is out-dated whenever we perturb the next population member/text. When I updated num_queries of individual population member after the whole perturbing step, I obtained the same total number queries as the one reported by GoalFunctionResult.

This reflects that fact that num_queries is really only accurately recorded in the goal function, and not the individual results. Since we intended _perform_search to be private, I think the way you fixed it should be fine.

@jinyongyoo jinyongyoo merged commit 278bb33 into QData:master Nov 22, 2020
@a1noack a1noack deleted the fix_query_count branch November 23, 2020 23:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants