Feature/hf dataset augmentation

[RakshitKhajuria]

Description

Added support for loading HuggingFace Datasets for Augmentation tasks.

Notebook ➤ Demo

➤ Fixes #621

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Usage

custom_proportions = {
    'add_ocr_typo':0.3
}

data_kwargs = {
      "data_source" : "glue",
      "subset": "sst2",
      "feature_column": "sentence",
      "target_column": "label",
      "split": "train"
       }
harness.augment(
    training_data = data_kwargs,
    augmented_data ="augmented_glue.csv",
    custom_proportions=custom_proportions,
    export_mode="add",
)

Checklist:

• I've added Google style docstrings to my code.
• I have linted my code
• I have added tests to cover my changes.

Screenshots (if appropriate):

[JulesBelveze]

@Prikshit7766 Why not doing something like?

harness.augment(
    input_path="glue",
    output_path="augmented.csv",
    custom_proportions=custom_proportions,
    export_mode="transformed",
    data_kwargs={
        "subset": "sst2",
        "feature_column": "sentence",
        "target_column": "label",
        "split": "train"
    }
)

then you simply have to do:

self.df.load_data(**data_kwargs)

[RakshitKhajuria]

@Prikshit7766 Why not doing something like?

harness.augment(
    input_path="glue",
    output_path="augmented.csv",
    custom_proportions=custom_proportions,
    export_mode="transformed",
    data_kwargs={
        "subset": "sst2",
        "feature_column": "sentence",
        "target_column": "label",
        "split": "train"
    }
)

then you simply have to do:

self.df.load_data(**data_kwargs)

Do we have to change this for the loading of hf dataset in the harness as well?
If yes then we will be adding one more parameter to the haness class. @JulesBelveze

[JulesBelveze]

@RakshitKhajuria Yes I don't think it's too bad to have an optional parameter called data_kwargs in the Harness constructor.. Also, I don't see any other way around it..
@ArshaanNazir what's your opinion?

[ArshaanNazir]

@RakshitKhajuria Yes I don't think it's too bad to have an optional parameter called data_kwargs in the Harness constructor.. Also, I don't see any other way around it.. @ArshaanNazir what's your opinion?

@JulesBelveze adding an additional param was the initial thought. However David insisted of not adding more params to harness class.

[JulesBelveze]

@ArshaanNazir then I guess the only way is to delete the input_path parameter and have a data_kwargs parameter of type Dict which requires a key input_path and other keys are optional?

[ArshaanNazir]

@ArshaanNazir then I guess the only way is to delete the input_path parameter and have a data_kwargs parameter of type Dict which requires a key input_path and other keys are optional?

@ArshaanNazir then I guess the only way is to delete the input_path parameter and have a data_kwargs parameter of type Dict which requires a key input_path and other keys are optional?

But our main use case was to retrain our own models. ( with data on which they have being trained )

h.augment( input_path = "train.conll" , ****) looks more appealing in that way. But yes, it will make it more generic.

What do you think @JulesBelveze ?

[ArshaanNazir]

data_kwargs

In this case, we can name it as training_data (parameter as Dict) , with data_source and other optional and output_path can be augmented_data

[Prikshit7766]

data_kwargs

In this case, we can name it as training_data (parameter as Dict) , with data_source and other optional and output_path can be augmented_data

@ArshaanNazir
can you provied one sample example for both the cases

[JulesBelveze]

LGTM

[RakshitKhajuria]

LGTM

@JulesBelveze don't merge it yet. We will be updating this PR with the notebook 😊