Skip to content

Combine GPTHuggingfaceDatasetConfig input sources into source_schema #255

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

Draft
wants to merge 14 commits into
base: generalize_dynamic_classes
Choose a base branch
from

Conversation

nitsanluke
Copy link
Contributor

@nitsanluke nitsanluke commented May 7, 2025

✨ Description

This PR creates a common interface for all GPTHuggingfaceDatasetConfig input columns via the new source_schema variable. Beyond the variable filed we require additional keys to preprocess and tokenize different types of datasets. (eg: SFT, combine cols, etc).
Therefore we have created a new variable source_schema which can accommodate these different data sources specific preprocessing and tokenization. Current variables field and loss_masking_spans are moved into TextColumnConfig as a type of input/data source.

Merge after #245

🔍 Type of change

Select all that apply:

  • 🐛 Bug fix (non-breaking change that addresses a specific issue)
  • 🚀 New feature (non-breaking change that adds functionality)
  • ⚠️ Breaking change (a change that could affect existing functionality)
  • 📈 Performance improvement/optimization (improves speed, memory usage, or efficiency)
  • 🛠️ Code refactor (non-functional changes that improve code readability, structure, etc.)
  • 📦 Dependency bump (updates dependencies, including Dockerfile or package changes)
  • 📝 Documentation change (updates documentation, including new content or typo fixes)
  • 🔧 Infrastructure/Build change (affects build process, CI/CD, or dependencies)

📝 Changes

List the key changes introduced in this PR:

✅ Checklist

Make sure the following tasks are completed before submitting the PR:

General

  • 📜 I have read and followed the contributing guidelines.
  • 🏷️ I am using a clear and descriptive PR title that summarizes the key change or feature introduced.
  • 🎉 The functionality is complete, and I have tested the changes.
  • 📝 I have updated the documentation if needed.
  • ⚠️ The change does not introduce any new issues (e.g., runtime warnings, type checker errors, linting problems, unhandled edge cases).
  • 🧩 I have commented my code, especially in hard-to-understand areas.

Dependencies and Configuration

  • 🐋 I have updated the Docker configuration or dependencies, if applicable.
  • 🔄 I have ensured compatibility with the existing setup after dependency changes.

Testing

  • 🧪 I have added or updated tests to cover my changes.
  • ✔️ New and existing tests pass locally with my changes.
  • 🚦 I have tested these changes on GPUs and verified training stability.
  • 🏋️ I have tested the changes on realistic training workloads, if applicable.

Copy link
Collaborator

@tscholak tscholak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one minor suggestion, otherwise LGTM!

class SourceSchemaConfig(Config):
pass

class TextColumnConfig(SourceSchemaConfig):
Copy link
Collaborator

@tscholak tscholak May 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
class TextColumnConfig(SourceSchemaConfig):
class TextColumnConfig(SourceSchemaConfig):
type: ClassVar[str] = "text_column"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jlamypoirier, what's the endorsed idiom for this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing until we merge @245. Then we can add to registry. This one won't work unless it's marked as a classvar

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nitsanluke's PR is assuming #245 is getting merged. It's branching off from the generalize_dynamic_classes branch of #245.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, then it needs to be registered after the class definition, ex. https://github.com/ServiceNow/Fast-LLM/pull/245/files#diff-7001a0c0d12d5adf8e07c112218448985de3f25255f166f01d001768c7130788R148. Here something like SourceSchemaConfig.register_subclass("text_column", TextColumnConfig).

nitsanluke and others added 9 commits May 8, 2025 15:27
Co-authored-by: Torsten Scholak <torsten.scholak@googlemail.com>
Co-authored-by: Torsten Scholak <torsten.scholak@googlemail.com>
…com:ServiceNow/Fast-LLM into restructure_dataset_config_for_multi_source
Co-authored-by: Torsten Scholak <torsten.scholak@googlemail.com>
…com:ServiceNow/Fast-LLM into restructure_dataset_config_for_multi_source
Comment on lines 40 to 41
_data_column: str
_loss_masking_spans_column: str | None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qq: do we need to make these class variables? With more schemas coming in, we would have to define class variables for fields in each of them. Wouldn't it be simpler to directly access them from the schema config?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the type class variable is a discriminator field. It tells fast-llm to instantiate the right class when deserializing the config from yaml

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only need one such discriminator field (type: ClassVar[str]) per source schema config class

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait a sec. This isn’t the class I thought I was looking at. I think you’re right @sohamparikh, I don’t think we need these fields here. @nitsanluke?

Copy link
Contributor Author

@nitsanluke nitsanluke May 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sohamparikh The idea was to separate the set of vars used by prepare from the config; since we can't change config vars after defining. So it become complex to use the same var with multiple data sources (need to set during validation). Eg: For the concat case the new col that would be generated during the execution will take the place of _data_column and rest of the prepare code doesn't have to change. The separation allows for different source schema to use the class vars to setup for the specific use-case they are dealing with. We can discuss further to see if the alternative has more benefits.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to use a typing.ClassVar[str] in the config class. Or for more flexibility it could be a @property or @cachedproperty

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @nitsanluke, makes sense to separate them from the config
With more modalities coming in (image, audio), could we rename _data_column to _text_column?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to _text_column

@nitsanluke nitsanluke changed the title Combine GPTHuggingfaceDatasetConfig input sources into data_source Combine GPTHuggingfaceDatasetConfig input sources into source_schema May 9, 2025
default="text",
desc="Field of the dataset to use.",
source_schema: SourceSchemaConfig = Field(
default_factory=TextColumnConfig,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default_factory doesn't actually work and is removed for config classes in #245. I'm working on a way to set a default subclass https://github.com/ServiceNow/Fast-LLM/pull/245/files#diff-7001a0c0d12d5adf8e07c112218448985de3f25255f166f01d001768c7130788R44.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will remove it from here and keep a TODO.

@tobyzl2 tobyzl2 mentioned this pull request May 12, 2025
Merged
25 tasks
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

Successfully merging this pull request may close these issues.

4 participants