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

filter on loading rather than increase loading limit #584

Merged
merged 2 commits into from
Feb 28, 2024

Conversation

dafnapension
Copy link
Collaborator

@dafnapension dafnapension commented Feb 20, 2024

per @elronbandel comment in recent PR:
Perhaps employing the HuggingFace filter upfront can ease load on the system, better than increase loading_limit only to allow the following pre-processing step that filters out.

Copy link

codecov bot commented Feb 20, 2024

Codecov Report

Attention: Patch coverage is 88.88889% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 88.59%. Comparing base (3923a46) to head (3818172).

Files Patch % Lines
src/unitxt/loaders.py 75.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #584      +/-   ##
==========================================
+ Coverage   88.55%   88.59%   +0.03%     
==========================================
  Files          87       87              
  Lines        7858     7876      +18     
==========================================
+ Hits         6959     6978      +19     
+ Misses        899      898       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@dafnapension dafnapension force-pushed the filtering_lambda branch 3 times, most recently from d24c938 to 89b6316 Compare February 21, 2024 08:12
Copy link
Member

@elronbandel elronbandel left a comment

Choose a reason for hiding this comment

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

I like the idea. Could we do it with expression rather then lambda? What sould be with other loaders which are not HFLoader? Lastly maybe we should consider doing it all through an independent operator?

@dafnapension
Copy link
Collaborator Author

dafnapension commented Feb 21, 2024

My understanding of the HF api, is that a function returning True or False, when fed with an insrance, is needed there. We need it to be artifact-able, so can be cataloged. Lambda seemed most apropriate.
Another, safer, solution can be laid on the shoulders of recipe: if it sees a filter by condition, or by expression, operator among the steps, the recipe should position any stream refiner by number - following the filter. perhaps always have the refiners -- the last in the pipeline?
The loader cache will still have to suffer, but no more than necessary, and the solution is universal.

I see that currently, the load limits sneak into the loader, and become effective as it actually loads. Is it advisable to change this too?

@dafnapension dafnapension force-pushed the filtering_lambda branch 4 times, most recently from c803772 to a6becb2 Compare February 28, 2024 11:53
Signed-off-by: dafnapension <dafnashein@yahoo.com>
…overage

Signed-off-by: dafnapension <dafnashein@yahoo.com>
@dafnapension dafnapension merged commit bc498c2 into main Feb 28, 2024
7 checks passed
@dafnapension dafnapension deleted the filtering_lambda branch February 28, 2024 17:06
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.

2 participants