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

Continual Editing #220

Closed
Wonder1905 opened this issue Apr 4, 2024 · 6 comments
Closed

Continual Editing #220

Wonder1905 opened this issue Apr 4, 2024 · 6 comments
Labels
question Further information is requested

Comments

@Wonder1905
Copy link

Hi, thanks again for this excellent framework and papers, In you paper youve talked about "Continual Editing", is there a piece of code that handles this experiments? if not do you have any idea how to implement it using the current code, with minimum amount of changes?
Please share your thoughts.

Thank again!

@zxlzr zxlzr added the question Further information is requested label Apr 4, 2024
@pengzju
Copy link
Collaborator

pengzju commented Apr 5, 2024

Thank you for your attention, if you would like to edit sequentially. You can set keep_original_weight to False so that the parameters will not be rolled back after each edit.

  • But even so, the evaluation is still based on a single edit before proceeding to the next step of editing.
  • If you want to evaluate after editing 500 times for example, you can move the code here outside the loop

@Wonder1905
Copy link
Author

Thanks for your quick reply, about this line:
"But even so, the evaluation is still based on a single edit before proceeding to the next step of editing"
How did you evaluate you continual editing on the paper? after each step or at the end? just so that we will be aligned

@pengzju
Copy link
Collaborator

pengzju commented Apr 8, 2024

In our paper, the sequential editing used is to edit one item and test the performance of the other. For example, after editing the second item, use the current checkpoint to test the performance of the second item, and the cycle repeats. "This aligns with our original paper." The pseudocode looks like this:

for i, request in tqdm(enumerate(requests)):
    edited_model, weights_copy = edit_func(model, tok, request, hparams)
    edit_evaluation(all_metrics, request, edited_model, hparams, tok, i)

    with torch.no_grad():
        for k, v in weights_copy.items():
            nethook.get_parameter(model, k)[...] = v.to(f'cuda:{hparams.device}')

However, a more scientific test method is to edit N items and use this checkpoint to test the performance of 1-N. You can appreciate the difference. If you go this route, the pseudocode looks like this:

for i, request in tqdm(enumerate(requests)):
    edited_model, weights_copy = edit_func(model, tok, request, hparams)
for i, request in tqdm(enumerate(requests)):
    edit_evaluation(all_metrics, request, edited_model, hparams, tok, i)

@pengzju
Copy link
Collaborator

pengzju commented Apr 8, 2024

If you have any questions, please feel free to leave a message. Thank you again for your attention. 😊

@zxlzr
Copy link
Contributor

zxlzr commented Apr 9, 2024

Hi, do you have any further issues?

@Wonder1905
Copy link
Author

No, thanks for the detailed comment!

This was referenced May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants