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

naming confuse from code to paper, and outer-loop procedure. #2

Closed
leeeizhang opened this issue Dec 15, 2021 · 2 comments
Closed

naming confuse from code to paper, and outer-loop procedure. #2

leeeizhang opened this issue Dec 15, 2021 · 2 comments

Comments

@leeeizhang
Copy link

MeTAL is an inspiring effort for meta learning !!

I want to understand some details in your work:

  1. Is the generated_alpha_params and generated_beta_params represent the \gamma and \beta for affine transformation in https://github.com/baiksung/MeTAL/blob/master/inner_loop_optimizers.py#L137
  2. Can I understand your update for meta-learner as:
  • In inner-loop, the base-model will be trained with adaptive loss generated by \gamma and \beta from meta-learner;
  • In the outer-loop, the query set will be used to check the performance of the base-model from the inner-loop, and these losses will be used to update the meta-learner to generate more generalization loss.
  1. Suppose my comprehension of your work is proper. Could you answer one of my puzzles: when use the same task dataset for the inner and outer loop update, is it a cheat for meta-learner to generate robust and generalized parameters for the inner-loop to perform well? Just like giving the validation dataset for the model to train.

Thanks for your work again!! I am looking forward to your reply!

@baiksung
Copy link
Owner

baiksung commented Dec 15, 2021

Hi, thanks for the interest in our paper.

  1. The generated_alpha_params and generated_beta_params are the components of ALFA, which is my previous work. The affine transformation parameters for adaptive loss are generated by LossAdapter for labeled support examples at

    updated_meta_loss_weights = self.meta_loss_adapter(support_task_state, num_step, meta_loss_weights)
    and for unlabeled query examples at
    updated_meta_query_loss_weights = self.meta_query_loss_adapter(query_task_state.mean(0), num_step, meta_query_loss_weights)
    .
    The generated affine transformation parameters are fed into a meta-loss network for support examples at
    meta_support_loss = self.meta_loss(support_task_state, num_step, params=updated_meta_loss_weights).squeeze()

    and for query examples at
    meta_query_loss = self.meta_query_loss(query_task_state, num_step, params=updated_meta_query_loss_weights).mean().squeeze()
    .

  2. The first point is addressed in the response above. And the second point seems correct.

  3. I'm not sure if I understood your question correctly. Are you asking if it is correct to use the same data (support and query sets) for the given task? If so, it is ok as long as you don't use the labels for query sets since the query set is used to evaluate the generalization performance of the meta-learning algorithms. The semi-supervised inner-loop optimization proposed in this work utilizes unlabeled query examples (that is, without accessing the labels for query examples) for better adaptation. The setting that exploits the relationship between labeled and unlabeled examples is transductive setting and has been explored in many metric-based meta-learning algorithms for high performance (e.g., TPN). Hence, it is not a cheating but rather you can think of it as a form of semi-supervised learning.
    If you are interested in how MeTAL behaves when using unlabeled examples that are distinct from query examples, you can refer to Section C in our supplementary document.

Hope this clarifies! :)

@leeeizhang
Copy link
Author

thanks a lot for your explication about semi-supervise part I confused. we will follows MeTAL you proposed, and wish to see more innovative work your present in near future.

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

No branches or pull requests

2 participants