Closed RaunoArike closed 1 year ago
This report describes the design choices we made throughout the process of integrating models defined using PyTorch into the CounterfactualExplanations.jl
package. We wrote functionality that supports generating counterfactuals for any neural network the user has defined and trained in PyTorch, regardless of the specific architectural details of the model.
When we started looking into possible ways of generating counterfactuals for Python models using Julia, we found three libraries that offered functionalities for conversion between Python and Julia:
ONNX.jl
Flux.jl
. This would have given Flux.jl
, a package already heavily integrated into our package, gradient access to any model defined using PyTorch, which would have enabled generating counterfactual explanations for PyTorch models in a very similar way to how the package already generates explanations for models from Flux.jl
.ONNX.jl
library is in the process of total reconstruction. As noted in JuliaHub, no conversion to Flux.jl
is implemented yet. As implementing this conversion would be a project worthy of a whole software project, we quickly realized that ONNX.jl
is not a feasible option for implementing support for Python models.ONNX.jl
has not been maintained particularly actively in recent times, we decided that it's best to look for an alternative solution.PyCall.jl
PyCall.jl
and torch for R through RCall.jl
in the same Julia session caused Julia to crash. We looked into the problems a bit and decided that there's a better alternative to PyCall.jl
that works in a different way and avoids this problem.PythonCall.jl
PyCall.jl
, this library is more recent and more actively maintained. For this reason, we decided that it would be easiest to solve the problems the client had been running into using this library.For the reasons described above, we decided to solve this problem using PythonCall.jl
.
Once we had implemented basic support for generating counterfactuals for PyTorch models through PythonCall.jl
, we discussed with the client whether the package should offer support only for PyTorch models predefined by the user in a Python environment or whether we should also offer support for training PyTorch models inside the package. Since defining PyTorch models through Julia code is tedious and error-prone, the client expected most users to only want counterfactuals for models they have themselves previously trained using PyTorch. Since the client has considerable machine learning experience and offered compelling reasons for this design choice, we decided not to offer special support for defining and training PyTorch models through our package.
Instead of relying on
PythonCall
to explain models trained in Python, investigate whether it's possible to use ONNX.jl to transform models intoFlux
models and then proceed as usual.