Various requests and LIG bug about transformers-interpret HOT 1 CLOSED

Hi @rpryzant,

Thank you very much for the suggestions and input, this package is super nascent at the moment and there are a lot of things I would like to change going forward with it many of which you have mentioned here. I'm going to address each of your comments point by point as I think that's easiest:

1. Totally in agreement on this, it's my biggest issue with the package at the moment aswell especially since I've been working on a question answering explainer and the design of the constructor has kind of started to fall apart. I'm going to separate the constructor from the instantiated object. At the time I guess I really liked the idea of a one liner but it doesn't really work well and the two behaviors are confusing.

The only change I would make to the example you provided is that I would try and keep the instance of the explainer as a callable rather than invoking a explain method, I would be interested though in why you would do it this way. Also when you refer to the products of the inference and attribution living in the same versus different object I couldn't see a significant difference between your first and last example other than text being a required argument to the explain method.

This is how I would go about structuring the interface:

    explainer = SequenceClassificationExplainer(model, tokenizer)    
    for text, label in zip(texts, labels):
        attributions = explainer(text= text, index=1)
        print(attributions.word_attributions)            
        print(attributions.predicted_class_index)

2. You're right I think this is a layover of an old bug I was having with the visualizer where I was casting everything to string for safety. I'm doing two different behaviors here for models of different types i.e. models that have a single node output are having the class cast to a int (either 0 or 1) whereas models that have multi-node ouputs have the true class cast to a string. I'll definitely fix this although I don't think it should be causing any major issues as the type casting here is purely cosmetic.

3. I think you be incorrect here, from what I can see I am using ref_input_ids which is special tokens plus pads for attributions, when token type ids and position ids are available I also use their reference type ids as well. The team at Captum were very helpful recently in helping me figure out how to pass reference ids for token type and position ids you can check that out here pytorch/captum#624

4. Yep it does, that's probably going to go in the next update.

5. The latest version should be returning the iPython HTML object in visualize, writing to a file has been optional from the start I believe.

Thank you again for this input, I really appreciate it especially at this stage of the project, I think it has a lot of room to grow but I need to figure out interface issues like those you have highlighted first. Would love to hear any other suggestions you might have in the future.

from transformers-interpret.