feat: Add options for what to do with missing metadata fields in MetaFieldRanker

[robpasternak]

Related Issues

• fixes MetaFieldRanker: allow different options for what to do with missing metadata field #7691
• Adds param missing_meta to MetaFieldRanker:

        :param missing_meta:
            What to do with documents that are missing the sorting metadata field.
            Possible values are:
            - 'drop' will drop the documents entirely.
            - 'top' will place the documents at the top of the metadata-sorted list
                (regardless of 'ascending' or 'descending').
            - 'bottom' will place the documents at the bottom of metadata-sorted list
                (regardless of 'ascending' or 'descending').

Proposed Changes:

• The missing_meta param has three options: "bottom", "top", and "drop".
  • Using "bottom" exhibits the same behavior as was implemented prior to this PR, i.e., documents without the sorting metadata field are put on the bottom of the sorted list.
  • Using "top" puts them at the top instead.
  • Using "drop" drops such documents entirely.
• Validation was added to ensure that the value of missing_meta is legit.
• Tests were added for the new functionality.

How did you test it?

Wrote and tried new tests functions in the test directory:

• test_raises_value_error_if_wrong_missing_meta: Tests validation of missing_meta
• test_missing_meta_bottom: Tests that missing_meta = "bottom" behaves as desired.
• test_missing_meta_top: Tests that missing_meta = "top" behaves as desired.
• test_missing_meta_drop: Tests that missing_meta = "drop" behaves as desired.

Notes for the reviewer

None

Checklist

• I have read the contributors guidelines and the code of conduct
• I have updated the related issue with new insights and changes
• I added unit tests and updated the docstrings
• I've used one of the conventional commit types for my PR title: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test:.
• I documented my code
• I ran pre-commit hooks and fixed any issue

[coveralls]

Pull Request Test Coverage Report for Build 9449261101

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 61 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+0.09%) to 89.818%

---

Files with Coverage Reduction	New Missed Lines	%
components/evaluators/llm_evaluator.py	2	95.5%
evaluation/eval_run_result.py	4	92.19%
core/pipeline/base.py	14	93.73%
core/pipeline/pipeline.py	41	62.58%

Totals
Change from base Build 9387490162:	0.09%
Covered Lines:	6854
Relevant Lines:	7631

---

💛 - Coveralls

[shadeMe]

Thanks for the PR! Added a few comments.

[shadeMe]

Hmm, I'd want to convert the Literal init parameters to follow the enum pattern seen in other parts of the library (c.f HFGenerationAPIType and HuggingFaceAPIGenerator).

Would you be up to fixing that in a follow-up PR? This would also mean that the validation code gets changed/moved around.

[shadeMe]

Once we introduce the enum, the bulk of this docstring can be moved to the corresponding docstrings of the former.