Forum Discussion
MLFlow - Problem with aliases and metrics
- 6 months ago
What you’re seeing is expected MLflow behavior, and it can be confusing at first in Fabric.
Key point: in MLflow, metrics/params live on the Run, not on the Model Registry objects. A ModelVersion (or ModelInfo, LoggedModel, etc.) typically exposes registry metadata (name, version, tags, source, run_id), but not the run’s params/metrics directly. The right pattern is:
ModelVersion → run_id → client.get_run(run_id)
If aliases are failing in Fabric, it’s usually because the hosted registry endpoint doesn’t support the alias APIs (or the underlying MLflow server feature set differs). In that case, a practical workaround is to use model version tags as a “pseudo-alias” (e.g., champion=true, env=prod) and resolve your “production” version via tags.
References:
MLflow Client / Registry API: https://mlflow.org/docs/latest/python_api/mlflow.client.html
MLflow Model Registry (aliases & versions): https://mlflow.org/docs/latest/ml/model-registry/ and https://mlflow.org/docs/latest/ml/model-registry/tutorial/
Fabric ML model experience (run tracking + registering): https://learn.microsoft.com/en-us/fabric/data-science/machine-learning-model
import mlflow from mlflow.tracking import MlflowClient client = MlflowClient() model_name = "<YOUR_MODEL_NAME>" model_version = "<YOUR_VERSION_NUMBER>" # e.g. "3" # 1) Registry -> ModelVersion mv = client.get_model_version(name=model_name, version=model_version) print("Model:", mv.name, "Version:", mv.version, "RunId:", mv.run_id) # 2) Run -> params/metrics run = client.get_run(mv.run_id) print("\nParams:") print(run.data.params) print("\nMetrics:") print(run.data.metrics) # Optional: metric history (if you logged multiple values over time) # hist = client.get_metric_history(mv.run_id, "accuracy") # print(hist)
What you’re seeing is expected MLflow behavior, and it can be confusing at first in Fabric.
Key point: in MLflow, metrics/params live on the Run, not on the Model Registry objects. A ModelVersion (or ModelInfo, LoggedModel, etc.) typically exposes registry metadata (name, version, tags, source, run_id), but not the run’s params/metrics directly. The right pattern is:
ModelVersion → run_id → client.get_run(run_id)
If aliases are failing in Fabric, it’s usually because the hosted registry endpoint doesn’t support the alias APIs (or the underlying MLflow server feature set differs). In that case, a practical workaround is to use model version tags as a “pseudo-alias” (e.g., champion=true, env=prod) and resolve your “production” version via tags.
References:
MLflow Client / Registry API: https://mlflow.org/docs/latest/python_api/mlflow.client.html
MLflow Model Registry (aliases & versions): https://mlflow.org/docs/latest/ml/model-registry/ and https://mlflow.org/docs/latest/ml/model-registry/tutorial/
Fabric ML model experience (run tracking + registering): https://learn.microsoft.com/en-us/fabric/data-science/machine-learning-model
import mlflow
from mlflow.tracking import MlflowClient
client = MlflowClient()
model_name = "<YOUR_MODEL_NAME>"
model_version = "<YOUR_VERSION_NUMBER>" # e.g. "3"
# 1) Registry -> ModelVersion
mv = client.get_model_version(name=model_name, version=model_version)
print("Model:", mv.name, "Version:", mv.version, "RunId:", mv.run_id)
# 2) Run -> params/metrics
run = client.get_run(mv.run_id)
print("\nParams:")
print(run.data.params)
print("\nMetrics:")
print(run.data.metrics)
# Optional: metric history (if you logged multiple values over time)
# hist = client.get_metric_history(mv.run_id, "accuracy")
# print(hist)- claudevs6 months agoFrequent Visitor
Thank you for your answer bariscihan
At the end, your solution is part of how we use MLFlow, nevertheless I´m still finding out more missing features of MLFlow in fabric, although these features also can be replaced with other approaches, It would be awesome if they could be implemented in the future, as MLFLow is a powerful tool that helps a lot in the ML model lifecycle process
- claudevs6 months agoFrequent Visitor
Thank you for your answer bariscihan
At the end, your solution is part of how we use MLFlow, nevertheless I´m still finding out more missing features of MLFlow in fabric, although these features also can be replaced with other approaches, It would be awesome if they could be implemented in the future, as MLFLow is a powerful tool that helps a lot in the ML model lifecycle proccess