feat: Add Explanations to service APIs#216
Conversation
sasha-gitg
left a comment
There was a problem hiding this comment.
Added a few comments. Thanks!
| from google.cloud.aiplatform_v1beta1.types.explanation_metadata import ( | ||
| ExplanationMetadata, | ||
| ) | ||
| from google.cloud.aiplatform_v1beta1.types.explanation import ExplanationParameters |
There was a problem hiding this comment.
It makes sense to elevate these protos to the aiplatform namespace but ExplanationParameters relies on additional protos which are not elevated, requiring the user import from multiple modules to build the spec. Perhaps all of the required explanation protos should be encapsulated in the aiplatform.explain namespace.
There was a problem hiding this comment.
Sounds good, will elevate all Explanation protos to aiplatform.explain
There was a problem hiding this comment.
Actually only including protos that are used as inputs, and only raising ExplanationMetadata subclasses that are two levels deep. Lmk if you think we should include outputs too.
sasha-gitg
left a comment
There was a problem hiding this comment.
LGTM. Left a two more comments.
|
All requested changes from MB SDK Dev addressed. Blocking merge until receiving LGTM from XAI Eng. |
| Encoding = ExplanationMetadata.InputMetadata.Encoding | ||
| FeatureValueDomain = ExplanationMetadata.InputMetadata.FeatureValueDomain | ||
| Visualization = ExplanationMetadata.InputMetadata.Visualization | ||
|
|
There was a problem hiding this comment.
a bit orthogonal question: why don't we have Modality class?
There was a problem hiding this comment.
It appears that modality is a string field in InputMetadata according to the protos. Should it be an enum?
There was a problem hiding this comment.
I was looking at this proto. Do you know why it is an Enum in the DB one and not in the other by any chance? Anyhow, lgtm.
There was a problem hiding this comment.
Interesting, I raised this with jianan@ and he explained they lean towards string over enums in the API protos to avoid having to make frequent changes to those files while the DB protos are more strongly typed. If it improves usability, we could manually add the enum in the SDK but it would have to be kept in sync.
nanchenchen
left a comment
There was a problem hiding this comment.
Thanks for working on this! It looks good to me 👍
I only have a minor comment. Should be good to go after addressing it.
| if explanation_metadata or explanation_parameters: | ||
| explanation_spec = gca_endpoint.explanation.ExplanationSpec() | ||
| explanation_spec.metadata = explanation_metadata | ||
| explanation_spec.parameters = explanation_parameters | ||
| deployed_model.explanation_spec = explanation_spec | ||
|
|
There was a problem hiding this comment.
Since explanation_metadata and explanation_parameters must pass together, shouldn't this be an and instead of or?
There was a problem hiding this comment.
The thought behind this was allowing the service to throw the exception about them being passed together instead of creating two sets of validation. I confirmed that an error response is returned service-side right away if only one is passed.
There was a problem hiding this comment.
We inform the user in the docstring. Do you think we should add validation in the library as well?
python-aiplatform/google/cloud/aiplatform/models.py
Lines 480 to 481 in b5000c2
There was a problem hiding this comment.
I think telling users what will fail as early as possible will be better. We don't necessary need full validation (though it is good to have if it is low cost), but having some basic sanity check can help prevent user frustration (especially since all the operations here are async and have some wait time).
Also, I noticed that there other similar logics are using and (e.g., Ln 1287), so I thought it was unintentional :)
There was a problem hiding this comment.
Good point, I've added the local validation for ensuring they are passed together.
ExplanationMetadataandExplanationParametersto theaiplatformnamespaceExplanationSpecto the following methodsModel.batch_predict()Model.deploy()Model.upload()Endpoint.deploy()BatchPredictionJob.create()Endpoint.explain()to get predictions with explanations on deployed modelsFixes b/174502675 and part 1 of b/172828587 🦕