While investigating a discrepancy between the predictions of a ClassifierFCM and an equivalent standalone AutoGluon model, I found that the issue was caused by the ordering of the parent variables passed to estimate_probabilities().
The current API is:
estimate_probabilities(parent_samples: np.ndarray)
Since the input is a NumPy array, there is no feature name information. The method implicitly assumes that the columns are provided in exactly the same order that was used during fitting (internally obtained from get_ordered_predecessors(...)).
For example, if the model is fitted using
training_data[get_ordered_predecessors(graph, target)]
then every subsequent call to
estimate_probabilities(...)
must provide the columns in exactly that same order.
If the same variables are provided in a different order (even with identical values), the method silently returns incorrect probabilities, since the features are interpreted positionally.
I think there are two possible improvements.
- Document the ordering requirement
The docstring of estimate_probabilities() (and similar prediction methods) should explicitly state that the input columns must be provided in the same order used during fitting.
For example:
parent_samples must contain the parent variables in the same column order used during fitting (typically the order returned by get_ordered_predecessors(...)).
This would make the API contract explicit and avoid difficult-to-diagnose errors.
- Provide a DataFrame-based prediction API
A safer alternative would be to provide an additional method, for example:
estimate_probabilities_dataframe(parent_samples: pd.DataFrame)
This method could:
verify that all expected parent columns are present,
reorder them automatically according to the fitted model,
internally call the existing NumPy implementation.
This would make the API much safer for external users while preserving the current NumPy-based implementation for internal use and maximum performance.
While investigating a discrepancy between the predictions of a ClassifierFCM and an equivalent standalone AutoGluon model, I found that the issue was caused by the ordering of the parent variables passed to estimate_probabilities().
The current API is:
estimate_probabilities(parent_samples: np.ndarray)
Since the input is a NumPy array, there is no feature name information. The method implicitly assumes that the columns are provided in exactly the same order that was used during fitting (internally obtained from get_ordered_predecessors(...)).
For example, if the model is fitted using
training_data[get_ordered_predecessors(graph, target)]
then every subsequent call to
estimate_probabilities(...)
must provide the columns in exactly that same order.
If the same variables are provided in a different order (even with identical values), the method silently returns incorrect probabilities, since the features are interpreted positionally.
I think there are two possible improvements.
The docstring of estimate_probabilities() (and similar prediction methods) should explicitly state that the input columns must be provided in the same order used during fitting.
For example:
parent_samples must contain the parent variables in the same column order used during fitting (typically the order returned by get_ordered_predecessors(...)).
This would make the API contract explicit and avoid difficult-to-diagnose errors.
A safer alternative would be to provide an additional method, for example:
estimate_probabilities_dataframe(parent_samples: pd.DataFrame)
This method could:
verify that all expected parent columns are present,
reorder them automatically according to the fitted model,
internally call the existing NumPy implementation.
This would make the API much safer for external users while preserving the current NumPy-based implementation for internal use and maximum performance.