feat: DataProcessor v1

[dushyantbehl]

Description of the change

This PR is to be merged after #398 as it follows the changes. Once #398 is merged this PR will be rebased on top of it.

This PR is to provide a data preprocessor framework which will enable flexibility to easily add more data preprocessing features in the future. This PR covers the following:

• Change base framework to the new configurable framework
  • Preprocessing utils function changed from format_dataset to process_dataargs
• Handle currently supported features using the new base framework
• Cleanup redundant code and port unit tests.
• Unit testing data preprocessor
• Unit testing setup data preprocessor

This PR does not explicitly enable any new features in fms-hf-tuning, it's purpose is to more easily allow new features to be added in the future by changing the backend.

Co-Authored by @willmj @Abhishek-TAMU

How to verify the PR

• New/refactored unit tests located in testing/data
• Unit tests of train() function
• Run e2e tuning + vLLM (see example build)

Was the PR tested

• I have added >=1 unit test(s) for every new method I have added.
• I have ensured all unit tests pass

[github-actions]

Thanks for making a pull request! 😃
One of the maintainers will review and advise on the next steps.

[Abhishek-TAMU]

@dushyantbehl Thanks for the PR to let us know on the WIP. Just some comments on below would be appreciated.

[Abhishek-TAMU]

When raw_datasets = raw_datasets.map(handler, **kwargs) is called and kwargs["batched"] = True then element[f"{dataset_text_field}"] here would be a list right. So does below condition make sense ?

if isinstance(element[dataset_text_field], list): # batched = True
      return {
          f"{dataset_text_field}": [
              text + tokenizer.eos_token for text in element[f"{dataset_text_field}"]
          ]
      }
return {
    f"{dataset_text_field}": element[f"{dataset_text_field}"] + tokenizer.eos_token
}
  

And similar case addition in tokenize_and_apply_instruction_masking logic when kwargs["batched"] = True

[dushyantbehl]

Thanks for the catch @Abhishek-TAMU yes I need to update the code below.

[dushyantbehl]

@Abhishek-TAMU I consciously reverted this change and made our default handlers run in batched=False mode for now, we can mention this in documentation for people to not use these handlers in batched mode. This change was made due to the fact that this and the other handlers we have defined right now are complex operations and need us to deconstruct each example from a batch before processing them.

That being said this was after I had already implemented a patch to make all handlers take in batched and non-batched input and it is here in a different branch
so we can even cherry pick this to the current branch if needed.

cc @Ssukriti @willmj @ashokponkumar

[Abhishek-TAMU]

so we can even cherry pick this to the current branch if needed.

This sounds fine to me.

[willmj]

Thanks for the WIP PR @dushyantbehl, it's looking really nice so far!
Would definitely like to see some unit tests for these new data types and functions using the example configs you provided as unit tests will only get harder to add as we continue to build onto this. Additionally, we need to make sure our current unit tests pass to retain existing behavior. Overall though, these changes are a great starting point - thanks for your hard work on this!

[Abhishek-TAMU]

Thanks Dushyant for cleanup of format_dataset function and related test cases.
Thanks Will for the multi-gpu fix. Cleanup and other changes looks good to me as its not affecting current implementation.

[fabianlim]

I feel the PR lacks docmentation. We should have some things written out for the common use cases

• adding a new data preprocessor
• adding a new handler. etc..
• fallback on for use cases that does not require the data preprocessor routines..
• how to write a data config.. etc.

[ashokponkumar]

I feel the PR lacks docmentation. We should have some things written out for the common use cases

• adding a new data preprocessor
• adding a new handler. etc..
• fallback on for use cases that does not require the data preprocessor routines..
• how to write a data config.. etc.

We definitely need it, but we will add it in the next PR where we will be exposing these features to external users. Currently these are internal implementation which is used by the existing exposed interface.

So I would recommend going ahead with this PR and following it up with these documentations in the next PR.

[fabianlim]

I am ok that my comments are addressed, cc: @ashokponkumar @Ssukriti

[dushyantbehl]

@dushyantbehl Support for packing pre-tokenized datasets is now first class feature in huggingface/trl. Good to allow for that in fms-hf-tuning.

fms-hf-tuning check previously present which can be relaxed and as well absorbed in to this PR :

fms-hf-tuning/tuning/utils/preprocessing_utils.py

Line 85 in 5c29940

raise ValueError("packing will not be used when datasets are pretokenized")

PR for reference: huggingface/trl#2011

cc: @ashokponkumar

@kmehant this change has been reverted for now as we need to get transformers up to the version where this patch will be supported. Please open up an issue and we can take this up when trl is up to date.

[willmj]

LGTM