Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore: Refactoring inconsistent naming and unnecessary model type (#592)
<!-- Thanks for sending a pull request! Here are some tips for you: 1. Run unit tests and ensure that they are passing 2. If your change introduces any API changes, make sure to update the e2e tests 3. Make sure documentation is updated for your PR! --> # Description <!-- Briefly describe the motivation for the change. Please include illustrations where appropriate. --> This PR mainly do refactoring to ml observability related code. Following are the issues: * Inconsistent field name between `InferenceSchema` and `PyfuncV3Model` `ModelInput` and `ModelOutput`. In `InferenceSchema` unique identifier for each prediction is defined in `row_id_column` where in `ModelInput` and `ModelOutput` are stored in `prediction_ids`. To make the term consistent we will change `prediction_ids` into `row_ids` * Initially we add new model type when a model wants to onboard to ml observability, but this is necessary user just need to implement `PyfuncV3Model` instead of old `PyFuncModel` and use existing `pyfunc` model type * Update documentation on model schema and model observability # Modifications <!-- Summarize the key code changes. --> * Remove all the code that using `pyfunc_v3` as model type * `python/sdk/merlin/pyfunc.py` -> Add `row_ids` on `ModelInput` and `ModelOutput`, not remove `prediction_ids` yet to support backward compatibility # Tests <!-- Besides the existing / updated automated tests, what specific scenarios should be tested? Consider the backward compatibility of the changes, whether corner cases are covered, etc. Please describe the tests and check the ones that have been completed. Eg: - [x] Deploying new and existing standard models - [ ] Deploying PyFunc models --> # Checklist - [x] Added PR label - [ ] Added unit test, integration, and/or e2e tests - [ ] Tested locally - [x] Updated documentation - [ ] Update Swagger spec if the PR introduce API changes - [ ] Regenerated Golang and Python client if the PR introduces API changes # Release Notes <!-- Does this PR introduce a user-facing change? If no, just write "NONE" in the release-note block below. If yes, a release note is required. Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". For more information about release notes, see kubernetes' guide here: http://git.k8s.io/community/contributors/guide/release-notes.md --> ```release-note ```
- Loading branch information