Fix #23853: AI Governance and Compliance Framework for AI Applications #23854
Conversation
github-actions
bot
added
backend
safe to test
|
TypeScript types have been updated based on the JSON schema changes in the PR |
| "resourceType": {"type": "string"} | ||
| } | ||
| }, | ||
| "hyperparameters": { |
There was a problem hiding this comment.
should we keep this as an open KV pair for people to define? similar to how we have it in mlmodel https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-spec/src/main/resources/json/schema/entity/data/mlmodel.json#L190
might be hard to keep tabs on every param
There was a problem hiding this comment.
- These 6 hyperparameters are the most common ones used in LLM training (universal across PyTorch, TensorFlow, JAX)
- Having them as structured fields provides type safety (number vs integer) and validation
- Makes UI forms easier - we can render proper input fields with appropriate controls
| "weightDecay": {"type": "number"} | ||
| } | ||
| }, | ||
| "trainingMetrics": { |
There was a problem hiding this comment.
same here, I guess depending on the model the metrics teams can track could be different
| }, | ||
| "required": ["name", "ruleType", "action"] | ||
| }, | ||
| "biasThreshold": { |
There was a problem hiding this comment.
Would it make sense to define Bias Metrics with our Metrics definition, link those metrics as entityRefs to the llmModel, and then have the threshold here as an EntityReference + Threshold number? This way we're sure we are always going to be following the same definitions, and users might be able to go and add further pieces without them being coupled to the schema
There was a problem hiding this comment.
Bias metrics are generic no? teams do not exactly what they want to track here. We need to be more prescriptive than having a generic metric
There was a problem hiding this comment.
- User Experience: These are "snapshot" metrics that represent the current state. Forcing users to create separate Metric entities for every AI application's bias score adds
significant overhead- Use Case: biasMetrics, performanceMetrics, etc. are NOT time-series metrics - they're current evaluation snapshots that belong to the entity
- Governance: Having bias metrics inline makes governance checks easier - you can immediately see if an application has bias without needing to follow references
- OpenMetadata Metric entities: These are designed for database/table metrics (like row count, column distributions), not AI evaluation metrics
- Different semantics: EntityReference to Metrics implies these are reusable metric definitions. But "overall bias score for Application X" is specific to that application, not
reusable
| } | ||
| } | ||
| }, | ||
| "biasMetrics": { |
There was a problem hiding this comment.
same, looks like we're redefining bias with possibly different keys/props
Jest test CoverageUI tests summary
|
|
|
2 participants
Describe your changes:
Fixes #23853
I worked on ... because ...
Type of change:
Checklist:
Fixes <issue-number>: <short explanation>