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

Parameter sensitivity analytic engine. #133

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

sergey-serebryakov
Copy link
Contributor

Related Issues / Pull Requests

This PR depends on #131.

Description

This analytic engine is designed to compute how machine learning metrics such as accuracy depend on variations of (hyper-) parameters such as learning rate. In this initial implementation, the engine consumes data from graph or tabular data sources. It creates a report object that brings together various pieces of information that can be useful to build real-world reports. This information includes name of a parameter, name of a metric and list of metric values.

What changes are proposed in this pull request?

  • New feature (non-breaking change which adds functionality).

Checklist:

  • My code follows the style guidelines of this project (PEP-8 with Google-style docstrings).
  • I have commented my code.
  • I have added tests that prove my fix is effective or that my feature works.
  • New and existing unit tests pass locally with my changes.

This commit adds doc strings and type annotation for CmfQuery class methods.
- References to `client` in the source code (e.g., CmfClient instead of CmfQuery) are removed.
- Several bugs related to checking input dict parameters are fixed (e.g., `d = d or {}` where it should be `if d is None: d= {}`). Now, the corrent object is returned when input dict is just empty.
- Missing doc strings and type annotations are added.
- Additional checks and log messages are added.
Fixing one possible bug related to accessing a column in a data frame when this data frame is empty.
Adding key mapper classes to help map source to target keys when copying dictionaries.
The API implements graph-like API to traverse CMF metadata in a graph-like manner. The entry point is the
`MetadataStore` class that retrieves from metadata store pipelines, stages, executions and artifacts. Users
can specify search query to specify what they want to return (the query is basically the value for the
`filter_query` parameter of the `ListOptions` class ML Metadata (MLMD) library).

Each node mentioned above (pipeline, stages, executions and artifacts) havs its own Python wrapper class that
provides developer-friendly API to access node's parameters and travers graph of machine learning concepts (e.g.,
get all stages of a pipeline or get all executions of a stage).

The graph API also provides the `Properties` wrapper for MLMD's properties and custom_propertied nodes' fields.
This wrapper implements the `Mapping` API and automatically converts MLMD's values to Python values on the fly.
- Adding unit tests (97% coverage).
- Renaming certain classes, redesigning implementation of several methods.
- Adding `Type` class that represents concepts such as ContextType, ExecutionType and ArtifactType in MLMD library.
- Implementation of multiple analytic functions.
- Unified mechanism to traverse graph of artifacts along their dependency paths.
- New traverse API.
- Base methods.
- Allow users to specify selection criteria for artifacts in some methods.
- Adding HPE header.
- Improving doc strings for classes that are responsible for traversing MLMD graph of artifacts.
This analytic engine is designed to compute how machine learning metrics such as accuracy depend on variations of (hyper-) parameters such as learning rate. In this initial implementation, the engine consumes data from graph or tabular data sources. It creates a `report` object that brings together various pieces of information that can be useful to build true reports. This information includes now name of a parameter, name of a metric and list of metric values.
Copy link
Contributor

@annmary-roy annmary-roy left a comment

Choose a reason for hiding this comment

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

@sergey-serebryakov A session to explain these changes would be good

raise NotImplementedError


class ParameterSensitivityReport:
Copy link
Contributor

Choose a reason for hiding this comment

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

@sergey-serebryakov should'nt we consider the parameter values also for sensitivity report ?

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